Deployment strategies
There is no best deployment strategy, only a best fit for a workload's tolerance for downtime, its cost profile, and how quickly it needs to be able to go back.
Choosing
| Strategy | Downtime | Rollback speed | Cost during deploy | Best for |
|---|---|---|---|---|
| All-at-once | Yes, briefly | Redeploy | None extra | Non-production, batch, internal tools |
| Rolling | None if capacity allows | Redeploy previous batch | Moderate | Most stateless web workloads |
| Rolling with additional batch | None | Redeploy | +1 batch | Capacity-constrained workloads where available capacity is tight |
| Immutable | None | Re-point to previous ASG | +full second set, briefly | Workloads where any in-place mutation is unacceptable |
| Blue/green | None | Instant traffic switch | Double for the transition | Customer-facing services with strict availability targets |
All-at-once
The new version is deployed to every instance in the Auto Scaling group simultaneously. The old version is replaced everywhere at once.
before: [v1] [v1] [v1] [v1]
during: [v1→v2] [v1→v2] [v1→v2] [v1→v2]
after: [v2] [v2] [v2] [v2]
Pros. Fast; simple to reason about; no extra capacity.
Cons. Any defect affects every instance immediately; there is a window where no instance is serving; rollback means another full replacement.
Use for development and test environments, scheduled batch workloads, and internal tools where a brief interruption is acceptable.
Rolling
Instances are divided into batches. One batch is replaced at a time; the rest keep serving the previous version.
before: [v1] [v1] [v1] [v1]
step 1: [v2] [v2] [v1] [v1]
step 2: [v2] [v2] [v2] [v2]
Pros. No downtime if capacity is sufficient; a failed batch affects a subset; rollback is limited to the replaced batch.
Cons. Slower; two versions run simultaneously, so the application must tolerate mixed versions (schema compatibility, API contracts); capacity must cover the departure of a batch.
Use for most stateless web applications.
Rolling with additional batch
A new batch of instances is launched first, then the old instances are replaced. Available capacity never drops below the pre-deployment level.
before: [v1] [v1] [v1] [v1]
step 1: [v1] [v1] [v1] [v1] [v2]
step 2: [v2] [v2] [v2] [v2] [v2] (old four retired)
Pros. Maintains full capacity throughout; no downtime even at the capacity limit.
Cons. Temporarily costs more; still runs mixed versions during the transition.
Use where the workload runs close to its capacity ceiling and cannot spare instances during a deploy.
Immutable
A complete new Auto Scaling group is created with the new version. Once healthy, instances are moved to the new group and the old one is terminated.
before: ASG-A [v1] [v1] [v1]
create: ASG-B [v2] [v2] [v2] ← health-checked
switch: traffic → ASG-B, ASG-A terminated
Pros. No in-place mutation, so configuration drift cannot affect the deployment; rollback is re-pointing to the previous group; a failed deployment leaves the running system untouched.
Cons. Requires double capacity during the transition; slower; requires a clean separation between instance state and application state.
Use where instances must be reproducible — anything built from a golden image, and any workload where in-place changes are a compliance concern.
Blue/green
Two identical environments exist. Production traffic points at one; the new version is deployed to the other; traffic is switched when it passes validation.
blue [v1] ←── live traffic
green [v2] staged and validated
↓
blue [v1] retained for rollback
green [v2] ←── live traffic
Pros. Instant rollback by switching traffic back; the new version is validated under production-equivalent conditions before it receives traffic; the old environment remains available.
Cons. Roughly double the infrastructure while both environments exist; the data layer must be compatible with both versions simultaneously; DNS or load balancer switching must be reliable and fast.
Use for customer-facing services with strict availability targets and a data layer that supports backward-compatible changes.
Data compatibility
Every strategy except all-at-once runs two versions at once for some period. That has consequences beyond the compute layer:
- Schema changes must be backward compatible. Add columns, do not rename or drop them in the same release. Use expand/contract across two releases.
- API contracts must tolerate both versions. A consumer on v1 must still work while v2 rolls out.
- Message formats must be versioned. A queue draining during a deploy contains messages from the previous version.
- Session state must be externalised. A user mid-session must not be pinned to a terminating instance.
A deployment strategy that assumes instant cutover breaks on the first incompatible migration.
Rollback
| Strategy | Mechanism | Typical time |
|---|---|---|
| All-at-once | Redeploy previous version | Full deployment duration |
| Rolling | Redeploy previous version | Full deployment duration |
| Immutable | Point ASG back to previous image | Minutes |
| Blue/green | Switch traffic back | Seconds to minutes |
| Container (ECS/EKS) | Roll back to previous task definition / revision | Minutes |
Rollback is a rehearsed action. If the team has never executed it, it is a plan, not a capability.