Amazon EBS: The Ultimate SAA-C03 Study Guide
Amazon Elastic Block Store (EBS) provides high-performance block-storage volumes for use with Amazon EC2 instances. In the world of the SAA-C03 exam, EBS is a fundamental building block for any architecture requiring persistent data that survives instance termination.
The Real-World Analogy
Think of Amazon EBS as a USB Flash Drive or an External SSD. You “plug” it into your computer (EC2 instance) to store files. If you turn off your computer, the data stays on the drive. You can even unplug it and plug it into a different computer, but generally, you can only plug it into one computer at a time (unless it’s a special multi-attach drive).
Core Concepts & Volume Types
EBS volumes are categorized by their underlying storage technology: SSD-backed for transactional workloads and HDD-backed for throughput-intensive workloads.
| Volume Type | API Name | Use Case | Max IOPS |
|---|---|---|---|
| General Purpose SSD | gp3 / gp2 | System boot volumes, virtual desktops, dev/test environments. (gp3 is recommended). | 16,000 |
| Provisioned IOPS SSD | io2 / io1 | Critical business apps, large databases (SAP HANA, Oracle, SQL Server). | 64,000 (up to 256k on Nitro) |
| Throughput Optimized HDD | st1 | Streaming workloads, Big Data, Data Warehousing, Log processing. | 500 |
| Cold HDD | sc1 | Infrequently accessed data, lowest cost. | 250 |
Snapshots and Data Lifecycle
EBS Snapshots are incremental backups. This means only the blocks that have changed since your last snapshot are saved. Snapshots are stored in Amazon S3 (internally), though you cannot access the S3 bucket directly.
- Multi-AZ: EBS volumes are replicated within a single Availability Zone (AZ). To move a volume to another AZ, you must take a snapshot and restore it in the new AZ.
- EBS Data Lifecycle Manager (DLM): An automated way to back up EBS volumes via policies.
- Fast Snapshot Restore (FSR): Eliminates latency of the first read from a restored snapshot (expensive but high performance).
Security and Encryption
Encryption is a high-priority topic for the SAA-C03. EBS encryption uses AWS Key Management Service (KMS) with AES-256.
- Data at rest, data in transit (between instance and volume), and all snapshots are encrypted.
- Encryption is handled at the EC2 instance level (using the instance’s CPU).
- You can enable encryption by default for all new volumes in a region.
Exam Tips and Gotchas
- AZ Lock: An EBS volume is locked to a specific AZ. You cannot attach a volume in us-east-1a to an instance in us-east-1b.
- Termination Policy: By default, the “Root” volume is deleted when the instance is terminated. Additional volumes are kept. This is configurable.
- Multi-Attach: Only
io1andio2volumes support Multi-Attach (attaching one volume to multiple instances in the same AZ). - RAID 0 vs RAID 1: Use RAID 0 for maximum performance (striping); use RAID 1 for mirroring (though EBS is already replicated within an AZ).
Decision Matrix: If-Then Guide
| If the requirement is… | Then choose… |
|---|---|
| Lowest cost for large, sequential data | sc1 (Cold HDD) |
| Database requiring > 16,000 IOPS | io2 (Provisioned IOPS) |
| A boot volume for a web server | gp3 (General Purpose SSD) |
| Big Data MapReduce workloads | st1 (Throughput Optimized) |
Topics covered:
Summary of key subtopics covered in this guide:
- EBS Volume Types (SSD vs HDD)
- EBS Snapshots and Cross-AZ migration
- EBS Encryption via AWS KMS
- Provisioned IOPS vs Throughput
- Multi-Attach capabilities
- EBS Data Lifecycle Manager (DLM)
Amazon EBS Architecture & Ecosystem
Service Ecosystem
IAM: Control who can create/attach volumes.
KMS: Manage encryption keys for data-at-rest.
CloudWatch: Monitor Burst Balance and Throughput.
Scaling & Limits
gp3: Scale IOPS and Throughput independently of storage size.
Elastic Volumes: Increase capacity or change volume type without downtime.
Optimization
Delete on Termination: Avoid “zombie” volumes that cost money.
Cold Storage: Move infrequently accessed data to sc1 to save up to 90% vs SSD.
Production Use Case: High Availability Database
To ensure data durability, use io2 volumes for sub-millisecond latency. Schedule EBS Snapshots every 12 hours via DLM. For disaster recovery, enable Cross-Region Snapshot Copy to automatically replicate backups to a secondary AWS region.