EC2の設計で「EBSはとりあえずgp3」で進めた結果、あとから性能不足やコスト過多に気づくことは珍しくありません。ここでは **SAA-C03の学習にもつながる“考え方”**として、要件（IOPS・スループット・レイテンシ・耐久性・ブート可否）から gp3 / io2 / st1 / sc1 を選ぶ手順を、公式仕様を根拠に整理します。
迷ったらこの要件表から逆算する
EBSは「何を重視するか」で最適解が変わるので、最初に要件を言語化すると選定が一気にラクになります。
要件からの選定マップ
- ランダムI/Oが多い（DB・トランザクション） → まず gp3、足りなければ io2
- とにかく低レイテンシ＆高IOPSを安定して出したい → io2（特にio2 Block Express）
- 大きな順次読み書き（ログ、ETL、DWH、ビッグデータ） → st1
- ほぼ読まない保管寄り（バックアップ置き場、アーカイブ） → sc1
- OSブート → gp3 または io2（st1 / sc1 はブート不可）
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
EBSボリュームタイプの前提｜IOPSとスループットは別物
「速い＝IOPSが高い」と思いがちですが、EBSは IOPS（回数） と スループット（転送量） が別軸です。
- IOPS：小さめのランダムI/O（例：8KiB〜16KiB）を何回さばけるか
- スループット（MiB/s）：大きめの順次I/O（例：1MiBの連続読み書き）をどれだけ流せるか
- さらに、体感に効くのは レイテンシ（遅延）。DBはここで差が出ます。
（EBSの比較表でも、最大IOPSや最大スループット、io2 Block Expressの低レイテンシ特性が整理されています）
gp3｜基本はこれ。IOPSとスループットを独立に“盛れる”のが強い
gp3は「汎用SSD」の最新世代で、学習者が最初に押さえるべき標準です。ポイントは バーストに頼らず、プロビジョンド性能を継続できること。
gp3の要点
- ベースライン 3,000 IOPS（ストレージ料金に含まれる）
- ベースライン 125 MiB/s（含まれる）
- 追加で 最大 80,000 IOPS までプロビジョニング可能（サイズ条件あり）
- 追加で 最大 2,000 MiB/s までプロビジョニング可能（IOPS条件あり）
- バーストモデルではない（“クレジット切れ”で遅くなるタイプではない）
gp3がハマる典型例
- 小〜中規模のWeb/業務サーバ、コンテナノードのルート/データ
- RDBを1台で動かすが、超高負荷までは想定しない
- 「まず動かして、必要になったらIOPS/スループットを上げる」運用をしたい
gp3の落とし穴
- スループットは“上限だけ”見て決めない：大きい値が必要＝順次I/O中心とは限りません。ランダムI/O中心ならIOPS側が先に詰まります。
- サイズ条件：最大IOPSや最大スループットにはボリュームサイズやIOPS条件が絡みます（数字だけ暗記より、条件付きで理解）。
io2｜ミッションクリティカルの“確実さ”を買う選択肢
io2は「プロビジョンドIOPS SSD」で、高IOPSを安定して出したい・耐久性も重視したいときの候補です。特に io2 Block Express は単一ボリュームでの上限が大きいです。
io2（Block Express含む）の要点
- 比較表上の目安：最大 256,000 IOPS、最大 4,000 MiB/s（io2 Block Express）
- 公式紹介でも 最大256,000 IOPS / 4,000 MB/s / 64TiB 等が示されています
- io2 Block Express は 16KiB I/Oで平均 500マイクロ秒未満のレイテンシを想定した設計
- スループットは プロビジョンドIOPSに比例してスケール（上限あり）
io2が向くケース
- Oracle / SQL Server / SAP HANA など、I/Oに厳しいDBや分析基盤（公式の例にも登場）
- 「夜間バッチで急に重くなる」ではなく、常に重い・レイテンシのブレが困るワークロード
- 障害許容度が低い（耐久性重視）の設計判断が求められる場面
io2の注意点
- 何でもio2にするとコストが膨らみやすいので、まずgp3で要件を満たせるか検討し、“満たせない根拠”があるときに格上げするのが現実的です。
- インスタンスタイプ（Nitro等）やアタッチ条件で到達できる性能が変わるため、「ボリュームの上限＝体感の上限」ではありません。
st1 / sc1｜HDDは“スループットの世界”。クレジットとブート不可を押さえる
st1（Throughput Optimized HDD）とsc1（Cold HDD）は、大きな順次I/Oを低コストで流すための選択肢です。どちらも ブートボリュームには使えません。
st1｜ログ処理・DWH・ビッグデータ向け
st1はスループット重視で、性能は **バーストクレジット（スループットクレジット）**に影響されます。
- 1TiBのst1は バースト 250 MiB/s、ベースライン 40 MiB/s 相当（クレジットの貯まり方）
- 大きくすると比例して伸びるが、上限は 最大500 MiB/s
- 最大IOPSは高くない（1MiB I/O前提での指標）ので、ランダムI/Oが多い用途には不向き
sc1｜ほぼアクセスしない“冷たいデータ”向け
sc1はさらに低コスト寄りで、こちらもクレジットモデルです。
- 1TiBのsc1は バースト 80 MiB/s、ベースライン 12 MiB/s 相当
- スループット上限は 最大250 MiB/s
- スナップショット取得中に性能が落ちる可能性が明記されています（運用上の注意点）。
要件表｜gp3 / io2 / st1 / sc1 を“数字と性格”で比較する
ここは暗記より、「どの軸に強いか」を掴むのが目的です（数字は公式の代表値）。
| 観点 | gp3 | io2（Block Express含む） | st1 | sc1 |
|---|---|---|---|---|
| 得意なI/O | ランダム〜混在 | ランダム（高IOPS・低レイテンシ） | 順次（大容量ストリーム） | 順次（低頻度アクセス） |
| ブート可否 | 可 | 可 | 不可 | 不可 |
| 性能の出し方 | IOPS/スループットをプロビジョニング（バーストなし） | IOPSを強くプロビジョニング、上限大 | クレジット（バースト/ベースライン） | クレジット（バースト/ベースライン） |
| 代表的な上限例 | 最大80,000 IOPS / 2,000 MiB/s | 最大256,000 IOPS / 4,000 MiB/s（Block Express） | 最大500 MiB/s | 最大250 MiB/s |
| 典型用途 | 汎用、まずはこれ | ミッションクリティカルDB | ログ、DWH、ETL | アーカイブ、バックアップ置き場 |
※上限や条件、クレジット挙動は公式ドキュメントに詳細があります。
SAA-C03的に“設計判断”を組み立てる
試験でも実務でも、いきなりタイプ名を選ぶより「除外→絞り込み」が事故りません。
ブートが必要か
- Yes → st1/sc1は除外（gp3 か io2）
- No → 以降の要件で判断
I/Oがランダム中心か、順次中心か
- ランダム中心（DB、キーバリュー、トランザクション）→ gp3 / io2
- 順次中心（ログ集計、ETL、スキャン）→ st1 / sc1
性能の“ブレ”が許容できるか
- ブレが困る（常時一定の性能が必要）→ gp3（バーストなし） or io2
- 短時間のバーストで十分・コスト優先 → st1 / sc1（クレジット理解が前提）
具体例で当てはめる
- 小規模Web＋RDSではなくEC2内DB：まずgp3で開始。必要に応じてIOPS/スループットを増やし、それでもレイテンシやIOPSが厳しければio2へ。
- ログをS3ではなくEBS上で一時処理：順次I/Oが中心ならst1。アクセスがさらに低頻度ならsc1。
学習を一気に固めたい人へ｜EBSを“設計文脈”で理解する教材の一例
EBSは「数字の暗記」より、EC2設計（可用性・性能・コスト）とセットで理解すると定着が早い分野です。
体系的に押さえるなら、EC2/EBS/EFS/S3の使い分けや性能設計をハンズオンで整理できるUdemy講座を1本持っておくと、復習の軸が作りやすくなります（あくまで教材の一例です）。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
まとめ｜EBSは“要件の言語化”ができれば選べる
- gp3は基本。IOPSとスループットを独立に調整でき、バーストに頼らない設計がしやすい
- io2は「低レイテンシ・高IOPS・耐久性」をより強く求める場面で効く（特にio2 Block Express）
- st1 / sc1は順次I/O向け。クレジットモデルとブート不可を理解して使う
- 選定は「ブート要件 → I/O特性 → ブレ許容 → コスト」の順で絞るとミスりにくい
必要なら、あなたの想定ワークロード（例：DB種類、ピーク時のI/O、読み書き比率、容量）を前提に、**“要件表を埋めた完成版”**まで一緒に作って記事内の図表にしてもOKです。
