Study guide
3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda
AWS Certified DevOps Engineer – Professional Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CI/CD Pipeline Architecture & Source Integration
1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models
2 Chapter 2: Automated Testing, Test Gates & Quality Verification
2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates
3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies
3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda
4 Chapter 4: CloudFormation, CDK & Reusable IaC Components
4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance
5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower
5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation
6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration
6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig
7 Chapter 7: High Availability & Multi-Region Resiliency
7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR
8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation
8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery
9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation
9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions
10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray
10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps
11 Chapter 11: Automated Observability & Event-Driven Monitoring
11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries
12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines
12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling
13 Chapter 13: Automated Remediation & Deployment Troubleshooting
13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures
14 Chapter 14: Identity, Access Management & Secrets at Scale
14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager
15 Chapter 15: Security Automation, Data Protection & Compliance Auditing
15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config
3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda
Key Takeaways Explain This Topic AI
AWS CodeDeploy manages progressive blue/green deployments for Amazon ECS by launching a green task set, routing test traffic via an ALB test listener, validating health, and swapping production target groups.
Canary and linear traffic shifting configurations (such as ECSLinear10PercentEvery1Minute or LambdaCanary10Percent30Minutes) control the rate of traffic migration to limit defect blast radius.
AWS Lambda alias traffic shifting relies on weighted routing between published version ARNs, managed via AWS SAM deployment preferences and validated by PreTraffic and PostTraffic hook functions.
Lifecycle hook Lambda functions for serverless deployments must explicitly invoke the codedeploy.putLifecycleEventHookExecutionStatus API with Succeeded or Failed to prevent deployment timeouts.
Amazon EKS manages progressive delivery using Kubernetes native rolling updates (maxSurge, maxUnavailable) with container readiness probes, or advanced ingress-based service meshes and controllers like Argo Rollouts and Flagger.
Last updated: September 2026
Progressive Delivery Overview
Progressive delivery builds upon continuous delivery by gradually rolling out new software versions while measuring real-time telemetry and error budgets. In microservices and serverless architectures, deploying updates all at once exposes the entire customer base to latent regressions. For the DOP-C02 exam, you must master the mechanics of progressive delivery across three compute platforms:
Amazon Elastic Container Service (ECS) : Managed blue/green deployments using AWS CodeDeploy and Application Load Balancer dual-listener routing.
AWS Lambda : Alias traffic shifting using AWS Serverless Application Model (SAM) and CodeDeploy lifecycle hooks.
Amazon Elastic Kubernetes Service (EKS) : Native rolling updates with readiness probes and progressive delivery operators (Argo Rollouts / Flagger).
Amazon ECS Blue/Green Deployments with AWS CodeDeploy
To perform automated blue/green deployments on Amazon ECS, the ECS service must be configured with the CODE_DEPLOY deployment controller rather than the default ECS rolling controller.
Application Load Balancer Architecture Requirements
An ECS blue/green deployment orchestrated by CodeDeploy requires a specific Application Load Balancer (ALB) network topology: +---------------------------------+
- | Application Load Balancer |
- +----------------+----------------+
- |
- +-----------------------+-----------------------+
- | |
- v v
- +--------------------+ +-------------------+
- | Production Listener| | Test Listener |
- | (Port 443) | | (Port 8443) |
- +---------+----------+ +---------+---------+
- | |
- [Initial State: 100% Traffic] [Test Traffic: Synthetic Validation]
- | |
- v v
- +--------------------+ +-------------------+
- | Target Group 1 | | Target Group 2 |
- | (Blue / Old) | | (Green / New) |
- +---------+----------+ +---------+---------+
- | |
- v v
- +--------------------+ +-------------------+
- | Original Task Set | |Replacement TaskSet|
- | (ECS Revision 1) | | (ECS Revision 2) |
- +--------------------+ +-------------------+
Two Target Groups : TargetGroup1 (Blue) and TargetGroup2 (Green). At any given time, one receives production traffic while the other stands by or receives test traffic.
Production Listener (e.g., Port 443) : Directs live customer traffic to the current active production target group.
Test Listener (e.g., Port 8443) : Directs internal verification traffic exclusively to the replacement target group before production traffic is shifted.
ECS Deployment Workflow & Lifecycle Hooks
When a new ECS Task Definition revision is registered, the CodeDeploy workflow executes as follows:
Create Replacement Task Set : CodeDeploy launches the desired count of replacement (green) container tasks.
Route Test Traffic ( AfterAllowTestTraffic ) : The test listener on port 8443 is pointed to the green target group. CodeDeploy triggers an optional Lambda function hook ( AfterAllowTestTraffic ) to run automated synthetic integration tests against port 8443.
Shift Production Traffic : If tests succeed, CodeDeploy initiates production traffic shifting on the main listener (port 443) according to the configured traffic routing strategy.
Post-Traffic Validation ( AfterAllowTraffic ) : After 100% of production traffic is routed to the green target group, a second Lambda hook runs final validation.
Blue Task Set Termination : The original blue task set is kept alive for a configurable termination wait time (e.g., 60 minutes) to allow instant, zero-downtime rollback before tasks are permanently drained and terminated.
Traffic Shifting Configurations for ECS
CodeDeployDefault.ECSAllAtOnce : 100% of traffic shifts immediately from Blue to Green.
CodeDeployDefault.ECSLinear10PercentEvery1Minute : Traffic shifts 10% each minute over 10 equal increments.
CodeDeployDefault.ECSCanary10Percent5Minutes : Shifts 10% of traffic initially, waits 5 minutes to monitor CloudWatch alarms, then shifts the remaining 90% in a single batch.
ECS appspec.yaml Definition version: 0.0
Resources:
- TargetService:
Type: AWS::ECS::Service
Properties:
TaskDefinition: "arn:aws:ecs:us-east-1:123456789012:task-definition/payment-api:14"
LoadBalancerInfo:
- ContainerName: "payment-container"
- ContainerPort: 8080
CapacityProviderStrategy:
- CapacityProvider: "FARGATE"
- Weight: 1
Hooks:
- AfterAllowTestTraffic: "arn:aws:lambda:us-east-1:123456789012:function:ValidatePaymentGreenTask"
- AfterAllowTraffic: "arn:aws:lambda:us-east-1:123456789012:function:PostDeploymentSanityCheck"
- Serverless Progressive Deployments with AWS Lambda & AWS SAM
When deploying serverless microservices, deploying new AWS Lambda code directly to an unqualified function ARN modifies execution instantly. AWS Lambda Version Aliases enable progressive delivery by shifting traffic weights between two immutable published versions (e.g., 90% to Version 1, 10% to Version 2).
AWS SAM DeploymentPreference Syntax
Using the AWS Serverless Application Model (SAM), alias traffic shifting is configured declaratively under DeploymentPreference : AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
OrderProcessingFunction:
Type: AWS::Serverless::Function
Properties:
- Handler: index.handler
- Runtime: nodejs20.x
- CodeUri: ./src
- AutoPublishAlias: live
DeploymentPreference:
Type: Canary10Percent10Minutes
Alarms:
- !Ref OrderFunction5xxErrorsAlarm
- !Ref OrderFunctionLatencyAlarm
Hooks:
- PreTraffic: !Ref ValidateOrderProcessingHook
- PostTraffic: !Ref PostDeploymentValidationHook
- Lifecycle Validation Hooks Contract ( putLifecycleEventHookExecutionStatus )
The PreTraffic and PostTraffic hooks reference independent AWS Lambda functions that perform health validation:
PreTraffic Hook : Executes before any traffic shifts to the new version. Tests database migrations, cache warming, or schema compatibility.
PostTraffic Hook : Executes after 100% of traffic has shifted to the new version.
Exam Trap : A hook Lambda function MUST explicitly call the AWS CodeDeploy API PutLifecycleEventHookExecutionStatus returning either Succeeded or Failed . If this API call is omitted, CodeDeploy blocks waiting for a status until it reaches the default 1-hour timeout and fails the deployment! const { CodeDeployClient, PutLifecycleEventHookExecutionStatusCommand } = require("@aws-sdk/client-codedeploy");
const codedeploy = new CodeDeployClient();
- exports.handler = async (event) => {
- const deploymentId = event.DeploymentId;
- const lifecycleEventHookExecutionId = event.LifecycleEventHookExecutionId;
- let status = 'Succeeded';
- try {
- // Execute synthetic integration test against newly published Lambda version
- await runSmokeTests();
- } catch (err) {
- console.error("Smoke tests failed!", err);
- status = 'Failed';
- }
- const params = {
- deploymentId: deploymentId,
- lifecycleEventHookExecutionId: lifecycleEventHookExecutionId,
- status: status
- };
- await codedeploy.send(new PutLifecycleEventHookExecutionStatusCommand(params));
- };
- Kubernetes / Amazon EKS Progressive Delivery Patterns
In Amazon EKS, deployments can be orchestrated using either native Kubernetes rolling update semantics or advanced progressive delivery operators.
Native Kubernetes Rolling Updates
Kubernetes Deployment resources manage pod replacements using the RollingUpdate strategy controlled by two parameters: spec:
strategy:
type: RollingUpdate
rollingUpdate:
- maxSurge: 25%
- maxUnavailable: 0
maxSurge : The maximum number of pods that can be created above the desired replica count during an update (e.g., 25% or absolute count 2 ).
maxUnavailable : The maximum number of pods that can be unavailable during the process. Setting maxUnavailable: 0 ensures that 100% of desired application capacity is maintained at all times.
Health Probes
Rolling updates rely on container Readiness Probes ( readinessProbe ). Until a newly launched pod passes its readiness probe, the Kubernetes endpoint controller refrains from adding the pod IP to the Service endpoints, ensuring live traffic is never routed to uninitialized containers.
Advanced Progressive Delivery: Argo Rollouts & Flagger
For enterprise progressive delivery in EKS, native rolling updates lack automated traffic shifting and automated metric analysis. Modern EKS platforms adopt Argo Rollouts or Flagger :
Argo Rollouts : Replaces the Kubernetes Deployment object with a custom Rollout CRD. Integrates with the AWS Load Balancer Controller (TargetGroupBinding) or ingress controllers to execute canary shifting (e.g., 5% -> 20% -> 50% -> 100%).
Automated Metric Analysis : Queries Prometheus or Amazon CloudWatch during each canary step. If HTTP 5xx error rates exceed thresholds or latency spikes, the controller automatically halts the rollout and rolls back traffic instantly without human intervention.
Progressive Delivery Decision Matrix
Attribute Amazon ECS Blue/Green AWS Lambda Alias Shifting EKS Native Rolling EKS Argo Rollouts / Flagger
Traffic Routing Layer Application Load Balancer AWS Lambda Service Alias Kube-Proxy / CoreDNS ALB Ingress / Service Mesh
Traffic Shifting Control CodeDeploy (Linear / Canary) CodeDeploy (Linear / Canary) Pod replacement ratio Metric-driven step-shifting
Validation Hooks Lambda (AfterAllowTestTraffic) Lambda (PreTraffic / Post) Readiness / Liveness Probes AnalysisTemplates (CloudWatch/Prometheus)
Rollback Mechanism Re-route ALB target group Revert Lambda Alias weight Rollout undo deployment Automated metric-driven rollback
Rollback Timing Depends on target health and ALB traffic routing Depends on alias update and invocation propagation Depends on pod scheduling, startup, and readiness Depends on controller analysis and traffic-provider reconciliation