Blue-green deployment keeps two identical production environments running side by side. One (say, blue) serves live traffic. The other (green) sits idle, ready to receive a new release. You deploy the new version to green, smoke-test it against real infrastructure, then flip the load balancer to point at green. Blue is now your instant rollback: one config change reverts the entire release.

The critical property is that the switch is atomic. There is no window where half your traffic hits v1 and the other half hits v2 (that's canary — a different pattern). At time T, everyone is on blue. At T+1ms, everyone is on green. If green explodes, you flip back before your on-call finishes their coffee.

Real-world example: A payments API team runs blue on ECS behind an ALB target group. They deploy v2.3 to the green target group, run a synthetic transaction suite against green's internal DNS name, then update the ALB listener rule to route 100% to green. Ten minutes later, an alert fires: green is throwing 500s on a rare currency conversion path. The on-call flips the listener back to blue in under 30 seconds. No customers noticed. Debug happens on green with zero pressure.

The traps nobody warns you about:

• Database migrations are the hard part. Both environments share the DB. Your schema changes must be backward-compatible with blue for the entire cutover window. Rule of thumb: expand, migrate, contract — add the new column, backfill, deploy code that uses it, then remove the old column in a later release.
• In-flight requests on blue don't magically finish. Drain connections before terminating, or use a graceful shutdown period (typically 30–60s).
• Stateful sessions break. If blue holds sticky sessions in local memory, cutover logs everyone out. Externalize session state to Redis first.
• Cost. You're paying for 2x infrastructure during the release window. For 24/7 blue-green, that's a permanent 2x compute bill — often justified for tier-1 services, rarely for internal tools.

Rule of thumb: Blue-green makes sense when your rollback cost (revenue lost per minute of a bad release × mean time to detect) exceeds the infrastructure cost (2x compute during the release window). For a service doing $10K/hour with a 15-minute MTTD, one bad release without blue-green costs $2,500 — often more than a month of duplicate infra.

Compare to canary (gradual %-based rollout, better for detecting subtle issues) or rolling deploy (cheaper, no instant rollback). Blue-green wins on speed of rollback and simplicity of reasoning: at any moment, 100% of traffic is on exactly one version.