3.3 Deployment Strategies

AWS Certified Developer – Associate DVA-C02

Track your progress as you read

Finished sections get a check mark.

1 Introduction: DVA-C02 Overview & Study Plan

1.1 What the AWS Developer Associate Tests 1.2 Exam Format, Scoring & Logistics 1.3 The Four Domains & A Study Plan

2 Chapter 1: Development with AWS Services

1.1 AWS Lambda 1.2 Amazon API Gateway 1.3 Amazon DynamoDB 1.4 Amazon S3 1.5 Messaging: SQS, SNS, EventBridge 1.6 Containers: ECS, ECR, Fargate 1.7 AWS SDK & API Best Practices

3 Chapter 2: Security

2.1 IAM for Developers 2.2 Encryption & AWS KMS 2.3 Secrets Manager vs Parameter Store 2.4 Amazon Cognito

4 Chapter 3: Deployment

3.1 CloudFormation & SAM 3.2 CI/CD with CodePipeline, CodeBuild, CodeDeploy 3.3 Deployment Strategies 3.4 Elastic Beanstalk & Container Deploys

5 Chapter 4: Troubleshooting, Optimization & Exam Strategy

4.1 Observability: CloudWatch & X-Ray 4.2 Performance & Caching 4.3 Common Traps & Final Review

3.3 Deployment Strategies

Key Takeaways Explain This Topic AI

In-place updates the same instances batch by batch (cheaper, brief reduced capacity, slower rollback); blue/green provisions a parallel environment and shifts traffic for zero downtime and near-instant rollback.

CodeDeploy for Lambda and ECS shifts traffic by canary (a slice first, then the rest after a wait), linear (equal increments on a schedule), or all-at-once (everything immediately).

Canary10Percent5Minutes shifts 10% first then the remaining 90% after 5 minutes; Linear10PercentEvery1Minute shifts 10% each minute until complete.

Lambda traffic shifting uses an alias that points partly at the old version and partly at the new version; a CloudWatch alarm can trigger automatic rollback during the shift.

Canary and linear limit blast radius and support automatic rollback; all-at-once is fastest but exposes all users at once.

Last updated: June 2026

In-place vs blue/green

The core deployment decision is in-place vs blue/green , and the exam frames it as a tradeoff between cost and rollback speed.

In-place updates the existing instances, one batch at a time. It is cheaper (no duplicate fleet) but reduces capacity during each batch, and rollback means redeploying the old version — slower and itself risky.

Blue/green stands up a brand-new ( green ) environment beside the running ( blue ) one, shifts traffic to green, and keeps blue intact. This gives zero downtime and near-instant rollback by re-pointing traffic, at the cost of briefly running two full environments.

When a question stresses fastest rollback or no downtime and budget is not the constraint, choose blue/green. When it stresses lowest cost and a short capacity dip is acceptable, choose in-place.

A related vocabulary the exam mixes in: a canary release exposes a small percentage of users to the new version first, linear ramps it in equal steps, and an all-at-once cutover flips everyone at once. These are traffic-shifting patterns that can layer on top of either model, but in practice CodeDeploy ties canary/linear shifting specifically to its blue/green flow for Lambda and ECS.

CodeDeploy traffic shifting (Lambda and ECS)

For Lambda and ECS , CodeDeploy moves traffic to the new version using a deployment configuration :

• Configuration Behavior
• All-at-once Shifts 100% immediately — fastest, riskiest
• Canary Shifts a slice, waits, then the remainder in one jump
• Linear Shifts equal increments on a fixed interval until 100%

The predefined config names encode the numbers exactly: Canary10Percent5Minutes shifts 10% first, then the remaining 90% five minutes later (a two-step pattern); Linear10PercentEvery1Minute shifts 10% every minute for ten minutes. Other built-ins include Canary10Percent30Minutes and LinearEvery1Minute variants.

Lambda aliases and rollback

Lambda traffic shifting works through an alias . CodeDeploy adjusts the alias so it splits traffic between the old version and the new version by weight, raising the new share over the canary or linear schedule. A CloudWatch alarm associated with the deployment triggers automatic rollback if it enters the ALARM state mid-shift, instantly returning the alias to 100% old version. Canary and linear limit the blast radius ; all-at-once does not. You can also add BeforeAllowTraffic / AfterAllowTraffic hooks for pre- and post-shift validation.

ECS blue/green and task sets

For ECS , CodeDeploy blue/green spins up a replacement task set (the green tasks) registered to a second target group behind the same Application Load Balancer, then shifts the listener from the blue target group to green on the same canary/linear/all-at-once schedule. A failed validation hook or a CloudWatch alarm rolls the listener back to the original task set, and the green tasks are terminated. This is why ECS blue/green requires an ALB with two target groups, a detail the exam likes to probe.

API Gateway offers its own lighter-weight traffic management with canary deployments on a stage — you route a percentage of requests to a canary release and promote or discard it — independent of CodeDeploy. Match the service to the question: CodeDeploy for Lambda/ECS/EC2, API Gateway stage canary for API-only rollouts.

Quick decision guide

Use this mapping when a scenario describes a constraint:

• Requirement in the question Pick
• Lowest cost, brief capacity dip OK In-place / Beanstalk Rolling
• Zero downtime, instant rollback, budget OK Blue/green
• Test new version on a small slice first Canary
• Ramp new version smoothly in equal steps Linear
• Auto-revert if error/latency alarm fires CloudWatch alarm on a CodeDeploy deployment
• Beanstalk, never drop below full capacity Rolling with additional batch or Immutable

One more nuance: CodeDeploy supports a rollback on alarm and a rollback on deployment failure , and you can disable automatic rollback to inspect a bad release. The exam rewards recognizing that the fastest rollback always comes from a strategy that keeps the old version intact (blue/green, immutable, weighted-alias canary) rather than from redeploying old code in place.

Elastic Beanstalk deployment policies

Beanstalk has its own policies, each trading speed against availability and rollback safety. This table is among the most heavily tested in the domain:

• Policy Downtime Capacity during deploy Deploys to Rollback
• All at once Yes (brief) N/A Existing instances Manual redeploy
• Rolling No Reduced (one batch out) Existing instances Manual redeploy
• Rolling + additional batch No Full (extra batch added) New + existing Manual redeploy
• Immutable No Full New instances (2nd ASG) Terminate new instances
• Blue/green No Full New environment Swap URL (CNAME) back

Key distinctions: Rolling reduces capacity because a batch is pulled out of service; Rolling with additional batch maintains full capacity by launching one extra temporary batch first, then retiring it at the end. Immutable deploys to all-new instances in a second Auto Scaling group, giving the safest in-environment rollback (just terminate the new ASG) but the longest time and highest cost. Blue/green is a separate environment plus a CNAME swap , so it needs a DNS change but gives the cleanest cutover and instant rollback. All-at-once is the only Beanstalk policy that causes downtime.