– All at once – Deploy the new version to all instances simultaneously. All instances in your environment are out of service for a short time while the deployment occurs.
– Rolling – Deploy the new version in batches. Each batch is taken out of service during the deployment phase, reducing your environment’s capacity by the number of instances in a batch.
– Rolling with additional batch – Deploy the new version in batches, but first launch a new batch of instances to ensure full capacity during the deployment process.
– Immutable – Deploy the new version to a fresh group of instances by performing an immutable update.
– Blue/Green – Deploy the new version to a separate environment, and then swap CNAMEs of the two environments to redirect traffic to the new version instantly.
| Method | Impact of Failed Deployment | Deploy Time | Zero Downtime | No DNS Change | Rollback Process | Code Deployed To |
|---|---|---|---|---|---|---|
| All at once | Downtime | 1 | No | Yes | Manual Redeploy | Existing Instances |
| Rolling | Single batch out of service; any successful batches before failure running new application version | 2.5 | Yes | Yes | Manual Redeploy | Existing Instances |
| Rolling with additional batch | Minimal if first batch fails; otherwise, similar to Rolling | 3.5 | Yes | Yes | Manual Redeploy | New and Existing Instances |
| Immutable | Minimal | 4 | Yes | Yes | Terminate New Instances | New Instances |
| Blue/green | Minimal | 4 | Yes | No | Swap URL | New Instances |
