Amazon EBS (Elastic Block Store)

は、インスタンスにアタッチして使うサービスです。からはディスクのように見えるため、ルートボリューム、データベース、低遅延が必要なアプリケーションの永続ディスクとして使います。

SAA では、単に「EC2 のディスク」と覚えるだけでは不十分です。ワークロードが重視か、重視か、容量重視か、単一インスタンス向けか、複数インスタンス共有が必要かを見て、EBS、、、を切り分けます。

Point

EBS = Elastic Block Store の略です。
Elastic は「伸縮できる」、Block Store は「ブロック単位の保存場所」という意味です。
試験では「EC2 にアタッチする低遅延の永続ディスク」として覚えると判断しやすいです。
和訳
- Elastic: 伸縮性のある
- Block: かたまり、ブロック
- Weblio英和辞書「elastic」

概要

は、と組み合わせて使う永続的なストレージです。インスタンスを停止しても EBS ボリュームのデータは残り、別のインスタンスへ付け替えることもできます。のサーバーに外付けディスクを接続するイメージに近いですが、AWS ではボリュームタイプ、サイズ、、、暗号化、を設計要件に合わせて選びます。

EBS ボリュームは基本的に 1 つの内に作成され、その AZ 内の EC2 にアタッチします。複数 AZ にまたがる共有ファイルシステムが必要な場合は、オブジェクト保存が必要な場合は、インスタンスに内蔵された一時的な高速ストレージでよい場合はと比較します。

SAA では、データベース、ブートボリューム、暗号化、スナップショット、復旧、性能不足への対処がよく問われます。特に、単一ボリュームの性能上限に近い場合は、ボリュームタイプ変更、IOPS/スループット調整、EC2 側の EBS 帯域、 0 による分散を切り分けます。

主要技術

①ボリュームタイプと性能軸

のボリュームタイプは、主に系と系に分かれます。SSD 系は小さい I/O を頻繁に読み書きするトランザクション処理に向き、が重要です。HDD 系は大きなデータを順番に読み書きする処理に向き、が重要です。

Point

IOPS = Input/Output Operations Per Second の略です。
1 秒あたりに何回読み書きできるかを表す指標です。
小さいデータを何度も読むデータベースでは、IOPS が重要になりやすいです。
Throughput（スループット） は、1 秒あたりにどれだけのデータ量を運べるかを表します。
試験では、
- IOPS: 読み書きの回数
- スループット: 運べるデータ量と分けて考えます。
和訳
- Input: 入力
- Output: 出力
- Operation: 操作
- Weblio英和辞書「operation」

ボリュームタイプ	主な用途	判断ポイント
gp3	一般的なブートボリューム、アプリケーション、開発・検証	容量、IOPS、スループットを個別に調整しやすい汎用 SSD です。
gp2	既存環境で使われる汎用 SSD	容量に応じて性能が変わるため、新規設計では gp3 と比較します。
io1 / io2	I/O が多いデータベース、低遅延が必要な業務システム	プロビジョンド IOPS により、安定した高 IOPS を必要とする場合に選びます。
io2 Block Express	非常に高い IOPS、低、ミッションクリティカルな DB	io1 より高い性能とが必要な場合に検討します。
st1	ログ処理、、大きな順次読み書き	IOPS よりスループットを重視する HDD 系です。
sc1	低頻度アクセスでコストを抑えたい大容量データ	性能より低コストを重視するコールドデータ向けです。

⚠️ 頻出: 「データベース」「低遅延」「ランダム I/O」「安定した IOPS」は SSD 系、特に io1/io2 を考えます。「ログ処理」「大容量の順次読み書き」「スループット」は st1 を考えます。

1 ボリュームあたりの上限は、gp3 が 80,000 IOPS・2,000 MiB/s、io1 が 64,000 IOPS、io2 Block Express が 256,000 IOPS・4,000 MiB/s です (256,000 IOPS を出すには Nitro ベースのインスタンスが必要です)。耐久性は gp3・io1 が 99.8〜99.9%、io2 Block Express が 99.999% です。必要な IOPS がどの上限を超えるかで、選べるタイプが決まります。

gp3 は容量にかかわらず 3,000 IOPS と 125 MiB/s のベースラインが保存料金に含まれ、GB あたりの単価は gp2 より最大 20% 安くなります。gp2 は容量 1 GiB あたり 3 IOPS で性能が決まるため、IOPS を得るために必要以上の容量を確保している gp2 は、gp3 へ変更すると費用を下げられます。

ボリュームの容量拡張、タイプ変更、IOPS やスループットの変更は、Elastic Volumes によりアタッチしたまま行えます。インスタンスの停止やデタッチは不要で、容量を増やした後は側でファイルシステムを拡張します。容量の縮小はできません。

複数のから 1 つのブロックデバイスを共有したい場合は Multi-Attach を使います。対象は io1/io2 だけで、同じの Nitro ベースのインスタンス最大 16 台にアタッチできます。XFS や ext4 などの通常のファイルシステムは同時アクセスを想定していないため、クラスター対応のファイルシステムやアプリケーション側で書き込みを制御します。

②EBS 最適化と EC2 側の帯域

の性能は、ボリュームだけで決まりません。インスタンスが EBS へ出せる帯域、EBS 最適化、I/O サイズ、キュー深度、やファイルシステムの設定にも影響されます。

プロビジョンドボリュームに高い IOPS を設定しても、EC2 側の EBS 帯域が不足していると期待した性能は出ません。SAA では、ストレージ性能不足の問題で「ボリュームタイプを上げる」だけでなく、「が EBS 性能を引き出せるか」を確認します。

確認する観点	内容	試験での見方
ボリュームタイプ	gp3、io1、io2 など	ワークロードに合う性能軸を選びます。
プロビジョンド IOPS	必要な IOPS を指定できるか	DB など安定 IOPS が必要な場合に重要です。
EC2 の EBS 帯域	インスタンスが EBS に出せる上限	ボリュームを強化しても EC2 側が上限になる場合があります。
I/O サイズ	小さい I/O か大きい I/O か	IOPS とのどちらが効くかを判断します。

⚠️ 頻出: 「高 IOPS を設定したのに性能が出ない」場合は、ボリュームの上限だけでなく、EC2 インスタンスの EBS 帯域、EBS 最適化、複数ボリュームへの分散も確認します。

③RAID 0 による複数 EBS ボリュームのストライピング

単一ボリュームで必要な I/O 性能に届かない場合、同じ性能の複数 EBS ボリュームをにアタッチし、レベルで 0 を構成して I/O を分散できます。RAID 0 はストライピングにより、複数ボリュームのとを合算する考え方です。

RAID 0 は性能改善には有効ですが、冗長化ではありません。配下の 1 つのボリュームに障害が起きると、RAID 0 全体のデータを失う可能性があります。そのため、、バックアップ、マルチ構成のデータベース、などと組み合わせて復旧設計を行います。

RAID 構成	主な目的	EBS での試験判断
RAID 0	性能向上、I/O 分散	単一ボリュームの性能上限を超えたい場合に検討します。
RAID 1	ミラーリング	EBS 自体が AZ 内で複製されるため、試験では性能改善目的では選びにくいです。
RAID 5 / 6	パリティによる冗長化	パリティ書き込みで IOPS を消費するため、EBS では推奨されにくいです。

⚠️ 頻出: 「単一の io1/io2 ボリュームで期待する I/O 性能が出ない」「データベースのストレージスループットを上げたい」「複数 EBS に I/O を分散したい」といった条件では、複数 EBS ボリュームを RAID 0 でストライピングする選択肢を考えます。ただし、EC2 側の EBS 帯域を超える構成にはできません。

④スナップショット、暗号化、バックアップ

は、EBS ボリュームのバックアップをに保存する仕組みです。初回は必要なデータを保存し、以後は増分で保存されます。スナップショットから新しい EBS ボリュームを作成できるため、バックアップ、復旧、環境複製、別へのコピーに使います。

機能	目的	試験での判断ポイント
Snapshot	ボリュームのバックアップ	復旧、複製、作成の基礎になります。
Fast Snapshot Restore	スナップショット復元直後の初期性能を改善	復元直後から安定性能が必要な場合に検討します。
EBS Encryption	ボリュームとスナップショットの暗号化	キー、権限、コピー時の暗号化を確認します。
Data Lifecycle Manager	スナップショット作成・削除の自動化	定期バックアップや保持期間管理に使います。

スナップショットから作成したボリュームは、各ブロックを初めて読むときに S3 からデータを取り込むため、作成直後の I/O に遅延が出ます。Fast Snapshot Restore をスナップショットとの組で有効にすると、その AZ で作成したボリュームは作成時点で初期化済みとなり、最初からプロビジョンした性能を出せます。

ほとんど復元しないスナップショットを長く保持するなら、EBS スナップショットの層 (EBS Snapshots Archive) へ移します。90 日以上保持するスナップショットの保存費用を最大 75% 下げられる一方、アーカイブ時に増分ではなくフルスナップショットへ変換され、最低保持期間は 90 日、標準層への復元には最大 72 時間かかり、復元するまでボリュームを作成できません。月次・四半期・年次のスナップショットやプロジェクト終了時のスナップショットに向き、日次の増分スナップショットをアーカイブすると、かえって高くなることがあります。

暗号化された EBS ボリュームから作成したスナップショットも暗号化されます。別アカウントや別リージョンへコピーする場合は、KMS キーの権限も含めて設計します。

EBS 暗号化のデフォルト有効化は、アカウントのリージョンごとの設定です。有効にしたリージョンでは、起動テンプレートやスクリプトで暗号化を指定していなくても、新しく作るボリュームとスナップショットのコピーが暗号化されます。既存のボリュームやスナップショットには影響しません。組織全体で強制するなら、ec2:Encrypted 条件で暗号化されていないボリュームの作成を拒否するも使えます。

誤削除への備えには、ごみ箱 (Recycle Bin) と EBS スナップショットロックがあります。ごみ箱は、保持ルールに合う EBS スナップショット、EBS ボリューム、EBS-backed AMI が削除されても、指定した期間は残して復元できるようにします。スナップショットロックは、ロックしたスナップショットを権限にかかわらず誰も削除できないようにする型の保護で、モードとモードがあります。

⑤他ストレージサービスとの使い分け

はに密結合したです。複数サービスの選択肢が並ぶ問題では、「どの単位でアクセスするか」と「どの範囲で共有するか」を見ます。

要件	優先して考えるサービス	理由
EC2 のルートディスク、DB の低遅延ディスク	EBS	ブロックストレージとして EC2 にアタッチします。
複数 EC2 から同時に共有する Linux ファイル		マネージドとして複数インスタンスから使えます。
オブジェクト、画像、ログ、バックアップ		高耐久なです。
一時データ、、超低遅延のローカル処理	Instance Store	インスタンス停止や障害で失われ得る一時ストレージです。
Windows ファイル共有		ベースの Windows 共有に向きます。

Instance Store は高速ですが、永続性が必要なデータベースの主要保存先としては注意が必要です。問題文に「永続的」「停止後も保持」「」「バックアップ」といった条件があれば EBS を優先して考えます。

試験対策

SAA の問題では、ストレージ性能、永続性、共有範囲、バックアップ、暗号化を切り分けます。特に性能問題では、ボリュームタイプだけでなく側の上限や複数ボリューム構成を見落とさないことが重要です。

問題文のキーワード	優先して考える機能	理由
EC2 に低遅延の永続ディスクが必要	EBS	EC2 にアタッチするです。
データベースで安定した高が必要	io1 / io2	プロビジョンド IOPS により性能を指定できます。
単一 EBS ボリュームでは I/O 性能が足りない	複数 EBS + 0	I/O を複数ボリュームへ分散し、IOPS とを合算できます。
高 IOPS を指定したが性能が出ない	EC2 の EBS 帯域、EBS 最適化、I/O 設計	ボリューム性能だけでなくインスタンス側の上限が影響します。
復旧や複製をしたい	Snapshot	EBS ボリュームをバックアップし、新しいボリュームへ復元できます。
複数 EC2 から同じファイルを共有したい	/	EBS は基本的に単一 EC2 向けのブロックストレージです。
一時データでローカル高速処理したい	Instance Store	高速ですが永続性がない点に注意します。

よくある誤答は、性能不足の原因を容量不足だけで考えることです。io1/io2 では、ボリューム容量を増やすだけで常にスループット問題が解決するとは限りません。必要な性能軸が IOPS なのかスループットなのか、単一ボリュームの上限なのか、EC2 インスタンス側の EBS 帯域なのかを確認します。

また、へ変更する選択肢は「高速」に見えますが、永続的なデータベース保存先としては要件に合わないことがあります。停止、終了、障害時のデータ保持が求められる場合は、EBS やマネージドデータベースサービスを優先して考えます。

⚠️ 頻出: EBS の RAID 0 は「冗長化」ではなく「性能向上」のための選択肢です。試験では、単一ボリュームの性能上限を超えたいときに選び、可用性や復旧要件は別途やデータベース側の冗長化で満たします。