Key Amazon EBS Metrics to Monitor

The key Amazon EBS metrics to monitor cover reads, writes, latency, queue depth, idle time, and, on credit-based volume types, burst balance. Every EBS volume attached to an EC2 instance already reports them to CloudWatch with no opt-in. EBS metrics open up a storage layer that an observability setup otherwise sees only through application latency. The value lies in knowing which ones to graph, which to alarm on, and how the answer changes between a gp2 boot volume and an io2 database volume.

This guide covers the core EBS metrics and how to interpret each one, the newer per-minute metrics AWS added to expose micro-bursting, and which metrics to prioritize for each volume type.

What Is Amazon EBS?

Amazon Elastic Block Store (EBS) provides block-level volumes that attach to EC2 instances and persist independently, which suits databases, file systems, and anything else that needs durable disk storage. AWS sells six current-generation volume types across two media.

The SSD types are gp2, gp3, io1, and io2, and AWS now delivers io2 as io2 Block Express. The HDD types, st1 and sc1, handle large sequential reads for workloads such as log processing and rarely scanned cold data, and AWS steers small random I/O to SSD.

How Does CloudWatch Track EBS Metrics?

CloudWatch tracks EBS volume metrics in the AWS/EBS namespace at one-minute resolution for every volume type, at no charge, from the moment the volume is attached to an instance. EC2 Detailed Monitoring is an instance-level setting that moves EC2 metrics from five-minute to one-minute periods for a fee and doesn't affect EBS volumes, so you don't need it for EBS data.

Instance architecture decides how much of this telemetry data you can see. On AWS Nitro instances, Minimum and Maximum statistics become meaningful on the core metrics, the AWS/EC2 namespace adds instance-wide EBS aggregates such as EBSReadOps and the EBSIOBalance% bucket, and the per-minute metrics covered later publish only for Nitro-attached volumes.

What Are the Core EBS Metrics to Monitor?

The core EBS metrics to monitor cover IOPS, throughput, latency, queue depth, idle time, and burst credits, and the table maps each to its CloudWatch metric, unit, and the volume types that publish it:

1. IOPS from VolumeReadOps and VolumeWriteOps

IOPS shows whether a workload is reaching the volume's operation ceiling. VolumeReadOps and VolumeWriteOps count completed operations per period, so IOPS = Sum(VolumeReadOps) / Period plus the write equivalent, or (m1 + m2) / 60 in metric math at a one-minute period. Compare the combined read and write rate with the maximum IOPS per volume for each type:

• gp2: The ceiling is 16,000 IOPS.
• gp3: The ceiling is 80,000 IOPS.
• io1: The ceiling is 64,000 IOPS.
• io2 Block Express: The ceiling is 256,000 IOPS.

Volumes reach 256,000 IOPS only on Nitro instances; other instance types top out at 32,000 IOPS, even on volumes provisioned higher. Driving a volume past its available IOPS raises I/O latency, which shows up first in the application.

2. Throughput from VolumeReadBytes and VolumeWriteBytes

Throughput shows whether a workload is reaching a bandwidth ceiling. VolumeReadBytes and VolumeWriteBytes total the bytes moved, and Sum / Period / 1024 converts either to KiB/s. Two ceilings apply and both bind, the per-volume cap and the instance's EBS-optimized bandwidth. The per-volume caps are:

• SSD volume caps: gp2 tops out at 250 MiB/s, io1 at 1,000 MiB/s, gp3 at 2,000 MiB/s, and io2 Block Express at 4,000 MiB/s.
• HDD volume caps: st1 reaches 500 MiB/s, while sc1 reaches 250 MiB/s.

The instance cap can hide behind the volume's provisioned figure. In an AWS troubleshooting example, a 1 TiB gp3 volume provisioned at 700 MiB/s on a t3.medium reached about 260 MiB/s for roughly 30 minutes a day, then settled at the instance's 43 MiB/s baseline.

3. Latency from VolumeTotalReadTime and VolumeTotalWriteTime

EBS latency is a derived value, calculated from VolumeTotalReadTime and VolumeTotalWriteTime, because CloudWatch doesn't publish metrics named VolumeReadLatency or VolumeWriteLatency. On Nitro, read latency in milliseconds is (Sum(VolumeTotalReadTime) / Sum(VolumeReadOps)) × 1000, and writes follow the same shape. Nitro-attached volumes also publish native VolumeAvgReadLatency and VolumeAvgWriteLatency, which report the average latency of operations completed in the last minute.

Normal latency depends on the type, with io2 Block Express averaging under 500 microseconds for 16 KiB I/O on Nitro. AWS documents gp2, gp3, and io1 only as single-digit milliseconds and publishes no figure for st1 and sc1, so baseline your own.

4. Queue Depth from VolumeQueueLength

VolumeQueueLength reports the read and write requests waiting to complete, which makes it the clearest saturation signal. For SSD volumes, the EBS I/O characteristics guidance targets an average queue length of one per 1,000 provisioned IOPS, measured per minute. The EBS performance guidance calls for a queue of four or more on HDD volumes under 1 MiB sequential I/O.

A queue that sits high and flat while idle time stays near zero indicates a volume at capacity. The remedy depends on the limiting resource:

• Provisioned IOPS: Increase the provisioned IOPS when operation capacity is the constraint.
• Larger gp2 volume: Increase gp2 capacity when the size-based baseline is too low.
• Different volume type: Change the volume type when the current performance model doesn't match the workload.

Once the queue shows saturation, the next question is which deploy, query, or pod caused it. In Coralogix, a cross-stack observability platform, AWS/EBS metrics arrive through CloudWatch Metric Streams and sit next to the logs and traces from the same instance.

5. Idle Time from VolumeIdleTime

VolumeIdleTime reveals unused capacity and micro-bursting by counting the seconds in each period with no read or write submitted. Sum(VolumeIdleTime) / Period × 100 turns it into an idle percentage. A volume with high idle time every hour is paying for provisioned performance it never uses, and a sudden jump on a busy volume can signal that an upstream application stopped sending work.

High idle time in the same minute as high IOPS or throughput is the signature of micro-bursting, where the volume does a minute's worth of work in a few seconds and then waits.

6. Credit Exhaustion from BurstBalance

BurstBalance shows the percentage of burst credits left on gp2, st1, and sc1, and a drained balance drops the volume to its baseline performance. The credits govern IOPS on gp2 and throughput on st1 and sc1. On gp2, baseline performance is three IOPS per GiB with a 100 IOPS floor, volumes under 1 TiB can burst to 3,000 IOPS, and the credit bucket starts full.

At zero percent, the volume drops to its size-based baseline, and credits accrue only while demand sits at or below that baseline, which means a saturated workload never recovers on its own. Repeated drains signal a move to gp3, which delivers steady baseline performance with no credit model at a lower price per GiB, or to io1 or io2 for sustained IOPS.

Which Newer EBS Metrics Catch Micro-Bursting?

VolumeIOPSExceededCheck, VolumeThroughputExceededCheck, VolumeAvgIOPS, and VolumeAvgThroughput are the newer per-minute metrics that catch micro-bursting, which minute-level graphs average away. The ExceededCheck pair arrived on October 30, 2024, and reports 1 when an application consistently tried to drive more IOPS or throughput than the volume's provisioned performance within the last minute, and 0 otherwise.

The VolumeAvg pair followed on October 29, 2025, and reports the average IOPS and the average throughput in KiB/s driven to the volume each minute. All four publish at one-minute intervals at no additional charge for volumes attached to Nitro instances, and the ExceededCheck pair isn't available on magnetic volumes, Multi-Attach volumes, or volumes used by ECS and Fargate tasks. When ExceededCheck breaches recur, move the workload to a larger volume or to a volume type with higher provisioned performance.

Which EBS Metrics Should You Prioritize for Each Volume Type?

The metrics to prioritize are the two or three that expose each volume type's primary constraint, which shortens mean time to repair because the first graph you open explains the incident:

• gp2: BurstBalance first and VolumeQueueLength second. Credit exhaustion is the dominant failure, and the queue grows as the volume throttles toward its size-based baseline.
• gp3: Write latency, derived or native, and VolumeAvgThroughput on Nitro. With no credit model, these two show whether the IOPS and throughput you provisioned independently match demand.
• io1 and io2: VolumeIOPSExceededCheck against the provisioned figure and VolumeQueueLength against the queue guidance above. VolumeThroughputPercentage, the share of provisioned IOPS delivered, exists only on Provisioned IOPS volumes and belongs on the same dashboard.
• st1 and sc1: VolumeReadBytes and VolumeWriteBytes as MiB/s against the size-scaled throughput cap, BurstBalance for the throughput credits, and a queue that holds at the recommended level under sequential I/O.

On Nitro instances, add VolumeIdleTime and the ExceededCheck pair to each of these dashboards to catch bursts the core metrics average away.

How to Set Alarms on EBS Metrics

An EBS alarm should fire on a sustained condition rather than a single breach, which keeps storage alarms from adding to alert fatigue. The threshold patterns below cover the failure modes above:

• VolumeQueueLength: Use the Average statistic against the SSD queue guidance above, and require several consecutive evaluation periods before the alarm fires.
• VolumeIOPSExceededCheck: Trigger after repeated breach values across multiple minute-level evaluations. Requiring repeats separates a recurring micro-bursting pattern from one noisy period.
• BurstBalance: Choose a threshold that fits the workload and leaves enough time for a volume modification. Waiting for complete depletion lets the volume fall back to its baseline before you can respond.

Missing data belongs on ignore (maintain alarm state), because CloudWatch reports BurstBalance only while the volume is active, and a quiet volume would otherwise look like a broken one.

Coralogix's AWS EBS Observability extension adds a dedicated EBS dashboard for volume health, performance, and capacity trends. Its alerts cover read and write latency and throughput anomalies, saving you from building those thresholds by hand.

How to Read EBS Metrics When a Volume Looks Slow

Reading EBS metrics on a slow volume comes down to five checks, run in order:

• IOPS and throughput: Compare both against the volume and instance ceilings.
• Latency: Check whether operation time rises as the workload approaches a ceiling.
• Queue length: Look for requests accumulating while the volume remains busy.
• BurstBalance: Check remaining credits on credit-based volume types.
• Minute-average checks: Use the ExceededCheck and VolumeAvg* metrics to validate aggregated graphs.

Metrics tell you a volume is saturated, and the instance's logs and traces tell you why. Coralogix keeps all three signals on one timeline, so the saturation and its cause show up in the same investigation.

Explore the Coralogix platform to view your EBS volume metrics next to the logs from the instances they serve.

Frequently Asked Questions About EBS Metrics

What are the types of Amazon EBS volumes?

Amazon EBS has six current-generation volume types, four SSD and two HDD:

• SSD volumes: The SSD family includes gp2, gp3, io1, and io2 for random and transactional I/O such as databases and boot volumes.
• HDD volumes: The HDD family includes st1 and sc1 for large sequential workloads such as big-data scans and infrequently accessed archives.

Only gp2, st1, and sc1 use a credit model, so BurstBalance applies to those three. AWS also still lists the previous-generation magnetic volume type, which the ExceededCheck metrics don't support.

When should you use EBS vs. EFS vs. S3?

EBS suits block storage, EFS a shared file system, and S3 objects, depending on how your workload accesses data:

• EBS: EBS is block storage for a single instance or multiple Nitro instances through io1 and io2 Multi-Attach, suited to low-latency database and file-system workloads.
• EFS: Amazon Elastic File System (EFS) is a shared file system that multiple instances can mount at once.
• S3: Amazon S3 is object storage for backups and the snapshots EBS itself stores.

Each service has its own CloudWatch namespace, AWS/EBS, AWS/EFS, and AWS/S3, so EBS volume metrics never describe EFS or S3 behavior.

What does a high VolumeQueueLength mean?

A high VolumeQueueLength means more read and write requests are pending against the volume than it can complete, and a sustained average above the SSD queue guidance indicates rising latency. VolumeQueueLength is the first metric to check during root cause analysis of a slow database, alongside VolumeIdleTime to rule out micro-bursting.