Deployment Strategies for AWS Solutions Architects
In the AWS ecosystem, deployment strategies determine how new code or infrastructure updates are rolled out to users. Choosing the right strategy involves balancing availability (downtime), cost, and rollback speed. For the SAA-C03 exam, you must understand how services like AWS CodeDeploy, Elastic Beanstalk, and CloudFormation implement these patterns.
- In-Place: Renovating your kitchen while you are still living in the house (messy, potential downtime).
- Blue/Green: Buying a brand new fully furnished house, checking if the lights work, then moving in and selling the old one (clean, zero downtime, but you pay for two houses for a while).
Core Deployment Strategies
1. In-Place (All-at-Once)
The application on each instance in the deployment group is stopped, the latest application revision is installed, and the new version of the application is started. Exam Context: Use this for non-critical dev/test environments where downtime is acceptable and cost must be kept low.
2. Rolling Update
Updates instances in batches. For example, if you have 10 instances, you might update 2 at a time. Exam Context: Reduces risk but reduces total capacity during the update. If 2 instances are down for updates, your fleet only has 80% capacity.
3. Rolling with Additional Batch
Similar to Rolling, but AWS launches a new batch of instances first to maintain 100% capacity during the process. Exam Context: Choose this when you need to maintain full performance/throughput during the deployment without the full cost of Blue/Green.
4. Blue/Green Deployment
A completely new environment (Green) is provisioned alongside the old one (Blue). Traffic is shifted via Route 53 or an Application Load Balancer (ALB). Exam Context: The “Gold Standard” for zero downtime and near-instant rollback. If Green fails, just point traffic back to Blue.
5. Immutable Deployment
A new set of instances is launched in a separate Auto Scaling group. Once they pass health checks, they are integrated, and the old ones are terminated. Exam Context: Ensures that if a deployment fails, only the new instances are affected, leaving the production environment untouched.
Comparison Table: Strategy Trade-offs
| Strategy | Downtime | Cost Impact | Rollback Speed | Best For… |
|---|---|---|---|---|
| In-Place | Yes | Lowest | Slow (Re-deploy) | Development / Testing |
| Rolling | No (Reduced Cap) | Low | Slow (Manual) | Production (Small Apps) |
| Rolling + Batch | No | Medium | Moderate | Mission Critical (Stable) |
| Blue/Green | No | Highest (2x) | Fastest (DNS/ALB) | High Availability Apps |
| Immutable | No | Medium | Fast (Terminate) | Clean State Reliability |
Decision Matrix: If-Then Guide
- If the requirement is “Zero Downtime” and “Fast Rollback” → Choose Blue/Green.
- If the requirement is “Minimize Cost” and “Downtime is OK” → Choose In-Place.
- If you must maintain “Full Capacity” without doubling costs → Choose Rolling with Additional Batch.
- If deploying to Lambda → Choose Canary or Linear (via CodeDeploy).
Exam Tips and Gotchas
- Route 53 Weighted Routing: This is the primary mechanism for manual Blue/Green or Canary transitions at the DNS level.
- CodeDeploy vs. Elastic Beanstalk: Beanstalk manages the underlying infrastructure (S3, EC2, ASG) automatically; CodeDeploy is an engine that can deploy to EC2, On-premises, or Lambda.
- Canary on Lambda: CodeDeploy can shift traffic to a new Lambda version in increments (e.g., 10% for 10 minutes). This is a common exam scenario for serverless stability.
- CloudFormation: Use
UpdatePolicyto control how Auto Scaling groups handle rolling updates. - Distractor: “A/B Testing” is a business goal (testing features), while “Blue/Green” is a deployment methodology. Don’t confuse the two!
Topics covered:
Summary of key subtopics covered in this guide:
- In-Place vs. Rolling vs. Blue/Green methodologies.
- Infrastructure capacity management during updates.
- Rollback mechanisms and performance trade-offs.
- AWS Service-specific implementations (Elastic Beanstalk, CodeDeploy).
- Serverless deployment patterns (Canary/Linear).
Visualizing Blue/Green Deployment
Integrations
- IAM: Control who can trigger deployments.
- CloudWatch: Monitor health checks to trigger auto-rollbacks.
- KMS: Encrypt deployment artifacts in S3.
Scaling
- Pre-warming: Ensure new instances are ready before shifting traffic.
- ASG Cooldowns: Ensure scaling doesn’t conflict with deployment.
Optimization
- Blue/Green: High cost (temporary double resources).
- Spot Instances: Use for non-critical rolling updates to save 90%.
Production Use Case: The “No-Fail” Retailer
A large e-commerce site uses Blue/Green during Black Friday. They deploy the new code to the Green fleet, run automated integration tests, and then swap the ALB listener. If the checkout service shows a 1% error spike in CloudWatch, the system automatically swaps the ALB listener back to the Blue fleet in seconds.