🏠Startseite 📚Zertifizierungen 📱Mobile Apps

🎓Prüfungsinfo

✍️Blog 📊Fortschritt 📅Kalender 💬Support

Datenschutzrichtlinie Nutzungsbedingungen Kontakt Cookie-Richtlinie Haftungsausschluss Barrierefreiheit DMCA / Urheberrecht

Zum Inhalt springen

SAA-C03Handbuch

Handbuch

AWS Certified Solutions Architect Associate

Zuletzt überprüft: Mai 2026

Eine übersichtliche Referenz der Architekturmuster, die in der SAA-C03-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.

Abschnitte

Sichere Architekturen entwerfen34 Einträge
Resiliente Architekturen entwerfen28 Einträge
Hochleistungsarchitekturen entwerfen26 Einträge
Kostenoptimierte Architekturen entwerfen24 Einträge

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.

SSRF-Angriffe blockieren, die versuchen, EC2-Instanzmetadaten zu lesen.

IMDSv2 (`HttpTokens=required`) beim Start der Instanz erzwingen. Unauthentifizierte IMDSv1-Anfragen ablehnen.

Warum: IMDSv2 erfordert ein Sitzungstoken über PUT, bevor der Metadaten-Endpunkt antwortet; SSRF-Angriffe, die nur GETs durchführen, werden blockiert.

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.

Verhindern, dass S3-Buckets in der Organisation öffentlich gemacht werden.

S3 Block Public Access auf Kontoebene aktivieren (und organisationsweit über SCPs). Überschreibt Bucket-Level-ACLs und -Richtlinien.

Warum: Die Einstellung auf Kontoebene hat Vorrang vor Einstellungen pro Bucket — Abwehr gegen versehentliche Fehlkonfiguration.

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.

Cognito User Pool vs. Identity Pool auswählen.

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.

Benutzerdefinierten Validierungsschritt zum Cognito-Anmeldevorgang hinzufügen (z.B. E-Mail-Domain auf Whitelist setzen).

Lambda-Trigger: Pre Sign-up, Pre Authentication, Define/Create/Verify Auth Challenge. Validieren oder ablehnen in der Lambda-Funktion.

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).

Daten in `us-east-1` verschlüsseln; nach der Replikation in `us-west-2` entschlüsseln, ohne neu zu verschlüsseln.

KMS Multi-Region-Schlüssel. Primär in einer Region, Replikat in einer anderen, beide mit dem gleichen Schlüsselmaterial und derselben ID.

Warum: Vermeidet das erneute Umschließen des Chiffretextes bei regionsübergreifendem Failover oder DR.

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.

Secrets Manager vs. SSM Parameter Store SecureString auswählen.

DB-Anmeldeinformationen mit automatischer Rotation, kontoübergreifender Freigabe, großen Secrets → Secrets Manager. Konfigurations-Flags, App-Einstellungen, einfache Secrets, geringste Kosten → SSM Parameter Store.

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.

RDS-Passwort alle 30 Tage automatisch rotieren.

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".

Sicherheitsgruppe vs. NACL auswählen.

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.

EC2 in privatem Subnetz muss S3/DynamoDB ohne NAT-Ausgangskosten erreichen.

VPC-Gateway-Endpunkt für S3 und DynamoDB. Kostenlos, Routing-Tabellen-Eintrag, kein NAT.

Warum: Gateway-Endpunkte sind nur für S3/DynamoDB. Spart NAT-Datenverarbeitungsgebühren und hält den Datenverkehr im AWS-Backbone.

Privates Subnetz muss AWS-Dienst-APIs (KMS, Secrets Manager, ECR usw.) privat erreichen.

VPC-Interface-Endpunkt (PrivateLink) pro Dienst. ENI in Ihrer VPC, Abrechnung pro Stunde + pro GB.

Warum: Interface-Endpunkte funktionieren für fast jeden AWS-Dienst. Verwenden Sie diese, um den NAT-Ausgang für Dienstaufrufe zu eliminieren.

SaaS-Anbieter stellt seinen In-VPC-Dienst Kundenkonten privat zur Verfügung, ohne VPC-Peering oder die Notwendigkeit, Kunden-Routing zu pflegen.

AWS PrivateLink-Endpunktdienst, unterstützt durch einen NLB. Kunden erstellen Interface-Endpunkte zur Nutzung.

Warum: Keine CIDR-Überlappungsprobleme, kein Peering-Meshing, einseitige Exposition (Anbieter sieht keinen Kundenverkehr).

Mehr als 30 VPCs kontoübergreifend und On-Premises in einer Hub-and-Spoke-Topologie verbinden.

AWS Transit Gateway. Einzelner Anhang pro VPC; Routing-Tabellen segmentieren den Datenverkehr.

Warum: Full-Mesh-Peering erfordert N×(N-1)/2 Verbindungen. TGW skaliert linear und unterstützt kontoübergreifend über RAM.

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.

Kontinuierliche Bedrohungserkennung über VPC Flow Logs, DNS, CloudTrail, EKS-Audit, S3-Datenereignisse hinweg.

Amazon GuardDuty. Organisationsweit über delegierten Administrator von Organizations.

Warum: Verwaltete Bedrohungserkennung. Ergebnisse in Security Hub oder EventBridge zur Automatisierung der Reaktion.

PII / PHI in S3-Buckets entdecken und klassifizieren.

Amazon Macie. ML-basierte Erkennung sensibler Daten, S3-bezogen, integriert mit Security Hub.

Kontinuierliches CVE-Scanning für EC2, ECR-Images, Lambda-Funktionen.

Amazon Inspector v2. Erkennt Ressourcen automatisch über den Systems Manager Agent und scannt gegen veröffentlichte CVEs.

Ergebnisse von GuardDuty, Inspector, Macie, IAM Access Analyzer in einem Dashboard zusammenfassen.

AWS Security Hub. CSPM mit AWS Foundational Security Best Practices und CIS-Standards.

Durchsetzen, dass alle EBS-Volumes verschlüsselt sind; nicht-konforme Ressourcen automatisch beheben.

AWS Config-Regeln (verwaltetes `encrypted-volumes`) + Systems Manager Automation-Runbook zur Behebung, ausgelöst über Config-Behebungsaktion.

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.

Mehrere Abteilungen benötigen bereichsbezogenen Zugriff auf verschiedene Präfixe in einem gemeinsamen S3-Bucket.

S3 Access Points — eine pro Abteilung, jede mit ihrer eigenen Zugriffsrichtlinie und (optional) VPC-Einschränkung.

Warum: Sauberer als eine ausufernde Bucket-Richtlinie; Access Points haben ihre eigenen ARNs und DNS-Namen.

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.

Resiliente Architekturen entwerfen

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.

Lesen und Schreiben im einstelligen ms-Bereich in 3+ Regionen, mit Last-Writer-Wins-Replikation.

DynamoDB Global Tables. Multi-aktive Replikation mit Last-Writer-Wins-Konfliktlösung.

Warum: Aktiv-aktiv in jeder Region; kein Leader. Verwenden, wenn Anwendungs-Level-Konflikttoleranz akzeptabel ist.

Eine DynamoDB-Tabelle nach versehentlichem Löschen auf einen bestimmten Zeitpunkt innerhalb der letzten 35 Tage wiederherstellen.

Point-in-Time Recovery (PITR) aktivieren. Die Wiederherstellung erstellt eine neue Tabelle zum gewählten Zeitpunkt.

Datenverkehr zur primären Region leiten; bei Fehler der Gesundheitsprüfung auf sekundäre Region umschalten.

Route 53 Failover-Routing-Richtlinie. Aktive Gesundheitsprüfung am primären Endpunkt; sekundärer Eintrag dient, wenn primärer ungesund ist.

Warum: Anwendungsschicht-Gesundheitsprüfung (HTTP-Pfad) erfasst Teilausfälle, die TCP-Probes übersehen.

Jeden Benutzer an die gesunde Region mit der geringsten Latenz senden.

Route 53 latenzbasiertes Routing. Gesundheitsprüfung jedes Endpunkts; Route 53 liefert die gesunde Antwort mit der geringsten Latenz pro Anfrage.

Canary-Rollout: 10% an v2 senden, 90% an v1.

Route 53 gewichtetes Routing. Zwei Einträge mit gleichem Namen, unterschiedlichen Zielen, Gewichten 10 und 90.

EC2-Instanzen benötigen 3 Minuten zum Initialisieren; Skalierung ist bei Verkehrsspitzen zu langsam.

Auto Scaling Warm Pool. Vorinitialisierte Instanzen werden gestoppt gehalten (günstiger), um in Sekunden zu starten.

Warum: Kaltstart + Bootstrap ist der langwierige Teil. Warm Pool verlagert diese Arbeit aus dem kritischen Pfad.

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.

Rechenkosten für eine nicht-kritische Flotte senken, die Unterbrechungen toleriert.

ASG mit Mixed-Instances-Richtlinie: Basiskapazität auf On-Demand, zusätzliche Kapazität auf Spot, mehrere Instanztypen und AZs zur Diversifizierung.

Warum: Diversifizierung über Instanztypen reduziert das Spot-Unterbrechungsrisiko im Vergleich zu einem einzelnen Pool.

ALB vs. NLB auswählen.

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.

Eine Flotte von Drittanbieter-Sicherheits-Appliances zur Datenverkehrsinspektion über VPCs hinweg einschleusen.

Gateway Load Balancer (GWLB) mit Appliance-Flotte als Zielen. Datenverkehr über GENEVE gekapselt; transparente Einschleusung über Routing.

„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.

Mehrstufiger Workflow benötigt Wiederholung pro Aufgabe mit exponentiellem Backoff und Fehlererfassung.

AWS Step Functions Standard-Workflow. `Retry`-Block mit `IntervalSeconds`, `MaxAttempts`, `BackoffRate`. `Catch`-Block leitet spezifische Fehler an einen Wiederherstellungszustand weiter.

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.

Backups über EBS, RDS, DynamoDB, EFS, FSx mit einer einzigen Aufbewahrungsrichtlinie zentralisieren.

AWS Backup mit Backup-Plänen + Ressourcenauswahl per Tag. Kontoübergreifende / regionsübergreifende Kopie unterstützt. Vault Lock für Compliance-Unveränderbarkeit.

Ransomware-resistente Backups: Selbst ein Administrator kann sie vor der Aufbewahrung nicht löschen.

AWS Backup Vault Lock im Compliance-Modus. WORM-Erzwingung; selbst der Root-Benutzer kann die Aufbewahrungsdauer nicht verkürzen.

Ein DR-Muster nach RPO/RTO-Anforderung auswählen.

Backup & Restore: RPO Stunden, RTO Stunden, am günstigsten. Pilot Light: RPO Minuten, RTO 10er-Minuten. Warm Standby: RPO Sekunden, RTO Minuten. Multi-Site Active-Active: RPO ~null, RTO Sekunden, am teuersten.

Kritischen Bucket regionsübergreifend für DR mit RPO unter 15 Minuten replizieren.

S3 Cross-Region Replication (CRR) mit S3 Replication Time Control (RTC). 99,99% der Objekte in 15 Min.

Warum: Standard CRR ist Best-Effort. RTC fügt eine SLA + Replikationsmetriken in CloudWatch hinzu.

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.

TCP/UDP-Verkehr mit geringem Jitter zur nächsten gesunden Region; statische Anycast-IPs.

AWS Global Accelerator. Zwei Anycast-IPs; leitet über das AWS-Backbone zum nächsten Endpunkt.

Warum: Besser als Route 53 Latenz für Nicht-HTTP. Schnelleres Failover (Anycast) + statische IP-Whitelisting.

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.

Freiwillige Pod-Evictions (Node Drain, Cluster Autoscaler) legen alle Replikate einer Bereitstellung still.

Kubernetes PodDisruptionBudget, das `minAvailable` oder `maxUnavailable` spezifiziert. Cluster respektiert dies bei freiwilligen Unterbrechungen.

Hochleistungsarchitekturen entwerfen

Eine S3-Speicherklasse auswählen.

Häufiger Zugriff → Standard. Unbekanntes Zugriffsmuster → Intelligent-Tiering. 30+ Tage seltener Zugriff → Standard-IA. Einzelne AZ akzeptabel, seltener Zugriff → One Zone-IA. Archiv, ms-Abruf → Glacier Instant. Archiv, Minuten → Glacier Flexible. Archiv, Stunden, am günstigsten → Glacier Deep Archive.

Bucket mit gemischtem Zugriff und unvorhersehbaren Mustern; Kosten automatisch optimieren.

S3 Intelligent-Tiering. Überwacht den Zugriff; verschiebt Objekte automatisch über Tiers (Häufig / Selten / Archiv Instant / Archiv / Deep Archive). Keine Abrufgebühren.

Warum: Geringe Überwachungsgebühr pro Objekt, aber günstiger als falsch zu raten. Standard für unbekannte Muster.

Große Objekte (> 100 MB) zuverlässig und schnell über das Internet hochladen.

S3 Multipart Upload (parallele Teile) + S3 Transfer Acceleration (CloudFront Edge-Ingestion).

Warum: Parallele Teile sättigen die Bandbreite; Transfer Acceleration verlagert den WAN-Hop in das AWS-Backbone.

EBS-Volume-Typ auswählen.

Allgemein, Standard → gp3 (3000 Basis-IOPS, 125 MB/s; anpassbar). Datenbank mit hohen IOPS → io2 Block Express. Big-Data sequentieller Durchsatz → st1. Kaltarchiv → sc1. Boot-Volumes → gp3.

Warum: gp3 entkoppelt IOPS/Durchsatz von der Größe; günstiger als gp2 bei gleicher Leistung.

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.

Ein freigegebenes Dateisystem auswählen.

POSIX-konformes Linux NFS, Multi-AZ, Auto-Skalierung → EFS. Windows SMB / AD-integriert → FSx for Windows. HPC, Lustre, S3-verknüpft → FSx for Lustre. NetApp ONTAP-Funktionen (Snapshots, NetApp-Tools) → FSx for ONTAP. ZFS → FSx for OpenZFS.

EFS — Durchsatzmodus auswählen.

Variable Arbeitslast, skaliert mit Größe → Bursting. Vorhersehbarer hoher Durchsatz → Provisioned. Burst-empfindlich, aber elastische Ausgaben gewünscht → Elastic (Standard für neue Dateisysteme, skaliert automatisch).

On-Premises Datei-/Block-/Tape-Backup, das mit S3 / Glacier integriert ist.

AWS Storage Gateway: File Gateway (NFS/SMB → S3), Volume Gateway (iSCSI → S3 + EBS-Snapshots), Tape Gateway (VTL → Glacier).

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.

Anfrage/Antwort am Edge manipulieren.

Leichtgewichtig, Viewer-seitig, Sub-ms (Header-Umschreibungen, Umleitungen, A/B) → CloudFront Functions. Schwerer, Node.js / Python, längere Rechenzeit, Netzwerkzugriff → Lambda@Edge.

ElastiCache Redis vs. Memcached auswählen.

Replikation, Persistenz, Pub/Sub, geordnete Sets, Multi-AZ-Failover → Redis. Multi-threaded, einfacher Schlüssel/Wert, nur horizontale Sharding → Memcached.

Redis-Session-Store benötigt HA mit automatischem Failover über AZs hinweg.

ElastiCache for Redis Replikationsgruppe mit Multi-AZ + automatischem Failover aktiviert. Primär in einer AZ, Replikate in anderen.

DynamoDB-Leselatenz im Mikrosekundenbereich; Cache ohne App-Änderungen.

DynamoDB Accelerator (DAX). In-VPC verwalteter Cache; gleiches DynamoDB SDK; transparente Read-Through-Funktion.

Warum: ElastiCache erfordert Anwendungs-Level-Cache-Logik. DAX ist ein Drop-in für DynamoDB.

Eine Cache-Strategie auswählen.

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.

Eine Compute-Plattform auswählen.

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.

Lambda Java Kaltstart beeinträchtigt p99-Latenz.

Lambda SnapStart (Java, Python, .NET). Snapshot der initialisierten Laufzeit wird bei Aufruf wiederhergestellt; bis zu 10-mal schnellerer Kaltstart.

Vorhersehbare Burstanlast; Kaltstarts inakzeptabel.

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.

API Gateway-Typ auswählen.

Voller Funktionsumfang (Anfragevalidierung, Transformationen, API-Schlüssel, Nutzungspläne) → REST API. Geringere Kosten, geringere Latenz, native JWT/OIDC-Unterstützung, einfacher → HTTP API. Echtzeit bidirektional → WebSocket API.

Mobile/Web-App benötigt GraphQL mit Echtzeit-Abonnements, unterstützt durch DynamoDB / Lambda.

AWS AppSync. Verwaltetes GraphQL, WebSocket-Abonnements, feingranulare Autorisierung über Cognito / IAM / Lambda-Authorizer.

Kinesis Data Streams vs. Firehose vs. Managed Service for Apache Flink vs. MSK auswählen.

Benutzerdefinierte Konsumenten, ms-Latenz, Replay, Multi-Konsumenten-Fan-Out → Data Streams. Einfach an S3/Redshift/OpenSearch mit Buffering liefern → Firehose. Stream-Verarbeitung (Fenster, Joins) → Managed Service for Apache Flink. Kafka-kompatibel → MSK.

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.

Daten, die in S3 liegen, von Redshift abfragen, ohne sie zu laden.

Redshift Spectrum. Externes Schema über Glue Data Catalog; Spectrum-Knoten scannen S3 und streamen Ergebnisse zurück zum Cluster.

DynamoDB Kapazitätsmodus auswählen.

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).

DynamoDB-Session-Tabelle wächst unbegrenzt; Sessions verfallen nach 24h.

DynamoDB TTL auf einem numerischen Epoch-Attribut. DynamoDB löscht abgelaufene Elemente asynchron, keine Schreibkapazität wird berechnet.

HPC-Workload benötigt geringstmögliche Inter-Node-Latenz.

Cluster Placement Group: Instanzen in derselben AZ auf demselben physischen Rack. Bis zu 10 Gbit/s Einzelfluss.

Warum: Spread Placement → maximale Isolation (HA); Partition → Big-Data (Hadoop, Cassandra); Cluster → geringste Latenz.

Kostenoptimierte Architekturen entwerfen

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).

Compute Savings Plan vs. EC2 Instance Savings Plan vs. SageMaker Savings Plan auswählen.

Compute SP: maximale Flexibilität (deckt EC2, Fargate, Lambda ab) — bester Standard. EC2 Instance SP: familiengebunden, höherer Rabatt. SageMaker SP: nur für SageMaker.

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.

Ungenutzte Reserved Instances nach der Migration.

Im Reserved Instance Marketplace verkaufen (nur Standard RIs). Oder über Convertible RIs in eine andere Familie konvertieren.

Warum: Convertible RIs tauschen einen etwas geringeren Rabatt gegen das Recht zum Tausch.

Rechenkosten ohne Architektur-Rewrite senken.

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.

Lambda-Funktionen, bei denen die Laufzeit ARM unterstützt.

Architektur auf `arm64` (Graviton) setzen. 20% günstiger pro ms als x86, oft schneller. Erfordert architekturkompatible native Abhängigkeiten.

Lambda-Kosten zu hoch; Laufzeit CPU-gebunden.

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.

Datenübertragungskosten senken.

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.

CloudWatch Logs Kosten explodieren.

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).

Right-Sizing-Kandidaten über EC2, Auto Scaling Groups, EBS, Lambda finden.

AWS Compute Optimizer. Liest CloudWatch-Metriken + ML, empfiehlt Downsizing oder Familienwechsel. Kostenlos für organisationsweites Opt-in.

Unerwartete Ausgabenspitzen proaktiv erkennen.

AWS Cost Anomaly Detection (innerhalb von Cost Explorer). ML-basierte Monitore pro Dienst / verknüpftem Konto / Kostenkategorie. Warnungen über SNS / E-Mail.

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.

Dev RDS-Instanz nachts/am Wochenende im Leerlauf.

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).

Container-Flotten-Kostenoptimierung.

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.

S3 / EC2 Egress ins Internet reduzieren.

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.

100 TB von On-Premises NFS nach S3 migrieren.

AWS DataSync Agent On-Premises; geplante Übertragung nach S3. Verschlüsselt, integritätsgeprüft, ratenbegrenzt. Snowball Edge für 100 TB+ oder geringe Bandbreite.

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.

Produktions-RDS / ElastiCache / OpenSearch / Redshift läuft 24×7.

Reserved Instances für verwaltete Datenbanken (kein Savings Plan-Äquivalent für diese Dienste). 1 Jahr oder 3 Jahre; Teilerstzahlung meist bester NPV.

Schnelle, geringfügige Kosteneinsparungen über das Konto hinweg.

AWS Trusted Advisor Kostenprüfungen: untätige Load Balancer, gering ausgelastete EC2, nicht angehängte EBS, unterausgelastete RDS, untätige Redshift. Kostenloser Tarif begrenzt; vollständiger Satz mit Business / Enterprise Support.