What's the Difference Between EBS IOPS and Physical Disk IOPS

Applicability of This Document

Ready-to-Run Commands

# 対象: Amazon EBS（AWS CLI v2）
# 権限: ec2:DescribeVolumes
# 変更作業: なし（参照のみ）
# Production 実行: 可能
aws ec2 describe-volumes \
  --volume-ids vol-0123456789abcdef0 \
  --query "Volumes[].{Id:VolumeId,Type:VolumeType,SizeGiB:Size,Iops:Iops,\
ThroughputMiBs:Throughput,MultiAttach:MultiAttachEnabled,State:State,\
AttachedTo:Attachments[0].InstanceId,Device:Attachments[0].Device}" \
  --output table

# 対象: Amazon CloudWatch（名前空間 AWS/EBS）
# 権限: cloudwatch:GetMetricStatistics
# 変更作業: なし（参照のみ）
# Production 実行: 可能
for M in VolumeReadOps VolumeWriteOps VolumeQueueLength BurstBalance
do
  echo "===== $M ====="
  aws cloudwatch get-metric-statistics \
    --namespace AWS/EBS \
    --metric-name "$M" \
    --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
    --start-time 2026-08-12T00:00:00Z \
    --end-time   2026-08-13T00:00:00Z \
    --period 300 \
    --statistics Average Maximum Sum \
    --output text
done

# 対象: EC2 上の Linux
# 権限: 一般ユーザー（nvme list は root 権限が必要な場合がある）
# 変更作業: なし（参照のみ）
# Production 実行: 可能
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL
sudo nvme list
cat /sys/block/nvme1n1/queue/nr_requests
iostat -x 1 5

# 対象: Linux + fio 3.x
# 権限: 対象ファイルへの読み取り権限（デバイス直接指定なら root）
# 変更作業: なし（読み取りのみ）だが、実行中は他の処理の I/O 性能に影響する
# Production 実行: 非推奨。検証環境、または本番と共有しないボリュームで実行すること
fio --name=randread \
    --filename=/mnt/testdir/fio_testfile \
    --size=64G \
    --rw=randread \
    --bs=4k \
    --ioengine=libaio \
    --direct=1 \
    --iodepth=32 \
    --numjobs=4 \
    --runtime=300 \
    --time_based \
    --group_reporting

How to Read the Results

When to Use This

• Performance that was achieved on on-premises SSD is not reproduced after moving to EBS
• A benchmark tool's numbers diverge significantly from EBS's provisioned values
• Increasing a volume's IOPS doesn't raise throughput
• A large volume was attached, but the expected performance is not achieved
• A gp2 volume is fast for a while, then suddenly slows down at some point
• CloudWatch's VolumeReadOps value doesn't line up with IOPS units

Possible Causes (Most Likely First)

1. 01

   EBS is network-attached block storage

   EBS is not a device physically attached to the instance — it is storage connected over the network. IOPS is therefore determined not by "how fast the device is" but by "how much the service lets through." Because it goes over the network, latency characteristics also differ from a physical disk.

2. 02

   I/O size changes how many IOPS a single operation consumes

   EBS counts I/O in fixed-size units. An I/O larger than that unit is counted as multiple IOPS, while consecutive I/O can sometimes be counted together. In other words, "one operation" does not equal "one IOPS." The unit size differs by volume type (SSD-based vs. HDD-based), so check the current EBS volume type documentation for the value for your type — this article does not give specific byte figures.

3. 03

   IOPS and throughput are separate ceilings

   EBS has two ceilings: IOPS (operations/sec) and throughput (MiB/sec). A workload issuing many small I/Os hits the IOPS ceiling first, while one issuing large I/Os hits the throughput ceiling first. Judge which is the limiting factor by whether I/O size times IOPS has reached the throughput ceiling.

4. 04

   The instance side also has an EBS bandwidth ceiling

   In addition to the volume-side ceiling, each EC2 instance class has a defined bandwidth ceiling to EBS (EBS-optimized bandwidth). Attaching a high-performance volume to a small instance means the instance-side ceiling becomes the bottleneck. Since the ceiling differs by instance class, check the target class in current AWS documentation.

5. 05

   gp2 depends on burst credits

   gp2 has a baseline performance tied to capacity, with I/O beyond that drawn from I/O credits. Once credits run out, performance falls to baseline. This is the classic cause of "fast at first, then slows down at some point." gp3 is not credit-based — it is a model where additional IOPS and throughput are configured on top of a baseline.

6. 06

   Confusion with instance store (NVMe)

   Instance store is an NVMe device physically attached to the host, and it is not subject to a network-based ceiling like EBS. However, it is temporary storage that loses data on instance stop or termination. Benchmarking instance store and comparing the result against EBS numbers will always produce a mismatch.

7. 07

   The benchmark is measuring the cache

   If `direct=1` is not specified, or the test data size is smaller than RAM, what's being measured is the OS page cache. A figure obtained under these conditions does not represent storage performance, on a physical disk or on EBS.

Diagnostic Steps

1. 1

   Check the volume-side ceiling

   Read-only

   Use `aws ec2 describe-volumes` to check the type, capacity, provisioned IOPS, and throughput setting.

2. 2

   Check the instance-side ceiling

   Read-only

   Check the attached instance class's EBS bandwidth ceiling in current AWS documentation. If lower than the volume side, the instance is the limiting factor.

3. 3

   Pull measured values from CloudWatch

   Read-only

   Get the Sum of VolumeReadOps/VolumeWriteOps and divide by the number of seconds in the period to convert to IOPS. Also check VolumeQueueLength and BurstBalance.

4. 4

   Check the I/O size

   Read-only

   Divide throughput (bytes/sec) by IOPS (ops/sec) to get the average I/O size. This is a basis for judging whether the limit is IOPS or throughput.

5. 5

   Check the OS-side view

   Read-only

   Use `iostat -x` to check `r/s`, `w/s`, `aqu-sz`, `await`, and `%util`, and cross-check against the CloudWatch values.

6. 6

   Run fio in a test environment if needed

   Low

   Always specify `--direct=1` and a working set larger than RAM. Do not run this against a volume shared with production.

Solutions

Differences by Version and Environment

If This Doesn't Resolve It

• Check the filesystem and mount options

  Alignment, journaling settings, and whether `noatime` is set affect I/O count. Check this when things are slow without hitting a block-device ceiling.

• Check the application's synchronous I/O settings

  A database log write is synchronous I/O, where latency matters more than throughput. Check this if things are slow despite headroom in IOPS.

• Check for waiting at the RAID or LVM layer

  When striping multiple volumes, a single slow one drags down the whole array. Check `iostat -x` per device.

• Check for contention with the instance's network bandwidth

  How EBS bandwidth and network bandwidth are handled differs by generation and class. Worth checking if I/O drops during heavy network traffic.

• Obtain the measurement conditions for anything being compared

  If the measurement conditions (I/O size, queue depth, direct flag, working set) behind a claim like "on physical disk it was this value" are unknown, the comparison itself does not hold.

Basis and Limitations of This Document

FAQ

Questions This Document Covers

• Why does HDD RAID 0 show a high IOPS value
• Why doesn't raising EBS IOPS make things faster
• Can't get the same performance on EBS as on-premises SSD
• How to convert CloudWatch's VolumeReadOps to IOPS

What the Risk Labels Mean

• Read-onlyDoes not change data or settings.
• LowImpact is limited, but permissions and load should be checked.
• MediumMay affect performance, locking, or cost.
• HighMay cause an outage, data loss, or require recovery work.
• Expert Review RequiredRequires a separate review before applying to production.

GIIP's Scope of Support

Where an EBS ceiling applies can be figured out in a single investigation once conditions are matched. What matters operationally isn't that — it's whether you notice the moment data volume and access patterns shift enough to start hitting the ceiling. At GIIP, an AI agent continuously tracks storage-side leading indicators such as VolumeQueueLength and BurstBalance across several databases on AWS and Azure and roughly 30 web services, and a human specialist judges whether a configuration change is needed once a trend approaches the ceiling. The goal is to detect this before it becomes an incident, not to measure it afterward.

Related Services

• データベース性能チューニング
• 性能障害の切り分けを依頼する