If you have worked with Amazon ECS long enough, you have probably heard two different stories that both sound true.

The first says that if you want blue/green on ECS, you use AWS CodeDeploy. The second says that Amazon ECS now supports rolling, blue/green, canary, and linear deployments directly. Both are true — they just belong to different generations of the ECS deployment model.

The real distinction is not the rollout names; it is the control plane. In the legacy path, CodeDeploy owns the blue/green workflow and ECS participates through task sets. In the newer path, the ECS deployment controller owns the service deployment directly and tracks service revisions inside ECS itself.

That shift matters because most real environments are mixed. Existing services may still depend on the older CodeDeploy pattern, while new services can often standardize on the native ECS strategies. If you lead platform or DevOps work, you need to be comfortable in both worlds.

The one distinction that clears up most confusion

Amazon ECS separates the deployment controller from the deployment strategy.

A deployment controller is the control plane that runs the release. In practice, that means ECS for native ECS-managed deployments, CODE_DEPLOY for CodeDeploy-managed ECS blue/green, and EXTERNAL for a third-party deployment controller.

A deployment strategy is the rollout shape used by that controller. With the ECS deployment controller, ECS supports ROLLING, BLUE_GREEN, CANARY, and LINEAR.

Older write-ups often equate "ECS blue/green" with "CodeDeploy," but current AWS docs also describe native ECS blue/green, canary, and linear. Advanced ECS traffic shifting used to be a CodeDeploy-only capability. It is now also an ECS-native one.

Quick comparison: what changes in the traffic layer?

The fastest way to explain the entire topic is through the traffic layer.

Built-in rolling usually keeps the same listener and target-group path, with ECS replacing tasks in place.

Legacy CodeDeploy blue/green introduces the dual-target-group model, a production listener, and an optional test listener, with CodeDeploy deciding how traffic moves between blue and green task sets.

Built-in ECS blue/green, canary, and linear also use a dual-environment traffic model for managed shifting, but ECS now owns the listener-rule changes and the rollout behavior.

Quick matrix — what changes in the traffic layer across built-in and legacy ECS deployment models.

Full comparison diagram

The same idea is clearer with the legacy and native models side by side.

Figure 1 — Legacy CodeDeploy controller vs native ECS controller. Both use a dual-target-group pattern; the difference is who owns the rollout.

Part 1: The legacy model — CodeDeploy blue/green for Amazon ECS

For a long time, if a team wanted something safer than a standard ECS rolling update, it usually meant stepping into CodeDeploy-controlled blue/green.

In that model, the ECS service uses deploymentController = CODE_DEPLOY, the deployment is started through CodeDeploy, CodeDeploy creates a replacement green task set, traffic is shifted away from the original blue task set, and after success, blue is terminated according to deployment settings.

From the load-balancer point of view, the pattern is deliberate and explicit. Legacy CodeDeploy ECS blue/green requires two target groups, a production listener, and an optional test listener. One target group serves blue and the other serves green during deployment.

Note that legacy ECS traffic shifting can be all-at-once, canary, or linear — but those are CodeDeploy deployment configurations, not separate ECS-native strategies.

Legacy diagram 1 — CodeDeploy blue/green, all-at-once

The fastest legacy cutover. It is still blue/green because CodeDeploy creates and validates a replacement task set, then moves production traffic in one step.

Figure 2 — Legacy CodeDeploy blue/green, all-at-once. A single 0% → 100% production shift after green is provisioned.

Legacy diagram 2 — CodeDeploy blue/green, canary

The legacy two-phase rollout. CodeDeploy shifts a small percentage first, evaluates health and alarms during the canary interval, and only then shifts the remainder.

Figure 3 — Legacy CodeDeploy blue/green, canary. ALB-based; uses a CodeDeployDefault.ECSCanary* deployment configuration.

Legacy diagram 3 — CodeDeploy blue/green, linear

The most gradual traffic-shift pattern in the legacy model. CodeDeploy increases traffic to green in equal steps, giving you more than one checkpoint before full cutover.

Figure 4 — Legacy CodeDeploy blue/green, linear. ALB-based; uses a CodeDeployDefault.ECSLinear* deployment configuration.

Important legacy caveat — when the legacy model uses a Network Load Balancer, AWS documents all-at-once as the supported traffic-shift mode. That is why legacy canary and linear are presented here as ALB-based examples.

Part 2: The modern model — native Amazon ECS service deployments

The modern ECS deployment story is cleaner because the ECS deployment controller now owns the deployment behavior directly.

Instead of relying on CodeDeploy to manage replacement task sets, the native model works with ECS service deployments and service revisions. That reduces control-plane sprawl and turns the strategy choice into a single ECS concern rather than a multi-service orchestration problem.

For managed traffic shifting, AWS documents support through Application Load Balancer, Network Load Balancer, or Service Connect, depending on the pattern. The diagrams below use Application Load Balancer because that makes the traffic behavior easiest to follow visually.

Native strategy 1 — Rolling

Rolling remains the simplest native option. ECS launches new tasks, stops old tasks as deployment progresses, and follows the deployment configuration controlled by minimumHealthyPercent and maximumPercent.

From the traffic-layer point of view, rolling changes the least. The service typically stays on the same target-group path and ECS replaces tasks in place. ECS can support multiple target groups for some service designs, but that is a service capability, not a blue/green traffic-shift requirement.

Figure 5 — Native ECS rolling deployment. Same target-group path; tasks are replaced in place under min-healthy / max-percent constraints.

Native strategy 2 — Blue/Green

Native ECS BLUE_GREEN is the closest built-in replacement for teams that used blue/green for safer cutovers and quick rollback.

The most important point: native ECS blue/green is not "blue/green with optional canary or linear." In the native model, BLUE_GREEN, CANARY, and LINEAR are separate strategies. Native blue/green performs an all-at-once production cutover after validation.

For ALB-based native blue/green, ECS uses a primary target group for blue, an alternate target group for green, a production listener rule for production traffic, and an optional test listener (or test rule) for validation traffic. ECS updates the listener rules during deployment.

Figure 6 — Native ECS blue/green. ECS owns the listener-rule swap. Primary TG = blue, alternate TG = green.

Native strategy 3 — Canary

Native ECS CANARY is the small-blast-radius strategy.

ECS launches the green service revision, can optionally validate it with test traffic, then shifts a configured small percentage of production traffic to green. ECS waits through the canary bake time, and if the deployment stays healthy, shifts the remaining traffic and waits through the deployment bake time before terminating blue.

The traffic model is straightforward: a small percentage first, the rest later.

Figure 7 — Native ECS canary. A single small slice, a bake window, then a full shift.

Native strategy 4 — Linear

Native ECS LINEAR is the most gradual rollout.

ECS launches green, optionally validates it, then shifts production traffic in equal percentage increments with a configured step bake time between increments. After reaching 100% green, ECS waits through the deployment bake time before terminating blue.

This fits services where you want more than one checkpoint and you expect some issues to appear only as traffic gradually increases.

Figure 8 — Native ECS linear. Equal-step shifts with a bake between each, then a deployment bake before teardown.

What actually changes between rolling and blue/green-style deployments?

Summary of the practical differences across deployment models.

What I would choose in practice

If I were setting standards for an AWS platform team today, I would keep the defaults simple.

Use rolling when the service is low risk, backward compatibility is strong, and traffic shaping is unnecessary.

Use native blue/green when you want safer releases than rolling, you want validation before production cutover, and you do not need a gradual production ramp.

Use native canary when blast radius matters most and you want a small real-user slice before full cutover.

Use native linear when you want the smoothest progressive rollout and more checkpoints than canary provides.

Keep legacy CodeDeploy blue/green when services already run it successfully and migration would create more near-term risk than value.

Legacy CodeDeploy still matters because many production estates still run it, but the center of gravity for new ECS design has clearly moved toward native ECS deployment strategies.

The most common mistakes to avoid

• Do not say native blue/green "contains" canary and linear. In native ECS, those are separate strategies.
• Do not draw legacy canary or linear as NLB-based. The legacy NLB path supports all-at-once.
• Do not imply rolling always uses exactly one target group. Rolling usually stays on the same target-group path, but ECS can support multiple target groups for some service designs.
• Do not treat native ECS traffic shifting as a CodeDeploy feature. ECS supports native BLUE_GREEN, CANARY, and LINEAR with the ECS deployment controller.
• Do not mix task-set language with service-revision language. Legacy CodeDeploy ECS blue/green uses task sets; native ECS deployments use service revisions.

Where to go next

This post compares legacy and ECS-native deployment strategies, but ECS-native deployments now include more capabilities than can comfortably fit into a comparison article. Built-in blue/green, canary, and linear deployment strategies support deployment lifecycle hooks — Lambda functions invoked at defined stages of a deployment, so teams can run automated validation, smoke tests, or custom checks before traffic shifts further.

These hooks pair naturally with a test listener or listener rule for pre-production validation against the green target group, as described in the ECS blue/green deployment workflow. They also work well with CloudWatch alarms and bake windows, where a failing alarm can trigger an automated rollback instead of requiring manual intervention. ECS canary and linear deployments extend the same idea by shifting production traffic gradually, giving teams multiple checkpoints to detect issues before 100% of traffic reaches the new revision.

If you already run CodeDeploy blue/green deployments and are wondering whether to migrate, AWS has published an official AWS Containers Blog post, Migrating from AWS CodeDeploy to Amazon ECS for blue/green deployments, that walks through the practical migration steps and key ECS deployment model changes. Pair it with the Migrate CodeDeploy blue/green deployments to Amazon ECS docs page for the reference details. Migration is not free — CodeDeploy deployments, ECS service revisions, and task sets use different mental models — but for most greenfield ECS services, the ECS-native model is now the better default going forward.