AWS EBS의 IOPS와 물리 디스크의 IOPS는 무엇이 다른가

この文書の適用条件

そのまま実行できるコマンド

# 対象: 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

結果の読み方

こういう状況で使います

• 온프레미스 SSD에서 나오던 성능이 EBS로 옮기니 나오지 않음
• 벤치마크 도구의 수치가 EBS의 프로비저닝 값과 크게 어긋남
• 볼륨의 IOPS를 늘렸는데 처리량이 오르지 않음
• 큰 볼륨을 연결했는데도 기대한 성능이 나오지 않음
• gp2 볼륨에서 한동안 빠르다가 어느 시점부터 갑자기 느려짐
• CloudWatch의 VolumeReadOps 값과 IOPS의 단위가 맞지 않음

考えられる原因（可能性の高い順）

1. 01

   EBS는 네트워크 연결형 블록 스토리지임

   EBS는 인스턴스에 물리적으로 부착된 장치가 아니라 네트워크를 통해 연결된 스토리지입니다. 따라서 IOPS는 "장치가 얼마나 빠른가"가 아니라 "서비스가 어디까지 통과시키는가"로 결정됩니다. 네트워크를 경유하기 때문에 지연 시간의 성질도 물리 디스크와 다릅니다.

2. 02

   I/O 크기에 따라 1회 I/O가 소비하는 IOPS 수가 달라짐

   EBS는 I/O를 고정 크기 단위로 셉니다. 그 단위보다 큰 I/O는 여러 IOPS만큼으로 계산되며, 반대로 연속된 I/O는 묶여서 계산되는 경우가 있습니다. 즉 "1작업=1 IOPS"가 아닙니다. 단위 크기는 볼륨 종류(SSD 계열과 HDD 계열)에 따라 다르므로 최신 EBS 볼륨 종류 문서에서 대상 종류의 값을 확인하십시오. 본 문서에서는 구체적인 바이트 수를 제시하지 않습니다.

3. 03

   IOPS와 처리량은 별개의 상한임

   EBS에는 IOPS(횟수/초)와 처리량(MiB/초)이라는 두 가지 상한이 있습니다. 작은 I/O를 대량으로 내는 워크로드는 IOPS 상한에, 큰 I/O를 내는 워크로드는 처리량 상한에 먼저 걸립니다. 어느 쪽이 제한 요인인지는 I/O 크기와 IOPS의 곱이 처리량 상한에 도달했는지로 판단합니다.

4. 04

   인스턴스 쪽에도 EBS 대역 상한이 있음

   볼륨 쪽 상한과는 별도로 EC2 인스턴스 클래스마다 EBS로의 대역 상한(EBS 최적화 대역)이 정해져 있습니다. 고성능 볼륨을 작은 인스턴스에 연결하면 인스턴스 쪽 상한에서 한계에 부딪힙니다. 상한값은 인스턴스 클래스마다 다르므로 최신 AWS 문서에서 대상 클래스를 확인하십시오.

5. 05

   gp2는 버스트 크레딧에 의존함

   gp2는 용량에 따른 기본 성능을 가지며, 이를 초과하는 I/O는 I/O 크레딧으로 충당합니다. 크레딧이 고갈되면 기본 성능까지 떨어집니다. "처음에는 빠르지만 어느 시점부터 느려진다"는 현상의 전형적인 원인입니다. gp3는 크레딧 방식이 아니라 기본값에 대해 추가 IOPS와 처리량을 설정하는 모델입니다.

6. 06

   인스턴스 스토어(NVMe)와 혼동하고 있음

   인스턴스 스토어는 호스트에 물리적으로 부착된 NVMe 장치로, EBS와 같은 네트워크 경유의 상한이 적용되지 않습니다. 다만 인스턴스 정지·종료 시 데이터가 사라지는 임시 스토리지입니다. 벤치마크로 인스턴스 스토어의 값을 측정하고 이를 EBS의 값과 비교하면 반드시 어긋납니다.

7. 07

   벤치마크가 캐시를 측정하고 있음

   `direct=1`을 지정하지 않았거나 테스트 데이터의 크기가 RAM 용량보다 작으면 측정하고 있는 것은 OS의 페이지 캐시입니다. 이 조건에서 나온 수치는 물리 디스크에서든 EBS에서든 스토리지의 성능을 나타내지 않습니다.

確認手順

1. 1

   볼륨 쪽 상한 확인하기

   参照のみ

   `aws ec2 describe-volumes`로 종류·용량·프로비저닝 IOPS·처리량 설정을 확인합니다.

2. 2

   인스턴스 쪽 상한 확인하기

   参照のみ

   연결된 인스턴스 클래스의 EBS 대역 상한을 최신 AWS 문서로 확인합니다. 볼륨 쪽보다 낮으면 인스턴스가 제한 요인입니다.

3. 3

   CloudWatch로 실측값 가져오기

   参照のみ

   VolumeReadOps·VolumeWriteOps를 Sum으로 가져와 기간 초 수로 나눠 IOPS로 환산합니다. VolumeQueueLength와 BurstBalance도 함께 봅니다.

4. 4

   I/O 크기 확인하기

   参照のみ

   처리량(바이트/초)을 IOPS(횟수/초)로 나눠 평균 I/O 크기를 구합니다. 이것이 IOPS 제한인지 처리량 제한인지 판단하는 근거가 됩니다.

5. 5

   OS 쪽에서 보이는 상태 확인하기

   参照のみ

   `iostat -x`로 `r/s`·`w/s`·`aqu-sz`·`await`·`%util`을 확인해 CloudWatch 값과 대조합니다.

6. 6

   필요하면 검증 환경에서 fio 실행하기

   低

   `--direct=1`과 RAM보다 큰 워킹셋을 반드시 지정합니다. 운영 환경과 함께 쓰는 볼륨에서는 실행하지 않습니다.

対応方法

バージョン・環境による違い

これで解決しない場合に確認すること

• 파일시스템과 마운트 옵션 확인하기

  정렬(alignment), 저널 설정, `noatime` 유무 등이 I/O 횟수에 영향을 줍니다. 블록 장치의 상한에 걸려 있지 않은데도 느린 경우의 확인 대상입니다.

• 애플리케이션 쪽 동기 I/O 설정 확인하기

  데이터베이스의 로그 쓰기는 동기 I/O이며 처리량이 아니라 지연 시간이 효과를 줍니다. IOPS에 여유가 있는데도 느린 경우 여기를 확인합니다.

• RAID 구성이나 LVM 계층에서 대기가 발생하지 않는지 확인하기

  여러 볼륨을 스트라이핑한 경우 하나의 지연이 전체를 끌어내립니다. 장치 단위로 `iostat -x`를 확인합니다.

• 인스턴스의 네트워크 대역과 경합하지 않는지 확인하기

  세대·클래스에 따라 EBS 대역과 네트워크 대역의 처리 방식이 다릅니다. 대량의 네트워크 통신과 동시에 I/O가 떨어지는 경우 확인이 필요합니다.

• 비교 대상의 측정 조건 확보하기

  "물리 디스크에서는 이 값이었다"는 수치의 측정 조건(I/O 크기, 큐 깊이, direct 지정, 워킹셋)을 모른다면 비교 자체가 성립하지 않습니다.

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• HDD RAID 0에서 높은 IOPS 값이 표시되는 이유
• EBS의 IOPS를 올려도 빨라지지 않는 이유
• 온프레미스 SSD와 같은 성능이 EBS에서 나오지 않음
• CloudWatch의 VolumeReadOps를 IOPS로 환산하는 방법

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

EBS의 상한이 어디에 걸리는지는 조건을 맞추면 한 번의 조사로 알 수 있습니다. 운영에서 문제가 되는 것은 그 부분이 아니라, 데이터량과 접근 패턴이 변화해서 어느 날부터 상한에 걸리기 시작하는 순간을 알아챌 수 있는가입니다. GIIP에서는 AWS와 Azure 상의 여러 데이터베이스 및 약 30개의 웹 서비스에 대해 VolumeQueueLength나 BurstBalance 같은 스토리지 쪽 선행 지표를 AI 에이전트가 지속적으로 추적하고, 상한에 근접하는 경향이 나타난 단계에서 사람인 전문가가 구성 변경 필요성을 판단합니다. 장애가 발생한 뒤 측정하는 것이 아니라 상한에 닿기 전에 감지하는 것을 목적으로 하고 있습니다.

関連サービス

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