Amazon CLF-C02: Cloud-Konzepte — Lernleitfaden

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

Teil des AWS Cloud Practitioner CLF-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Grundlegende Cloud-Konzepte und das Wertversprechen von AWS

Cloud Computing verlagert kapitalintensive Probleme der Kapazitätsplanung in ein Betriebsmodell, bei dem Rechenleistung, Speicher und Netzwerkressourcen bei Bedarf genutzt werden. AWS bietet Elastizität (automatische Skalierung zur Anpassung an die Last), globale Reichweite (Regions und Availability Zones für Lokalität und Fehlerisolierung) und eine Reihe von Managed Services, die undifferenzierte, schwere Routineaufgaben („undifferentiated heavy lifting“) abnehmen. Architekturkonzepte wie „Designing for Failure“ (Ausfallsicherheit als Designprinzip), lose Kopplung und unveränderliche Infrastruktur („Immutable Infrastructure“) helfen Teams, die Vorteile der Cloud zu nutzen: schnellere Markteinführung („Time to Market“), ein reines Pay-for-what-you-use-Kostenmodell und globale Skalierbarkeit. Netzwerkprimitive wie VPCs, Subnets und ein Internet Gateway steuern den ein- und ausgehenden Datenverkehr (Ingress und Egress) für Workloads. Direct Connect bietet eine dedizierte Verbindung mit hohem Durchsatz zu lokalen Rechenzentren, wenn eine vorhersagbare Bandbreite oder geringere Latenz erforderlich ist. Für sehr große physische Migrationen oder bei unterbrochener Konnektivität ermöglichen Snowball Edge-Geräte einen sicheren Offline-Transfer und sogar Edge-Computing. Häufige Fallstricke für Praktiker sind die Annahme, dass „Lift-and-Shift“ automatisch Kosten senkt, die Unterschätzung von Gebühren für ausgehenden Netzwerkverkehr (Egress Fees) und das Versäumnis, eine Multi-AZ-Ausfallsicherheit zu konzipieren. Entscheidungskriterien sollten die Geschäftsanforderungen an die Verfügbarkeit, die „Data Gravity“, Latenzanforderungen und langfristige Betriebskosten abwägen, bevor man sich für eine Rehost-, Replatform- oder Refactor-Strategie entscheidet.

Services, Migrationsmuster und Architekturentscheidungen

Die Wahl des richtigen AWS-Services hängt davon ab, ob Sie einen verwalteten Betrieb (Managed Operations), Kontrolle über Verantwortlichkeiten auf Betriebssystemebene oder Edge-/Offline-Fähigkeiten benötigen. Migrationsmuster umfassen Rehost (Lift-and-Shift), Replatform (kleinere Optimierungen vornehmen) und Refactor (Neugestaltung der Architektur für Cloud-native). Die Wahl des Speichers spiegelt die Zugriffsmuster wider: S3 für Objektspeicher und Data Lakes, EBS für Blockspeicher, der an EC2 angebunden ist, EFS für POSIX-konforme, gemeinsam genutzte Dateisysteme und FSx-Varianten für verwaltete Windows- oder Hochleistungs-Dateisystemanforderungen. Datenbanken können als Managed Services wie Amazon RDS und Amazon DynamoDB betrieben werden, die administrative Aufgaben abnehmen, oder selbstverwaltet auf EC2, wobei der Kunde die Verantwortung für Betriebssystem, Patching, Backups und Skalierung behält. Für Container reduzieren verwaltete Optionen den Betriebsaufwand und bieten dabei unterschiedliche Kompromisse:

Amazon ECS (EC2-Starttyp): verwaltete Orchestrierung, aber Sie verwalten die EC2-Hosts.
Amazon ECS / Fargate: Serverless-Container ohne Host-Management.
Amazon EKS: verwaltete Kubernetes Control Plane; Sie können die Nodes selbst verwalten oder Fargate nutzen. Für eine schnelle Anwendungsbereitstellung, ohne jede Ressource manuell erstellen zu müssen, beschleunigen AWS Elastic Beanstalk oder CloudFormation-Templates die Auslieferung und erzwingen gleichzeitig Standardarchitekturen. Zu den Fallstricken für Praktiker gehören die Unterschätzung des Betriebsaufwands für selbstverwaltete Datenbanken oder Container-Hosts und das Vergessen, IAM Instance Profiles an EC2 anzuhängen, um einen sicheren Servicezugriff zu gewährleisten.

Cloud-Wirtschaftlichkeit: Preismodelle und Praktiken zur Kostenoptimierung

AWS bietet mehrere Preismodelle, die auf die Vorhersehbarkeit von Workloads und deren Toleranz gegenüber Unterbrechungen abgestimmt sind. On-Demand ist flexibel und ohne Vertragsbindung, Reserved Instances und Savings Plans bieten hohe Rabatte für eine konstante Nutzung, Spot Instances sind stark rabattiert, können aber unterbrochen werden, und Dedicated Hosts erfüllen regulatorische oder lizenzrechtliche Anforderungen. Kostentransparenz und -kontrolle basieren auf Tagging, dem Cost Explorer, AWS Budgets und AWS Cost Anomaly Detection; Rightsizing-Tools wie der AWS Compute Optimizer und die Ressourcenempfehlungen des Cost Explorers helfen dabei, überprovisionierte EC2-Instanzen zu identifizieren. Der Trusted Advisor zeigt Kosten- und Leistungsoptimierungen auf und hebt verwaiste Ressourcen („orphaned resources“) hervor, während AWS Budgets SNS-Benachrichtigungen auslösen kann, wenn Ausgaben die Schwellenwerte überschreiten. Häufige Fallstricke sind der Kauf von Reserved Instances oder Savings Plans ohne Analyse der bisherigen Auslastung, die Verwendung von Spot Instances für kritische, nicht unterbrechbare Workloads und die fehlende Implementierung eines konsistenten Taggings, was die Kostenverrechnung (Chargeback) und Optimierungsbemühungen untergräbt. Entscheidungskriterien sollten Workload-Muster, Unterbrechungstoleranz und Prognosen kombinieren: Nutzen Sie On-Demand für unvorhersehbare Lasten, Savings Plans oder RIs für konstante Grundlasten und Spot für flexible, fehlertolerante Rechenleistung.

Sicherheit, geteilte Verantwortung und bewährte Betriebspraktiken

Sicherheit in AWS ist ein Modell der geteilten Verantwortung: AWS sichert die Cloud-Infrastruktur (Hardware, Netzwerk, Regionen, Availability Zones und grundlegende Dienste), während Kunden in der Cloud für die Sicherheit verantwortlich sind – dies umfasst Daten, Zugriffskontrolle, Verschlüsselung auf Anwendungsebene, das Einspielen von Patches für Betriebssysteme und Software bei IaaS sowie die Identitätsföderation. Verwenden Sie IAM-Rollen, die an EC2-Instanzprofile angehängt sind, um temporären Zugriff mit den geringsten Rechten (Least Privilege) auf Dienste wie S3 zu gewähren; vermeiden Sie es, langlebige Anmeldeinformationen in Instanzen einzubetten. Zu den Datenschutzfunktionen gehören S3-Versioning und Object Lock zur Aufbewahrung, serverseitige Verschlüsselung (SSE) und clientseitige Verschlüsselung für sensible Datensätze. Überwachung und Auditierbarkeit basieren auf CloudTrail für die API-Protokollierung, AWS Config für die Konfigurations-Compliance, Amazon Inspector für Schwachstellenbewertungen von EC2-Workloads, GuardDuty für die Bedrohungserkennung und Amazon Macie für die Erkennung sensibler Daten in S3. Das Well-Architected Framework dient als Leitfaden für Überlegungen zu Betrieb, Sicherheit, Zuverlässigkeit, Leistung und Kosten; häufige Fehler von Anwendern sind die übermäßige Nutzung des Root-Kontos, die Vernachlässigung automatisierter Backups und die fehlende Implementierung von Multi-AZ-Architekturen oder Disaster-Recovery-Plänen. Betriebliche Entscheidungen sollten Automatisierung, das Prinzip der geringsten Rechte und eine zentralisierte Protokollierung priorisieren, um menschliche Fehler zu reduzieren und die Reaktion auf Vorfälle zu beschleunigen.

Praktisches Problem: Anwendungsfallszenario

Szenario: Acme Analytics betreibt eine saisonale Datenverarbeitungspipeline in einer einzigen AWS-Region. Ihre Umgebung umfasst EC2-Instanzen für die Datenverarbeitung (Compute), ein On-Premises-Archiv und einen S3-Data-Lake. Sie müssen pro Saison 50 TB von On-Premises aufnehmen, eine hohe Verfügbarkeit während der Ausführung sicherstellen und die Kosten zwischen den Saisons kontrollieren.

Herausforderung: Massendatentransfer von 50 TB bei begrenzter Bandbreite und der Notwendigkeit einer dauerhaften, auditierbaren Aufnahme; die Rechenleistung muss für ein zweimonatiges Verarbeitungsfenster hochverfügbar und im Leerlauf kosteneffizient sein.

Empfohlener Ansatz:

Bestellen Sie ein Amazon Snowball Edge, um die 50 TB sicher in Amazon S3 zu importieren. Nutzen Sie dabei Edge-Computing, falls eine Vorverarbeitung erforderlich ist.
Speichern Sie die aufgenommenen Daten in einem S3-Bucket mit aktiviertem Versioning und wenden Sie S3 Object Lock zur Aufbewahrung der Quelldatensätze an.
Führen Sie die Verarbeitung auf Auto-Scaling-Gruppen von EC2-Instanzen über mehrere Availability Zones hinweg aus oder nutzen Sie AWS Batch/ECS Fargate für eine verwaltete Skalierung während des zweimonatigen Zeitfensters.
Implementieren Sie Cost Explorer, AWS Budgets mit Benachrichtigungen und wenden Sie Savings Plans oder Reserved Instances nur für grundlegende, persistente Ressourcen an. Beenden oder skalieren Sie die Rechenressourcen nach der Saison herunter.

Begründung: Snowball Edge minimiert die Übertragungszeit und Netzwerkkosten für große, einmalige Importe, während S3 einen dauerhaften, auditierbaren Speicher bietet. Die Nutzung von Auto Scaling oder verwalteter Rechenleistung während der Spitzenmonate gewährleistet die Verfügbarkeit und verursacht nur Kosten während der Verarbeitung, während Kostenmanagement-Tools unerwartete Ausgaben verhindern.

Alle Domänen · Globale AWS-Infrastruktur →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →