Choosing a Deployment Strategy

Twelve EC2 instances sit behind an Application Load Balancer. You have a new AMI that fixes a logging bug and, without knowing it, ships a database driver that leaks connections under load. In about 40 minutes, the pool will be exhausted and requests will start timing out.

Every deployment strategy in this lesson ships that same broken AMI. What they change is how many people are affected before you notice, and how long it takes to undo. That is the whole subject.

The two questions behind every strategy

Strip the vocabulary away and there are only 2 decisions.

Do you change the servers you have, or build new ones? Changing what you have is cheap and leaves you nothing to fall back to. Building new ones costs a second set of capacity and gives you a known-good version still running while you evaluate the new one.

When the new version is live, how much traffic reaches it at once? All of it, a growing fraction, or a fixed small slice you have chosen to risk.

Every named strategy is a specific answer to those 2 questions. Once you see that, the names stop being a list to memorize and start being coordinates.

All at once: the strategy you get for free

Stop the application everywhere, install the new version, start it. This is what a plain yum update and a restart across a fleet does, and it is what you get by default when nobody configures anything.

It is the fastest and the cheapest. No extra instances, no traffic plumbing, no waiting for batches. For a nightly batch worker, a development environment, or a single-instance internal tool with an agreed maintenance window, it is the correct answer and everything else is overengineering.

The cost is that there is a window where nothing serves, and rollback is a second deployment. If your 12 instances take 4 minutes each to restart, undoing a bad release takes another 4 minutes of outage, on top of however long it took you to notice. Nothing about the strategy is designed to help you notice.

Rolling: trade deployment time for availability

Split the fleet into batches and update one batch at a time. Instances in the current batch are taken out of the load balancer, updated, health checked, and put back before the next batch starts.

Work the numbers on those 12 instances with a batch size of 25 percent:

• Batch size is 3 instances, so there are 4 batches.
• While a batch is out, 9 instances serve traffic. That is 75 percent capacity.
• Total deployment time is roughly 4 times (update time plus health check time), so a deployment that takes 4 minutes per batch runs for 16 minutes instead of 4.

That 75 percent number is the design constraint, and it is where teams get hurt. If 12 instances are sized for peak, then 9 instances at peak are 25 percent short, and the deployment itself causes the latency spike. The batch size is not a convenience setting; it is a capacity decision that has to hold at your busiest hour, not your average one.

The fix, when you can pay for it, is to launch an extra batch first and terminate it at the end. You never drop below 100 percent serving capacity, you pay for 3 extra instances for 16 minutes, and the deployment takes one batch longer.

Now the part people underestimate. For most of a rolling deployment, both versions are serving live requests. Instances in completed batches answer with the new version while pending batches answer with the old one, and the load balancer does not care which is which. It is tempting to read "gradual" as "safe", but gradual is exactly what creates the mixed window. If the new version writes a record shape the old version cannot parse, a rolling deployment does not reduce the damage, it extends the period during which the damage is possible.

Rollback matches the same shape: to undo, you roll the fleet again. There is no pointer to move, because the old version has been overwritten wherever the deployment has already reached.

Immutable and blue/green: build first, switch second

The alternative is to stop touching running servers at all. Launch a complete new set from the new configuration, let it prove itself with health checks, and only then retire the originals.

Immutable is this applied to one group of instances. If the new set never goes healthy, you terminate it and the original instances are untouched, because they were never modified. A failed immutable deployment costs you money and a wasted 20 minutes, and costs your users nothing.

Blue/green is the same idea applied to a whole environment. Blue is production. Green is a full parallel copy running the new version: its own instances, its own target group, its own health checks. When green looks right, you move the traffic pointer from blue to green. Blue keeps running, idle, for as long as you want a rollback path.

The pointer is the entire trick, and its mechanism decides how fast you can undo:

Because blue is still running, rollback is a pointer move rather than a rebuild, which is what "fast rollback" actually means in the exam's vocabulary. The bill is straightforward: for the length of the deployment window you are paying for 2 full environments.

Canary and linear: a dial instead of a switch

Canary and linear are not different ways to build the new version. They assume you have already built it, exactly as blue/green does, and they change only the last step: instead of moving all traffic at once, you move a controlled fraction.

Canary shifts in 2 increments. A small percentage, say 10 percent, goes to the new version. You hold there for a set time while you watch error rates and latency. If the numbers hold, the remaining 90 percent follows.

Linear shifts in equal steps at equal intervals: 10 percent every 2 minutes until everything has moved.

What you buy is a measurement. Health checks tell you the process is listening on a port; a canary tells you real requests from real users are being answered correctly. The cost is that some users do meet the bug, by design, and the deployment now takes as long as your evaluation window.

Which means a canary is only worth running when 2 things are true: enough traffic reaches the canary slice to produce a readable signal, and you have decided in advance which metric and which threshold ends the deployment. A 1 percent canary on a service handling 20 requests per minute gives you about 3 requests to reason with. That is theater, not evidence.

Here is the boundary the exam probes. Blue/green and canary both run 2 environments, so counting environments does not tell them apart. Blue/green minimizes how long anyone is exposed to a bad version, by making the switch instant and reversible. Canary minimizes how many people are exposed, by holding most traffic back while you look. One is a switch, the other is a dial.

The comparison that matters

Read the table as a price list. Capacity is money. Exposure is user impact. Rollback speed is the time you spend serving a known-bad version. You are always paying with at least one of the three.

Picking one

The decision is usually forced by a constraint rather than a preference, so start with the constraints:

• A maintenance window is acceptable. All at once. It is faster and cheaper, and the sophistication buys you nothing.
• No downtime allowed, no budget for extra capacity. Rolling. Size the batch so the remaining fleet carries peak.
• Full capacity required throughout, some budget available. Rolling with an extra batch, or immutable.
• Rollback must be measured in seconds. Blue/green, or its traffic-shifted variants. Nothing that rebuilds capacity can meet that bar.
• You need evidence from real traffic before committing. Canary or linear, with a named metric and a threshold.

One constraint overrides all of these: can 2 versions of the application run at the same time? If they cannot, rolling, canary, and linear are all off the table regardless of budget, and you are choosing between a maintenance window and a blue/green switch.

The part none of them solve

Blue/green gets described as risk-free rollback, and for stateless application code that is close to true. The moment state enters, it stops being true, and this is where real incidents come from.

The database is usually shared. Green almost never gets its own copy of production data, because a copy would immediately be stale. So blue and green talk to the same database, and any schema change applies to both. Ship a migration that drops a column the old code reads, and the rollback path is gone: switching back to blue now means switching to code that cannot query its own database.

The discipline is to make schema changes backward compatible and separate them from the code that needs them. Add the new column and start writing to it while the old code ignores it. Deploy the code that reads it. Only after the new version is proven, in a later release, remove the old column. Slower, and it keeps the pointer meaningful.

Data written during the window does not roll back. If green serves for 10 minutes and writes 4,000 rows in a new format, moving the pointer to blue restores the old code and leaves those 4,000 rows exactly where they are. Traffic rollback is not data rollback.

Session state has to live outside the instances. A user halfway through a checkout on blue who lands on green needs their session to exist there. If sessions are held in instance memory, every one of these strategies drops customers mid-transaction, and the load balancer's stickiness settings only hide it until the instance goes away.

State the misconception plainly, because it survives most people's first blue/green: an instant traffic switch is not an instant undo. It undoes routing. It does not undo writes, migrations, cache contents, or messages already published to a queue.

Exam tips

• "Quickest deployment" or "a short period of downtime is acceptable" points at all at once. It is the right answer more often than candidates expect, because they read simple as wrong.
• "No downtime and no additional cost" is rolling. Adding "must maintain full capacity throughout" is what turns it into rolling with an additional batch.
• "Roll back quickly" or "revert immediately if there is a problem" means the old version must still be running: blue/green, or a weighted traffic shift. Any answer that redeploys the previous version is describing a slow rollback.
• "Test with a small percentage of production traffic" is canary. "Shift traffic in equal increments over equal intervals" is linear. The distinguishing words are percentage and increments, not the number of environments.
• A scenario that mentions a DNS or CNAME swap and then complains that some users still reach the old version is testing TTL and resolver caching, not a service failure.
• Watch for a database detail buried in a blue/green question. A schema migration in the same release is the trap, and the correct answer is usually to make the change backward compatible or to run it as a separate earlier step.
• An immutable deployment that fails leaves the original instances serving. A rolling deployment that fails leaves you with a mix of versions. Questions about the state after a failure are testing exactly that difference.

Carry one sentence out of this lesson: the strategy you pick is a statement about what you are willing to spend to shorten the gap between shipping a bad version and being able to undo it. You pay in money (a second environment), in time (a slower rollout), or in users (someone meets the bug). There is no option that pays nothing.

The next lesson turns each of these shapes into the specific AWS setting that produces it, which is where the exam actually lives: instance refresh percentages, CloudFormation update policies, ECS deployment strategies, Lambda aliases, and managed blue/green for RDS.