Skip to main content
Welcome — this lesson covers the Amazon EBS metrics available in AWS CloudWatch that matter most for performance troubleshooting and for certification exam prep. Below you’ll find the key metrics, how to interpret them together (IOPS, throughput, latency, queue depth), and how to create useful CloudWatch alarms.

​
Primary EBS metrics (quick summary)

The image is a slide titled "Amazon CloudWatch Metrics for Amazon EBS" showing four colored cards for metrics: VolumeReadOps, VolumeWriteOps, VolumeReadBytes, and VolumeWriteBytes. Each card includes a simple icon and a short description of the metric (read/write operations or bytes).

​
Important metric details

  • VolumeReadOps / VolumeWriteOps
    These report the total read and write operations during the metric period. Divide by the period length to obtain IOPS (operations/sec).
  • VolumeReadBytes / VolumeWriteBytes
    These report total bytes transferred. Divide by period length to get throughput (bytes/sec).
  • QueueLength (Queue Depth)
    QueueLength shows the number of outstanding I/O requests waiting to be processed. A sustained, rising QueueLength indicates the disk is a performance bottleneck (for example, your workload is issuing more IOPS than the volume can deliver).
  • Provisioned IOPS / throughput metrics (VolumeConsumedReadWriteOps, VolumeThroughputPercentage)
    For io1/io2 (provisioned) or gp3 configurations, CloudWatch exposes consumed IOPS/throughput and percentage-of-provisioned metrics. These help you tell if you’re hitting the provisioned limits. Values near 100% mean you’re using all the provisioned capacity.
  • BurstBalance and gp2 burst credits
    gp2 volumes use a credit-bucket model and can burst above their baseline rate while credits remain. gp3 separates IOPS/throughput from storage capacity and is generally preferred.
Note: gp2 still exists but gp3 is generally preferred. If you encounter performance issues on gp2 volumes, check BurstBalance before changing volume types.
  • Timing metrics (VolumeIdleTime, VolumeTotalReadTime, VolumeTotalWriteTime)
    These report time-based aggregates that you can use to compute average latencies per operation.
A slide titled "Amazon CloudWatch Metrics for Amazon EBS" showing three metric cards: VolumeTotalReadTime, VolumeTotalWriteTime, and Volume Consumed Read WriteOps. Each card includes an icon and a short description of the metric (time spent on read/write operations and I/O operations consumed).

​
How to reason about these metrics together

  • IOPS (operations per second)
    • read IOPS = VolumeReadOps / period_seconds
    • write IOPS = VolumeWriteOps / period_seconds
  • Throughput (bytes/sec)
    • read throughput = VolumeReadBytes / period_seconds
    • write throughput = VolumeWriteBytes / period_seconds
  • Average latency per operation
    • average read latency = VolumeTotalReadTime / VolumeReadOps
    • average write latency = VolumeTotalWriteTime / VolumeWriteOps
      Note: VolumeTotalReadTime and VolumeTotalWriteTime are reported in seconds in CloudWatch, so the result is seconds per operation — convert to milliseconds (×1000) if desired.
  • QueueLength (queue depth)
    If QueueLength grows steadily, that indicates operations are backing up — a classic sign of I/O saturation (disk bottleneck), not necessarily CPU or memory.
Putting this together: high IOPS/throughput with rising latency and increasing QueueLength = disk is saturated. If consumed IOPS or throughput percentage is near 100%, consider increasing provisioned IOPS/throughput or redistributing the workload.
A dashboard titled "Monitoring Using CloudWatch Alarms" showing semicircular gauge widgets with numeric values for EBS volume metrics. The gauges display metrics like VolumeTotalReadTime, VolumeQueueLength, VolumeReadOps, VolumeWriteOps, VolumeTotalWriteTime, VolumeIdleTime, VolumeReadBytes, BurstBalance, and VolumeWriteBytes.

​
CloudWatch alarms and automated actions

  • You can create CloudWatch alarms on any EBS metric. Choose between static thresholds and anomaly detection to reduce false positives.
  • Alarm comparison operators include GreaterThanThreshold, GreaterThanOrEqualToThreshold, LessThanThreshold, LessThanOrEqualToThreshold, etc.
  • Alarm actions commonly notify an SNS topic. From SNS you can:
    • Notify humans via email or SMS
    • Fan-out to other systems
    • Trigger an AWS Lambda function to run automated remediation
Best practices:
  • Use anomaly detection for variable workloads to avoid noisy alerts.
  • For disk bottlenecks, combine thresholds (e.g., QueueLength > X and VolumeConsumedReadWriteOps close to provisioned IOPS) to reduce false positives.
  • Consider automated remediation only after careful testing (e.g., scale-out, move data, modify EBS type).
A slide titled "Monitoring Using CloudWatch Alarms" showing an AWS CloudWatch metric/alarm configuration screen with a small time-series graph and fields like Namespace (AWS/EBS), Metric name (VolumeTotalReadTime), and VolumeId. The screenshot appears to demonstrate setting an alarm period and statistic for EBS volume read time.

​
Example alarm configuration options

  • Choose Static threshold or Anomaly detection depending on workload patterns.
  • Set comparison operator (e.g., GreaterThanThreshold) and an appropriate threshold value based on your baseline.
  • Configure evaluation periods and actions (SNS topics, Lambda functions).
A screenshot of a "Monitoring Using CloudWatch Alarms" settings page showing the Conditions panel for choosing threshold type (Static vs Anomaly detection) and comparison operators. The Static and Greater options are selected and the threshold value is set to 10000.

​
Exam tips / summary

  • Identify disk bottlenecks: a high and sustained QueueLength (queue depth) indicates the disk is overloaded — not CPU or memory.
  • Compute average latency from total time and operation counts:
    • average read latency = VolumeTotalReadTime / VolumeReadOps
    • average write latency = VolumeTotalWriteTime / VolumeWriteOps
  • Remember gp2 burst behavior (BurstBalance) and that provisioned IOPS volumes expose consumed I/O metrics (VolumeConsumedReadWriteOps, VolumeThroughputPercentage).
  • Use CloudWatch alarms (static or anomaly detection) and consider automation via SNS → AWS Lambda for remediation, but test automation carefully.

Watch Video