5.4 Architecture Best Practices and Design Principles
Key Takeaways
- Design for failure: assume everything will fail and architect for automatic recovery using Multi-AZ, Auto Scaling, and health checks.
- Loose coupling means components interact through well-defined interfaces (APIs, queues) so failures do not cascade.
- Horizontal scaling (adding more instances) is preferred over vertical scaling (getting a bigger instance) for reliability.
- Serverless architectures remove the operational burden of managing servers and scale automatically with demand.
- The AWS Well-Architected Tool helps you review workloads against best practices from the six pillars.
Design for Failure
"Everything fails, all the time." — Werner Vogels, CTO of Amazon
This mindset drives AWS architecture. Build systems that expect failure and recover automatically rather than assuming components stay healthy.
Strategies for Fault Tolerance
| Strategy | Implementation |
|---|---|
| Multi-AZ Deployment | Spread resources across AZs for resilience |
| Auto Scaling | Automatically replace failed instances |
| Health Checks | ELB and Route 53 route away from unhealthy targets |
| Backup and Recovery | Automated backups, snapshots, cross-Region replication |
| Decoupled Architecture | SQS/SNS/EventBridge stop failures cascading |
Loose Coupling
Loose coupling means components interact through well-defined interfaces (APIs, queues, event buses) rather than direct dependencies, so one failure stays isolated.
| Tightly Coupled | Loosely Coupled |
|---|---|
| Components call each other directly | Components talk via queues/APIs |
| One failure can take down all | Failures are isolated |
| Must scale everything together | Components scale independently |
| Changes need coordination | Components update independently |
Services for loose coupling: SQS (queues), SNS (pub/sub), EventBridge (events), Step Functions (workflows), API Gateway (API interfaces).
Elasticity and Scalability
Horizontal vs. Vertical Scaling
| Horizontal (Scale Out/In) | Vertical (Scale Up/Down) | |
|---|---|---|
| Method | Add/remove instances | Resize the instance |
| Limit | Virtually unlimited | Capped by largest instance |
| Downtime | None (behind a load balancer) | Often requires restart |
| Availability | Better (no single point of failure) | Single point of failure |
On the Exam: AWS favors horizontal scaling — it removes single points of failure and scales nearly without limit. Scalability/availability questions usually point to horizontal scaling plus load balancing.
Serverless Architecture
Serverless means no servers to manage — AWS handles provisioning, scaling, patching, and availability. The canonical serverless stack:
| Component | Service |
|---|---|
| API endpoint | API Gateway |
| Business logic | Lambda |
| Data storage | DynamoDB |
| File storage | S3 |
| Authentication | Cognito |
| Notifications | SNS |
| Workflow | Step Functions |
Benefits: no server management, automatic scaling, pay-per-use pricing, built-in high availability, and reduced operational overhead.
High Availability and Disaster Recovery
Multi-AZ vs. Multi-Region
Deploy across multiple AZs to survive a data-center/AZ failure (ELB across AZs, EC2 in several AZs, RDS Multi-AZ). For the highest resilience, go multi-Region with Route 53 failover routing, S3 Cross-Region Replication, DynamoDB Global Tables, and Aurora Global Database.
Disaster Recovery Strategies
| Strategy | RTO/RPO | Cost | Description |
|---|---|---|---|
| Backup & Restore | Hours | Lowest | Back up data, restore on disaster |
| Pilot Light | Tens of minutes | Low | Core infra idle, scale up when needed |
| Warm Standby | Minutes | Higher | Scaled-down copy always running |
| Multi-Site Active/Active | Near zero | Highest | Full production in multiple Regions |
On the Exam: Know the four DR strategies and their trade-offs. Backup & Restore is cheapest but slowest; Multi-Site Active/Active is fastest but most expensive. The "best" answer depends on the stated recovery-time and budget constraints.
Mapping Exam Phrases to Patterns
| Question Phrase | Think About |
|---|---|
| "Most highly available" | Multi-AZ, Auto Scaling, ELB |
| "Most cost-effective" | Right-sizing, Savings Plans, Spot, serverless |
| "Most secure" | Least privilege, encryption, private subnets |
| "Decouple components" | SQS, SNS, EventBridge |
| "Reduce operational overhead" | Managed services, serverless |
| "Global low latency" | CloudFront, Route 53 latency routing, Global Accelerator |
| "Survive a Region failure" | Multi-Region + Route 53 failover |
These design principles trace directly back to the six Well-Architected pillars, and the AWS Well-Architected Tool lets you formally review a workload against them. Recognizing which pillar a scenario stresses — reliability, security, cost, performance, operations, or sustainability — usually reveals the intended answer.
Putting the Principles Together
A well-architected workload rarely relies on a single principle; it layers several. Consider a typical resilient web application: a load balancer spreads traffic across multiple Availability Zones, an Auto Scaling group adds and replaces instances behind it, an RDS Multi-AZ database fails over automatically, and CloudFront caches static assets at the edge for global low latency. A queue (SQS) decouples a background-processing tier so a spike or a worker crash never blocks the front end.
Each piece advances a different pillar — reliability, performance efficiency, and cost — while together they eliminate single points of failure.
When the exam asks you to improve such a design, look for the weakest link in the scenario. A single-AZ deployment fails the availability test and wants Multi-AZ. A directly coupled component that overloads under spikes wants a queue. An oversized always-on instance fails cost optimization and wants right-sizing, a Savings Plan, or serverless. Mounting critical data only on instance store fails durability and wants EBS or S3.
Training yourself to identify the one constraint a question is really testing — and the smallest change that fixes it — is the core skill behind the Cloud Technology and architecture questions, and it keeps you from selecting an over-engineered, more expensive option than the scenario requires.
Which of the following is an example of loose coupling in cloud architecture?
Why does AWS generally recommend horizontal scaling over vertical scaling?
Which disaster recovery strategy provides the LOWEST cost but the LONGEST recovery time?
A company wants to build a REST API with no server management, automatic scaling, and pay-per-request pricing. Which combination of services should they use?
Which TWO strategies help achieve high availability for a web application on AWS? (Select TWO)
Select all that apply