AWS SAA-C03 design resilient architectures syllabus

Design Resilient Architectures carries 26 per cent of the scored content across just two task statements, which makes it the densest domain per task on the exam.

The two tasks divide cleanly. One is about decoupling so that components can fail or scale independently. The other is about surviving the failure of an Availability Zone or a Region. The AWS SAA-C03 syllabus hub page covers the other three domains.

Pattern

This domain carries 26 per cent of the scored content. The current weightings are below, and they replace the 26, 24, 24 and 26 split that most study material still quotes.

Task statements

Task 2.1: Design scalable and loosely coupled architectures

• API creation and management with Amazon API Gateway and REST APIs

• Managed services and their use cases, including AWS Transfer Family, Amazon SQS and AWS Secrets Manager

• Caching strategies

• Microservice design principles, and stateless against stateful workloads

• Event driven architectures

• Horizontal and vertical scaling

• Edge accelerators and content delivery networks

• Migrating applications into containers, and container orchestration with Amazon ECS and Amazon EKS

• Load balancing concepts, and multi-tier architectures

• Queuing and messaging, including publish and subscribe patterns

• Serverless technologies and patterns with AWS Lambda and AWS Fargate

• Storage types and their characteristics: object, file and block

• When to use read replicas

• Workflow orchestration with AWS Step Functions

Task 2.2: Design highly available and fault tolerant architectures

• AWS global infrastructure: Availability Zones, Regions and Amazon Route 53

• Disaster recovery strategies: backup and restore, pilot light, warm standby and active-active failover, with RPO and RTO

• Distributed design patterns and failover strategies

• Immutable infrastructure

• Load balancing and proxy concepts, including Amazon RDS Proxy

• Service quotas and throttling

• Storage durability and replication

• Workload visibility with AWS X-Ray

• Designs that mitigate single points of failure

• Using AWS services to improve the reliability of legacy applications not built for the cloud

The four disaster recovery strategies are the most reliably examined item in this domain. Questions give an RPO and an RTO and ask which strategy fits, so knowing the order from backup and restore through pilot light and warm standby to active-active, and roughly what each costs, answers them.

Services most used in this domain

• Amazon SQS, Amazon SNS, Amazon EventBridge and Amazon MQ

• AWS Lambda, AWS Fargate and AWS Step Functions

• Amazon ECS and Amazon EKS

• Elastic Load Balancing and Amazon EC2 Auto Scaling

• Amazon Route 53 and Amazon CloudFront

• Amazon RDS with read replicas, Amazon RDS Proxy and Amazon Aurora

• AWS Backup, Amazon S3 with replication, and Amazon EFS

• AWS X-Ray and Amazon API Gateway

What is not in this domain

• No cost comparison. Cost sits in Domain 4 even when the architecture is the same

• No performance tuning. That belongs to Domain 3

• No infrastructure as code authoring. AWS CloudFormation appears as a service rather than as a syntax exercise

• No out-of-scope services such as AWS Fault Injection Simulator

How to spend the time

Learn the four disaster recovery strategies as an ordered ladder with their trade-offs. RPO and RTO questions are a staple of this domain and the ladder answers most of them in seconds.

Get clear on which services decouple what. Amazon SQS for queuing, Amazon SNS for publish and subscribe, Amazon EventBridge for event routing, and AWS Step Functions for orchestration. Scenario questions usually name a symptom and expect the right one of those four.

Multi-AZ and read replicas are frequently confused. Multi-AZ is availability, read replicas are read scaling, and a question that mentions failover is asking about the first.

Stateless design is the thread running through Task 2.1. If a scenario describes session data on the instance, the answer almost always involves moving it off. Browse the available AWS Solutions Architect practice papers.

Common mistakes

• Confusing Multi-AZ deployment, which is for availability, with read replicas, which are for read scaling

• Choosing Amazon SQS where the scenario needs fan-out to several consumers, which is Amazon SNS

• Treating fault tolerance and high availability as the same requirement

• Ignoring service quotas and throttling, which are named in the syllabus and appear in scaling scenarios

• Answering a resilience question on cost grounds, when cost is a separate domain

• Overlooking that this domain has only two task statements but a quarter of the marks

Resilience against performance

Frequently asked questions

How much of the exam is Design Resilient Architectures?

26 per cent of the scored content, across two task statements.

What are the four disaster recovery strategies?

Backup and restore, pilot light, warm standby and active-active failover, named in the syllabus alongside RPO and RTO.

What is the difference between Multi-AZ and a read replica?

Multi-AZ is for availability and failover. A read replica is for scaling read traffic. Questions mentioning failover are about the first.

Which services are used for decoupling?

Amazon SQS for queuing, Amazon SNS for publish and subscribe, Amazon EventBridge for event routing and AWS Step Functions for workflow orchestration.

Is container orchestration in this domain?

Yes. Amazon ECS and Amazon EKS are named under designing scalable and loosely coupled architectures.

Are service quotas examined?

Yes, named with throttling under the high availability task.

Is AWS X-Ray in scope?

Yes, named under workload visibility.

Does this domain cover cost?

No. Cost optimisation is Domain 4, even where the architecture under discussion is the same.

How many task statements does it have?

Two, the fewest marks per task of any domain in reverse: it carries the most weight per task statement.

Is stateless design examined?

Yes, named under microservice design principles as stateless against stateful workloads.