AWS EBS Support
EBS performance troubleshooting: volume, instance or workload.
Disk slowness can come from the volume type limits, an exhausted burst balance, the instance's own EBS bandwidth cap, a volume restored from a snapshot that has not warmed up, or the application's I/O pattern. We measure at both the AWS and OS layers to see which it is.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Database or application latency rises with disk activity
- A gp2, st1 or sc1 volume was fast and became slow
- Restoring from a snapshot makes the first reads very slow
- Provisioned IOPS are paid for but not achieved
- Backups or batch jobs starve production I/O
What you get
- Bottleneck identified: volume, instance, snapshot warm-up or workload
- Volume type, IOPS and throughput recommendation with cost
- Instance type recommendation if the instance limit binds
- Alarms and a dashboard for EBS health
How we do it
A clear, safe process you can follow along with.
1. Capture the symptom from the OS
On Linux we run iostat -x and look at await, queue size and utilization per device, and on Windows we use disk queue and latency counters. This shows whether the device is saturated.
2. Check volume metrics in CloudWatch
We look at VolumeReadOps, VolumeWriteOps, VolumeReadBytes, VolumeWriteBytes, VolumeQueueLength, VolumeTotalReadTime and VolumeTotalWriteTime, and BurstBalance for gp2, st1 and sc1. A flat line at the volume's limit or a BurstBalance near zero means the volume itself is the limit.
3. Check the instance-level limit
Every instance type has its own maximum EBS IOPS and throughput, and smaller or burstable types can cap below what the volumes support. We compare the sum of attached volume activity with the instance limits, and look at the instance EBS exceeded status and burst balance metrics where available.
4. Check for snapshot initialization
Volumes created from snapshots load blocks lazily from S3 on first access, so the first reads are slower. We enable fast snapshot restore for critical restores, or pre-read the volume with fio or dd before production use.
5. Match volume type to workload
We move to gp3 with more IOPS and throughput, or io2 for sustained high IOPS and latency-sensitive databases, st1 for large sequential throughput, rather than relying on gp2 burst behavior. Changes use Elastic Volumes online.
6. Tune the workload and file system
We review I/O size, queue depth, read-ahead, file system and mount options, and database settings. Many apps issue small synchronous writes that cause latency regardless of volume type.
7. Verify under load
We re-run the load or the problem job, compare latency and queue length, and set alarms on queue length, burst balance and latency.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Buying more IOPS when the instance caps below it
The volume cannot go faster than the instance allows.
Ignoring BurstBalance
gp2 and st1 can look fine until credits run out.
Benchmarking a fresh snapshot volume
Results reflect lazy loading, not steady state.
Blaming EBS for an application problem
Lock contention and query plans can show up as disk waits.
Frequently Asked Questions
Why is my EBS volume slow?
Typical causes are volume or instance IOPS and throughput limits, an empty burst balance, snapshot initialization, or an I/O pattern the volume type does not suit.
What is a good VolumeQueueLength?
There is no universal number, but a queue that grows with high latency indicates saturation. Compare it to the IOPS you have provisioned and the workload's needs.
Do EBS volumes get faster when restored from snapshots?
Blocks are fetched from S3 on first access, which is slow, then they run at full speed. Fast snapshot restore or pre-reading avoids the initial penalty.
Want Help With EBS performance troubleshooting: volume, instance or workload?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required