CodeDeploy: Blue/Green, Canary, Linear

AWS CodeDeploy is a fully managed deployment service that automates software deployments to various compute services like Amazon EC2, AWS Lambda, and Amazon ECS. It supports multiple deployment strategies to control how traffic is shifted from an original (current) version to a new (revision) version. The three primary strategies are Blue/Green, Canary, and Linear. Each strategy defines the pace and pattern of traffic shifting, which directly impacts risk, rollback speed, and user experience. The DVA-C02 exam expects you to know the differences, configuration parameters, and appropriate use cases for each.

Blue/Green deployment involves provisioning a new set of resources (green environment) alongside the existing ones (blue environment). Once the green environment is ready and passes health checks, traffic is shifted from blue to green in a single step. This strategy is ideal for applications that can tolerate the cost of running duplicate environments temporarily and require instant cutover.

How it works: - CodeDeploy creates a replacement environment (e.g., new Auto Scaling group, new Lambda function alias, or new ECS task set). - Traffic is routed to the new environment using a load balancer or Lambda alias routing configuration. - The original environment remains intact for a configurable 'termination wait time' (default 5 minutes) to allow rollback if issues are detected. - After the wait time, the original environment is terminated.

Key parameters: - DeploymentOption: WITH_TRAFFIC_CONTROL (default) or WITHOUT_TRAFFIC_CONTROL. - TerminationWaitTimeInMinutes: 0 to 2880 (48 hours). Default is 5. - LifecycleEventHooks: BeforeAllowTraffic and AfterAllowTraffic can be used to run validation tests.

Exam tip: Blue/Green is the fastest rollback because you can instantly switch back to the original environment if the green fails. However, it requires double the resources during deployment.

Canary deployment shifts traffic in two increments: first a small percentage (the canary), then the remainder after a specified interval. This is used to validate the new version with a subset of users before full rollout.

How it works: - Initially, a small portion of traffic (e.g., 10%) is sent to the new version. - After a 'canary interval' (e.g., 5 minutes), the remaining 90% of traffic is shifted to the new version. - The canary percentage and interval are defined in the deployment configuration.

Key parameters (for Lambda and ECS): - CanaryPercentage: 5, 10, 15, or 20% (predefined configurations). - CanaryInterval: 5, 10, or 15 minutes. - For EC2/On-Premises, CodeDeploy uses a different mechanism: it deploys to a batch of instances first (canary), then to the rest.

Predefined configurations: - CodeDeployDefault.ECSCanary10Percent5Minutes - CodeDeployDefault.LambdaCanary10Percent5Minutes - CodeDeployDefault.ECSCanary10Percent15Minutes - CodeDeployDefault.LambdaCanary10Percent15Minutes - CodeDeployDefault.ECSCanary10Percent10Minutes (not for Lambda)

Linear deployment shifts traffic in equal increments at fixed intervals until 100% of traffic is on the new version. This provides a gradual, predictable rollout.

How it works: - At each interval, a fixed percentage of traffic is shifted to the new version. - The process continues until all traffic is shifted. - For example, Linear10PercentEvery1Minute shifts 10% every minute, completing in 10 minutes.

Key parameters: - LinearPercentage: 5, 10, or 15% per interval. - LinearInterval: 1, 2, 3, 5, or 10 minutes.

Predefined configurations: - CodeDeployDefault.LambdaLinear10PercentEvery1Minute - CodeDeployDefault.ECSCanary10Percent5Minutes (actually linear? No, ECS has both canary and linear) - CodeDeployDefault.ECSLinear10PercentEvery1Minute - CodeDeployDefault.ECSLinear10PercentEvery3Minutes - CodeDeployDefault.LambdaLinear10PercentEvery10Minutes - CodeDeployDefault.EC2Linear10PercentEvery1Minute (for EC2/On-Premises)

Exam tip: The exam often tests the difference between canary and linear: canary has two phases (small then full), linear has multiple equal steps. Also note that for EC2/On-Premises, CodeDeploy uses a different model: it deploys to a percentage of instances at a time, not traffic weighting.

EC2/On-Premises: - Blue/Green: Requires an Auto Scaling group and a load balancer. CodeDeploy creates a new ASG and attaches it to the ELB. - Canary/Linear: CodeDeploy deploys to a batch of instances (canary) or a percentage of instances per interval (linear). Traffic shifting is achieved by deregistering old instances and registering new ones with the load balancer. - Note: For EC2, canary and linear are not as granular as for Lambda/ECS—they deploy to a percentage of instances, not traffic weight.

AWS Lambda: - Blue/Green: Uses Lambda alias traffic shifting. The alias points to two versions with a routing config. - Canary/Linear: Lambda alias routing config automatically shifts traffic weight over time. - Lifecycle hooks: BeforeAllowTraffic and AfterAllowTraffic run validation.

Amazon ECS: - Blue/Green: Uses ECS task sets and a load balancer target group. CodeDeploy creates a new task set and shifts traffic. - Canary/Linear: CodeDeploy uses the ECS deployment controller type CODE_DEPLOY and adjusts the task set's traffic weight. - Lifecycle hooks: BeforeInstall, AfterInstall, BeforeAllowTraffic, AfterAllowTraffic.

CodeDeploy can automatically roll back a deployment if a CloudWatch alarm is triggered or if the deployment fails. Rollback redeploys the last known good revision. For Blue/Green, rollback is instantaneous by switching traffic back to the original environment. For Canary/Linear, rollback may take time because it redeploys the previous version.

Key exam points: - Rollback triggers: deployment failure, manual stop, CloudWatch alarm. - Rollback configuration: AutoRollbackConfiguration with events like DEPLOYMENT_FAILURE, DEPLOYMENT_STOP_ON_ALARM, DEPLOYMENT_STOP_ON_REQUEST. - Rollback redeploys the previous revision, not the original environment (except Blue/Green where original may still exist).

Lifecycle hooks allow you to run custom scripts or Lambda functions at various stages of the deployment. Common hooks: - BeforeInstall: Run tasks before the new application revision is installed. - AfterInstall: Run tasks after installation. - BeforeAllowTraffic: Run validation before traffic is shifted to the new version. - AfterAllowTraffic: Run validation after traffic is shifted. - ValidateService: Run health checks after deployment.

For Lambda and ECS, the hooks are BeforeAllowTraffic and AfterAllowTraffic. For EC2, you have additional hooks like ApplicationStop, DownloadBundle, Install, ApplicationStart.

Creating a deployment with canary (CLI):

aws deploy create-deployment \
    --application-name MyApp \
    --deployment-group-name MyDG \
    --deployment-config-name CodeDeployDefault.LambdaCanary10Percent5Minutes \
    --revision revisionType=AppSpecContent,appSpecContent=...

Creating an ECS deployment with linear:

aws deploy create-deployment \
    --application-name MyECSApp \
    --deployment-group-name MyECSGroup \
    --deployment-config-name CodeDeployDefault.ECSLinear10PercentEvery1Minute \
    --revision revisionType=AppSpecContent,appSpecContent='{"version":1,"Resources":[{"TargetService":{"Type":"AWS::ECS::Service","Properties":{"TaskDefinition":"arn:aws:ecs:...","LoadBalancerInfo":{"ContainerName":"web","ContainerPort":80}}}}]}'

| Strategy | Traffic Shift Pattern | Rollback Speed | Resource Cost | Use Case | |----------|----------------------|----------------|---------------|----------| | Blue/Green | Instant (100% at once) | Fast (switch back) | Double during deploy | Critical apps needing instant cutover | | Canary | Two steps: small then full | Moderate (redeploy) | Canary resources | Validate with a subset of users | | Linear | Multiple equal steps | Moderate (redeploy) | Gradual resource use | Controlled rollout with constant monitoring |

Exam trap: Candidates often confuse canary and linear. Remember: canary has exactly two phases (e.g., 10% then 90%), linear has many equal phases (e.g., 10% every minute for 10 minutes). Also, Blue/Green is the only strategy that allows instant rollback without redeploying.

A large e-commerce company uses Blue/Green deployments for their critical checkout service running on ECS. They have two production clusters (blue and green) in different Availability Zones. During a deployment, CodeDeploy creates a new task set (green) with the updated container image, attaches it to the load balancer, and shifts 100% traffic instantly. The original task set (blue) remains for a termination wait time of 30 minutes. If any errors are detected (e.g., increased 5xx errors), the team manually rolls back by shifting traffic back to blue. This strategy ensures zero downtime and instant rollback. The cost of running duplicate clusters is acceptable given the revenue impact of downtime. One common mistake is forgetting to set the termination wait time long enough—if set too short (e.g., 1 minute), the original environment might be terminated before rollback is possible.

A SaaS company uses canary deployments for their user-facing API running on AWS Lambda. They want to test a new feature with 10% of users for 5 minutes before full rollout. They use CodeDeployDefault.LambdaCanary10Percent5Minutes. The Lambda alias 'prod' initially routes 100% to version 1. During deployment, CodeDeploy creates version 2 and updates the alias routing to 10% version 2, 90% version 1. After 5 minutes, it shifts to 100% version 2. They monitor error rates and latency via CloudWatch alarms. If the canary phase shows increased errors, they trigger a rollback. A common issue is that the canary interval is too short to gather meaningful data—they learned to use at least 10 minutes for statistically significant results.

A bank uses linear deployments for their backend batch processing system on EC2. They need a controlled rollout to avoid overwhelming the system. They use CodeDeployDefault.EC2Linear10PercentEvery1Minute, which deploys to 10% of instances every minute. Each batch of instances is taken out of service, updated, and re-registered with the load balancer. They use lifecycle hooks to run database migration scripts before traffic is shifted. A common problem is that if the migration script fails, the entire batch fails, causing a partial deployment. They mitigate by running the migration as a separate step before the deployment. Misconfiguration of the load balancer deregistration delay can cause connection draining issues, so they set the deregistration delay to match the deployment interval.