3.3 Deployment Strategies
Key Takeaways
- 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.
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.
A regulated team must keep full request-serving capacity at every moment during an Elastic Beanstalk deployment and cannot tolerate any reduced availability, but wants to update instances within the existing environment rather than swapping URLs. Which deployment policy fits best?
A serverless team deploys a Lambda function with CodeDeploy using CodeDeployDefault.LambdaCanary10Percent5Minutes. What traffic pattern does this produce?
During a CodeDeploy blue/green Lambda deployment, error rates spike on the new version while a portion of traffic is on it. What is the fastest way to make rollback automatic when this happens?