AIAI Agent Dev Labaiagentdev-lab.com
Sign in to save progressSign in
Menu

SAA-C03 · LESSON 2

Design Resilient Architectures26% · 2 topics

Learn to design scalable, loosely coupled architectures and highly available, fault-tolerant architectures.

2.1Design scalable and loosely coupled architectures

2.1 Design scalable and loosely coupled architectures.

Concept

Loose coupling places SQS (queues), SNS (notifications) or EventBridge (events) between components so that delays or failures in one do not spread to another. Make processing stateless, keep sessions in ElastiCache or DynamoDB, and scale horizontally with Auto Scaling. Serverless (Lambda, API Gateway, Step Functions) and containers (ECS, EKS, Fargate) are also options.

How it works / steps

  1. Turn synchronous calls into asynchronous processing with SQS where appropriate
  2. To deliver one event to multiple processes, go from SNS to multiple SQS queues (fan-out)
  3. Make the app stateless and keep sessions externally
  4. Auto Scale on metrics such as SQS queue length
  5. Control multi-step processing with Step Functions and define retries on failure

Workplace example

An order is published to SNS and fanned out to inventory, billing and notification SQS queues so each process scales independently. Even if billing stops, orders remain in the queue.

Common confusions and exam tips

Mini quiz

Q1. You want to scale a web app on EC2 horizontally with Auto Scaling. Login state is stored in server memory, so users are logged out when the number of servers changes. What is the most appropriate fix?

  1. Store session data in ElastiCache or DynamoDB and make the servers stateless
  2. Ask users to change browser settings so login state is not stored
  3. Disable ALB health checks so Auto Scaling does not replace servers
  4. Stop using Auto Scaling and run on a single largest instance
Show answer and explanation

Answer: A Store session data in ElastiCache or DynamoDB and make the servers stateless

Keeping sessions in an external data store lets any server handle the same session, so you can freely add and remove servers. Sticky sessions are only a temporary workaround.

Q2. You want to scale the number of tasks of a containerized order app on ECS according to the number of messages in an SQS queue. Which is the most appropriate approach?

  1. Use target tracking on CPU utilization to scale ECS tasks
  2. Use an ECS capacity provider to scale only the EC2 instance count
  3. Configure ECS service Auto Scaling based on the queue's message count
  4. Use an EventBridge schedule to add tasks only on weekday daytime
Show answer and explanation

Answer: C Configure ECS service Auto Scaling based on the queue's message count

ECS service Auto Scaling can adjust the task count based on CloudWatch metrics (such as queue depth). [Other options] CPU may not reflect queue backlog. Schedules do not follow actual load. Capacity providers adjust underlying instances, not the task count.

Reference links

2.2Design highly available and/or fault-tolerant architectures

2.2 Design highly available and/or fault-tolerant architectures.

Concept

The basis of high availability is spreading across multiple AZs (ALB + Auto Scaling group, RDS Multi-AZ). For Region-scale disasters (DR), there are four strategies by cost and RTO/RPO: backup and restore → pilot light → warm standby → multi-site (active/active). Switch over with Route 53 health checks and failover routing.

How it works / steps

  1. Decide RTO (time to recover) and RPO (how much data loss is acceptable)
  2. Build web and app tiers with a multi-AZ Auto Scaling group and an ALB
  3. Make the DB RDS Multi-AZ (synchronous replication, automatic failover)
  4. Choose a DR strategy by RTO, RPO and cost, and replicate to another Region
  5. Switch to the DR Region with Route 53 failover and drill regularly

Workplace example

For a requirement of RTO 1 hour and RPO 15 minutes, adopt warm standby with a scaled-down environment always running in another Region, plus an Aurora global database.

Common confusions and exam tips

Mini quiz

Q1. To increase a web app's availability, you want to eliminate single points of failure. Which architecture is most appropriate?

  1. Consolidate all processing on one high-performance instance
  2. Place the ALB and Auto Scaling group across multiple AZs and make the database Multi-AZ
  3. Put two EC2 instances in the same AZ and keep one stopped
  4. Put the database on one EC2 instance's instance store and manually copy it to another server after work every day
Show answer and explanation

Answer: B Place the ALB and Auto Scaling group across multiple AZs and make the database Multi-AZ

Spread across multiple AZs and use a load balancer, automatic scaling and a Multi-AZ database so the service continues even if any one location fails.

Q2. Which statement correctly describes RPO and RTO?

  1. RPO is the acceptable window of data loss; RTO is the acceptable time from outage to recovery
  2. RPO is the time to recover; RTO is the amount of data that can be stored
  3. RPO is the number of Regions used; RTO is the number of Availability Zones used
  4. RPO and RTO mean the same thing; both represent a cost ceiling
Show answer and explanation

Answer: A RPO is the acceptable window of data loss; RTO is the acceptable time from outage to recovery

RPO (recovery point objective) is how far back you can afford to lose data; RTO (recovery time objective) is how quickly you must recover. Use them to choose a DR strategy.

Reference links

Lessons are written by this site based on public information and do not guarantee exam content. Product specifications change, so check the latest information at the reference links.

Notes (unofficial, original questions, no pass guarantee)