Cargando...
Cargando...
In-Place vs Blue/Green vs Canary vs Linear — pick the right strategy every time
Downtime tolerance, rollback speed, and cost determine the winning strategy
| Feature | In-Place (Rolling) Deploy on existing instances, cost-efficient | Blue/Green (All-at-Once) Instant cutover, full fleet swap | Blue/Green (Canary) Shift small % first, validate, then all | Blue/Green (Linear) Gradual equal-step traffic shifting | All-at-Once (In-Place) Fastest deploy, highest downtime risk |
|---|---|---|---|---|---|
Deployment Model In-Place modifies existing infrastructure; Blue/Green always provisions NEW infrastructure alongside old | Deploy to existing instances in batches; old version replaced on same host | New fleet (green) provisioned; all traffic shifted at once from old (blue) | New fleet provisioned; small % of traffic shifted first, remainder after validation interval | New fleet provisioned; traffic shifted in equal increments at regular intervals | All instances updated simultaneously; fastest but riskiest |
Downtime Risk Blue/Green strategies are the ONLY way to achieve true zero-downtime for EC2/On-Premises. Lambda and ECS ONLY support Blue/Green. | Reduced capacity during deployment; partial downtime possible if batch fails | Near-zero downtime; traffic cut over only when green fleet is healthy | Near-zero; only a small % of users see new version during validation window | Near-zero; gradual shift limits blast radius at each step | Full downtime possible; all instances offline simultaneously during update |
Rollback Speed Blue/Green rollback = traffic re-route (seconds). In-Place rollback = full re-deployment (minutes). This distinction is CRITICAL on exams. | Slow — must redeploy previous revision to all instances; no instant rollback | Fast — re-route traffic back to blue fleet (if not yet terminated) | Fast — shift 100% traffic back to blue during or after canary window | Fast — shift traffic back to blue at any linear step | Slowest — must redeploy old revision across entire fleet |
Infrastructure Cost Blue/Green always costs more during deployment due to running two environments. Old (blue) instances can be terminated immediately or kept for a configurable period. | No extra cost — reuses existing instances | 2x instance cost during deployment window (blue + green running simultaneously) | 2x instance cost during canary validation window | 2x instance cost throughout entire linear shift duration | No extra cost — reuses existing instances |
Supported Compute Platforms Lambda and ECS do NOT support In-Place deployments at all. Lambda/ECS use traffic-shifting (Canary/Linear/All-at-Once) exclusively via Blue/Green. | EC2/On-Premises ONLY. NOT supported for Lambda or ECS. | EC2/On-Premises, AWS Lambda, Amazon ECS | AWS Lambda and Amazon ECS ONLY (not EC2/On-Premises native canary) | AWS Lambda and Amazon ECS ONLY (not EC2/On-Premises native linear) | EC2/On-Premises ONLY |
Traffic Shifting Mechanism Predefined configurations like 'CodeDeployDefault.LambdaCanary10Percent5Minutes' are commonly tested. Know the naming pattern: [Platform][Strategy][Percent]Every/[Minutes]. | Load balancer deregisters instances in batches; no weighted routing | ALB/NLB/CLB listener rules shift 100% traffic at once to target group | ALB weighted target groups OR Lambda alias weights — e.g. Canary10Percent5Minutes shifts 10% for 5 min then 90% | ALB weighted target groups OR Lambda alias weights — e.g. Linear10PercentEvery1Minute adds 10% per minute | No traffic shifting — all instances replaced simultaneously |
Pre-defined Configuration Examples You can also create CUSTOM deployment configurations with your own percentage and interval values — not limited to pre-defined options. | CodeDeployDefault.OneAtATime, CodeDeployDefault.HalfAtATime, CodeDeployDefault.AllAtOnce | CodeDeployDefault.ECSAllAtOnce, CodeDeployDefault.LambdaAllAtOnce | CodeDeployDefault.LambdaCanary10Percent5Minutes, CodeDeployDefault.LambdaCanary10Percent30Minutes, CodeDeployDefault.ECSCanary10Percent5Minutes, CodeDeployDefault.ECSCanary10Percent15Minutes | CodeDeployDefault.LambdaLinear10PercentEvery1Minute, CodeDeployDefault.LambdaLinear10PercentEvery2Minutes, CodeDeployDefault.ECSLinear10PercentEvery1Minute, CodeDeployDefault.ECSLinear10PercentEvery3Minutes | CodeDeployDefault.AllAtOnce (EC2/On-Premises) |
Load Balancer Requirement Blue/Green for EC2 REQUIRES a load balancer. Without one, you cannot perform Blue/Green on EC2. This is a frequent exam trap. | Optional but recommended (ALB, NLB, or CLB). Required for zero-downtime rolling. | REQUIRED — ALB or NLB (CLB supported for EC2 Blue/Green). Needed to shift traffic between target groups. | REQUIRED — ALB (for ECS) or Lambda alias (for Lambda). Weighted routing is the mechanism. | REQUIRED — ALB (for ECS) or Lambda alias (for Lambda). | Not required; all instances updated regardless of load balancer state |
Auto Scaling Group Integration For EC2 Blue/Green, CodeDeploy copies the current ASG configuration to create the green environment automatically — you don't manually provision it. | Deploys to existing ASG instances; does not create new ASG | CodeDeploy can automatically provision a new ASG (green) by copying the blue ASG settings | New ASG provisioned automatically for green fleet; scales independently | New ASG provisioned automatically for green fleet | Deploys to existing ASG instances; no new ASG |
Deployment Lifecycle Hooks (AppSpec) Lambda/ECS Blue/Green hooks are BeforeAllowTraffic and AfterAllowTraffic. EC2 In-Place uses a longer hook chain including ApplicationStop and Install hooks. Know both. | ApplicationStop → DownloadBundle → BeforeInstall → Install → AfterInstall → ApplicationStart → ValidateService | BeforeAllowTraffic → AllowTraffic → AfterAllowTraffic (Lambda/ECS). EC2 adds full lifecycle. | BeforeAllowTraffic → AllowTraffic → AfterAllowTraffic. Validation runs between canary and full shift. | BeforeAllowTraffic → AllowTraffic → AfterAllowTraffic at each linear step. | Same as In-Place Rolling but applied to all instances simultaneously |
Failure Handling / Automatic Rollback CloudWatch Alarms can trigger automatic rollback for Blue/Green strategies. This is a key integration pattern tested on exams — especially for Lambda deployments. | Failed instances remain in failed state; can configure automatic rollback to redeploy previous revision | If green fleet fails health checks, traffic stays on blue; automatic rollback re-routes to blue | If canary % fails CloudWatch alarms, automatic rollback shifts 100% back to blue immediately | If any linear step fails CloudWatch alarms, automatic rollback shifts all traffic back to blue | If deployment fails, all instances may be in failed state — highest blast radius |
Old Environment Termination Keeping the blue environment running after full cutover incurs ongoing cost. The termination wait time is configurable — useful for emergency rollback window. | N/A — same instances are reused | Blue instances can be: (1) Terminated immediately, (2) Kept for a configurable number of days, (3) Never terminated (manual) | Blue environment kept until full shift completes; then configurable termination | Blue environment kept until full shift completes; then configurable termination | N/A — same instances are reused |
Best Use Case | Cost-sensitive workloads, non-critical apps, dev/test environments, when you can tolerate brief capacity reduction | Production workloads needing fast cutover with immediate full validation; Lambda and ECS production deployments | High-traffic production services where you want to test new version on a small % of real users before full rollout; risk-averse deployments | Regulated environments needing gradual, auditable traffic shifting; SLA-sensitive services needing controlled rollout | Dev/test environments, batch jobs, non-production workloads where speed matters more than availability |
Integration with CodePipeline ECS Blue/Green in CodePipeline uses a special 'Amazon ECS (Blue/Green)' action type — distinct from the standard 'Amazon ECS' action which does rolling updates via ECS directly. | Fully supported as a Deploy action in CodePipeline | Fully supported; ECS Blue/Green has native CodePipeline integration via 'Amazon ECS (Blue/Green)' action | Fully supported; Lambda canary deployments triggered via CodePipeline deploy stage | Fully supported via CodePipeline deploy stage | Fully supported as a Deploy action in CodePipeline |
Minimum Healthy Hosts (EC2) MinimumHealthyHosts is an EC2/On-Premises In-Place concept only. It does not apply to Blue/Green because the original fleet remains untouched until traffic shifts. | Configurable: by percentage (e.g. 75%) or fixed count. OneAtATime = 1 instance at a time. HalfAtATime = 50% minimum healthy. | Not applicable — new fleet is fully provisioned before traffic shifts; old fleet remains healthy | Not applicable — old fleet stays fully healthy during canary window | Not applicable — old fleet stays fully healthy during linear shift | 0 minimum healthy — all instances updated simultaneously; full capacity risk |
Summary
Choose In-Place deployments when cost matters most and brief capacity reduction is acceptable — ideal for non-production or cost-sensitive workloads. Choose Blue/Green when zero downtime, fast rollback, and production safety are paramount; use Canary or Linear variants when you need gradual traffic validation with real users before full cutover. Lambda and ECS ONLY support Blue/Green traffic-shifting strategies, making the choice automatic for those platforms.
🎯 Decision Tree
If compute = Lambda or ECS → MUST use Blue/Green (Canary/Linear/All-at-Once). If compute = EC2/On-Premises AND cost is priority → In-Place Rolling. If compute = EC2/On-Premises AND zero-downtime is priority → Blue/Green. If you need to test on small % of real users first → Canary. If you need equal gradual steps with audit trail → Linear. If you need fastest possible full deployment (accepting risk) → All-at-Once In-Place (dev/test only). If rollback speed is #1 priority → any Blue/Green variant.
Lambda and ECS CANNOT use In-Place deployments — they ONLY support Blue/Green with traffic shifting (Canary, Linear, or All-at-Once). If an exam scenario involves Lambda or ECS with zero-downtime requirements, the answer is always Blue/Green with a traffic-shifting strategy.
Rollback speed is the #1 differentiator between In-Place and Blue/Green: Blue/Green rollback = re-route traffic to blue fleet (near-instant, seconds). In-Place rollback = redeploy previous revision to all instances (slow, minutes). Any scenario asking for 'fastest rollback' or 'minimal rollback time' = Blue/Green.
Blue/Green for EC2 REQUIRES a load balancer. Without ALB/NLB/CLB, CodeDeploy cannot perform Blue/Green on EC2 instances. If a scenario describes EC2 Blue/Green without a load balancer, it is not possible — this is a common distractor answer.
Canary vs Linear decision: Use Canary when you want to validate quickly with a small initial percentage then flip all at once. Use Linear when you need a steady, equal, auditable progression (e.g., regulatory compliance, SLA-sensitive services). Both limit blast radius but Linear is more controlled and gradual.
CloudWatch Alarms integration enables automatic rollback for Blue/Green deployments. This is a key architectural pattern: deploy with CodeDeploy → monitor with CloudWatch → alarm triggers automatic rollback. Scenarios asking 'how to automatically roll back a bad Lambda deployment' = CodeDeploy Blue/Green + CloudWatch Alarms.
The ECS Blue/Green CodePipeline action type is 'Amazon ECS (Blue/Green)' — distinct from 'Amazon ECS' which performs a rolling update directly via ECS service update. The Blue/Green option routes through CodeDeploy and supports traffic shifting hooks.
MinimumHealthyHosts is an In-Place EC2 concept only. It does NOT apply to Blue/Green because the original fleet is never touched during deployment. If an exam question mentions MinimumHealthyHosts, the answer involves EC2/On-Premises In-Place deployment.
The #1 exam trap: assuming In-Place deployment is available for Lambda or ECS. Lambda and ECS ONLY support Blue/Green traffic-shifting deployments (Canary/Linear/All-at-Once). Candidates who don't know this will incorrectly select In-Place options for Lambda/ECS scenarios and fail those questions. Additionally, candidates confuse 'fast rollback' — Blue/Green rollback is traffic re-routing (seconds), NOT a redeployment, while In-Place rollback requires a full re-deployment of the previous revision (minutes).
CertAI Tutor · · 2026-02-22
Services
Guides & Patterns