Amazon SAP-C02: Resilience, Disaster Recovery & High Availability — Study Guide
Part of the AWS Solutions Architect Professional SAP-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
RTO and RPO planning: quantifying tolerance and mapping architecture
RTO (Recovery Time Objective) and RPO (Recovery Point Objective) drive every resilience choice from compute sizing to replication topology. Begin by classifying workloads by business impact and cost of downtime, then translate those priorities into measurable objectives: millisecond RPOs drive synchronous replication or purpose-built global databases, while minute-to-hour RPOs allow asynchronous replication, snapshot schedules, or batched log shipping. Use AWS services that align to objectives: Amazon Aurora Multi‑AZ and Aurora Global Database for low RTO/RPO at scale, RDS Multi‑AZ for synchronous single‑Region high availability, cross‑Region read replicas for recovery and reporting, and AWS Elastic Disaster Recovery (DRS) for near-real-time replication of on‑prem servers with minimal application changes. A common trap is designing only to meet average load rather than worst-case recovery operations; another is assuming snapshots alone meet RPO for transactional systems because snapshots can be minutes apart and may lack application consistency. Decision trade-offs are straightforward: synchronous replication increases cost and write latency but lowers RPO; asynchronous replication reduces latency and cost but increases potential data loss. Test the plan with chaos testing, scheduled failovers, and restore drills to validate actual RTO/RPO and identify hidden dependencies like external auth, DNS, or IP whitelists.
Multi‑AZ and Multi‑Region architectures and failover strategies
Multi‑AZ architectures protect against AZ failures by placing redundant compute, networking, and storage across Availability Zones; Multi‑Region extends tolerance to region-level failures, natural disasters, or large network partitions. Choose an architecture pattern—pilot light, warm standby, active‑passive, or active‑active—based on cost and recovery needs. Pilot light uses minimal resources in a secondary Region to minimize cost and scales up during failover; warm standby keeps scaled‑down services running for faster recovery; active‑active serves traffic in multiple Regions for lowest RTO but demands strong data replication and conflict resolution. Use Route 53 with health checks and failover routing, Amazon CloudFront or Global Accelerator for global traffic management, and data services like DynamoDB Global Tables or Aurora Global Database for cross‑Region replication. Common pitfalls include relying on DNS TTLs that are too long, not validating stateful service failover (session stores, caches), and neglecting cross‑Region data transfer costs and compliance constraints. Trade off complexity and cost of multi‑Region deployment against acceptable downtime and data loss; when in doubt, instrument and model failover times to inform the business case.
Application resilience patterns: statelessness, decoupling, and state management
Design for failure by minimizing state pinned to individual compute nodes and by decoupling components so partial failures don’t cascade. Stateless application nodes behind an Application Load Balancer or Network Load Balancer enable horizontal scale and rapid replacement. For session state, prefer external stores like Amazon DynamoDB or Amazon ElastiCache rather than sticky sessions; for file shares, use Amazon S3, Amazon EFS, or FSx depending on protocol and performance needs. Asynchronous patterns using Amazon SQS, SNS, or Kinesis buffer spikes, enable retries and smooth backpressure, and reduce synchronous dependencies during failover. Implement circuit breakers, bulkheads, and exponential backoff in clients to isolate failing subsystems. A frequent architect trap is underestimating cold‑start or scale‑up times—Lambda concurrency limits, Auto Scaling cooldowns, and warm‑up strategies affect RTO. Another is treating caching as durability; caches must be rebuildable. Cost versus resilience choices manifest in buffer sizing and replication: higher resilience often requires more reserved capacity or cross‑Region replication, increasing cost; choose the minimum viable redundancy that satisfies RTO/RPO while ensuring observability and automation to detect and remediate failures.
Backups, replication, governance, and operational readiness
Backups are insurance; the crucial parts are consistency, security, retention, and recoverability. Use AWS Backup for centralized backup policies across EBS, RDS, DynamoDB, EFS, and FSx and enforce cross‑account, cross‑Region backup copies for geographic resilience. For object data, enable S3 versioning with Lifecycle rules and S3 Replication (CRR) for cross‑Region durability. Ensure application‑consistent snapshots for databases and Windows file systems by leveraging database native backups, RDS automated snapshots, or AWS DRS with VSS support. Cross‑account replication and IAM least‑privilege are essential to prevent accidental deletions. Regular restore exercises uncover issues with missing IAM roles, networking (VPC CIDR overlaps), or external integrations. Automate runbooks with Systems Manager Automation and codify failover procedures in CloudFormation or Terraform to reduce manual error. Common traps include relying solely on point‑in‑time snapshots without exportability, not encrypting backups with customer‑managed keys, and failing to monitor backup job success. Balance retention and storage costs against regulatory requirements; tier older backups to S3 Glacier for cost control while keeping recent backups quickly accessible for fast restores.
Practical Problem: Use-Case Scenario
Scenario: Meridian Events Inc., a global live-events enterprise, runs a ticketing application in a single AWS Region using EC2 Auto Scaling groups behind an ALB, with a 3-node PostgreSQL cluster on EC2 in one AZ and nightly EBS snapshots. The organization needs to reduce RTO to under 10 minutes and RPO to under 5 minutes while minimizing operational overhead and cost.
Challenge: Achieve near-continuous availability and low data loss for the database across AZs/Regions with predictable failover and minimal application changes.
Recommended Approach:
- Configure Amazon RDS for PostgreSQL with Multi‑AZ deployment or migrate to Amazon Aurora PostgreSQL with Multi‑AZ and enable automated continuous backups and fast snapshot exports; enable automated backups with an appropriate retention window.
- Add cross‑Region replication using Aurora Global Database (or RDS logical/physical replication to a read replica in a secondary Region) to meet geographic RPO goals, and configure Route 53 latency-based routing with health checks to enable controlled Region failover.
- Replace single‑AZ EC2 PostgreSQL with managed service to eliminate host maintenance, and refactor application connection logic to use cluster endpoints or the RDS Proxy for connection pooling and faster failover handling.
- Implement continuous replication verification and runbook automation: scheduled failover drills using Systems Manager Automation and CloudFormation templates for rapid resource recreation; instrument metrics and run alerts via CloudWatch and SNS.
Rationale: Using managed, Multi‑AZ database services and cross‑Region replication reduces operational complexity and meets aggressive RTO/RPO targets; automation and periodic drills ensure the plan works in practice while RDS/Aurora minimize manual failover steps and failover time.
← Migration · All domains · Cost Optimization →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →