Amazon DOP-C02: CI/CD-Pipelines und Deployment-Strategien — 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

Ein robustes CI/CD-System auf AWS verbindet Quellcodeverwaltung, Build, Test, Artefakt-Governance, Deployment-Orchestrierung und sichere Release-Strategien über mehrere Konten und Regionen hinweg. Die zentralen Managed Services – CodeCommit, CodeArtifact, CodeBuild, CodePipeline und CodeDeploy – eliminieren die Serverwartung, integrieren sich eng mit IAM und KMS und bieten erstklassige Unterstützung für Blue/Green-, Canary-, Rolling- und In-Place-Deployments auf EC2/Auto Scaling, ECS und Lambda. Effektive Pipelines basieren zudem auf präzisen Auslösern (Webhooks, EventBridge, Zeitpläne), diszipliniertem Artefakt-Management, Build-Caching zur Beschleunigung und gezielter Traffic-Verschiebung mit Zustandsalarmen für automatische Rollbacks. Für Unternehmen sind konto- und regionsübergreifende Muster zwingend erforderlich, was die Übernahme von Rollen (Role Assumption), regionale Artefaktspeicher und konsistente Verschlüsselungsrichtlinien erfordert.

Orchestrierung mit AWS Developer Tools

Verwenden Sie CodeCommit als privaten, hochverfügbaren Git-Dienst. Er integriert sich mit EventBridge für Repository- und Pull-Request-Ereignisse, unterstützt Vorlagen für Genehmigungsregeln (Approval Rule Templates) und nutzt IAM für eine feingranulare Autorisierung. Für Git von Drittanbietern (GitHub/Bitbucket) konfigurieren Sie CodePipeline-Quellaktionen (Source Actions) mit Webhooks für nahezu echtzeitbasierte Auslöser.

CodeArtifact zentralisiert die Paketverwaltung für verschiedene Ökosysteme (npm, Maven, PyPI, NuGet). Es unterstützt Upstream-Verbindungen zu öffentlichen Registries mit Caching, repository-spezifische KMS-Verschlüsselung und bereichsbezogene Authentifizierungstoken (scoped auth tokens), die automatisch ablaufen. Integrieren Sie es in CodeBuild, indem Sie während pre_build den Befehl

undefined

aufrufen, um Paketmanager zu konfigurieren, ohne langlebige Secrets fest zu hinterlegen.

CodeBuild stellt ephemere, containerisierte Builds bereit, ohne dass Worker verwaltet werden müssen. Wichtige Funktionen:

• Umgebungsisolierung und VPC-Unterstützung für private Abhängigkeiten. Aktivieren Sie den privilegierten Modus für Docker-Builds und das lokale Docker-Layer-Caching, um die Erstellung von Images zu beschleunigen.
• Umgebungsvariablen aus drei Quellen: Klartext, SSM Parameter Store und Secrets Manager (standardmäßig sicher, keine hartcodierten Secrets). Sie können auch Variablen von CodePipeline übergeben.
• Caching zur Reduzierung der Build-Zeiten:
  • Lokales Caching: Quellcode-Cache, Docker-Layer-Cache und benutzerdefinierte Verzeichnisse auf dem Build-Host.
  • S3-Caching: wiederverwendbare Abhängigkeitssätze, die über Builds hinweg geteilt werden.
• Artefakt-Management: Geben Sie primary und secondaryArtifacts an, um mehrere Ausgaben zu veröffentlichen (z. B. App-Bundle und CloudFormation-Template). Verschlüsseln Sie Artefakte mit KMS-Schlüsseln und vermeiden Sie öffentliche ACLs.
• Reporting: Senden Sie Protokolle an CloudWatch Logs/S3. Verwenden Sie Berichte für Testergebnisse und CodeBuild-Badges für PR-Feedback.

CodePipeline ist der Orchestrator. Definieren Sie Phasen (Source, Build, Test, Deploy, Approval) mit Aktionen, die parallel oder sequenziell ausgeführt werden können. Best Practices:

• Auslöser:
  • Webhooks für GitHub/Bitbucket-Quellen.
  • EventBridge-Regeln für Branch-Änderungen in CodeCommit; überprüfen Sie die Existenz der Regel, wenn Pipelines nicht starten.
  • Geplante Pipelines über EventBridge-Zeitplanregeln, die StartPipelineExecution aufrufen.
• Artefaktspeicher: ein S3-Bucket pro Region, der von der Pipeline verwendet wird; nutzen Sie einen kundenverwalteten KMS-Schlüssel. Fügen Sie für regionsübergreifende Aktionen regionale Artefaktspeicher hinzu.
• Manuelle Genehmigungen mit SNS oder EventBridge zur Integration von Chat/Webhooks für Benachrichtigungen in nahezu Echtzeit.
• Feingranulares IAM: eine Pipeline-Servicerolle mit den geringsten Rechten (Least Privilege); für kontoübergreifende Operationen werden rollenbasierte Berechtigungen pro Aktion übernommen.

CodeDeploy ist die Deployment-Engine, die EC2/On-Premises-, ECS- und Lambda-Ziele unterstützt. Es verwaltet Lifecycle-Hooks, Traffic-Verschiebung, Zustandsprüfungen (Health Checks) und automatische Rollbacks über CloudWatch-Alarme. Stellen Sie sicher, dass auf EC2-Instanzen der CodeDeploy-Agent ausgeführt wird, sie ein Instanzprofil haben und eine ausgehende Konnektivität zu den CodeDeploy-Endpunkten besteht (oder der ausgehende Verkehr über ein NAT-Gateway geleitet wird). Übersprungene Ereignisse und No-Op-Deployments (Bereitstellungen ohne Operation) deuten oft auf Probleme mit dem Agenten, den Berechtigungen oder der Konnektivität hin.

Bereitstellungsstrategien und CodeDeploy-Lebenszyklus

Wählen Sie die Strategie nach Risiko, Kapazität und Plattform aus:

• In-place (EC2/On-Premises): Aktualisiert die Anwendung auf bestehenden Instanzen. Kombinieren Sie dies mit den Bereitstellungskonfigurationen OneAtATime, HalfAtATime oder AllAtOnce. Hängen Sie einen ELB an, um Instanzen zu entleeren (drain) und neu zu registrieren.
• Rolling (ECS): Ersetzt Tasks in Batches innerhalb desselben Service. Natives ECS-Rolling oder verwaltet über CodeDeploy als Blue/Green mit kontrollierter Verschiebung.
• Blue/Green:
  • EC2/Auto Scaling: Eine grüne ASG bereitstellen, validieren und dann den Traffic von Blau auf Grün umschalten. Optional kann die blaue Umgebung beendet oder beibehalten werden.
  • ECS: Einen Ersatz-Task-Satz hinter einer zweiten Zielgruppe erstellen; validieren und dann die Listener umschalten.
  • Lambda: Alias-Traffic auf eine neue Funktionsversion verschieben und überwachen.
• Canary: Zuerst einen kleinen Prozentsatz verschieben (z. B. 10 %), für einen bestimmten Zeitraum beobachten und dann abschließen.
• Linear: Den Traffic in gleichen Schritten erhöhen (z. B. 10 % alle 5 Minuten).

Die CodeDeploy appspec.yml definiert, was installiert und wann Skripte ausgeführt werden sollen:

• Für EC2/On-Premises (YAML):
  • files: wo Dateien platziert werden sollen.
  • permissions: Aktualisierungen von Dateibesitz/Modus ohne benutzerdefinierte Skripte.
  • hooks (allgemein): ApplicationStop, BeforeInstall, Install, AfterInstall, ApplicationStart, ValidateService.
  • Hooks zur Traffic-Steuerung (bei Verwendung eines Load Balancers): BeforeBlockTraffic, AfterBlockTraffic, BeforeAllowTraffic, AfterAllowTraffic.
  • Verwenden Sie vordefinierte Umgebungsvariablen (z. B. DEPLOYMENT_GROUP_NAME, DEPLOYMENT_ID, LIFECYCLE_EVENT), um das Verhalten dynamisch ohne separate Revisionen zu ändern, z. B. das Umschalten von Apache-Log-Levels pro Bereitstellungsgruppe.
• Für ECS:
  • resources: TargetService mit TaskDefinition und LoadBalancerInfo.
  • hooks: BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, AfterAllowTraffic.
  • AfterAllowTestTraffic ist ideal für Smoke-/Integrationstests auf dem grünen Task-Satz mit einem Test-Listener.
• Für Lambda:
  • resources definieren die Funktion, Version und den Alias, der verschoben werden soll.
  • hooks: BeforeAllowTraffic und AfterAllowTraffic.

Traffic-Verschiebung und Rollback:

• Konfigurieren Sie Bereitstellungskonfigurationen:
  • Lambda/ECS: Canary10Percent15Minutes, Canary10Percent5Minutes, Linear10PercentEvery1Minute, AllAtOnce oder benutzerdefiniert.
  • EC2 Blue/Green: All-at-once-, Canary- oder lineare Traffic-Umleitung über die Listener/Zielgruppen des Load Balancers.
• Fügen Sie der Bereitstellungsgruppe CloudWatch-Alarme hinzu, um bei Fehlern, 5xx-Statuscodes oder benutzerdefinierten Metriken ein automatisches Rollback durchzuführen. Bei ECS können Alarme die 5xx-Metriken der Zielgruppe oder Service-Metriken überwachen; bei Lambda überwachen Sie die Funktionsmetriken Errors/Throttles mit Alias-/Versions-Dimensionen.
• Verwenden Sie Lifecycle-Hooks (z. B. AfterAllowTestTraffic), um die Validierung über Lambda oder SSM auszuführen; ein Beenden mit einem Exit-Code ungleich Null führt zu einem Rollback.

Blue/Green und Traffic-Verschiebung für EC2, ECS und Lambda

EC2/Auto Scaling:

• Blue/Green mit CodeDeploy stellt eine neue Auto Scaling-Gruppe für Grün bereit, verknüpft sie mit einer separaten Zielgruppe und schaltet dann die ALB-Listener um. Sie können wählen, ob Blau automatisch beendet oder für ein schnelles Rollback beibehalten werden soll.
• Bei In-Place-Bereitstellungen auf EC2 kombinieren Sie dies mit einem ELB, um die Registrierung von Instanzen ordnungsgemäß aufzuheben/wiederherzustellen und die Verfügbarkeit zu schützen. Die Bereitstellungskonfiguration bestimmt die Batch-Größen und das Tempo.

ECS:

• CodeDeploy integriert sich mit ECS-Services unter Verwendung von zwei Zielgruppen hinter einem ALB. Ein Ersatz-Task-Satz (Grün) wird mit der neuen Task-Definition erstellt.
• Test-Traffic fließt über einen dedizierten Test-Listener zur grünen Zielgruppe; der Produktions-Traffic bleibt bis zur Hochstufung (Promotion) auf Blau.
• Canary- oder lineare Verschiebungen leiten den Traffic schrittweise auf Grün um, während CloudWatch-Alarme überwacht werden. Verwenden Sie AfterAllowTestTraffic, um die Validierung (z. B. eine Lambda-Funktion, die synthetische Prüfungen aufruft) vor der Umstellung auf die Produktion durchzuführen.

Lambda:

• CodeDeploy aktualisiert einen Funktions-Alias auf eine neue Version mit gewichtetem Routing. Canary- und lineare Muster verschieben den prozentualen Traffic schrittweise. CloudWatch-Alarme auf dem Alias steuern das automatische Rollback.
• Mit AWS SAM oder CDK können Sie AutoPublishAlias und DeploymentPreference in Vorlagen festlegen, um Canary-/lineare Richtlinien und Alarme pro Funktion zu kodieren.

Gewichtetes Routing über CodeDeploy hinaus:

• Für Multi-Region- oder Multi-Stack-Balancing bieten gewichtete Einträge (Weighted Records) von Route 53 mit Zustandsprüfungen (Health Checks) eine regionale Aufteilung des Traffics (z. B. 1 % an eine sekundäre Region) und Failover. Dies ergänzt, ersetzt aber nicht die Traffic-Verschiebung pro Service von CodeDeploy.

Konto- und regionenübergreifende Bereitstellung

Enterprise-Pipelines befinden sich typischerweise in einem zentralisierten „Tooling“-Konto und stellen Anwendungen in Entwicklungs-, Test- und Produktionskonten über mehrere Regionen hinweg bereit:

• Kontenübergreifend:
  • Geben Sie in CodePipeline-Aktionen eine RoleArn im Zielkonto an, die dem Principal der Pipeline-Rolle vertraut. Verwenden Sie für jede Aktion (CloudFormation, CodeDeploy, ECS, Lambda) Berechtigungen nach dem Prinzip der geringsten Rechte (Least Privilege).
  • Wenn CodeBuild auf Ressourcen im Zielkonto zugreifen muss, lassen Sie den Build eine Rolle annehmen (STS) oder verwenden Sie eine aktionsspezifische Rolle pro Konto, anstatt weitreichenden AdministratorAccess zu gewähren.
  • Bei CodeDeploy für EC2 verwaltet das Zielkonto die Anwendungs-/Bereitstellungsgruppe und die Service-Rolle; die Pipeline nimmt eine Rolle an, um CreateDeployment aufzurufen.
• Regionenübergreifend:
  • Fügen Sie pro Region einen Artefaktspeicher in der Pipeline-Konfiguration hinzu (ein S3-Bucket mit einem regionalen KMS-Schlüssel). Aktualisieren Sie die Bucket-Richtlinien, um der Pipeline-Rolle und den aktionsspezifischen Rollen Lese-/Schreibzugriff zu gewähren.
  • Erstellen Sie bei Bedarf regionsspezifische Artefakte (z. B. durch Verpacken von Lambda-Code mit dem Befehl aws cloudformation package, der auf einen regionenlokalen S3-Bucket abzielt).
  • CloudFormation-Bereitstellungsaktionen in einer entfernten Region müssen auf den Artefaktspeicher der Region verweisen und können eine Stack-Ausführungsrolle im Zielkonto für das Prinzip der geringsten Rechte angeben.

Sicherheit, Artefakte und Governance:

• Halten Sie Artefakt-Buckets privat; vermeiden Sie öffentliche ACLs wie authenticated-read. Verlassen Sie sich auf Bucket-Richtlinien, die auf Pipeline- und Aktionsrollen beschränkt sind, mit KMS-Verschlüsselung.
• Standardisieren Sie Buildspecs, um Artefakte vorhersagbar zu pushen (z. B. Anwendungs-Bundle für EC2/CodeDeploy, taskdef.json und appspec für ECS, gepackte Vorlagen für Lambda).
• Fördern Sie die Unveränderlichkeit durch „Pre-Baking“ von AMIs für EC2, damit der CodeDeploy-Agent und die Basis-Laufzeitumgebung konsistent sind; dies reduziert Drift und die Bereitstellungszeit.
• Verwenden Sie EventBridge-Regeln, um Pipeline-Ereignisse in Benachrichtigungen, ChatOps oder Ticketing zu spiegeln und um manuelle Genehmigungsschritte (Gates) zu orchestrieren.

Praktisches Problemszenario

Spotify benötigt sicherere Releases für Hunderte von Microservices mit einer gemischten Compute-Infrastruktur (ECS on Fargate, EC2-basierte Dienste und Lambda). Sie fordern Canary- und Blue/Green-Deployments mit automatisierten Tests vor der Umleitung des Produktionsverkehrs, Artefakt-Governance und eine regionenübergreifende Beförderung (Promotion), während die Produktionsumgebung in einem separaten Konto verbleibt.

1. Repositories und Pakete einrichten

• Verwenden Sie CodeCommit für private Repos und eine durch EventBridge gesteuerte PR-/Testautomatisierung. CodeArtifact hostet npm-, Maven- und PyPI-Abhängigkeiten mit Upstreams und KMS-Verschlüsselung, um die Kontrollen der Lieferkette (Supply Chain) zu standardisieren. Warum: Zentrale IAM/KMS-Integration und keine externen Webhooks für kritische Repos erforderlich; CodeArtifact bietet zwischengespeicherte, kuratierte Pakete.

2. Build und Test

• Erstellen Sie CodeBuild-Projekte pro Service mit VPC-Integration, lokalem Caching (Docker-Layer und Quellcode) und Umgebungsvariablen aus dem Secrets Manager/Parameter Store. Erstellen Sie Images und pushen Sie sie nach ECR; generieren Sie sekundäre Artefakte (taskdef.json/appspec.yaml oder gepackte CloudFormation-Vorlagen). Warum: Ephemere, isolierte Builds, sichere Handhabung von Secrets, schnellere Zyklen durch Caching und mehrere Ausgaben unterstützen sowohl Container- als auch Serverless-Packaging.

3. Pipelines orchestrieren

• Erstellen Sie eine zentralisierte CodePipeline in einem Tooling-Konto mit den Phasen: Source, Build, Unit-Tests, Deploy-to-Staging, Automatisierte Tests, Manuelle Genehmigung, Deploy-to-Prod. Trigger werden durch EventBridge bei CodeCommit-Updates ausgelöst; eine nächtlich geplante EventBridge-Regel startet Integrationstests. Warum: Ein vorgegebener (opinionated), auditierbarer Ablauf mit Gates und sowohl ereignis- als auch zeitplangesteuerten Ausführungen.

4. Blue/Green- und Canary-Deployments

• ECS-Services verwenden CodeDeploy Blue/Green mit zwei Zielgruppen und Canary-Traffic-Shifting; die Validierung läuft in der Phase AfterAllowTestTraffic über eine Lambda-Funktion, die Vertragstests und synthetische Prüfungen ausführt. EC2-Services verwenden CodeDeploy In-Place mit OneAtATime oder Blue/Green-ASG-Swaps, wenn die Kapazität es zulässt. Lambda-Funktionen werden mit CodeDeploy unter Verwendung von Canary10Percent15Minutes und CloudWatch-Alarmen für Errors und 5xx-Fehler vom API Gateway bereitgestellt. Warum: Erstklassige Steuerung des Traffics pro Laufzeitumgebung und automatisches Rollback bei Alarmüberschreitungen minimieren die Auswirkungen auf den Kunden.

5. Konto- und regionenübergreifende Beförderung (Promotion)

• Die Pipeline nimmt umgebungsspezifische Rollen in den Entwicklungs-, Test- und Produktionskonten an. Konfigurieren Sie für us-east-1 und eu-west-1 regionale Artefaktspeicher und regionale KMS-Schlüssel; CodeBuild produziert regionsspezifische gepackte Vorlagen und lädt Artefakte in regionenlokale Buckets hoch. CloudFormation-Aktionen in jedem Konto/jeder Region verwenden Stack-Ausführungsrollen; CodeDeploy-Aktionen zielen auf umgebungsspezifische Anwendungs-/Bereitstellungsgruppen ab. Warum: Starke Isolierung der Produktion, geringste Rechte (Least Privilege) durch Rollenübernahme und konforme Verschlüsselung bei geringem Betriebsaufwand.

6. Artefakt-Governance und Sicherheit

• Erzwingen Sie private S3-Artefakt-Buckets mit restriktiven Richtlinien und entfernen Sie alle öffentlichen ACLs. Signieren Sie Container-Images und Vorlagen; speichern Sie SBOMs als Build-Artefakte. Verwenden Sie IAM Condition Keys, um Produktionsaktionen auf Pipelines im Tooling-Konto zu beschränken. Warum: Verhindert Datenlecks, verbessert die Nachverfolgbarkeit (Provenance) und entspricht den Best Practices für die Lieferkette.

7. Observability und Benachrichtigungen

• Fügen Sie allen Bereitstellungsgruppen CloudWatch-Alarme hinzu; EventBridge-Regeln leiten Ausführungs- und Genehmigungsereignisse von CodePipeline an ein SNS-Thema und eine Lambda-Funktion weiter, die in Slack postet. Warum: Schnelleres Feedback, automatisierte Rollbacks und bei Bedarf manuelle Genehmigungen durch einen Menschen (Human-in-the-Loop).

Dieses Design vereinheitlicht heterogene Laufzeitumgebungen unter einer einzigen verwalteten Toolchain, bietet sichere Rollout-Strategien mit automatisierter Verifizierung, reduziert den Wartungsaufwand durch den Wegfall selbst gehosteter CI/CD-Infrastruktur und skaliert global mit einer klaren Trennung der Zuständigkeiten (Separation of Duties).

Alle Domänen · Infrastruktur als Code und Konfigurationsmanagement →

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

Amazon durchsuchen →