Amazon EBS
Block-level storage volumes for use with EC2 instances
EBS is like a hard drive for your EC2 instances, except it's not physically attached; it's connected over a super-fast network. When you launch an EC2 instance, you need somewhere to store the operating system and your data. That's EBS. It acts just like a regular hard drive: you can format it, partition it, install software on it. The cool part? You can detach it from one instance and attach it to another, like unplugging a USB drive and plugging it into a different computer. And you can take snapshots (backups) anytime, storing them in S3 for disaster recovery.
EBS provides block-level storage volumes that attach to EC2 instances via the network. Each volume is automatically replicated within its Availability Zone for durability. EBS offers multiple volume types: gp3 (general purpose SSD, best price/performance), io2 (provisioned IOPS SSD for databases), st1 (throughput-optimized HDD for big data), and sc1 (cold HDD for infrequent access).
Key Capabilities
Key configurations: volume size, IOPS, throughput, and encryption (uses KMS).
Gotchas & Constraints
Gotcha #1: EBS volumes are AZ-specific; you can't attach a volume in us-east-1a to an instance in us-east-1b. To move data across AZs, create a snapshot and restore it in the target AZ. Gotcha #2: Root volumes are deleted when instances terminate by default; set DeleteOnTermination=false to preserve data. Constraints: Maximum volume size is 64TB (gp3/io2) or 16TB (st1/sc1). IOPS and throughput limits depend on volume type and instance type; even a high-IOPS volume won't perform well on a small instance.
A database server runs PostgreSQL on an EC2 instance with a 2TB io2 EBS volume provisioned for 10,000 IOPS. The database handles 5,000 transactions per second, requiring consistent low-latency storage. They enable EBS encryption for compliance and take automated snapshots every 6 hours using AWS Backup. When the database grows to 1.8TB, they use EBS Elastic Volumes to increase the volume size to 3TB without downtime, with no need to stop the instance or detach the volume. During a disaster recovery drill, they restore a snapshot to a new volume in a different AZ, attach it to a standby instance, and verify data integrity. For cost optimization, they use gp3 volumes for non-critical workloads (dev/test databases), saving 20% vs. gp2 while maintaining performance.