[2.0] AWS EBS Snapshot Management: Secure Copies, Encryption, Cleanup, and Instant Recovery

Imagine we’re managing a global chain of bakeries. We need to ship recipes to new locations (copy snapshots), lock our secret ingredients (encryption), clean up old files (delete snapshots), and instantly restock shelves during a rush (fast restore). AWS EBS offers tools to handle all this - let’s break them down.

---

1. Copying Snapshots: Sending Recipes to New Bakeries

When opening a bakery in Paris, we’d mail our New York recipes. Copying EBS snapshots works similarly, letting our replicate data across AWS Regions.

Why Copy Snapshots?

• Disaster Recovery: Backup our croissant recipes in another region in case of a kitchen fire.

• Global Expansion: Launch our app in Tokyo by copying snapshots from Ohio.

• Encryption Tweaks: Change the lock on our recipe vault (switch KMS keys) during the copy.

Step-by-Step: Mail a Snapshot

1. Open the EC2 Console: Navigate to Snapshots.

2. Select Our Snapshot: Choose the one to copy (e.g., snap-12345).

3. Click Copy Snapshot:

   • Destination Region: Pick Paris (eu-west-3).

   • Encryption: If the original is unencrypted, add a lock (KMS key).

4. Wait for Delivery: Track progress in the destination region’s console.

Pro Tips:

• Incremental Copies: Only changed data is copied after the first backup.

• No Tag Sharing: Tags don’t transfer - relabel copies manually.

• Concurrency Limits: Only 20 snapshot copies can process at once per region.

---

2. Encryption: Locking Our Recipe Vaults

Our secret recipes need safes. EBS encryption uses AWS KMS keys to lock data at rest (on disks) and in transit (to/from instances).

How It Works

• Automatic Protection: New volumes inherit encryption if enabled by default.

• Snapshot Impact: Encrypted volumes create encrypted snapshots - copying them retains the lock.

• Shared Access: To share a locked snapshot, grant others KMS key access.

Pitfalls to Avoid

• No Re-encryption: Can’t remove encryption later. Bake it in from the start.

• Performance Trade-offs: Minimal latency from encryption - worth it for security.

---

3. Deleting Snapshots: Spring Cleaning Our Kitchen

Old recipes clutter our shelves. Deleting snapshots frees space, but tread carefully.

Rules of the Trash

• AMIs Block Deletion: Can’t delete snapshots tied to registered AMIs. Deregister the AMI first.

• Recycle Bin Safety Net: Deleted snapshots stay recoverable for 7–30 days if enabled.

• Shared Snapshots: Deleting our copy revokes others’ access.

How to Delete

1. EC2 Console > Snapshots: Select the snapshot.

2. Click Delete: Confirm, unless it’s in the Recycle Bin.

3. Wait for Completion: In-progress snapshots finish before deletion.

Pro Tip: Use Amazon Data Lifecycle Manager to auto-delete old snapshots.

---

4. Fast Snapshot Restore (FSR): Instant Oven Preheating

During a lunch rush, we need cookies ready now. FSR skips the preheating - volumes launch fully initialised.

When to Use FSR

• High-Performance Apps: Databases needing instant IOPS.

• Disaster Recovery: Quickly spin up replacements during outages.

Setup Guide

1. Enable FSR: In the EC2 console, select a snapshot and enable FSR for its AZ.

2. Create Volumes: New volumes in that AZ bypass lazy loading.

Limitations:

• AZ-Bound: Enable FSR per snapshot per AZ (e.g., us-east-1a).

• Size Caps: Snapshots over 16 TB won’t qualify.

---

Putting It All Together: Running a Bakery Empire

Scenario: Launching a Tokyo Branch

1. Encrypt: Enable default encryption for all new Tokyo volumes.

2. Copy Snapshot: Replicate our NYC database to ap-northeast-1.

3. Enable FSR: Speed up Tokyo’s opening day.

4. Delete Old Copies: Clean up test snapshots after launch.

---

Conclusion: Master Our EBS Toolkit

Managing EBS snapshots is like running a bakery chain:

• Copy recipes globally.

• Encrypt our secrets.

• Delete clutter wisely.

• Restore instantly during crises.