EBS DevOps Guide
How to run Elastic Block Store well in production
If you want to learn about EBS in the context of RDS, instead of this guide, see RDS DevOps Guide.
There are two types of SSD-backed general-purpose volumes: gp2 and gp3. Use gp3: they’re cheaper, both in absolute terms, and for a given level of performance. Price aside, gp3 is faster, with a minimum IOPS of 3000, as compared to 100 for gp2. Not only is gp3 faster but more consistent: while gp2 can burst to 3000 iops for a while, gp3 can sustain that performance indefinitely.
Don’t use Provisioned IOPS volumes, since they’re like 30x costlier, unless you’re running something extremely high performance, which is not the case for most startups.
You can increase the space, IOPS or throughput of a volume separately, depending on where you’re facing a bottleneck. You can do this live.
An unloaded EBS volume should have both read and write latencies < 1 ms.
You can increase but not decrease the size of an EBS volume. So, if you’re in doubt about what size you should use, err on the lower side.
Volumes should be attached to instances in the same availability zone.
By default, the free space in EBS volumes isn’t tracked, risking an outage. To prevent this, install the CloudWatch agent in your VMs, and set an alarm if disk_free < 10 GB.
Detect swapping by monitoring the swap_used_percent metric. With sufficient memory, this should be a single-digit percentage.
You can take a snapshot of a volume. This is fast and doesn’t disrupt ongoing activity. Snapshots are stored in S3.