ECS just got easier with built-in blue/green deployments

For years, doing blue/green deployments on ECS meant coordinating several loosely coupled services. ECS ran your tasks, CodeDeploy handled traffic shifting, and ALBs routed requests, but there was no single, cohesive deployment model tying them together. You had to configure deployment groups, alarms, listener rules, and permissions across multiple services. Everything had to line up exactly for a rollout to succeed. Even small oversights, such as a missing IAM permission or an outdated deployment configuration, could stop the deployment mid-flow or shift traffic at the wrong moment. The result was a deployment process that was fragile, complex, and operationally expensive. Teams made it work, but small misconfigurations could easily cause failures, and the risk of production incidents remained high.

That has changed. ECS now handles blue/green deployments natively. What used to require CodeDeploy, multiple configurations, and careful orchestration can now be managed entirely within ECS. This means you can deploy updates safely and reliably without having to juggle multiple services or worry about misconfigured deployment groups.

This newsletter breaks down the key changes developers need to understand about native ECS blue/green deployments, the challenges involved in migrating from legacy workflows, and practical steps to adopt native blue/green deployments without disrupting running services. By the end, you should have a clear model for planning, configuring, and deploying updates safely, while relying on built-in traffic shifting, monitoring, and rollback mechanisms.

Blue/green deployments and legacy ECS workflow#

A blue/green deployment is a strategy to update applications with minimal risk. You have two versions of your service. The blue version is the current production version in service, and the green version is the new version you wish to deploy. Traffic is gradually shifted from blue to green, allowing you to test the new version in production while keeping the old version available for reference. If something goes wrong, you can quickly switch back to the blue version.

Previously, ECS did not manage this process independently. To perform a blue/green deployment, you needed CodeDeploy. ECS would run your tasks, but CodeDeploy handled creating a new task set, routing traffic through load balancers, and managing rollbacks. This required setting up deployment groups, configuring listener rules, and monitoring health checks across multiple services. While effective, the process was complex, error-prone, and resulted in additional operational overhead.

Native blue/green deployments in ECS#

With the latest update, ECS now handles blue/green deployments internally, removing the need for CodeDeploy. When you update a service, ECS creates a new task set for the updated revision and continues to run the existing task set. You can configure how traffic shifts between the old and new versions. ECS monitors the health of the new task set and automatically rolls back to the previous version if any issues are detected.

This native approach simplifies deployments by managing task sets, traffic shifting, monitoring, and rollback all within ECS. Developers and operators no longer need to coordinate multiple services or manually configure deployment groups and listener rules. At the same time, it preserves the core principle of blue/green deployments, which involves a safe and controlled rollout of new versions with the ability to quickly revert if needed.

How to migrate to native ECS blue/green deployments#

Migrating from CodeDeploy to ECS native blue/green deployments starts with understanding your resources.

• Reusing existing resources: For services already using CodeDeploy, you can reuse the existing load balancer, production listener, and target groups. The production listener must be preconfigured with a rule that includes both target groups, with the primary group weighted at 1 and the secondary group weighted at 0. After that, these resources can be modified to work with the ECS deployment controller by simply updating the service configuration to use the blue/green strategy.

• Parallel deployments: To run a parallel deployment, new target groups and listener rules must be created under the same load balancer.

• Reverse proxies: For setups behind a reverse proxy, such as Route 53 or CloudFront, creating a new ECS service with a new load balancer, listener rules, and target groups enables full parallel testing without impacting the existing service.

IAM roles are critical#

IAM roles are a critical part of the migration process. Your ECS service needs an IAM role that grants permission to manage the load balancer, target groups, and, if used, life cycle hooks. Each Lambda function must also have a role that allows it to execute and report status back to ECS. For existing services using CodeDeploy, you need to replace or update the old CodeDeploy IAM role with a new ECS role containing the required permissions. Assign the appropriate IAM roles when creating or updating the ECS service to ensure the deployment can register and deregister targets, adjust listener rules, and invoke any life cycle functions. Without the correct permissions, the deployment will fail.

Migration steps#

Once the required resources and IAM roles are in place, the remaining migration steps are mostly straightforward.

• Update the ECS service to use the ECS deployment controller and the blue/green strategy.

• Assign the appropriate load balancer, target groups, and optional life cycle hooks.

• For parallel deployments, launch the green service and gradually shift traffic from the old version, closely monitoring task health and application behavior to ensure a smooth transition.

Rollback is handled either by reverting the service revision, adjusting listener rule weights, or redirecting traffic at the proxy layer, depending on your approach. After verifying that the new deployment works as expected, you can safely retire the old CodeDeploy setup.

Why native blue/green deployments matter#

Native ECS blue/green deployments provide clear, tangible advantages that go beyond simply removing CodeDeploy. With this update, teams can:

• Reduce deployment time: Handling task set creation, traffic shifting, and health checks internally, cutting down the number of manual steps from minutes to seconds.

• Lower operational risk: Unhealthy deployments are automatically rolled back in real time, eliminating delays or mistakes caused by misconfigured load balancer rules.

• Simplify infrastructure management: The consolidation of what previously required multiple services into a single, unified ECS workflow.

• Enable safer experimentation: Gradually shifting traffic to new versions lets teams test updates in production without impacting the existing version.

These advantages translate into measurable improvements. Updates that once required careful coordination across ECS, CodeDeploy, and load balancers can now be executed reliably in a single service. Rollbacks are faster and more predictable. Teams can deploy more frequently, reduce downtime, and spend less time troubleshooting deployment issues.

Final thoughts and looking ahead#

Migrating to native ECS blue/green deployments can simplify deployment workflows and reduce operational risk. By auditing existing ECS services, validating load balancers and target groups, testing parallel task sets, and planning staged traffic shifts, you can transition to the native model without disrupting production traffic.

ECS continues to add deployment features, including improved life cycle hooks, bake times, and internal traffic management. Staying up to date with the ECS service documentation ensures you can leverage these improvements and maintain reliable, predictable deployments.

Putting theory into action#

Now that you understand how native ECS blue/green deployments simplify service updates and reduce operational risk, it’s time to get hands-on with it.

Educative Cloud Labs enable you to work directly with ECS and related AWS services in a secure, controlled environment. For ECS blue/green deployment, you can try out our Creating an Amazon ECS Service Using a Blue/Green Deployment lab that walks you through setting up an ECS service with blue/green deployment using real AWS infrastructure.