Auto Scaling & stateless design

Elastic, self-healing, horizontally-scaled tiers.

Elasticity — matching capacity to demand automatically — is what makes cloud architecture cost-effective and resilient. Auto Scaling and load balancing together deliver capacity that grows, shrinks, and self-heals.

Auto Scaling groups

An EC2 Auto Scaling group maintains a desired number of instances, adds or removes them based on demand (target-tracking on CPU or request count, scheduled scaling for known patterns), and replaces unhealthy instances automatically — giving you both elasticity and self-healing. Spanning the group across multiple AZs and fronting it with a load balancer is the canonical resilient web tier: traffic spreads across healthy instances in several AZs, capacity follows load, and failed instances are replaced without intervention. Scaling works best when the tier is stateless, so any instance can serve any request and instances can be added or terminated freely.

ALB (across AZ-a/b/c)
 └─ Auto Scaling group  min=2  desired=4  max=12
      ├─ target tracking: keep avg CPU ~50%  → scale out/in automatically
      ├─ health checks: replace unhealthy instances
      └─ multi-AZ: capacity spread for availability
# Keep the app STATELESS (session state in DynamoDB/ElastiCache) so any
# instance serves any request and scaling/replacement is seamless.

Stateless design and scaling databases

Horizontal scaling (adding instances) is the cloud-native approach and depends on statelessness — keep session and shared state in a shared store (DynamoDB, ElastiCache) rather than on individual instances, so there are no sticky dependencies. Vertical scaling (bigger instances) has limits and downtime, so it is a last resort. Databases scale differently: reads scale out with read replicas and caching (ElastiCache/DAX), while writes typically scale vertically or, for NoSQL, through DynamoDB’s automatic throughput scaling and good partition-key design. Designing every tier to scale horizontally, with state externalized, is what lets an architecture handle growth and spikes gracefully while only paying for the capacity in use.