Amazon EBS —
Elastic Block Store
Persistent block storage for EC2 instances. Like a virtual hard drive that persists independently of the instance lifecycle — attach, detach, snapshot, and resize on demand.
⚡ EBS in 30 Seconds
- Block storage — raw disk that an OS reads/writes as a filesystem (like a physical hard drive)
- Attached to one EC2 instance at a time (with multi-attach exceptions for io1/io2)
- AZ-locked — an EBS volume exists in ONE Availability Zone (cannot cross AZs directly)
- Persistent — data survives instance stop/restart. Independent lifecycle from EC2.
- Snapshot to S3 for backup, cross-region copy, or creating new volumes in different AZs
- Volume types: gp3 (default), io2 (high IOPS), st1 (throughput), sc1 (cold archive)
What is EBS
Storage in the cloud comes in three fundamental forms. Each serves different access patterns:
Block Storage (EBS)
Data divided into fixed-size blocks. The OS treats it as a raw disk — formats it with a filesystem (ext4, NTFS) and mounts it. Lowest latency, highest IOPS.
Use: databases, boot drives, apps needing disk I/O
Object Storage (S3)
Stores files as objects with metadata + unique key. No filesystem hierarchy — flat namespace. Access via HTTP API. Unlimited capacity, highly durable.
Use: backups, media, data lakes, static hosting
File Storage (EFS)
Shared filesystem (NFS). Multiple instances can mount simultaneously. Elastic capacity — grows/shrinks automatically. Multi-AZ.
Use: shared config, CMS, containers needing shared state
👉 Key distinction: EBS = personal hard drive (one instance, one AZ, high performance). S3 = infinite filing cabinet (any service, any region, HTTP access). EFS = shared network drive (many instances, many AZs, NFS protocol).
When you launch an EC2 instance, it needs a disk to boot from and store data. But EC2 instances are ephemeral — their local storage (instance store) disappears when the instance stops. EBS solves this by providing a persistent, network-attached disk that survives instance stops, restarts, and even termination (if configured).
Without EBS (Instance Store)
- Storage is physically on the host machine
- Data lost if instance stops or terminates
- Cannot detach or reattach
- Cannot snapshot
- Size fixed at launch
Like a whiteboard — data exists only while you're standing there.
With EBS
- Network-attached persistent storage
- Data survives stop/restart/terminate (configurable)
- Can detach from one instance and attach to another
- Can snapshot to S3 for backup
- Can resize without downtime
Like an external hard drive — unplug it, plug it into another machine, data is still there.
Think of EBS like a USB external hard drive for your cloud server:
Attach/Detach
Plug it into one computer at a time. Unplug and move to another. The data stays on the drive.
Snapshot
Like cloning the entire drive to a backup. You can create a new drive from that backup anywhere.
AZ = Building
The drive exists in ONE building (AZ). To move it to another building, you must snapshot it first, then restore in the new location.
👉 Critical rule: An EBS volume lives in exactly one AZ. An EC2 instance in us-east-1a cannot attach a volume in us-east-1b. To move data across AZs, you must snapshot → create new volume in target AZ. This is the #1 EBS architectural constraint.
🐳 Container note: EBS is not supported on Fargate (ECS Fargate has ephemeral storage + EFS only). For ECS on EC2, you can mount EBS volumes via task definition volume mappings. For Kubernetes (EKS), use the EBS CSI driver to dynamically provision EBS volumes as PersistentVolumes.
| Feature | EBS | S3 | EFS |
|---|---|---|---|
| Storage type | Block | Object | File (NFS) |
| Access | One EC2 (mostly) | Any service, HTTP API | Many EC2 simultaneously |
| Scope | Single AZ | Regional (cross-AZ) | Regional (Multi-AZ) |
| Persistence | Independent of EC2 | Always persistent | Always persistent |
| Capacity | Provisioned (1GB–64TB) | Unlimited | Elastic (auto-grows) |
| Performance | Highest IOPS (up to 256K) | High throughput, high latency | Good throughput, moderate IOPS |
| Latency | Sub-millisecond | Milliseconds (HTTP) | Low milliseconds (NFS) |
| Best for | Databases, boot volumes, apps | Backups, media, data lakes | Shared files, CMS, containers |
| Pricing | Per GB provisioned + IOPS | Per GB stored + requests | Per GB stored |
EBS volume MUST be in the same AZ as the EC2 instance. Network-attached via AWS internal fabric.
EBS = persistent block storage, attached to one EC2, locked to one AZ.
- Block storage — OS formats and mounts it as a filesystem. Lowest latency of all AWS storage types.
- Persistent — data survives instance stop/restart. Lifecycle independent of EC2 (configurable).
- AZ-locked — volume lives in ONE AZ. Cannot cross AZs directly. Use snapshots to move data.
- Network-attached — physically separate from EC2 hardware (unlike instance store). Small network hop.
- Mental model: External hard drive. Plug into one computer. Snapshot = clone. Different building = must clone first.
- vs S3: EBS = disk for one instance. S3 = infinite storage for any service. Different tools for different jobs.
Core Concepts
An EBS volume is a durable, block-level storage device that you attach to a single EC2 instance. Once attached, the OS sees it as a raw disk device (e.g., /dev/xvdf). You format it with a filesystem, mount it, and read/write to it like any local drive — except the data persists even if the instance is stopped or terminated.
Volume Properties
- Size: 1 GiB – 64 TiB (depends on type)
- Type: gp3, io2, st1, sc1 (determines performance)
- AZ: Fixed at creation time (cannot move)
- State: available (unattached) or in-use (attached)
- Encryption: optional, uses KMS
- Device name: /dev/xvda (root), /dev/xvdf+ (additional)
Key Behaviors
- Can resize while attached (no downtime — elastic resize)
- Can change type while attached (gp2 → gp3, etc.)
- Can increase IOPS/throughput without detaching
- Can attach multiple volumes to one instance
- Instance sees volumes as separate block devices
- Billed even when unattached (you own the capacity)
Every EC2 instance has at least one EBS volume — the root volume. You can attach more as additional volumes. They behave differently:
| Feature | Root Volume (/dev/xvda) | Additional Volumes (/dev/xvdf+) |
|---|---|---|
| Contains | Operating system (boot partition) | Application data, databases, logs |
| Created | Automatically with instance launch | Manually created and attached |
| Delete on Termination | YES by default (⚠️ data lost!) | NO by default (data preserved) |
| Detachable? | Only after stopping instance | Yes, while instance is running |
| Typical size | 8–30 GiB (OS only) | 10 GiB – 16 TiB (app-dependent) |
| Encryption | Optional (set at launch) | Optional (set at creation) |
🚨 Critical Warning — Delete on Termination: The root volume is deleted by default when you terminate an instance. If you stored important data on the root volume and terminate the instance — that data is gone permanently (unless you have a snapshot). Always set DeleteOnTermination: false for root volumes with important data, or better — store application data on separate additional volumes.
Attach
- Volume must be in same AZ as instance
- Volume must be in available state
- Specify device name (/dev/xvdf)
- One volume → one instance (usually)
- After attach: format + mount in OS
Detach
- Unmount first in the OS (avoid corruption)
- Additional volumes: detach while running
- Root volume: must stop instance first
- After detach: volume returns to "available"
- Data is preserved on the volume
Reattach
- Attach to a different instance (same AZ)
- Common for: maintenance, upgrading instances
- Data is intact — just mount again
- Like unplugging USB and plugging elsewhere
- ⚠️ Cannot attach to instance in different AZ
EBS volumes have an independent lifecycle from EC2 instances. Understanding this prevents data loss:
| Instance Event | Root Volume (default) | Additional Volumes (default) |
|---|---|---|
| Instance Stop | ✅ Data preserved | ✅ Data preserved |
| Instance Restart | ✅ Data preserved | ✅ Data preserved |
| Instance Terminate | ⚠️ DELETED (default!) | ✅ Data preserved (stays available) |
| Instance Hibernate | ✅ RAM dumped to root EBS | ✅ Data preserved |
👉 Best practice: Never store important application data on the root volume. Use separate EBS volumes for databases, user uploads, and application state. This way, even if you terminate the instance accidentally, your data survives.
What You CAN Do
- Increase size while attached (no detach needed)
- Change volume type (gp2 → gp3, gp3 → io2, etc.)
- Increase IOPS/throughput (for gp3, io2)
- Resize completes in background (may take hours for large volumes)
- After resize: extend filesystem in OS (
xfs_growfs,resize2fs)
What You CANNOT Do
- Cannot decrease size — ever (must create smaller volume from snapshot)
- Cannot resize more than once per 6 hours (cooldown period)
- Must wait for "optimizing" state to complete before next modification
- Filesystem extension is not automatic — you must run OS commands
Beyond the "Delete on Termination" flag, you can protect volumes from accidental deletion using IAM policies and tagging strategies:
👉 Protection strategies: ① Set DeleteOnTermination: false for all critical volumes. ② Use IAM policies with ec2:DeleteVolume conditions to restrict deletion to specific roles. ③ Tag critical volumes (Protected=true) and use tag-based IAM conditions. ④ Enable AWS Backup Vault Lock for immutable backups that cannot be deleted even by root.
Normally: 1 volume = 1 instance. But io1/io2 volumes support Multi-Attach — up to 16 instances can read/write the same volume simultaneously. This is used for clustered applications that need shared block-level storage.
Multi-Attach Requirements
- Only io1 and io2 volume types
- All instances must be in same AZ
- Maximum 16 instances simultaneously
- Must use cluster-aware filesystem (not ext4!)
- Application must manage concurrent access
Multi-Attach Limitations
- NOT available for gp3, st1, sc1
- Does NOT work across AZs
- Requires application-level concurrency control
- Cannot use standard filesystems (ext4, XFS)
- Windows: requires WSFC (Failover Cluster) — NTFS cannot handle concurrent writes
- Complex — most apps should use EFS instead
Best practice: separate root (OS) from data. Root can be deleted on terminate — data volumes persist independently.
EBS volumes have independent lifecycles — create, attach, detach, reattach, snapshot, delete.
- Root volume = OS disk. Deleted on terminate by default (⚠️). Always separate data to additional volumes.
- Additional volumes = data disks. Preserved on terminate by default. Can be detached/reattached freely.
- Lifecycle: Creating → Available (unattached) → In-Use (attached) → Available (detach) → Deleted
- Resize: You can increase size, change type, and adjust IOPS/throughput while the volume is attached (no downtime).
- Multi-Attach: io1/io2 only. Up to 16 instances can share one volume. Requires cluster-aware filesystem.
- Billing: You pay for provisioned capacity even when unattached. Delete unused volumes to save costs.
Volume Types
EBS offers four volume types in two categories. The choice depends on your workload's I/O pattern — whether it needs fast random reads (IOPS) or fast sequential reads (throughput):
SSD-Backed (Random I/O)
Optimized for small, random reads/writes (IOPS). Think database queries, boot volumes, app servers.
- gp3 / gp2 — General purpose (default)
- io2 / io1 — Provisioned IOPS (highest performance)
HDD-Backed (Sequential I/O)
Optimized for large, sequential reads/writes (throughput). Think log processing, big data, streaming.
- st1 — Throughput Optimized (frequent access)
- sc1 — Cold HDD (infrequent access, cheapest)
👉 Rule of thumb: SSD types can be boot volumes. HDD types cannot be boot volumes. If the question asks about a boot volume — the answer is always gp3/gp2 or io2/io1, never st1/sc1.
| Feature | gp3 | io2 Block Express | st1 | sc1 |
|---|---|---|---|---|
| Category | General Purpose SSD | Provisioned IOPS SSD | Throughput HDD | Cold HDD |
| Max Size | 16 TiB | 64 TiB | 16 TiB | 16 TiB |
| Max IOPS | 16,000 | 256,000 | 500 | 250 |
| Max Throughput | 1,000 MB/s | 4,000 MB/s | 500 MB/s | 250 MB/s |
| Baseline IOPS | 3,000 (included free) | You provision (100–256K) | N/A (throughput-based) | N/A (throughput-based) |
| Boot volume? | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
| Multi-Attach? | ❌ No | ✅ Yes (up to 16) | ❌ No | ❌ No |
| Pricing | $0.08/GB-month | $0.125/GB + $0.065/IOPS | $0.045/GB-month | $0.015/GB-month |
| Best for | Most workloads (default) | Databases needing guaranteed I/O | Big data, log processing | Archive, infrequent access |
gp3 is the recommended default for most workloads. It replaced gp2 as the go-to volume type because it offers better baseline performance at 20% lower cost, and lets you independently tune IOPS and throughput.
gp3 Advantages
- 3,000 IOPS baseline — included free regardless of size
- 125 MB/s throughput — included free baseline
- Independent IOPS scaling: up to 16,000 (pay extra)
- Independent throughput: up to 1,000 MB/s (pay extra)
- 20% cheaper per GB than gp2
- No burst credits — consistent performance
gp3 vs gp2
- gp2: IOPS scales with size (3 IOPS/GB)
- gp3: IOPS independent of size (3K baseline free)
- gp2: uses burst credits (unpredictable)
- gp3: no burst model (consistent)
- gp2: $0.10/GB · gp3: $0.08/GB
- Verdict: Always use gp3 for new volumes
gp2 burst credits: gp2 earns credits when idle, can burst to 3K IOPS temporarily. Baseline = size × 3 (e.g., 100GB = 300 IOPS). Credits exhaust → throttled. gp3 eliminates this entirely — 3K IOPS always, no credits.
When your workload needs guaranteed, consistent IOPS (databases like Oracle, SAP, or Cassandra that are IOPS-sensitive), io2 is the answer. You explicitly provision the IOPS you need — and AWS guarantees delivery.
io2 Key Features
- Up to 256,000 IOPS (Block Express on Nitro)
- Up to 4,000 MB/s throughput
- 99.999% durability (5 nines — vs 99.8-99.9% for others)
- Multi-Attach supported (clustered databases)
- Provisioned IOPS → you know exactly what you get
- IOPS:GB ratio up to 1000:1 (500:1 for io1)
Cost Warning
- Most expensive EBS type
- $0.125/GB + $0.065 per provisioned IOPS
- Example: 500GB + 10K IOPS = $62.50 + $650 = $712.50/month
- Only use if gp3's 16K IOPS isn't enough
- For most databases: gp3 with 16K IOPS is sufficient
io2 vs io2 Block Express: Regular io2 is limited to 64K IOPS and 16 TiB. Block Express unlocks the full 256K IOPS / 64 TiB / 4 GB/s — but requires specific Nitro instance types.
| Feature | io2 (standard) | io2 Block Express |
|---|---|---|
| Max size | 16 TiB | 64 TiB |
| Max IOPS | 64,000 | 256,000 |
| Max throughput | 1,000 MB/s | 4,000 MB/s |
| Sub-ms latency | Single-digit ms | Sub-millisecond |
| Instance support | All Nitro | r5b, r6i, c6in, i4i, etc. |
| Multi-Attach | Up to 16 | Up to 16 |
👉 Exam tip: If the question says "256K IOPS" or "sub-millisecond latency" → io2 Block Express. If it says "64K IOPS max" → regular io2. Block Express is for the highest-end workloads (SAP HANA, Oracle RAC, large SQL Server).
st1 — Throughput Optimized
- 500 MB/s max throughput
- Baseline: 40 MB/s per TB
- Use for: Hadoop, Kafka, log processing, data warehouses
- $0.045/GB — cheap for large volumes
- Sequential access patterns (not random)
- ❌ Cannot be boot volume
sc1 — Cold HDD
- 250 MB/s max throughput
- Baseline: 12 MB/s per TB
- Use for: infrequent access, archive, backups
- $0.015/GB — cheapest EBS type
- Lowest cost for rarely accessed data
- ❌ Cannot be boot volume
| If your workload needs… | Choose | Why |
|---|---|---|
| General app, boot volume, dev/test | gp3 | Best price/performance, 3K IOPS free |
| Database (MySQL, PostgreSQL) up to 16K IOPS | gp3 (with extra IOPS) | Cheaper than io2 for most databases |
| High-performance database (>16K IOPS) | io2 | Up to 256K IOPS, guaranteed performance |
| Clustered database (shared block storage) | io2 (Multi-Attach) | Only type supporting multi-attach |
| Big data, streaming, log processing | st1 | High sequential throughput, cheap per GB |
| Infrequent access, archive, backups | sc1 | Cheapest EBS — $0.015/GB |
SSD types (gp3, io2) = random I/O, can boot · HDD types (st1, sc1) = sequential I/O, cannot boot
Four volume types, two categories — pick based on IOPS vs throughput needs.
- gp3 — Default for 90% of workloads. 3K IOPS + 125 MB/s free. Boot volume. $0.08/GB. Always start here.
- io2 — When gp3 isn't enough. Up to 256K IOPS. Guaranteed performance. Multi-Attach. 99.999% durable. Expensive.
- st1 — Sequential throughput workloads. 500 MB/s. Hadoop, Kafka, logs. Cannot boot. $0.045/GB.
- sc1 — Cheapest EBS. Cold data, infrequent access. 250 MB/s. Archive. Cannot boot. $0.015/GB.
- SSD vs HDD: SSD = random I/O (IOPS), can boot. HDD = sequential I/O (throughput), cannot boot.
- Exam tip: "Boot volume" → SSD only. "Lowest cost, infrequent" → sc1. ">16K IOPS guaranteed" → io2. "Big data throughput" → st1.
Snapshots & Backups
An EBS snapshot is a point-in-time backup of your volume, stored in S3 (managed by AWS — you don't see the S3 bucket). Snapshots are the primary mechanism for backup, disaster recovery, cross-AZ migration, and cross-region replication of EBS data.
What it Does
- Copies all data from volume to S3
- Creates a restorable backup
- Can create new volumes from snapshot
- Can copy to other regions
- Can share with other AWS accounts
Incremental
- First snapshot = full copy
- Subsequent = only changed blocks
- Saves storage cost significantly
- Each snapshot is still independently restorable
- Delete old snapshots safely — data deduped
Key Behaviors
- Can snapshot while volume is in-use
- Snapshot is async (no downtime)
- Stored in S3 (11 nines durability)
- Regional resource (not AZ-locked)
- You pay for stored data, not provisioned size
👉 Critical insight: Snapshots are regional — not locked to an AZ. This is how you move EBS data across AZs: snapshot in AZ-a → create new volume from snapshot in AZ-b. Snapshots are your escape hatch from AZ-lock.
Create
aws ec2 create-snapshot- From running volume (no detach needed)
- Best practice: flush writes first
- First snap: full copy (slow)
- Subsequent: incremental (fast)
Copy (Cross-Region)
- Copy snapshot to another region
- Enables cross-region DR
- Snapshot is re-encrypted with target region KMS key
- Async — large volumes take time
aws ec2 copy-snapshot --region us-west-2
Restore
- Create new volume from snapshot
- Choose any AZ in the region
- Can change volume type (gp2 → gp3)
- Can change size (increase only)
- First-read penalty: lazy loading from S3
⚠️ Lazy Loading Warning: When you restore a volume from a snapshot, blocks are loaded from S3 on first access. This means the first read of each block is significantly slower. For production databases, use EBS Fast Snapshot Restore (FSR) or pre-warm the volume by reading all blocks with dd or fio before going live.
| Component | Cost | Notes |
|---|---|---|
| Snapshot storage | $0.05/GB-month | Only changed blocks stored (incremental) |
| Fast Snapshot Restore | ~$0.75/hr per AZ | Pre-initializes volume — eliminates lazy load |
| Cross-region copy | Data transfer + snapshot storage | First copy is full; subsequent is incremental |
| Snapshot Archive | $0.0125/GB-month (75% cheaper) | Minimum 90-day retention. Restore takes 24-72h. |
Fast Snapshot Restore (FSR)
- Pre-initializes volume blocks — eliminates lazy loading entirely
- Cost: ~$0.75/hr per AZ per snapshot (expensive!)
- Example: 1 snapshot × 3 AZs × 720 hrs = ~$1,620/month
- Use for: production databases where first-read latency is unacceptable
- NOT for: dev/test or workloads that can tolerate initial warm-up
Snapshot Archive Tier
- 75% cheaper than standard ($0.0125 vs $0.05/GB-month)
- Minimum retention: 90 days (charged for full 90 days even if restored earlier)
- Restore time: 24–72 hours (not instant!)
- Use for: compliance archives, long-term backups, rarely needed data
- NOT for: DR, frequent restores, or any time-sensitive recovery
Data Lifecycle Manager (DLM)
- Automate snapshot creation on schedule
- Tag-based: "backup all volumes tagged env=prod"
- Retention policies: keep last N snapshots
- Cross-region copy policies
- Free service (pay only for snapshot storage)
AWS Backup
- Centralized backup across all AWS services
- EBS, RDS, DynamoDB, EFS, S3 in one place
- Backup plans with schedules + retention
- Cross-region and cross-account backup
- Compliance: audit trail + vault lock
Volume (AZ-locked) → Snapshot (regional, S3-stored) → Restore in any AZ, or copy to another region for DR
Snapshots = your escape from AZ-lock. Backup, copy, restore anywhere.
- Snapshot = point-in-time backup to S3. Regional resource (not AZ-locked). Independently restorable.
- Incremental — only changed blocks stored after first full backup. Each snapshot still fully restorable.
- Cross-AZ: Snapshot in AZ-a → Restore as new volume in AZ-b. The only way to move EBS data across AZs.
- Cross-region: Copy snapshot to another region for disaster recovery.
- Lazy loading: Restored volumes load blocks from S3 on first access. Use FSR for production databases.
- Automation: Use DLM or AWS Backup for scheduled snapshots with retention policies.
- Snapshot Archive: 75% cheaper storage for snapshots you rarely restore (minimum 90 days).
Performance & Optimization
EBS performance is measured in two independent dimensions. Understanding the difference is critical for right-sizing your volumes:
IOPS (Input/Output Operations Per Second)
- Number of read/write operations per second
- Each operation = one block (up to 256 KiB for SSD)
- Measures random access speed
- Critical for: databases, transaction processing
- Analogy: how many times per second you can open a filing cabinet drawer
Throughput (MB/s)
- Amount of data transferred per second
- Measures sequential read/write speed
- Critical for: streaming, big data, log processing
- Can be limited by IOPS × block size
- Analogy: how many pages per second you can read from a book
👉 Key formula: Throughput = IOPS × I/O size. For gp3: 3,000 IOPS × 256 KiB = 750 MB/s theoretical. But gp3 is capped at 1,000 MB/s throughput and 16,000 IOPS — whichever limit you hit first becomes the bottleneck.
| Parameter | Baseline (Free) | Max (Extra Cost) | Cost to Add |
|---|---|---|---|
| IOPS | 3,000 | 16,000 | $0.005 per provisioned IOPS above 3K |
| Throughput | 125 MB/s | 1,000 MB/s | $0.040 per provisioned MB/s above 125 |
| Size | 1 GiB | 16 TiB | $0.08 per GB-month |
The game-changer with gp3: IOPS, throughput, and size are all independent. You can have a tiny 20GB volume with 16,000 IOPS — impossible with gp2 (which ties IOPS to size). This lets you right-size for cost.
Even if your EBS volume supports 256K IOPS, your EC2 instance might not. Each instance type has maximum EBS bandwidth. If the instance can only push 4,750 Mbps to EBS, you'll never see 256K IOPS regardless of volume config.
| Instance Type | Max EBS Bandwidth | Max EBS IOPS | EBS Optimized |
|---|---|---|---|
| t3.micro | 2,085 Mbps | 11,800 | Yes (burst) |
| m5.large | 4,750 Mbps | 18,750 | Yes |
| m5.xlarge | 4,750 Mbps | 18,750 | Yes |
| r6i.2xlarge | 10,000 Mbps | 40,000 | Yes |
| r6i.8xlarge | 40,000 Mbps | 160,000 | Yes |
| r6i.metal | 80,000 Mbps | 260,000 | Yes |
⚠️ Common mistake: Provisioning io2 with 100K IOPS on a t3.large instance. The instance can only do ~18K IOPS — you'll pay for 100K but get 18K. Always check instance EBS limits before provisioning high-IOPS volumes.
EBS-Optimized means the instance has dedicated bandwidth between EC2 and EBS, separate from network traffic. Without it, EBS and network compete for the same pipe.
Modern Instances (Default)
- t3, m5, r5, c5, r6i — EBS-optimized by default
- Dedicated EBS bandwidth (5–80 Gbps depending on size)
- No additional cost — included in instance price
- All Nitro-based instances are EBS-optimized
Older Instances
- t2, m4, c4 — must enable EBS optimization manually
- Additional hourly fee when enabled
- Without it: EBS + network share bandwidth → unpredictable I/O
- Recommendation: Use modern Nitro instances to avoid this
RAID 0 (Striping)
- Combine multiple volumes for more IOPS + throughput
- 4 × gp3 volumes = up to 64K IOPS combined
- No redundancy — if one volume fails, data is lost
- Use when: need more performance than single volume max
- Exception case — usually gp3/io2 is enough alone
RAID 1, 5, 6 — Not Recommended
- RAID 1 (mirror): wasteful — EBS already replicates within AZ
- RAID 5/6: parity writes consume IOPS — terrible performance
- AWS explicitly advises against RAID 5/6 on EBS
- For redundancy: use snapshots, not RAID
Performance = min(app capability, EC2 EBS bandwidth, volume IOPS/throughput). All three must be sized correctly.
Two dimensions: IOPS (random speed) × Throughput (sequential speed). Right-size all three: app, instance, volume.
- IOPS = operations per second (databases). Throughput = MB/s (big data, streaming).
- gp3 tuning: 3K IOPS + 125 MB/s free. Scale independently up to 16K IOPS / 1 GB/s.
- Instance limits: EC2 type caps EBS bandwidth. Don't provision 100K IOPS on a t3.large.
- Three bottlenecks: app I/O pattern → EC2 EBS bandwidth → volume IOPS/throughput. All must align.
- RAID 0 only: Stripe volumes for more IOPS. Never RAID 5/6 on EBS (AWS advises against it).
- Cost optimization: Use io2 only for IOPS-critical data. Use gp3 for everything else. Mix volume types per workload.
Security & Encryption
EBS encryption provides at-rest encryption for your volumes, snapshots, and data in transit between EC2 and EBS — all using AWS KMS keys. When you enable encryption, everything is handled transparently: the OS doesn't know the disk is encrypted, and there's minimal performance impact.
What Gets Encrypted
- Data at rest on the volume (all blocks)
- Data in transit between EC2 and EBS
- All snapshots created from the volume
- All volumes restored from encrypted snapshots
- Encryption is end-to-end — never leaves AWS in plaintext
How It Works Internally
- Uses AES-256 encryption algorithm
- AWS generates a Data Encryption Key (DEK) per volume
- DEK is encrypted by your KMS Customer Master Key (CMK)
- Encryption/decryption happens on the EC2 host (Nitro hardware)
- Minimal latency impact — hardware-accelerated on Nitro instances
👉 Key insight: EBS encryption is free — no additional charge for encrypting volumes. You only pay for KMS key usage (a few cents per 10,000 API calls). There is no reason NOT to encrypt. AWS recommends encryption for all production volumes.
| Key Type | Name | Who Manages | Cost | Use Case |
|---|---|---|---|---|
| AWS managed | aws/ebs | AWS (auto-created) | Free | Default — simplest option |
| Customer managed | Your CMK | You (create in KMS) | $1/month + API calls | Cross-account sharing, custom rotation |
| Custom key store | CloudHSM-backed | You (own HSM cluster) | $$$ | Regulatory / compliance (FIPS 140-2 L3) |
When to Use Customer Managed Keys
- Cross-account snapshot sharing — AWS managed keys can't be shared
- Key rotation control — set your own rotation schedule
- Key policies — fine-grained access control (who can use/manage the key)
- Audit trail — CloudTrail logs every key usage
- Disable/delete key — render all encrypted data unreadable
Encryption Gotchas
- Cannot un-encrypt an encrypted volume in-place
- To remove encryption: snapshot → copy (unencrypted) → create new volume
- Cannot change KMS key on existing volume — must snapshot + re-create
- Encrypted volumes can only be attached to supported instance types (all Nitro)
- Cross-region snapshot copy requires re-encryption with target region's key
AWS lets you enable encryption by default at the account level per region. When enabled, every new EBS volume is automatically encrypted — no one can forget.
👉 Best practice: Enable "EBS encryption by default" in every region you use. This ensures 100% of new volumes are encrypted. Settings → EBS encryption → Enable. You can choose the default KMS key (aws/ebs or your CMK). This is a one-time setting per account per region.
You cannot encrypt an existing unencrypted volume in-place. The process requires creating a new encrypted copy:
Step-by-Step Process
- 1. Create snapshot of unencrypted volume
- 2. Copy snapshot → enable encryption (select KMS key)
- 3. Create new volume from encrypted snapshot
- 4. Detach old volume, attach new encrypted volume
- 5. Delete old unencrypted volume + snapshot
Why This Approach?
- EBS can't re-encrypt existing blocks in-place
- Each block must be read, encrypted, written to new location
- Snapshot copy handles this transparently
- Brief downtime required (detach → attach swap)
- Snapshot remains unencrypted — delete after migration
KMS provides the key → EC2 Nitro handles encryption/decryption on the host → Data encrypted at rest on EBS and in snapshots (S3)
EBS encryption is free, transparent, and should be on for every volume.
- AES-256 encryption — at rest, in transit, and snapshots. Hardware-accelerated on Nitro (minimal perf impact).
- KMS keys: AWS managed (free, simplest) or Customer managed ($1/mo, cross-account sharing, custom policies).
- Enable by default: Account → EBS settings → Encryption by default. Every new volume auto-encrypted.
- Cannot un-encrypt in-place. Must: snapshot → copy (encrypted) → create new volume → swap.
- Cross-region: Snapshot copy re-encrypts with target region's KMS key.
- Exam tip: "Encrypt at rest with minimal effort" → EBS encryption + KMS. "Cross-account encrypted snapshot" → Customer managed CMK.
Architecture Patterns
Architecture
- Single EC2 instance
- gp3 root volume (OS + app code)
- gp3 data volume (user uploads, SQLite/file-based DB)
- Daily DLM snapshots
When to Use
- Small apps, personal projects
- Low traffic (no scaling needed)
- Simple backup with snapshots
- Budget-conscious deployments
Architecture
- EC2 (r-class, EBS-optimized)
- gp3 for OS (20 GB, 3K IOPS)
- io2 for data files (high IOPS, Multi-Attach for clustering)
- gp3 for WAL/redo logs (tuned IOPS)
- st1 for backups/staging (cheap throughput)
- Automated snapshots with cross-region copy
When NOT to Use
- If RDS supports your DB engine — use RDS instead
- Self-managed = you handle HA, backups, patching
- Only for: engines not in RDS, need OS-level access, custom clustering
- Default recommendation: always try RDS first
EBS is AZ-locked, so HA requires replication across AZs via snapshots or application-level replication:
Snapshot-Based HA
- Primary EC2 + EBS in AZ-a
- Frequent snapshots (every 15-60 min)
- On failure: restore snapshot in AZ-b → launch new EC2
- RPO: last snapshot (15-60 min data loss)
- RTO: 10-30 min (restore + launch + warm)
- Cheapest HA option
Replication-Based HA
- Primary + standby EC2 in different AZs
- App-level sync (PostgreSQL streaming replication, DRBD)
- Each instance has its own EBS volumes
- RPO: near-zero (synchronous replication)
- RTO: seconds to minutes (failover)
- Double the cost (2× EC2 + 2× EBS)
| Scenario | Method | Steps |
|---|---|---|
| Move volume to different AZ | Snapshot + restore | Snapshot → Create volume in new AZ → Attach |
| Copy data to another region | Snapshot + copy + restore | Snapshot → Copy to target region → Create volume |
| Upgrade instance type | Detach + reattach | Stop instance → Detach EBS → Launch new instance → Attach |
| Encrypt existing volume | Snapshot + encrypted copy | Snapshot → Copy (enable encrypt) → Create encrypted volume |
| Change volume type | Modify volume (in-place) | aws ec2 modify-volume → no detach needed |
EC2 + encrypted EBS → DLM snapshots → Cross-region DR copy · KMS for keys · CloudWatch for monitoring · AWS Backup for compliance
| If the exam says… | Answer |
|---|---|
| "Persistent block storage for EC2" | EBS |
| "Boot volume" | gp3 or io2 (SSD only — not st1/sc1) |
| "Highest IOPS, guaranteed" | io2 Block Express (up to 256K) |
| "Default volume for most workloads" | gp3 |
| "Cheapest storage, infrequent access" | sc1 ($0.015/GB) |
| "Big data throughput, sequential" | st1 |
| "Move volume to different AZ" | Snapshot → create in new AZ |
| "Encrypt existing unencrypted volume" | Snapshot → copy (encrypt) → new volume |
| "Share data between multiple EC2" | EFS (not EBS — unless io2 Multi-Attach) |
| "Temporary high-IOPS local storage" | Instance Store (not EBS) |
| "Cross-region DR for EBS" | Snapshot → cross-region copy |
| "Delete on Termination risk" | Root volume: YES by default (⚠️) |
EBS patterns range from simple single-volume apps to multi-AZ HA database clusters.
- Simple app: EC2 + gp3 root + gp3 data + daily snapshots. Cheapest pattern.
- Database: Mix volume types — io2 for data, gp3 for WAL/OS, st1 for backups. Use RDS if possible.
- Multi-AZ HA: Snapshot-based (cheapest, 15-60 min RPO) or replication-based (near-zero RPO, 2× cost).
- Migration: Snapshot is the universal tool — cross-AZ, cross-region, encrypt, resize, change type.
- Decision guide: Block storage = EBS. Shared files = EFS. Objects = S3. Temp/scratch = Instance Store.
- Production stack: Encrypted EBS + DLM snapshots + cross-region DR + CloudWatch monitoring + AWS Backup compliance.