Lernen

Die Prüfung auf einen Blick

Der AWS Certified Solutions Architect – Associate ist die bekannteste Associate-Zertifizierung. Geprüft wird nicht Wissen über einzelne Dienste, sondern die Entwurfsentscheidung: Welche Kombination aus Diensten erfüllt die genannten Anforderungen — und zwar sicher, robust, leistungsfähig und zu vertretbaren Kosten. Die aktuelle Fassung heißt SAA-C03.

Stand der Angaben: September 2026, laut offizieller Zertifizierungsseite und Prüfungsleitfaden. Vor der Buchung dort noch einmal prüfen.

Die vier Bereiche und ihr Gewicht

Die Bereiche überschneiden sich stark: Fast jede Frage beschreibt eine Architektur, und der Bereich ergibt sich daraus, welche Eigenschaft die Frage gerade verlangt.

Wie die Fragen gebaut sind

Typisch ist ein Szenario von zwei bis vier Sätzen, gefolgt von der Frage „Which solution meets these requirements?“. Alle vier Optionen sind technisch denkbar. Entschieden wird über den Superlativ in der Frage:

Denkraster für jede Frage

1. Anforderungen herausschreiben. Meist sind es zwei bis drei: „ohne Verwaltungsaufwand“, „Daten dürfen die Region nicht verlassen“, „RPO 15 Minuten“. Jede Option, die eine davon verletzt, fällt raus.
2. Harte Ausschlüsse zuerst. Öffentlicher S3-Bucket, Zugangsschlüssel in der Anwendung, Datenverkehr übers Internet, wo „privat“ gefordert ist, eine einzelne AZ, wo Hochverfügbarkeit gefordert ist — alles sofort streichen.
3. Verwaltet schlägt selbst gebaut. Wenn zwei Optionen dasselbe erreichen, gewinnt bei „geringster Betriebsaufwand“ die mit weniger eigenen Servern.
4. Auf den Superlativ zurückkommen. Zwischen den letzten beiden entscheidet fast immer er.
5. Zeit im Blick. Zwei Minuten je Frage. Lange Szenarien liest man am besten von hinten: erst die Frage, dann das Szenario.

Was vorausgesetzt wird

• Etwa ein Jahr praktische Erfahrung mit AWS — oder gleichwertiges Üben in einem eigenen Konto.
• Sicheres Grundwissen aus dem Cloud Practitioner: Regionen und AZs, IAM, die großen Dienste, das Modell der geteilten Verantwortung.
• Nicht geprüft werden Programmierung, Betriebssystem-Administration und das Schreiben von CloudFormation-Vorlagen im Detail.

Lernquellen

• Offizieller Prüfungsleitfaden (SAA-C03): die verbindliche Liste der Aufgabenbereiche und der Dienste, die vorkommen können.
• AWS Skill Builder: „Exam Prep“-Kurs, das kostenlose Official Practice Question Set und die kostenpflichtige Official Practice Exam mit 65 Fragen.
• AWS-Whitepaper: das Well-Architected Framework, besonders die Säulen Sicherheit, Zuverlässigkeit und Kostenoptimierung, sowie „Disaster Recovery of Workloads on AWS“.
• Generalprobe: Die Prüfungssimulation hier zieht 65 Fragen im Gewicht der Bereiche und läuft mit 130-Minuten-Countdown.

Zugriff: Rollen statt Schlüssel

Die häufigste richtige Antwort im ganzen Bereich: eine IAM-Rolle. Wo im Szenario Zugangsschlüssel auftauchen, ist die Option fast immer falsch.

• Least Privilege schlägt Komfort: lieber eine enge Richtlinie mit Bedingungen (aws:SourceIp, aws:MultiFactorAuthPresent, s3:prefix) als ein breites Allow.
• Permissions Boundary begrenzt, was ein Benutzer oder eine Rolle höchstens darf — nützlich, wenn Teams eigene Rollen anlegen dürfen sollen.
• Service Control Policies (AWS Organizations) begrenzen ganze Konten, auch deren Administratoren — der übliche Weg für „nur diese Regionen“ oder „Protokollierung darf nicht abgeschaltet werden“.
• IAM Access Analyzer findet Ressourcen, die von außerhalb des Kontos erreichbar sind, und erzeugt aus CloudTrail-Daten passgenaue Richtlinien.
• AWS Control Tower richtet eine Multi-Account-Umgebung mit Leitplanken ein.

Netz: privat, wo es privat sein soll

Security Groups verweist man aufeinander: Die Security Group der Instanzen erlaubt nur Verkehr von der Security Group des Load Balancers, nicht von IP-Bereichen. Das ist die Musterantwort für „nur über den Load Balancer erreichbar“.

Anwendungsschutz am Rand

• AWS WAF vor CloudFront, ALB oder API Gateway: SQL-Injection, XSS, Geo-Sperren und ratenbasierte Regeln gegen zu viele Anfragen aus einer IP.
• Shield Advanced: bei geschäftskritischen Zielen, mit Response Team und Kostenschutz.
• AWS Network Firewall: zustandsbehaftete Filterung des gesamten VPC-Verkehrs, inklusive Intrusion Prevention und Domain-Listen — die Antwort, wenn „ausgehender Verkehr“ gefiltert werden soll.
• Firewall Manager: dieselben Regeln über viele Konten hinweg durchsetzen.

Geheimnisse

Daten verschlüsseln

• S3: SSE-S3 (von AWS verwaltet), SSE-KMS (eigener Schlüssel, Protokollierung jedes Zugriffs, Bucket Keys senken die KMS-Kosten), DSSE-KMS (doppelt), SSE-C (Schlüssel bringt der Client mit).
• EBS, RDS, EFS: per Schalter mit KMS. Eine unverschlüsselte RDS-Instanz lässt sich nicht nachträglich verschlüsseln — Snapshot, verschlüsselte Kopie, daraus wiederherstellen.
• KMS: kundenverwaltete Schlüssel erlauben eigene Schlüsselrichtlinien, jährliche automatische Rotation und Multi-Region-Schlüssel für regionsübergreifende Replikate. CloudHSM nur, wenn alleinige Kontrolle über das Hardwaremodul gefordert ist.
• In transit: TLS am ALB oder an CloudFront terminieren; wenn „Ende zu Ende verschlüsselt“ gefordert ist, muss auch die Strecke vom Load Balancer zum Ziel HTTPS sein.
• Unveränderlich aufbewahren: Versionierung plus S3 Object Lock (WORM), dazu MFA Delete.

Sehen, was passiert

Lose koppeln

Zwei Komponenten, die direkt aufeinander zeigen, fallen gemeinsam aus. Die Prüfung liebt den Puffer dazwischen.

Sichtbarkeitszeitraum (visibility timeout) länger als die Verarbeitungsdauer, sonst holt ein zweiter Worker dieselbe Nachricht. Long Polling spart Anfragen und Kosten.

Skalieren statt größer kaufen

• Auto Scaling Group über mehrere AZs, davor ein Load Balancer. Das ist das Standardbild für „hochverfügbar und elastisch“.
• Zielverfolgung (target tracking) auf CPU oder ALBRequestCountPerTarget für gleichmäßige Last; geplante Skalierung für bekannte Zeiten; schrittweise Skalierung für grobe Stufen.
• Health-Check-Typ ELB statt EC2, damit auch hängende Anwendungen ersetzt werden.
• Lifecycle-Hooks, wenn beim Start oder Stopp noch etwas passieren muss (Daten sichern, Warmlauf).
• Zustandslos bauen: Sitzungen in DynamoDB oder ElastiCache, Dateien in S3, nichts Wichtiges auf der Instanz. Sticky Sessions sind die Notlösung, nicht die Musterantwort.

Hochverfügbarkeit je Schicht

Notfallwiederherstellung: RTO und RPO entscheiden

RTO = wie lange darf es dauern, RPO = wie viele Daten darf man verlieren. Die Frage nennt meist beides; daraus folgt die Strategie.

• Route 53 schaltet mit Failover-Routing und Health Checks um; Global Accelerator tut dasselbe auf Netzebene und in Sekunden.
• AWS Backup plant Sicherungen dienstübergreifend, auch regions- und kontoübergreifend, mit unveränderlichem Backup-Tresor.
• Storage Gateway (Tape Gateway) ersetzt Bandsicherungen im eigenen Rechenzentrum.
• Testen gehört dazu: Eine Wiederherstellung, die nie geprobt wurde, ist keine Strategie.

Fehler einplanen

• Wiederholen mit exponentiellem Backoff und Jitter, Verarbeitung idempotent bauen — dieselbe Nachricht darf zweimal ankommen.
• Fehler eingrenzen: getrennte Warteschlangen, Zeitlimits, Circuit Breaker, damit ein langsamer Nachbar nicht alles mitreißt.
• Grenzen kennen: Service Quotas rechtzeitig erhöhen lassen — auch das ist eine Prüfungsantwort.

Speicher nach Zugriffsmuster

Rechenleistung passend wählen

• Instanzfamilien: C für Rechenlast, R und X für Arbeitsspeicher, I und D für lokale Platten, P und G für GPUs, M als Allzweck. Graviton (Endung g) bringt oft mehr Leistung je Euro.
• Placement Groups: cluster für niedrigste Latenz zwischen Knoten (HPC), spread für wenige Instanzen, die sich keinesfalls einen Host teilen dürfen, partition für große verteilte Systeme wie HDFS oder Cassandra.
• EFA (Elastic Fabric Adapter) für MPI-Kommunikation in HPC-Clustern, Enhanced Networking als Grundlage.
• Lambda: mehr Speicher bedeutet auch mehr CPU. Kaltstarts entschärft Provisioned Concurrency, plötzliche Lastspitzen fängt reservierte Nebenläufigkeit und eine Warteschlange davor ab.
• Container: ECS mit Fargate, wenn der Betrieb von Knoten stört; EKS, wenn Kubernetes gefordert ist; AWS Batch für Stapelverarbeitung mit Warteschlange.

Die richtige Datenbank

• DynamoDB: Partitionsschlüssel mit hoher Streuung wählen — eine „heiße“ Partition ist die klassische Fehlerursache. GSI für andere Abfragemuster (eigene Kapazität), LSI nur beim Anlegen der Tabelle und mit demselben Partitionsschlüssel.
• RDS: Lesereplikate nehmen Lesezugriffe ab (Anwendung muss sie ansprechen), Multi-AZ ist Verfügbarkeit. Aurora Serverless v2 für stark schwankende Last.
• ElastiCache: Redis OSS für Persistenz, Replikation und Datenstrukturen; Memcached für einfaches, horizontal verteiltes Caching. Strategien: Lazy Loading, Write-Through, TTL.
• Migration: DMS für die Daten (Full Load + CDC, geringe Ausfallzeit), Schema Conversion Tool beim Wechsel der Engine.

Netz und Auslieferung

• CloudFront für statische und dynamische Inhalte nahe am Nutzer; Ursprung S3 (mit Origin Access Control) oder ALB. Kleine Logik am Rand: CloudFront Functions (sehr schnell, Header und Weiterleitungen) oder Lambda@Edge (mehr Möglichkeiten, Netzzugriff).
• Global Accelerator für TCP/UDP, statische Anycast-IPs und Umschalten in Sekunden — die Antwort bei Spielen, VoIP und nicht cachebarem Verkehr.
• Route 53: latenzbasiert für Geschwindigkeit, Geolocation für Rechtsvorgaben, gewichtet für Tests, Failover für Ausfälle.
• Direct Connect für gleichbleibende Bandbreite und Latenz; VPN als günstiges Backup. Transit Gateway statt vieler VPC-Peerings.

Daten in Bewegung

Die Reihenfolge, in der man spart

1. Abschalten, was niemand braucht — Testumgebungen nachts, ungenutzte Lesereplikate, alte Snapshots.
2. Richtig dimensionieren — Compute Optimizer und CloudWatch statt Bauchgefühl.
3. Preismodell wählen — Savings Plans für die Grundlast, Spot für Unterbrechbares.
4. Speicher automatisch verschieben — Lifecycle-Regeln und Intelligent-Tiering.
5. Datenwege begradigen — Endpunkte statt NAT, CloudFront statt direktem Ausgang.

Rechenleistung

Reservierungen und Savings Plans werden in AWS Organizations über die konsolidierte Rechnung kontoübergreifend genutzt — ungenutzter Rabatt eines Kontos kommt anderen zugute.

Speicher

• Lifecycle-Regeln verschieben nach Alter: Standard → Standard-IA → Glacier Instant/Flexible → Deep Archive, und löschen am Ende. Der Klassiker für Protokolle und Archive.
• Intelligent-Tiering, wenn das Zugriffsmuster unbekannt ist oder schwankt — keine Abrufgebühren, kleine Überwachungsgebühr je Objekt.
• Vorher messen: S3 Storage Lens für den Überblick, Storage Class Analysis für die Frage, ab wann sich IA lohnt.
• EBS: gp2 auf gp3 umstellen spart meist sofort; alte Snapshots in die Archivstufe (Wiederherstellung dauert dann allerdings bis zu 72 Stunden); nicht angehängte Volumes löschen.
• EFS: Lifecycle nach Infrequent Access; beim ersten Zugriff kommen die Dateien zurück.
• Nicht vergessen: Versionierung ohne Lifecycle-Regel lässt alte Versionen unbegrenzt liegen — und die kosten.

Datenbanken

• Aurora Serverless v2 bei stark schwankender oder schwer vorhersagbarer Last statt einer dauerhaft großen Instanz.
• DynamoDB: On-Demand bei unregelmäßiger Last, Provisioned mit Auto Scaling bei gleichmäßiger und vorhersagbarer Last. TTL löscht abgelaufene Einträge kostenfrei, große Anhänge gehören nach S3 (Verweis in der Tabelle).
• Reserved DB Instances für langlebige RDS-Datenbanken.
• Nicht mit Kanonen: Selten abgefragte Verlaufsdaten gehören nach S3 und werden mit Athena abgefragt — nicht in eine laufende Datenbank.
• Redshift: Cluster pausieren, wenn nicht gebraucht; RA3 trennt Rechenleistung von Speicher.

Netzwerk — der stille Kostentreiber

Kosten sichtbar machen

• Kostenzuordnungs-Tags aktivieren und konsequent vergeben — ohne sie lässt sich nichts zuordnen.
• AWS Budgets mit Warnungen, bei Bedarf mit Budget Actions, die Rechte entziehen oder Instanzen stoppen.
• Cost Explorer für Auswertung und Prognose, Cost and Usage Report für die Rohdaten, Cost Anomaly Detection für Ausreißer ohne feste Schwellen.
• CloudWatch Logs nicht vergessen: Aufbewahrungsdauer setzen, Älteres nach S3.

Die Duelle, die immer wieder kommen

In den meisten Fragen bleiben am Ende zwei Optionen übrig. Diese Paare entscheiden sie.

Reizwörter und ihre Antworten

Bilder, die hängen bleiben

• Multi-AZ ist ein Zwilling, das Lesereplikat ein Praktikant. Der Zwilling springt ein, der Praktikant nimmt Arbeit ab.
• Pilot Light: Die Zündflamme brennt (Daten), der Rest des Ofens wird erst angeworfen.
• Sichtbarkeitszeitraum: Die Nachricht ist beim Bearbeiter „unsichtbar“ — kommt er nicht rechtzeitig zurück, greift der Nächste zu.
• Heiße Partition: Ein Kassierer für den ganzen Supermarkt. Besser streuen.
• NAT Gateway: Einbahnstraße nach draußen.
• Gateway-Endpunkt: Hausinterner Aufzug zu S3 — kein Weg über die Straße.