Evolution path
A single server concentrates entry, application, session, and database state in one failure domain. A resilient architecture separates them:
- Route 53 provides DNS.
- CloudFront caches static and cacheable content and can pair with WAF at the edge.
- An ALB distributes HTTP and HTTPS traffic.
- An Auto Scaling group maintains stateless application nodes across AZs.
- Sessions move to ElastiCache or DynamoDB.
- Static files and uploads move to S3.
- RDS or Aurora uses Multi-AZ for availability and read replicas when read scale is needed.
- SQS, EventBridge, or Step Functions decouples background work and long-running workflows.
Why stateless matters
If sessions, uploads, or job state live only on one host, instance replacement and horizontal scaling break user experience. Stateless does not mean “no state”; it means placing state in reliable managed stores that every node can access.
Availability is not backup
Multi-AZ, health checks, and replacement protect availability. Snapshots, PITR, cross-Region copies, and recovery exercises protect recoverability. Both matter, but they solve different problems.
Common mistakes
- An ALB alone is not HA without multiple AZs and healthy backends.
- Sticky sessions can be a bridge, not a replacement for stateless design.
- Read replicas scale reads; they do not replace Multi-AZ failover.
- NAT gateways should be designed per AZ to avoid cross-AZ dependencies.
- Serverless architectures still require quota, retry, idempotency, observability, and cost design.
Remember
Remove single points of failure, externalize state, then design scaling, fault domains, security, observability, and recovery for every layer.