AWS SAA-C03: High Availability, Fault Tolerance & Disaster Recovery — Study Guide

By Laurynas Brazys · 15 July 2026 · #amazon #aws #saa-c03 #ha-dr #certification #exam-prep #study-guide

Part of the AWS SAA-C03 Complete Study Guide. Practice these concepts with verified answers in the AWS/Amazon exam hub, or take timed practice tests on ExamRoll.io.

Multi-AZ Deployments and Replication

Multi-AZ architectures address failure of a single data center or Availability Zone — nothing more. This distinction is the single most misunderstood point in high-availability design. A Multi-AZ deployment tolerates the loss of an AZ within one Region; it does not tolerate a Region-wide outage, a regional service impairment, or the accidental deletion of a resource that immediately replicates the deletion to the standby. Replication faithfully propagates bad data — logical corruption, schema mistakes, ransomware writes — which is why replication and backup are complementary, not substitutes.

For Amazon RDS, Multi-AZ provisions a synchronous standby replica in a different AZ. Writes commit on both instances before acknowledgment, giving an RPO effectively at zero and an RTO typically of 60–120 seconds during automatic failover. In the classic Multi-AZ instance deployment the standby is not readable — it exists purely for durability and failover. Multi-AZ cluster deployments (two readable standbys) reduce failover time further and provide some read scaling, but still confine themselves to one Region.

For read scaling, add read replicas. Read replicas use asynchronous replication and exist to offload reporting, analytics, and dashboard queries. Treating a read replica as an HA failover mechanism is wrong on three counts: replication is asynchronous (data loss on promotion), promotion is manual or scripted (not automatic), and the primary endpoint is not preserved. When a growing workload needs more read capacity without new complexity, add a read replica; when the requirement is automatic failover with zero data loss, use Multi-AZ. When RPO/RTO must survive a Region failure for a relational engine, Aurora Global Database provides sub-second cross-Region replication lag and sub-minute managed failover RTO.

Amazon ElastiCache follows the same pattern with replication groups. A Redis replication group with Multi-AZ enabled maintains a primary and one or more replicas across AZs; if the primary fails, ElastiCache promotes a replica and updates the primary endpoint. For horizontal scale, Redis (cluster mode enabled) partitions data across shards, each shard being its own replication group. Memcached, by contrast, does not replicate — node loss means data loss for that partition.

Amazon FSx offers Multi-AZ deployment types for FSx for Windows File Server and FSx for ONTAP, using synchronous replication between a preferred and standby file server. FSx for Lustre is generally single-AZ (scratch or persistent); durability for Lustre comes from S3 data repository associations, not from AZ replication.

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

RDS Automated Backups and Point-in-Time Recovery

RDS automated backups combine a daily snapshot with continuous 5-minute transaction log uploads to S3, giving point-in-time recovery (PITR) to any second within the 1–35 day retention window. If your RPO is 2 hours, RDS’s native backups already cover it — no extra snapshot scheduling is required, and layering AWS Backup on top is redundant unless you need cross-Region copies, cross-account isolation, or Vault Lock semantics beyond what RDS snapshot copy provides. The default automated backup is often the cheapest correct answer to modest RPO requirements.

AWS Backup as the Centralized Control Plane

AWS Backup is the policy-driven control plane for backup across EBS, EC2 (as AMIs), RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway, S3, and more. Rather than scripting service-specific snapshot logic, you define backup plans grouping rules that describe frequency, backup window, start/completion windows, lifecycle transitions to cold storage, retention, and destination vaults. Resources are enrolled through resource assignments by tag or ARN, so a tagging convention like Backup=Daily becomes the operational contract that governs coverage. For fleets of hundreds of EC2 instances, tag-based selection is the lowest-effort approach — apply the tag and let AWS Backup enumerate, rather than authoring per-instance schedules.

A backup vault is the KMS-encrypted container where recovery points live. Access is controlled by resource policies on the vault.

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

Cross-Region and Cross-Account Copies

The CopyActions block is the mechanism for cross-Region DR copies. AWS Backup handles the snapshot copy, re-encrypts with a destination-Region KMS key (the destination vault must reference a key in that Region), and applies an independent lifecycle. EBS and RDS snapshots default to the source Region — if the whole Region is impaired, so are the snapshots. Any regulatory or business requirement mentioning regional resilience must include an explicit cross-Region copy step, whether through AWS Backup copy actions, RDS automated snapshot cross-Region copy, or DLM policies with cross-Region destinations.

For cross-account copies, AWS Organizations delegates an administrator account for AWS Backup; the source vault’s policy allows the destination account, and the destination vault permits copies from the source. This is the cost-effective way to centralize DR: one management account holds recovery points from many workload accounts and can restore into either Region. For EC2, an AMI copy to a second Region plus snapshot sharing lets you launch instances there without warm infrastructure. Encrypted snapshots require sharing the CMK — the destination account or Region needs kms:CreateGrant and access to the key. Missing this is why cross-account restores silently fail.

A 24-hour RPO is satisfied cheaply by a daily automated snapshot copied cross-Region — far less costly than a cross-Region read replica or a warm standby cluster. Tighten to continuous replication only when RPO drops below what snapshot cadence can deliver.

AMI Lifecycle and EC2 Backups

Two mechanisms automate EC2 backups: Data Lifecycle Manager (DLM) and AWS Backup. DLM predates AWS Backup and creates policy-driven EBS snapshots or AMIs on schedule with cross-Region and cross-account copy actions. AWS Backup subsumes this and adds central policy, Vault Lock, and multi-service scope. Prefer AWS Backup when you already run it for other services; use DLM for pure EBS/AMI scenarios where you don’t need vault features.

For stateless web tiers behind an Auto Scaling group with no persistent local data, backing up running EC2 instances is wasteful. The correct posture is to bake a hardened AMI (via EC2 Image Builder or a CI pipeline), reference it in the launch template, and let ASG handle instance replacement. Backup effort concentrates on the stateful tiers whose native automated backups meet the RPO.

Immutability: Vault Lock and Object Lock

A plain snapshot in your account can be deleted by anyone with the right IAM permission — snapshots alone do not satisfy immutability requirements. Regulatory regimes (SEC 17a-4, FINRA, HIPAA, GDPR) frequently demand write-once-read-many retention that even administrators cannot circumvent. Two AWS mechanisms deliver this.

AWS Backup Vault Lock enforces WORM on a backup vault:

In compliance mode, once the cooling-off period elapses, no user — including the root account — can shorten retention, delete recovery points before expiry, or remove the lock itself. This defeats both insider deletion and a ransomware operator who has fully compromised the account.

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

S3 Object Lock provides object-level WORM in Governance mode (privileged users with s3:BypassGovernanceRetention can override) or Compliance mode (nobody, including root, can delete or shorten retention). Legal Hold is independent of retention periods. Object Lock requires versioning and must be enabled at bucket creation for full protection.

Capacity Reservations for the Failover Region

A DR plan that assumes the failover Region will have EC2 capacity available on the day of a large-scale event is not a plan. When a Region fails, everyone fails over simultaneously, and instance types — especially large, GPU, or specialized shapes — can exhaust. On-Demand Capacity Reservations (ODCRs) in the target Region guarantee capacity for a specific instance type, platform, and AZ, and are billed whether used or not. Pair with a Savings Plan to offset cost. For long-horizon GPU/ML commitments, Capacity Blocks apply; for family flexibility, a Capacity Reservation Fleet covers multiple instance families. The principle: if the business requires guaranteed compute in the DR Region, reserve it — do not rely on best-effort On-Demand availability.

DR Strategy Selection

AWS canonicalizes four DR tiers, each with a distinct cost/recovery tradeoff:

The correct tier is dictated by the business’s RPO and RTO — not architectural preference. A 24-hour RPO tolerates daily cross-Region snapshot copies (Backup & Restore). An RPO of seconds demands continuous replication — cross-Region read replicas, Aurora Global Database, DynamoDB Global Tables, or S3 Cross-Region Replication. Attempting a 5-minute RPO with nightly snapshots is architecturally impossible, regardless of budget. Conversely, defaulting to active-active for every workload is a cost antipattern: it demands globally-consistent data (DynamoDB Global Tables or Aurora Global with write-forwarding), duplicate compute at full scale, and complex traffic steering via Route 53 or Global Accelerator. Pick the cheapest pattern that meets the stated RPO/RTO — for a 2-hour RPO, backup-and-restore or pilot light usually suffices, and warm standby is over-engineering.

Deletion Protection and Layered Safeguards

Resilience is not merely “do we have backups” — it is “can any single actor, mistake, or attack erase them.” Layered controls prevent the one-wrong-click catastrophe:

• RDS: enable DeletionProtection and require a final snapshot on delete.
• EC2: enable DisableApiTermination and DisableApiStop on critical instances.
• DynamoDB: enable deletion protection and point-in-time recovery.
• S3: Versioning + MFA Delete + Object Lock for immutability.
• CloudFormation: DeletionPolicy: Retain on stateful resources and stack termination protection.
• IAM SCPs: deny backup:DeleteRecoveryPoint, backup:DeleteBackupVault, rds:DeleteDBInstance, and ec2:DeleteSnapshot outside break-glass roles.

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

Combined with Vault Lock in compliance mode, these produce defense in depth: even a compromised administrator credential cannot destroy the last-line-of-defense recovery points.

Common Traps

Treating Multi-AZ as DR. RDS Multi-AZ, ElastiCache Multi-AZ, and FSx Multi-AZ all live within one Region. A Regional API outage, an accidental table drop, or a misapplied schema migration hits both nodes. Any requirement mentioning “another Region,” “regional failure,” or “cross-Region RPO” mandates cross-Region replication or copy — Multi-AZ alone fails the requirement.

Confusing read replicas with HA. Read replicas are asynchronous, promote manually, and change endpoints. They solve read scaling, not automatic failover.

Assuming snapshots equal compliance. Snapshots without Vault Lock (compliance mode) or Object Lock are deletable by any principal with the right IAM permission and by the root account. WORM regulatory retention requires explicit immutability configuration with a locked cooling-off period elapsed.

Local-only snapshots for a Regional RPO. EBS and RDS snapshots default to the source Region. Regional resilience requires an explicit cross-Region copy action.

Backups without tested restores or reserved capacity. A snapshot you have never restored is a hypothesis, not a backup. Restore drills reveal missing IAM roles, KMS key access issues in the destination Region and account, and unavailable instance types. Without Capacity Reservations for critical workloads, the DR Region may simply not have the shape you need when everyone fails over simultaneously — and RTO becomes unbounded.

Over-engineering to active-active. Duplicate global compute, globally-consistent data replication, and complex traffic steering are expensive. If the RPO/RTO doesn’t justify it, a pilot light or warm standby is the correct architecture.

Backing up stateless tiers. Snapshotting ephemeral web servers behind an ASG wastes money and complicates recovery. Bake AMIs, reference them in launch templates, and concentrate backup investment on stateful data.

← Previous: Management · All domains

Practice High Availability questions → · Timed practice on ExamRoll.io →

Browse Amazon →