3.3.1. Deployment Strategies (Blue/Green, Canary for Dev)

First Principle: Application deployment strategies (e.g., Blue/Green, Canary) manage the risk of introducing new code into production, prioritizing minimal downtime and controlled exposure for reliable releases.

For developers, choosing the right deployment strategy ensures that their new code is released smoothly and safely to users, minimizing disruption and enabling quick rollbacks if issues arise.

• In-place Deployment: (Updates application directly on existing servers.)
  • Pros: Simple.
  • Cons: Downtime, higher risk of issues.
• Rolling Update: (Gradually replaces old versions with new ones in a phased manner.)
  • Pros: Reduces downtime compared to in-place.
  • Cons: Rollbacks can be complex, potential for mixed environments.
• Blue/Green Deployment: (Runs two identical production environments, "Blue" (old version) and "Green" (new version), and shifts traffic when the new version is validated.)
  • Pros: Near-zero downtime, instant rollback (switch traffic back to "Blue"), ideal for critical applications.
  • Cons: Requires provisioning double the resources.
• Canary Deployment: (Rolls out a new version of an application to a small percentage of users first, then gradually to all users if it performs well.)
  • Pros: Minimizes impact of issues to a small subset of users, real-world testing.
  • Cons: More complex to implement traffic shifting and monitoring.
• AWS Services: AWS CodeDeploy supports Blue/Green deployments for EC2, ECS, and Lambda, and canary/linear traffic shifting for Lambda and ECS. Lambda aliases enable traffic shifting for Lambda functions.
• Where the Switch Happens: Blue/green traffic moves at the router — an ALB listener/target group, or DNS (e.g., moving a Route 53 weighted record from the blue endpoint to the green one). Stopping the blue instances or editing security groups is not a traffic switch.
• Predefined CodeDeploy Configurations: Lambda — CodeDeployDefault.LambdaCanary10Percent10Minutes (10% for 10 minutes, then the remaining 90%), LambdaLinear10PercentEvery1Minute (another 10% every minute), LambdaAllAtOnce. EC2/on-premises — OneAtATime, HalfAtATime, AllAtOnce, which count instances, not traffic.
• Amazon ECS: The default deployment type is the rolling update — ECS starts new tasks, waits for them to pass load balancer health checks, then stops old ones (minimumHealthyPercent/maximumPercent set how many change at once; the defaults of 100/200 keep full capacity), so both versions serve briefly with zero downtime. A CodeDeploy blue/green deployment for ECS requires the service to sit behind an Application (or Network) Load Balancer with two target groups — one for the blue tasks, one for green — whose listener CodeDeploy re-points.
• Elastic Beanstalk Deployment Policies: All at once (downtime), Rolling, Rolling with additional batch (keeps full capacity), Immutable (a full new set of instances in a temporary Auto Scaling group; zero downtime, and rollback just terminates the new instances), and Traffic splitting (canary: a percentage of traffic goes to the new instances for an evaluation period). For blue/green, clone the environment, deploy the new version to the clone, validate it, then Swap Environment URLs (a CNAME swap).

Scenario: You need to deploy a new feature to your critical web application. You want to ensure minimal downtime and have the ability to immediately revert to the previous version if the new feature causes any issues after launch.

⚠️ Exam Trap: Blue/green deployment for Lambda (via CodeDeploy) uses traffic shifting on aliases — NOT separate function copies. The "blue" and "green" are versions of the SAME function, not two different functions.