blue-green-deploy

Create two Deployments labeled with slot: blue and slot: green, then point a single Service selector at the active slot. Switch traffic by patching the Service selector to the new slot after validating readiness and running smoke tests against the new pods.

Use the elbv2 client to wait for targets in the new target group to become healthy, then call modify_rule on the listener's default rule to forward to the new target group ARN. Monitor health checks afterward and modify the rule back to the old target group if failures exceed the threshold.

Only backward-compatible migrations are safe because both blue and green versions run simultaneously during the switch. Adding nullable columns and concurrent indexes is safe; dropping or renaming columns must be split across multiple deploys with dual-write and backfill phases.

Rollback flips the traffic selector or load balancer rule back to the previous slot, which is still running the old version. Because the old environment stays alive for at least 30 minutes after the switch, rollback completes in seconds without redeploying anything.

Avoid blue-green when you cannot afford double infrastructure capacity, when your application relies on sticky sessions or local state, or when database changes cannot be made backward compatible. In those cases, consider canary or rolling deployments instead.