In diesem Leitfaden beleuchten wir eingehend die Logik hinter dem Übergang von traditionellen On-Premise-Umgebungen zu modernen Cloud-Architekturen, die Service- und Bereitstellungsmodelle, das Cloud-Netzwerkdesign (SDN/VPC) aus der Perspektive eines Infrastruktur-Ingenieurs, die Prinzipien der Hochverfügbarkeit (HA) sowie die Sicherheitsregeln, die man auf keinen Fall übersehen sollte.
1. Der Übergang von On-Premise zur Cloud#
Beim Aufbau eines Systems in einer traditionellen On-Premise-Architektur (lokales Rechenzentrum) ist ein erheblicher physischer Aufwand und Prozessmanagement erforderlich: Beschaffung physischer Server, Verkabelung, Klimatisierung, unterbrechungsfreie Stromversorgung (USV), Rack-Layout und Netzwerkhardware (Switches, Router, Firewalls).
Die größten Einschränkungen dieses traditionellen Ansatzes sind:
- CapEx-Belastung (Capital Expenditure): Hohe Anfangsinvestitionen. Es müssen enorme Hardware-Investitionen getätigt werden, bevor die tatsächliche Traffic-Last und der Erfolg eines Projekts überhaupt bekannt sind.
- Das Dilemma der Kapazitätsplanung: Bei plötzlichen Traffic-Spitzen kann das System überlastet werden und ausfallen (Under-Provisioning); oder Hardware wird mit Blick auf Spitzenlasten angeschafft, wodurch an normalen Tagen bis zu 80 % der Ressourcen ungenutzt bleiben (Over-Provisioning).
- Mangelnde Agilität: Die Bestellung, Lieferung, Montage und Konfiguration eines neuen Servers kann Wochen oder sogar Monate dauern.
Cloud Computing verwandelt Hardware von einem physischen Gut in eine Dienstleistung (Utility) und ein Software-Objekt. Ähnlich wie beim Strom- oder Wassernetz: Man erzeugt genau die benötigte Ressource sofort, zahlt nur für das, was man nutzt (Pay-as-you-go), und zerstört die Ressource nach Gebrauch mit einem einzigen API-Aufruf.
2. Cloud-Servicemodelle (XaaS)#
Cloud-Dienste werden je nach Abstraktionsgrad und Verantwortungsverteilung in drei Hauptkategorien unterteilt:
| Servicemodell | Ihre Verantwortung | Verantwortung des Cloud-Anbieters |
|---|---|---|
| SaaS | Nur Daten und Nutzung | Anwendung, Runtime, Betriebssystem, Hardware |
| PaaS | Anwendung und Daten | Runtime, Betriebssystem, Virtualisierung, Hardware |
| IaaS | Betriebssystem, Anwendung, Netzwerkkonfiguration | Virtualisierung, Hardware, Rechenzentrum |
🏢 IaaS (Infrastructure as a Service)#
Dies ist die grundlegendste Infrastrukturebene. Hardware und Virtualisierungsschicht werden vom Cloud-Anbieter (AWS, Azure, GCP) verwaltet; der virtuelle Server (VM), der Speicher, die Wahl des Betriebssystems und die detaillierte Netzwerkkonfiguration liegen vollständig in Ihrer Hand.
- Anwendungsfall: Bestehende On-Premise-Systeme unverändert in die Cloud verlagern (Lift-and-Shift) oder Infrastrukturen, die vollständige Kontrolle erfordern.
- Beispiele: AWS EC2, Azure VMs, Google Compute Engine.
🛠️ PaaS (Platform as a Service)#
Betriebssystem-Updates, Sicherheitspatches, die Verwaltung der Laufzeitumgebung (Runtime: Node.js, Python, Java usw.) und der Datenbank-Engine werden dem Cloud-Anbieter überlassen. Der Entwickler schreibt lediglich seinen Code und stellt ihn bereit.
- Anwendungsfall: Software-Teams, die ihr Produkt bzw. ihre Anwendung schnell live bringen möchten, ohne Zeit mit Serververwaltung zu verlieren.
- Beispiele: AWS Elastic Beanstalk, Heroku, Google App Engine, Azure App Service.
📦 SaaS (Software as a Service)#
Vollständig verwaltete, gebrauchsfertige Software für Endnutzer, die über einen Webbrowser oder eine API zugänglich ist. Es ist weder Programmierung noch Hardwareverwaltung erforderlich.
- Beispiele: Google Workspace, Microsoft 365, Salesforce, Jira.
3. Cloud-Bereitstellungsmodelle (Deployment Models)#
- Public Cloud: Ein Modell, bei dem Ressourcen über das öffentliche Internet von Drittanbietern (AWS, Azure, GCP) für jedermann bereitgestellt werden. Bietet hohe Skalierbarkeit.
- Private Cloud: Eine Cloud-Infrastruktur, die ausschließlich einer einzigen Organisation zugeordnet ist und entweder im firmeneigenen Rechenzentrum (On-Premise) oder auf isolierten privaten Servern (OpenStack, VMware Cloud Foundation) läuft.
- Hybrid Cloud: Ein Modell, bei dem On-Premise-Infrastruktur sicher mit der Public Cloud verbunden wird und beide gemeinsam betrieben werden. Dies ist die bevorzugte Wahl für Organisationen – etwa im Finanz-, Gesundheits- und Bankwesen –, die sensible Daten verarbeiten, aber dennoch von der Flexibilität der Public Cloud profitieren möchten.
- Multi-Cloud: Eine Architektur, bei der zwei oder mehr Public-Cloud-Anbieter (z. B. AWS + Google Cloud) gleichzeitig genutzt werden, um die Abhängigkeit von einem einzelnen Anbieter (Vendor Lock-in) zu verringern und die jeweils besten Dienste zu kombinieren.
4. Ingenieurperspektive: Cloud und Software-Defined Networking (SDN)#
Ein weit verbreiteter Irrtum ist, dass die Cloud lediglich aus virtuellen Servern besteht. Tatsächlich kann keine Cloud-Architektur ohne ein solides, sauber isoliertes Netzwerkdesign sicher funktionieren. Konzepte aus der physischen Welt – VLANs, Subnetze, Routing-Tabellen, NAT und Firewalls – werden in der Cloud durch Software-Defined Networking (SDN) in code-basierte Strukturen überführt.
Design eines Virtual Private Cloud (VPC)#
Ein VPC ist eine logisch isolierte virtuelle Netzwerkumgebung innerhalb der Public Cloud, die ausschließlich Ihrer Organisation zugewiesen ist.
Subnetz-Hierarchie:
- Public Subnet: Das Netzwerksegment, das direkt mit dem Internet Gateway (IGW) verbunden ist und in dem Komponenten platziert werden, die von außen erreichbar sein müssen (Load Balancer, Bastion Hosts usw.).
- Private Subnet: Ein Segment, das nicht direkt aus dem Internet erreichbar ist, nur aus dem internen Netzwerk zugänglich ist und den Internetzugang über ein NAT-Gateway erhält (Anwendungsserver, Microservices).
- Database Subnet: Ein vollständig isoliertes Segment ohne jeglichen Internetzugang, das ausschließlich auf Anfragen aus dem Private Subnet reagiert.
Sicherheitsebenen (Defense in Depth):
- Security Group (SG): Eine zustandsbehaftete (stateful) Firewall auf Ebene des virtuellen Servers (ENI). Sobald eingehender Traffic zugelassen wird, wird der entsprechende Rückverkehr automatisch erlaubt.
- Network ACL (NACL): Eine zustandslose (stateless) Sicherheitsebene auf Subnetz-Ebene. Sowohl eingehende (Inbound) als auch ausgehende (Outbound) Regeln müssen explizit definiert werden.
[ Internet ]
↓
[ Internet Gateway ]
↓
[ Public Subnet ] ──> (Load Balancer / Security Group)
↓
[ NAT Gateway ]
↓
[ Private Subnet ] ──> (App Servers / Security Group)
↓
[ Database Subnet ] ──> (Isolated Database Cluster)Methoden zur Anbindung von On-Premise an die Cloud#
In hybriden Architekturen werden zwei grundlegende Methoden verwendet, um das lokale Rechenzentrum mit dem Cloud-VPC zu verbinden:
- Site-to-Site IPsec VPN: Ein über das Internet aufgebauter verschlüsselter Tunnel – schnell einzurichten und kostengünstig.
- Dedicated Direct Connection (AWS Direct Connect / Azure ExpressRoute): Eine feste, hochgeschwindige (1 Gbit/s–100 Gbit/s), latenzarme physische Glasfaserverbindung zwischen dem Rechenzentrum des Kunden und dem PoP des Cloud-Anbieters, die das öffentliche Internet vollständig umgeht.
5. Hochverfügbarkeit (High Availability) und Elastizität#
Zwei grundlegende Engineering-Prinzipien unterscheiden die Cloud-Architektur von traditionellen Strukturen:
🔄 Auto Scaling & Elastizität#
Die Erhöhung der Prozessor- (CPU) oder Arbeitsspeicherkapazität (RAM) eines Servers bei steigendem Traffic wird als Vertical Scaling (Scale Up) bezeichnet, während das Hinzufügen neuer Serverinstanzen mit denselben Eigenschaften als Horizontal Scaling (Scale Out) bekannt ist.
Dank der Auto Scaling Group (ASG)-Struktur in der Cloud kann die Architektur beispielsweise automatisch neue EC2/VM-Instanzen starten, sobald die CPU-Auslastung 70 % übersteigt, und diese wieder herunterfahren, wenn der Traffic sinkt.
🌐 Multi-AZ- und Multi-Region-Architektur#
- Availability Zone (AZ): Physisch getrennte Rechenzentren innerhalb einer Region, jeweils mit unabhängiger Strom-, Kühl- und Netzwerkinfrastruktur.
- Hochverfügbarkeit (HA): Damit das System bei Ausfall eines Servers unterbrechungsfrei weiterläuft, werden Anwendungen über Subnetze verteilt, die sich über mindestens zwei verschiedene AZs erstrecken, und durch einen Application Load Balancer (ALB) vorgeschaltet.
6. Sicherheit und das Modell der geteilten Verantwortung (Shared Responsibility Model)#
Der größte strategische Fehler in der Cloud-Sicherheit ist die Denkweise “Wir haben alles in die Cloud verlagert, jetzt ist Sicherheit deren Aufgabe.” Große Anbieter wie AWS und Azure arbeiten nach dem Prinzip des Shared Responsibility Model:
- Security OF the Cloud (Verantwortung des Anbieters): Physische Sicherheit der Rechenzentren, Hardwareausfälle, die Hypervisor-Schicht, physische Netzwerkverkabelung und die Sicherheit der Infrastruktureinrichtungen.
- Security IN the Cloud (Verantwortung des Kunden): Betriebssystem-Updates auf dem virtuellen Server, IAM-Berechtigungen (Identity and Access Management), Firewall-Regeln, Datenverschlüsselung (im Ruhezustand und bei der Übertragung) sowie die Sicherheit des Anwendungscodes.
7. Infrastructure as Code (IaC) und FinOps#
In der modernen Cloud-Verwaltung ist das manuelle Erstellen von Servern oder Netzwerken per Klick in der Konsole (“ClickOps”) weder nachhaltig noch frei von menschlichen Fehlern.
Infrastructure as Code (IaC)#
Dabei wird die gesamte Infrastruktur (VPC, Subnetze, EC2, Load Balancer usw.) durch Code-Dateien definiert.
- Terraform / OpenTofu: Mit ihrer deklarativen Sprache ermöglichen sie die codebasierte Verwaltung der Infrastruktur über alle Cloud-Anbieter hinweg.
- Vorteile: Versionskontrolle (Nachverfolgung über Git), Wiederholbarkeit (dieselbe Infrastruktur innerhalb von Sekunden in einer Testumgebung aufbauen) und erleichterte Notfallwiederherstellung (Disaster Recovery).
FinOps und Kostenmanagement#
Während die Cloud Flexibilität bietet, kann sie auch zu aus dem Ruder laufenden Budgets führen. FinOps bezeichnet die Zusammenarbeit von Engineering- und Finanzteams zur Kostenoptimierung durch:
- Identifizierung und Entfernung ungenutzter, im Leerlauf befindlicher Ressourcen.
- Nutzung von Reserved Instances (RI) oder Savings Plans für stabile, rund um die Uhr laufende Workloads, wodurch Einsparungen von 60–70 % erzielt werden.
- Nutzung von Spot Instances für temporäre Aufgaben.
8. Fazit und Ausblick#
Cloud Computing hat die Infrastruktur-Entwicklung vollständig von der Abhängigkeit physischer Hardware befreit und die Ära der Software-Defined Infrastructure (SDN & IaC) eingeläutet. Heute wachsen die Rollen Netzwerktechnik, Systemadministration und Softwareentwicklung unter den Disziplinen DevOps, SRE (Site Reliability Engineering) und Cloud Engineering zusammen.
Für einen Ingenieur, der in dieses Feld einsteigen möchte, ist es der entscheidende Schritt, Netzwerkgrundlagen (TCP/IP, Routing, DNS), Virtualisierungs-/Container-Technologien (Docker, Kubernetes) und Infrastructure-as-Code-Tools (Terraform) mit den Cloud-Prinzipien zu verbinden.
Statt bei der Theorie zu bleiben, ist das Anlegen eines kostenlosen Free-Tier-Kontos bei AWS oder Azure – den führenden Anbietern des Marktes – und das Umsetzen praktischer Projekte der schnellste Weg, sich dieses Ökosystem anzueignen.