Skip to main content

High Availability & Scalability

Let's establish the core terminology of High Availability and Scalability before we dive into the specific AWS services that help us achieve these goals.

Key Takeaways​

Vertical Scalability (Scale Up/Down).​

  • The Mechanic: You don't add more machines; you just make the existing machine bigger by swapping its instance type (e.g., migrating an EC2 app from a t3.micro to a m5.large).
  • The Bound: You can go from a tiny t2.nano (0.5 GB RAM) all the way up to a massive bare-metal instance (u-t12tb1.metal) with 12 TB of RAM. However, you will eventually hit a hard hardware limit where a bigger physical server simply doesn't exist.
  • Best For: Non-distributed systems that can't easily partition their state across multiple servers. The absolute classic example is a relational database (like standard RDS or ElastiCache clusters).

Horizontal Scalability (Scale Out/In).​

  • The Mechanic: You add or remove more instances of the same size to absorb traffic spikes.
  • The Terminology:
    • Scale Out: Adding more instances to handle an increasing workloads.
    • Scale In: Terminating excess instances when traffic drops to save cash.
  • Best For: Distributed architectures, modern web applications, and stateless microservices. It is infinitely scalable because you aren't capped by a single motherboard's physical constraints.

High Availability (HA)​

  • The Mechanic: Running your application infrastructure across at least two distinct data centers (AZs) inside an AWS region.
  • The Goal: Pure disaster resilience. High availability is engineered specifically to ensure your system can survive a full data center failure or a massive network outage in one zone without crashing your entire application.
  • Active vs. Passive HA:
    • Active HA: Multiple instances are handling live client traffic across different AZs simultaneously (e.g., an Auto Scaling Group behind an Application Load Balancer).
    • Passive HA: A secondary system sits idly in a separate AZ as a standby backup. It doesn't take active traffic unless the primary master server fails (e.g., an RDS Multi-AZ deployment).

Exam Tips​

  • The Database Limit Clue: If an exam scenario states that a monolithic application or a specialized stateful relational database is experiencing extreme processing lag during peak hours and cannot handle data replication across multiple active writing nodes, look for an answer that advises Vertical Scaling (upgrading the instance class/family).

  • The Resiliency Requirement: If a question says an application is highly scalable but must be engineered to withstand a "zonal failure or an "AZ outage with zero downtime", your answer must involve a Multi-AZ layout using an Auto Scaling Group (ASG) or an Elastic Load Balancer (ELB). Scaling a machine up to 12TB of RAM does absolutely nothing if that specific data center catches fire!