TECH **AWS EBS Volume Types & Snapshots: Zero-Fluff, Hands-On Guide**

AWS EBS Volume Types & Snapshots: Zero-Fluff, Hands-On Guide

(For AWS Solutions Architect – Associate & Real-World Production)

1. What This Is & Why It Matters

You’re a cloud engineer, and your team just migrated a monolithic app to AWS. The database is on an EBS volume, but performance is terrible—queries take 10x longer than on-prem. Meanwhile, your CFO is freaking out because storage costs are skyrocketing. EBS volume types and snapshots are your tools to fix this.

• EBS volume types determine speed, cost, and durability of your block storage. Pick wrong, and your app crawls (or you overspend).
• Snapshots let you backup, clone, and restore volumes in seconds—but misuse them, and you’ll either lose data or pay for useless backups.

Real-world scenario:
You inherit a legacy app with: - A gp2 volume for a high-traffic PostgreSQL DB (bottleneck: IOPS).
- No automated snapshots (risk: data loss if the volume fails).
- A st1 volume for logs (waste: logs don’t need high throughput).

This guide will show you:
✅ How to diagnose which EBS type fits your workload.
✅ How to migrate volumes without downtime.
✅ How to automate snapshots (and avoid $10K/month in unused backups).
✅ Exam traps (e.g., "Why is io2 better than gp3 for databases?").

2. Core Concepts & Components

? EBS Volume Types

? EBS Snapshots

• Definition: Incremental backups of EBS volumes stored in S3 (but you don’t see them in your S3 console).
• Production Insight:
• First snapshot = full copy. Subsequent snapshots only store changed blocks (saves cost).
• Snapshots are region-specific. To copy across regions, use aws ec2 copy-snapshot.
• Encryption: If the volume is encrypted, the snapshot is automatically encrypted (and vice versa).
• Restore time: Creating a volume from a snapshot takes seconds to minutes (depends on size).

? Key Terms

• IOPS (Input/Output Operations Per Second): How many reads/writes per second. Critical for databases.
• Throughput (MiB/s): How much data can be read/written per second. Critical for large files (logs, backups).
• Burst Balance: gp2/gp3 volumes can burst above baseline IOPS for short periods. Monitor this in CloudWatch!
• Multi-Attach: Only io1/io2 volumes can be attached to multiple EC2 instances (useful for clustered apps like Oracle RAC).

3. Step-by-Step Hands-On: Migrate a gp2 Volume to gp3 (Zero Downtime)

Prerequisites

✅ AWS CLI installed & configured (aws configure).
✅ An EC2 instance with a gp2 volume (e.g., /dev/xvda).
✅ Basic Linux knowledge (lsblk, df -h).

Step 1: Check Current Volume Type & Performance

# List volumes attached to your instance
aws ec2 describe-volumes --filters "Name=attachment.instance-id,Values=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)" --query "Volumes[].{ID:VolumeId,Type:VolumeType,Size:Size,IOPS:Iops}" --output table

Expected Output:

-----------------------------------------
|            DescribeVolumes            |
+------------+-------+------+-----------+
|     ID     | Type  | Size |   IOPS    |
+------------+-------+------+-----------+
| vol-123456 | gp2   | 100  | 300       |
+------------+-------+------+-----------+

Why this matters:
- If IOPS is 300 (3 IOPS/GB for gp2), your DB might be throttled.
- If Type is gp2, you’re overpaying.

Step 2: Create a Snapshot (Backup)

aws ec2 create-snapshot --volume-id vol-123456 --description "Pre-migration backup" --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=gp2-to-gp3-migration}]'

Verify:

aws ec2 describe-snapshots --snapshot-ids $(aws ec2 describe-snapshots --filters "Name=tag:Name,Values=gp2-to-gp3-migration" --query "Snapshots[0].SnapshotId" --output text) --query "Snapshots[0].State"

Expected Output: "completed"

Step 3: Create a New gp3 Volume from the Snapshot

aws ec2 create-volume \
  --snapshot-id $(aws ec2 describe-snapshots --filters "Name=tag:Name,Values=gp2-to-gp3-migration" --query "Snapshots[0].SnapshotId" --output text) \
  --volume-type gp3 \
  --iops 3000 \          # Baseline for gp3 (can go up to 16,000)
  --throughput 125 \     # Baseline for gp3 (can go up to 1,000 MiB/s)
  --availability-zone $(aws ec2 describe-instances --instance-ids $(curl -s http://169.254.169.254/latest/meta-data/instance-id) --query "Reservations[0].Instances[0].Placement.AvailabilityZone" --output text) \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=gp3-migrated-volume}]'

Verify:

aws ec2 describe-volumes --volume-ids $(aws ec2 describe-volumes --filters "Name=tag:Name,Values=gp3-migrated-volume" --query "Volumes[0].VolumeId" --output text) --query "Volumes[0].{Type:VolumeType,IOPS:Iops,Throughput:Throughput}"

Expected Output:

{
    "Type": "gp3",
    "IOPS": 3000,
    "Throughput": 125
}

Step 4: Detach Old Volume & Attach New gp3 Volume

# Detach old volume
aws ec2 detach-volume --volume-id vol-123456

# Attach new volume (replace /dev/xvda with your device name)
aws ec2 attach-volume --volume-id $(aws ec2 describe-volumes --filters "Name=tag:Name,Values=gp3-migrated-volume" --query "Volumes[0].VolumeId" --output text) --instance-id $(curl -s http://169.254.169.254/latest/meta-data/instance-id) --device /dev/xvda

On the EC2 instance:

# Check if the new volume is attached
lsblk

Expected Output:

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  100G  0 disk
└─xvda1 202:1    0  100G  0 part /

Step 5: Verify Performance

# Install fio (Flexible I/O tester)
sudo yum install -y fio

# Run a quick benchmark (4K random reads)
sudo fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread --bs=4k --direct=1 --size=1G --numjobs=4 --runtime=60 --group_reporting

Expected Output (gp3 vs. gp2):
| Metric | gp2 (300 IOPS) | gp3 (3,000 IOPS) | |--------------|----------------|------------------| | IOPS | ~300 | ~3,000 | | Latency | ~10ms | ~1ms |

Step 6: Clean Up (Optional)

# Delete the old gp2 volume (if you're sure the new one works)
aws ec2 delete-volume --volume-id vol-123456

4. ? Production-Ready Best Practices

? Security

• Encrypt all EBS volumes by default (use AWS KMS).
  bash aws ec2 create-volume --encrypted --kms-key-id alias/aws/ebs ...
• Restrict snapshot sharing (only share with trusted accounts).
  bash aws ec2 modify-snapshot-attribute --snapshot-id snap-123456 --attribute createVolumePermission --operation-type add --user-ids 123456789012
• Enable EBS encryption by default in your AWS account: bash aws ec2 enable-ebs-encryption-by-default

? Cost Optimization

• Use gp3 instead of gp2 (20% cheaper, better performance).
• Delete unused snapshots (they cost $0.05/GB/month).
  bash # Find snapshots older than 30 days aws ec2 describe-snapshots --owner-ids self --query "Snapshots[?StartTime<='$(date -d "30 days ago" -u +"%Y-%m-%d")'].SnapshotId" --output text
• Use st1/sc1 for backups/logs (cheaper than gp3).
• Monitor "EBS:VolumeReadOps" and "EBS:VolumeWriteOps" in CloudWatch to right-size volumes.

? Reliability & Maintainability

• Tag all volumes & snapshots (e.g., Environment=prod, Backup=true).
  bash aws ec2 create-tags --resources vol-123456 --tags Key=Environment,Value=prod
• Automate snapshots with Amazon Data Lifecycle Manager (DLM).
  bash aws dlm create-lifecycle-policy \
--description "Daily snapshots for prod volumes" \
--state ENABLED \
--execution-role-arn arn:aws:iam::123456789012:role/AWSDataLifecycleManagerDefaultRole \
--policy-details '{
"ResourceTypes": ["VOLUME"],
"TargetTags": [{"Key": "Backup", "Value": "true"}],
"Schedules": [{
"Name": "DailySnapshots",
"CreateRule": {"Interval": 24, "IntervalUnit": "HOURS"},
"RetainRule": {"Count": 7},
"CopyTags": true
}]
}'
• Test snapshot restores (don’t assume they work!).

? Observability

• CloudWatch Metrics to Monitor:
• VolumeReadOps / VolumeWriteOps (IOPS usage).
• VolumeQueueLength (if > 1, your volume is throttled).
• BurstBalance (gp2/gp3 only—if < 100%, you’re using burst credits).
• Set up alerts:
  bash aws cloudwatch put-metric-alarm \
--alarm-name "EBS-High-Queue-Length" \
--metric-name VolumeQueueLength \
--namespace AWS/EBS \
--statistic Average \
--period 300 \
--threshold 1 \
--comparison-operator GreaterThanThreshold \
--evaluation-periods 2 \
--alarm-actions arn:aws:sns:us-east-1:123456789012:Alerts

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus (AWS SAA-C03)

Typical Question Patterns

1. "Which EBS volume type is best for a high-performance database?"
2. ✅ io2 (99.999% durability, 64,000 IOPS).

3. ❌ gp3 (good for most workloads, but not high-performance DBs).

4. "You need a cost-effective volume for infrequently accessed logs. Which type?"

5. ✅ st1 (cheap, high throughput for sequential workloads).

6. ❌ sc1 (even cheaper, but too slow for logs).

7. "How do you migrate a gp2 volume to gp3 without downtime?"

8. ✅ Create snapshot → Create gp3 volume → Swap volumes.

9. ❌ "Just change the volume type in the console" (not possible).

10. "What happens if you delete an EBS volume with snapshots?"

11. ✅ Snapshots remain (they’re incremental backups).
12. ❌ "All snapshots are deleted" (common misconception).

⚠️ Key Distinctions

7. ? Hands-On Challenge

Scenario:
You have a gp2 volume (vol-123456) attached to an EC2 instance. Your DB is slow, and you suspect IOPS throttling. Migrate it to gp3 with 5,000 IOPS and verify performance improvement.

Solution:

# 1. Create snapshot
aws ec2 create-snapshot --volume-id vol-123456 --description "Migration to gp3"

# 2. Create gp3 volume from snapshot (5,000 IOPS)
aws ec2 create-volume --snapshot-id snap-123456 --volume-type gp3 --iops 5000 --availability-zone us-east-1a

# 3. Detach old volume, attach new one
aws ec2 detach-volume --volume-id vol-123456
aws ec2 attach-volume --volume-id vol-789012 --instance-id i-1234567890 --device /dev/xvda

# 4. Verify with fio
sudo fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread --bs=4k --direct=1 --size=1G --numjobs=4 --runtime=60 --group_reporting

Why it works:
- gp3 provides baseline 3,000 IOPS (scalable to 16,000).
- Incremental snapshots mean no data loss.
- Zero downtime (detach/attach takes seconds).

8. ? Rapid-Reference Crib Sheet