4.1.7. Deployment Strategies: Blue/Green, Rolling, and Canary

💡 First Principle: Every deployment is a controlled risk. The question is not whether something might go wrong, but how quickly you can detect it, how many users it affects when it does, and how fast you can revert. Deployment strategies are risk management tools — you trade deployment complexity and speed for blast radius reduction and rollback capability.

The Four Primary Strategies:

Blue/Green Deployment on AWS:

The "blue" environment runs the current version. The "green" environment runs the new version. Traffic switches from blue to green all at once (via DNS, load balancer, or Auto Scaling group swap).

Implementation options:

• Route 53 weighted routing: Shift 0% → 100% between two ALBs
• ALB target group swap: Two target groups; update listener rules
• Auto Scaling group swap: CodeDeploy manages two ASGs

Canary/Traffic Splitting:

Route a small percentage of real traffic to the new version, monitor for errors, then gradually increase:

AWS CodeDeploy Deployment Types:

Deployment configurations set the pace: EC2/on-premises in-place uses CodeDeployDefault.AllAtOnce, HalfAtATime or OneAtATime; Lambda and ECS shift traffic with canary (e.g. LambdaCanary10Percent5Minutes: 10%, wait 5 minutes, then the rest), linear (equal steps at fixed intervals) or all-at-once. Attach CloudWatch alarms to the deployment group and CodeDeploy stops the deployment when one goes into ALARM, even if health checks pass; with automatic rollback on alarm enabled, it also rolls back to the last good revision. In an EC2 blue/green deployment, green instances can be validated before any production traffic reaches them; afterwards the blue instances are deregistered from the load balancer and either terminated (immediately or after a wait you set) or kept running.

Immutable Deployments: Instead of updating existing instances, launch an entirely new set of instances with the new version. Only swap traffic when the new fleet is healthy. Existing instances are terminated after the swap. This is the safest EC2 deployment pattern — old instances are never modified.

AppSpec File: CodeDeploy uses an appspec.yml file to define deployment hooks — scripts that run at specific lifecycle events:

A hook script that exits non-zero fails the deployment on that instance — CodeDeploy neither skips nor retries it — and, if automatic rollback on failure is enabled, redeploys the last good revision.

Elastic Beanstalk deployment policies: All at once (the default and fastest; brief outage — in a single-instance environment the only instance is out of service while it updates), Rolling (batches of existing instances; capacity drops and versions mix), Rolling with additional batch (adds a batch first to keep capacity; versions still mix), Immutable (a fresh set of instances, health-checked, then swapped in; full capacity, no version mixing, rollback = terminate the new instances) and Traffic splitting (canary-style percentage). Blue/green is not a policy: you deploy to a second environment and swap environment URLs.

CodePipeline and CodeBuild: A manual approval action pauses the pipeline (optionally notifying reviewers through SNS) until someone approves or rejects — place it just before the stage it guards, such as production. A CodeBuild project's compute type (e.g. BUILD_GENERAL1_SMALL, MEDIUM, LARGE) sets the build container's memory and vCPUs, so an out-of-memory build needs a larger compute type.

⚠️ Exam Trap: "Blue/green" for ECS with CodeDeploy works by creating a new task set (green) alongside the existing one (blue), then shifting traffic at the ALB level. It is not implemented by running two separate ECS clusters — both task sets run in the same cluster. The ALB has two target groups (blue and green), and CodeDeploy manages the traffic shift percentage.

Reflection Question: Your team deploys a critical payment service update. Requirements: no downtime, instant rollback capability if errors spike, and real production traffic should validate the new version before full rollout. Which deployment strategy do you use, and how does it enable each requirement?