AWS CodeDeploy Deployment Strategies - Blue/Green Deployments to EC2 / ECS / Lambda

Manage deployment strategies for the three platforms EC2 / ECS / Lambda in a unified way. This article introduces ECS blue/green deployments and automatic rollback linked to CloudWatch alarms.

CodeDeploy's Supported Platforms and Deployment Types

CodeDeploy is a deployment service that supports three platforms: EC2/on-premises, ECS, and Lambda. For EC2/on-premises, you can choose between in-place deployment (sequentially updating existing instances) and blue/green deployment (creating a new instance group and switching over to it). ECS supports only blue/green deployment, which launches a new task set and switches the target group. Lambda provides gradual deployment through traffic shifting. Deploying to EC2, Lambda, and ECS with CodeDeploy incurs no additional charge, while deployments to on-premises instances are charged for each instance update.

Designing ECS Blue/Green Deployments

In an ECS blue/green deployment, you configure two target groups (one for production and one for testing) on the ALB. When the deployment starts, a new task set (Green) is launched and registered with the test target group. You verify the behavior of the Green environment through the test listener port, and if there are no problems, you switch the production listener's traffic to Green. Even after the switch, the old task set (Blue) is retained for the specified wait time (default 1 hour), so you can go back to the original task set if a problem occurs. You can build a configuration that runs automated tests in the AfterAllowTestTraffic hook of the AppSpec file and automatically rolls back when a test fails.

Automatic Rollback and Alarm Integration

CodeDeploy's automatic rollback works with two triggers: deployment failure and a CloudWatch alarm firing. With CloudWatch alarm integration, you monitor the error rate after deployment (the percentage of 5xx responses), latency (p99 response time), and business metrics (such as order success rate). When a threshold is exceeded, CodeDeploy automatically rolls back to the previous version. In Lambda traffic shifting, a Canary deployment first sends 10% of traffic to the new version, and if no alarm fires for the specified time (for example, 10 minutes), it switches the remaining 90%. A Linear deployment shifts traffic gradually in 10% increments and monitors alarms at each step.

CodeDeploy Pricing

Deploying to EC2, Lambda, and ECS with CodeDeploy incurs no additional charge, while updates to on-premises instances are charged. Compute charges do arise for the period when twice the resources temporarily run during a blue/green deployment, but there is no additional charge for CodeDeploy itself. In an ECS blue/green deployment, both Blue and Green tasks run from the launch of the Green task set until traffic is switched, so Fargate or EC2 charges for that period are added. You can keep costs down by setting a short retention time for the Blue task set after the switch.

Deployment Configurations and Traffic Shifting

In CodeDeploy, you can choose through configuration how traffic is moved when switching to a new version. The method of switching everything at once is fast, but if there is a problem, it affects all users. With the canary method, which starts with a very small portion and gradually increases it, or the linear method, which moves traffic step by step in fixed percentages, you can detect anomalies early and limit the damage. In Lambda, you use an alias to adjust the percentage of traffic between versions and switch over smoothly. By choosing the switching method according to your risk tolerance, you can release new versions while limiting downtime and the impact of failures.

EC2 Deployment Methods

For deployments to EC2 or on-premises servers, you can choose between the in-place method, which sequentially updates running instances, and the blue/green method, which sets up a new group of instances and then switches over. Blue/green makes it easy to go back to the original environment if there is a problem, but it temporarily requires double the resources. The deployment targets are defined as a deployment group using tags and similar means. Because you can insert any processing at each stage of the deployment, you can build in preparation and verification before and after startup. You choose the appropriate method according to the characteristics of the application and your tolerance for downtime.

CI/CD Pipeline Integration

CodeDeploy can be built in as part of a CI/CD pipeline. You can build a flow that automatically deploys the artifacts that have passed build and test in the final stage of the pipeline. The deployment steps and the verification processing to run at each stage are written declaratively in a definition file. As a result, the content of the deployment is managed as code, and reproducibility is maintained. By automating everything from commit to deployment without manual work, you can increase the frequency of releases while reducing human error. A deployment built into a pipeline becomes part of continuous delivery.

Best Practices for Safe Releases

The key to safe deployments is putting in place a mechanism that detects problems early and can roll back automatically. You run verification processing during the deployment to confirm that the new version works correctly. If you monitor metrics after the release and configure it to roll back automatically when it detects an anomaly such as a rise in the error rate, it becomes easier to limit the damage. Combined with a method that shifts traffic gradually, you can notice problems before a full switchover. Building into your mechanisms the principle of not rolling out to all users at once, but trying on a small scale and expanding while confirming, leads to reliable release operations.

Summary

CodeDeploy is a service that manages safe deployments to EC2, ECS, and Lambda in a unified way. Blue/green deployments and traffic shifting limit the risk to production environments, and with CloudWatch alarm integration, you can roll back automatically when a problem occurs. With AppSpec lifecycle hooks, you can build tests into the deployment process and run tests as part of deployment automation.

References (Official AWS Resources)

The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.

If this page and the official documentation disagree, treat the official documentation as authoritative.

Share