Blue/Green Deployment: Definition, Pros, and Cons

Last verified on Nov 8, 2026.

Blue/green deployment is a release technique built on two identical environments. The blue environment runs the current version and serves production traffic. The green environment runs the new version, staged in parallel. When green is ready, you shift traffic to it. AWS says the approach gives releases near zero downtime and a rollback path.

How It Works

Stand up green beside blue, on its own resources, with the new version.
Test green without user traffic: smoke tests, health checks, and internal requests.
Shift traffic. Move the load balancer, route, or DNS record from blue to green.
Watch it. Keep blue running and watch error rate and latency against what blue showed.
Roll back or retire. If green misbehaves, point traffic back to blue. If it holds, retire blue.

The shift can be abrupt or gradual. With DNS routing in Amazon Route 53, AWS says you can move traffic all at once or use weighted records, increasing green's share step by step. That weighted approach is effectively a canary, which AWS calls out. A rollback is a DNS update, but DNS Time to Live (TTL) controls how long clients cache the old answer, so your rollback is only as fast as your TTL.

AWS CodeDeploy automates this. For EC2, it installs the latest revision on replacement instances and reroutes traffic when you choose, immediately or after you finish testing. For Amazon ECS, it installs the update as a replacement task set, reroutes production traffic, and terminates the original task set after a successful deployment. CodeDeploy can stop and roll back a deployment on errors, automatically or manually.

Why Teams Use It

AWS names these benefits:

Isolation. Green is built on separate resources, so launching it does not disturb blue.
Validation in production conditions. In-place upgrades make it hard to validate a new version in production while the old one keeps running.
Simpler CI/CD. Automation has fewer dependencies on the existing environment's state.
Cost control. You can size the new environment for the new version and do not have to stay overprovisioned for long.

The Database Problem

The hard part is data. AWS says the difficulty depends on how many data stores you have, how intricate the data model is, and your consistency requirements. Unstructured stores such as object storage, NoSQL databases, and shared file systems are often easier to share between environments. Relational stores where the schema can diverge need more care.

The recommended technique is to decouple schema changes from code changes: make additive schema changes first so both versions work, then remove old fields in a later release. AWS warns that deletive changes carry more risk, because the old version may still depend on something you removed, or an undocumented dependency may bring down the version you wanted to fall back to. Put weight on pre-deployment testing.

When Not to Use It

AWS lists situations where blue/green may not be worth it:

Schema changes too complex to decouple, or data stores that cannot be shared, such as environments in different regions. You then have to synchronize data in both directions, which adds risk and moving parts.
Applications that must be deployment aware, with code that behaves differently during the cutover. AWS says this adds risk and complexity, and that blue/green aims at immutable infrastructure.
Commercial software with its own tested upgrade process, where working around it can negate the benefits.

AWS also marks its whitepaper on the topic as historical reference, so check current service documentation for exact steps.

Blue/Green vs Canary

Both limit the damage of a bad release, and the line between them is blurry. In AWS Lambda documentation, a canary exposes the new version to part of the requests, while blue/green switches all traffic at once. AWS's deployment overview calls canary a more risk-averse blue/green strategy that shifts traffic in two increments. Google's workbook describes blue/green as resembling an A/B canary, with green as the control, blue as the canary, and traffic share setting the canary population. See canary deployment for metrics and an example.

Watching a Cutover

Blue/green fails quietly when nobody compares the two sides. Track error rate and latency per environment, and keep blue warm until green has served real load for long enough to trust. The page on regression detection after a deploy covers how new failures appear in logs, and the guides on latency spikes and crash loops cover two failures that tend to show up right after a cutover. A bad cutover is also an incident: use your runbook for rollback, and learn from it in a postmortem.

Frequently Asked Questions

What is a blue/green deployment?

A release technique that runs two identical environments, one serving production traffic (blue) and one running the new version (green), and shifts traffic between them. Rolling back means pointing traffic at the original environment again.

What is the difference between blue/green and canary deployment?

Blue/green typically cuts traffic over from one full environment to the other, while a canary exposes the new version to a portion of requests and widens gradually. AWS describes canary as a more risk-averse form of blue/green, and Google describes blue/green as resembling an A/B canary.

How do you handle databases in a blue/green deployment?

The usual approach is to share the data store between both environments and separate schema changes from code changes. Additive changes ship first and deletions later, because deleting a field the old version needs can break the environment you wanted to keep as a fallback.

When should you avoid blue/green deployment?

AWS lists cases where it adds risk: data stores you cannot share, schema changes too complex to decouple, applications that must be deployment aware, and off-the-shelf software with its own upgrade process.

Sources

Watch your next cutover with Sazabi