3.3.2. Snapshot Automation: EC2, RDS, EBS, S3, DynamoDB
💡 First Principle: Manual snapshots are a liability disguised as a process. The only reliable backup is one that runs automatically on a schedule, because humans consistently forget, deprioritize, or skip manual tasks under operational pressure.
Resource-Specific Backup Mechanisms:
| Resource | Automated Backup Method | Manual Backup |
|---|---|---|
| RDS/Aurora | Automated backups (1–35 day retention; enabled by default) | Manual DB snapshots (kept until deleted) |
| EC2 | Data Lifecycle Manager (DLM) or AWS Backup | Manual AMI creation |
| EBS | DLM policies or AWS Backup | Manual snapshot |
| DynamoDB | Point-in-Time Recovery (PITR) + AWS Backup | On-demand backup |
| S3 | Versioning + replication + S3 Backup in AWS Backup | Individual object copy |
AWS Data Lifecycle Manager (DLM): Automates EBS snapshot creation and retention through lifecycle policies. You define:
- Target resource: EC2 instances or volumes with specific tags
- Schedule: Every N hours/days
- Retain: Keep last N snapshots or for N days
- Cross-region copy: Automatically copy snapshots to another region
- Fast snapshot restore: Pre-warm snapshots for near-instant restore
DLM is simpler than AWS Backup for EBS-only use cases but doesn't provide the cross-service management or compliance reporting of AWS Backup.
How EBS snapshots store data: snapshots are incremental. The first stores only the blocks that hold data (not empty space); each later snapshot stores only the blocks changed since the previous one, and you pay for the blocks stored. A volume restored from a snapshot is usable at once, but its blocks load from S3 lazily on first access, so early reads are slow until each block has been read. Fast snapshot restore (FSR) on the snapshot removes that first-read penalty. A one-off snapshot from the CLI is aws ec2 create-snapshot --volume-id <vol-id>: EBS snapshot commands live under ec2, and create-image makes an AMI of an instance, not a volume snapshot.
RDS Automated Backups vs. Manual Snapshots:
| Feature | Automated Backup | Manual Snapshot |
|---|---|---|
| Retention | 1–35 days (deleted automatically) | Indefinite (until you delete) |
| Point-in-time restore | ✅ Yes (to any second within retention period) | ❌ No (restores to snapshot time only) |
| Deleted with DB? | ✅ Yes, unless you choose Retain automated backups at deletion (they then expire with the retention period) | ❌ No (persists after DB deletion) |
DynamoDB Point-in-Time Recovery (PITR): When enabled, DynamoDB continuously backs up your table, allowing restore to any point in the past 35 days with second-level granularity. PITR is not enabled by default — you must explicitly enable it per table. Enabling PITR is a best practice for any production DynamoDB table.
⚠️ Exam Trap: When you delete an RDS instance, its automated backups are deleted too unless you choose to retain them; a final snapshot taken at deletion is a manual snapshot, so it persists. If you want to preserve the ability to restore after deletion, always take a manual snapshot before deleting an RDS instance, or configure deletion protection.
Reflection Question: A developer accidentally ran DROP TABLE on a production DynamoDB table 6 hours ago. PITR was not enabled. What recovery options exist, and what would you configure immediately to prevent this from happening again?
