AWS Backup Strategy: EBS Snapshot vs AMI Deep Dive

1-Line Summary

An EBS Snapshot is an incremental block-level storage backup, whereas an AMI is a complete recovery blueprint bundling instance metadata (OS, bootloader, Block Device Mapping) with underlying volume snapshots.

1. EBS Snapshot vs AMI Architecture Comparison

To achieve precise Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO), engineers must decouple block-level data from system state metadata.

[Amazon Machine Image (AMI) Architecture]
┌─────────────────────────────────────────────────────────┐
│ AMI ID: ami-xxxxxxxxxxxxxxxxx                           │
│  ├─ [Root Volume EBS Snapshot] (snap-01)                │
│  ├─ [Attached Data Volume EBS Snapshot] (snap-02)        │
│  └─ [Instance Metadata] (Block Device Mapping, OS, Arch)│
└─────────────────────────────────────────────────────────┘

Dimension	EBS Snapshot	Amazon Machine Image (AMI)
Scope	Single or multiple EBS block volumes	Entire EC2 Instance (OS + Config + All Volumes)
Storage Engine	Incremental changed blocks stored in S3	Snapshot pointer + Block Device Mapping metadata
Restore Path	1. Create Volume from Snapshot 2. Attach volume to target EC2	1-Click Launch new EC2 instance directly
Primary Use	Database/File volume incremental backup	Disaster Recovery (DR), Auto Scaling Launch Templates

---

2. Decision Matrix

• Scenario A: Full OS and System Disaster Recovery ➔ Choose AMI
  • When system binaries or configuration files corrupt, launch an identical replacement instance instantly from the pre-baked AMI.
• Scenario B: Recurring Database/Application Volume Backup ➔ Choose EBS Snapshot
  • Only modified storage blocks consume incremental S3 tier space, optimizing storage costs.

---

3. Crash Consistency & File System Quiescence

When taking live backups on active production workloads, uncommitted dirty pages in kernel memory can lead to file system corruption unless quiesced.

# Linux: Freeze I/O operations (XFS / EXT4)
fsfreeze -f /data

# AWS CLI: Trigger Snapshot
aws ec2 create-snapshot --volume-id vol-0123456789abcdef0 --description "Quiesced-Production-Backup"

# Unfreeze I/O operations
fsfreeze -u /data

---

4. Automated Backup Lifecycle (Amazon Data Lifecycle Manager)

Eliminate human error by applying tag-driven retention policies with AWS DLM:

{
  "ResourceTypes": ["VOLUME"],
  "TargetTags": [{"Key": "Environment", "Value": "Production"}],
  "Schedules": [
    {
      "Name": "Daily-Snapshot",
      "CreateRule": {"Interval": 24, "IntervalUnit": "HOURS", "Times": ["03:00"]},
      "RetainRule": {"Count": 7}
    }
  ]
}

---

5. Gotchas & Engineering Checkpoints

1. Snapshot Deletion Lineage: Deleting an intermediate snapshot does not corrupt dependent snapshots; AWS automatically merges referenced block data downstream in S3.
2. Production DB Live Backups: For high-write transactional databases (MySQL/PostgreSQL), prefer native RDS Automated Backups or WAL-based archiving over raw disk snapshots to guarantee transactional integrity.

---

Published: 2026-07-28 08:33:04Updated: 2026-08-15 13:57:00