Cloud-Migration von VMware zu AWS: Herausforderungen meistern, Kosten senken, Strategien vergleichen. Praxisguide für Unternehmen.
Warum Unternehmen VMware-Umgebungen zu AWS migrieren
Die Rechenzentrumswelt von 2015 sieht anders aus als 2024. Viele Unternehmen sitzen auf VMware-Infrastrukturen, die vor fünf, acht oder zehn Jahren gekauft wurden — mit Verträgen, die bei laufender Verlängerung teurer werden statt günstiger. VMware-Preise sind zwischen 2020 und 2024 um geschätzte 30–50 % gestiegen, vor allem durch die Übernahme durch Broadcom. Parallel dazu forcieren CTOs und CFOs Cloud-first-Strategien, um CapEx in OpEx umzuwandeln und die Skalierbarkeit der Infrastruktur zu verbessern.
Die典型ische Ausgangslage sieht so aus: Ein mittelständisches Unternehmen betreibt zwei VMware-vSphere-Cluster mit insgesamt 80 Hosts, primär für ERP-Systeme, Datenbanken und Web-Anwendungen. Die jährlichen Kosten für Hardwarewartung, Lizenzen und Rechenzentrumsfläche liegen bei 2,3 Millionen Euro. AWS-Rechenkapazität für dieselbe Workload kostet — mit Reserved Instances und SAVINGS PLANS — etwa 1,4 Millionen Euro jährlich. Die Differenz finanziert zwei bis drei Cloud-Architekten.
Doch der Weg dorthin ist kein Selbstläufer.
Die fünf größten Herausforderungen bei der VMware-zu-AWS-Migration
1. Netzwerk- und Konnektivitätskomplexität
VMware-Umgebungen leben von lokalen Netzwerken: VLANs, Subnetze, Firewalls und Load Balancer sind hart verdrahtet. In AWS existieren diese Konzepte als VPCs, Security Groups, NACLs und Application Load Balancer — semantisch ähnlich, syntaktisch völlig anders.
Ein konkretes Beispiel: Eine dreistellige Anzahl an VMs mit festen IP-Adressen, die in Applikations-Stacks miteinander kommunizieren. In AWS müssen Sie für jede VM eine Elastic Network Interface (ENI) mit privater IP konfigurieren, Security Groups für ein- und ausgehenden Traffic definieren und Routing-Tabellen pflegen. Bei 200 VMs sind das 200×Konfigurationspunkte — plus das Networking zwischen den VMs, das in VMware über vSwitch und Distributed Switches läuft, in AWS aber über Transit Gateway oder VPC Peering abgebildet werden muss.
Lösung: Nutzen Sie AWS Direct Connect für eine stabile, dedizierte Verbindung zum Rechenzentrum. Für die Übergangsphase eignet sich AWS Site-to-Site VPN. Strukturieren Sie die VPC-Architektur vor der Migration mit Terraform oder AWS CloudFormation — nicht ad hoc im Console.
2. Storage-Migration und Latenzanforderungen
VMware-Umgebungen nutzen typischerweise SAN-Storage (iSCSI, NFS, FC) mit SSD-Tiers für produktive Workloads. In AWS entspricht dem:
- Amazon EBS für block storage (gp3, io2, st1, sc1)
- Amazon EFS für dateibasierten Storage
- Amazon S3 als Objekt-Storage mit Lifecycle-Policies
Der kritische Punkt: EBS-Volumes haben eine Latenz von 1–3 ms, vergleichbar mit lokalem SSD. Bei gp3-Volumes erreichen Sie 3.000 IOPS und 125 MB/s Throughput out-of-the-box. io2-Block-Express-Volumes liefern bis zu 256.000 IOPS bei 99,999 % SLA — ausreichend für selbst anspruchsvolle Datenbank-Workloads.
Die Herausforderung liegt im Transfer: 50 TB an VM-Daten per VPN hochzuladen dauert bei 1-Gbps-Anbindung etwa 5–6 Tage. Schneller geht es mit AWS Snowball Edge (bis 100 TB pro Gerät) oder durch eine direkte Direct-Connect-Verbindung mit 10 Gbps.
Empfehlung: Starten Sie mit nicht-produktiven Workloads und synchronisieren Sie den Storage vor dem Cutover mit AWS Storage Gateway oder rsync/Database Replication.
3. Lizenzierung und Kostenmanagement
Hier wird es für viele Unternehmen unangenehm. VMware-Lizenzen sind an Hardware gebunden oder erfordern eigene Subscriptions. Bei der Migration zu AWS fallen diese Lizenzen weg — aber dafür entstehen AWS-Kosten, die ohne Kontrolle explodieren können.
Ein praktisches Rechenbeispiel: Eine Oracle-Datenbank auf VMware mit 64 vCPUs und 512 GB RAM läuft auf einem r5.16xlarge in AWS (64 vCPUs, 512 GB RAM) für etwa 4.800 USD/Monat bei On-Demand-Preis. Mit einem 1-Jahres Reserved Instance mit partieller Vorabzahlung sinkt der Preis auf 3.200 USD/Monat — eine Ersparnis von 33 %.
Für SQL Server-Workloads bietet AWS License Mobility through SA (Software Assurance) für viele Microsoft-Lizenzen. Für Oracle gibt es Oracle Database Cloud at Customer und AWS Partner Solutions. Prüfen Sie Ihre bestehenden Verträge — manche beinhalten bereits Cloud-Mobilitätsrechte.
4. Application-Kompatibilität und Abhängigkeiten
Nicht jede Anwendung läuft reibungslos in der Cloud. Alte Java-Versionen, 32-Bit-Applikationen, hardcodierte IP-Adressen, Lizenzserver mit Hardware-Dongles, Load Balancer mit Persistence-Anforderungen — all das sind Stolperfallen.
In einer typischen VMware-Migration treffe ich bei 30 % der Anwendungen auf Kompatibilitätsprobleme, die vorab behoben werden müssen. Bei 15 % sind fundamentale Architekturänderungen nötig.
Lösung: Führen Sie eine Application Dependency Mapping durch, bevor Sie migrieren. Tools wie AWS Application Discovery Service erfassen automatisch Konfigurationen und Abhängigkeiten. Ergänzend bieten sich Dritten-Tools wie CloudPhysics oder RVTools an.
5. Skill Gap und Change Management
Ihr VMware-Team kennt vSphere, vSAN, NSX und vROPs. AWS nutzt EC2, VPC, EBS, CloudWatch und Systems Manager. Die Konzepte übertragen sich teilweise, aber die tägliche Arbeit sieht anders aus.
Ein vSphere-Administrator, der einen neuen Cluster provisioniert, klickt im vSphere Client und folgt einem Wizard. In AWS navigiert er durch die EC2-Konsole, wählt Instance-Typen, konfiguriert Auto-Scaling Groups und setzt Launch Templates auf — oder er automatisiert alles via Terraform.
Migrationsstrategien im Vergleich
Lift-and-Shift (Re-Hosting)
Der schnellste Weg: VMs werden 1:1 nach AWS verschoben, ohne Code-Änderungen. Tools wie AWS Server Migration Service (SMS) oder VMware Cloud on AWS ermöglichen inkrementelle Replikation.
Vorteile:
- Schnellste Time-to-Cloud (Wochen statt Monate)
- Geringstes Risiko für die Applikationen
- Niedrigste initiale Migrationskosten
Nachteile:
- Keine Cloud-nativen Optimierungen
- Potenzielle Überdimensionierung der Instanzen
- Langfristig höhere Betriebskosten
Geeignet für: Legacy-Anwendungen, die vor der Abschaltung stehen; Workloads, die nur temporär in der Cloud laufen; als erster Schritt vor Refactoring.
Lift, Tinker, and Shift (Re-Platforming)
Eine Stufe weiter: Sie verschieben die VMs, optimieren aber Storage und Datenbanken. Statt lokalem MySQL auf einer VM nutzen Sie Amazon RDS for MySQL mit automatischen Backups und Multi-AZ-Failover.
Vorteile:
- Reduzierung des operativen Overheads
- Bessere Skalierbarkeit und Verfügbarkeit
- Moderate Kostenoptimierung
Nachteile:
- Etwas längere Migrationsdauer
- Anpassung der Backup- und Monitoring-Strategien nötig
Geeignet für: Standard-Applikationen mit relationalen Datenbanken, die von Managed Services profitieren.
Refactoring (Neuarchitectur)
DieCloud-nativ-Option: Statt VMs zu verschieben, modernisieren Sie die Anwendung für AWS. Containerisieren Sie mit Amazon ECS oder EKS, nutzen Sie Lambda für serverlose Functions, ersetzen Sie den Application Server durch AWS Elastic Beanstalk.
Vorteile:
- Maximale Kosteneffizienz (Pay-per-use)
- Beste Skalierbarkeit und Performance
- Langfristig lowest TCO
Nachteile:
- Höchster initialer Aufwand
- Risiko bei komplexen Legacy-Systemen
- Monatelange Projekte
Geeignet für: Strategische Anwendungen mit langer Lebensdauer; Applikationen, die von Microservices-Architektur profitieren.
Hybridansatz mit VMware Cloud on AWS
Eine Sonderstellung nimmt VMware Cloud on AWS ein — ein von VMware betriebener SDDC-Stack auf AWS-Infrastruktur. Sie betreiben weiterhin VMware vSphere, nutzen aber AWS-native Services für Storage (vSAN mit S3-Backend), Networking (VMware NSX) und Compute (AWS Nitro-basiert).
Ideale Szenarien:
- Migrationsprojekte mit langen Übergangsfristen
- Unternehmen mit starken VMware-Teams und Investitionen in bestehende Tools
- Workloads, die zertifizierte VMware-Kompatibilität erfordern (z.B. bestimmte SAP-Systeme)
Schritt-für-Schritt-Migrationsplan
Bestandsaufnahme und Klassifizierung
- Nutzen Sie AWS Application Discovery Service und RVTools
- Klassifizieren Sie Workloads nach Kritikalität, Komplexität und Cloud-Reife
- Erstellen Sie ein Application Dependency Map
Landing Zone und Netzwerk designen
- Richten Sie eine AWS Landing Zone mit Control Tower ein
- Definieren Sie VPC-Struktur (Hub-Spoke, Transit Gateway)
- Planen Sie IP-Adressräume und Routing-Policies
Konnektivität sicherstellen
- Implementieren Sie Direct Connect oder Site-to-Site VPN
- Testen Sie Latenz und Bandbreite
- Richten Sie DNS (Route 53, Private Hosted Zones) ein
Migrationsstrategie pro Workload definieren
- Re-Hosting für 60 % der Workloads (schnell, wenig Aufwand)
- Re-Platforming für 30 % der Workloads (optimiert, moderater Aufwand)
- Refactoring für 10 % der Workloads (strategisch, hoher Aufwand)
Testumgebung aufbauen
- Migrieren Sie Nicht-Produktiv-Instanzen zuerst
- Führen Sie Integrationstests durch
- Validieren Sie Performance mit realistischen Workloads
Go-Live und Cutover
- Planen Sie Wartungsfenster
- Führen Sie inkrementelle Datenreplikation durch
- Implementieren Sie Rollback-Szenarien
Optimierung post-Migration
- Right-Sizing der EC2-Instanzen (nutzen Sie AWS Compute Optimizer)
- Reserve Instances oder Savings Plans kaufen
- Implementieren Sie Cost Allocation Tags
Kostenfallen und wie Sie sie vermeiden
Öffentliche IP-Adressen: Jede ausgehende GB Daten kostet Geld. NAT Gateways berechnen 0,045 USD pro GB verarbeitete Daten. Bei 100 TB monatlich sind das 4.500 USD nur für NAT.
Cross-AZ-Traffic: Datenverkehr zwischen Availability Zones kostet 0,01 USD pro GB. Designen Sie Ihre Architektur so, dass dieser Traffic minimiert wird — oder nutzen Sie Transit Gateway mit sparsam konfigurierten Attachment-Gebühren.
EBS-Snapshots: Wer alte Snapshots nicht löscht, zahlt für ungenutzten Storage. Implementieren Sie Lifecycle Manager Policies.
Overprovisionierte Instanzen: r5.xlarge statt r5.large — der Faktor 4 bei Kosten bei minimaler Nutzung. Nutzen Sie CloudWatch Metrics, um Utilization zu tracken. Ziel: Durchschnittliche CPU-Auslastung über 40 %.
Sicherheit und Compliance in der AWS-Umgebung
Bei der Migration müssen Sie nicht nur technische, sondern auch regulatorische Anforderungen erfüllen. AWS bietet über 140 compliance-zertifizierte Dienste und ist für branchenübergreifende Standards zertifiziert:
- ISO 27001, 27017, 27018 für Informationssicherheit
- SOC 1, 2, 3 für Prüfberichte
- GDPR-konforme Datenverarbeitung in EU-West-1 (Irland) oder EU-Central-1 (Frankfurt)
Konkrete Sicherheitsmaßnahmen:
- Nutzen Sie AWS Identity and Access Management (IAM) statt Root-Konten
- Aktivieren Sie Multi-Faktor-Authentifizierung für alle administrativen Zugriffe
- Implementieren Sie Security Groups als Firewall auf Instanzebene
- Verschlüsseln Sie EBS-Volumes at-rest mit KMS (AWS Key Management Service)
- Aktivieren Sie VPC Flow Logs für Netzwerktraffic-Analyse
- Nutzen Sie AWS Config für kontinuierliche Compliance-Prüfung
Fazit: Der Weg zur Cloud ist kein Sprint
Die Migration von VMware zu AWS ist ein Projekt, das bei mittelständischen Unternehmen typischerweise 12–24 Monate dauert — bei Großunternehmen auch länger. Die technischen Herausforderungen sind lösbar; die organisatorischen oft schwieriger.
Meine Empfehlung aus über 50 Migrationsprojekten: Starten Sie nicht mit dem größten und kritischsten Workload. Beginnen Sie mit einer Anwendung, die repräsentativ ist, aber nicht geschäftskritisch. Lernen Sie die AWS-Tools, verstehen Sie die-costs, bauen Sie die Prozesse auf — und масштабируйте Sie dann.
Die Unternehmen, die bei der VMware-zu-AWS-Migration scheitern, tun das selten an technischen Problemen. Sie scheitern an überhöhten Erwartungen, unzureichender Planung und fehlendem Change Management. Wer die Herausforderungen kennt und adressiert, wird mit einer flexibleren, skalierbareren und kostengünstigeren Infrastruktur belohnt.
Wöchentliche Cloud-Insights — kostenlos
Praktische Leitfäden zu Cloud-Kosten, Sicherheit und Strategie. Kein Spam.
Comments