Blue-green stands up a second, identical environment, validates it, and shifts traffic at the load balancer — so a release is instant to roll back instead of a 40-minute incident. This page walks the real strategies (blue/green vs canary vs rolling), how each is implemented on ECS, EKS, Lambda, and a raw ALB, the database and stateful gotchas that quietly break rollbacks, automated rollback on CloudWatch alarms, and the observability gates that decide go/no-go — then how a vetted AWS partner builds it for you, often AWS-funded if you qualify for credits.
The reason anyone reaches for blue-green or canary is the same: the old way — push new code over the running version and hope — turns every release into a small bet on production. A safe deploy removes the bet. It releases with zero user-visible downtime, proves the new version is healthy before it carries real traffic, and can undo itself fast when something is wrong.
Three properties separate a deploy strategy that helps from one that just adds moving parts. First, zero downtime: requests in flight when you cut over are not dropped, and there is no maintenance window. Second, fast, deterministic rollback: when the new version is bad, getting back to the known-good version is one action that takes seconds to a couple of minutes — not a frantic redeploy of an old artifact you hope still builds. Third, a real go/no-go signal: the cutover or ramp is gated on actual health — error rate, latency, saturation — not on "the deploy command exited 0."
The strategy you pick (blue/green, canary, or rolling) is mostly a trade between blast radius and cost/complexity. Rolling is cheapest and simplest but exposes every user to the new version gradually with no clean whole-version undo. Blue-green is the cleanest rollback story but doubles capacity for the duration of the release. Canary is the most controlled — only a small percentage of users see the new version first — but it needs solid metrics and automation to be worth the extra plumbing.
A point worth stating plainly because it trips up so many teams: the hard part of safe deploys is almost never the stateless compute. Flipping traffic between two sets of containers is a solved problem on AWS. What breaks rollbacks is everything with state — the database schema, queues, caches, feature flags, and long-running jobs. A blue-green flip is only truly reversible if the previous version can still run correctly against whatever the new version did to the database while it was live. Most "blue-green didn't actually save us" stories are really database-migration stories. We come back to this in detail in section VI.
The honest framing for this page: the mechanics below are well documented and the AWS-native paths are mature. What is not commoditized is the surrounding design — choosing the right strategy per service, wiring the CloudWatch alarms that actually catch a bad release, defining the bake time, making migrations backward-compatible, and rehearsing the rollback so it works under pressure. That design work is exactly what a good AWS partner does for you in a week or two.
These three terms get used loosely. Here is what each one actually does, mechanically, and the failure mode each one is built to avoid. The full side-by-side table is in the comparison section below; this is the conceptual grounding.
All three are forms of deployment that avoid a hard cutover. They differ in how many versions run at once, how traffic moves between them, and how rollback works.
A rolling deployment replaces the running instances or tasks incrementally: take down (or add) a small batch, bring up the new version, wait for health checks, repeat until everything runs the new version. AWS does this natively — an ECS service update is a rolling update by default, governed by minimumHealthyPercent and maximumPercent; an EKS Deployment uses a RollingUpdate strategy with maxSurge and maxUnavailable.
The upside is that it is the default, costs almost nothing extra (you only need a little headroom, not a second full environment), and needs no special tooling. The downsides are real: during the rollout you have both versions serving live traffic at once, which your code and database must tolerate; rollback means kicking off another rolling deploy back to the previous version, so it is minutes, not seconds; and there is no single moment where you validate the new version in isolation before users hit it.
Rolling is the right default for internal tools, background workers, and stateless services where a brief mixed-version window is harmless and you do not need instant rollback. It is the wrong choice when a bad release must be reversible in seconds.
Blue-green keeps the current version (blue) running while you deploy the new version (green) as a complete, parallel environment behind the same load balancer. You run smoke tests against green on a test listener that real users never touch. When green is proven healthy, you shift 100% of production traffic to it in one move at the load balancer. Blue stays running, idle, for a defined window.
Rollback is the headline feature: because blue is still alive, undoing the release is just shifting traffic back — seconds, no rebuild, no redeploy. After the bake window with no problems, blue is torn down. AWS CodeDeploy automates exactly this for ECS and Lambda: it provisions the green task set, shifts the listener, watches your alarms during the bake, and tears down or rolls back accordingly.
The cost is capacity: for the duration of the release you are running roughly two copies of the service. For most startups that is a few minutes to an hour of doubled task count — trivial. The other subtlety is stateful resources: two versions briefly share one database, so the same migration discipline applies as with rolling. Blue-green gives you the cleanest rollback story on AWS, which is why it is the most common ask behind the search "blue green deployment aws."
A canary deployment sends a small percentage of traffic — commonly 5% or 10% — to the new version while the rest stays on the old one. You hold there for a bake/observation period, watch the new version's error rate and latency against the baseline, and only then shift the remaining traffic. If a metric breaches a threshold during the bake, the rollout aborts and traffic returns to the old version automatically.
Canary has the smallest blast radius of the three: a bad release is seen by a fraction of users for a few minutes, not everyone. The trade is that it depends entirely on good signals and automation — if you cannot reliably tell a healthy canary from a sick one with metrics, the small-slice protection is illusory. It also takes longer end to end because of the deliberate bake. On AWS, CodeDeploy offers predefined canary configs for ECS and Lambda (e.g. Canary10Percent5Minutes: 10% for 5 minutes, then 100%), and on EKS, Argo Rollouts or Flagger drive metric-gated canaries with fine-grained steps.
Canary is the right choice for high-traffic, user-facing services where a regression is costly and you have the observability to gate on. It is overkill for a nightly batch job. Many mature teams use a hybrid: blue-green for the clean rollback property, with a short canary ramp on the new environment before the full flip.
ECS (on Fargate or EC2) is where most AWS teams run containers, and AWS CodeDeploy is the native, batteries-included way to do blue/green and canary on it. This is the path you will use most often.
You configure the ECS service with the CODE_DEPLOY deployment controller and two target groups behind an Application Load Balancer — one for blue, one for green — plus a production listener and an optional test listener. CodeDeploy owns the cutover. When a new task definition is released, it:
The decisions that matter here are not which buttons to click but the policy: which deployment config (all-at-once vs canary vs linear), how long the bake and termination-wait windows are, and — most importantly — which alarms gate the rollback. A blue/green setup with no meaningful alarms attached will happily promote a broken release; the alarms are the safety system, not the traffic shift itself. A good setup wires ALB 5xx rate, target-group unhealthy-host count, and p99 latency, plus one or two business-specific alarms (e.g. checkout error rate), and sets thresholds tight enough to catch a regression but loose enough not to roll back on noise. This is the single most common thing teams get wrong, and the single most valuable thing to get reviewed.
CodeDeploy on ECS is the common path, but the same strategies have first-class implementations on Kubernetes, on Lambda, and at the bare load-balancer layer. Pick the one that matches where the service actually runs.
On Amazon EKS, a stock Kubernetes Deployment only gives you a rolling update. For true canary or blue-green with automated, metric-based gating you add a progressive-delivery controller — most commonly Argo Rollouts (it replaces Deployment with a Rollout resource) or Flagger. You define the rollout steps declaratively: shift to 10% of pods, pause and run an analysis against Prometheus/CloudWatch metrics, then 25%, 50%, 100% — automatically aborting and rolling back if an analysis step fails.
Traffic splitting is done by the ingress/mesh layer: the AWS Load Balancer Controller (ALB weighted target groups), or a service mesh like Istio or AWS App Mesh, or NGINX ingress. Argo Rollouts integrates with these to move the percentages. This pairs naturally with GitOps — Argo CD reconciles the desired Rollout from Git, Argo Rollouts executes the progressive shift. If you are already running Argo CD on EKS, Rollouts is the obvious complement.
Serverless gets the cleanest canary model of all. You publish an immutable version of the function and point an alias (e.g. prod) at it. The alias supports weighted routing — you can send, say, 10% of invocations to the new version and 90% to the old one, then ramp. AWS CodeDeploy manages this for you with predefined configs (e.g. Canary10Percent5Minutes, Linear10PercentEvery1Minute, or AllAtOnce) and rolls back automatically if a CloudWatch alarm fires during the shift.
This is built into the common serverless toolchains: AWS SAM exposes it via AutoPublishAlias + DeploymentPreference, and the Serverless Framework has the same. Add PreTraffic and PostTraffic hook functions to run validation around the shift. For event-driven and API-backed Lambda functions, this is the safe-deploy mechanism — no second environment to stand up, just weighted versions behind one alias.
Underneath all of the above is one primitive: an Application Load Balancer forwarding to weighted target groups. A single listener rule can forward to multiple target groups with weights (e.g. blue 90 / green 10), and you adjust the weights to shift traffic. This is what you reach for when you are not on ECS/EKS/Lambda — for example, services on plain EC2 Auto Scaling Groups — or when you want to script the shift yourself in Terraform/OpenTofu or the CLI.
It works, and it is fully under your control, but you are now responsible for the parts CodeDeploy and Argo Rollouts give you for free: orchestrating the weight changes, running the bake, watching the alarms, and executing the rollback. For most teams that is a reason to use the managed controller rather than hand-roll it — but knowing the ALB primitive is what demystifies what those tools are actually doing.
The traffic shift is the visible mechanic; the observability gate is what actually makes a deploy safe. A canary that nobody is watching is just a slower way to ship a bug to everyone. The gates are the product.
A gate is a measurable condition that must hold for the rollout to proceed, and whose breach aborts it. In practice you gate on a small set of signals, evaluated over the bake window against a baseline:
Two design choices make or break the gate. First, baseline comparison: judge the canary against the current production version over the same window, not against an absolute number, so normal traffic variation does not cause false rollbacks. Argo Rollouts AnalysisTemplates and CloudWatch metric math both support this. Second, bake time: long enough to let a real problem surface (a memory leak or a slow-burning error needs minutes, not seconds), short enough that releases do not crawl. A common shape is 5–10 minutes at the first canary step for a busy service, longer if traffic is low and you need volume to get a signal. The whole point of CloudWatch-alarm-driven rollback on ECS/Lambda, and AnalysisTemplate-driven abort on EKS, is to make these gates automatic — the system rolls back without a human in the loop at 3am.
No rollout proceeds past its first traffic step without a passing gate, and every rollback path is exercised before you rely on it. A blue/green or canary setup with the alarms unconfigured is theatre — it shifts traffic confidently into a broken version. Wire the alarms, set a real bake window, and watch a rollback happen in a drill at least once.
Everything above assumes the new and old versions can coexist and that going back to the old version is genuinely safe. For stateless compute that is true. The moment a release touches a database schema, a queue contract, or a cache shape, "instant rollback" can quietly become "rollback that corrupts data." This is the section that separates a deploy strategy that works on the slides from one that works at 3am.
The core problem: during a blue-green flip or a canary ramp, two versions of your code run against one database. And if you roll back, the old version must run correctly against a schema the new version may already have changed. A migration that drops a column, renames it, or changes its type in a single step makes rollback impossible — the old code expects the old schema, which no longer exists.
The fix is expand-then-contract (also called the parallel-change or expand/contract pattern), which keeps every intermediate state backward-compatible:
Expand: add the new schema element additively — a new nullable column, a new table — without touching or removing the old one. Both old and new code can read the database. Deploy this migration ahead of the code that needs it.
Migrate the code: deploy application code that writes to both the old and new shape and reads from the new one, falling back to the old. Now the new version is live and the old version still works, because nothing was removed. This is the deploy you can blue-green/canary safely.
Backfill: copy historical data into the new shape in the background, idempotently, so the new column/table is complete.
Contract: only after the new version has been stable for long enough that you will never roll back to a version that needs the old shape, deploy a final migration that removes the old column/table. The contract step is a separate release, deliberately late.
Long-running migrations: a migration that locks a large table (adding a non-null column with a default on a big Postgres table, certain index builds) can take the database down even though the deploy "succeeded." Use online/concurrent migration techniques (e.g. CREATE INDEX CONCURRENTLY, add column nullable then backfill) and run heavy data changes outside the deploy.
Message queues and events: if the new version changes a message or event schema, old consumers must still parse old messages and new consumers must tolerate both during the overlap. Version your event payloads; do not make breaking changes in lockstep with a rollout.
Caches and sessions: a changed cache key or serialized-session format can mean the rolled-back version cannot read what the new version wrote. Namespace cache keys by version or make formats forward/backward compatible.
Stateful workloads themselves: databases, brokers, and stores generally should not be blue-green'd as part of the app deploy — you do not stand up a second Postgres and flip it. Keep stateful resources stable and singular; apply the safe-deploy patterns to the stateless tier that talks to them.
There is no universally correct choice; there is a correct choice per service. Here is how to decide quickly, the way a platform engineer would on a whiteboard.
Match the strategy to the service's blast-radius tolerance and your observability maturity, not to fashion.
You can build everything above yourself; this page gives you the map. But most teams searching "blue green deployment aws" do not want to spend two weeks becoming CodeDeploy and Argo Rollouts experts — they want releases to stop being scary, correctly set up, so the team can get back to the product. That is what CloudRoute routes you to.
CloudRoute matches you to a vetted AWS partner who builds safe deploys end to end: the right strategy per service (blue/green, canary, or rolling), the traffic shifting (CodeDeploy on ECS/Lambda, Argo Rollouts on EKS, or weighted ALB target groups), the CloudWatch alarms and automatic rollback, the observability gates and bake windows, and the expand-then-contract migration discipline so rollbacks are genuinely safe — wired into your CI/CD pipeline and handed over tested, with a rollback you have watched work. You get the work done by people who do this for a living, without running a hiring loop or vetting agencies yourself.
The commercial part, stated honestly: for credit-eligible companies, the partner engagement is frequently AWS-funded — the partner is paid through AWS partner-funding programs and your AWS usage during the build is covered by credits — so the customer pays $0 or low cost. If you are not credit-eligible, it is a straightforward vetted-partner referral: you still skip the hiring-and-vetting slog, you just pay the partner for the engagement directly. CloudRoute is paid a commission by the partner, not by you. We will tell you which bucket you are in up front; we do not pretend everything is free.
If you also want the AWS credits that fund the engagement, that runs in parallel. See the AWS credits routes (the $100K Activate Portfolio tier is the common one for funded startups) and the startup persona page below; the deploy work and the credit application are typically filed by the same partner in the same week. Safe deploys also rarely arrive alone — they pair naturally with the CI/CD pipeline, the load-balancer setup, and the observability that the alarms gate on, all of which the same partner can build.
Your repo + which AWS account(s) + your deploy target (ECS / EKS / Lambda) + how critical each service is + how hands-on you want to stay. The partner returns the rollout strategy per service, traffic shifting, alarms with automatic rollback, observability gates, backward-compatible migrations, and a rollback you have watched fire in a drill. For credit-eligible companies, often at $0.
The three strategies compared on the axes that actually drive the choice. Read it as: how big is a bad release's blast radius, how fast and clean is rollback, and what does it cost you in capacity and complexity?
| Dimension | Rolling | Blue-green | Canary |
|---|---|---|---|
| How it works | Replace tasks/instances in place, a batch at a time | Stand up a full second environment, flip 100% at the LB | Shift a small % to the new version, bake, then ramp |
| Versions live at once | Both, transiently, across the fleet | Both, fully, until blue is torn down | Both, with the new one at a small weight |
| Release downtime | Zero (if health-checked) | Zero | Zero |
| Rollback speed | Minutes (redeploy previous) | Seconds (flip back to blue) | Seconds–automatic (abort the ramp) |
| Blast radius of a bad release | Gradual → eventually everyone | Everyone at the flip (until rollback) | Smallest — a fraction of users first |
| Extra capacity needed | Minimal (small surge) | ~2× for the release window | Small (the canary slice) |
| Needs strong metrics/automation | No | Helpful (alarms gate the flip) | Yes — it is the whole point |
| AWS-native path | ECS rolling / EKS RollingUpdate | ECS + CodeDeploy, Lambda alias, weighted ALB | CodeDeploy canary, EKS Argo Rollouts/Flagger |
| Best fit | Internal tools, workers, low-stakes | User-facing services needing clean rollback | High-traffic critical paths with good observability |
Situation: Deploys were rolling ECS updates with no gating: a recent release shipped a query regression that did not crash the service but tripled p99 latency, and because rollback meant kicking off another rolling deploy of the previous image, customers felt it for ~35 minutes before the team got back to known-good. Migrations were run by hand and one had already made a "quick rollback" impossible mid-incident. They wanted releases they were not afraid of but had no dedicated DevOps hire. They were also raising and qualified for AWS credits.
What CloudRoute did: CloudRoute routed them within a day to a US-based AWS partner with an ECS/CodeDeploy track record. The partner moved the API to ECS blue/green via AWS CodeDeploy with two ALB target groups and a CodeDeployDefault.ECSCanary10Percent5Minutes ramp, attached CloudWatch alarms on ALB 5xx, target-group unhealthy hosts, and p99 latency to drive automatic rollback, added BeforeAllowTraffic smoke tests, set a 10-minute termination-wait so blue stayed warm for instant rollback, and converted the migration workflow to expand-then-contract with plan-on-PR. They also filed the AWS Activate Portfolio credit application in the same week.
Outcome: Live in under two weeks. The next regression was caught at the 10% canary step on a latency alarm and rolled back automatically in under a minute — no human paged, no customer-visible incident. Rollback went from a 35-minute scramble to seconds. Because the company was credit-eligible, the engagement was AWS-funded and the customer paid $0; CloudRoute was paid by the partner.
build window: < 2 weeks · rollback: 35 min → seconds (automatic) · last regression: caught at 10% canary · cost to customer: $0 (credit-eligible)
CloudRoute routes you to a vetted AWS partner who builds blue/green or canary, automatic rollback on CloudWatch alarms, observability gates, and safe migrations — wired into your pipeline. For credit-eligible companies it is often AWS-funded — customer pays $0. Otherwise, a clean vetted-partner referral.