AWS Deployment Strategies: Blue/Green, Canary, and Beyond

[!IMPORTANT] Mastering deployment strategies is a core requirement for the AWS Certified DevOps Engineer - Professional (DOP-C02) exam. This guide focuses on the technical implementation and trade-offs of shifting traffic between application versions.

---

Learning Objectives

By the end of this guide, you should be able to:

• Distinguish between mutable (In-place) and immutable (Blue/Green) deployment patterns.
• Configure traffic shifting for AWS Lambda using aliases and weighted distributions.
• Evaluate the benefits of Canary vs. Linear deployment configurations.
• Implement Blue/Green deployments for Elastic Beanstalk using CNAME swapping.
• Address stateful service challenges during deployment transitions.

---

Key Terms & Glossary

• In-Place Deployment: A deployment where the application on each instance in the deployment group is stopped, the latest application revision is installed, and the new version is started.
• Blue/Green Deployment: A strategy where two identical environments run simultaneously; one (Blue) is the current production, and the other (Green) is the new version.
• Canary Deployment: A pattern where a small percentage of traffic is routed to the new version to test stability before a full rollout.
• Linear Deployment: A shifting method where traffic grows at equal increments over a set period (e.g., 10% every 10 minutes).
• Immutable Infrastructure: A model where servers are never modified after they are deployed. If a change is needed, new servers are built from a common image (AMI/Container).

---

The "Big Idea"

In modern DevOps, the goal is to maximize velocity while minimizing risk. Deployment methods like Blue/Green and Canary act as a safety net. Instead of hoping a deployment works, these methods allow us to "test in production" with limited blast radiuses. If a new version fails, we don't fix it in place; we simply reroute traffic back to the known-good version, achieving near-zero RTO (Recovery Time Objective).

---

Formula / Concept Box

Lambda Shifting Configurations

---

Hierarchical Outline

1. Deployment Philosophies
   • Mutable (In-place): Faster, uses existing resources, but riskier with no easy rollback.
   • Immutable (Blue/Green): Safer, provides a clean environment, facilitates easy rollbacks.
2. Platform Specific Implementations
   • AWS Lambda: Uses Function Aliases and weighted traffic. Requires new versions to be published first.
   • Amazon ECS: Uses Replacement Task Sets. Traffic shifts through an Application Load Balancer (ALB).
   • AWS Elastic Beanstalk: Uses CNAME Swapping or additional environment cloning.
   • Amazon EC2: Managed via AWS CodeDeploy with deployment groups.
3. Rollback Mechanisms
   • Automatic rollbacks triggered by CloudWatch Alarms (e.g., 5xx errors or high latency).

---

Visual Anchors

Blue/Green Traffic Flow

Linear vs. Canary Traffic Shift

---

Definition-Example Pairs

• Weighted Alias (Lambda): A pointer to two different versions of a Lambda function with specific weights assigned to each.
  • Example: Pointing an PROD alias to Version 1 (90%) and Version 2 (10%) to perform a canary test.
• CNAME Swap: Swapping the DNS endpoints of two Elastic Beanstalk environments.
  • Example: Swapping myapp-prod.elasticbeanstalk.com with myapp-stage.elasticbeanstalk.com so users hit the new code instantly.
• Pre-deployment Hook: A Lambda function or script that runs before traffic starts shifting.
  • Example: Running a database migration or health check before CodeDeploy allows traffic to the Green environment.

---

Worked Examples

Scenario: Configuring a Lambda Canary

Goal: Shift 10% of traffic to a new Lambda version, wait 10 minutes, then shift the rest.

1. Publish a New Version: Use aws lambda publish-version --function-name MyFunction.
2. Update the Alias: Use the AWS CLI to update a weighted alias.
   bashCopy

   aws lambda update-alias --function-name MyFunction \\ --name prod --function-version 1 \\ --routing-config '{"AdditionalVersionWeights": {"2": 0.1}}'
3. Monitor: Watch CloudWatch Metrics for version 2. If errors > 0, set Version 2 weight back to 0.
4. Finalize: After 10 minutes, update the alias to point 100% to Version 2.

---

Checkpoint Questions

1. What is the primary advantage of a Blue/Green deployment over an In-Place deployment regarding rollbacks?
2. In a Lambda Linear deployment, if you choose Linear10PercentEvery2Minutes, how long does it take for the new version to receive 100% of the traffic?
3. Why is it recommended to keep your RDS database in a separate stack when performing Blue/Green deployments with Elastic Beanstalk?
4. What AWS service is primarily used to automate the deployment process and manage these strategies across EC2, Lambda, and ECS?

---

Muddy Points & Cross-Refs

• The Database Dilemma: Blue/Green deployments create two app environments, but they usually share one database. If the new version changes the DB schema in a way that is backward-incompatible, the Blue version will break.
  • Deep Study: Research Expand and Contract (Parallel Change) pattern for database migrations.
• Stateful Sessions: If users are logged into the Blue environment, shifting them to Green might log them out if session data isn't centralized (e.g., in ElastiCache/Redis).

---

Comparison Tables

Deployment Strategy Trade-offs