Deployment Strategies
The strategies for shipping a change to a workload that is already serving traffic, and the AWS settings that produce each one: instance refresh, CloudFormation update policies, ECS deployment strategies, Lambda aliases, and RDS blue/green.
Every deployment ships the same code. What changes between strategies is how many users meet a problem before you notice, and how long it takes to undo. This topic covers the vocabulary first (all at once, rolling, immutable, blue/green, canary, linear) and then the specific AWS fields that produce each shape, because on the exam the answer is usually a percentage or a policy name rather than a concept.
What This Topic Covers
- The 2 questions behind every strategy: replace the servers you have or build new ones, and how much traffic reaches the new version at once
- What each strategy costs in extra capacity, exposed users, and rollback speed, with the arithmetic for a rolling batch size
- The boundary between blue/green and canary, stated as a traffic mechanism rather than an environment count
- Why the data tier is the part no strategy fixes: shared schemas, non-reversible writes, and session state
- Auto Scaling instance refresh: minimum and maximum healthy percentages, warmup, checkpoints, skip matching, and the conditions that make rollback unavailable
- The 3 CloudFormation update policies for an Auto Scaling group, and the defaults that empty a fleet
- ECS rolling deployments, the rounding that stalls small services, the deployment circuit breaker, and native blue/green, linear, and canary with bake time and lifecycle hooks
- Lambda versions, aliases, and weighted routing, plus how to tell which version served a request
- Managed RDS blue/green deployments and what happens to the old environment after switchover
Why It Matters
Exam questions in this area rarely ask what blue/green means. They give you a service with 2 tasks and a stalled deployment, an instance refresh that cannot roll back, or a CloudFormation update that took a whole fleet offline, and ask what went wrong. Each of those has a specific setting behind it.
The job pressure is identical. Most production incidents are not caused by writing bad code; they are caused by shipping it in a way that made the problem large before anyone could see it.