AWS Academy Cloud Architecting — Module 9: Implementing Elasticity, High Availability, and Monitoring

Module Objective: Design a compute architecture that scales elastically, tolerates failure across Availability Zones, and is observable through monitoring.

Cross-cutting design begins here: Starting with this module, the course shifts from adding new layers to applying design principles across every layer already built.

Elasticity and Scalability

Scalability is the ability of a system to handle growth; elasticity is the ability to scale automatically, in both directions, in response to actual demand — the latter being a defining characteristic of well-architected cloud systems rather than a nice-to-have.

Concept	Example
Vertical scaling	Moving to a larger EC2 instance type — limited by the largest available size
Horizontal scaling	Adding more EC2 instances behind a load balancer — limited mainly by architecture design
Elasticity	An Auto Scaling group automatically adding and removing instances as load changes

🔵 Note Horizontal scaling combined with a stateless compute design (Module 4) is what makes elasticity practical — a stateful, vertically-scaled server is much harder to scale elastically.

High-Availability Architecture Patterns

Applying the fault-tolerance and high-availability concepts from AWS Academy Cloud Foundations Module 3 to a concrete design: every tier of the café architecture — load balancer, compute, and database — should be spread across at least two Availability Zones.

Tier	Multi-AZ Pattern
Load balancer	An Elastic Load Balancer inherently spans multiple AZs
Compute	An Auto Scaling group launches instances across subnets in multiple AZs
Database	An RDS Multi-AZ deployment maintains a synchronously replicated standby in a second AZ

⚠️ Warning — A Single-AZ Design Has a Single Point of Failure No matter how well-designed the other pillars are, an architecture confined to one Availability Zone remains vulnerable to that AZ's failure — this is one of the most commonly tested points on the SAA-C03 exam.

Elastic Load Balancing Revisited

Building on AWS Academy Cloud Foundations Module 5, this module applies Elastic Load Balancing as the mechanism that ties a Multi-AZ Auto Scaling group together into a single, reliable endpoint — automatically routing around unhealthy instances or AZs.

✅ Tip — The Load Balancer Is the Architecture's Front Door Every request into the café's application tier should pass through the load balancer — never directly to an individual instance's address, which would bypass health checking and defeat the purpose of the Auto Scaling group.

Auto Scaling Revisited

The Auto Scaling group concepts and policy types from AWS Academy Cloud Foundations Module 10 are applied here as the mechanism that actually delivers elasticity — dynamically resizing the compute tier as the CloudWatch metrics below detect changes in demand.

🔵 Note Setting an Auto Scaling group's minimum capacity to at least 2, spread across 2 AZs, is a common minimum bar for a production architecture — even before dynamic scaling policies are added on top.

Monitoring with Amazon CloudWatch Revisited

CloudWatch metrics, alarms, and dashboards — covered in AWS Academy Cloud Foundations Module 10 — are what make elasticity and high availability observable and actionable: without monitoring, there's no way to know whether the architecture is actually meeting demand or approaching a failure.

✅ Tip — Monitor Every Tier, Not Just Compute A well-architected design monitors the load balancer, the Auto Scaling group, and the database tier — not only EC2 CPU utilization — since a bottleneck can appear at any layer.

Key Terms for Module 9

elasticity: The ability of a system to automatically scale resources up and down in response to demand
horizontal scaling: Adding more resources, such as instances, rather than making a single resource larger
Multi-AZ deployment: Spreading a tier's resources across multiple Availability Zones for fault tolerance
minimum viable Auto Scaling group: A group configured with at least two instances spread across at least two AZs as a baseline for production

Review Questions

What is the difference between scalability and elasticity?
Why is a single-Availability-Zone architecture considered a design flaw rather than a minor risk?
How does Elastic Load Balancing tie a Multi-AZ Auto Scaling group into one reliable endpoint?
Why should monitoring cover every architectural tier rather than just the compute layer?