【小ネタ】 EC2 インスタンス診断 (Instance diagnostics) の「EBS パフォーマンス」で何が確認できるのか調べてみた

EC2 コンソールの Instance diagnostics に新たに追加された「EBS パフォーマンス」機能について、実際の検証環境を交えながら深掘りしていきます。EBS ボリュームと EC2 インスタンスの性能構成のミスマッチを可視化する便利な機能の使い方をご紹介します。

片方裕人

2026.08.02

 はじめにテクニカルサポートの 片方 です。

少し前になりますが、EC2 コンソールのインスタンス診断 (Instance diagnostics) において、EBS パフォーマンスについて出力されるようになりました。
今回は小ネタとして、こちらのではどのようなことを確認できるのかを深堀りしたいと思います。
 先に結論からEC2 コンソールの Instance diagnostics に追加された「EBS パフォーマンス」では、主に以下の情報を確認できました。
EC2 インスタンス側の EBS ボリューム性能
ベースライン IOPS
最大 IOPS
ベースラインスループット
最大スループット
インスタンスにアタッチされた EBS ボリュームの設定
ボリュームタイプ
サイズ
IOPS
スループット
実際の EBS 利用状況
インスタンス全体の合計 IOPS
インスタンス全体の合計スループット
ボリューム単位の平均 IOPS
ボリューム単位の平均スループット
読み取り／書き込みレイテンシー
インスタンスまたはボリュームの性能上限を超えたかどうか
EC2 インスタンスと EBS ボリュームの性能構成にミスマッチがないか
特に便利だと感じたのは、EBS ボリュームに設定した性能を、EC2 インスタンス側で十分に引き出せる構成になっているかを確認できる点です。

EBS ボリュームに高い IOPS やスループットを設定しても、実際に利用できる性能は EC2 インスタンスタイプ側の EBS 性能上限にも制限されます。
今回確認した環境では、t3.large に対して、15,000 IOPS、1,500 MiB/s を設定した gp3 ボリュームをアタッチしました。その結果、EC2 インスタンスのベースライン性能が、アタッチされた EBS ボリュームの性能を下回っていることを示す警告が表示されました。

一方、この警告は、実際に EBS の性能問題が発生したことを示すものではありません。

以下の2つは分けて考える必要があります。
構成上、EBS ボリュームの性能を十分に利用できない可能性がある
実際のワークロードによって性能上限に到達した
Instance diagnostics の EBS パフォーマンス画面では、この両方を同じ画面から確認できます。
 検証環境今回は、EBS の構成が異なる 2 つの EC2 インスタンスで表示内容を確認しました。

どちらの環境でも、EC2 インスタンスタイプには t3.large を使用しています。
検証環境は以下のとおりです。


環境
インスタンスタイプ
EBSタイプ
サイズ
IOPS
スループット


環境 1
t3.large
gp2
30 GiB
100
25 MiB/s

環境 2
t3.large
gp3
50 GiB
15,000
1,500 MiB/s

環境 1 は、EBS ボリューム側の性能が EC2 インスタンスのベースライン性能より低い構成です。

環境 2 では、検証のため、gp3 の IOPS とスループットを意図的に高く設定しています。


 確認してみた「EBS パフォーマンス」タブを開くと、はじめにインスタンス側の EBS 性能に関する情報が表示されます。

ここでは、以下の情報を確認できます。
インスタンスタイプ
EBS 最適化の有効／無効
ベースライン IOPS
最大 IOPS
ベースラインスループット
最大スループット
その下には、インスタンス全体の EBS メトリクスが表示されます。
合計 IOPS
合計スループット
インスタンス EBS パフォーマンスチェック (インスタンス EBS IOPS/スループット 超過チェック)
さらに画面を下へスクロールすると、アタッチされた EBS ボリュームの一覧と、ボリューム単位のメトリクスを確認できます。
 環境 1: EBS ボリューム性能がインスタンスのベースラインを下回る構成最初に、30 GiB の gp2 ボリュームをアタッチした環境を確認します。

今回使用した t3.large の EBS 性能は、画面上では以下のように表示されました。


項目
値


ベースライン IOPS
4,000

最大 IOPS
15,700

ベースラインスループット
82.9 MiB/s

最大スループット
331.4 MiB/s

一方、アタッチした gp2 ボリュームの表示内容は以下のとおりです。


項目
値


ボリュームタイプ
gp2

サイズ
30 GiB

IOPS
100

スループット
25 MiB/s

IOPS とスループットをそれぞれ比較すると、次の関係になります。
 IOPS
- EBS：               100 IOPS
- EC2 ベースライン：  4,000 IOPS
- EC2 最大：        15,700 IOPS
 スループット
- EBS：                25 MiB/s
- EC2 ベースライン：   82.9 MiB/s
- EC2 最大：         331.4 MiB/s
この環境では、EBS ボリューム側の表示性能が EC2 インスタンス側のベースライン性能を下回っています。

そのため、後述するインスタンスの EBS 性能に関する構成上の警告は表示されませんでした。

また、ボリュームの詳細では、以下の情報も確認できます。
ボリューム平均 IOPS
ボリューム平均スループット
読み取りレイテンシー
書き込みレイテンシー
ボリュームパフォーマンスチェック (ボリューム IOPS/スループット 超過チェック, ボリューム I/O 停止チェック)
EBS ヘルスイベント
今回の確認時点では高いディスク負荷を発生させていなかったため、IOPS とスループットは低い値となっています。ボリュームパフォーマンスチェックにも問題は検出されていません。
 gp2 の IOPS 表示について画面には、30 GiB の gp2 ボリュームの IOPS として 100 が表示されています。

ただし、これは gp2 ボリュームが常に　100 IOPSまでしか利用できない、という意味ではありません。

gp2 はボリュームサイズに応じたベースライン性能を持ち、ボリュームサイズが小さい場合でも、I/O クレジットを使用して最大3,000 IOPSまでバーストできます。
https://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/emr-plan-storage-compare-volume-types.html
今回の画面に表示されている 100 IOPS は、30 GiB の gp2 ボリュームにおけるベースライン IOPS と考えられます。

gp2 を利用している環境では、Instance diagnostics の情報だけではなく、必要に応じて BurstBalance などの CloudWatch メトリクスも確認する必要があります。
https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/using_cloudwatch_ebs.html
 環境 2 :EBS の性能を意図的に引き上げた構成続いて、gp3 の IOPS とスループットを意図的に高く設定した環境を確認します。

設定内容は以下のとおりです。


項目
値


ボリュームタイプ
gp3

サイズ
50 GiB

IOPS
15,000

スループット
1,500 MiB/s

この gp3 ボリュームを、先ほどと同じ t3.large にアタッチしています。

Instance diagnostics の EBS パフォーマンス画面を確認すると、ベースライン IOPS とベースラインスループットの項目に警告が表示されました。

画面には、以下のメッセージが表示されています。
!アタッチされたボリュームのベースラインを下回っています
IOPS の関係は以下のとおりです。
 IOPS
- EC2 ベースライン：  4,000 IOPS
- EBS：            15,000 IOPS
- EC2 最大：        15,700 IOPS
EBS ボリュームに設定した15,000 IOPSは、t3.large の最大 IOPSである15,700 IOPSには収まっています。

一方で、インスタンスのベースライン IOPSである4,000 IOPSは大きく上回っています。

このため、Instance diagnostics では、インスタンスのベースライン性能がアタッチされた EBS ボリュームの性能を下回っている構成として警告されています。
同様に、スループットも比較します。
 スループット
- EC2 ベースライン：   82.9 MiB/s
- EBS：             1,500 MiB/s
- EC2 最大：         331.4 MiB/s
こちらは EBS ボリュームに設定した 1,500 MiB/s が、t3.large のベースラインだけではなく、最大スループットも上回っています。

実際に利用できる EBS 性能は、EBS ボリューム側の性能と EC2 インスタンス側の性能のうち、低い方に制限されます。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-optimized.html
インスタンスの EBS パフォーマンスは、インスタンスタイプのパフォーマンス制限、またはアタッチされたボリュームの合計パフォーマンスのうち、どちらか小さい方によって制限されます。EBS のパフォーマンスを最大化するには、インスタンスにアタッチされたボリュームが合計でインスタンスの最大パフォーマンスと同等かそれ以上のパフォーマンスを発揮する必要があります。
今回の構成を単純化すると、利用できる最大スループットは以下のようになります。
 計算
min(
  EBS ボリューム：1,500 MiB/s,
  EC2 インスタンス：331.4 MiB/s
)

= 331.4 MiB/s
そのため、EBS ボリュームに1,500 MiB/s を設定していても、t3.large からそのすべてを利用することはできません。

特にスループットについては、EBS ボリュームに設定した性能の大部分を EC2 インスタンス側で利用できない構成になっていると確認可能です。
 まとめEC2 Instance diagnostics の EBS パフォーマンスでは、EBS ボリュームの利用状況だけでなく、EC2 インスタンス側の EBS 性能上限も確認できました。

今回のように、t3.large に15,000 IOPS、1,500 MiB/sの gp3 ボリュームをアタッチすると、EBS ボリューム側に高い性能を設定していても、EC2 インスタンス側で十分に利用できない可能性があることが警告されます。

EBS のパフォーマンス問題を調査する際は、ボリュームの IOPS とスループットだけではなく、以下もあわせて確認する必要があります。
EC2 インスタンスタイプ側の EBS 性能
複数ボリュームを含む合計 IOPS／スループット
インスタンスとボリュームのパフォーマンスチェック
読み取り／書き込みレイテンシー
EBS ヘルスイベント
EC2 インスタンスと EBS ボリュームのサイジング確認や、EBS の性能問題を切り分ける際に活用できそうです。

この記事がどなたかの参考になれば幸いです。
 参考資料Amazon EBS ボリュームタイプ gp2 と gp3 の比較
Amazon EBS の Amazon CloudWatch メトリクス - Amazon EBS
Amazon EBS 最適化インスタンスタイプ - Amazon Elastic Compute Cloud
 クラスメソッドオペレーションズ株式会社についてクラスメソッドグループのオペレーション企業です。

運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。

当社は様々な職種でメンバーを募集しています。

「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました