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:
| Strategy | How It Works | Downtime | Rollback Speed | Risk |
|---|---|---|---|---|
| In-place (All-at-once) | Replace all running instances simultaneously | ā Possible | ā Slow (redeploy old version) | Highest |
| Rolling | Replace instances in batches (e.g., 25% at a time) | ā None | ā ļø Medium | Medium |
| Blue/Green | New environment alongside old; switch traffic when ready | ā None | ā Instant (switch back) | Low |
| Canary | Route small % of traffic to new version; expand if healthy | ā None | ā Fast | Lowest |
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:
| Compute Platform | Deployment Types Available |
|---|---|
| EC2/On-premises | In-place, blue/green |
| Lambda | Canary, linear, all-at-once |
| ECS | Blue/green (via ALB target group swap) |
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:
| Lifecycle Event | Runs When |
|---|---|
BeforeInstall | Before the new application version is installed |
AfterInstall | After installation, before starting |
ApplicationStart | To start the application |
ValidateService | To verify the deployment succeeded |
ā ļø 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?
