AWS Database Services: Backup & Recovery Essentials
In the AWS Certified Solutions Architect – Associate (SAA-C03) exam, understanding how to protect data is as critical as knowing how to store it. Database backups ensure business continuity, meet compliance requirements, and provide a safety net against accidental deletions or system failures.
Core Backup Types: RDS & Aurora
1. RDS Automated Backups
AWS automatically takes a full daily snapshot of your DB instance and captures transaction logs. This allows for Point-in-Time Recovery (PITR) down to the second.
- Retention: 1 to 35 days (0 days disables backups).
- Storage: Stored in S3 (though you don’t see the bucket).
- Performance: In Single-AZ, I/O may be suspended briefly. In Multi-AZ, the backup is taken from the standby to avoid impact.
2. RDS Manual Snapshots
User-initiated backups that persist even after the DB instance is deleted.
- Retention: Indefinite (until manually deleted).
- Use Case: Long-term archiving or pre-upgrade safety checks.
3. Aurora Backups
Aurora is “backup-native.” It continuously streams data to S3 in real-time. There is no performance impact during the backup process, and the retention period is also 1-35 days.
Comparison: RDS vs. DynamoDB Backups
| Feature | Amazon RDS | Amazon DynamoDB |
|---|---|---|
| PITR | Enabled by default (1-35 days) | Optional (last 35 days) |
| Manual Backups | Snapshots (stored in S3) | On-Demand Backups |
| Performance Impact | Brief pause (Single-AZ only) | Zero impact on throughput |
| Cross-Region | Manual copy of snapshots | Global Tables or AWS Backup |
Security & Compliance
- Encryption: If the DB is encrypted, the backup is encrypted. You cannot “un-encrypt” a snapshot.
- Sharing: You can share manual snapshots with other AWS accounts. However, you cannot share a snapshot encrypted with the default AWS KMS key; you must use a Custom Managed Key (CMK).
- AWS Backup: A centralized service to manage backups across RDS, DynamoDB, DocumentDB, and Neptune, offering “Write Once Read Many” (WORM) locks via Backup Vault Lock.
Decision Matrix: If-Then Guide
- If you need to recover to a specific second… Then use Automated Backups (PITR).
- If you need to keep data for 7 years for compliance… Then use Manual Snapshots or AWS Backup.
- If you need to minimize performance impact on a production RDS… Then use Multi-AZ deployment.
- If you need to move a database to a different region… Then Copy Snapshot to the target region and Restore.
Exam Tips and Gotchas
- The “0” Trap: Setting the backup retention period to 0 disables automated backups and deletes all existing automated backups immediately.
- Restore != Overwrite: Restoring from a backup always creates a new DB instance with a new endpoint. You must update your application configuration.
- Cross-Account Sharing: To share an encrypted snapshot, you must share the custom KMS key used to encrypt it first.
- Aurora Backtrack: Unlike a restore, Backtrack lets you “rewind” an existing cluster to a point in time without creating a new instance (faster RTO).
Topics covered :
Summary of key subtopics covered in this guide:
- Automated Backups vs. Manual Snapshots
- Point-in-Time Recovery (PITR) mechanisms
- Performance implications (Single-AZ vs. Multi-AZ)
- Encryption and Cross-account sharing constraints
- DynamoDB On-Demand vs. PITR
- AWS Backup for centralized governance
Infographic: AWS Database Backup Architecture
Flow: Daily Backup → S3 Storage → Cross-Region Copy → Restore to New Instance
KMS: Manages encryption keys for snapshots.
CloudWatch: Monitors backup storage usage and failure events.
IAM: Controls who can DescribeSnapshots or ModifyDBInstance.
Multi-AZ: Backups are taken from the Standby instance to prevent latency on the Primary.
Aurora: Distributed storage layer allows continuous backups without snapshots impacting compute.
Storage: You pay for snapshot storage. Delete manual snapshots that are no longer needed.
Incremental: RDS snapshots are incremental; only changed blocks are saved, reducing costs over time.