Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der SAP-C02-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Einrichten einer AWS-Umgebung mit über 100 Accounts, konsistenten Guardrails, Logging und Identity von Tag eins an.
AWS Control Tower als Landing Zone. Account Factory stellt Accounts bereit; obligatorische + dringend empfohlene Guardrails setzen Baselines durch; zentrales Log-Archiv + Audit-Accounts werden automatisch erstellt.
Warum: Control Tower kodifiziert das gut-architektierte Multi-Account-Muster. Ein Neuaufbau nur mit Organizations würde die gleiche Infrastruktur manuell reproduzieren.
Es müssen benutzerdefinierte Guardrails und Ressourcen über die Control Tower-Standardeinstellungen hinaus über alle Accounts hinzugefügt werden.
Customizations for AWS Control Tower (CfCT). Eine Pipeline von CloudFormation-Templates + SCPs, die über StackSets auf OUs bereitgestellt werden.
Warum: CfCT erweitert Control Tower, ohne seinen Lebenszyklus zu unterbrechen. Benutzerdefinierte Config-Regeln, Sicherheits-Baselines, Networking - alles versionskontrolliert und wiederholbar.
S3 KMS-Verschlüsselung erzwingen + nicht-konforme Buckets in 300 Accounts in <15 Minuten automatisch beheben.
AWS Config organisationsweiter Konformitätspack über delegierten Administrator. Config-Regel + SSM Automation-Dokument zur automatischen Behebung.
Warum: Konformitätspacks stellen Config-Regeln + Behebung über die gesamte Organisation von einem Account aus bereit. Ansätze pro Account mit Lambda oder nur SCP verpassen entweder Echtzeit-Erkennung oder Behebung.
Manipulationssichere CloudTrail-Logs über alle Accounts, 7 Jahre lang aufbewahrt; nur das Sicherheitsteam kann sie lesen.
Organizations Trail, der in einen dedizierten Logging-Account S3-Bucket liefert. Object Lock im Compliance-Modus mit 7-jähriger Aufbewahrung. SCP, das den Bucket-Zugriff auf Sicherheits-IAM-Rollen beschränkt.
Warum: Object Lock im Compliance-Modus blockiert das Löschen auch durch den Root-Benutzer. Org-Trail sammelt automatisch von allen Accounts. Ein dedizierter Logging-Account isoliert den Blast Radius.
150 Accounts über SAML mit dem Unternehmens-AD föderieren; Berechtigungen nach AD-Gruppe zuweisen.
IAM Identity Center mit externem SAML 2.0 IdP. Berechtigungssätze, die über SCIM-Bereitstellung AD-Gruppen zugeordnet sind. Account-Zuweisungen über Gruppen.
Warum: Identity Center zentralisiert die Föderation über alle Organisations-Accounts. Berechtigungssätze sind über Accounts hinweg wiederverwendbar; SCIM hält den Benutzer-/Gruppenzustand synchron.
Zugriff auf Ressourcen gewähren, die mit dem Kostenbereich des Benutzers getaggt sind, skalierbar auf Tausende von Benutzern.
Attributbasierte Zugriffskontrolle in Identity Center. AD-Attribute über SAML übergeben; Berechtigungssätze referenzieren `aws:PrincipalTag/CostCenter` gegenüber `aws:ResourceTag/CostCenter`.
Warum: ABAC skaliert ohne Änderungen der Richtlinien pro Benutzer. Das Hinzufügen eines neuen Kostenbereichs ist nur ein Tag - kein IAM-Rewrite.
Der CI/CD-Account nimmt eine Deployment-Rolle in 50 Workload-Accounts an, um CloudFormation auszuführen.
IAM-Rolle pro Workload-Account mit Vertrauensrichtlinie, die den CI/CD-Account-Principal zulässt. CI/CD übernimmt über STS AssumeRole. Externe ID verwenden, wenn ein Drittanbieter-Tool initiiert.
Warum: Die externe ID verhindert das Problem des Confused Deputy. Das Verketten von Rollen begrenzt die Sitzung auf 1 Stunde, selbst wenn die Rolle eine längere Dauer zulässt.
Das zentrale Netzwerkteam besitzt die VPC; 30 Spoke-Accounts stellen Workloads in gemeinsam genutzten Subnetzen bereit.
AWS RAM teilt Subnetze mit teilnehmenden Accounts. Teilnehmer starten Ressourcen, ohne die VPC zu besitzen; das zentrale Team behält die Kontrolle über die Routing-Tabelle + NAT.
Warum: Gesharete VPCs eliminieren die VPC-Zersplitterung pro Account + doppeltes IPAM. Teilnehmer können die VPC nicht löschen oder das Routing ändern.
VPCs in 5 Regionen + On-Prem mit deterministischem Routing und zentraler Inspektion verbinden.
Transit Gateway in jeder Region. TGW-Peering für Inter-Region. Inspektions-VPC mit Appliances, erreichbar über TGW-Routing-Tabellen.
Warum: TGW-Peering vermeidet ein vollständiges Mesh von Inter-Region-VPN/Peering. Routing-Tabellen pro Anhang ermöglichen es der Sicherheit, spezifische Flüsse zu inspizieren, ohne andere zu unterbrechen.
Ein globales privates Netzwerk über Regionen + Zweigstellen mit richtliniengesteuertem Routing aufbauen - jenseits von TGW-Peering.
AWS Cloud WAN. Core-Netzwerkrichtlinie in JSON definiert deklarativ Segmente, Regionen, Anhänge, Sharing.
Warum: Cloud WAN ersetzt das Hub-of-Hubs-TGW-Design durch ein einziges verwaltetes globales Backbone. Segmente bieten logische Isolation über Regionen hinweg.
On-Prem DC benötigt eine 10-Gbps-Verbindung zu AWS mit Ausfallsicherheit bei Verbindungsfehlern und ohne Internetzugang.
Zwei Direct Connect-Verbindungen an separaten DX-Standorten. Jede mit einem privaten VIF, der auf einem Direct Connect Gateway → TGW endet. BGP-Failover zwischen den Verbindungen.
Warum: Ein einzelnes DX ist ein Single Point of Failure. Verschiedene DX-Standorte schützen vor standortweiten Ausfällen. DX Gateway ermöglicht einem VIF, mehrere Regionen/VPCs zu erreichen.
Direct Connect-Verbindung als primär; automatisches VPN-Failover erforderlich.
Site-to-Site VPN, das an dasselbe TGW wie das DX Gateway angeschlossen ist. AWS bevorzugt DX BGP-Routen; VPN übernimmt, wenn DX BGP zurückgezogen wird.
Warum: Die BGP-Routenpräferenz macht das Failover automatisch. Vorprovisioniertes VPN vermeidet Bereitstellungsverzögerungen während des Ausfalls.
Der Regulator verlangt Layer-2-Verschlüsselung zwischen On-Prem und AWS über Direct Connect.
Direct Connect mit MACsec auf einer dedizierten 10-Gbps- oder 100-Gbps-Verbindung. Vorab geteilter Schlüssel an beiden Enden konfiguriert.
Warum: IPsec läuft auf Layer 3; MACsec verschlüsselt auf Layer 2 mit Leitungsgeschwindigkeit und erfüllt damit die Anforderungen von Regulierungsbehörden, die eine physische Link-Verschlüsselung vorschreiben.
Ost-West-Traffic zwischen VPCs muss eine Stateful Inspection durchlaufen.
Zentralisierte Inspektions-VPC mit AWS Network Firewall. TGW-Routing-Tabellen leiten den VPC-übergreifenden Traffic durch die Firewall-VPC, bevor er das Ziel erreicht.
Warum: Network Firewall ist die verwaltete Suricata-Regel-Engine für die Stateful Inspection. Die Zentralisierung vermeidet die Zersplitterung von Firewalls pro VPC.
Eine Baseline WAF + Network Firewall-Konfiguration automatisch auf jeden Account in der Organisation anwenden.
AWS Firewall Manager mit delegiertem Administrator. Richtlinien für WAF, Shield Advanced, Network Firewall, Sicherheitsgruppen gelten organisationsweit.
Warum: Firewall Manager hängt Richtlinien automatisch an neue Ressourcen an. Ohne ihn weicht jeder Account von der Baseline ab, wenn Accounts hinzugefügt werden.
Security Hub-Findings von über 100 Accounts in einer einzigen Ansicht zentralisieren.
Security Hub delegierter Administrator. Aggregationsregion sammelt Findings von allen Mitglieds-Accounts + allen aktivierten Regionen in einer Konsole.
Warum: Ohne Aggregation bleiben Findings pro Account/Region. Delegierter Admin vermeidet die Nutzung des Management-Accounts für Sicherheitsoperationen.
GuardDuty über die gesamte Organisation mit zentraler Überwachung und Transparenz der Abrechnung pro Account aktivieren.
GuardDuty mit delegiertem Administrator. Automatische Aktivierung für neue Accounts über die Org-Integration. Findings werden an den Admin-Account aggregiert.
Warum: Die automatische Aktivierung schließt die Lücke bei neu erstellten Accounts, die sonst unüberwacht blieben.
Kontinuierliche PII-Erkennung über alle S3-Buckets in 200 Accounts.
Macie mit delegiertem Administrator. Organisationsweite automatische Aktivierung. Findings fließen zu Security Hub für eine einheitliche Überprüfung.
Warum: Macie kann ohne explizite Einrichtung nicht über Accounts hinweg lesen. Die Konfiguration auf Organisationsebene stellt sicher, dass jeder Bucket erfasst wird.
Ein GuardDuty-Finding untersuchen, indem CloudTrail + VPC Flow Logs über Accounts hinweg korreliert werden.
Amazon Detective delegierter Administrator in einem dedizierten Sicherheits-Account. Mitglieds-Accounts tragen zum Verhaltensgraphen bei.
Warum: Detective erstellt den Verhaltensgraphen automatisch aus VPC Flow Logs, CloudTrail, GuardDuty. Delegierter Admin (nicht Management) folgt den AWS Best Practices.
Erkennen, wann eine Ressource in der Organisation mit einem externen Account geteilt wird.
IAM Access Analyzer mit Org als Vertrauenszone, delegiert an den Sicherheits-Account. Findings zu Cross-Account-Zugriff in S3, IAM-Rollen, KMS-Keys, Lambda, SQS, Secrets.
Warum: Access Analyzer verwendet formale Verifikation, nicht Musterabgleich. Die Vertrauenszone auf Organisationsebene behandelt Geschwister-Accounts als vertrauenswürdig.
Savings Plan-Nutzung über 50 Accounts mit unterschiedlichen Workload-Mustern maximieren.
Konsolidierte Abrechnung in Organizations mit aktivierter Savings Plans + RI-Freigabe. Im Payer-Account gekaufte Pläne werden organisationsweit geteilt.
Warum: Durch das Teilen wird die Nutzung gepoolt, sodass ungenutzte Kapazität in einem Account den Bedarf in einem anderen ausgleicht. Teilen nur für die Isolierung der Kostenverteilung deaktivieren.
Anwendungsteams sollen genehmigte Infrastruktur (VPCs, RDS) selbst bereitstellen können, ohne IAM-Administratorrechte zu besitzen.
AWS Service Catalog Portfolios. Vorab genehmigte CloudFormation-Produkte mit Einschränkungen. Portfolios über Accounts hinweg via Organizations teilen.
Warum: Bietet Self-Service mit Guardrails. Einschränkungsrichtlinien verbergen Komplexität (Instanztypen, Tags), während Produkte den IAM-Bereich für den Start mit sich bringen.
Mandatory `CostCenter` und `Environment`-Tags konsistent über die Organisation hinweg durchsetzen.
Organizations-Tag-Richtlinien, die an OUs angehängt sind. Erlaubte Werte + Groß-/Kleinschreibung definieren. Kombinieren mit Config-Regel `required-tags` zur Durchsetzung.
Warum: Tag-Richtlinien validieren; Config-Regeln erkennen Nicht-Konformität. SCPs können die Ressourcenerstellung ohne Tags verweigern.
Root-Benutzeraktionen in Mitglieds-Accounts verhindern (Compliance-Anforderung).
SCP, das jede Aktion verweigert, wenn `aws:PrincipalArn` mit `arn:aws:iam::*:root` übereinstimmt.
Warum: SCPs gelten auch für Root. IAM kann Root nicht verweigern. Root-Aktionen sollten niemals benötigt werden, außer zur Account-Wiederherstellung.
AWS Backup-Pläne über alle Accounts mit konsistenter Aufbewahrung vorschreiben.
Organizations-Backup-Richtlinien, die an OUs angehängt sind. Pläne + Auswahlkriterien definieren; automatisch auf relevante Ressourcen anwenden.
Warum: Die Duplizierung von Backup-Plänen pro Account führt zu Abweichungen. Org-Richtlinien erzwingen eine einzige Quelle der Wahrheit.
Über 100 VPCs, jede mit NAT Gateway, verursachen zu hohe Kosten. Ein einziger Egress-Punkt wird gewünscht.
Zentralisierte Egress-VPC mit NAT Gateway. Spoke-VPCs routen 0.0.0.0/0 → TGW → Egress-VPC → NAT.
Warum: Ein NAT statt 100 senkt die Kosten drastisch. TGW-Datenübertragungsregeln zwischen Regionen gelten, daher sorgfältig für den Inter-Region-Traffic planen.
EC2 in VPC muss On-Prem Hostnamen auflösen; On-Prem muss VPC private DNS auflösen.
Route 53 Resolver Inbound + Outbound Endpoints. Weiterleitungsregeln senden `corp.local`-Abfragen an On-Prem; On-Prem DNS leitet `*.compute.internal` an Inbound Endpoint weiter.
Warum: Resolver Endpoints sind HA ENIs in zwei AZs. Bedingtes Forwarding ermöglicht bidirektionale Auflösung, ohne DNS dem Internet auszusetzen.
Interne Dienste benötigen DNS, das von mehreren VPCs über Accounts hinweg auflösbar ist.
Route 53 Private Hosted Zone, verbunden mit VPCs aus mehreren Accounts über Cross-Account VPC Association.
Warum: Eine PHZ, die über Cross-Account-Association geteilt wird, ist besser als pro-VPC-Duplikate, die auseinanderdriften.
Windows-Workloads benötigen volles AD mit Vertrauen zu On-Prem Forest.
AWS Managed Microsoft AD. Zwei-Wege-Forest-Vertrauen mit On-Prem AD über DX/VPN herstellen.
Warum: Managed AD ist echtes Microsoft AD (DCs in zwei AZs, Schema erweiterbar). AD Connector fungiert nur als Proxy; Simple AD unterstützt kein Vertrauen.
Anwendungen in AWS müssen sich gegen ein bestehendes On-Prem AD authentifizieren, ohne Identitäten zu replizieren.
AD Connector. Fungiert als Proxy von VPC zu On-Prem AD über DX/VPN.
Warum: Keine Verzeichnisdaten verlassen On-Prem; Authentifizierungsanfragen werden durchgeleitet. Die Latenz hängt von der Verbindung ab.
Latenzempfindliche Workload muss in einem bestimmten Rechenzentrum laufen, aber über AWS APIs verwaltet werden.
AWS Outposts Rack/Server. Dieselben AWS APIs (EC2, EBS, ECS, EKS, RDS-Untermenge) laufen On-Prem. Verbindet sich mit einer Parent Region.
Warum: Für Sub-Millisekunden-Latenz zu lokalen On-Prem-Systemen oder Datenresidenz, wo Local Zones nicht abdecken. Single-AZ - zwei Outposts für HA koppeln.
Latenz für Endbenutzer in einer Metropolregion reduzieren, die weit von der Parent Region entfernt ist.
AWS Local Zones. Compute, Storage nahe Bevölkerungszentren bereitstellen; Datenebene wird zur Control Plane an die Parent Region zurückgeleitet.
Warum: Local Zones hosten EC2/EBS/RDS/ELB in der Nähe großer Städte. Günstiger als Outposts, wenn keine volle DC-Eigentümerschaft benötigt wird.
Anwendung benötigt einstellige Millisekunden-Latenz für mobile Benutzer auf 5G.
AWS Wavelength Zones in Carrier-5G-Netzwerken. EC2/EBS am Carrier Edge bereitstellen; der Traffic bleibt im Netzwerk des Mobilfunkanbieters.
Warum: Eliminiert den öffentlichen Internet-Hop vollständig für 5G-Anwendungsfälle wie AR/VR, Echtzeit-Inferenz, Gaming.
Compliance-Auditor benötigt die aktuelle Konfiguration jeder Ressource in der Organisation.
AWS Config Aggregator im Audit-Account, für die gesamte Organisation über alle Regionen hinweg.
Warum: Config Aggregator ist die schreibgeschützte organisationsweite Ansicht. Aggregatoren aktivieren Config nicht in Mitglieds-Accounts - das ist separat.
CloudWatch Logs von 50 Accounts müssen in einem S3-Archiv für die SIEM-Aufnahme landen.
Abonnementfilter in jedem Account → Cross-Account Kinesis Data Stream / Firehose → S3 im Logging-Account.
Warum: Abonnementfilter ermöglichen das Pushen von Log-Gruppen in Echtzeit. Firehose übernimmt Batching, Komprimierung, S3-Partitionierung.
Laufend Nachweisberichte für SOC 2, PCI, HIPAA über die gesamte Organisation erstellen.
AWS Audit Manager. Vorgefertigte Frameworks mappen Kontrollen zu AWS-Nachweisen (Config, CloudTrail, Security Hub). Delegierter Admin im Sicherheits-Account.
Warum: Audit Manager sammelt Nachweise pro Kontrolle automatisch. Spart Hunderte von Stunden manueller Screenshot-Sammlung pro Audit-Zyklus.
Eine grundlegende IAM-Rolle für jeden bestehenden + zukünftigen Account in der Organisation bereitstellen.
CloudFormation StackSets mit Service-verwalteten Berechtigungen + Auto-Deployment für neue Accounts. Die gesamte Organisation oder spezifische OUs ansprechen.
Warum: Selbstverwaltete StackSets erfordern IAM in jedem Account. Service-verwaltete nutzen Org-Berechtigungen und sind der Standard für Organizations.
Nach monatelangem Betrieb von StackSets wird ein Abweichen durch manuelle Änderungen vermutet.
Drift-Erkennung für das StackSet initiieren. Ergebnisse pro Stack-Instanz überprüfen, ohne Ressourcen zu ändern.
Warum: Drift-Erkennung vergleicht die Live-Ressourcenkonfiguration mit der Vorlage. Das erneute Bereitstellen von StackSets zur "Behebung" von Drift kann unbeabsichtigte Änderungen verursachen.
Variable, kurzzeitig stark ansteigende Datenbank-Workload - Kapazitätsbedarf schwankt innerhalb von Minuten um das Zehnfache.
Aurora Serverless v2. Min/Max ACU festlegen; Aurora skaliert in Sekunden ohne Verbindungsabbrüche.
Warum: v2 skaliert durch Hinzufügen von Kapazität zur bestehenden Instanz - kein Failover. Provisioned Aurora kann nicht so schnell skalieren; Serverless v1 skaliert langsamer und pausiert Verbindungen.
Globale Anwendung mit <1s RPO und <1min RTO für Cross-Region DB-Failover.
Aurora Global Database. Speicherbasierte Replikation, typische Replikationsverzögerung <1s. Sekundärsystem in Sekunden hochstufen.
Warum: Global DB versendet Seiten, nicht Transaktionen - Sub-Sekunden über Regionen hinweg. Cross-Region Read Replicas über logische Replikation können dies nicht erreichen.
Eine Produktionsdatenbank für Tests reproduzieren, ohne für eine vollständige Kopie zu bezahlen.
Aurora Cloning. Copy-on-Write - der anfängliche Klon ist kostenlos; nur geänderte Seiten werden abgerechnet.
Warum: Klone sind Point-in-Time, sofortig, isoliert. Snapshot + Restore dauert Stunden und berechnet sofort den vollen Speicherplatz.
Sich von einem logischen Fehler (DROP TABLE in Prod) in Minuten, nicht Stunden, erholen.
Aurora MySQL Backtrack. Spult den Cluster an Ort und Stelle auf einen früheren Zeitpunkt zurück, ohne aus dem Backup wiederherzustellen.
Warum: Backtrack ist In-Place und schnell. PITR-Restores erstellen einen neuen Cluster - langsamer und erfordert eine App-Umstellung.
Berichtsabfragen an spezifische Reader-Instanzen mit größerem Speicher weiterleiten.
Aurora Custom Endpoints. Endpunkt definieren, der auf eine Untermenge von Readern (die größeren) zeigt.
Warum: Der Standard-Reader-Endpoint verteilt alle Reader im Round-Robin-Verfahren. Custom Endpoints partitionieren den Cluster nach Workload-Typ.
DynamoDB-Tabelle erlebt Hot Partition Spikes, die einige Lese-/Schreibvorgänge drosseln.
Provisioniert mit Auto-Scaling + Adaptive Capacity (automatisch). Partitionsschlüssel neu gestalten, wenn ein einzelner Schlüssel der Hotspot ist.
Warum: Adaptive Capacity verteilt den Durchsatz über Partitionen ohne Aktion neu. Wenn jedoch ein Schlüssel heiß ist, hilft nur eine Schema-Neugestaltung (Verbundschlüssel, Write Sharding).
Nebenwirkung bei jedem DynamoDB-Schreibvorgang - Push an OpenSearch zur Suchindexierung.
DynamoDB Streams + Lambda Trigger. Lambda batched Stream-Records und schreibt sie in OpenSearch.
Warum: Streams erfassen Änderungen auf Item-Ebene für 24 Stunden. Natives Trigger-Modell - Kinesis Data Streams Adapter existiert für längere Aufbewahrung/Analysen.
Zweiphasiger Schreibvorgang über mehrere DynamoDB-Items muss atomar sein.
TransactWriteItems / TransactGetItems. ACID-Semantik über bis zu 100 Items.
Warum: Native Transaktionen vermeiden die Komplexität der Distributed Saga. Die Kosten betragen das Doppelte der normalen Kapazität pro Item - nur verwenden, wenn Atomizität erforderlich ist.
Ein selbst gehosteter MongoDB-Cluster zu einem Managed Service migrieren und die API beibehalten.
Amazon DocumentDB. MongoDB-kompatible API. mongodump/mongorestore oder DMS für die Migration verwenden.
Warum: DocumentDB ist API-kompatibel mit MongoDB 4.0/5.0 (die meisten Operatoren, nicht alle). Treiber-/Feature-Kompatibilität vor dem Commit überprüfen.
Eine Empfehlungs-Engine muss einen sozialen Graphen mit 100 Millionen Knoten durchlaufen.
Amazon Neptune. Property Graph (Gremlin) oder RDF (SPARQL).
Warum: Zweckbestimmte Graph-DB. Das Modellieren von Beziehungen in DynamoDB oder RDS ist möglich, aber die Abfrageleistung verschlechtert sich mit der Hop-Tiefe.
IoT-Flotte emittiert 10 Millionen Timeseries-Datenpunkte/Sekunde mit gemischter Frequenzaufbewahrung.
Amazon Timestream. Memory Store (aktuelle Daten), Magnetic Store (historische Daten) - automatische Tiering.
Warum: Zweckbestimmte Timeseries - DynamoDB/RDS-Skalierung zu diesem Satz kosten prohibitiv. Eingebaute Aufbewahrungs-Tiering reduziert Speicherkosten.
Ein Bankenbuch benötigt kryptografische Verifizierung jeder Datensatzänderung.
Amazon QLDB. Unveränderliches, kryptografisch verifizierbares Journal. SHA-256 Digest-Export für Nachweise verwenden.
Warum: QLDB ist ein zweckbestimmtes Ledger. DynamoDB Streams liefern die Änderungshistorie, aber keine eingebaute kryptografische Verkettung.
Log-Analyse-Workload mit unvorhersehbaren Spitzen und wartungsfreiem Betrieb.
Amazon OpenSearch Serverless. Entkoppelte Compute/Storage; skaliert OCUs automatisch.
Warum: Keine Cluster-Größenanpassung oder Shard-Verwaltung. Für vorhersehbare, konstante Workloads sind provisionierte Domains günstiger.
Petabyte-Skala-Analysen mit elastischer Compute-Leistung und Datenaustausch zwischen Teams.
Redshift RA3-Knoten mit Managed Storage. Cross-Cluster Data Sharing (kein Kopieren).
Warum: RA3 trennt Compute von Storage - skaliere jeden unabhängig. Data Sharing eliminiert ETL zwischen den Clustern der Teams.
Bestehender Redshift-Cluster + S3 Data Lake - S3 von Redshift abfragen oder Athena verwenden?
Redshift Spectrum, wenn Joins zwischen Clustertabellen und S3-Daten benötigt werden. Athena, wenn komplett serverless Ad-hoc nur auf S3.
Warum: Spectrum führt S3-Abfragen über Redshift Compute aus. Athena zahlt pro gescanntem TB. Wählen Sie, wo die dominanten Daten leben.
Verschiedene Teams benötigen unterschiedliche Zeilen-/Spalten-Sichtbarkeit auf denselben Glue Catalog-Tabellen.
AWS Lake Formation mit Zeilen-, Spalten- und Zellfiltern. Gewährung über LF-Tags.
Warum: IAM/S3-Richtlinien können keine Zeilenebene. Lake Formation erzwingt feingranularen Zugriff über Glue Catalog-Metadaten + Athena/Redshift Spectrum/EMR-Konsumenten.
Täglicher Glue-Job verarbeitet inkrementelle Daten; darf die Dateien von gestern nicht erneut verarbeiten.
Glue Job Bookmarks. Verarbeitete S3-Schlüssel / DB-Zeilen verfolgen; vom letzten erfolgreichen Checkpoint fortsetzen.
Warum: Bookmarks vermeiden doppelte Verarbeitung ohne manuelle Zustandsverfolgung. Für vollständige Neuverarbeitungs-Läufe deaktivieren.
Managed Kafka vs. Kinesis Data Streams für Event Streaming auswählen.
MSK, wenn bestehende Kafka-Clients/Ökosystem vorhanden. Kinesis für enge AWS-Integration (Lambda-Trigger, Firehose, KCL) und Serverless-Option.
Warum: Beide streamen dauerhaft mit Replay. MSK bewahrt die Kafka API und das Ökosystem; Kinesis kostet weniger für kleine Streams und integriert sich nativ.
Variabler Kafka-Durchsatz; möchte Cluster-Management ohne manuellen Aufwand.
MSK Serverless. Skaliert Partitionen und Durchsatz automatisch; Abrechnung pro Partition + Daten.
Warum: Keine Broker-Dimensionierung. Für anhaltend hohen Durchsatz ist provisioniertes MSK günstiger.
SQS → Filter → Step Functions verbinden, ohne Glue Lambda zu schreiben.
EventBridge Pipes. Quelle → optionaler Filter → optionale Anreicherung → Ziel.
Warum: Ersetzt ein typisches Lambda-as-glue. Reduziert Code, Kosten und operative Angriffsfläche.
Die Ereignisse der letzten Woche durch einen neuen Consumer wiedergeben, ohne sie von der Quelle erneut zu emittieren.
EventBridge Archiv + Replay. Archiv erfasst passende Ereignisse; gibt sie später an ein Ziel wieder.
Warum: Eingebauter Replay vermeidet die Notwendigkeit eines separaten Event Stores. Nützlich für die Wiederherstellung nach Vorfällen und das Onboarding neuer Consumer.
Hunderte von Produzenten emittieren Ereignisse; Consumer benötigen typisierte Bindings.
EventBridge Schema Registry mit Auto-Discovery. Generiert stark typisierte Code-Bindings (Java, Python, TypeScript).
Warum: Discovery lernt Schemata aus beobachteten Ereignissen. Bindings bieten Compile-Zeit-Sicherheit.
Sub-Sekunden-abgerechnete Orchestrierung von hochvolumigen, kurzen Workflows (>100k/Sek.).
Step Functions Express Workflows. Abrechnung pro Ausführungs-ms; max. 5 Minuten.
Warum: Standard-Workflows sind dauerhaft + Historie wird verfolgt, Abrechnung pro Statusübergang. Express tauscht Audit-Trail für Kosten bei kurzlebigen Flüssen ein.
10 Millionen S3-Objekte parallel durch eine Step Function verarbeiten.
Distributed Map State. Gleichzeitige Kindausführungen bis zu 10.000 parallel; liest die Quelle direkt von S3.
Warum: Inline Map ist auf 40 parallele begrenzt. Distributed Map skaliert auf S3-Bucket-Größen-Jobs, ohne Service-Quotas zu erreichen.
FIFO-Warteschlange erfordert >300 Nachrichten/Sek.
SQS FIFO mit aktiviertem High-Throughput-Modus. Bis zu 70.000 Nachrichten/Sek. pro API pro Region; Partitionierung nach `MessageGroupId`.
Warum: Standard-FIFO ist auf 300 Nachrichten/Sek. ohne Batching begrenzt. Der High-Throughput-Modus partitioniert die Sortierung nach Gruppen-ID.
Mehrere Consumer benötigen jeweils den vollen Lesedurchsatz auf demselben Kinesis Stream.
Enhanced Fan-Out (EFO). Jeder Consumer erhält eine dedizierte 2 MB/s/Shard-Pipe über HTTP/2-Push.
Warum: Standard-Polling teilt die 2 MB/s/Shard-Grenze unter den Konsumenten auf. EFO eliminiert die Konkurrenz zu höheren Kosten.
Firehose nach S3; Data Lake-Abfragen scannen zu viel, weil die Partitionierung nach Ingestionszeit, nicht nach Ereigniszeit erfolgt.
Firehose Dynamic Partitioning. Ereigniszeit / Tenant ID aus JSON extrahieren; nach S3-Präfix `year=YYYY/month=MM/tenant=X/` schreiben.
Warum: Athena/Spectrum Partition Pruning nach Ereigniszeit reduziert Scan-Kosten und Latenz drastisch.
Mobile-/Web-Client benötigt Echtzeit-Updates und selektives Feld-Fetching.
AWS AppSync (GraphQL) mit Subscriptions. WebSocket-basiert.
Warum: GraphQL-Clients holen nur angeforderte Felder und abonnieren Deltas. REST/HTTP API Gateway erzwingt Over-Fetch und Polling.
Interne API darf nicht aus dem öffentlichen Internet erreichbar sein.
API Gateway Private Endpoint über Interface VPC Endpoint. Ressourcenrichtlinie beschränkt auf spezifische VPCs.
Warum: Private APIs sind nur von VPC + verbundenen Netzwerken erreichbar. Öffentliche APIs erfordern WAF + Authentifizierung, um sicher zu sein.
S3-Origin sperren, sodass nur CloudFront darauf zugreifen kann.
Origin Access Control (OAC). Ersetzt das ältere OAI; unterstützt SSE-KMS und alle S3-Funktionen.
Warum: OAI unterstützt SSE-KMS-Objekte nicht. AWS empfiehlt OAC für alle neuen Distributionen.
Zeitlich begrenzter Zugriff auf bestimmte kostenpflichtige Videos in S3.
CloudFront Signed URLs (pro URL) oder Signed Cookies (mehrere URLs). Vertrauenswürdige Schlüsselgruppe signiert Anfragen.
Warum: Vorab signierte S3-URLs umgehen das CloudFront-Caching. CloudFront Signed URLs cachen am Edge UND beschränken den Zugriff.
Leichte Viewer-Request-Transformation: Header-Rewrite, Redirect, A/B-Routing.
CloudFront Functions. JS, Sub-Millisekunde, alle Edge POPs.
Warum: Lambda@Edge ist volles Node/Python am regionalen Edge - schwerer und teurer. Functions sind 10x günstiger für einfache Manipulationen.
Nicht vertrauenswürdige Multi-Tenant-Workloads in EKS mit starker Isolation ausführen.
EKS Fargate Per-Pod-Isolation. Jeder Pod läuft in einer dedizierten Micro-VM.
Warum: Managed Node Groups teilen den Kernel - Privilegienerweiterung überschreitet Tenants. Fargate Kernel-Isolation ist die stärkste in EKS.
EKS-Cluster-Autoscaling-Latenz zu langsam; Instanztyp-Sprawl bei Node Groups.
Karpenter. Provisioner wählt Instanztypen Just-in-Time basierend auf ausstehenden Pod-Anforderungen.
Warum: Cluster Autoscaler skaliert vordefinierte ASGs, langsam und begrenzt. Karpenter skaliert beliebige EC2 in Sekunden mit Diversifizierung.
EKS-Pod benötigt Least-Privilege IAM (Vermeidung von Node-Instance-Rollen-Sharing).
IAM Roles for Service Accounts (IRSA) über OIDC-Provider. ServiceAccount mit Rollen-ARN annotieren.
Warum: EKS Pod Identity ist die neuere Alternative - einfacheres Vertrauensmodell. IRSA ist ausgereift und funktioniert über Regionen hinweg.
ECS-on-EC2-Task-Starts dauern 5-7 Minuten während des Scale-Out - benötigen <60s.
ECS Capacity Provider mit verwaltetem Skalierungsziel ~80% auf `CapacityProviderReservation`. Idle-Puffer aufrechterhalten.
Warum: Reservierter Puffer bedeutet, dass neue Tasks sofort auf bestehender Kapazität landen, während ASG Ersatz startet.
Lambda wird durch SQS ausgelöst, aber nur 5% der Nachrichten passen - verschwendete Invokationen.
Event Source Mapping mit Filterkriterien. Lambda wird nur für passende Nachrichten aufgerufen.
Warum: Der Pre-Lambda-Filter vermeidet Kosten pro Aufruf für irrelevante Nachrichten. Filterung wird für SQS, Kinesis, DynamoDB, MQ, Kafka unterstützt.
Produktions-App benötigt einen LLM-Endpoint mit geringem operativen Aufwand.
Amazon Bedrock für verwaltete Foundation Models (Claude, Llama, Titan). SageMaker nur, wenn Sie benutzerdefinierte Modelle oder Open-Weights eng abgestimmt hosten müssen.
Warum: Bedrock ist API-only - keine Infrastruktur. SageMaker ist eine vollständige ML-Plattform - wählen Sie, wenn Sie den Trainings-/Fine-Tuning-Lebenszyklus besitzen.
Verwaltete KI für Vision / NLP auswählen, ohne ein Modell zu trainieren.
Rekognition (Bild-/Video-Labels, Gesichter, Content-Moderation). Comprehend (Stimmung, Entitäten, Sprachen, PII-Erkennung). Translate. Polly. Transcribe.
Warum: Vortrainierte AWS AI-Services überspringen den gesamten ML-Lebenszyklus für gängige Aufgaben. SageMaker nur verwenden, wenn "off-the-shelf" nicht passt.
Web-App unterstützt E-Mail/Passwort + Google + Apple + SAML Enterprise SSO.
Cognito User Pool mit gehosteter UI. OIDC + SAML IdPs konfigurieren. App erhält Cognito JWT.
Warum: User Pool aggregiert IdPs zu einem Token. Identity Pool tauscht nur Tokens gegen AWS-Anmeldeinformationen - für AWS API-Zugriff, nicht Authentifizierung.
DynamoDB Global Tables mit gleichzeitigen Schreibvorgängen auf denselben Schlüssel in zwei Regionen.
Last-Writer-Wins nach Zeitstempel. Anwendung entwirft idempotente Schreibvorgänge oder partitioniert Schreibvorgänge nach Region.
Warum: GT-Replikation ist asynchrones Multi-Master. Konfliktlösung ist zeitstempelbasiert - Anwendungen müssen Eventual Consistency tolerieren.
EC2-Flotte in der gesamten Organisation überdimensioniert; automatisierte Right-Sizing-Empfehlungen erforderlich.
AWS Compute Optimizer auf Organisationsebene aktiviert. Empfehlungen mit Auslastungsfenstern überprüfen; für die Nachverfolgung nach S3 exportieren.
Warum: Compute Optimizer verwendet ML für CloudWatch-Metriken. Manuelles Right-Sizing verpasst Workload-Shape-Signale.
Unerwartete Kosten-Spitzen innerhalb von Stunden erkennen, nicht erst am Monatsende.
AWS Cost Anomaly Detection. ML überwacht Ausgaben pro Service / pro Account; alarmiert über SNS / E-Mail, wenn der Schwellenwert überschritten wird.
Warum: Budgets werden bei geplanten Schwellenwerten ausgelöst. Anomalieerkennung fängt Überraschungen (kompromittierter Schlüssel, außer Kontrolle geratener Trainingsjob) Tage/Wochen früher ab.
Wenn ein Account 100% des monatlichen Budgets erreicht, nicht-essentielle Ressourcen automatisch anhalten.
AWS Budget Actions. Eine restriktive IAM-Richtlinie anwenden + Lambda über SNS auslösen, um nicht-essentielle EC2/RDS zu stoppen.
Warum: Budget-Aktionen wechseln von "nur Alarm" zu "durchsetzen". Kombinieren Sie sie mit Cost Anomaly Detection, um ungeplante Ausgaben zu erfassen.
Organisationsweite Transparenz über S3-Kostenoptimierungsmöglichkeiten.
S3 Storage Lens mit erweiterten Metriken + organisationsweiter Geltungsbereich. Zeigt Kandidaten für Cold-Tier, IT-Tier-Möglichkeiten, abgebrochene Multipart-Uploads auf.
Warum: Der Free Tier deckt grundlegende Metriken ab; der Advanced Tier zeigt Replikation, Aktivität, Optimierungsempfehlungen. Zentralisiert im Audit-/Sicherheits-Account.
Die S3-Rechnung steigt trotz Löschvorgängen weiter an.
Lebenszyklusregel bricht `incomplete multipart uploads` nach 7 Tagen ab. Mit `s3api list-multipart-uploads` überprüfen.
Warum: Fehlgeschlagene Uploads hinterlassen Teile, die als Speicherplatz abgerechnet werden, aber in der Konsolenliste unsichtbar sind. Häufige Kostenfalle.
Kalte Archivdaten, die höchstens einmal pro Quartal abgerufen werden.
S3 Glacier Flexible Retrieval (1-12 Std. Wiederherstellung). Für "nie abgerufene" Daten Deep Archive verwenden (12 Std. Abruf, geringste Kosten).
Warum: Standard-IA bietet Millisekunden-Zugriff; Glacier-Tiers tauschen Zugriffszeit gegen ~80-95% Kostenreduzierung ein.
NAT Gateway Egress-Kosten für S3 + DynamoDB-Traffic senken.
Gateway VPC Endpoints für S3 + DynamoDB (kostenlos). Traffic über Endpoint routen, NAT umgehen.
Warum: NAT berechnet pro GB; Gateway Endpoints sind kostenlos. Für andere AWS-Services reduzieren Interface Endpoints die Kosten, eliminieren sie aber nicht.
Workload mit viel Kommunikation über AZs hinweg; Datenübertragungskosten dominieren die Rechnung.
Microservices, wo möglich, in derselben AZ platzieren. VPC Lattice oder Service Mesh mit AZ-Affinitäts-Routing verwenden.
Warum: Cross-AZ kostet 0,01 $/GB pro Richtung. Microservice-Chatter in großem Maßstab summiert sich. Etwas HA für Kosten eintauschen, wo 99,95% ausreichen.
Egress-Traffic ins Internet ist der größte Einzelposten.
Alles mit CloudFront versehen. CloudFront-to-Internet-Egress ist günstiger als direkter EC2/ALB-Egress.
Warum: CloudFront Egress-Preise sind gestaffelt und deutlich niedriger als regionaler Egress. Caching reduziert den Origin-Egress zusätzlich.
Wählen zwischen Compute Savings Plan vs. EC2 Instance Savings Plan vs. Reserved Instances.
Compute SP: am flexibelsten (jede Region, Familie, OS) - etwas geringerer Rabatt. EC2 Instance SP: familiengebundene Region - tieferer Rabatt. RI: seltene Fälle, die eine Kapazitätsreservierung benötigen.
Warum: Compute SP deckt Lambda + Fargate + EC2 ab. RIs schlagen SPs nur, wenn Kapazitätsreservierung wichtig ist; in den meisten Fällen gewinnen SPs.
Zustandslose Batch-Flotte läuft auf Spot - Unterbrechungsrate zu hoch.
Spot Fleet mit kapazitätsoptimierter Strategie über viele Instanztypen + AZs hinweg.
Warum: Die Strategie mit dem niedrigsten Preis konzentriert sich auf einen einzigen Pool - hohe Unterbrechung. Kapazitätsoptimiert wählt Pools mit der tiefsten verfügbaren Kapazität.
Compute-Kosten auf der zustandslosen Web-Ebene um ~20% senken, ohne Neuschreiben.
Migration zu Graviton (ARM) - `c7g`, `m7g`, Lambda ARM, Aurora Graviton. Kompatibilitätstests für kompilierte Binärdateien.
Warum: Graviton bietet für die meisten Workloads eine um ca. 20% bessere Preis-Leistung. Java/Python/Node "funktionieren einfach"; nativer Code muss möglicherweise neu kompiliert werden.
Kostenreduzierung für einen lang laufenden, aber unterbrechungstoleranten Fargate-Service.
Fargate Spot über Capacity Provider-Strategie. Spot + On-Demand für HA-Tasks mischen.
Warum: Fargate Spot ist ~70% günstiger. Tasks erhalten eine 2-minütige Warnung vor der Beendigung - mit graceful Drain koppeln.
CloudWatch Logs-Speicherkosten steigen Monat für Monat.
Aufbewahrungszeit pro Log-Gruppe festlegen (Standard ist "ewig"). Für langfristige Speicherung nach S3 exportieren + in CW löschen. Logs Infrequent Access-Klasse verwenden.
Warum: CW Logs kostet $0.03/GB Ingestion + Speicherung für immer. S3 Standard-IA zu $0.0125/GB ist günstiger für Archivzugriff.
Fragmentiertes Monitoring durch einheitliche Observability über alle Dienste hinweg ersetzen.
CloudWatch ServiceLens für Service Map; X-Ray für Traces; CloudWatch Logs Insights für Ad-hoc; Container Insights für ECS/EKS; RUM für Browser; Synthetics für Canaries.
Warum: AWS-native Stack vermeidet Agenten pro Host. Mit OpenTelemetry SDK für Portabilität koppeln.
Einen Request über Dienste in 5 Accounts hinweg verfolgen.
X-Ray Cross-Account Observability. Quell-Accounts teilen Traces mit dem zentralen Monitoring-Account über OAM.
Warum: Ohne OAM fragmentieren Traces pro Account. Cross-Account-Aggregation zentralisiert die Ansicht des Request-Pfads.
Metriken + Logs + Traces aus mehreren Accounts in einer CloudWatch-Konsole anzeigen.
CloudWatch Observability Access Manager (OAM). Quell-Accounts verknüpfen sich mit einem Monitoring-Account über Sink + Link.
Warum: OAM ist das kanonische Multi-Account-Observability-Fabric. Eliminiert das Springen zwischen Konsolen pro Account.
Aurora-Cluster-Langsamkeit - Top-SQL nach Warteereignis identifizieren.
Performance Insights auf dem Cluster aktiviert. Top-SQL nach Last + Warteanalyse ohne Query-Log-Dump.
Warum: PI sampled Warteereignisse mit geringem Overhead. CloudWatch-Metriken sagen Ihnen, dass etwas langsam ist, PI sagt Ihnen, was.
Anomalien in DynamoDB / RDS / Lambda / ECS automatisch erkennen, ohne Alarmschwellenwerte zu schreiben.
Amazon DevOps Guru. ML-basierte Anomalieerkennung für Betriebsmetriken + korrelierte Ereignisse.
Warum: Statische Schwellenwerte verpassen seltene Modi. DevOps Guru lernt Baselines und alarmiert bei Abweichungen vom Normalen.
5.000 EC2-Instanzen nach einem Zeitplan patchen, ohne Skripte pro Instanz.
SSM Patch Manager mit Patch-Baselines + Wartungsfenstern. Tag-basiertes Targeting; Sicherheits-Patches nach N Tagen automatisch genehmigen.
Warum: Patch Manager zentralisiert den gesamten Patch-Lebenszyklus. Selbstverwaltete Skripte driften und verpassen neue Instanzen.
Config-Regel-Fehler (z.B. offene SG) automatisch beheben, ohne menschliche Genehmigung.
Config-Behebungsaktion, die ein SSM Automation-Dokument aufruft. Vorgefertigte `AWS-DisablePublicAccessForSecurityGroup` etc.
Warum: Config erkennt; SSM Automation handelt. Engere Schleife als SNS → Mensch → Ticket.
AMI/Container-Image Golden Pipeline muss reproduzierbar und aktuell sein.
EC2 Image Builder Pipeline. Source AMI → Recipe (Komponenten) → Test → Verteilung an Regionen/Accounts.
Warum: Ersetzt Ad-hoc-Packer-Skripte durch einen verwalteten Lebenszyklus. Neubauten für monatliche Patch-Aktualisierung planen.
Kontinuierliches CVE-Scannen über EC2 + ECR-Images + Lambda.
Amazon Inspector v2 mit organisationsweiter Aktivierung. Findings fließen zu Security Hub.
Warum: Inspector v2 deckt EC2 + Container-Images + Lambda-Abhängigkeiten in einem Service ab. Manuelles CVE-Matching ist im großen Maßstab unmöglich.
Validieren, dass eine Multi-Tier-App eine RTO von 1 Stunde / RPO von 15 Minuten erfüllen kann.
AWS Resilience Hub. Richtlinie definieren → App bewerten → Empfehlungen + automatisierte Runbooks.
Warum: Resilience Hub formalisiert RTO/RPO-Ansprüche mit konkreten Tests. Manuelle DR-Runbooks driften ab.
Testen, ob Auto-Scaling und Failover unter echten, nicht angenommenen, Fehlern funktionieren.
AWS Fault Injection Service (FIS). Templatisierte Experimente - Instanzen abschalten, APIs drosseln, Latenz injizieren. Während Game Days ausführen.
Warum: Chaos Engineering als Service. Echte Fehler decken brüchige Annahmen auf; das Lesen von Runbooks nicht.
Multi-Region-Failover - automatisierte Readiness Checks + zonale Evakuierung.
Route 53 Application Recovery Controller. Readiness Checks + Routing Controls für zellenbasiertes Failover.
Warum: Einfache Route 53 Health Checks bewerten Endpunkte. ARC fügt aktive/standby Control Planes für explizites, geprüftes Failover hinzu.
RDS-Major-Version-Upgrade mit Rollback-Möglichkeit.
RDS Blue/Green Deployments. Green-Klon mit neuer Version hochfahren; Binlog wiedergeben; in <1 Minute umschalten.
Warum: In-Place Major Upgrade ist irreversibel. Blue/Green hält die alte DB live, bis der Cutover erfolgreich ist.
Den Blast Radius von fehlerhaften Deployments mit automatischem Rollback reduzieren.
CodeDeploy mit Canary-Konfiguration (z.B. `CodeDeployDefault.ECSCanary10Percent5Minutes`). CloudWatch-Alarm löst Rollback aus.
Warum: Canary begrenzt den Schaden für 10% der Benutzer für 5 Minuten. All-at-once maximiert den Schaden; Rolling verteilt ihn, aber ohne traffic-basiertes Gate.
Lambda-Funktionen sind hinsichtlich des Speichers überdimensioniert.
Compute Optimizer für Lambda. Speicher-Tuning-Empfehlungen aus Invocation-Profilen.
Warum: AWS Lambda Power Tuning State Machine ist die Alternative - Compute Optimizer ist hands-off.
Least-Privilege-IAM-Richtlinie aus beobachteter CloudTrail-Aktivität generieren.
IAM Access Analyzer Policy Generation. Analysiert CloudTrail für die Rolle; gibt eine Richtlinie nur der verwendeten Aktionen aus.
Warum: Besser als manuelles Erstellen von `iam:Get*` etc. Die generierte Richtlinie als Ausgangspunkt verwenden, dann überprüfen.
Verbindung von EC2 zu RDS schlägt fehl - den Grund herausfinden ohne Packet Captures.
VPC Reachability Analyzer. Statische Analyse von Routing-Tabellen, SGs, NACLs, NAT, Peering. Liefert den Blocker.
Warum: Schneller als tcpdump. Identifiziert die spezifische Konfiguration (welche SG-Regel, welche NACL-Deny).
Überprüfen, welche Pfade aus dem Internet interne Ressourcen erreichen können.
VPC Network Access Analyzer. Scope-Ausdrücke beschreiben verbotene Pfade (z.B. Internet → DB-Tier). Gibt passende Pfade zurück.
Warum: Reachability Analyzer ist Punkt-zu-Punkt; Network Access Analyzer ist eine bereichsweite Compliance-Prüfung.
Schnelle Kostenvorteile in der gesamten Organisation.
Trusted Advisor Kostenoptimierungs-Checks (benötigt Business/Enterprise Support). Idle ELBs, gering ausgelastete EC2, ungenutzte EIPs, RI-Auslastung.
Warum: Der Free Tier von TA ist begrenzt; Business+ schaltet alle Checks frei. Die Org-Ansicht mit delegiertem Admin zeigt aggregierte Findings.
Lambda → RDS-Verbindungsstürme erschöpfen DB-Verbindungen.
RDS Proxy. Verbindungspooling zwischen Lambda und RDS/Aurora. Schnelleres Failover (~66% Reduktion).
Warum: Lambda-Concurrency erzeugt im schlimmsten Fall eine Verbindung pro Aufruf. Proxy multiplexed auf einen kleinen Pool.
Cache-Miss-Rate für Long-Tail-Inhalte am Origin zu hoch - Origin unter Last.
CloudFront Origin Shield in einer Region nahe dem Origin. Dedupliziert Anfragen über Edges hinweg, bevor sie den Origin erreichen.
Warum: Ohne Origin Shield verpasst jeder POP unabhängig zum Origin. Shield reduziert die Origin-Hit-Rate um ~70%.
200 On-Prem-Server mit minimaler Ausfallzeit per Lift-and-Shift zu EC2 migrieren.
AWS Application Migration Service (MGN). Kontinuierliche Block-Level-Replikation; Cutover pro Server in Minuten.
Warum: MGN ist das von AWS empfohlene Rehost-Tool (ersetzt SMS + CloudEndure). Der Cutover pro Server ermöglicht eine wellenbasierte Migration.
On-Prem Oracle zu Aurora PostgreSQL mit minimaler Ausfallzeit migrieren.
Schema Conversion Tool (SCT) für Schema- + Prozedur-Rewrite. AWS DMS für Full-Load + CDC.
Warum: SCT adressiert Code; DMS adressiert Daten. CDC hält die Quelle bis zum Cutover synchron.
Alle On-Prem-Datenbanken entdecken und die Migrationskomplexität bewerten.
AWS DMS Fleet Advisor. Inventarisierung + Bewertung heterogener Flotten in großem Maßstab.
Warum: Fleet Advisor konsolidiert Discovery + Sizing in einem Workflow, bevor DMS-Jobs gestartet werden.
500 Anwendungen für die Migrationsstrategie kategorisieren.
Seven Rs Framework: Retire (stilllegen), Retain (On-Prem behalten), Relocate (VMware Cloud Lift), Rehost (MGN), Replatform (RDS statt selbstverwalteter DB), Repurchase (verwerfen & SaaS), Refactor (Microservices).
Warum: Größere Portfolios mischen alle 7. Eine frühzeitige Zuordnung pro App vermeidet "One-Size-Fits-All"-Migrationsschulden.
Vor dem Start der Wellen das Migrationsinventar mit Abhängigkeiten erstellen.
AWS Application Discovery Service. Agentless (vCenter-Scan) oder Agent-basiert (pro Server). Gibt Abhängigkeitskarte aus.
Warum: Ohne Abhängigkeitsmapping verpasst die Wellenplanung enge Kopplungen. Discovery deckt sie automatisch auf.
Hunderte laufende Server- + DB-Migrationen über MGN, DMS, manuell verfolgen.
AWS Migration Hub als zentrale Übersicht. Aggregiert den Status von MGN, DMS, Refactor Spaces.
Warum: Konsolen pro Tool fragmentieren den Status. Migration Hub konsolidiert und unterstützt das Portfolio-Reporting.
100 TB von einem Remote-Standort ohne nutzbare WAN-Bandbreite verschieben.
AWS Snowball Edge Storage Optimized. Gerät versenden, lokal kopieren, an AWS zurücksenden. Mehrere Geräte parallel für >80 TB.
Warum: Snowmobile (45 PB) ist für Exabyte; Snowcone (8 TB) für winzige. Edge ist das Petabyte-Skala-Arbeitstier.
Kontinuierliche Datenreplikation On-Prem NFS → S3 mit Bandbreitenbeschränkungen.
AWS DataSync Agent. Geplante Aufgaben; Bandbreitenbegrenzung pro Aufgabe; Verify-Modus für Integrität.
Warum: DataSync ist zweckbestimmt und 10x schneller als selbstverwaltetes rsync über WAN. Snowball ist offline; DataSync ist online.
On-Prem-Anwendung erwartet NFS/SMB, aber Daten sollen in S3 landen.
File Gateway in Storage Gateway. Lokaler Cache + S3-Backend; Objekte auch über S3 API zugänglich.
Warum: Volume Gateway exponiert iSCSI; Tape Gateway emuliert VTL. File Gateway ist die NAS-zu-S3-Brücke.
VMware-lastige Unternehmen wünschen sich AWS-seitige Kapazität ohne Umstellung von vSphere/NSX.
VMware Cloud on AWS. Derselbe vSphere-Stack auf Bare-Metal-AWS-Hosts. HCX für Live-Migration verwenden.
Warum: Bewahrt operative Tools. Brücke vor Refaktor. Danach schrittweise Replatforming zu nativen AWS-Services.
Legacy Java/.NET-Monolithen ohne Neuschreiben containerisieren.
AWS App2Container CLI. Inspiziert laufende Anwendung, generiert Container-Artefakte + ECS/EKS-Manifeste.
Warum: A2C erfasst die Laufzeitkonfiguration (Umgebung, Ports, Abhängigkeiten) in einem funktionsfähigen Image. Manuelle Containerisierung verpasst nicht-offensichtliche Abhängigkeiten.
COBOL-Mainframe-Modernisierung - Umwandlung in Java-Microservices.
AWS Mainframe Modernization Service mit Blu Age (Refaktor) oder Micro Focus (Replatform). Wahl basierend auf Toleranz für Laufzeitemulation.
Warum: Refaktor schaltet Cloud-native Muster frei; Replatform ist schneller, emuliert aber den Mainframe. Beide reduzieren die Mainframe-Lizenzkosten.
Einen Monolithen über 18 Monate zerlegen, ohne die Entwicklung einzufrieren.
Strangler Fig Pattern. Den Monolithen mit API Gateway/ALB voranstellen; spezifische Endpunkte zu neuen Microservices routen, sobald diese herausgeschnitten wurden.
Warum: Big-Bang-Rewrites scheitern in der Regel. Strangler entkoppelt den Cutover nach Route, hält den Monolithen während des Übergangs funktionsfähig.
Möchte Microservices inkrementell extrahieren, ohne die Routing-Ebene zu besitzen.
AWS Migration Hub Refactor Spaces. Verwaltete Anwendungs-/Routen-/Dienst-Abstraktion über API Gateway + VPCs.
Warum: Spart das Schreiben der Infrastruktur der Strangler Fig. Vorgefertigtes Routing + VPC-Konnektivität für inkrementelle Extraktion.
Selbstverwaltetes PostgreSQL auf EC2 → RDS für Managed Ops.
DMS für Cutover mit CDC. RDS Custom nur verwenden, wenn Sie OS-Zugriff oder herstellerspezifische Erweiterungen benötigen.
Warum: RDS übernimmt Backups/Patches/HA. RDS Custom ist ein Notausgang für Legacy-Bedürfnisse, führt aber operative Lasten wieder ein.
Von RDS MySQL zu Aurora MySQL wechseln für Leistung + Kosten.
Aurora Read Replica von RDS, dann hochstufen. Oder DMS für Zero-Downtime, wenn Versionsunterschiede wichtig sind.
Warum: Read-Replica-Pfad ist der einfachste im Engine. DMS bewältigt Versionsunterschiede und heterogene Verschiebungen.
Unternehmen wünscht AWS-Migrationsfinanzierung + Best-Practice-Framework.
AWS Migration Acceleration Program (MAP). Phasen: Bewerten (MRA), Mobilisieren (MAP-Partner + Tools), Migrieren & Modernisieren.
Warum: MAP schaltet Finanzierung und strukturierte Methodik frei. Das Überspringen von MAP verpasst beides.
Vor-Migrations-Kostenschätzung für den Executive Sponsor.
AWS Pricing Calculator (designtes Konfiguration) + Migration Evaluator (datengesteuert aus On-Prem-Inventar).
Warum: Pricing Calculator liefert "Was-wäre-wenn"-Preise. Migration Evaluator nimmt vSphere/Hyper-V-Daten auf, um tatsächliche Einsparungen zu prognostizieren.
Selbst gehostete SFTP-Server stilllegen; Partner müssen weiterhin SFTP verwenden.
AWS Transfer Family (SFTP/FTPS/FTP) mit S3 oder EFS als Backend.
Warum: Verwalteter Protokolldienst. IAM-zugeordnete Benutzer; nur VPC-Endpunkte. Vermeidet das Betreiben von EC2 SSH-Daemons.
Windows-Dateifreigaben mit AD-Integration per Lift-and-Shift migrieren.
Amazon FSx for Windows File Server. AD-verbunden; SMB; DataSync für Online-Synchronisierung von On-Prem; Snowball für Bulk.
Warum: FSx for Windows ist die AD-native Landing Zone. EFS ist nur Linux; S3 fehlt SMB-Semantik.
NetApp ONTAP-Workloads migrieren und alle NetApp-Funktionen (Snapshots, FlexClone) beibehalten.
Amazon FSx for NetApp ONTAP. Native ONTAP-APIs; Multi-Protokoll NFS+SMB; SnapMirror-Replikation von On-Prem.
Warum: Andere FSx-Varianten exponieren keine ONTAP-spezifischen Funktionen. Lift-and-Shift NetApp ohne Neugestaltung von Backups/Replikation.
DNS-basierter Cutover birgt das Risiko von DNS-Cache-Verzögerungen.
Cutover hinter CloudFront / ALB / Global Accelerator. Backend wechseln, ohne öffentliches DNS zu ändern.
Warum: Caches respektieren TTL, aber Clients/Firewalls cachen aggressiv. Eine stabile öffentliche Adresse isoliert von DNS-Verzögerungen.
Schrittweise Traffic-Migration von On-Prem zu AWS zur Risikokontrolle.
Route 53 Weighted Routing. Start 1% → AWS, schrittweise erhöhen. Health Checks für automatisches Failback.
Warum: Weighted Routing ermöglicht Canary-ähnliche Migration auf DNS-Ebene. ARC fügt explizite Gates für risikoreichere Cuts hinzu.
Windows / Oracle / SQL Server BYOL-Lizenzen über migrierte Workloads hinweg verfolgen.
AWS License Manager. Regeln definieren; beim Start erzwingen; über RAM in der Organisation teilen.
Warum: BYOL-Nicht-Konformität ist teuer. License Manager verhindert versehentliche Überbereitstellung.
Nach der Migration sind Dev/Test RDS-Instanzen über Nacht überprovisioniert.
Dev/Test zu Aurora Serverless v2 mit niedrigem Min ACU migrieren. Automatisch herunterfahren, wenn im Leerlauf.
Warum: Spart nächtliche Leerlaufkosten ohne die Komplexität eines Instanz-Schedulers.
Kubernetes On-Prem mit denselben Tools wie EKS während der Migration ausführen.
EKS Anywhere auf On-Prem-Hardware. Dieselben Kubernetes-Versionen + ECR + AWS Outposts-Integration.
Warum: Eine konsistente Control Plane reduziert den Skill-Drift der Operatoren. Die spätere Migration zu EKS ist eine Workload-Verschiebung, keine Tooling-Neuschreibung.