Scalability and High Availability

Scaling and availability are separate goals

Vertical scaling (scale up) changes the size of one instance; it fits software that is difficult to distribute but has hardware limits and often requires interruption. Horizontal scaling (scale out) adds or removes instances and requires stateless workloads or externally shared state.

flowchart LR
  U["Users"] --> LB["Load balancer<br/>spans AZ 1a, 1b"]
  LB --> A["Instance<br/>AZ 1a"]
  LB --> B["Instance<br/>AZ 1b"]
  A --> ST["Shared state<br/>RDS, ElastiCache, S3"]
  B --> ST
  ASG["Auto Scaling group<br/>min 2, max 6"] -.-> A
  ASG -.-> B
  %% step U: Users reach one stable DNS name, not individual servers.
  %% step LB: The load balancer has nodes in several AZs and sends traffic only to healthy targets.
  %% step A: Identical instances run in different AZs.
  %% step B: If AZ 1a fails, the instances in AZ 1b keep serving.
  %% step ST: Session data and files live outside the instances, so any instance can serve any request.
  %% step ASG: Auto Scaling replaces failed instances and adds more when load grows.

Three words, three meanings

Term	Question it answers	Typical AWS building block
Scalability	Can the system handle more load if we add resources?	Bigger instance types, more instances
Elasticity	Does capacity follow demand automatically, up and down?	Auto Scaling policies
High availability (HA)	Does it keep working when a component or AZ fails?	Multi-AZ load balancer, ASG across AZs, Multi-AZ databases

High Availability reduces single points of failure. Two instances in one AZ still share a fault domain; an HA EC2 design commonly uses a multi-AZ Load Balancer and an ASG spanning subnets and AZs. Elasticity adjusts capacity to demand. Scaling alone does not create HA: many instances can still share one AZ or a failed dependency such as a single database.

Designing for scale-out

Horizontal scaling only works if instances are interchangeable:

Keep sessions out of instance memory: use ElastiCache, DynamoDB or signed cookies. Load balancer stickiness is a workaround, not a design.
Keep uploads and shared files in S3 or EFS, not on the local disk.
Bake configuration into the AMI or fetch it at boot from Parameter Store, so a new instance is ready without manual steps.
Make instances disposable: if one misbehaves, terminate it and let the ASG replace it.

Measuring availability

Availability is usually expressed in "nines": 99.9% allows about 8.8 hours of downtime a year, 99.99% about 53 minutes. Each extra nine needs removing another single point of failure — a second AZ, a standby database, a second Region. Ask what the business needs before building for more nines than it will pay for.

Disaster recovery

HA handles the loss of an instance or AZ. A whole-Region outage needs disaster recovery (DR): backups and infrastructure in another Region, chosen by RTO (how quickly you must recover) and RPO (how much data you may lose). Strategies range from backup-and-restore (cheapest, slowest) through pilot light and warm standby to active-active (fastest, most expensive).

Command	Purpose
`aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names web-asg`	View capacity and AZs
`aws elbv2 describe-load-balancers --names web-alb`	View a load balancer and its AZs
`aws ec2 describe-instances --filters Name=tag:aws:autoscaling:groupName,Values=web-asg --query "Reservations[].Instances[].Placement.AvailabilityZone"`	Check how instances spread across AZs

Traps: calling ten instances in one AZ "highly available"; scaling out an app that stores sessions in memory; confusing HA with backups.