Amazon SOA-C02: High Availability, Fault Tolerance, and Disaster Recovery — Study Guide

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Part of the AWS SysOps Administrator Associate SOA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

This domain covers designing systems that remain available and recoverable when components, services, or whole regions fail. It spans backup and snapshot strategies, replication and failover patterns, and operational testing needed to meet business RTO (Recovery Time Objective) and RPO (Recovery Point Objective) targets. Operational importance is high: outages and data loss directly impact SLAs, revenue, and compliance. Effective designs balance cost, complexity, and the acceptable risk of data loss and downtime.

Backup strategies, snapshots, and retention

Backups must be automated, consistent with application state, and retained according to policy. Use AWS Backup to centralize plans, retention, and lifecycle rules (create backup plan with vault, assign resource id ARNs or tags). For EBS volumes use Data Lifecycle Manager (DLM) to schedule snapshots (console or aws dlm create-lifecycle-policy); CLI snapshot creation example: aws ec2 create-snapshot –volume-id vol-0123456789abcdef0 –description “pre-upgrade”. For RDS use automated snapshots or manual DB snapshots (aws rds create-db-snapshot –db-instance-identifier mydb –db-snapshot-identifier mydb-snap-YYYYMMDD). Enable RDS automated backups for point-in-time recovery; enable enhanced monitoring and snapshot retention to meet retention SLAs.

Retention, immutability, and cross-region copies are critical decisions:

Short RPO/RTO needs frequent snapshots and low retention deletion windows; this increases cost.
For regulatory immutability, use AWS Backup Vault Lock or S3 Object Lock for legal hold.
For cross-region durability, copy snapshots (aws ec2 copy-snapshot –source-region us-east-1 –source-snapshot-id snap-abc –destination-region us-west-2) and enable S3 versioning before cross-region replication.

Always capture application-consistent state: for EC2, use AWS Systems Manager Run Command or scripts to flush/lock filesystems before creating snapshots; for databases prefer engine-native snapshots (RDS/Aurora) or logical backups (mysqldump, pg_dump) for point-in-time validation.

Cross-region replication and disaster recovery patterns

Cross-region strategies reduce blast radius from a regional failure. S3 Cross-Region Replication (CRR) requires versioning, an IAM replication role, and a replication configuration (console or aws s3api put-bucket-replication –bucket src –replication-configuration file://replication.json). RDS supports cross-region read replicas (aws rds create-db-instance-read-replica) and Aurora Global Database for low-lag cross-region read/write architectures with controlled failover. DynamoDB Global Tables replicate data asynchronously across regions and are suited for multi-region reads with eventual consistency considerations.

Choose a DR pattern based on RTO/RPO and cost:

Pilot Light: replicate critical data to a secondary region (S3, snapshots, DB replicas) but minimal running infrastructure; quick scale-up via IaC templates.
Warm Standby: smaller active footprint in secondary region with continuously replicated data and scaled-down services that can be increased automatically.
Multi-Region Active-Active: run full stacks in multiple regions with traffic routing and conflict resolution; requires global replication (DynamoDB global tables, Aurora Global DB, application-level conflict handling).

Consider replication consistency: synchronous replication minimizes RPO but increases latency and may not be supported cross-region; most cross-region options are asynchronous and introduce replication lag that defines realistic RPO.

Multi-AZ and Multi-Region architecture choices

Multi-AZ is the default for high availability within a region; it provides automatic failover for many managed services with minimal RTO. RDS Multi-AZ and Aurora replicate storage across AZs—failover is typically automatic and uses DNS switch-over. For EC2, place instances in multiple AZs behind an Application Load Balancer and Auto Scaling groups; use cross-AZ health checks to detect and replace unhealthy targets.

Multi-Region adds resilience against region-wide failures but increases complexity (data replication, global routing, compliance). Decision criteria:

Use Multi-AZ when you need high availability with low latency inside a region and want managed automatic failover at lower cost.
Use Multi-Region for disaster recovery against region loss or for global active-active latency reduction.

Design considerations:

DNS TTLs: low TTLs (e.g., 60s) are needed for fast DNS-based failover but increase DNS query load.
Data locality and compliance: some data must remain in a region; architect replication and encryption accordingly.
Cost vs RTO/RPO: Multi-Region active-active increases cost but minimizes RTO.

Failover mechanisms (Route53 health checks, automated)

Automated failover uses health checks, routing policies, and orchestration. Route53 supports health checks and failover/weighted/latency routing. Configure Route53 health checks to probe endpoints (HTTP, TCP, or CloudWatch alarms) and a failover record set that switches to a secondary resource when the primary fails. CLI update example: aws route53 change-resource-record-sets –hosted-zone-id Z123456 –change-batch file://changes.json. Use CloudWatch alarms (alarm actions trigger AWS Lambda) to orchestrate failover for non-DNS actions.

Integrate Load Balancers and Auto Scaling: ALB/NLB target group health checks remove unhealthy instances, while Auto Scaling replaces them automatically. For database failover, rely on service-level mechanisms: RDS Multi-AZ or Aurora automated failover, and for cross-region promotion use read replicas or Aurora Global DB controlled promotion.

Two operational patterns:

DNS failover (Route53): fast to implement, but dependent on DNS TTL and client caching.
Control plane failover (Lambda/Step Functions + API calls): orchestrates promotion, IP/EIP reassignment, and Route53 updates in a predictable sequence for complex applications.

RTO/RPO planning, testing, and validation

RTO is the maximum acceptable downtime; RPO is the maximum acceptable data loss. Define measurable targets for each workload and align architecture choices: synchronous replication reduces RPO but may increase latency; asynchronous replication lowers cost but increases potential data loss window. Translate business SLAs into retention and replication frequency: RPO = replication lag + backup interval; RTO = detection time + failover orchestration time + recovery validation time.

Testing is essential: run scheduled DR drills that validate restoration procedures, DNS failover, and application integrity. Validate backups by restoring to an isolated account or VPC (use CloudFormation/CloudFormation StackSets or Terraform to automate rebuilds). Capture metrics during tests (time to DNS propagation, recovery point, application-level checks) and iterate on automation to reduce RTO.

Common Pitfalls and Decision Criteria

Assuming snapshots equal recoverability: always perform restores to a separate environment and validate application-consistency; use engine-native snapshots or quiesce applications before snapshotting.
Designing single-region systems for global critical workloads: choose Multi-Region patterns or warm standby when regional failure impacts customers; consider data sovereignty.
Ignoring RTO/RPO in design: capture RTO/RPO per workload and select replication/backups accordingly; map RPO to replication frequency and RTO to orchestration automation.
Long DNS TTLs that block fast failover: set low TTLs for critical failover records and use global acceleration only when stable routing is required.
Neglecting IAM/permissions for cross-region replication: CRR, snapshot copy, and backup vault access require correct roles and resource policies; test replication IAM paths.
Not monitoring replication lag and health: instrument CloudWatch Metrics (ReplicaLag, CPU, network) and alert when thresholds approach RPO limits.

Practical Problem: Use-Case Scenario

AcmePayments runs a PCI-scoped transaction API in us-east-1 and needs <5-minute RTO and near-zero RPO for core transaction data during a regional outage.

Define RTO=5 min and RPO≈0 by selecting Aurora Global Database with writable primary in us-east-1 and secondary in eu-west-1 for fast cross-region replication.
Enable synchronous/per-region Multi-AZ for intra-region HA (Aurora replicas + Multi-AZ), and publish DNS via Route53 with health checks and low TTL (60s) for failover routing.
Use cross-region automated snapshots and AWS Backup vault copies as an additional immutable copy with retention and vault lock.
Automate failover playbook with Step Functions and Lambda to validate replica promotion, update Route53 records (aws route53 change-resource-record-sets), run smoke tests, and rollback if failures detected.
Schedule quarterly DR drills restoring backups to an isolated VPC and measure actual RTO and RPO, then refine automation and scaling policies.

Rationale: combining a low-latency global DB product (Aurora Global) with DNS-based routing and automated orchestration meets strict RTO/RPO while keeping operational steps repeatable and testable. Regular validation ensures backups and replicas are actually recoverable.

← Monitoring · All domains · Deployment →

Practice these questions → · Timed practice on ExamRoll.io →