Blue-green needs two full fleets. Canary needs traffic-splitting infrastructure. Rolling deployment is the middle ground: you replace instances in your existing fleet a few at a time, so at any moment most of the fleet is serving traffic and a small slice is being updated.

The mechanics are simple. Take N instances out of the load balancer, drain their in-flight requests, deploy the new version, health-check them, put them back in, and repeat. Kubernetes does this by default with its RollingUpdate strategy — maxUnavailable caps how many pods can be down, maxSurge caps how many extras can exist temporarily.

The rule of thumb: your batch size should be small enough that losing it doesn't degrade service, and your total rollout time should be long enough to catch problems. For a 20-instance fleet with 30-second health checks, a batch of 2 with a 60-second soak between batches gives you a 10-minute rollout — enough time for error-rate alarms to trigger before you've replaced everything.

Real-world example: You're deploying a new version of an order service running on 12 EC2 instances behind an ALB. You configure the deployment group with MinimumHealthyHosts: 75%, meaning at most 3 instances can be out at once. The deployer pulls 3 instances out, deploys, waits for health checks, and moves to the next batch. Halfway through, CloudWatch fires a 5xx alarm — the deployer halts, and you still have 6 instances on the old version serving traffic. You roll forward with a fix or roll back the completed batches.

The catches:

• Mixed versions run simultaneously. Your v1 and v2 code must be forward- and backward-compatible for the duration of the rollout. Database migrations must be additive (add column, don't rename).
• Rollback is slow. Unlike blue-green's instant traffic flip, rolling back means another rolling deployment in reverse — 10 more minutes while bad code serves users.
• Session affinity breaks. If a user is pinned to an instance that gets replaced, their session goes with it unless state lives elsewhere.
• Capacity dips. With maxSurge: 0, you're temporarily running at reduced capacity. If you're already near your load ceiling, deploy during off-peak or set maxSurge to add temporary instances.

When to pick it: stateless services with backward-compatible changes, when a second full fleet is too expensive (blue-green doubles infra cost), and when your problems tend to surface within minutes rather than hours. If you need instant rollback or long-tail bug detection, canary or blue-green is worth the extra machinery.