Amazon CLF-C02: Kern-Compute-Services — 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 EC2-Konzepte, Kaufmodelle und Verfügbarkeitsmuster

Amazon EC2 ist das grundlegende IaaS-Compute-Angebot: Sie wählen Instance-Typen für CPU, Arbeitsspeicher, Speicher und Netzwerk, führen Betriebssysteme aus, die Sie kontrollieren, und hängen optional Elastic Block Store (EBS)-Volumes für persistenten Blockspeicher an. Das Design für Hochverfügbarkeit erfordert die Platzierung von Workloads über mehrere Verfügbarkeitszonen (Availability Zones, AZs) und gegebenenfalls über mehrere Regionen hinweg. Für verwaltete relationale Datenbanken verwenden Sie Amazon RDS Multi-AZ für eine synchrone Standby-Instanz und automatisches Failover; für extreme Leseskalierung oder regionsübergreifende Notfallwiederherstellung (Disaster Recovery) ziehen Sie Amazon Aurora Global Database in Betracht. Die Kaufoptionen für Instances bestimmen die Kompromisse zwischen Kosten und Ausfallsicherheit: On-Demand bietet Flexibilität ohne Bindung; Reserved Instances oder Compute Savings Plans bieten die größten planbaren Einsparungen für eine kontinuierliche Nutzung bei stabiler Auslastung; Spot-Instances liefern den niedrigsten Preis für fehlertolerante, unterbrechbare Workloads. Häufige Fallstricke sind das Verlassen auf eine einzige AZ, das Einbetten langlebiger Anmeldeinformationen auf Instances und die Überprovisionierung „für alle Fälle“. Verwenden Sie Auto-Scaling-Gruppen mit Zustandsprüfungen (Health Checks), Lifecycle-Hooks und Richtlinien für gemischte Instances (On-Demand + Spot), um Kosten und Verfügbarkeit auszugleichen. Entscheiden Sie zwischen Reserved/Savings Plans und Spot, indem Sie die erforderliche Uptime, die Toleranz gegenüber Unterbrechungen und die Prognosegenauigkeit bewerten; wählen Sie Multi-AZ oder Multi-Region basierend auf RTO/RPO-Anforderungen und regionsübergreifenden Latenzbeschränkungen.

Verwaltete Container-, Batch- und Serverless-Compute-Dienste: Entscheidungskriterien

AWS bietet mehrere verwaltete Compute-Plattformen, die auf die Architekturziele abgestimmt sind. AWS Lambda ermöglicht ereignisgesteuerte, serverlose Funktionen mit automatischer Skalierung und Abrechnung im Millisekundentakt, am besten für zustandslose, kurzlebige Aufgaben. Amazon ECS bietet eine verwaltete Option zur Container-Orchestrierung, die sich mit Fargate für die serverlose Ausführung von Containern oder mit EC2 für mehr Kontrolle integrieren lässt. Amazon EKS führt Kubernetes als verwaltete Steuerungsebene (Control Plane) für Teams aus, die auf Kubernetes standardisieren, wobei die Worker-Knoten als EC2 oder Fargate bereitgestellt werden. AWS Batch plant und skaliert Batch-Compute-Jobs über EC2- oder Spot-Kapazitäten und optimiert den Durchsatz für hochleistungsfähige oder volumenstarke Jobs. Elastic Beanstalk ist eine Anwendungsplattform für die Bereitstellung von Web-Apps, ohne die zugrunde liegende Infrastruktur verwalten zu müssen; es abstrahiert das Setup von EC2, Auto Scaling, ELB und RDS für schnellere Lift-and-Shift-Deployments. Wichtige Entscheidungskriterien sind die betrieblichen Fähigkeiten (Kubernetes-Expertise spricht für EKS), die Deployment-Geschwindigkeit (Beanstalk), die Kostenvorhersehbarkeit (Fargate vereinfacht, kann aber teurer sein) und die Workload-Eigenschaften (Lambda für kurze, ereignisbasierte Aufgaben; ECS/EKS für langlaufende Dienste). Vermeiden Sie den Fallstrick, die funktionsreichste Option zu wählen, wenn ein einfacherer verwalteter Dienst (Lambda oder Fargate) den Betriebsaufwand reduzieren und die Agilität erhöhen würde.

Autoscaling, Elastizität und Kostenoptimierungsstrategien

Elastizität ist die Fähigkeit, Ressourcen je nach Bedarf hoch- und herunterzuskalieren; Autoscaling ist der Mechanismus, um dies zu erreichen. Verwenden Sie Auto-Scaling-Gruppen (ASGs) für EC2, um Instances basierend auf Zielverfolgungs-, Schritt- oder vorausschauenden Richtlinien hinzuzufügen oder zu entfernen. Für Container nutzen Sie das Auto-Scaling von ECS oder EKS für Tasks und Cluster und die integrierte Parallelitätssteuerung von Lambda für Funktionen. Legen Sie Ihre Architektur auf Zustandslosigkeit aus und lagern Sie den Zustand in verwaltete Dienste wie Amazon RDS, DynamoDB, ElastiCache oder S3 aus, damit Instances kurzlebig (ephemeral) sein können. Dimensionieren Sie Instances durch regelmäßige Überprüfungen der Größe richtig, nutzen Sie Überwachung (CloudWatch-Metriken und -Alarme) und ziehen Sie Savings Plans oder Reserved Instances für eine stabile Grundlast in Betracht, während Sie variable Workloads auf Spot platzieren. Zu berücksichtigende Preismodelle:

On-Demand: keine Verpflichtung, Bezahlung pro Stunde/Sekunde.
Reserved Instances / Savings Plans: 1- oder 3-Jahres-Bindung für erhebliche Rabatte.
Spot-Instances: höchste Rabatte für unterbrechbare Workloads.
Dedicated Hosts/Instances: physische Isolierung für Compliance, höhere Kosten. Beliebte Fallstricke sind das Unterschätzen der Aufwärmzeiten beim Autoscaling, die fehlende Nutzung von Lifecycle-Hooks für ein sauberes Herunterfahren und die übermäßige Nutzung von Spot für zustandsbehaftete kritische Workloads. Verwenden Sie Blue/Green- oder Canary-Deployments für sichere Releases und Lifecycle-Richtlinien zur Automatisierung der Kostenkontrolle für ungenutzte Ressourcen.

Sicherheits-, Compliance- und Betriebstools für Compute

Sicherheit und Betrieb sind grundlegend für Compute in AWS. Nach dem Modell der geteilten Verantwortung (Shared Responsibility Model) sichert AWS die globale Infrastruktur und die verwalteten Dienste, während Kunden bei der Nutzung von IaaS für das Gastbetriebssystem (Guest OS), die Anwendungskonfiguration, die Daten und die IAM-Berechtigungen verantwortlich sind. Vermeiden Sie das Einbetten von langlebigen Zugriffsschlüsseln (Access Keys). Weisen Sie stattdessen IAM-Rollen an EC2-Instanzen zu oder verwenden Sie IAM Roles for Service Accounts (IRSA) für EKS. Nutzen Sie AWS Secrets Manager oder den Systems Manager Parameter Store (SecureString), um Secrets zu rotieren und zentral zu verwalten. Für Audits und Untersuchungen aktivieren Sie AWS CloudTrail, um die API-Aktivitäten im gesamten Konto zu erfassen, und verwenden Sie AWS Config, um Ressourcenkonfigurationen aufzuzeichnen. Nutzen Sie Amazon Macie, um sensible Daten in S3 zu entdecken und zu klassifizieren, und den IAM Access Analyzer oder S3 Access Analyzer, um kontoübergreifende oder öffentliche Ressourcenfreigaben zu finden. Für Compliance-Nachweise verwenden Sie AWS Artifact, um Audit-Berichte abzurufen. Die betriebliche Transparenz wird durch VPC Flow Logs für den Netzwerkverkehr, das AWS Personal Health Dashboard für kontospezifische Ereignisse und das Service Health Dashboard für den globalen Servicestatus verbessert. Zu den häufigen Fehlern von Anwendern gehören das Belassen aktiver Schlüssel für das Root-Konto, das Versäumnis, MFA für den Root-Benutzer zu aktivieren, und die fehlende Zentralisierung der Identitäten mit dem IAM Identity Center (ehemals AWS SSO) für SAML-basiertes Single Sign-On bei externen Anwendungen.

Praktisches Problem: Anwendungsfallszenario

Szenario: Acme Analytics betreibt eine Datenverarbeitungsanwendung auf EC2 in einer einzigen AZ innerhalb eines AWS-Produktivkontos. Sie haben Batch-Jobs, die nachts große Datenmengen verarbeiten, und möchten die Kosten senken, eine schnellere Wiederherstellung nach einem AZ-Ausfall erreichen und Secrets sicher handhaben.

Herausforderung: Reduzieren Sie die Compute-Kosten, während der nächtliche Batch-Durchsatz sichergestellt und die Verfügbarkeit über mehrere AZs hinweg verbessert wird, ohne die gesamte Anwendung sofort neu zu architekturieren.

Empfohlener Ansatz:

Migrieren Sie die Batch-Worker in eine AWS Batch Compute-Umgebung mit einer Mixed-Instance-Policy (Spot + On‑Demand), um die Kosten zu senken und gleichzeitig eine Basiskapazität aufrechtzuerhalten.
Konfigurieren Sie AWS Batch für die Nutzung mehrerer AZs und aktivieren Sie Retry/RetryStrategy mit Job-Warteschlangen, die zur Erhöhung der Ausfallsicherheit über die AZs verteilt sind.
Ersetzen Sie eingebettete Anmeldeinformationen durch IAM-Rollen für EC2/Batch-Jobs und speichern Sie rotierte Secrets im AWS Secrets Manager; integrieren Sie diesen mit IAM für den automatischen Abruf.
Implementieren Sie CloudWatch-Alarme und Auto-Scaling-Richtlinien für eine minimale EC2-Flotte für alle verbleibenden zustandsbehafteten (stateful) Komponenten und aktivieren Sie Cross‑AZ RDS Multi‑AZ, falls eine Datenbank verwendet wird.

Begründung: Die Verwendung von verwaltetem Batch + Spot reduziert Kosten und Betriebsaufwand, während die Multi‑AZ-Verteilung und IAM/Secrets Manager die Verfügbarkeit und Sicherheit verbessern – im Einklang mit den Best Practices für Elastizität, das Prinzip der geringsten Rechte (Least Privilege) und die automatisierte Rotation von Secrets.

← Globale AWS-Infrastruktur · Alle Domänen · Kern-Speicherservices →

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