AWS Cloud Practitioner 01: Cloud-Grundlagen und globale Infrastruktur

Mit dieser Serie arbeiten wir in elf Teilen den Stoff der Prüfung AWS Certified Cloud Practitioner (CLF-C02) durch, vom Grundbegriff bis zur Prüfungsstrategie, und probieren in jedem Teil etwas im eigenen AWS-Account aus. Die Prüfung richtet sich an Einsteiger. Programmieren, Architekturdesign, Troubleshooting, Implementierung und Lasttests liegen laut Exam Guide ausdrücklich außerhalb dessen, was von Kandidaten erwartet wird. Verlangt wird, dass wir Begriffe, Dienste und Verantwortlichkeiten sicher zuordnen.

Die Prüfung in Zahlen

Die Eckdaten stammen aus dem Exam Guide und von der Zertifizierungsseite (Stand 25.10.2026):

Die 15 ungewerteten Fragen sind nicht gekennzeichnet. Wir erkennen sie also nicht und behandeln jede Frage gleich ernst. Die Bewertung folgt einem kompensatorischen Modell. Wir müssen nicht jede Domäne einzeln bestehen, entscheidend ist die Gesamtpunktzahl.

Falsche Antworten kosten keine Punkte, eine unbeantwortete Frage zählt dagegen als falsch. Raten lohnt sich deshalb immer. Neben Multiple Choice mit einer richtigen Antwort gibt es Multiple Response, bei der zwei oder mehr von fünf oder mehr Optionen richtig sind. Wer bestanden hat, kann dieselbe Prüfungsversion laut After-Testing-Policy zwei Jahre lang nicht erneut ablegen.

Der Stoff verteilt sich auf vier Domänen mit fester Gewichtung:

Ein Nachfolger CLF-C03 ist auf der offiziellen Seite nicht angekündigt, CLF-C02 steht dort ohne Ablaufdatum (Stand 25.10.2026).

Die deutsche Sprachversion der Prüfung wird nach dem 31.12.2026 eingestellt, ebenso die italienische. Wer später antritt, liest die Fragen auf Englisch oder in einer der anderen angebotenen Sprachen. Deshalb bleiben in dieser Serie alle Servicenamen und Schlüsselbegriffe englisch, erklärt wird auf Deutsch. So erkennen wir die Begriffe in der Prüfung wieder, egal in welcher Sprache wir sie ablegen.

Cloud Computing als Mietmodell

Cloud Computing heißt im Kern, dass wir Rechenleistung, Speicher und Netz nicht kaufen und selbst betreiben, sondern bei Bedarf mieten und nach Verbrauch bezahlen. Der Exam Guide unterscheidet drei Betriebsmodelle (Task 3.1): Cloud (alles läuft beim Anbieter), on-premises (alles im eigenen Rechenzentrum, oft auch Private Cloud genannt) und hybrid (eine Kombination aus beidem, etwa wenn ein Unternehmen Altsysteme im eigenen Rechenzentrum behält und neue Anwendungen in der Cloud baut).

Fünf Merkmale aus der verbreiteten NIST-Definition grenzen Cloud Computing von klassischem Hosting ab:

Die Vorteile formuliert AWS im Whitepaper „Overview of Amazon Web Services“ als sechs Punkte, die in Prüfungsfragen oft wörtlich wiederkehren:

Abgerechnet wird nach Compute, Storage und ausgehendem Datentransfer (Data Transfer OUT). Eingehender Datentransfer ist kostenlos. Teil 10 geht auf die Preismodelle im Detail ein.

Die Servicemodelle unterscheiden sich darin, wie viel der Anbieter uns abnimmt:

AWS selbst nennt IaaS, PaaS und SaaS auf seiner Seite zu den Types of Cloud Computing die traditionelle Einteilung und versteht unter SaaS vor allem fertige Endanwendungen, deren Betrieb komplett beim Anbieter liegt. Diese Abstufung kehrt beim Shared Responsibility Model weiter unten wieder.

Scalability, Elasticity, High Availability

Scalability, Elasticity und High Availability klingen ähnlich, meinen aber Verschiedenes.

Scalability heißt, dass ein System mehr Last bewältigen kann, wenn wir es vergrößern. Das geht vertikal oder horizontal. Beim vertikalen Skalieren (scale up) bekommt eine einzelne Maschine mehr CPU und Arbeitsspeicher, etwa durch einen größeren Instanztyp. Das ist einfach, endet aber an der größten verfügbaren Maschine, und die Anwendung läuft weiterhin an einem einzigen Ort. Beim horizontalen Skalieren (scale out) kommen weitere gleichartige Maschinen hinzu, auf die ein Load Balancer die Last verteilt.

Elasticity geht einen Schritt weiter. Das System skaliert automatisch nach der tatsächlichen Last, nach oben wie nach unten, und wir bezahlen nur, was gerade läuft. Bei AWS übernimmt das typischerweise Auto Scaling, das wir in Teil 03 anlegen. Ein Shop, der am Black Friday zehnmal so viele Server braucht wie im Februar, ist das Lehrbuchbeispiel.

High Availability beschreibt, dass ein System den Ausfall eines Rechenzentrums übersteht. Dafür läuft es in mindestens zwei Availability Zones. Horizontal skalierte Server, die über mehrere Zonen verteilt sind, liefern beides zugleich. Fault Tolerance ist die strengere Anforderung. Ein fehlertolerantes System bleibt beim Ausfall einer Komponente verfügbar, weil redundante Komponenten bereitstehen und deren Arbeit praktisch nahtlos übernehmen.

Agility gehört nicht in diese Reihe, mit Last hat sie nichts zu tun. Gemeint ist, dass wir Ressourcen in Minuten statt in Wochen bereitstellen und damit schneller ausprobieren und verwerfen können.

Regionen, Availability Zones und Local Zones

Die globale Infrastruktur von AWS hat mehrere Ebenen. Eine Region ist ein geografischer Standort wie eu-central-1 (Frankfurt). Jede Region besteht aus mehreren Availability Zones (AZs), und jede AZ aus einem oder mehreren Rechenzentren. Der Exam Guide hält in Task 3.2 fest, dass sich AZs keine Single Points of Failure teilen. Deshalb reicht der Betrieb in zwei AZs für Hochverfügbarkeit.

Eine Region wählen wir nach vier Kriterien: Compliance und Datenhoheit, Latenz zu den Kunden, Verfügbarkeit der benötigten Services und Preis. Die meisten Services sind region-scoped, eine EC2-Instanz in Frankfurt existiert also nur dort. Einige Services sind global, darunter IAM, Route 53 und CloudFront. AWS WAF ist ein Sonderfall, weil es vor CloudFront global arbeitet, vor einem Application Load Balancer oder API Gateway dagegen regional. Mehrere Regionen nutzen wir laut Task 3.2 für Disaster Recovery, Business Continuity, geringere Latenz oder Datenhoheit.

Außerhalb der Regionen liegen Edge Locations. Dort liefert CloudFront Inhalte nahe beim Nutzer aus, Teil 06 behandelt das ausführlich.

Für Fälle, in denen die nächste Region zu weit entfernt ist, gibt es Erweiterungen:

Local Zones zählen nicht zum Prüfungsstoff, im Hands-on sehen wir trotzdem eine. Für Frankfurt gibt es eine Local Zone in Hamburg.

Das Shared Responsibility Model

Sicherheit in der Cloud teilen sich AWS und Kunde. AWS verantwortet die Security OF the Cloud, also Rechenzentren, globales Netz, Hardware und Virtualisierung. Wir verantworten die Security IN the Cloud, also alles, was wir auf dieser Infrastruktur einrichten. Wo die Grenze verläuft, hängt vom Service ab. Task 2.1 verlangt genau diese Zuordnung je Service, der Exam Guide nennt dafür RDS, Lambda und EC2 als Beispiele.

Bei EC2 mieten wir eine virtuelle Maschine. Ab dem Betriebssystem aufwärts gehört alles uns, auch das Einspielen von Sicherheitsupdates. Bei RDS betreibt AWS die Datenbank samt Betriebssystem und patcht die Engine, wir verwalten Datenbankbenutzer, Netzwerkzugriff und Daten. Bei S3 sehen wir gar keinen Server mehr, wir konfigurieren nur noch Buckets und deren Zugriff.

Je höher ein Service abstrahiert, desto weiter rutscht die Grenze nach oben. Die Daten und die Zugriffsrechte bleiben immer beim Kunden. Ein öffentlich lesbarer S3-Bucket ist deshalb kein Sicherheitsproblem von AWS, sondern eine Fehlkonfiguration des Kunden.

Einige Bereiche teilen sich beide Seiten, jede für ihre Ebene: Patch Management, Configuration Management sowie Awareness & Training. Beim Patchen etwa kümmert sich AWS um die Infrastruktur, wir uns auf EC2 um unsere Gastbetriebssysteme.

Ein eigener Demo-Account

Für die Hands-on-Abschnitte der Serie brauchen wir einen AWS-Account, an dem nichts Wichtiges hängt. Am besten legen wir dafür einen neuen an, sichern ihn ab und arbeiten danach nie wieder mit dem Root User.

Account anlegen

AWS bietet zwei Wege zur Anmeldung. Sign up for AWS (new) meldet uns mit einem vorhandenen Google-, GitHub-, Apple- oder Amazon-Login an und richtet ein vorkonfiguriertes Projekt ein. Dieser Weg wird laut AWS erst schrittweise für einen Teil der Neukunden freigeschaltet. Für die Serie nehmen wir den klassischen Weg Sign up for AWS (advanced), der einen Account mit eigenem Root User anlegt, so wie ihn die Prüfung voraussetzt.

Für die Anmeldung brauchen wir:

• eine E-Mail-Adresse, die künftig der Login des Root Users ist und über die sich sein Passwort zurücksetzen lässt
• einen Account-Namen, AWS schlägt für private Accounts das Muster vorname-nachname-zweck vor
• ein starkes Passwort mit 8 bis 128 Zeichen aus mindestens drei Zeichengruppen
• Kontaktdaten, eine gültige Zahlungsmethode und eine Telefonnummer, die per SMS oder Anruf einen Code empfangen kann

Während der Anmeldung wählen wir den Account-Plan. Im Free Plan entstehen keine Kosten, wir bekommen 100 USD Credits und können bis zu 100 USD dazuverdienen. Er endet nach sechs Monaten oder wenn die Credits verbraucht sind, danach wird der Account geschlossen, sofern wir nicht in den Paid Plan wechseln. Für die Serie genügt der Free Plan, die Details stehen in Teil 10. Als Support-Plan wählen wir Basic, er ist kostenlos. Die Aktivierung dauert meist wenige Minuten, kann laut AWS aber bis zu 24 Stunden brauchen.

Den Root User absichern

Nach der ersten Anmeldung als Root User aktivieren wir sofort MFA. AWS verlangt das inzwischen für alle Account-Typen, MFA muss spätestens 14 Tage nach dem ersten Konsolen-Login eingerichtet sein. Am sichersten sind Passkeys oder FIDO-Sicherheitsschlüssel, eine Authenticator-App auf dem Smartphone genügt aber auch. Der Root User kann bis zu acht MFA-Geräte haben, ein zweites als Reserve ist sinnvoll.

Access Keys für den Root User legen wir nicht an. Die E-Mail-Adresse des Root Users schützen wir wie ein Passwort, denn wer sie kontrolliert, kann das Root-Passwort zurücksetzen. Danach melden wir uns als Root User ab und nutzen ihn nur noch für die wenigen Aufgaben, die nur er erledigen kann (Teil 02).

Einen Admin-User anlegen

Für die tägliche Arbeit legen wir in der IAM-Konsole einen IAM-User mit Zugang zur Management Console an, etwa admin. Den User stecken wir in eine Gruppe Admins, an der die AWS-managed Policy AdministratorAccess hängt. Danach melden wir uns als dieser User an und aktivieren auch für ihn MFA. Ab hier arbeiten wir nur noch mit diesem User.

In der Konsole: IAM → IAM users → Create user. Wir tragen den User name ein, haken „Provide user access to the AWS Management Console“ an und gehen über Set permissions (Add user to group, bei Bedarf Create group) und Review and create bis Retrieve password. Das Passwort ist wahlweise Autogenerated oder Custom. Mit „Users must create a new password at next sign-in“ muss der User es bei der ersten Anmeldung ändern.

AWS empfiehlt für menschliche Benutzer eigentlich IAM Identity Center. Für einen einzelnen Demo-Account passt es aber nicht gut. Die Variante ohne AWS Organizations, die sogenannte Account Instance, unterstützt keine Permission Sets und gibt damit keinen Zugriff auf den Account selbst. Die volle Variante setzt AWS Organizations voraus, und ein Account im Free Plan wechselt beim Beitritt zu einer Organisation automatisch in den Paid Plan. Für mehrere Accounts ist Identity Center dagegen die richtige Wahl, mehr dazu in Teil 02 und Teil 10.

Die CLI anbinden

Die Befehle der Serie laufen mit der AWS CLI. Ab Version 2.32.0 meldet sie sich mit aws login über den Browser an, mit denselben Zugangsdaten wie die Konsole. Die CLI erhält dabei nur temporäre Credentials, erneuert sie alle 15 Minuten und hält die Sitzung bis zu 12 Stunden. Langlebige Access Keys auf der Festplatte brauchen wir damit nicht.

aws --version
aws login
aws configure set region eu-central-1
aws sts get-caller-identity

aws login öffnet den Browser, dort wählen wir die Sitzung unseres Admin-Users. get-caller-identity zeigt danach, als wer die CLI arbeitet. Der ARN muss auf :user/admin enden, nicht auf :root. Die Policy AdministratorAccess deckt die nötige Berechtigung für aws login bereits ab. Für eingeschränkte User gibt es dafür die AWS-managed Policy SignInLocalDevelopmentAccess.

Hands-on

Schauen wir uns die globale Infrastruktur im Demo-Account an. Beide Befehle lesen nur, sie legen nichts an und kosten nichts. Voraussetzung ist die eben eingerichtete CLI, angemeldet als Admin-User.

Zuerst zählen wir die Regionen. Mit --all-regions erscheinen auch die, die für unseren Account nicht aktiviert sind:

aws ec2 describe-regions --all-regions --region eu-central-1 \
  --query "length(Regions)"
34

aws ec2 describe-regions --all-regions --region eu-central-1 \
  --query "length(Regions[?OptInStatus=='opt-in-not-required'])"
17

In der Konsole: AWS Global View → Regions and Zones → Regions, dort steht pro Region „Enabled by default“ oder „Not opted in“, freigeschaltet wird über „Enable region“.

Von 34 Regionen sind 17 standardmäßig aktiv. Die anderen 17 haben den Status not-opted-in. Diese Opt-in-Regionen müssen wir erst ausdrücklich freischalten, bevor wir dort Ressourcen anlegen können. Dazu gehören zum Beispiel eu-central-2 (Zürich), eu-south-1 (Mailand), il-central-1, me-central-1, mx-central-1, ca-west-1 und ap-southeast-5 bis ap-southeast-7.

Jetzt die Availability Zones der Region Frankfurt:

aws ec2 describe-availability-zones --all-availability-zones --region eu-central-1 \
  --filters Name=zone-type,Values=availability-zone \
  --query "AvailabilityZones[].[ZoneName,ZoneId]" --output text
eu-central-1a   euc1-az2
eu-central-1b   euc1-az3
eu-central-1c   euc1-az1

In der Konsole: EC2 → Dashboard → Zones, alternativ AWS Global View → Regions and Zones → Availability Zones.

Frankfurt hat drei AZs. Auffällig ist die zweite Spalte. Der Zone-Name (eu-central-1a) wird pro Account anders den physischen Zonen zugeordnet, die Zone-ID (euc1-az2) dagegen bezeichnet überall dieselbe Zone. Wenn zwei Accounts ihre Ressourcen in dieselbe physische AZ legen wollen, müssen sie sich über die Zone-ID abstimmen, nicht über den Namen.

Zum Schluss die Local Zones, die an Frankfurt hängen:

aws ec2 describe-availability-zones --all-availability-zones --region eu-central-1 \
  --filters Name=zone-type,Values=local-zone \
  --query "AvailabilityZones[].[ZoneName,OptInStatus,ParentZoneName]" --output text
eu-central-1-ham-1a   not-opted-in   eu-central-1b
eu-central-1-waw-1a   not-opted-in   eu-central-1b
eu-central-1-ath-1a   not-opted-in   eu-central-1a
eu-central-1-ist-1a   not-opted-in   eu-central-1c

In der Konsole: AWS Global View → Regions and Zones → Local Zones, mit der Suche „eu-central-1-“. Die Konsole zeigt statt der Parent-AZ die Parent Region.

Vier Local Zones gehören zur Region Frankfurt: Hamburg, Warschau, Athen und Istanbul. Keine davon ist aktiviert, auch Local Zones sind Opt-in. Die Spalte ParentZoneName zeigt, an welcher AZ der Region die Local Zone hängt, Hamburg etwa an eu-central-1b.

Aufräumen müssen wir nichts, denn beide Befehle haben nur gelesen. Wir schalten bewusst keine Opt-in-Region und keine Local Zone frei. In späteren Teilen legen wir Ressourcen an, die nach Ablauf des Free Tier Kosten erzeugen können; dort steht am Ende jeweils der passende Löschbefehl.

Für die Prüfung

Typische Fallen:

• Elasticity und Scalability verwechseln. Das Signalwort für Elasticity ist „automatisch“ oder „nach Bedarf“, Scalability fragt nur nach der Fähigkeit, mehr Last zu bewältigen.
• Agility als Skalierungsbegriff lesen. Agility meint Geschwindigkeit bei der Bereitstellung, nicht Kapazität.
• Daten oder IAM bei AWS verorten. Daten, Verschlüsselung und Zugriffsrechte bleiben bei jedem Service beim Kunden, auch bei S3 und RDS.
• Eine AZ mit einem Rechenzentrum gleichsetzen. Eine AZ besteht aus einem oder mehreren Rechenzentren, eine Region aus mehreren AZs.
• Fragen leer lassen. Unbeantwortet ist immer falsch, Raten kostet nichts. Das gilt auch für Multiple Response mit zwei oder mehr richtigen Optionen.

Quellen

• AWS: Exam Guide AWS Certified Cloud Practitioner (CLF-C02), abgerufen am 25.10.2026
• AWS: Exam Guide, Domain 1: Cloud Concepts
• AWS: Exam Guide, Domain 2: Security and Compliance
• AWS: Exam Guide, Domain 3: Cloud Technology and Services
• AWS: In-Scope-Services und Out-of-Scope-Services
• AWS: AWS Certified Cloud Practitioner, Zertifizierungsseite, abgerufen am 25.10.2026
• AWS: Certification Policies, After Testing
• AWS: Six advantages of cloud computing und Types of Cloud Computing
• AWS: Regions and Availability Zones
• AWS Architecture Blog: What to Consider when Selecting a Region for your Workloads
• AWS: AWS WAF FAQs (globale Regeln an CloudFront, regionale an ALB, API Gateway, AppSync)
• AWS: AWS Outposts racks FAQs (physische Sicherheit beim Kunden, lokale Datenverarbeitung und Data Residency)
• AWS Whitepaper: Availability and Beyond, Fault tolerance and fault isolation
• AWS: Shared Responsibility Model
• AWS: Sign up for AWS (advanced)
• AWS: Sign up for AWS (new)
• AWS: Choosing a plan (Free und Paid Plan)
• AWS: MFA für den Root User
• AWS: Organization- und Account-Instanzen von IAM Identity Center
• AWS: CLI-Anmeldung mit aws login

Im nächsten Teil geht es um Identitäten und Berechtigungen: AWS Cloud Practitioner 02: IAM erklärt User, Gruppen, Policies und Roles und zeigt, warum der Root-User im Alltag in der Schublade bleibt.