Elasticity
😟 THE PROBLEM
Results go live at 10:00 and visitors jump from 300 to 300,000 in a minute.
😊 THE SOLUTION
Use autoscale: servers are added and removed automatically, in real time.
- Humans react too slowly✓ Autoscale reacts in minutes, automatically
- Paying for servers overnight✓ It scales back in when demand drops
- Impossible to predict the peak✓ Capacity follows real demand
Quick answer
Elasticity is the ability of a cloud system to automatically add or remove resources in real time as demand changes, so capacity closely tracks actual usage. It is scalability made automatic and fast. In Azure, elasticity comes from autoscale features in services such as Virtual Machine Scale Sets, App Service, Azure Functions and AKS.
Exam objective: 1.2.1 Describe the benefits of high availability and scalability in the cloud. (Skills measured as of July 20, 2026)
Start with a question
Results are published at 10:00. At 9:59 there are 300 visitors. At 10:01 there are 300,000. Who adds the servers?
No human can react that fast. If someone has to notice the slowdown, log in and add servers, the site will already be down when they finish.
The cloud’s answer is elasticity: the system watches demand and stretches itself automatically, then shrinks back when the crowd leaves.
Explain it like I’m 10
The technical explanation
Elasticity is the ability to automatically and rapidly provision and release resources so that capacity matches demand at any moment. It builds on scalability. Scalability says you can add resources; elasticity says the system does it for you, in real time.
Bought once for an "average busy day". Idle at night, overwhelmed at the 3 pm exam rush.
37%capacity idle
5%demand unmet
An engineer adds or removes servers on a schedule. Better, but the rush arrived an hour before anyone reacted.
30%capacity idle
1%demand unmet
Capacity follows demand automatically with a small safety buffer. Very little waste, nobody turned away.
15%capacity idle
0%demand unmet
Scalability vs elasticity
| Scalability | Elasticity | |
|---|---|---|
| What it is | Ability to change resources to meet demand | Automatic, real-time adjustment of resources |
| Trigger | Manual or planned (often) | Metrics or events (CPU, queue length, HTTP requests) |
| Speed | Minutes to days | Seconds to minutes |
| Typical tool | Resize a VM, add instances | Autoscale rules, serverless platforms |
Elasticity in Azure
-
1 Measure
Azure Monitor collects metrics: CPU, memory, HTTP queue, Service Bus messages.
-
2 Evaluate
Rule: average CPU > 70% for 10 minutes?
-
3 Act
Add 2 instances (up to the maximum).
-
4 Shrink
CPU < 30%? Remove 1 instance (down to the minimum).
Services with built-in elasticity include Virtual Machine Scale Sets, App Service autoscale, Azure Functions and Azure Container Apps (event-driven, including scale to zero), and AKS (horizontal pod autoscaler and cluster autoscaler).
Architect level Writing autoscale rules that behave
- Always pair scale-out and scale-in rules, with a gap between thresholds (70% out, 30% in) to avoid oscillation.
- Set realistic minimums (for availability, at least 2) and maximums (to cap cost and protect downstream systems).
- Scale on the metric that reflects user pain. For workers, queue length usually beats CPU.
- Use scheduled profiles for known events and let metric rules handle surprises.
- Keep start-up time short. Elasticity is only as fast as your instances become healthy.
Real-world business scenario
A concert ticketing site
- The problem
- Traffic goes from almost nothing to hundreds of times normal when tickets go on sale, and drops within an hour.
- What they used
- Front end on App Service with a scheduled scale-out 15 minutes before each sale plus CPU-based autoscale; order processing via Service Bus queue and Azure Functions.
- Why that choice
- Elasticity handles the unpredictable size of each spike automatically and removes capacity right after, keeping costs low between sales.
- The result
- Sales opened without crashes, and compute costs between events dropped to a small baseline.
When to use it and when not to
✓ Use it when…
- Spiky, unpredictable or event-driven workloads.
- Consumer-facing apps with daily or weekly patterns.
- Background processing where queue length varies widely.
✕ Think twice when…
- Applications that take a long time to start, unless you pre-warm or keep a minimum.
- Workloads with perfectly flat demand. Fixed capacity plus a reservation is simpler and cheaper.
↔ Alternatives to consider
- **Scheduled scaling** for predictable patterns.
- **Serverless** for event-driven work that scales automatically with no rules to manage.
Interview preparation
Say your answer out loud first, then open the model answer. Interviewers care more about your reasoning than the exact words.
Beginner What is elasticity?
Model answer
Elasticity means the cloud automatically adds resources when demand goes up and removes them when demand goes down, without anyone doing it manually. Like a rubber band that stretches and shrinks back.
Interviewer follows up
How is that different from scalability?
You
Scalability is the ability to change resources to meet demand, which can be manual. Elasticity is when that scaling happens automatically and quickly in response to real-time demand.
Intermediate How would you configure elasticity for a web app on Azure App Service?
Model answer
Enable autoscale on the App Service plan with a minimum and maximum instance count, a scale-out rule (for example CPU above 70% for 10 minutes, add 2 instances), a matching scale-in rule (CPU below 30%, remove 1), and cool-down periods. Optionally add schedule-based profiles for known peaks, or use automatic scaling, which scales on HTTP traffic.
Experienced developer What can go wrong with autoscale in production?
Model answer
Flapping, where rules that are too sensitive or have no cool-down scale out and in repeatedly. Slow start-up, where new instances take minutes to warm up, so the peak passes first (use pre-warming, minimum instances or scheduled scale-out). Missing scale-in rules, so costs never come down. Scaling on the wrong metric, such as CPU when the real bottleneck is a queue length or database. And downstream overload, where scaling out the front end overwhelms a database that cannot scale as fast. You also need quota headroom in the region.
Scenario A ticket website gets massive spikes the minute concert tickets go on sale, then quiet within an hour. Which cloud benefit is most important?
Model answer
Elasticity. Capacity must grow automatically within minutes and shrink straight afterwards so they do not pay for idle servers. Combine autoscale with a scheduled scale-out just before the sale opens, plus a queue for orders.
Test yourself with exercises
4 original practice questions in the AZ-900 style. Pick your answers, then check them. You will see why each option is right or wrong. Score 75% or more and this topic is marked complete.
Quick revision
Key points
- Elasticity = automatic, rapid scaling in both directions as demand changes.
- It is a specific kind of scalability; all elastic systems are scalable, but not all scalable systems are elastic.
- In Azure, implemented through autoscale (Scale Sets, App Service, Functions, AKS, Container Apps).
- Saves money by removing capacity automatically when demand drops.
- Needs good rules, a minimum and maximum, and cool-down periods.
Important terminology
- Elasticity
- Automatically and rapidly matching resources to current demand, up and down.
- Autoscale
- Rules or metrics that automatically change the number of instances (for example, add 2 instances when CPU > 70%).
- Scale-in rule
- The rule that removes instances when demand drops, which is the part that saves money.
- Cool-down
- A waiting period after a scale action before the next one, to avoid flapping up and down.
Common mistakes
- Treating any scaling as elasticity. Manual scaling is scalability, not elasticity.
- Forgetting scale-in rules, so capacity never shrinks.
Exam tips
- "Automatically" + "based on demand" + "add and remove resources" = elasticity.
- If the scenario only says "can be increased", without automatic, think scalability.
Five quick revision questions
-
1.What makes elasticity different from scalability?Show
Elasticity is automatic and happens in real time based on demand.
-
2.Which Azure feature provides elasticity for VMs?Show
Virtual Machine Scale Sets with autoscale.
-
3.Why do autoscale rules need a cool-down period?Show
To avoid flapping, meaning rapid repeated scale-out and scale-in.
-
4.Which part of autoscale saves money?Show
The scale-in rules that remove unused instances.
-
5.Name a workload that needs elasticity.Show
Ticket sales, flash sales, exam result days, which are all sudden unpredictable spikes.
Official references
Finished this lesson? Tick it off. Your progress is saved in this browser.
Next up: Reliability