Amazon SAA-C03: Datentransfer & Migration — Lernleitfaden

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Teil des AWS SAA-C03 — Vollständiger Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Die Entscheidung: Bandbreite vs. Versand

Jede Migration beginnt mit einer einfachen Rechnung. Berechnen Sie die theoretische Übertragungszeit, bevor Sie ein Tool auswählen:

Transfer days = (Dataset size in bits) / (Usable bandwidth in bps × 86,400)
Usable bandwidth = Link speed × Allowed utilization %

Die Zahlen sind unerbittlich. Bei konstanten 100 Mbit/s dauert die Übertragung von 1 TB etwa 24 Stunden; bei 1 Gbit/s sind es etwa 2,5 Stunden. Eine 15-Mbit/s-Verbindung mit einer Auslastung von 70 % liefert nur ca. 113 GB pro Tag, sodass 20 TB mehr als 175 Tage benötigen würden. Die Übertragung von 150 TB über Nacht (10 Stunden bei 80 % von 100 Mbit/s) ergibt ca. 360 GB pro Nacht oder 10,5 TB pro Monat – bei Weitem nicht ausreichend für eine 30-Tage-Frist. Selbst bei voller Auslastung rund um die Uhr verschiebt eine 100-Mbit/s-Leitung nur ca. 1 TB/Tag, sodass 150 TB mindestens 150 Tage benötigen. Im Petabyte-Bereich verschlechtert sich das Bild: Eine 500-Mbit/s-Verbindung mit realer Effizienz liefert einen theoretischen Durchsatz von etwa 5,4 TB/Tag, was bedeutet, dass 10 PB mehr als fünf Jahre ununterbrochener Übertragung erfordern würden – länger, als die Bereitstellung der meisten Direct Connect-Leitungen dauert.

Eine vernünftige Faustregel:

Die häufigste falsche Antwort in Migrationsszenarien ist die Wahl einer WAN-Übertragung, die mathematisch unmöglich innerhalb des Zeitfensters abgeschlossen werden kann. Die damit verbundene Falle – „wir lassen es einfach jede Nacht über das WAN laufen“ – ist nicht nur langsamer. Sie verbraucht Produktionsbandbreite, birgt das Risiko teilweiser oder beschädigter Übertragungen, die erneute Uploads erfordern, und ist in der Regel teurer, wenn man die Bandbreitenkosten und den Engineering-Aufwand mit einrechnet. Die Gebühr für eine Snowball-Einheit zuzüglich Versand ist ein fester, vorhersehbarer Posten.

Die Snow-Familie für den Offline-Massentransfer

Snowball Edge-Geräte gibt es in zwei Varianten:

Snowcone ist der kleine Formfaktor (~8 TB SSD), robust und per Kurier versandfertig, nützlich für Standorte mit begrenztem Platz und vorinstalliert mit DataSync-Agenten für die Edge-Synchronisierung. Snowmobile – ein 45-Fuß-Container, der bis zu 100 PB transportieren kann – war für die Evakuierung von Rechenzentren im Exabyte-Bereich gedacht, wurde aber in den meisten Regionen zugunsten paralleler Flotten von Snowball Edge-Geräten abgekündigt. Die Wahl von Snowmobile für Datenmengen unter einem Petabyte ist eine Ablenkungsoption.

Die Compute-Variante ist nicht nur ein größeres Laufwerk. Sie führt EC2 AMIs, Lambda-Funktionen und Greengrass-Workloads lokal aus und ist damit die richtige Wahl, wenn Daten vor der Aufnahme transformiert, gefiltert oder personenbezogene Daten (PII) unkenntlich gemacht werden müssen, wenn ein Workload nach der Aufnahme sofort in AWS wiederaufgenommen werden muss oder wenn der Standort keine oder nur eine unterbrochene Verbindung hat (Schiffe, entlegene Minen, taktische Einsätze, Fernforschung). Wählen Sie Compute Optimized, wenn eine Verarbeitung auf dem Gerät erforderlich ist; wählen Sie Storage Optimized, wenn es sich um eine reine Massenkopie handelt.

Jedes Snow-Gerät führt eine 256-Bit-Verschlüsselung im Ruhezustand (at rest) mit KMS-Schlüsseln durch, die AWS niemals verlassen. Die Gehäuse sind manipulationssicher und verfügen über ein E-Ink-Versandetikett sowie ein Hardware Trusted Platform Module. Daten werden auf dem Gerät mit dem Snowball-Client, dem S3-kompatiblen Endpunkt oder einer NFS-Freigabe geschrieben; TLS schützt die Daten während der Übertragung (in transit) bei der Aufnahme und dem Austausch des Versandmanifests. Nach der Rücksendung werden die Inhalte in S3 aufgenommen und das Gerät wird gemäß NIST 800-88 kryptografisch gelöscht.

Für Arbeiten im Petabyte-Bereich pro Standort ist Parallelisierung das gängige Muster. Ein Büro mit einer Verbindungskapazität von 1–2 Gbit/s würde immer noch Monate ununterbrochener Auslastung benötigen, um 1 PB online zu verschieben; eine Flotte von ca. 13 Storage Optimized-Geräten pro Standort (jeweils 80 TB), die parallel versandt werden, hält eine Vier-Wochen-Frist ein und schont gleichzeitig die Internetverbindung des Büros. Für einen Auftrag von 600 TB innerhalb von zwei Wochen über eine ausgelastete 100-Mbit/s-Leitung ist eine kleine parallele Flotte die einzig richtige Antwort – selbst wenn man die Kosten außer Acht lässt, machen die physikalischen Gegebenheiten den Einsatz von DataSync oder einer neuen Direct Connect-Verbindung unmöglich.

DataSync für Online-, verifizierte, inkrementelle Übertragung

DataSync ist das richtige Werkzeug, wenn die Bandbreite ausreicht, aber die Eigenschaften der Workload – Millionen kleiner Dateien, tiefe Verzeichnisstrukturen, laufende inkrementelle Synchronisierungen oder dateisystemübergreifende Migrationen – naive Werkzeuge überfordern würden. Ein Verzeichnis mit 20 Millionen 4-KB-Dateien, das mit aws s3 cp kopiert wird, wird durch die Round-Trip-Latenz und nicht durch den Durchsatz ausgebremst; jeder PutObject verursacht einen TLS/HTTP-Roundtrip und eine Gebühr für die API-Anfrage. Das Bündeln in Archiven funktioniert, aber man verliert die Adressierbarkeit auf Dateiebene. Der Agent von DataSync parallelisiert über viele TCP-Streams, verarbeitet Metadaten nativ, prüft jede Datei End-to-End mit SHA-256-Prüfsummen, führt Wiederholungsversuche transparent durch und meldet an CloudWatch – und erreicht dabei bis zu ~10 Gbit/s pro Agent mit vorhersagbaren Preisen pro GB.

Quellen und Ziele umfassen NFS, SMB, HDFS, selbstverwaltete Objektspeicher, S3, EFS, FSx for Windows File Server, FSx for Lustre, FSx for OpenZFS und FSx for NetApp ONTAP. Die Übertragungen verwenden TLS 1.2 In-Transit und können über VPC-Interface-Endpunkte laufen, um das öffentliche Internet zu meiden.

Ein entscheidendes Detail: DataSync benötigt einen Agenten für On-Premises-NFS/SMB-Quellen. Der Agent läuft als VM auf VMware, Hyper-V oder KVM, auf EC2 oder auf Snowcone. Zu glauben, DataSync sei für On-Premises agentenlos, ist eine häufige Falle – es ist nur dann agentenlos, wenn beide Endpunkte native AWS-Services sind.

Eine minimale Bereitstellung:

# Activate the on-prem agent
aws datasync create-agent \
  --activation-key ABCDE-12345-FGHIJ-67890-KLMNO \
  --agent-name onprem-nfs-agent \
  --vpc-endpoint-id vpce-0a1b2c3d

# Define source (NFS) and destination (S3)
aws datasync create-location-nfs \
  --server-hostname 10.0.5.20 \
  --subdirectory /export/video \
  --on-prem-config AgentArns=arn:aws:datasync:...:agent/agent-0abc

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::video-archive \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Role

# Task with bandwidth cap, verification, and a nightly schedule
aws datasync create-task \
  --source-location-arn <nfs-arn> \
  --destination-location-arn <s3-arn> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,BytesPerSecond=104857600,PreserveDeletedFiles=PRESERVE,PosixPermissions=PRESERVE \
  --schedule ScheduleExpression="cron(0 2 * * ? *)"

Zwei operative Merkmale sind wichtig. Bandbreitendrosselung (BytesPerSecond) verhindert die Sättigung einer gemeinsam genutzten Verbindung – eine direkte Antwort auf Muster wie „1-Gbit/s-Leitung, die mit anderen Abteilungen geteilt wird“. Filterung und Zeitplanung ermöglichen Synchronisierungen außerhalb der Geschäftszeiten und den Ausschluss von temporären Dateien. Über eine 10-Gbit/s-Direct-Connect-Verbindung, bei der Benutzer weiterhin lesen und schreiben, ist die Planung wiederholter Aufgaben das kanonische Muster: Der erste Durchlauf überträgt den Großteil der Daten, nachfolgende inkrementelle Läufe erfassen die Deltas, und 700 TB sind selbst bei teilweiser Auslastung in deutlich weniger als einer Woche erreichbar.

Eine subtilere Falle betrifft die Metadatentreue. DataSync bewahrt einen kuratierten Satz von POSIX- oder SMB-Attributen – UID/GID/Modus/Zeitstempel für NFS, Besitzrechte und DACLs für SMB – erfasst aber nicht jedes proprietäre NAS-Attribut. Herstellerspezifische ACLs, erweiterte Attribute, die über das hinausgehen, was das Protokoll bereitstellt, Snapshots und Deduplizierungs-Metadaten fallen nicht in seinen Zuständigkeitsbereich. Wenn die Compliance eine exakte NAS-Replik einschließlich der Herstellerfunktionen erfordert, ist DataSync allein nicht ausreichend; ein NetApp-fähiger Pfad wie FSx for ONTAP mit SnapMirror oder ein Lift-and-Shift über Storage Gateway ist erforderlich.

DataSync ergänzt auch Snowball: Snowball verschiebt die anfänglichen 150 TB, und DataSync kümmert sich danach um das laufende wöchentliche Delta eines 500-GB-Arbeitsdatensatzes.

Storage Gateway: Hybride Präsentation, nicht Migration

Storage Gateway ist kein Migrationstool – es ist eine hybride Präsentationsschicht. On-Premises-Anwendungen kommunizieren weiterhin über NFS, SMB, iSCSI oder iSCSI-VTL, während die Daten in S3, S3 Glacier oder EBS-Snapshots landen. Storage Gateway mit DataSync zu verwechseln ist ein häufiger Fehler: File Gateway ist nicht dafür ausgelegt, 70 TB in Eile zu verschieben, und DataSync stellt On-Premises-Clients keine persistente Freigabe zur Verfügung.

File Gateway ist das Arbeitspferd. Das Schreiben von \\gateway\share\reports\2024\report.pdf erzeugt s3://bucket/reports/2024/report.pdf – nativ nutzbar von Athena, Lambda, EMR oder jedem S3-Client. Diese Eins-zu-eins-Zuordnung von Datei zu Objekt ist ein großer Vorteil gegenüber Black-Box-Backup-Zielen. Lokales Caching bedeutet, dass „heiße“ Dateien mit LAN-Geschwindigkeit zurückgegeben werden; „kalte“ Dateien werden bei Bedarf aus S3 gestreamt.

Der Cache ist der springende Punkt der Appliance. Lesezugriffe auf „heiße“ Daten werden lokal bedient; Schreibvorgänge landen zuerst auf der lokalen Festplatte und werden asynchron hochgeladen. Ein häufiger Designfehler ist die Annahme, dass S3-gestützt bedeutet, dass jeder Lesezugriff eine Internet-Round-Trip-Latenz verursacht – das ist nicht der Fall, vorausgesetzt, der Arbeitsdatensatz passt in den Cache. Umgekehrt führt eine Unterdimensionierung des Caches zu ständigen Cache-Misses und die Workload erscheint „langsam“. Faustregel: Cache = 20 % des gesamten Datensatzes oder 100 % des „heißen“ Arbeitsdatensatzes, je nachdem, welcher Wert größer ist.

Die Cached-vs-Stored-Falle verdient besondere Aufmerksamkeit. Der Cached-Modus behält die primäre Kopie in S3, während „heiße“ Blöcke lokal gehalten werden – günstig, elastisch, aber ein Cache-Miss ist ein WAN-Roundtrip. Der Stored-Modus behält die primäre Kopie auf der lokalen Festplatte mit asynchronen Snapshots zu S3 als EBS-Snapshots – jeder Lesezugriff ist lokal und mit geringer Latenz, aber der gesamte Datensatz muss On-Premises Platz finden. Für die Anforderung eines Backup-Ersatzes „lokaler Zugriff auf alle Daten, während sie auf AWS gesichert werden“ ist der Stored-Modus korrekt; der Cached-Modus würde diese Anforderung verletzen. Den Cached-Modus für eine Workload zu wählen, die den gesamten Datensatz mit geringer Latenz benötigt, widerspricht dem Design; den Stored-Modus zu wählen, wenn der Standort nicht den vollständigen Datensatz hosten kann, ist per Definition unmöglich.

Tape Gateway beantwortet eine sehr spezifische Anforderung: die Außerbetriebnahme einer physischen Bandbibliothek, während die Workflows von Veeam, NetBackup oder Commvault intakt bleiben, indem eine VTL über iSCSI bereitgestellt wird, wobei die Daten von S3 zu Glacier oder Deep Archive per Lifecycle-Regel verschoben werden. Es ist von unschätzbarem Wert, wenn regulatorische Aufbewahrungsfristen in Bezug auf Bandmedien definiert sind und die vorhandene Backup-Software nicht geändert werden kann.

AWS Transfer Family

Die Transfer Family bietet vollständig verwaltete SFTP-, FTPS-, FTP- und AS2-Endpunkte, die auf S3 oder EFS basieren. Das Wertversprechen liegt in der Beibehaltung der protokollbasierten Verträge mit Partnern: Anbietersysteme, die Dateien nur über SFTP ausgeben, tun dies unverändert weiter, während die empfangende Seite natives S3 ist – mit Lifecycle-Richtlinien, Lambda-Triggern und Analyse-Integration.

Die Falle hierbei ist die Annahme, dass ein Altanbieter „einfach auf S3-APIs umsteigen“ kann. Viele Anbietersysteme sind Appliances, HL7-Feeds aus Krankenhäusern, Batch-Systeme im Bankwesen oder B2B-EDI-Pipelines, deren SFTP-Client in die Firmware oder signierte Binärdateien integriert ist. Die Kosten für Änderungsmanagement, Sicherheitsüberprüfungen und Neuzertifizierung übersteigen oft die gesamten Kosten der AWS-Migration. Die Transfer Family umgeht dies vollständig. Die AS2-Unterstützung ermöglicht zusätzlich EDI-Workloads mit MDN-Empfangsbestätigungen und Nachrichten-Signierung/-Verschlüsselung für B2B-Compliance.

Die Authentifizierung unterstützt vom Service verwaltete Benutzer, AWS Directory Service (Managed Microsoft AD oder AD Connector für On-Premises-AD) oder einen benutzerdefinierten Identitätsanbieter über API Gateway/Lambda – wodurch bestehende Unternehmensanmeldeinformationen die „Source of Truth“ bleiben können. Ein Lambda-Authorizer kann benutzerspezifische IAM-Rollen, Home-Verzeichnis-Zuweisungen und Sitzungsrichtlinien zurückgeben, was eine anbieterspezifische Isolierung ohne anbieterspezifische Infrastruktur ermöglicht.

Type: AWS::Transfer::Server
Properties:
  Protocols: [SFTP]
  IdentityProviderType: AWS_DIRECTORY_SERVICE
  IdentityProviderDetails:
    DirectoryId: d-9067f4a1c2
  Domain: S3
  EndpointType: VPC
  EndpointDetails:
    VpcId: vpc-0abc123
    SubnetIds: [subnet-0a, subnet-0b]
    SecurityGroupIds: [sg-0sftp]

Amazon AppFlow

AppFlow ist die verwaltete Integrationsschicht für die Datenverschiebung von SaaS zu AWS: Salesforce, ServiceNow, Google Analytics, Slack, Marketo, SAP OData, Zendesk und Dutzende andere, deren Daten in S3, Redshift oder Snowflake fließen. Es übernimmt Paginierung, inkrementelle Extraktion, Feldzuordnung, Filterung, Maskierung und Validierung ohne einen selbst erstellten ETL-Job.

Das sicherheitskritische Merkmal ist die PrivateLink-Integration für unterstützte Konnektoren (insbesondere Salesforce). Anstatt den Datenverkehr über das öffentliche Internet zum SaaS-Mandanten zu leiten und zu AWS zurückzukehren, durchläuft der Flow einen privaten VPC-Endpunkt – wodurch die Offenlegung von Extraktions-Payloads im öffentlichen Internet vermieden und die Audit-Situation für Workloads im Gesundheitswesen, im Finanzsektor und mit personenbezogenen Daten (PII) vereinfacht wird. Flows können zeitgesteuert, ereignisgesteuert durch Änderungen von SaaS-Datensätzen oder bei Bedarf ausgeführt werden und unterstützen bis zu 100 GB pro Flow-Ausführung.

AppFlow arbeitet auf einer höheren Ebene als DataSync oder Storage Gateway: Es ist das richtige Werkzeug, wenn die Quelle eine API-gesteuerte SaaS ist und kein Dateisystem oder keine Datenbank.

Datenbankmigration: DMS und SCT

Der AWS Database Migration Service repliziert Daten zwischen Quell- und Zieldatenbanken, während die Quelle voll funktionsfähig bleibt. Er unterstützt homogene (MySQL → RDS MySQL, Oracle → RDS Oracle) und heterogene (Oracle → Aurora PostgreSQL, SQL Server → MySQL) Migrationen, und die Ziele gehen über RDS hinaus und umfassen Aurora, Redshift, S3, DynamoDB und Kinesis. Zu den Quellen gehören Oracle, SQL Server, MySQL, PostgreSQL, MongoDB und Db2.

Eine Aufgabe (Task) arbeitet in einem von drei Modi:

Der Motor für eine Umstellung mit minimaler Ausfallzeit ist Change Data Capture (CDC). Während eines „Full Load + CDC“ kopiert DMS massenhaft bestehende Zeilen und analysiert gleichzeitig das Transaktionsprotokoll der Quelle – Oracle Redo, MySQL Binlog, SQL Server MS-CDC oder MS-Replication. Sobald das vollständige Laden abgeschlossen ist, wendet CDC die in der Warteschlange befindlichen Änderungen an und hält das Ziel kontinuierlich aktuell, bis die Anwendung umgeschaltet wird. CDC nicht zu aktivieren, wenn die Anwendung beschreibbar bleiben muss, ist ein häufiger Architekturfehler: Ein reines „Full Load“ führt dazu, dass das Ziel in dem Moment veraltet ist, in dem das Laden abgeschlossen ist.

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

Für heterogene Arbeiten übersetzt das AWS Schema Conversion Tool (oder sein Cloud-Pendant DMS Schema Conversion) DDL, Stored Procedures, Views und Funktionen und markiert Elemente, die eine manuelle Überarbeitung erfordern. DMS verschiebt Daten; SCT konvertiert das Schema. Das Überspringen des SCT-Bewertungsberichts ist der Grund, warum Migrationen drei Tage vor der Umstellung scheitern.

Engine-spezifische Voraussetzungen und Einschränkungen können bei Nichtbeachtung schwerwiegende Folgen haben. Oracle LOBs über 64 KB erfordern den limited LOB mode mit einem festen Maximum; LONG RAW hat Vorbehalte (Caveats). PostgreSQL erfordert wal_level=logical und eine Replikationsrolle. MySQL erfordert binäres Logging im ROW-Format mit ausreichendem binlog_row_image und erhöhten CDC-Berechtigungen (REPLICATION CLIENT, REPLICATION SLAVE). Oracle Spatial, RAC-spezifische Verhaltensweisen und SQL Server CLR-Assemblies werden häufig nicht unterstützt. TLS wird zwischen der Replikationsinstanz und den Endpunkten erzwungen, mit den SSL-Modi require, verify-ca oder verify-full.

DMS Serverless ist die richtige Wahl, wenn das Workload-Profil unvorhersehbar oder stoßweise ist – zum Beispiel ein On-Premises-Oracle-System mit Lastspitzen am Tag und ruhigen Nächten. Sie definieren MinCapacityUnits und MaxCapacityUnits in DCUs (DMS Capacity Units), und DMS skaliert die Replikationskapazität basierend auf der CPU- und Speicherauslastung:

ReplicationConfigIdentifier: oracle-to-rds-cdc
ReplicationType: full-load-and-cdc
SourceEndpointArn: arn:aws:dms:...:endpoint:oracle-onprem
TargetEndpointArn:  arn:aws:dms:...:endpoint:rds-oracle
ComputeConfig:
  MinCapacityUnits: 4
  MaxCapacityUnits: 64
  MultiAZ: true

Eine häufige Falle ist die Annahme, dass eine provisionierte DMS-Instanz (z. B. dms.c5.4xlarge) automatisch skaliert. Das tut sie nicht – provisionierte Instanzen sind EC2-Hosts mit fester Größe. Wenn der Durchsatz die Kapazität übersteigt, wächst die Replikationsverzögerung (Lag), und Sie müssen die Instanzklasse manuell ändern und die Tasks neu starten. Provisioniertes DMS eignet sich für Migrationen mit gleichbleibendem, bekanntem Durchsatz; Serverless eignet sich für unvorhersehbare.

Für eine 20-TB-MySQL-Migration mit einem zweiwöchigen Zeitfenster und geringer Ausfallzeit ist DMS mit „Full Load plus CDC“ nach Aurora MySQL oder RDS MySQL die kostengünstigste Variante. Native Wiederherstellungen mit mysqldump/mysqlpump verursachen inakzeptable Ausfallzeiten; Snowball fügt Versandlatenz und Offline-Lücken hinzu.

DMS Fleet Advisor erkennt On-Premises-Datenbankbestände, was für die Wellenplanung (Wave Planning) nützlich ist.

Servermigration: AWS Application Migration Service (MGN)

AWS Application Migration Service ist der primäre Dienst für Lift-and-Shift („Rehosting“) und hat CloudEndure Migration sowie Server Migration Service für die meisten Anwendungsfälle abgelöst. MGN installiert einen schlanken AWS Replication Agent auf jedem Quellserver (physisch, VMware, Hyper-V oder eine andere Cloud). Der Agent führt einen initialen Snapshot auf Blockebene in einen kostengünstigen Staging-Bereich in der Ziel-VPC durch – kleine T3-Instanzen mit angehängten EBS-Volumes – und repliziert dann kontinuierlich Änderungen auf Blockebene asynchron. Da die Replikation auf Blockebene und kontinuierlich erfolgt, dauert ein Cutover nur wenige Minuten: MGN wandelt die Staging-Volumes zum Zeitpunkt des Cutovers in produktive EC2-Instanzen des Ziel-Instanztyps um.

1. Install replication agent on each source (or use agentless for vCenter)
2. Configure launch template (instance type, subnet, IAM role, tags)
3. Run "Test" launches → validate → "Cutover" launch → decommission source

Test-Starts sind unerlässlich und werden oft übersprungen. MGN startet isolierte Testinstanzen aus dem aktuellen Replikationsstatus, ohne die laufende Replikation zu unterbrechen. Sie validieren das Anwendungsverhalten, verwerfen den Test, iterieren und leiten den Cutover erst ein, wenn die Tests erfolgreich sind – der Cutover stoppt die Replikation, startet die endgültige Instanz und markiert die Migrationswelle als abgeschlossen.

Der falsche Ansatz ist das manuelle Exportieren von VMs nach OVF, das Hochladen über aws ec2 import-image und die Neuinstallation von Anwendungen auf frisch bereitgestellten EC2-Instanzen. Dies ist langsam, fehleranfällig, erfordert pro VM eine Ausfallzeit, die der Exportdauer entspricht, bietet keine Delta-Replikation und keine unterbrechungsfreien Tests. MGN eliminiert all das – die Quelle läuft bis zur letzten Sekunde des Cutovers weiter, und der Drift zwischen Quelle und Ziel ist praktisch null.

Die allgemeine Portfolio-Empfehlung lautet, zuerst ein Rehosting durchzuführen und dann ein Re-Platforming oder Refactoring in der Region vorzunehmen, wo die Iterationskosten niedriger sind. Ein gleichzeitiges Refactoring und eine Migration vervielfachen das Risiko ohne einen entsprechenden Nutzen.

Hybride Konnektivität: Direct Connect und VPN

AWS Direct Connect bietet eine dedizierte Layer-2-Leitung von einem On-Prem-Router zu einem Direct Connect-Standort und bietet konsistente Bandbreite (1, 10, 100 Gbit/s dediziert; unter 1 Gbit/s über von Partnern gehostete Verbindungen) und vorhersagbare Latenz. Virtuelle Schnittstellen (Virtual Interfaces) unterteilen die Leitung:

• Private VIF – Zugriff auf eine einzelne VPC über ein Virtual Private Gateway.
• Transit VIF – Zugriff auf viele VPCs über ein Direct Connect Gateway, das an ein Transit Gateway angebunden ist. Dies ist das kanonische Muster für große Umgebungen mit mehreren VPCs und Standorten.
• Public VIF – Zugriff auf öffentliche AWS-Service-Endpunkte (S3, DynamoDB), ohne das Internet zu durchqueren.

DX ist für sich allein nicht hochverfügbar: Eine einzelne Leitung an einem einzigen DX-Standort hängt von einem einzigen Glasfaserpfad ab. Zwei Resilienz-Muster sind wichtig:

1. DX + Site-to-Site VPN-Backup über das Internet ist die minimal umsetzbare HA. BGP handhabt das automatische Failover mit AS-Path Prepending, MED oder Local-Pref, um DX im Normalbetrieb zu bevorzugen.
2. Zwei DX-Leitungen an getrennten DX-Standorten ist das Muster für maximale Resilienz für geschäftskritische Workloads und wird für das DX-SLA vorausgesetzt.

Das Versäumnis, irgendeinen Backup-Pfad bereitzustellen, ist eine bekannte Falle: Wenn DX ausfällt und kein VPN vorhanden ist, bleiben hybride Apps, DataSync-Jobs und Storage Gateway-Uploads für die Dauer der Reparatur durch den Carrier stehen. Eine reine VPN-Lösung ist für Workloads mit geringerem Durchsatz oder als Überbrückung während der Bereitstellung von DX, die Wochen dauern kann, akzeptabel.

On-prem Router ──── DX (primary, BGP MED=100) ────┐
                                                   ├── VGW/DXGW ── VPC
On-prem Router ──── VPN over Internet (backup) ────┘

# Multi-VPC access via DX Gateway
DirectConnectGateway:
  Associations:
    - TransitGateway: tgw-corp
    - VirtualPrivateGateway: vgw-prod-vpc
  AllowedPrefixes:
    - 10.0.0.0/8

Wo eine Verschlüsselung auf der physischen Schicht (Physical Layer) vorgeschrieben ist, wählen Sie eine MACsec-fähige DX-Verbindung. Die Kombination von DX für die Bandbreite, DataSync für die Orchestrierung und Storage Gateway für den fortgesetzten lokalen Zugriff ist das kanonische hybride Muster für große, aktive Datensätze, die kein Ausfallfenster tolerieren können.

AWS Outposts für On-Prem-AWS-Infrastruktur

Outposts erweitert die AWS-Infrastruktur als vollständig verwaltetes Rack (oder 1U/2U Outposts-Server) in die Räumlichkeiten eines Kunden. Es führt eine kuratierte Auswahl von Diensten lokal aus – EC2, EBS, ECS, EKS, RDS, S3 on Outposts, EMR – mit den gleichen APIs wie die übergeordnete Region. Control-Plane-Operationen fließen über einen Service Link aus redundanten, verschlüsselten Tunneln zur übergeordneten Region zurück; ein WAN-Ausfall verhindert vorübergehend das Starten neuer Instanzen, stoppt aber keine laufenden Workloads.

Die Aufteilung der geteilten Verantwortung (Shared Responsibility) ist die Falle, in die Betreiber tappen. AWS liefert und wartet die Hardware, den Hypervisor und die verwalteten Dienste. Der Kunde ist verantwortlich für:

• Physischen Platz, Strom, Kühlung und Netzwerkanbindung, die den Outposts-Spezifikationen entsprechen (redundante Stromversorgungen, Upstream-Switches, geeignete PDUs).
• Physische Sicherheit der Einrichtung.
• Lokale Netzwerkkonfiguration – das Local Gateway (LGW) für den On-Prem-Verkehr und den Service-Link-Uplink.
• Betriebssystem- und Anwendungsbelange der Workloads, genau wie in der Region.
• Ausreichende WAN-Konnektivität zurück zur übergeordneten Region.

Outposts eliminiert den Betrieb nicht – es verschiebt die Abstraktionsebene. Anzunehmen, AWS sei für die Stromversorgung des Rechenzentrums oder das Upstream-Netzwerk verantwortlich, ist ein fundamentales Missverständnis. Es bedeutet auch nicht, „jeden AWS-Dienst on-prem auszuführen“: Die Liste der unterstützten Dienste ist begrenzt, und Dienste wie Route 53 oder IAM bleiben regionsbasiert.

Für eine Hadoop/Spark-Modernisierung, bei der Daten aus regulatorischen Gründen on-premises bleiben müssen, ist EMR on Outposts das richtige Muster – verwaltete, elastische Spark-Cluster mit In-Region-Tooling und lokaler Datenresidenz. Storage Gateway oder DataSync erfüllen die Residenzanforderung nicht; ein Lift-and-Shift zu EMR in der Region verstößt gegen die Compliance.

Verteilen von Inhalten an Edge-Flotten

Wenn Outposts-Server, Einzelhandelsgeschäfte oder Edge-Geräte wiederholt dieselbe große Nutzlast – zum Beispiel ein nächtliches Software-Release – abrufen, führt das direkte Abrufen aus einem S3-Bucket in einer einzigen Region zur Sättigung der Uplinks und verlängert die Bereitstellungszeit. Das korrekte Muster ist CloudFront mit einem S3-Ursprung und signierten URLs:

S3 bucket (ap-northeast-1)  ← Origin Access Control
        │
   CloudFront distribution (global edge PoPs)
        │
   Signed URLs (short expiry, per-server or per-release)
        │
   Edge devices download from nearest PoP

Das erste Gerät in einer Region wärmt den Edge-Cache auf; jedes nachfolgende Gerät ruft die Daten mit Edge-Latenz ab. Signierte URLs verhindern unbefugte Downloads ohne gerätespezifische IAM-Anmeldeinformationen, und es muss keine Flotte regionaler Replikate verwaltet werden.

Zwei Anti-Muster, die zu vermeiden sind: das Hosten des Releases auf einem einzelnen EC2-Webserver (eine Katastrophe in Bezug auf Skalierung und Latenz) und das Replizieren des S3-Buckets in jede Region mittels Cross-Region Replication nur zur Reduzierung der Download-Latenz (unnötige Speicherkosten und betriebliche Komplexität, die das CloudFront-Caching kostenlos löst).

Entscheidungszusammenfassung

← Speicherung · Alle Domänen · Netzwerk →

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

Amazon durchsuchen →