How do you design a highly available architecture on AWS?

Start with the requirement, not the architecture. RTO and RPO determine how much you should spend, and "as available as possible" is not a requirement.

The layers, in increasing cost and protection:

• Eliminate single points of failure within an availability zone. Multiple instances behind an Application Load Balancer in an Auto Scaling group, with health checks replacing unhealthy instances automatically.
• Spread across availability zones. This is the fundamental AWS availability pattern and usually the best value: AZs are physically separate with independent power and networking, and inter-AZ latency is low. Use Multi-AZ RDS, subnets in at least three AZs, and Auto Scaling configured to balance across them.
• Make the application stateless. Sessions in ElastiCache or DynamoDB, uploads in S3 — so any instance can serve any request and instances are disposable.
• Multi-region only if the requirement genuinely demands surviving a region failure. It roughly doubles cost and introduces hard data replication and consistency problems. Route 53 health checks or Global Accelerator handle failover; the database is the difficult part.

Design for failure throughout: retries with exponential backoff and jitter, circuit breakers, timeouts on every call, graceful degradation, and queues to absorb spikes and decouple components.

Note: Say that an untested failover is not a failover. Regular game days are what turn a diagram into a capability.