How to use this rolling vs blue-green guide
Enter your instance count, batch size, replacement time and canary share, and the page works out what each of the three strategies demands: instances needed, waves, total replacement time, the capacity drop during the deploy and the unit you roll back in.
How it is calculated
Rolling waves are ceil(instances / batch) and total time is waves times replacement time. The capacity drop is max(0, batch minus extra instances) divided by instances. Blue-green stands up a second stack of the same size, so instances needed double and the extra cost is extra instances times overlap hours times hourly cost. The first canary wave is ceil(instances x share), with a floor of one instance. As of October 2026 this page proposes no recommended share or batch size.
Limits and cautions
No strategy is declared the winner here. The blue-green startup figure assumes room to launch the whole stack at once, and health check waits and connection draining are not included. A database schema change is never reversed automatically under any of these strategies.
Frequently asked questions
During the switch, yes. The old stack has to stay up while an equally sized new stack comes online, which is what lets routing move in one step. In exchange, rolling back is also one routing switch, the fastest of the three. Keeping the overlap short keeps the extra cost down.
The batch being replaced cannot take traffic while it restarts. Allowing extra instances covers the gap, and once the extra count equals the batch size the drop reaches zero. The trade is a higher peak instance count.
Traffic splits only one instance at a time. Asking for 5% of 12 instances works out to 0.6, which rounds up to a single instance, and that single instance is 8.3% of the fleet. Finer control needs more instances or request-level weighting instead.