はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した Amazon EBS 関連の知識をまとめました。
ボリュームタイプの選択（特に IOPS の上限値）、暗号化のルール、Multi-Attach の制約など、試験で細かく問われるポイントを網羅しています。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
EBS ボリュームタイプ
| タイプ | 最大IOPS | 最大スループット | 主な用途 | Multi-Attach |
|---|---|---|---|---|
| io2 Block Express | 256,000 | 4,000 MB/s | 最高性能 DB | ✅ |
| io1 / io2 | 64,000 | 1,000 MB/s | 高 IOPS DB、ミッションクリティカル | ✅ |
| gp3 | 16,000 | 1,000 MB/s | 汎用（gp2 後継、ベースライン 3,000 IOPS） | ❌ |
| gp2 | 16,000 | 250 MB/s | 汎用（バーストモデル、3 IOPS/GiB） | ❌ |
| st1 | 500 | 500 MB/s | スループット最適化 HDD（ログ、ビッグデータ） | ❌ |
| sc1 | 250 | 250 MB/s | コールド HDD（アーカイブ） | ❌ |
試験で最も頻出のポイントは gp2/gp3 の最大 IOPS は 16,000 だということです。これを超える要件なら io1/io2 を選ぶ必要があります。
EBS 暗号化の重要ルール
EBS の暗号化を有効にすると、以下の すべてが暗号化 されます。
- 保存データ（at-rest）
- スナップショット
- インスタンス ⇔ ボリューム間の転送中データ（in-transit）
さらに覚えておくべきルールとして、暗号化は 一方通行 です。暗号化スナップショットからのコピーは必ず暗号化され、未暗号化には戻せません。
EBS Multi-Attach
- Provisioned IOPS SSD（io1 / io2）のみ対応
- 同一 AZ 内のみ（AZ をまたげない）
- 最大16インスタンスまで同時接続可能
- クラスタ対応ファイルシステムが必要
Fast Snapshot Restore（FSR）
- スナップショットからボリュームを作成する際の初期化遅延をゼロにする機能
- 通常は S3 からバックグラウンドでロードされるため、初回アクセスが遅い
- FSR を有効にすると、ボリューム作成直後からフルパフォーマンスを発揮
- 追加コストあり
Recycle Bin（ゴミ箱）
- 削除された EBS スナップショット / AMI を一定期間保持する機能
- 保持期間: 1日〜1年
- 保持期間中は復元可能、期間経過後に自動で完全削除
- 「誤削除から保護しつつ、古いものは自動削除」というシナリオで出題される
EBS のコスト特性
- プロビジョニングした容量 で課金される（使用量ではない）
- 100GB プロビジョニング + 1GB 使用 → 100GB 分の料金 が発生
これは EFS（使用量課金）や S3（使用量課金）とは異なる点で、コスト比較の問題で問われます。
試験で問われる設計パターン
SAA の試験では「どの EBS ボリュームタイプを選ぶか？」「暗号化で何が保護されるか？」というシナリオが頻出します。
ボリュームタイプの選択
25,000 IOPS 必要 → Provisioned IOPS SSD（io1/io2）
シナリオ: データベースのワークロードで 25,000 IOPS が安定的に必要です。どの EBS ボリュームタイプを選ぶべきでしょうか？
正解: Provisioned IOPS SSD（io1）
- gp2 / gp3 の最大 IOPS は 16,000 なので足りない
- io1 / io2 なら最大 64,000 IOPS まで対応可能
EC2 上の大規模 PostgreSQL + 高 IOPS + パッチ自己管理 → io1
シナリオ: 大規模な PostgreSQL データベースを EC2 上で運用しています。OS やデータベースのパッチは自社チームで管理しており、高い IOPS が求められます。ストレージにはどのボリュームタイプが適切でしょうか？
正解: Provisioned IOPS SSD（io1）
- 「パッチを自分で管理する」と明記されていれば、RDS ではなく EC2 上で動かしていることを意味する
- 大規模 DB + 高 IOPS = io1 / io2
EBS io1 が高コスト + 低使用率 + 時々バースト → gp2 に変更
シナリオ: EC2 に io1 ボリュームをアタッチしていますが、コスト分析の結果、EBS の費用が大きな割合を占めていました。普段の IOPS 使用率は低く、時折バーストが発生する程度です。コストを削減するにはどうすればよいでしょうか？
正解: io1 → gp2 に変更
- gp2 はバーストモデル（最大 3,000 IOPS）で、時々のバーストには十分対応できる
- コストの大部分を占めるリソースの最適化が最も効果的
- CloudFormation は無料（ダミー選択肢として登場しがち）
Multi-Attach
EBS Multi-Attach 対応ボリュームタイプ → io1/io2 のみ
シナリオ: 複数の EC2 インスタンスから同一の EBS ボリュームに同時にアクセスしたいです。Multi-Attach に対応しているボリュームタイプはどれでしょうか？
正解: Provisioned IOPS SSD（io1 / io2）
- gp2 / gp3、st1、sc1 は Multi-Attach 非対応
- 同一 AZ 内のみ（AZ をまたげない）
- 最大16インスタンスまで
スナップショット・復旧
EBS データクローン + 高 I/O + 最速プロビジョニング → スナップショット + FSR
シナリオ: 本番環境の EBS ボリュームから開発用のクローンを作成したいです。クローン直後から高 I/O のパフォーマンスが必要で、できるだけ早くプロビジョニングを完了させたい場合、どのアプローチが最適でしょうか？
正解: EBS スナップショット → FSR 有効化 → スナップショットから新ボリューム作成
- Multi-Attach はクローンではない（共有アクセスであり、データの分離にならない）
- AMI + Instance Store は永続的ストレージではない
- AWS Backup はデータ保護用（高速クローンには不向き）
EBS スナップショット誤削除防止 + 古いものは削除可能 → Recycle Bin
シナリオ: EBS スナップショットの誤削除を防止したいですが、一定期間を過ぎた古いスナップショットは自動的に削除してストレージコストを抑えたいです。どの機能を使えばよいでしょうか？
正解: EBS Snapshot Recycle Bin
- 保持期間内は復元可能、期間経過後に自動で完全削除
- AWS Backup Vault Lock は AWS Backup 経由で作成したもののみ適用
- IAM Deny ではすべての削除がブロックされる（古いものも削除不可）
暗号化
暗号化 EBS ボリュームで暗号化されるもの（3つ選択）
シナリオ: EBS ボリュームの暗号化を有効にした場合、具体的にどのデータが暗号化されるでしょうか？（3つ選択）
正解:
- ボリューム内の保存データ（at-rest）
- ボリュームから作成されたスナップショット
- ボリュームとインスタンス間のデータ移動（in-transit）
- 暗号化 EBS = すべて暗号化
- 暗号化は不可逆（一方通行）
コスト比較
ストレージコスト比較: S3 < EFS < EBS
シナリオ: 1GB のテストファイルを S3 Standard、EBS gp2（100GB プロビジョニング）、EFS Standard にそれぞれ保存した場合、月末のコストが安い順はどうなりますか？
正解: S3（$0.023）< EFS（$0.30）< EBS（$10.00）
- S3 / EFS は使用量課金（1GB 分のみ）
- EBS はプロビジョニング容量課金（100GB 分すべてに課金）
おわりに
EBS は「gp2/gp3 の上限は 16,000 IOPS」「Multi-Attach は io1/io2 のみ」「暗号化は一方通行」という3つのルールを押さえておけば、多くの問題に対応できます。コスト面では「プロビジョニング容量で課金される」という特性を、EFS や S3 との比較問題で忘れないようにしましょう。
間違いや補足があればぜひコメントで教えてください。