Architecture and Operations
What to know
Well-architected design balances reliability, security, performance, cost, and operational excellence. Reliability: deploy across multiple zones in a region, use SLB health checks, auto scaling, and design for graceful failure. Decoupling: use message queues and asynchronous processing so a slow component does not cascade failure. Statelessness: keep session state external (Redis, database) so instances can be replaced freely. Operations: infrastructure as code, monitored metrics and alarms, log aggregation, backup and restore testing, and defined RTO/RPO targets. Cost: right-size instances, use reserved or preemptible capacity for suitable workloads, lifecycle-tier cold data in OSS, and release idle resources.
Traps in questions
- Multi-zone within a region protects against zone failure; only multi-region protects against regional disaster. Questions often offer multi-zone as DR - it is not.
- Auto scaling needs a load balancer and health checks to be effective; scaling alone does not remove unhealthy instances unless configured to.
- Backups that are never restored are unverified. The correct answer includes periodic restore drills.
- Preemptible (spot-like) instances can be reclaimed - wrong for stateful, uninterruptible workloads.
- RTO is time to recover; RPO is acceptable data loss. Do not swap them.
Worked example
A ticketing system spikes during sales and must survive a zone outage. Rule of thumb: stateless web tier behind SLB across at least two zones, auto scaling on CPU and queue depth, session state in Redis, asynchronous order processing via message queue, and database with a standby. This addresses elasticity, zone failure, and decoupling in one design.
Rule of thumb
Design each tier to fail independently; verify recovery with drills, not assumptions.