Amazon DOP-C02: Container und Serverless-Betrieb — Lernleitfaden

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Überblick

Container und Serverless verändern die Art und Weise, wie Sie Anwendungen auf AWS betreiben, skalieren und veröffentlichen. Dieser Abschnitt verbindet die operativen Grundlagen von Amazon ECS, AWS Fargate, Amazon EKS, Amazon ECR, AWS Lambda und Amazon API Gateway, damit Sie sichere Deployments entwerfen, Image-Governance durchsetzen, die Parallelität (Concurrency) abstimmen und konsistente Entscheidungen zwischen EC2- und Fargate-basierter Kapazität treffen können. Der Fokus liegt auf den Planungsmodellen für Tasks und Pods, Health Checks und Deployment-Kontrollen, Traffic Shifting, der Verteilung von Images über verschiedene Konten hinweg und auf Performance-Features wie API-Caching und der bereitgestellten Parallelität (Provisioned Concurrency) von Lambda.

Amazon ECS und AWS Fargate

ECS-Task-Definitionen deklarieren einen oder mehrere Container und die gesamte Laufzeitkonfiguration, die der Scheduler benötigt. Wichtige Elemente sind CPU-/Speicherreservierungen und -limits, portMappings, Umgebungsvariablen und Secrets (aus AWS Secrets Manager oder Systems Manager Parameter Store), Linux-Parameter und ulimits, logConfiguration (awslogs, firelens, etc.), die Größe des ephemeralStorage (für Fargate, 20–200 GB) und Volumes (einschließlich EFS). Verwenden Sie die Task Execution Role für das Pullen von Images und für Log-Treiber; verwenden Sie die Task Role für den AWS-API-Zugriff der Anwendung. Der Container-healthCheck definiert Befehl, Intervall, Timeout, Wiederholungsversuche (Retries) und die startPeriod. In Kombination mit dependsOn (condition=HEALTHY) erzwingen Health Checks die Startreihenfolge für Sidecars.

ECS-Services halten die gewünschte Anzahl an Tasks aufrecht und registrieren Tasks optional bei einem ALB/NLB. Die deploymentConfiguration eines Service steuert Rolling Updates mit minimumHealthyPercent und maximumPercent. Der Deployment Circuit Breaker (enabled/rollback) kann fehlgeschlagene Rollouts automatisch zurücksetzen, wenn Tasks ihre Health Checks nicht bestehen. Service Autoscaling integriert sich mit Application Auto Scaling für CPU-/speicherbasiertes Target Tracking oder ALB RequestCountPerTarget. Service Discovery (AWS Cloud Map) und ECS Service Connect vereinfachen den Service-zu-Service-Traffic.

Clustertypen und Kapazität:

EC2 Launch Type führt Tasks auf selbstverwalteten EC2-Instanzen aus. Verwenden Sie Auto Scaling Groups, Placement Constraints/Strategies und jeden networkMode (bridge/host/awsvpc). Daemon-Tasks und spezialisierte AMIs (z. B. Bottlerocket) werden unterstützt.
Fargate Launch Type ist Serverless Compute für Container. Er verwendet ausschließlich awsvpc-Networking, wodurch jeder Task sein eigenes ENI und seine eigene Security Group erhält. Es gibt keine Daemon-Tasks; Sie verlassen sich auf Sidecars oder service-native Integrationen (z. B. FireLens). Plattformversionen bestimmen die verfügbaren Features (prüfen Sie die Release Notes für EFS-, Ephemeral-Storage- und Exec-Unterstützung). Fargate Spot reduziert die Kosten für unterbrechbare Tasks. Wählen Sie CPU/Speicher in unterstützten Paaren (z. B. 0,25 vCPU/0,5–2 GB bis hin zu 16 vCPU/120 GB). Wenn Sie Tasks in privaten Subnetzen ausführen, fügen Sie VPC Interface Endpoints für ECR (api und dkr), CloudWatch Logs und einen S3 Gateway Endpoint hinzu, um Images zu pullen und Logs ohne NAT zu versenden.

Fargate und EFS: Definieren Sie ein EFS-Volume in der Task-Definition und mounten Sie es mit TLS; bevorzugen Sie EFS Access Points für Least-Privilege und die Durchsetzung von Identitäten. Dies unterstützt zustandsbehaftete (stateful) Anforderungen wie geteilte Konfigurationen, Modell-Gewichtungen oder temporäre Dateien, ohne diese in die Images einbacken zu müssen.

Container-Health-Checks, Rolling Updates und Blue/Green:

Health Checks finden auf mehreren Ebenen statt: Container (CMD-basiert), ECS-Task (aggregierte Container-Status) und Load Balancer Target Health (HTTP/TCP). Stimmen Sie Intervalle und Schwellenwerte aufeinander ab, damit ECS fehlerhafte Tasks ordnungsgemäß ersetzen kann, bevor der ALB die Targets deregistriert.
Rolling Updates sind der Standard bei ECS. Passen Sie minHealthy/maxPercent an, um den Surge (Zuwachs) und die Kapazitätssicherheit zu steuern.
Blue/Green verwendet CodeDeploy mit ECS (deploymentController Typ

undefined

). CodeDeploy verwaltet zwei Zielgruppen (Target Groups) hinter dem ALB, leitet Test-Traffic auf die grüne Umgebung (AfterAllowTestTraffic), führt automatisierte Prüfungen aus (z. B. über Lambda) und schaltet dann den Produktions-Traffic um. Verknüpfen Sie CloudWatch-Alarme, um bei 5XX-Spitzen, Latenz oder benutzerdefinierten Metriken ein Rollback auszulösen. Dieses Muster isoliert Fehler und ermöglicht schnelle Wiederherstellungen mit nahezu null Ausfallzeit.

Image-Governance mit ECR:

Scannen: Aktivieren Sie „Scan-on-Push“ und nutzen Sie das erweiterte Scannen von Amazon Inspector für eine kontinuierliche CVE-Abdeckung und SBOMs. Steuern Sie Deployments basierend auf dem Schweregrad von Schwachstellen durch Prüfungen in der Pipeline.
Lifecycle-Richtlinien lassen alte Image-Tags nach Anzahl/Alter und Tag-Präfix ablaufen. Kombinieren Sie dies mit der Unveränderlichkeit von Tags (Tag Immutability), um versehentliches Überschreiben zu blockieren.
Verschlüsselung: Verwenden Sie die von ECR verwaltete Verschlüsselung oder einen kundenseitig verwalteten KMS-Schlüssel mit einer entsprechenden Schlüsselrichtlinie (Key Policy).
Kontoübergreifend (Cross-Account): Fügen Sie Repository-Ressourcenrichtlinien an, um Pull-/Push-Berechtigungen von anderen Konten oder CI-Rollen zu erteilen. Verwenden Sie ECR-Replikationsregeln, um Images über Regionen/Konten hinweg zu kopieren, um die Lokalität zu verbessern und den Blast Radius zu reduzieren. PrivateLink (VPC Endpoints) ermöglicht das Pullen von Images ohne Internetzugang.

API-Gateway-Design und kontoübergreifender ECR-Zugriff

API Gateway REST-APIs im Vergleich zu HTTP-APIs:

REST-APIs bieten den größten Funktionsumfang: Anfrage-/Antwort-Mapping (VTL), Nutzungspläne und API-Schlüssel, Authorizer, WAF und Caching auf Stage-Ebene. Wählen Sie REST-APIs, wenn Sie erweiterte Transformationen, API-Schlüssel mit Kontingenten oder ausgereifte Ökosystem-Integrationen benötigen.
HTTP-APIs haben eine geringere Latenz und niedrigere Kosten bei einfacherem Routing zu Lambda- und HTTP-Backends (einschließlich ALB/NLB/privater Integrationen). Sie unterstützen JWT-Authorizer und IAM, es fehlen jedoch viele REST-Funktionen, einschließlich Caching auf Stage-Ebene und VTL-Transformationen. Wählen Sie HTTP-APIs für unkompliziertes Proxying mit minimalem Overhead.

Stages und Drosselung:

Stages binden ein bestimmtes Deployment an einen URL-Pfad. Konfigurieren Sie Stage-Variablen, Protokollierung und Drosselung auf der Stage-Ebene. Wenden Sie Nutzungspläne (REST) an, um Drosselungen und Kontingente pro API-Schlüssel durchzusetzen. Die Drosselungseinstellungen umfassen Rate und Burst; sie werden mit den Limits auf Kontoebene kombiniert. Stellen Sie daher sicher, dass der aggregierte Datenverkehr die regionalen Kontingente nicht überschreitet. Aktivieren Sie die Zugriffsprotokollierung mit strukturiertem JSON und integrieren Sie WAF, um bösartige Anfragen zu überprüfen und zu blockieren.

Caching (nur REST-APIs):

Ein Cache auf Stage-Ebene reduziert die Backend-Last und Latenz. Legen Sie TTLs pro Methode fest, aktivieren Sie die Verschlüsselung und berücksichtigen Sie Cache-Schlüsselparameter/-Header für die Korrektheit. Invalidieren Sie Caches nach Deployments, die die Form oder das Verhalten von Antworten ändern.

Private Konnektivität:

Wählen Sie den Endpunkttyp: Edge-optimiert (REST, global über CloudFront), regional oder privat (VPC-Endpunkte). Private Integrationen mit VPC Link stellen eine Verbindung zu NLB/ALB-Backends in VPCs ohne öffentliche Exposition her.

Kontoübergreifender ECR-Zugriff:

Verwenden Sie Ressourcenrichtlinien für Repositories, um Principals in anderen Konten (CI/CD- oder Runtime-Rollen) Pull-/Push-Berechtigungen zu erteilen. Wenn Sie einen kundenseitig verwalteten KMS-Schlüssel verwenden, erweitern Sie die Schlüsselrichtlinie entsprechend. Definieren Sie für die Verteilung über mehrere Konten ECR-Replikationsregeln, die auf Zielkonten/-Regionen ausgerichtet sind, und validieren Sie die Image-Integrität durch Tag-Unveränderlichkeit und Digest-Pinning in Deployments.

Praktisches Problemszenario

Spotify modernisiert einen Microservice-Stack für Playlists, um Latenzschwankungen bei Spitzen-Releases zu reduzieren und die Image-Lieferkette über mehrere AWS-Konten hinweg zu straffen.

Standardisierung von Image-Build und Governance

Implementieren Sie ECR-Repositories mit Scan-on-Push und dem erweiterten Scannen von Amazon Inspector. Fügen Sie Tag-Unveränderlichkeit und Lifecycle-Richtlinien hinzu, um die neuesten N Versionen pro Branch beizubehalten und Abweichungen zu bereinigen. Konfigurieren Sie die regions- und kontoübergreifende Replikation vom Build-Konto zu den Prod- und Staging-Konten. Warum: Inspector gewährleistet eine kontinuierliche CVE-Abdeckung, die Unveränderlichkeit verhindert Tag-Hijacking und die Replikation lokalisiert Pull-Vorgänge, um die Deployment-Latenz und den Auswirkungsradius (Blast Radius) zu reduzieren.

Bereitstellung zustandsloser APIs auf ECS mit Fargate

Definieren Sie ECS-Aufgabendefinitionen mit awslogs und FireLens für strukturierte Protokolle und Metriken. Aktivieren Sie den Container-healthCheck und stimmen Sie die Health Checks der ALB-Zielgruppe darauf ab. Mounten Sie ein EFS-Volume für gemeinsam genutzte, schreibgeschützte Konfigurationen über einen Access Point. Führen Sie Services auf Fargate mit einer Capacity-Provider-Strategie aus, die Fargate und Fargate Spot für Kosteneffizienz mischt. Warum: Fargate eliminiert die Node-Verwaltung und isoliert Tasks pro ENI; EFS vermeidet das Einbacken von Konfigurationen in Images und unterstützt atomare Rollbacks der Konfiguration.

Sichere Deployments mit Blue/Green und automatisierten Tests

Stellen Sie ECS-Services auf einen CodeDeploy Deployment-Controller um. Konfigurieren Sie zwei Zielgruppen am ALB. Verwenden Sie einen Canary-Shift mit AfterAllowTestTraffic, um einen Lambda-Test-Runner aufzurufen, der kritische Endpunkte innerhalb von 5 Minuten testet. Hängen Sie CloudWatch-Alarme für 5XX-Fehler und p90-Latenz an, um ein Rollback auszulösen. Warum: CodeDeploy Blue/Green isoliert das Risiko, der Test-Hook validiert die Green-Umgebung vor der vollständigen Umstellung und Alarme ermöglichen ein automatisiertes, objektives Rollback.

Latenzempfindliche Operationen auf Lambda mit stabilisierten Kaltstarts

Packen Sie für eine Tokenisierungs-Hilfs-API die Funktion als ZIP-Datei mit schlanken Abhängigkeiten. Erstellen Sie eine Version/einen Alias und aktivieren Sie Provisioned Concurrency, die für Spitzenlasten dimensioniert ist. Steuern Sie die Provisioned Concurrency über Application Auto Scaling mit einem täglichen Zeitplan, der die Release-Fenster berücksichtigt. Verwenden Sie CodeDeploy Canary (10 %/15 Minuten) für eine Alias-basierte Traffic-Verschiebung, die an CloudWatch-Alarme gekoppelt ist. Warum: Provisioned Concurrency eliminiert Kaltstarts bei Lastspitzen; Alias-Canaries ermöglichen eine schrittweise Einführung mit schnellem Rollback.

Externe APIs über API Gateway bereitstellen und private Backends absichern

Schalten Sie API Gateway vor die Lambda-Funktion und den ECS-ALB. Verwenden Sie HTTP-APIs für den Lambda-Proxy, um Kosten und Latenz zu minimieren. Verwenden Sie die REST-API für den ECS-ALB-Pfad, der Anfrage-/Antwort-Mapping und Stage-Caching für leseintensive Endpunkte benötigt. Wenden Sie WAF Web ACLs und Drosselung auf Stage-Ebene an; aktivieren Sie strukturierte Zugriffsprotokolle. Warum: Die Abstimmung der API-Typen auf die Anforderungen optimiert Kosten und Funktionen; Caching reduziert die Last; WAF und Drosselung bieten Schutz bei Ereignisspitzen.

Kontoübergreifende Runtime-Pulls ohne Internet

Fügen Sie in den Runtime-VPCs Interface-Endpunkte für ECR (api, dkr) und CloudWatch Logs sowie einen S3-Gateway-Endpunkt hinzu. Hängen Sie Ressourcenrichtlinien für ECR-Repositories an, um den Task-Ausführungsrollen des Prod-Kontos das Pullen zu ermöglichen. Verwenden Sie einen kundenseitig verwalteten KMS-Schlüssel mit einer kontoübergreifenden Schlüsselrichtlinie für die Image-Verschlüsselung im Ruhezustand. Warum: Private Image-Pulls vermeiden NAT-Kosten und Egress-Risiken; explizite Ressourcen-/Schlüsselrichtlinien erzwingen den kontoübergreifenden Zugriff nach dem Prinzip der geringsten Rechte (Least Privilege).

Dieses Design reduziert den operativen Aufwand (keine Nodes zu verwalten), bietet eine deterministische Latenz durch Provisioned Concurrency und auf ALB-Health-Checks abgestimmte Rollouts und erzwingt die End-to-End-Nachverfolgbarkeit der Image-Herkunft durch ECR-Scanning, Replikation und Unveränderlichkeit.

← Sicherheit · Alle Domänen · Hochverfügbarkeit →

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