Deployment Strategies on AWS
Rolling, blue/green, and canary deployments — how to actually ship a new version to production without downtime or unacceptable risk.
Want a visual for this topic?
Generate a diagram tailored to Deployment Strategies on AWS — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain the tradeoffs between rolling, blue/green, and canary deployment strategies
- •Explain how each strategy maps to specific AWS services and configuration
- •Choose an appropriate deployment strategy given a specific risk/downtime tolerance
What is it?
A deployment strategy defines exactly how a new version of an application replaces the currently running version in production — the sequence, pacing, and safety mechanisms involved in that transition. The main strategies used on AWS are Rolling (updating instances gradually, a few at a time), Blue/Green (standing up an entirely separate new environment and switching traffic over), and Canary (exposing a small percentage of traffic to the new version before a full rollout).
Why it exists
Every deployment carries some risk that the new version has a bug not caught in testing. Deployment strategy exists specifically to manage and limit that risk's potential impact — the difference between a bug affecting 100% of users the instant a bad deployment goes live (a naive all-at-once approach) versus affecting a small, contained fraction of users for a short window before being caught and automatically reverted (a well-designed gradual strategy) is enormous in real business impact.
Problem it solves
It solves the all-or-nothing-risk problem (a bad deployment's blast radius can be deliberately limited rather than instantly affecting every user), the zero-downtime problem (users experience no interruption during a well-designed deployment, unlike a naive stop-old-start-new approach), and the fast-rollback problem (a well-designed strategy makes reverting to the previous version fast and low-risk if a problem is detected, rather than requiring a slow, manual, stressful emergency fix).
Intuition
Think of the difference between replacing every tire on a moving car simultaneously (an all-at-once deployment — fast, but catastrophic if anything goes wrong) versus replacing one tire at a time while the others keep the car stable (rolling deployment), or having an entirely separate, fully-prepared replacement car ready to seamlessly take over (blue/green), or first testing the new tires on just one wheel under careful observation before committing to changing the rest (canary).
Analogy
A restaurant testing a new menu item: rolling out the change to just one location first and watching how it performs (canary) is far lower-risk than simultaneously changing the menu at every location in the chain overnight (all-at-once) — if the new item flops, you've only affected customer experience at one location, and can quickly revert everywhere else having learned from that contained experiment.
Technical explanation
Rolling deployments are the default behavior of an Auto Scaling Group's instance refresh or a Kubernetes-style rolling update — old instances are terminated and replaced with new ones in configurable batches, with the load balancer's health checks ensuring only healthy instances (old or new) receive traffic throughout. Blue/Green deployments, well-supported by CodeDeploy, ECS, and Elastic Beanstalk, stand up a complete parallel environment and switch traffic over (often via updating a load balancer's target group, or a DNS change) — providing the fastest, cleanest rollback (just switch traffic back) at the cost of temporarily running double infrastructure. Canary deployments, supported natively by CodeDeploy for Lambda/ECS and achievable with weighted routing on an ALB or Route 53, expose a small percentage to the new version first, typically gated by an automatic CloudWatch-alarm-driven rollback if problems are detected during that initial exposure window before proceeding to full rollout.
Architecture
A company applies different deployment strategies matched to each service's actual risk profile: their high-traffic, revenue-critical checkout service uses canary deployment via CodeDeploy with a CloudWatch alarm gate (minimizing blast radius for their most consequential service), their internal admin tool uses simple rolling deployment via Auto Scaling instance refresh (lower risk tolerance justified, since limited internal users are affected and downtime tolerance is higher), and their stateless API layer uses blue/green via ECS (fast, clean rollback capability valued given how frequently that service deploys).
Workflow
- Assess the actual risk and downtime tolerance for the specific service being deployed — not every service warrants the most sophisticated (and most operationally complex) strategy. 2) For services with low risk tolerance and high deployment frequency, invest in canary or blue/green with automated rollback gates. 3) For less critical or lower-frequency services, simpler rolling deployment may be entirely sufficient. 4) Regardless of strategy, ensure meaningful automated tests and health checks actually gate the deployment's progress — the strategy's safety benefit depends entirely on those checks being real and sufficient, not just present.
Example
A mobile app's backend API deploys via ECS blue/green through CodeDeploy: a new task set is stood up fully, verified healthy via its own health checks, and traffic is shifted from the old task set to the new one over a 5-minute linear ramp, with a CloudWatch alarm watching p99 latency and error rate — if either degrades during the ramp, CodeDeploy automatically halts and reverts to the old task set, which remains running (not yet terminated) specifically to make that rollback fast and safe, only being torn down once the new version has been confirmed stable for a defined bake time after reaching 100% traffic.
Real-world usage
Rolling deployments remain the most common default for general-purpose EC2/Auto Scaling Group-based applications; blue/green and canary strategies via CodeDeploy are increasingly the standard recommendation for production-critical, frequently-deployed services, directly documented in AWS's own deployment best-practice guidance as the preferred approach for minimizing production risk.
Trade-offs
The choice of deployment strategy is fundamentally a tradeoff between operational simplicity/cost (rolling, cheapest and simplest) and deployment safety/blast-radius minimization (canary, most cautious but most complex and slowest to fully roll out) — blue/green sits as a middle ground, offering fast/clean rollback at a real but temporary cost. The right choice depends on a specific service's actual criticality, deployment frequency, and organizational risk tolerance, not a one-size-fits-all default applied uniformly.
Visual explanation
Picture three timelines. Rolling: an Auto Scaling Group's instances are updated a few at a time, with the load balancer routing traffic only to healthy, already-updated or not-yet-updated instances throughout — capacity dips slightly during the transition, but the deployment completes gradually with mixed old/new versions briefly coexisting. Blue/Green: an entirely new, fully-scaled 'green' environment is stood up alongside the existing 'blue' one, and traffic is switched from blue to green essentially all at once (or gradually) only once green is confirmed healthy — brief double capacity, but a much cleaner, more instantly reversible cutover. Canary: a small percentage of traffic is routed to the new version first, monitored closely, with the rest following only after that initial slice proves healthy.
Advantages
- —
Rolling: no extra infrastructure cost, straightforward to understand and configure via standard Auto Scaling mechanisms
- —
Blue/Green: fast, clean, low-risk rollback (just switch traffic back), and the old environment stays available as a safety net during the transition
- —
Canary: smallest possible blast radius for a bad deployment, catching problems while affecting only a small fraction of real traffic
- —
All three integrate with CloudWatch alarms for automated, rather than manually-triggered, rollback
Disadvantages
- —
Rolling: capacity dips slightly during the transition, and rollback requires another full rolling update rather than an instant switch
- —
Blue/Green: requires temporarily double infrastructure capacity, a real (if brief) cost consideration
- —
Canary: takes longer to complete a full rollout than an immediate all-at-once switch, and requires meaningful traffic volume for the canary slice to be statistically meaningful
- —
All three strategies' actual safety benefit depends entirely on having genuinely meaningful health checks/alarms gating them — a strategy without real verification provides only false confidence
Common mistakes
- —
Using the same deployment strategy uniformly across every service regardless of actual differing criticality and risk tolerance, rather than matching strategy to each service's real needs
- —
Implementing a sophisticated canary or blue/green strategy without meaningful CloudWatch alarms actually gating the rollout, providing the appearance of safety without the actual substance
- —
Not accounting for blue/green's temporary double-capacity cost when budgeting for a deployment pipeline
- —
Terminating the old environment/task set immediately after a blue/green cutover instead of keeping it available briefly as an instant rollback safety net
- —
Using an all-at-once deployment for a genuinely critical, high-traffic service where the added safety of canary or blue/green would have been well worth the extra complexity
In the AWS Console
- 1
EC2 → Auto Scaling Groups → [your group] → Instance refresh → Start instance refresh
Configure the minimum healthy percentage and instance warmup time for a rolling replacement of instances with an updated launch template.
A higher minimum healthy percentage keeps more capacity available during the rollout but replaces instances more slowly, in smaller batches.
- 2
AWS Console → CodeDeploy → Create deployment
For a blue/green or canary deployment, select the appropriate deployment configuration (e.g. CodeDeployDefault.LambdaCanary10Percent5Minutes for a Lambda canary) matching your desired traffic-shifting pace.
AWS provides several pre-built deployment configurations covering common canary/linear patterns — review these before building a fully custom one.
🎤 Interview questions
Compare rolling, blue/green, and canary deployment strategies. (Listen for: rolling = gradual instance replacement, no extra cost, slower rollback; blue/green = parallel environment, fast/clean rollback, temporary double cost; canary = smallest blast radius, gradual traffic exposure, slowest full rollout.)
Why would a team choose blue/green over rolling deployment for a specific service? (Listen for: need for fast, clean, low-risk rollback capability, willing to accept the temporary double-capacity cost in exchange for that safety.)
How does a canary deployment limit the impact of a bad release? (Listen for: only a small percentage of real traffic is exposed to the new version initially, monitored closely, before the rest follows — a bug affects a small, contained fraction rather than everyone immediately.)
What determines whether a deployment strategy's automated rollback actually provides real safety? (Listen for: the quality and relevance of the CloudWatch alarms/health checks actually gating it — a sophisticated strategy without meaningful monitoring provides only the appearance of safety.)
How would you decide which deployment strategy to use for a given service? (Listen for: assess the service's actual criticality, deployment frequency, and organizational risk/cost tolerance — not a uniform default applied to every service regardless of its specific needs.)