AWS Cloud Practitioner 11: Architektur, Migration und Prüfung

Zehn Teile lang ging es um einzelne Services. Im letzten Teil geht es um Architektur, also darum, wie AWS gute Workloads beschreibt, wie man sie gegen Ausfälle absichert und wie bestehende Systeme überhaupt in die Cloud kommen. Well-Architected Framework, Cloud Adoption Framework und Migrationsstrategien prüft Domain 1 des Exam Guide (Cloud Concepts, 24 % der Wertung), Disaster Recovery taucht in Domain 3 bei der Nutzung mehrerer Regionen auf (Task 3.2). Am Ende stehen die häufigsten Fallen in Prüfungsfragen und eine Strategie für die Prüfung selbst.

Well-Architected Framework mit sechs Pillars

Das AWS Well-Architected Framework ist ein Katalog von Fragen und Best Practices, an dem sich eine Architektur messen lässt. Es ist kein Service, den man bucht, sondern ein Prüfraster. Task 1.2 des Exam Guide nennt alle sechs Pillars, und die Prüfung erwartet, dass wir eine Aussage der richtigen Säule zuordnen.

Die Pillars stehen nicht gegeneinander, sie ergänzen sich. Dazu kommen allgemeine Design-Prinzipien, die quer durch alle Säulen gelten (General Design Principles). Kapazität wird nicht geschätzt, sondern automatisch skaliert. Getestet wird in Produktionsgröße, Entscheidungen stützen sich auf Daten, und der Ernstfall wird in Game Days geübt. Dazu kommen Automatisierung und eine Architektur, die sich weiterentwickeln darf. Wer die Teile zu Compute und Integration gelesen hat, kennt die Werkzeuge dazu bereits, von Auto Scaling bis CloudFormation.

Das Well-Architected Tool in der Konsole macht aus dem Framework einen Fragebogen für eine konkrete Workload. Es ist kostenlos und steht in der In-Scope-Liste. Im Hands-on unten legen wir eine Workload an und zählen die Fragen.

Disaster Recovery in vier Stufen

Disaster Recovery wird an RPO und RTO gemessen. Die Recovery Point Objective (RPO) sagt, wie viel Datenverlust wir hinnehmen, gemessen als Zeitspanne bis zum letzten nutzbaren Stand. Die Recovery Time Objective (RTO) sagt, wie lange der Dienst ausfallen darf, bis er wieder läuft. Beide Werte lassen sich drücken, aber jede Verbesserung kostet laufend Geld, weil mehr Infrastruktur in Bereitschaft stehen muss.

Die Zuordnung ergibt sich aus der Anforderung. Steht in der Frage „geringste Kosten, Ausfall von Stunden ist akzeptabel“, ist Backup & Restore die Antwort. Steht dort „kein Ausfall tolerierbar“, landet die Auswahl bei Multi-Site.

AWS Elastic Disaster Recovery (früher CloudEndure Disaster Recovery) repliziert Server blockweise und kontinuierlich in AWS. AWS nennt eine RPO im Sekundenbereich und eine RTO von Minuten (AWS Guidance, Herstellerangabe). AWS Backup verwaltet Backups zentral über Services, Regionen und Accounts hinweg, statt dass jeder Service seine eigenen Snapshots pflegt. Beide stehen in der In-Scope-Liste.

Migration nach den 7 Rs

Nicht jede Anwendung zieht auf dieselbe Weise in die Cloud. AWS unterscheidet sieben Strategien, die alle mit R beginnen (Prescriptive Guidance). Sie reichen von „gar nicht migrieren“ bis „neu schreiben“, und mit jedem Schritt steigt der Aufwand, aber auch der Nutzen aus der Cloud.

Am häufigsten verwechselt werden Rehost und Replatform. Bleibt das Betriebssystem samt Datenbank unverändert und läuft nur auf anderer Hardware, ist es Rehost. Wird dabei die selbst betriebene Datenbank durch einen Managed Service ersetzt, ist es Replatform.

Werkzeuge für die Migration und ihr Status

Für jede Phase einer Migration gibt es einen Service. Application Discovery Service und Migration Hub nehmen keine Neukunden mehr an, stehen aber weiter im Exam Guide.

Für die Prüfung gilt der Exam Guide, beide Services bleiben deshalb Prüfungsstoff, auch wenn ein neuer Account sie nicht mehr nutzen kann. Task 1.3 nennt außerdem ausdrücklich die Datenbankreplikation als Teil der Migrationsstrategien. Dafür ist DMS die Antwort, bei einem Wechsel der Datenbank-Engine zusammen mit dem Schema Conversion Tool.

Die Snow Family (Snowball und Verwandte) war lange die Lösung für den Offline-Transfer großer Datenmengen. AWS bietet Neukunden keine Snow-Geräte mehr an, und die Familie steht nicht in der In-Scope-Liste, ist also kaum prüfungsrelevant. Als Alternativen nennt AWS DataSync für den Online-Transfer, das AWS Data Transfer Terminal für den physischen Transport und Outposts für Edge-Szenarien (AWS).

Cloud Adoption Framework für die Organisation

Das Well-Architected Framework prüft eine Workload. Das AWS Cloud Adoption Framework (CAF) setzt eine Ebene höher an und beschreibt, was sich in einem Unternehmen ändern muss, damit die Cloud tatsächlich genutzt wird. Es gliedert diese Arbeit in sechs Perspektiven (AWS CAF).

Der Weg verläuft in vier Phasen: Envision → Align → Launch → Scale (AWS). In Envision entsteht das Zielbild, in Align werden Lücken zwischen den Beteiligten geklärt, in Launch gehen erste Pilotprojekte live, in Scale wird ausgeweitet. Task 1.3 fragt zudem nach dem Nutzen des CAF, und der Exam Guide nennt vier Punkte: geringeres Geschäftsrisiko, bessere ESG-Performance, mehr Umsatz und höhere operative Effizienz.

Beide heißen Framework, das macht sie leicht verwechselbar. Fragt eine Aufgabe nach Personal, Schulung oder Organisationswandel, ist das CAF gemeint. Geht es um Zuverlässigkeit oder Kosten einer einzelnen Anwendung, ist es Well-Architected.

Hands-on

Legen wir im Well-Architected Tool eine Workload an und schauen nach, wie viele Fragen der Standard-Lens wellarchitected stellt. Das Tool ist kostenlos, wir räumen trotzdem auf. Die Region ist wie in der ganzen Serie eu-central-1.

WL=$(aws wellarchitected create-workload \
  --workload-name ccp-demo-lernkarten-app \
  --description "Demo-Workload fuer die CLF-C02-Serie" \
  --environment PREPRODUCTION \
  --aws-regions eu-central-1 \
  --lenses wellarchitected \
  --review-owner "demo-admin" \
  --region eu-central-1 \
  --query WorkloadId --output text)

In der Konsole: Well-Architected Tool → Workloads → Define workload. Wir tragen Name, Beschreibung, Review owner, Environment und Regions ein und wählen unter Lenses „AWS Well-Architected Framework“.

Die Lens Review listet pro Pillar, wie viele Fragen noch offen sind. Die Ausgabe ist zur Lesbarkeit in Spalten ausgerichtet.

aws wellarchitected get-lens-review \
  --workload-id "$WL" \
  --lens-alias wellarchitected \
  --region eu-central-1 \
  --query 'LensReview.PillarReviewSummaries[].[PillarName,RiskCounts.UNANSWERED]' \
  --output text

Operational Excellence   11
Security                 11
Reliability              13
Performance Efficiency    5
Cost Optimization        11
Sustainability            6

Zusammen sind das 57 Fragen über sechs Pillars. Reliability hat die meisten, Performance Efficiency die wenigsten.

In der Konsole: Well-Architected Tool → Workloads → Workload wählen → Lens AWS Well-Architected Framework → Overview. „Continue reviewing“ startet den Fragebogen, „Generate report“ erzeugt ein PDF.

Die Werte entsprechen der CLI-Ausgabe.

Ein Blick in die Fragen der Cost Optimization zeigt, wie konkret der Fragebogen wird. Die Ausgabe ist gekürzt.

aws wellarchitected list-answers \
  --workload-id "$WL" \
  --lens-alias wellarchitected \
  --pillar-id costOptimization \
  --region eu-central-1 \
  --query 'AnswerSummaries[].QuestionTitle'

"How do you implement cloud financial management?"
"How do you govern usage?"
"How do you monitor your cost and usage?"
...

Die Fragen verlangen keine Konfiguration, sondern Antworten zu Prozessen und Verantwortlichkeiten. Genau das unterscheidet das Tool von Trusted Advisor aus Teil 10, der den Account automatisch prüft.

Aufräumen:

aws wellarchitected delete-workload \
  --workload-id "$WL" \
  --region eu-central-1

Das Well-Architected Tool selbst erzeugt keine Kosten. Bei allen anderen Hands-ons der Serie gilt weiter, dass Ressourcen im Free Plan Credits verbrauchen und im Paid Plan Geld kosten.

Für die Prüfung

Die folgende Tabelle sammelt die Stichworte, an denen Prüfungsfragen den gesuchten Service verraten.

WorkSpaces, AppStream 2.0, WorkSpaces Secure Browser, Amplify, IoT Core und SES gehören zu Task 3.8 des Exam Guide. Wie sie sich unterscheiden, steht in Teil 07.

Typische Fallen in diesem Teil:

• Well-Architected oder CAF. Workload und Technik → Well-Architected. Organisation, Menschen, Phasen → CAF.
• Rehost oder Replatform. Wird beim Umzug ein Managed Service eingesetzt, ist es Replatform.
• Pilot Light oder Warm Standby. Läuft nur der Datenkern, ist es Pilot Light. Läuft eine verkleinerte, aber komplette Umgebung, ist es Warm Standby.
• Snow Family. Steht nicht im Exam Guide und ist für Neukunden eingestellt.
• Status ist nicht Scope. Migration Hub und Application Discovery Service nehmen keine Neukunden mehr an, bleiben aber Prüfungsstoff.

Strategie für die 90 Minuten

Die Rahmendaten stehen schon in Teil 01, hier noch einmal kompakt mit Blick auf die Taktik (Exam Guide, Zertifizierungsseite, After-Testing-Policy, Certification FAQ, During-Testing-Policy, Stand 2026-10-25).

Raten lohnt sich immer. Für falsche Antworten gibt es keinen Abzug, eine unbeantwortete Frage zählt dagegen als falsch. Das kompensatorische Modell heißt, dass nicht jede Domain einzeln bestanden werden muss. Eine schwache Billing-Domain (12 %) lässt sich mit Security (30 %) und Cloud Technology and Services (34 %) ausgleichen. Bei Multiple-Response-Fragen sind zwei oder mehr von fünf oder mehr Optionen richtig.

Die wirksamste Technik ist das Eliminieren. Zuerst streichen wir die Antworten, die sicher falsch sind, oft bleiben danach nur zwei übrig. Wirkt eine Lösung zwar machbar, aber auffällig kompliziert, ist sie meist falsch. Spot-Instanzen sind nie die Antwort für Datenbanken oder kritische Jobs, die nicht unterbrochen werden dürfen. Bleibt eine Frage unklar, wählen wir trotzdem eine vorläufige Antwort, markieren die Frage mit dem Button „Flag for Review“ und kehren am Ende über den Review-Bildschirm zu ihr zurück. So bleibt keine Frage leer, und die Zeit geht nicht an einer einzelnen Aufgabe verloren. Weil die Prüfung auf Deutsch nur noch bis Jahresende angeboten wird, lohnt es sich, die englischen Servicenamen und Begriffe sicher zu kennen, so wie die ganze Serie sie verwendet.

Die Serie im Rückblick

Elf Teile decken den Stoff der CLF-C02 ab. Wer einzelne Themen wiederholen will, findet sie hier.

Die Prüfung will fast nie wissen, wie ein Service konfiguriert wird, sondern welcher Service zu einem beschriebenen Problem passt. Wer die Stichworte aus den Tabellen „Für die Prüfung“ sicher zuordnen kann, hat den größten Teil der Arbeit erledigt. Der Rest ist Streichen.

Quellen

• AWS Certified Cloud Practitioner (CLF-C02) Exam Guide: https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/cloud-practitioner-02.html
• Exam Guide, Domain 1 (Task 1.2 und 1.3): https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/cloud-practitioner-02-domain1.html
• Exam Guide, Domain 3 (Task 3.2): https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/cloud-practitioner-02-domain3.html
• In-Scope-Services: https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/clf-02-in-scope-services.html
• Out-of-Scope-Services: https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/clf-02-out-of-scope-services.html
• Zertifizierungsseite CLF-C02: https://aws.amazon.com/certification/certified-cloud-practitioner/
• After-Testing-Policy: https://aws.amazon.com/certification/policies/after-testing/
• During-Testing-Policy (Flag for Review): https://aws.amazon.com/certification/policies/during-testing/
• AWS Certification FAQ: https://aws.amazon.com/certification/faqs/
• Well-Architected Framework, General Design Principles: https://docs.aws.amazon.com/wellarchitected/latest/framework/general-design-principles.html
• Disaster-Recovery-Strategien (Whitepaper): https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html
• Elastic Disaster Recovery (Guidance): https://docs.aws.amazon.com/guidance/latest/deploying-cross-region-disaster-recovery-with-aws-elastic-disaster-recovery/getting-started.html
• Migrationsstrategien (7 Rs): https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• Application Discovery Service, Verfügbarkeit: https://docs.aws.amazon.com/application-discovery/latest/userguide/setting-up.html
• Migration Hub, Verfügbarkeitsänderung: https://docs.aws.amazon.com/migrationhub/latest/ug/migrationhub-availability-change.html
• Snowball Edge, Verfügbarkeitsänderung: https://docs.aws.amazon.com/snowball/latest/developer-guide/snowball-edge-availability-change.html
• AWS Cloud Adoption Framework: https://aws.amazon.com/cloud-adoption-framework/
• Was ist das Cloud Adoption Framework: https://aws.amazon.com/what-is/cloud-adoption-framework/
• Cost Explorer FAQ (Prognose 18 Monate): https://aws.amazon.com/aws-cost-management/aws-cost-explorer/faqs/