Deployment strategy is where the AWS Certified DevOps Engineer – Professional (DOP-C02) exam separates people who use a pipeline from people who design one. Anyone can push code; the exam wants to know whether you can push it in a way that limits blast radius, shifts traffic safely, validates health automatically, and rolls back the instant something breaks — all without a human watching a dashboard at 2 a.m.
This guide is written from a practitioner’s perspective. We’ll work through the deployment strategies AWS expects you to know — in-place, blue/green, canary, linear, and all-at-once — and, more importantly, how AWS CodeDeploy implements them differently across EC2, ECS, and Lambda. Deployment strategies sit in the largest scored domain, SDLC Automation, so getting this right pays off across a big chunk of the exam. If you want the full blueprint first, start with the AWS DevOps Engineer Professional exam guide, then come back here to go deep on deployments.
Why Deployment Strategy Is a Whole Exam Topic
Every deployment is a trade-off between three things: speed, cost, and risk. Deploy everything at once and you’re fast and cheap but exposed — a bad release hits 100% of users instantly. Stand up a parallel environment and shift traffic gradually and you cut risk dramatically, but you pay for double capacity and the rollout takes longer.
The DOP-C02 exam almost never asks “what is blue/green?” in isolation. Instead it hands you a scenario — a regulated workload that can’t tolerate downtime, a Lambda function behind an API that must validate before full rollout, an ECS service that needs instant rollback — and asks you to pick the strategy and the AWS mechanism that satisfies the constraints at the lowest cost. That means you need the concepts and the service-specific implementation together.
The Five Deployment Strategies You Must Know
Before mapping to AWS services, lock down the vocabulary. These terms recur throughout the exam.
| Strategy | How it works | Downtime | Rollback speed | Cost |
|---|---|---|---|---|
| All-at-once | Update every instance simultaneously | Yes (brief) | Slow (redeploy old version) | Lowest |
| In-place (rolling) | Update instances in batches, one group at a time | Reduced capacity, no full outage | Slow (redeploy) | Low |
| Blue/green | Provision a new “green” environment, shift traffic, retire “blue” | None | Instant (shift traffic back) | Higher (double environment) |
| Canary | Shift a small % of traffic first, then the rest in one later step | None | Instant | Higher |
| Linear | Shift traffic in equal increments on a fixed interval | None | Instant | Higher |
Two of these — canary and linear — are really traffic-shifting patterns that run on top of a blue/green deployment. Keep that mental hierarchy: blue/green is the environment model; canary and linear describe how fast you move traffic from blue to green.
All-at-Once and In-Place
An all-at-once deployment replaces the running version on every target in one shot. It’s the cheapest and fastest, but there’s a moment of unavailability and any failure is total. In-place (also called rolling) improves on this by updating instances in batches — half the fleet, then the other half — so the service stays partially available. The catch: during the deploy you’re running mixed versions, and rollback means redeploying the previous revision, which is not instantaneous. In-place also mutates existing infrastructure, so a failed deploy can leave instances in a bad state.
Blue/Green
A blue/green deployment provisions a separate set of resources (green) running the new version alongside the current one (blue). You validate green, then flip traffic — typically at the load balancer or DNS layer. Because blue stays running untouched, rollback is as simple as pointing traffic back. The cost is that you briefly run two full environments. This is the go-to answer whenever a scenario says “zero downtime” and “fast rollback” in the same breath.
Canary vs. Linear
Both shift traffic gradually to reduce blast radius, and the exam loves to test the difference:
- Canary shifts a fixed percentage first (say 10%), holds for a bake time while you watch metrics, then shifts the remaining 90% in a single step. Think: “test with a small group, then go all in.”
- Linear shifts traffic in equal increments at a fixed interval — for example 10% every 3 minutes until 100%. Think: “steady, predictable ramp.”
If a question emphasizes “a small initial exposure, then full rollout,” that’s canary. If it emphasizes “gradual, evenly-paced increase,” that’s linear.
How CodeDeploy Implements These Strategies
AWS CodeDeploy is the service that orchestrates deployments, and it behaves differently depending on the compute platform. This platform-specific behavior is the single most testable thing in this topic.
CodeDeploy for EC2/On-Premises
For the EC2/On-Premises platform, CodeDeploy supports in-place and blue/green deployments. It uses the CodeDeploy agent installed on each instance and an appspec.yml file that defines lifecycle event hooks. Deployment configurations control how many instances update at once:
CodeDeployDefault.AllAtOnceCodeDeployDefault.HalfAtATimeCodeDeployDefault.OneAtATime- Custom configurations by count or percentage of healthy hosts.
For blue/green on EC2, CodeDeploy provisions a new set of instances (often via an Auto Scaling group copy), deploys to them, reroutes the Elastic Load Balancer, and then terminates the originals after a wait you control.
A minimal appspec.yml for EC2 shows the lifecycle hooks CodeDeploy runs in order:
version: 0.0
os: linux
files:
- source: /
destination: /var/www/app
hooks:
BeforeInstall:
- location: scripts/stop_server.sh
timeout: 120
AfterInstall:
- location: scripts/install_deps.sh
timeout: 300
ApplicationStart:
- location: scripts/start_server.sh
timeout: 120
ValidateService:
- location: scripts/health_check.sh
timeout: 120The ValidateService hook is your safety net: if the health-check script exits non-zero, the deployment to that instance fails and CodeDeploy can roll the whole deployment back.
CodeDeploy for ECS
For Amazon ECS, CodeDeploy performs blue/green only, and this is a favorite exam scenario. It works with an Application Load Balancer that has two target groups (blue and green) and, usually, a production listener plus an optional test listener. CodeDeploy:
- Starts a new (green) task set with the new task definition.
- Optionally routes the test listener to green so you can validate before real users see it.
- Shifts the production listener from the blue target group to green using a canary, linear, or all-at-once configuration.
- Waits a configurable bake time, then terminates the blue task set — or rolls back instantly if alarms fire.
ECS deployment configurations mirror the traffic-shifting patterns:
| Deployment configuration | Behavior |
|---|---|
CodeDeployDefault.ECSAllAtOnce | Shift 100% immediately |
CodeDeployDefault.ECSCanary10Percent5Minutes | 10% first, remaining 90% after 5 min |
CodeDeployDefault.ECSCanary10Percent15Minutes | 10% first, remaining after 15 min |
CodeDeployDefault.ECSLinear10PercentEvery1Minutes | +10% every minute |
CodeDeployDefault.ECSLinear10PercentEvery3Minutes | +10% every 3 minutes |
The ECS appspec.yaml points CodeDeploy at the task definition and container/port to route, and can wire Lambda functions into lifecycle hooks such as BeforeAllowTraffic and AfterAllowTraffic for automated validation:
version: 0.0
Resources:
- TargetService:
Type: AWS::ECS::Service
Properties:
TaskDefinition: "arn:aws:ecs:us-east-1:111122223333:task-definition/web:24"
LoadBalancerInfo:
ContainerName: "web"
ContainerPort: 8080
Hooks:
- BeforeAllowTraffic: "LambdaValidateBeforeTraffic"
- AfterAllowTraffic: "LambdaValidateAfterTraffic"CodeDeploy for Lambda
For AWS Lambda, CodeDeploy shifts traffic between two versions of a function using an alias, and supports canary, linear, and all-at-once configurations — for example CodeDeployDefault.LambdaCanary10Percent5Minutes or CodeDeployDefault.LambdaLinear10PercentEvery1Minute. There are no servers or target groups here; the alias’s weighted routing does the work. The same BeforeAllowTraffic/AfterAllowTraffic hooks let you run validation functions before and after traffic moves.
This is frequently paired with the AWS Serverless Application Model (SAM), which can configure the whole thing declaratively:
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
Handler: app.handler
Runtime: python3.13
AutoPublishAlias: live
DeploymentPreference:
Type: Canary10Percent5Minutes
Alarms:
- !Ref ErrorRateAlarm
Hooks:
PreTraffic: !Ref PreTrafficHookFunction
PostTraffic: !Ref PostTrafficHookFunctionAutomatic Rollback: The Feature the Exam Loves
Choosing a strategy is only half the story. DOP-C02 is obsessed with automated recovery, so know how CodeDeploy rolls back:
- CloudWatch alarm rollback. Associate one or more CloudWatch alarms with the deployment group. If an alarm enters
ALARMstate during the deployment (elevated error rate, latency, 5xx count), CodeDeploy stops and rolls back automatically. This is the mechanism to name whenever a scenario says “automatically roll back if errors spike.” - Rollback on failed deployment. If the deployment itself fails (a lifecycle hook errors, health checks fail), CodeDeploy redeploys the last known-good revision.
- Rollback on stopped deployment. Manual stop can also trigger a rollback.
Because blue/green keeps the previous version alive, its rollback is effectively instantaneous — flip traffic back to blue. In-place rollback is slower because it must redeploy the old artifact onto the mutated instances. When a question weighs “fastest possible rollback,” blue/green wins.
Deployment Strategies Beyond CodeDeploy
CodeDeploy isn’t the only way AWS ships changes, and the exam expects breadth:
- CloudFormation supports blue/green-style updates and, for ECS, canary and linear traffic shifting via CodeDeploy hooks using the
AWS::CodeDeploy::BlueGreenhook andType: AWS::CodeDeployBlueGreentransforms. Update behavior is also shaped by UpdatePolicy (for Auto Scaling rolling updates) and UpdateReplacePolicy/DeletionPolicy for data safety. - AWS Elastic Beanstalk offers deployment policies directly: All at once, Rolling, Rolling with additional batch, and Immutable (which launches a fresh set of instances, akin to blue/green), plus traffic-splitting canary deployments.
- Amazon ECS rolling updates (without CodeDeploy) use
minimumHealthyPercentandmaximumPercentto control how tasks are replaced — a cheaper, in-place option when you don’t need instant rollback. - API Gateway stage canaries shift a percentage of API traffic to a canary release of a stage, independent of the compute behind it.
For how these fit into a full pipeline, see the deep dive on SDLC automation for DOP-C02 and the broader AWS DevOps CI/CD guide. For the infrastructure side, the CloudFormation guide covers update policies in detail.
A Decision Framework for Exam Scenarios
When a question describes a workload and asks for the deployment approach, run this sequence:
- Is zero downtime required? No → in-place/rolling may be fine and cheaper. Yes → blue/green.
- Is instant rollback required? Yes → blue/green (keep the old environment).
- How much initial exposure is acceptable?
- “Small test group, then everyone” → canary.
- “Even, gradual ramp” → linear.
- “Cost matters more than caution” → all-at-once.
- What’s the compute platform?
- EC2/on-prem → CodeDeploy in-place or blue/green.
- ECS → CodeDeploy blue/green (two target groups) or native ECS rolling update.
- Lambda → CodeDeploy alias traffic shifting (canary/linear).
- How should failure be handled? → Attach CloudWatch alarms to the deployment group for automatic rollback.
Run that and most DOP-C02 deployment questions collapse to one clear answer.
How Deployment Strategies Show Up on the Exam
A few patterns worth internalizing before test day:
- Platform constraints are the trap. Remember: ECS via CodeDeploy is blue/green only; Lambda via CodeDeploy shifts traffic on an alias; EC2 supports both in-place and blue/green. Answers that mix these up are the distractors.
- “Automatic rollback” almost always means CloudWatch alarms wired to the deployment group.
- Two target groups + one ALB is the fingerprint of an ECS blue/green deployment.
- Bake time / validation before full traffic points to canary or the
BeforeAllowTraffic/AfterAllowTraffichooks. - Cost-sensitive + can tolerate brief mixed versions points to in-place/rolling rather than blue/green.
Frequently Asked Questions
What is the difference between in-place and blue/green deployments in AWS?
An in-place deployment updates the application on your existing instances, usually in batches, so infrastructure is mutated and rollback means redeploying the previous version. A blue/green deployment provisions a separate new environment (green), validates it, then shifts traffic from the old environment (blue) to it. Blue/green gives you zero downtime and near-instant rollback because the old environment stays intact, at the cost of temporarily running two environments.
What is the difference between canary and linear deployments?
Both gradually shift traffic to the new version to limit blast radius. A canary deployment shifts a small fixed percentage first (for example 10%), holds for a bake period, then shifts the remaining traffic in a single step. A linear deployment shifts traffic in equal increments at a fixed interval (for example 10% every 3 minutes) until it reaches 100%. Canary is “test small, then go all in”; linear is a steady, evenly paced ramp.
Which deployment types does CodeDeploy support for ECS?
For Amazon ECS, CodeDeploy performs blue/green deployments only. It uses an Application Load Balancer with two target groups and shifts the production listener from the blue target group to a new green task set using an all-at-once, canary, or linear deployment configuration, with an optional test listener for pre-production validation and a bake time before terminating the old task set.
How does CodeDeploy automatically roll back a deployment?
CodeDeploy can roll back automatically in three situations: when the deployment fails (a lifecycle hook or health check fails), when a deployment is manually stopped, and — most importantly for the exam — when a CloudWatch alarm associated with the deployment group enters the ALARM state during the deployment. Rollback redeploys the last known-good revision, or for blue/green simply reroutes traffic back to the original environment.
Can I do canary deployments for AWS Lambda?
Yes. CodeDeploy shifts traffic between two versions of a Lambda function using an alias, and supports canary, linear, and all-at-once configurations (for example LambdaCanary10Percent5Minutes). You can also define this declaratively with AWS SAM’s DeploymentPreference, attaching CloudWatch alarms for automatic rollback and PreTraffic/PostTraffic hooks for validation.
Is blue/green always the best deployment strategy?
No. Blue/green minimizes downtime and rollback time, but it costs more because you temporarily run two full environments and it can be operationally heavier. For workloads that tolerate a brief period of mixed versions and where cost matters, an in-place rolling deployment (EC2) or a native ECS rolling update using minimumHealthyPercent/maximumPercent is often the right, cheaper choice. Match the strategy to the constraints in the scenario.
Conclusion and Next Steps
Deployment strategy on DOP-C02 rewards a simple two-layer mental model: pick the environment model (in-place vs. blue/green) from the downtime and rollback requirements, then pick the traffic pattern (all-at-once, canary, or linear) from how much initial exposure is acceptable — and remember that CodeDeploy implements all of this differently for EC2, ECS, and Lambda. Nail the platform-specific rules, wire CloudWatch alarms for automatic rollback, and most deployment questions become straightforward.
The fastest way to turn this framework into exam-day reflexes is realistic practice. Sailor.sh’s AWS Certified DevOps Engineer – Professional (DOP-C02) Mock Exam Bundle gives you scenario-based questions that mirror the real exam’s format and difficulty — including the CodeDeploy, blue/green, and traffic-shifting decisions covered here — with detailed explanations that surface the exact distinctions the exam tests. Working through realistic questions is the surest way to find your gaps before they cost you points.
Pair the practice with the full AWS DevOps Engineer study plan, then round out the SDLC and resilience domains with SDLC automation for DOP-C02, resilient cloud solutions, and incident response with automated remediation.