Scalability, Elasticity, and High Availability

Every module so far in this course introduced one AWS service or pattern at a time. This module asks a different question: given a real workload's actual requirements, which combination of services and patterns genuinely fits — and just as importantly, what trade-off does each choice carry?

A useful discipline for every scenario in this module: before naming any service, ask what the workload actually needs to do, who uses it, what traffic to expect, what happens when a component fails, what data must persist, what security boundaries apply, whether processing must be synchronous, how the system should scale, how it will be observed, how it will recover, what it will cost, and how infrastructure changes will be managed. Architecture is the answer to those questions — a service name is just the tool that answer points to.

Scalability is a system's ability to handle changing load — more users, more requests, more data. Elasticity is specifically about that capacity adjusting automatically in response to demand, rather than requiring someone to manually provision more capacity ahead of time. A system can be scalable (capable of handling more load, given enough manual provisioning) without being elastic (automatically adjusting on its own) — the next lesson's Auto Scaling Groups are exactly the mechanism that adds elasticity to an otherwise merely scalable design.

High availability is a different property again: the ability to remain accessible despite the failure of individual components. This course's own recurring building block for this is spreading resources across multiple Availability Zones (Module 1) — an application and its data tier deployed in more than one AZ so that one AZ's failure doesn't take the whole application down.

This is worth stating precisely: scalability and availability are not the same thing. A system can scale to handle enormous traffic and still have a single point of failure that takes it down entirely. A highly available system, spread carefully across AZs, may still fall over under load it was never sized to handle. Neither property substitutes for the other.

This distinction matters enough to state directly: high availability reduces interruption from component or infrastructure failures within an architecture's normal operating scope — it is not the same thing as disaster recovery. Multi-AZ deployment is a strong, common high-availability pattern, but it does not by itself constitute a complete disaster-recovery strategy for every scenario a business might need to plan for. Disaster recovery is about recovering from a larger-scale failure or disaster scenario, and can involve backups, replicated data, documented recovery procedures, and — depending on the actual requirement — alternate environments or even alternate Regions.

Two concepts worth knowing by name here, kept deliberately conceptual: RTO (Recovery Time Objective) — how quickly a service must be restored after a disruption — and RPO (Recovery Point Objective) — how much recent data loss is acceptable, measured in time. Different businesses can justify very different answers: a small internal tool might reasonably accept an RTO of several hours and an RPO of an hour, while a payments system might require an RTO of minutes and an RPO close to zero — and that difference in requirement is exactly what justifies very different (and very differently priced) architectures. Neither number is universal; both come from the actual business requirement, not a default.