Skip to main content
This lesson summarizes Domain 3: Resilient Cloud Solutions. Focused on designing systems that remain available and recoverable during incidents, this domain tests your ability to balance availability, scalability, and disaster recovery while controlling cost and operational overhead. Domain 3 at a glance
  • Exam weight: 15% (≈10 questions)
  • Core focus areas: high availability, scalability, and disaster recovery
  • Guiding principle: keep systems running under failure while balancing cost and operations
A presentation slide titled "Domain 3 at a Glance" outlining exam weight (15% / 10 questions), three task statements about high availability, scalability and disaster recovery, and core competencies. It also features the guiding principle: "Keep it running, no matter what."
High availability: multi‑AZ vs multi‑region
  • Multi‑AZ (Availability Zone) architectures provide fault tolerance within a region. Typical techniques:
    • Synchronous data replication where supported (transparent to the application).
    • Automatic health monitoring and transparent failover.
    • Distribute compute and state across AZs to avoid single‑AZ dependency.
    • Examples: RDS Multi‑AZ, Aurora cluster endpoints, ElastiCache Redis replication groups with automatic failover, EFS (regional service spanning AZs).
  • Multi‑region strategies protect against region‑level outages. Typical approaches:
    • Asynchronous replication (for data where synchronous cross‑region is impractical).
    • Independent infrastructure stacks in each region (for true isolation).
    • Global traffic management using DNS or network-level global services for failover and routing.
Key considerations and services for availability and traffic distribution:
Exam tip: If a question mentions an AZ failure, think multi‑AZ. If it mentions a regional outage or disaster, you need a multi‑region / global solution.
A slide titled "Task 3.1 – High Availability Essentials" showing two columns: "Multi‑AZ Architecture" with items like synchronous data replication, automatic health monitoring, and transparent failover, and "Multi‑Region Strategy" with independent infrastructure stacks, cross‑region replication, and global traffic management. Below are key services listed (Route 53, ALB/NLB, Auto Scaling Groups) and an exam tip about AZ vs region failure.
Scalability patterns and services
  • EC2 Auto Scaling policies: scheduled, step, target tracking, and simple scaling — choose based on predictability and metrics.
  • ECS / EKS: autoscaling at task/pod level plus cluster autoscalers (for node capacity) such as Karpenter.
  • Lambda: scales automatically with requests but watch for per‑region concurrency limits and the 15‑minute maximum execution time.
  • DynamoDB: on‑demand scaling and provisioned capacity; Global Tables for cross‑region replication and low‑latency reads.
  • Aurora/RDS read replicas: used for read scaling and optional cross‑region replication; read replicas are not automatic failover unless explicitly described as part of a HA feature (e.g., Aurora Global Database has its own behaviors).
Design patterns to favor:
  • Loose coupling and asynchronous communication for resilience and scalability: SQS for buffering, SNS for fan‑out, EventBridge for routing, Step Functions for orchestration.
A presentation slide titled "Loosely Coupled Architectures" showing icons and short descriptions for four AWS services: Amazon SQS, Amazon SNS, Amazon EventBridge, and AWS Step Functions. Each service has a brief note about its role (decoupling/queues, fan-out/multi-protocol, event routing/integration, and workflow orchestration).
Loosely coupled, event‑driven building blocks
  • SQS — decoupling and buffering
    • Standard queues: high throughput, at‑least‑once delivery, best‑effort ordering.
    • FIFO queues: strictly ordered, exactly‑once processing semantics (limited throughput).
  • SNS — pub/sub fan‑out to multiple subscribers and protocols (HTTP/S, Lambda, SQS, email, SMS).
  • EventBridge — rule‑based event routing, third‑party SaaS integrations, and schema registry.
  • Step Functions — orchestrated workflows and long‑running stateful flows; integrates with Lambda, ECS, and AWS SDK integrations.
Container and serverless resilience
  • ECS and EKS: support spreading tasks/pods across AZs; use health checks and lifecycle hooks for safe deployment and termination.
  • Fargate: serverless compute option for ECS/EKS — removes node management while enabling AZ distribution via the underlying service.
  • Kubernetes (EKS) options: use Pod Disruption Budgets (PDBs) to control voluntary disruptions and cluster autoscalers (Karpenter) to scale node capacity automatically.
  • Design for AZ‑aware task placement to avoid single‑AZ failure modes.
A slide titled "Container and Serverless Resilience" showing container strategies (Amazon ECS and EKS) and serverless approaches (AWS Fargate) with short notes on task placement, autoscaling, pod disruption budgets, node groups, and auto-distribution across availability zones. The slide includes AWS service icons and a KodeKloud copyright.
Disaster recovery fundamentals: RPO and RTO
  • Recovery Point Objective (RPO): maximum acceptable data loss — how far back your data can be recovered.
  • Recovery Time Objective (RTO): maximum acceptable downtime — how long until services are restored.
  • Tighter RPO/RTO typically increases architecture complexity and cost. Let RPO/RTO drive your DR pattern selection.
Examples of DR patterns (tradeoffs between cost and recovery time): Choose the DR pattern that meets your RTO/RPO requirements and budget constraints.
A slide titled "Task 3.3 – Disaster Recovery Fundamentals" showing a timeline with a flame icon marking a disaster and labeled points for Recovery Point Objective (RPO) on the left and Recovery Time Objective (RTO) on the right. It illustrates data loss (how far back) and downtime (how long to recover) between the last usable data point and system recovery.
A slide titled "DR Strategy Decision Framework" showing a comparison table of four disaster-recovery approaches—Backup & Restore, Pilot light, Warm Standby, and Active-Active—against RTO, RPO, and cost. The table notes RTO/RPO ranging from hours to near-zero and costs from low ($) to highest ($$$$).
Backup and recovery services
  • AWS Backup: centralized backup management, policy‑driven backups, and cross‑region copying for many AWS services.
  • Amazon S3: versioning, lifecycle policies, cross‑region replication (CRR), and object lock (WORM) for immutability and retention controls.
  • Amazon RDS: automated backups and point‑in‑time recovery — retention configurable (up to 35 days).
  • EBS: incremental snapshots for block storage recovery; snapshots can be copied across regions.
Best practices:
  • Implement automated, policy‑driven backups and periodically test restores.
  • Use cross‑region replication for critical data when RPO requirements demand geographic separation.
A slide titled "AWS Backup and Recovery Services" with four colored panels labeled AWS Backup, S3 Protection, RDS backups, and EBS Snapshots, each with a brief description. It summarizes centralized backup management, S3 versioning/cross-region replication, automated RDS point-in-time recovery, and incremental EBS snapshots.
DNS and global traffic management
  • Route 53 routing policies: Failover, Latency‑Based, Geolocation, Weighted, Simple, Multivalue Answer, Geoproximity. Use health checks and routing policies to implement cross‑region failover and traffic steering.
  • Global Accelerator: provides static anycast IPs and optimizes client‑to‑edge‑to‑regional endpoint routing for lower latency and fast failover.
  • Use Route 53 for DNS‑level traffic control and Global Accelerator when you need static IPs, improved TCP/UDP performance, or global network optimization.
Useful references:
A slide titled "Route 53 for Resilience" showing a purple Route 53 icon connected by a winding path to blue icons labeled with different DNS routing types (Failover, Latency-Based, Geolocation, Weighted, Simple, Multivalue Answer, Geoproximity and IP-Based Routing).
Load balancers and connection behavior
  • ALB, NLB, and GWLB distribute traffic across AZs; ensure cross‑zone load balancing and connection‑draining settings (deregistration delay) match your availability and deployment needs.
  • Session affinity (sticky sessions) can be required for stateful applications — design to avoid single‑AZ dependencies to preserve fault tolerance.
  • Always confirm default load‑balancer behaviors in the console or API and override defaults when exam or real‑world scenarios require specific settings.
Exam quick hits and practical reminders
  • Domain 3: ~15% of the exam questions.
  • Typical RDS Multi‑AZ failover time: ~60–120 seconds (varies by workload and configuration).
  • RDS automated backup retention: configurable up to 35 days.
  • AWS favors managed services and automated, operationally efficient solutions when available.
  • When unsure on the exam, prefer solutions that meet RTO/RPO while minimizing operational overhead.
A slide titled "Domain 3 Exam Quick Hits" showing three boxes: 15% exam weight, 60–120 seconds (RDS Multi‑AZ failover), and 35 days max (RDS automated backup retention). A footer note gives a final exam tip about choosing highest availability with lowest operational overhead.
Final notes
  • Multi‑AZ protects against AZ failures within a region; multi‑region protects against region‑level failures.
  • RTO measures acceptable downtime; RPO measures acceptable data loss — both should drive your architecture and DR choices.
  • Favor loose coupling (SQS, SNS, EventBridge) and managed services to improve resilience and reduce operational burden.
Remember to test failover and restore procedures regularly — backups and replicas are only valuable if restores succeed within your RTO/RPO targets.
Thanks for reading this lesson.

Watch Video