Calculate resource and downtime implications of a blue-green deployment switch.
A blue-green deployment keeps both the old (blue) and new (green) environments fully provisioned simultaneously during the cutover window, so peak resource usage doubles: resources = 2 × normal. Rollback speed is bounded by how quickly traffic can be redirected back to the stable environment, which for DNS-based cutovers is governed by the DNS record's TTL plus a buffer for resolvers/clients that cache slightly beyond the nominal TTL: rollback_time = dns_ttl + propagation_buffer.
total_capacity_during_deploy = blue_instances + green_instances
Unlike a rolling update which replaces capacity incrementally, blue-green provisions a complete second environment before cutting over, so both environments must run at full capacity simultaneously during the overlap window to allow instant, safe rollback.
Shorten the cutover window duration (validate quickly and decommission the old environment sooner), or use a partial blue-green approach where only a subset of capacity is duplicated while traffic gradually shifts — though this starts to resemble a canary deployment.
If cutover is done via DNS record changes (e.g. pointing a CNAME to a new load balancer), rollback speed is bounded by DNS TTL and caching resolvers; if cutover is done via a load balancer's own routing rules or service mesh virtual service, rollback can be nearly instant instead, bypassing DNS propagation delay entirely.
20-50% of the TTL value is a reasonable buffer to account for resolvers and clients that don't strictly honor TTL, though some misbehaving clients or aggressive caching layers (e.g. some corporate proxies) can hold stale records far longer than the TTL suggests.