This chapter covers two related but distinct cloud concepts — high availability and scalability. AZ-900 tests this under objective 1.5, and confusing these two concepts with each other is one of the most common mistakes candidates make.
Jump to a section
A simple way to picture High Availability and Scalability
A store preparing for a busy weekend might open more checkout registers to handle the extra customers — that's scalability, adding capacity to match demand. Separately, that same store might make sure that if one register's card reader breaks, another register is ready to take over immediately so the line doesn't stop moving — that's high availability, staying operational even when something fails. They solve different problems: one is about handling more load, the other is about surviving a failure without stopping service.
What high availability means
High availability refers to a system's ability to remain operational and accessible even when something fails — a server crashes, a network link drops, or a single data center has an issue. It's typically achieved through redundancy: having more than one instance of a critical component so a failure in one doesn't take down the whole system.
What scalability means
Scalability refers to a system's ability to handle increased (or decreased) demand by adding or removing resources. There are two common approaches: scaling up (or vertically) — increasing the power of an existing resource, like upgrading to a larger virtual machine — and scaling out (or horizontally) — adding more instances of a resource, like adding more virtual machines behind a load balancer.
How they relate but differ
A highly available system can still be poorly scaled — it might survive a failure but struggle under heavy load. A highly scalable system can still have poor availability — it might handle heavy load well but have no redundancy if a single component fails. Well-designed cloud architectures generally aim for both, but they address different risks.
Azure's role
Azure provides features that support both — redundant infrastructure and services (like Availability Zones, covered in a dedicated chapter) support high availability, while services like virtual machine scale sets and autoscaling support scalability.
Identify what problem you're solving
If the concern is 'what happens if something fails,' that's a high availability question. If the concern is 'what happens as demand grows or shrinks,' that's a scalability question.
Add redundancy for availability
High availability generally comes from having more than one instance of a critical component, so a single failure doesn't take the whole system down.
Choose scaling up or scaling out for scalability
Scaling up increases the power of a single resource; scaling out adds more instances of a resource. The right approach depends on the specific workload and its limitations.
Design for both where it matters
Many production systems need both — enough redundancy to survive a failure, and enough scalability to handle changing demand — though the balance depends on the workload's actual requirements.
An online ticketing platform preparing for a high-demand ticket release uses autoscaling to add more server instances as demand spikes, then scales back down once demand subsides — that's scalability in action. Separately, the same platform runs its database across multiple redundant instances, so if one instance fails, another takes over without customers noticing — that's high availability.
A common real-world mistake is designing a system that scales well under load but has a single point of failure — for example, a scalable application that all still depends on one non-redundant database instance. If that single instance fails, the scalability of everything else doesn't matter, since the whole system goes down anyway.
Objective 1.5 frequently tests the distinction between high availability and scalability — expect scenario-based questions that describe a situation and ask which concept it demonstrates.
The most common wrong answer is treating high availability and scalability as the same thing, or as automatically implying each other — a system can have one without the other. Another common trap is confusing "scaling up" (vertical) with "scaling out" (horizontal) — scaling up makes one resource bigger, scaling out adds more resources.
Stable terms: high availability, scalability, scale up (vertical), scale out (horizontal). These distinctions come up repeatedly across the exam whenever resiliency or performance under load is discussed.
Memory trick: availability = surviving a failure. Scalability = handling changing demand. They're solved with different techniques (redundancy vs. adding/adjusting capacity) and neither one guarantees the other.
High availability is about a system remaining operational despite failures, typically through redundancy.
Scalability is about a system handling changes in demand, through scaling up (vertical) or scaling out (horizontal).
The two concepts are related but distinct — a system can be strong in one without automatically being strong in the other.
Well-designed systems generally aim for both, using different techniques to address each concern.
These come up on the exam all the time. Here's how to tell them apart.
High Availability
Focuses on surviving failures
Achieved through redundancy
Answers: 'What happens if something breaks?'
Example: multiple redundant database instances
Scalability
Focuses on handling changing demand
Achieved through scaling up or out
Answers: 'What happens as load increases or decreases?'
Example: autoscaling a virtual machine scale set
Mistake
High availability and scalability are the same concept.
Correct
They address different problems — high availability is about surviving failures, scalability is about handling changing demand. A system can have strong performance in one without the other.
Mistake
A scalable system is automatically highly available.
Correct
Scalability handles load; it doesn't automatically provide redundancy against failure. A system can scale well and still have a single point of failure.
Mistake
Scaling up and scaling out are interchangeable terms for the same thing.
Correct
Scaling up (vertical) means making an existing resource more powerful; scaling out (horizontal) means adding more instances of a resource. They're different approaches with different tradeoffs.
High availability is about a system staying operational even when something fails, usually achieved through redundancy. Scalability is about a system handling more or less demand by adding or adjusting resources. They solve different problems and don't automatically imply each other.
Scaling up (vertical scaling) means increasing the power of an existing resource, like upgrading to a larger virtual machine. Scaling out (horizontal scaling) means adding more instances of a resource, like adding more virtual machines behind a load balancer.
No. Scalability addresses handling load, not surviving a failure. A system can scale very well under demand and still have a single point of failure with no redundancy — the two need to be designed for separately.
You've just covered High Availability and Scalability — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?