Amazon SAP-C02: Migration & Modernisierung — Lernleitfaden

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Teil des AWS Solutions Architect Professional SAP-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Migrationsstrategie und -planung

Eine effektive Migration beginnt mit einer disziplinierten Erkundung (Discovery), der Abbildung von Abhängigkeiten (Dependency Mapping) und einer risikobasierten Priorisierung. Verwenden Sie AWS Application Discovery Service und AWS Migration Hub, um Server zu inventarisieren, Leistungsmetriken zu sammeln und Anwendungsabhängigkeiten zu visualisieren. Ergänzen Sie dies durch agentenlose Netzwerkanalyse (Network Flow Analysis) und Konfigurationsmanagement-Daten, um versteckte zustandsbehaftete (stateful) Verbindungen zu finden. Setzen Sie die Ergebnisse der Erkundung in Entscheidungen für die Landing-Zone um: Wählen Sie eine Account-Strategie mit AWS Control Tower und Organizations, definieren Sie die Netzwerktopologie mit Transit Gateway und dimensionieren Sie die Ziel-Rechenleistung (Compute) mithilfe von Compute Optimizer und den Richtlinien zum Right-Sizing. Die Cutover-Strategie sollte pro Anwendung gewählt werden: Big-Bang für kleine Systeme mit geringem Risiko; phasen- oder wellenbasiert für geschäftskritische Suiten; Blue/Green oder Canary für kundenorientierte Dienste, um die Auswirkungen auf die Benutzer zu minimieren. Berücksichtigen Sie bei der Planung des Cutovers Daten-Synchronisationsfenster, DNS-TTLs, Bandbreitenbeschränkungen und regulatorische Anforderungen. Häufige Fallstricke sind die Unterschätzung der Datenübertragungszeit und -kosten, die Behandlung von Lift-and-Shift als Endzustand, die Vernachlässigung der Lizenzportabilität und die fehlende Planung für ein Rollback. Entscheidungskriterien wägen oft Kosten gegen Betriebsaufwand und Ausfallsicherheit ab: Managed Services (RDS/Aurora, DocumentDB) erhöhen die Vorhersehbarkeit der Betriebskosten (OPEX) und die Resilienz, können aber Schemaänderungen erfordern; ein Replatforming auf Managed Offerings reduziert den Betriebsaufwand auf Kosten einer höheren Migrationskomplexität.

Lift-and-Shift und Datenmigrations-Tools

Für ein schnelles Rehosting automatisiert der AWS Application Migration Service (MGN) die Replikation auf Blockebene von VMware, Hyper-V und physischen Servern in EC2. Dies minimiert die Cutover-Zeit und erhält Konfigurationen auf Betriebssystemebene. Die Migration großer Datenmengen oder die Offline-Migration erfordert möglicherweise AWS Snow Family oder DataSync für Dateien und POSIX/NFS-Workloads, während Amazon S3 Transfer Acceleration und Direct Connect die Übertragung von Objekten und Massendaten beschleunigen. Die Datenbankmigration stützt sich auf den AWS Database Migration Service (DMS) für homogene oder heterogene Migrationen, kombiniert mit dem Schema Conversion Tool (SCT), wenn strukturelle Änderungen erforderlich sind. Beachten Sie die Einschränkungen von DMS: Das Verhalten von MongoDB als Quelle/Ziel hat Versions- und Funktionsbeschränkungen, es gibt Besonderheiten beim Umgang mit großen LOBs und potenziellen Replikations-Lag während der CDC (Change Data Capture). Architekturen müssen auf Datenintegrität ausgelegt sein: Validieren Sie mit Prüfsummen, führen Sie einen Full Load plus CDC für minimale Ausfallzeiten durch und planen Sie den Cutover in verkehrsarmen Zeitfenstern. Design-Entscheidungen drehen sich um den Kompromiss zwischen Geschwindigkeit und Genauigkeit (Fidelity): MGN oder Rehosting minimiert Anwendungsänderungen, führt aber alte Betriebsmodelle fort; Replatforming reduziert den langfristigen Betriebsaufwand, erfordert aber Refactoring und Tests. Häufige Fallstricke sind die Vernachlässigung der Endpunktsicherheit, eine unzureichende Validierung vor dem Cutover und die Annahme identischer IOPS/Durchsatzraten im Cloud-Speicher.

Modernisierung: Container, Serverless und Muster für das Refactoring

Modernisierungsoptionen reichen vom Replatforming in eine Container-Orchestrierung bis zum vollständigen Refactoring in eine Serverless-Architektur. Wählen Sie Amazon ECS on Fargate für schnelle containerisierte Deployments mit minimalem Infrastrukturmanagement oder Amazon EKS für Kubernetes-native Workloads, die Portabilität und komplexe Orchestrierung erfordern. Für ereignisgesteuerte Microservices kombinieren Sie AWS Lambda mit API Gateway, EventBridge und Step Functions, um den Betriebsaufwand zu reduzieren und pro Anfrage zu skalieren. Datendienste sollten auf Managed Backends umgestellt werden: Amazon RDS/Aurora für relationale Datenbanken, Amazon DynamoDB oder Amazon DocumentDB für NoSQL/Dokumentenspeicher und ElastiCache für Caching mit geringer Latenz. Die Kompromisse hängen von der Betriebskomplexität im Vergleich zu Kosten und Leistungsvorhersehbarkeit ab: EKS bietet Kontrolle und Portabilität bei höheren Betriebskosten; Fargate vereinfacht den Betrieb, kann aber bei Skalierung teurer sein. Serverless bietet Kosteneffizienz für Workloads mit Lastspitzen (spiky workloads), bringt aber Kaltstarts (Cold Starts), Gleichzeitigkeitslimits (Concurrency Limits) und Herausforderungen bei der Beobachtbarkeit (Observability) mit sich. Häufige Architektur-Fallstricke sind das Verschieben von Monolithen in Container ohne die Dekomposition zustandsbehafteter Komponenten, unzureichende CI/CD und IaC (CloudFormation, CDK, Terraform) zur Verwaltung von Deployments und die Missachtung des Prinzips der geringsten Rechte (Least Privilege) bei IAM für Task Roles und Lambda Execution Roles.

Cutover, hybrides Networking und Betrieb nach der Migration

Ein erfolgreicher Cutover hängt von hybrider Netzwerkkonnektivität und Identitätsintegration sowie von robusten Plänen für Beobachtbarkeit und Rollback ab. Für die hybride DNS-Auflösung zwischen VPCs und einem on-premises Active Directory implementieren Sie Inbound- und Outbound-Endpunkte von Amazon Route 53 Resolver oder verwenden Sie AD Connector/Managed Microsoft AD für den Domänenbeitritt von EC2-Windows-Instanzen. Zu den Optionen für die Netzwerkkonnektivität gehören AWS Direct Connect und Transit Gateway für skalierbare Multi-Account-Topologien. Wählen Sie Direct Connect, wenn vorhersagbare Bandbreite und niedrigere Egress-Kosten wichtig sind, und Transit Gateway, um die Many-to-Many-Konnektivität zwischen VPCs und on-premises zu vereinfachen. Der Betrieb nach der Migration muss das Monitoring (CloudWatch, X-Ray), die zentralisierte Protokollierung und Analyse (CloudWatch Logs, Kinesis Firehose in ein zentrales Konto), Backup- und Cross-Region-Snapshot-Strategien (AWS Backup, Cross-Region Snapshot Copy) sowie Sicherheits-Baselines umfassen, die über AWS Config und IAM Boundary Policies durchgesetzt werden. Häufige Fehler sind das Versäumnis, die DNS-TTLs vor dem Cutover zu senken, das unzureichende Testen der AD-Integration unter Last und die Unterprovisionierung der Transit-Gateway-Bandbreite oder fehlende Konfigurationen für die Routenweitergabe. Entscheidungskriterien sind hier Resilienz gegenüber Kosten: Aktiv-Aktiv-Multi-Region-Designs erhöhen die Verfügbarkeit, vervielfachen aber die Replikationskosten und die Komplexität; Aktiv-Passiv vereinfacht die Kosten, verlängert aber die RTO.

Praktisches Problem: Anwendungsszenario

Szenario: Acme Energy, ein globales Forschungsunternehmen, verfügt über eine bestehende AWS-Umgebung mit mehreren Konten unter AWS Organizations und ein on-premises Rechenzentrum, das über eine private Direct-Connect-Verbindung angebunden ist. Sie müssen eine Reihe von Linux-Simulationsservern, ein MongoDB Replica Set und nächtliche Image-Dateifreigaben mit minimaler Unterbrechung zu AWS migrieren.

Herausforderung: Reduzierung des Betriebsaufwands und Ermöglichung elastischer Skalierung bei gleichzeitiger Gewährleistung von nicht mehr als zwei Stunden Ausfallzeit beim Cutover für die Simulationen und null Datenverlust für das MongoDB Replica Set und die nächtliche Aufnahme der Images.

Empfohlener Ansatz:

Implementieren Sie Agenten des AWS Application Migration Service (MGN), um Simulationsserver in ein dediziertes Migrationskonto zu replizieren. Konfigurieren Sie die kontinuierliche Replikation auf Blockebene mit einem niedrigen RPO und planen Sie eine gestaffelte Cutover-Welle, beginnend mit unkritischen Knoten.
Verwenden Sie AWS DMS mit MongoDB als Quelle und Amazon DocumentDB (mit MongoDB-Kompatibilität) als Ziel. Führen Sie einen Full Load plus CDC durch und validieren Sie die Konsistenz auf Dokumentenebene mithilfe von Prüfsummen und parallelen Lesereplikaten zur Verifizierung.
Migrieren Sie nächtliche Images mit AWS DataSync in einen Amazon S3 Bucket, der durch S3 Lifecycle-Regeln unterstützt wird. Stellen Sie Amazon FSx for Lustre oder Amazon EFS für POSIX-basierte Workloads bereit, die NFS-Semantik erfordern, und testen Sie die Lese-/Schreibleistung unter Spitzenlast.
Orchestrieren Sie den Cutover mit gesenkten Route 53 TTLs, Route 53 Weighted Routing für einen Blue/Green-Traffic-Shift und schließen Sie den DNS-Swap nach erfolgreichen Smoke-Tests ab. Erzwingen Sie die Verwendung von IAM-Rollen und aktivieren Sie CloudWatch X-Ray, zentralisierte CloudWatch Logs und AWS Backup für Snapshots.

Begründung: Dieser Ansatz minimiert die Ausfallzeit durch gestaffelte Replikation und CDC, reduziert den Betriebsaufwand durch die Nutzung von Managed Services (DocumentDB, S3, DataSync) und bietet sichere Rollback-Punkte sowie Beobachtbarkeit, um die Korrektheit vor dem endgültigen Cutover zu validieren. Dies entspricht den professionellen Best Practices für die Architektur bei Migration und Modernisierung.

← Datenbanken · Alle Domänen · Resilienz →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →