AWS Block Storage: EBS & Instance Store
In the AWS ecosystem, block storage provides the raw storage volumes that can be formatted and used by EC2 instances as hard drives. Understanding the trade-offs between persistent network storage (EBS) and temporary local storage (Instance Store) is critical for the SAA-C03 exam.
The Analogy: The Hotel Safe vs. The Nightstand
Imagine staying at a hotel. Amazon EBS is like the Hotel Safe: You can put your valuables in it, leave the hotel (stop the instance), and when you come back or move to a different room (attach to another instance), your belongings are still there. It is persistent and independent.
Amazon Instance Store is like the Nightstand Drawer: It’s physically right next to the bed (high speed), but the moment you check out of the room (stop/terminate the instance), the hotel staff clears the drawer completely. It is ephemeral and tied to the physical hardware.
Core Concepts & The Well-Architected Framework
Reliability & Sustainability
EBS volumes are designed for 99.999% availability and replicate data within an Availability Zone (AZ). For true disaster recovery, EBS Snapshots (stored in S3) allow you to recreate volumes across different AZs or Regions.
Performance Efficiency
AWS offers different volume types to match performance needs. SSD-backed volumes (gp3, io2) are optimized for transactional workloads and high IOPS, while HDD-backed volumes (st1, sc1) are optimized for large, sequential throughput like log processing or data warehousing.
Service Comparison Table
| Feature | Amazon EBS (SSD/HDD) | EC2 Instance Store |
|---|---|---|
| Persistence | Survives instance stop/termination | Lost on instance stop/termination |
| Connection | Network-attached (via AWS network) | Physically attached to host |
| Performance | High (up to 256k IOPS with io2 Block Express) | Ultra-low latency / Highest IOPS |
| Backups | Snapshots (Incremental to S3) | Manual (Must copy data to S3/EBS) |
| Usage | Boot volumes, Databases, Long-term storage | Cache, Buffers, Scratch data, Temp files |
Scenario-Based Decision Matrix
- If you need data to persist after an instance is stopped: Use EBS.
- If you need the absolute lowest latency for a NoSQL database cache: Use Instance Store.
- If you need a boot volume for your EC2 instance: Use EBS.
- If you need to scale throughput without increasing storage capacity: Use EBS gp3.
Exam Tips: Golden Nuggets
- Termination Protection: By default, the root EBS volume is deleted when the instance is terminated. You must change the
DeleteOnTerminationflag to ‘false’ to keep it. - Instance Store Limitations: You cannot “stop” an instance that uses Instance Store as the root volume; you can only Reboot or Terminate.
- EBS Multi-Attach: Only
io1/io2volumes support Multi-Attach, allowing multiple Nitro-based instances to attach to the same volume simultaneously. - Snapshots: Snapshots are incremental. The first one is a full copy; subsequent ones only store changed blocks.
Architectural Flow: Block Storage
Key Services
gp3: General purpose SSD. Balance of price/performance. Decoupled IOPS/Throughput.
io2: Provisioned IOPS. For mission-critical apps (SAP HANA, Oracle).
Common Pitfalls
Assuming Instance Store is safe for DB data. It is NOT. If the hardware fails or the instance stops, data is gone forever.
Quick Patterns
Snapshotting: Always snapshot before resizing a volume.
RAID 0: Use for maximum IOPS across multiple EBS volumes.