Eine übersichtliche Referenz der Architekturmuster, die in der SAA-C03-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Sichere Architekturen entwerfen
Drei-Schichten-Anwendung: Web, App, DB. Die Datenbank muss unter allen Umständen vom Internet aus unerreichbar sein.
Öffentliche Subnetze für die Web-Schicht (ALB). Private Subnetze für die Anwendungs- und DB-Schichten. Die DB-Sicherheitsgruppe erlaubt den Traffic nur von der Sicherheitsgruppe der App-Schicht (nicht von CIDR-Bereichen).
Warum: Subnetz-Routing-Tabellen erzwingen die Erreichbarkeit; Referenzen zwischen Sicherheitsgruppen kodieren das Prinzip der geringsten Rechte auf der SG-Ebene und überleben IP-Änderungen.
EC2-Instanz muss auf S3 zugreifen. Eingebettete Anmeldeinformationen vermeiden.
IAM-Rolle über Instanzprofil angehängt. SDK ruft temporäre Anmeldeinformationen von IMDSv2 ab.
Warum: Langlebige Zugriffsschlüssel auf Instanzen sind die Hauptursache für das Durchsickern von Anmeldeinformationen. Rollen werden automatisch rotiert und nie dauerhaft gespeichert.
Dienst A in Konto A ruft Lambda in Konto B auf. Geringste Rechte.
Ressourcenbasierte Richtlinie für das Ziel-Lambda, die `lambda:InvokeFunction` dem Rollen-Principal von Konto A gewährt. Aufrufer übernimmt seine eigene Rolle und ruft direkt auf - keine Rollenverkettung erforderlich.
Warum: Ressourcenrichtlinien sind das einfachste kontoübergreifende Muster für dienstgesteuerte Ressourcen (Lambda, S3, SNS, SQS, KMS).
Andere AWS-Konten müssen in einen zentralen S3-Bucket hochladen.
Bucket-Richtlinie, die `s3:PutObject` externen Konto-Principals gewährt. `bucket-owner-full-control` ACL-Anforderung hinzufügen, damit der Bucket-Besitzer die Kontrolle über Objekte behält.
Warum: Ohne `bucket-owner-full-control` (oder `BucketOwnerEnforced` Object Ownership) gehören hochgeladene Objekte dem schreibenden Konto.
Entwickler müssen IAM-Rollen selbst bereitstellen können, aber keine Berechtigungen vergeben, die über ein definiertes Maximal-Berechtigungssatz hinausgehen.
Berechtigungsgrenzen für den Entwickler-Principal. Effektive Berechtigungen = Identitätsrichtlinie ∩ Grenze.
Warum: SCPs gelten auf Konto-/OU-Ebene; Grenzen begrenzen einzelne Principals. Verwenden Sie Grenzen für delegierte Administrator-Muster.
Eine OU auf bestimmte Regionen für die Einhaltung der Datenresidenz beschränken.
Service Control Policy in Organizations, die jede Aktion verweigert, bei der `aws:RequestedRegion` nicht in der zulässigen Liste enthalten ist.
Warum: SCPs sind der einzige Mechanismus, der Aktionen verweigern kann, die das Konto selbst zulässt. IAM kann nicht verweigern, was ein Konto-Root gewähren könnte.
Single Sign-On für Mitarbeiter über viele AWS-Konten hinweg; Integration mit dem Unternehmens-IdP.
AWS IAM Identity Center (ehemals AWS SSO) mit SAML/OIDC-Föderation zum Unternehmens-IdP. Berechtigungssätze werden Rollen in Mitgliedskonten zugeordnet.
Warum: Identity Center ist die kanonische Multi-Konto-Mitarbeiteridentität. Cognito ist für Anwendungs-Endbenutzer, nicht für Mitarbeiter.
User Pool = Registrierung / Anmeldung / JWT-Ausgabe für App-Benutzer. Identity Pool = Austausch von Tokens gegen temporäre AWS-Anmeldeinformationen. Die meisten Apps verwenden beides: User Pool authentifiziert, Identity Pool autorisiert AWS-Zugriff.
Volle Kontrolle über Schlüsselrotation, Löschung und Audit-Trail pro Schlüssel erforderlich.
Kundenverwalteter KMS-Schlüssel (CMK). AWS-verwaltete Schlüssel (`aws/<service>`) sind einfacher, bieten aber keine Kontrolle über die Schlüsselrichtlinie oder Einblick in die individuelle Schlüsselnutzung.
Warum: CMKs ermöglichen es Ihnen, den Zugriff pro Schlüssel in CloudTrail zu definieren, Schlüsselrichtlinien für die kontoübergreifende Nutzung festzulegen und die Löschung zu deaktivieren/zu planen.
Konto B muss S3-Objekte entschlüsseln, die mit dem CMK von Konto A verschlüsselt wurden.
Schlüsselrichtlinie auf dem CMK gewährt `kms:Decrypt` den Principals von Konto B. Das IAM von Konto B benötigt ebenfalls `kms:Decrypt` auf dem Schlüssel-ARN. Beide Hälften erforderlich.
Warum: KMS kontoübergreifend erfordert eine explizite Genehmigung sowohl in der Schlüsselrichtlinie als auch in der aufrufenden IAM-Identität (im Gegensatz zu den meisten Ressourcenrichtlinien).
Große Objekte verschlüsseln, ohne dass KMS-API-Aufrufe pro Objekt die Kosten dominieren.
Umschlagverschlüsselung (Envelope Encryption). KMS generiert einen Datenschlüssel (ein API-Aufruf); verwenden Sie den Datenschlüssel, um die Nutzdaten lokal zu verschlüsseln; speichern Sie den verschlüsselten Datenschlüssel zusammen mit dem Chiffretext.
Warum: KMS ist ratenbegrenzt und wird pro Anfrage abgerechnet. Das Umschlag-Muster ist die kanonische Methode, um Daten > weniger KB zu verschlüsseln.
Warum: Secrets Manager verfügt über integrierte Rotations-Lambdas für RDS/Aurora/DocumentDB/Redshift; Parameter Store hat keine native Rotation, ist aber im Standard-Tarif kostenlos.
Secrets Manager mit verwalteter Rotation. Integrierte Lambda-Vorlage handhabt die Rotation eines einzelnen Benutzers gegen den RDS-Endpunkt. Apps rufen das Secret zur Verbindungszeit ab (zwischengespeichert) - keine erneute Bereitstellung der App.
Layer-7-HTTP-Flood abmildern, ohne legitime Spitzen zu blockieren.
AWS WAF ratenbasierte Regel (z.B. 2000 Anfragen / 5 Min pro IP) auf dem ALB oder CloudFront. Kombinieren mit verwalteten Regelgruppen für bekannte schlechte IPs.
Warum: WAF-Ratenregeln verfolgen pro Quell-IP; automatische Blockierung, wenn der Schwellenwert überschritten wird; Freigabe nach dem Fenster.
Missionskritische Anwendung benötigt DDoS-Kostenschutz und 24×7 SRT-Support.
AWS Shield Advanced auf CloudFront / ALB / NLB / Global Accelerator. Enthält Kostenschutz (Rückerstattungen für Skalierungsausgaben während eines Angriffs) + Zugang zum Shield Response Team.
Warum: Shield Standard ist automatisch und kostenlos; Advanced fügt Schutz und SLA hinzu. CloudFront ist immer die empfohlene "Haustür".
Stateful, an ENI anhängen, nur zulassen → Sicherheitsgruppe (Standard). Stateless, Subnetz-Ebene, zulassen + explizit ablehnen → NACL. NACLs für pauschale Ablehnungsregeln verwenden (IP-Bereiche blockieren); SGs für alles andere.
Warum: NACLs bewerten eingehenden und ausgehenden Datenverkehr getrennt. SGs erlauben den Rückverkehr automatisch.
Hybride Konnektivität, die vorhersagbare Bandbreite, geringe Latenz und Verschlüsselung benötigt.
Direct Connect mit einem Site-to-Site VPN über DX (MACsec oder IPsec). DX allein ist unverschlüsselt; VPN über DX ist privat + verschlüsselt + jitterarm.
Warum: Einfaches VPN über das Internet ist günstig, hat aber variable Latenz. DX allein ist schnell, aber im Klartext auf der Verbindungsschicht.
Ein einziges manipulationssicheres Audit-Log über alle Konten in der Organisation.
Organisationstrail mit aktivierter Logdatei-Validierung, geschrieben in einen zentralen S3-Bucket mit einer Bucket-Richtlinie, die das Löschen verweigert.
Warum: Org-Trails werden in allen Mitgliedskonten (aktuelle und zukünftige) automatisch aktiviert. Validierungshashes beweisen, dass Logs nicht geändert wurden.
PCI DSS-Workload - strikte Isolation von Nicht-PCI-Konten.
Dediziertes AWS-Konto innerhalb einer Organizations OU mit SCPs, die den Dienst-/Regionenzugriff einschränken. Separate VPC, KMS-Schlüssel, IAM-Rollen. Network Firewall oder GWLB für die Ausgangsinspektion.
Warum: Kontogrenze ist die stärkste Isolation des Blast Radius in AWS.
Öffentliches TLS-Zertifikat für `*.example.com` auf ALB und CloudFront. Automatische Verlängerung.
Öffentliches AWS Certificate Manager (ACM)-Zertifikat mit DNS-Validierung in Route 53. Verlängert sich automatisch 60 Tage vor Ablauf.
Warum: Kostenlos für die Verwendung mit AWS-integrierten Diensten. E-Mail-Validierung funktioniert, aber DNS-Validierung wird für die Automatisierung bevorzugt.
Produktions-RDS-Datenbank mit Failover in unter einer Minute.
RDS Multi-AZ-Bereitstellung (oder Multi-AZ DB-Cluster). Synchrone Replikation zum Standby; automatisches Failover über DNS-Endpunktschalter.
Warum: Multi-AZ ist für HA, nicht für Leseskalierung. Read Replicas sind für die Skalierung von Lesevorgängen (und asynchron; potenzielle Verzögerung).
Aurora vs. RDS für eine neue MySQL/PostgreSQL-Workload auswählen.
Aurora für höheren Durchsatz, schnelleres Failover, bis zu 15 Read Replicas, Global Database, Serverless v2. RDS für ältere Engines (MariaDB, Oracle, SQL Server) oder einfachere/günstigere Bereitstellungen.
Warum: Aurora-Speicher wird über Replikate geteilt (keine Replikatverzögerung durch den Speicher). Failover typischerweise < 30s.
Aktiv-passive Multi-Region-Datenbank mit < 1s Replikationsverzögerung und < 1 min RTO.
Aurora Global Database. Speicherbasierte Replikation in bis zu 5 sekundäre Regionen; im Katastrophenfall eine sekundäre zu primären hochstufen.
Warum: Die Replikation verwendet dedizierte Infrastruktur; die regionsübergreifende Verzögerung beträgt typischerweise < 1s. Read Replicas in entfernten Regionen für lokale Lesevorgänge mit geringer Latenz.
Variable / unvorhersehbare Datenbanklast mit Leerlaufzeiten.
Aurora Serverless v2. Skaliert in 0,5 ACU-Schritten; Skalierungsereignisse in unter einer Sekunde; keine vollständige Pause, aber sehr niedriges Minimum.
Warum: v2 hält die Verbindung während Skalierungsereignissen offen (im Gegensatz zu v1). Abrechnung pro ACU-Sekunde.
Beim Scale-In laufende Arbeiten abfließen lassen und Logs vor Instanzbeendigung beibehalten.
Auto Scaling Lifecycle Hook in `Terminating:Wait`. Der Hook veröffentlicht an SNS/EventBridge; der Handler schließt den Drain ab und ruft `complete-lifecycle-action` auf.
HTTP/HTTPS, Pfad-/Host-Routing, WAF-Integration, OIDC-Authentifizierung → ALB. TCP/UDP/TLS bei extremer Skalierung, statische IP pro AZ, geringste Latenz, Erhaltung der Client-Quell-IP → NLB.
„Poison Messages“ lassen Handler immer wieder fehlschlagen und sich erneut einreihen.
SQS Dead-Letter Queue. `maxReceiveCount` für die Quellwarteschlange konfigurieren; Nachrichten, die die Anzahl überschreiten, werden zur Inspektion in die DLQ verschoben.
Strenge Reihenfolge und genau einmalige Verarbeitung pro Nachrichtengruppe.
SQS FIFO-Warteschlange mit inhaltsbasierter Deduplizierung oder expliziter `MessageDeduplicationId`. `MessageGroupId` für parallele geordnete Gruppen verwenden.
Warum: Standard SQS ist mindestens einmal mit keiner Ordnungsgarantie. FIFO hat einen geringeren Durchsatz, es sei denn, der Hochdurchsatzmodus wird verwendet.
Asynchrones Lambda schlägt bei Downstream-Timeout fehl - fehlgeschlagene Ereignisse zur Wiederholung erfassen.
Lambda Destinations: Fehlerziel als SQS / SNS / EventBridge / ein anderes Lambda konfigurieren. Erfolgsziele werden ebenfalls unterstützt.
Warum: Sauberer als DLQ auf der Funktion: Destinations erhalten das vollständige Ereignis + die Antwortnutzdaten; DLQs erhalten nur das Auslöseereignis.
CloudFront-Origin (S3 oder ALB) fällt aus - Rückgriff auf einen sekundären Origin ohne DNS-Änderungen.
CloudFront-Origin-Gruppe mit primärem + sekundärem Origin. Failover-Kriterien konfigurieren (4xx/5xx-Codes). CloudFront wiederholt den Versuch mit dem sekundären Origin.
S3-Objekte vor versehentlichem Löschen und Ransomware-Überschreiben schützen.
S3-Versioning + MFA Delete + Object Lock (Governance- oder Compliance-Modus) auf kritischen Buckets aktivieren.
Warum: Versioning bewahrt Überschreibungen/Löschungen; Object Lock blockiert Löschungen vor der Aufbewahrung; MFA Delete fügt einen zweiten Faktor für die endgültige Entfernung hinzu.
Globale App benötigt Zero-RTO-Failover über zwei Regionen hinweg.
Aktiv-aktiv über Regionen hinweg: Global Accelerator oder Route 53 Latenz-Routing für den Ingress; DynamoDB Global Tables / Aurora Global Database für Daten; regionsübergreifende Replikation für Objektspeicher.
Lambda verarbeitet Bestellungen von SQS - Nachricht kann zweimal zugestellt werden.
Idempotenz: Request-Hash in DynamoDB mit TTL speichern; PUT-IfNotExists bei jedem Wiederholungsversuch. Oder FIFO-Warteschlange mit Deduplizierung verwenden.
Mehrere EC2-Instanzen müssen dasselbe Block-Volume lesen und schreiben.
EBS Multi-Attach mit io2 / io1 (nur Nitro-Instanzen). Gleichzeitige Anbindung an bis zu 16 Instanzen in derselben AZ.
Warum: Die Anwendung muss Schreibvorgänge koordinieren (Cluster-Dateisystem). EFS ist der Standard für den gemeinsamen Dateizugriff; Multi-Attach ist für geclusterte DBs, die Blockzugriff benötigen.
Statische Assets + API-Antworten mit globalen Benutzern; Origin-Last reduzieren.
CloudFront mit geeigneter Cache-Richtlinie. Lange TTLs für statische Inhalte; Cache-Schlüssel enthält nur wesentliche Header/Abfrageparameter. Origin Shield für Origins mit hoher Kardinalität verwenden.
Warum: Die Cache-Trefferquote beeinflusst sowohl Leistung als auch Kosten. Ein falscher Cache-Schlüssel (z.B. alle Header einschließen) zerstört die Trefferquote.
Lazy Loading (Cache-Fehler → abrufen + füllen): einfach, cacht nur das Angefragte. Write-Through (auf Cache + DB bei Update schreiben): Cache immer frisch, aber zusätzliche Schreibvorgänge. TTL: Begrenzt die Veraltung bei beiden Mustern.
Ereignisgesteuert unter 15 Minuten, Skalierung unter einer Sekunde, keine Infrastruktur → Lambda. Langlebige Container, keine Knotenverwaltung → Fargate. Benutzerdefinierter Kernel, GPU, persistenter Zustand, am günstigsten dauerhaft → EC2.
Bereitgestellte Parallelität (Provisioned Concurrency). Vorab aufgewärmte Umgebungen, bereit für Aufrufe bei jedem Durchsatz. Kombinieren mit Application Auto Scaling für geplante Hochskalierung.
Warum: Kostet mehr als On-Demand, eliminiert aber den Kaltstart. Nicht erforderlich für konstanten Datenverkehr, bei dem die Auslastung der bereitgestellten Parallelität natürlich hoch bleibt.
Athena-Abfragen scannen Terabytes; Kosten / Zeit übermäßig.
Daten nach Abfrageprädikat partitionieren (Datum, Region). In Parquet/ORC-Spaltenformat konvertieren. Partitions-Projektion verwenden, um Katalog-Round-Trips zu vermeiden.
Warum: Athena berechnet pro gescanntem TB. Spaltenformat + Partitionierung reduziert die Kosten oft um das 10- bis 100-fache.
Unvorhersehbare / spitzenartige / neue Workloads → On-Demand. Konstante, vorhersehbare, häufig genutzte - und kostensensitive → Provisioned mit Auto-Skalierung. Moduswechsel höchstens einmal pro 24 Stunden.
DynamoDB nach einem Attribut abfragen, das nicht der Partitionsschlüssel ist.
Global Secondary Index (GSI) für Abfragen nach einem anderen Partitionsschlüssel. Local Secondary Index (LSI) für einen alternativen Sortierschlüssel auf demselben Partitionsschlüssel (LSI muss zum Zeitpunkt der Tabellenerstellung erstellt werden).
EC2-Kaufoption für eine konstante 24×7-Flotte auswählen.
Compute Savings Plan (1 Jahr oder 3 Jahre) - 66% Rabatt auf den Listenpreis, flexibel über Instanzfamilie, Größe, OS, Tenancy, Region. RIs nur, wenn Kapazitätsreservierung erforderlich ist.
Warum: Savings Plans dominieren RIs für die meisten reinen Kosten-Anwendungsfälle (flexibler, gleicher Rabatt).
Spot für Kosteneinsparungen bei toleranten Workloads nutzen.
Spot über ASG Mixed-Instances-Richtlinie mit kapazitätsoptimierter Zuweisungsstrategie + mehreren Instanztypen. 2-minütige Unterbrechungsbenachrichtigung über Instanzmetadaten behandeln.
Warum: Kapazitätsoptimiert wählt Pools aus, die am wenigsten wahrscheinlich zurückgefordert werden. Mehrere Typen diversifizieren das Pool-Risiko.
Zu Graviton (ARM64)-Instanzen migrieren. Ca. 20% günstiger, ca. 40% besseres Preis-Leistungs-Verhältnis für viele Workloads. Erfordert Multi-Arch-Container-Images oder neu kompilierte Binärdateien.
Arbeitsspeicher erhöhen (was CPU und Netzwerk proportional skaliert). Lambda Power Tuning (Step Functions Tool) verwenden, um den optimalen Punkt zu finden - oft ist mehr Arbeitsspeicher schneller UND günstiger.
Logs und alte Objekte sammeln sich in S3 Standard an.
S3 Lifecycle-Regeln: Übergang zu IA nach 30 Tagen, Glacier Flexible nach 90 Tagen, Deep Archive nach 180 Tagen, Ablauf nach Aufbewahrungszeit. Kombinieren mit Intelligent-Tiering für unbekannte Muster.
S3-Ausgaben über Konten hinweg visualisieren; Optimierungskandidaten finden.
S3 Storage Lens. Organisationsweites Dashboard mit Nutzung, Aktivität, Kosteneinsparungsempfehlungen. Erweiterter Metrik-Tier für Aufschlüsselung auf Präfixebene.
NAT Gateway Datenverarbeitungsgebühren dominieren die Rechnung.
AWS-Dienst-Traffic durch VPC-Endpunkte ersetzen (Gateway für S3/DynamoDB; Interface für alles andere). Workloads, die Internet-Egress benötigen, nur bei Bedarf in öffentliche Subnetze verschieben.
Warum: NAT Gateway berechnet pro verarbeitetem GB, selbst für AWS-Dienst-Traffic. Endpunkte eliminieren diesen Pfad.
Gleiche AZ, gleiche VPC = kostenlos. Cross-AZ = 0,01 $/GB pro Richtung. Cross-Region = teuer. Egress ins Internet = am teuersten, aber kostenlos über CloudFront für cachefähigen Inhalt. Immer über CloudFront ausleiten, wenn möglich.
Explizite Aufbewahrung festlegen (Standard ist "Nie ablaufen"). Alte Logs nach S3 + Glacier exportieren. Logs Insights nur für warme Daten verwenden. Am Agent filtern (keine Debug-Logs in Produktion versenden).
Unkontrollierte Ausgaben in einem Sandbox-Konto stoppen.
AWS Budgets mit Aktion: bei 80% Schwellenwert eine SNS-Benachrichtigung ausführen; bei 100% eine ablehnende SCP / IAM-Richtlinie über Budgets Action anhängen.
Kostenverrechnung pro Team oder Produkt ohne separate Konten.
Kostenallokations-Tags. Benutzerdefinierte Tags in der Abrechnungskonsole aktivieren; in Cost Explorer + CUR anzeigen. Kombinieren mit `aws:CreatedBy` zur Identitätszuordnung.
Dev/Test EC2-Instanzen laufen 24×7 - werden nur von 9 bis 17 Uhr genutzt.
AWS Instance Scheduler (CloudFormation-bereitgestellte Lambda-Funktion). Instanzen mit Zeitplannamen taggen; führt Cron-ähnliches Starten/Stoppen aus. Oder einfach `aws:autoscaling:scheduledActions` auf Dev-ASGs.
Warum: Ca. 70% Reduzierung der Entwicklungskosten für Rechenleistung durch Stoppen außerhalb der Betriebszeiten.
RDS-Instanz stoppen (Einzel-AZ; bis zu 7 Tage, dann startet sie automatisch). Oder Aurora Serverless v2 mit min ACU = 0,5 (kein vollständiger Stopp, aber minimale Kosten im Leerlauf).
Konstante, hohe Auslastung → ECS auf EC2 (mit Spot/Savings Plans) - am günstigsten. Spitzenartige / kurzlebige / keine Knotenverwaltung → Fargate. Fargate Spot ist 70% günstiger als Fargate für tolerante Workloads.
Mit CloudFront voranstellen. Origin → Edge-Übertragung ist kostenlos; Edge → Benutzer ist günstiger als direkter EC2/S3-Egress im großen Maßstab. Komprimierung + geeignete TTLs aktivieren.
Mehr als 1 PB von On-Premises nach AWS verschieben; Bandbreite zu langsam für Online-Übertragung.
AWS Snow Family. Snowball Edge Storage Optimized (80 TB) für typische Fälle; mehrere Geräte parallel für 100er von TB. Snowmobile ist ausgemustert - für Petabyte-Skala mehrere Snowballs verwenden.