Cloud Computing Fundamentals
Scalability and Elasticity
Why a system that can grow and a system that grows and shrinks itself automatically are 2 different skills, and how an Auto Scaling group's capacity settings and scaling policies deliver the second one.
- Distinguish scalability from elasticity and explain why they answer different questions
- Explain how an Auto Scaling group's minimum, desired, and maximum capacity settings work together
- Compare target tracking, step, and scheduled scaling policies and identify which fits a given demand pattern
- Apply elasticity to a worked example that shows the cost impact of matching capacity to real-time demand
The 2 ways a plan for more traffic can go wrong
A retailer sizes its checkout servers for an average shopping day and gets crushed the first time a flash sale doubles traffic overnight; requests queue, pages time out, and the sale becomes the outage story instead of the revenue story. A different team overcorrects: it provisions enough servers to survive its single biggest sale day of the year, then pays for that same fleet the other 364 days, most of them running at a fraction of their capacity. Neither team has solved the actual problem, which has 2 separate parts: can the system grow at all, and does it grow (and shrink) itself to match what is actually happening right now.
Recall: growth you already know how to do
The compute lesson earlier in this course covered horizontal scaling, adding more instances of the same size behind a load balancer, as one answer to running out of capacity. What it did not cover is who decides when to add those instances, or when to take them away again once the load passes. That gap, the decision-making layer sitting on top of horizontal scaling, is exactly what this lesson fills in.
Scalability: the capacity to grow
Scalability is a system's ability to handle more load by adding resources, whether that means resizing 1 machine (vertical scaling) or adding more machines of the same size (horizontal scaling). Nothing in that definition says the growth has to be automatic. A team that notices rising traffic and manually launches 3 more instances has scaled the system. So has an on-premises IT department that orders and racks 2 new physical servers over the course of a month. Both improved the system's capacity to handle load; neither one did it by itself, in real time, or gave any capacity back once it stopped being needed.
Elasticity: matching capacity to demand, automatically
Elasticity is what happens when that decision-making gets automated in both directions: capacity increases as demand rises and decreases as demand falls, without a person watching a dashboard and clicking a button each time. It is a genuinely cloud-native idea. A physical server you already own and paid for doesn't shrink your bill when it sits idle overnight; a cloud instance that gets terminated during a quiet period stops costing you anything the moment it's gone. Elasticity is the reason "pay only for what you use" is more than a slogan: it requires the system to actually notice when "what you use" has changed and to act on that, continuously, without waiting for a human.
Picture a highway that engineers can widen with a construction crew over several months versus a highway with a reversible lane that opens automatically when sensors detect rush-hour traffic and closes again once it clears. Widening the highway is scalability: real capacity, real effort, and no reason to ever undo it. The reversible lane is elasticity: the same road, resized instantly and automatically to the traffic actually on it right now, and closed back up the moment it isn't needed. Push the comparison further and it breaks, a reversible lane is a fixed piece of infrastructure that gets toggled, not created and destroyed, while a cloud instance is provisioned and torn down entirely each time, which is exactly what makes it cost nothing while it's gone.
Worked example: 1 day inside an Auto Scaling group
An Auto Scaling group is the AWS mechanism that automates this. Say a group is configured with a minimum of 4 instances, a desired capacity of 6, and a maximum of 12. Minimum and maximum are hard boundaries the group will never cross in either direction; desired capacity is the starting point a scaling policy adjusts from within that range.
At 9am, traffic climbs and average CPU utilization across the group rises past its target. A target-tracking policy launches new instances, 1 or 2 at a time, until CPU utilization settles back near target, capacity landing around 10 instances by mid-morning. Traffic holds through the day and eases off by 6pm; the same policy now terminates instances as CPU utilization drops below target, easing capacity back down toward 6, and further toward the 4-instance minimum overnight. The group never touches its 12-instance ceiling that day, and it never runs below 4. The team pays for roughly 10 instances during the 9 busy hours that needed them and far fewer overnight, instead of running 12 (or even a flat 10) for all 24.
Scaling policies: 3 ways to tell the group when to act
| Policy | How it decides | Best fit |
|---|---|---|
| Target tracking | Continuously adjusts capacity to hold a chosen metric, like average CPU utilization, near a target value | Live, somewhat unpredictable demand |
| Step scaling | Adds or removes capacity in defined steps sized to how far a metric has moved past its threshold | Demand that can spike sharply and needs a proportionally larger response |
| Scheduled scaling | Sets capacity ahead of a known time, independent of any live metric | Predictable patterns, like a retailer's daily 9am traffic or a monthly batch job |
These are not mutually exclusive. A retail team might run scheduled scaling to pre-warm capacity just before its known 9am spike, then let target tracking handle the rest of the day's smaller fluctuations on top of that head start.
Elasticity also means self-healing
Auto Scaling groups do more than resize for demand. They continuously health-check every instance and replace any that fail, automatically, to keep the group at its desired capacity even when nothing about traffic has changed. That connects directly back to the previous lesson: an Auto Scaling group spread across multiple Availability Zones is part of how a highly available architecture gets built in the first place, not a separate concern from it.
Misconception: "Auto Scaling" is not just about scaling up
It's tempting to hear "Auto Scaling" and picture only the exciting half: automatically adding capacity to survive a traffic spike. The half that actually saves money is scaling in, removing capacity once demand drops. A group with no minimum worth respecting or no scale-in policy attached just becomes an expensive, self-launching version of plain scalability: it grows on its own, but it never gives anything back, and the cost advantage elasticity is supposed to deliver never shows up on the bill.
Exam cues: reading a scalability-versus-elasticity question
| The scenario says... | Points to |
|---|---|
| "Handle a growing amount of load by adding resources" | Scalability |
| "Automatically adjusts to real-time demand," "pay only for what you use," "scales in when idle" | Elasticity |
| "Minimum," "desired," "maximum capacity" | Auto Scaling group settings |
| "Known, predictable spike at a specific time" | Scheduled scaling |
| "Maintain a target CPU utilization" | Target tracking scaling |
Where this leaves you
Scalability answers whether a system can grow at all; elasticity answers whether it grows, and shrinks, itself, automatically, in step with demand that changes minute to minute. Every cloud workload needs the first. Only workloads with genuinely variable demand get real value from the second, which is most of them, since traffic that never varies is rare outside a handful of steady internal systems. The next lesson assumes all of this, redundancy, health checks, right-sized capacity, and asks what happens anyway: when a failure is bigger than any of it can absorb, and a team has to fall back on backups and a disaster recovery plan.