ExamFinch.com My Study

Study guide

5.4 Architecture Best Practices and Design Principles

Practice this exam

AWS Certified Cloud Practitioner CLF-C02

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the AWS Cloud Practitioner (CLF-C02) Exam Study Strategies and Exam Tips

2 Domain 1: Cloud Concepts (24%)

1.1 What Is Cloud Computing? 1.2 Cloud Deployment Models 1.3 AWS Well-Architected Framework 1.4 Cloud Migration Strategies 1.5 Cloud Economics

3 Domain 2: Security and Compliance (30%)

2.1 The AWS Shared Responsibility Model 2.2 AWS Identity and Access Management (IAM) 2.3 AWS Security Services 2.4 Compliance and Governance 2.5 Network Security

4 Domain 3: Cloud Technology and Services (34%)

3.1 AWS Compute Services 3.2 AWS Storage Services 3.3 AWS Database Services 3.4 AWS Networking and Content Delivery 3.5 Management and Governance Services 3.6 AI/ML and Analytics Services 3.7 Application Integration and Other Services

5 Domain 4: Billing, Pricing, and Support (12%)

4.1 AWS Pricing Models 4.2 Billing and Cost Management Tools 4.3 AWS Support Plans 4.4 Additional Billing Concepts and Services

6 AWS Services Deep Dive

5.1 Compute Services Deep Dive 5.2 Storage and Database Deep Dive 5.3 Security Services Deep Dive 5.4 Architecture Best Practices and Design Principles 5.5 Practice Exam — Mixed Domain Questions

5.4 Architecture Best Practices and Design Principles

Key Takeaways Explain This Topic AI

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.

Last updated: June 2026

  • 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.