AWS Certified Solutions Architect - Associate (SAA-C03) #8 Domain 2-3 Resilient Architectures — Backup Strategy

5 min read

In #7 DR Patterns we said the foundation of every DR strategy is a backup you can trust. This post, the last of the resilience domain, deals with that backup. In SAA, backup questions come as “how do you automate it,” “how do you recover to a specific point in time,” and “how do you manage it centrally and keep it immutable.”

EBS snapshots #

An EBS snapshot is a point-in-time backup of a volume, and it is internally stored in S3 (it’s managed, so you don’t see it directly).

  • Incremental storage — the first snapshot is full, after which only changed blocks are stored. That’s why storage cost is efficient. However, restoring from any snapshot always produces a complete volume as of that point.
  • Cross-Region , cross-account copy — copy a snapshot to another Region or account to use for DR and sharing. When sharing an encrypted snapshot across accounts, you need to allow it in the KMS key policy.
  • Data Lifecycle Manager (DLM) — automates the snapshot creation interval and retention period via policy. You set rules like “daily snapshot, 7-day retention.”

RDS backups #

RDS provides two backup mechanisms. The difference between them comes up often on the exam.

AspectAutomated backupManual snapshot
CreationDaily automatic + transaction logsCreated by the user directly
Point-in-time recovery (PITR)PossibleNot possible (snapshot point only)
Retention1–35 days (configurable)Permanent until deleted
When the instance is deletedDeleted along with it (usually)Remains
  • Automated backup — keeps the daily backup and transaction logs together so you can recover to any point in time within the retention period (up to 35 days), i.e. PITR. It is the answer to requirements like “roll back to the state 5 minutes ago.”
  • Manual snapshot — created by the user directly and retained until explicitly deleted. Use it when you need to keep it longer than 35 days, or keep the backup even after deleting the instance.

Aurora is continuously backed up to S3 and provides PITR within the retention period.

AWS Backup — centralized backup #

If every service has its own backup method, management gets hard. AWS Backup is a service that centrally manages backups of multiple services with a single policy.

  • Supported targets — EBS, RDS, DynamoDB, EFS, S3, Storage Gateway, and many more
  • Backup Plan — defines the interval, retention, and targets (tag-based selection) as a policy
  • Cross-Region , cross-account backup — centrally configure DR and isolated retention
  • Backup Vault Lock — locks backups as immutable (WORM, write-once-read-many, unchangeable after write) to prevent deletion or modification within the retention period. Used for ransomware protection and regulatory compliance.

If the requirement is “centrally manage backups of multiple services with a policy,” the answer is AWS Backup. If it is “keep backups so they cannot be deleted (immutable),” it is Vault Lock.

S3 data protection #

S3’s own data-protection mechanisms also appear in backup questions.

  • Versioning — preserves previous versions even if you overwrite or delete an object. The basis for recovering from accidental deletion.
  • Lifecycle — moves old versions to low-cost storage (covered in #11) or expires them.
  • Object Lock — preserves S3 objects as WORM (regulatory , immutability requirements).
  • Cross-Region Replication (CRR) — automatically replicates to a bucket in another Region.

Exam question patterns #

  • Centrally manage backups of multiple services with a policy.” → AWS Backup
  • “EBS snapshots on an automatic schedule.” → DLM (or AWS Backup)
  • “Recover RDS to any point in time.” → automated backup PITR (retention up to 35 days)
  • “Keep the backup permanently even after deleting the instance.” → manual snapshot
  • “Make backups undeletable (immutable).” → Backup Vault Lock / S3 Object Lock
  • “Keep snapshots in another Region (DR).” → cross-Region snapshot copy
  • “Recover an S3 object from accidental deletion.” → versioning

Common pitfalls #

1) Thinking RDS automated backup retention is unlimited #

Automated backups are up to 35 days. To keep them longer, use manual snapshots or set a long-term retention policy with AWS Backup.

2) Treating automated backups and manual snapshots as the same #

Automated backups provide PITR but have limited retention and are deleted along with the instance. Manual snapshots have no PITR but are retained permanently.

3) Assuming that because snapshots are incremental, restores are only partial too #

Storage is incremental, but a restore always produces a complete volume as of that point.

4) Forgetting KMS when sharing an encrypted snapshot across accounts #

To share an encrypted snapshot with another account, you must allow that account in the KMS key policy.

Summary #

What we nailed down in this post:

  • EBS snapshots — incremental storage (restore is a complete volume), cross-Region , account copy, automated with DLM
  • RDS — automated backup gives PITR (up to 35 days), manual snapshots give permanent retention. Different purposes
  • AWS Backup — multi-service backups under a central policy. Immutable retention with Vault Lock
  • S3 — versioning (recover from accidental deletion), Object Lock (WORM), CRR (cross-Region)

With this we finish the resilience domain (26%, #6–8). We nailed down single-Region high availability with multi-AZ , ASG , ELB, cross-Region disaster preparedness with DR strategy, and the foundation of data recovery with backup.

Next — Domain 3-1 High-Performance Architectures #

The next domain is performance (24%). We move on to design that “responds fast even as load grows.”

In #9 Domain 3-1 Choosing Compute we will organize the EC2 instance type families and how to choose among them, the performance and cost trade-offs of the purchasing options (On-Demand , Reserved , Spot , Savings Plan), and when to choose serverless compute (Lambda , Fargate).

X