EBSとEFSのコア概念と試験ノート

このトピックが重要な理由

EC2のストレージに関する問題は、AWS試験でも実運用でも頻出です。重要なのは、ブロックストレージ（EBS）と共有ファイルストレージ（EFS）をいつ使い分けるか、さらにスナップショット、ライフサイクル機能、料金トレードオフがアーキテクチャ判断にどう影響するかを理解することです。

EBSの基礎

Amazon EBS（Elastic Block Store）は、EC2向けのネットワーク接続型ブロックボリュームです。

実行中のEC2インスタンスにアタッチ可能
インスタンスのライフサイクルとは独立してデータを保持
通常は同時に1インスタンスへアタッチ（特定のマルチアタッチ例外あり）
1つのAvailability Zone（AZ）にスコープされる

EBSは「ネットワーク接続のUSBドライブ」のように考えると分かりやすいです。デタッチして再アタッチできますが、AZには縛られます。

EBSのアタッチとAZ制約

運用上の重要な挙動:

eu-west-1b で作成したEBSボリュームは eu-west-1b のインスタンスにしかアタッチできない
別AZでデータを使うには、スナップショットを作成し、対象AZで新しいボリュームとして復元する
1つのEC2インスタンスに複数のEBSボリュームを持たせられる
ボリュームは未アタッチのまま保持し、必要時に後からアタッチできる

このAZ境界は試験でよく引っかけポイントになります。

終了時削除（Delete-on-Termination）の挙動

EC2起動時、各EBSボリュームには DeleteOnTermination 設定があります。

ルートボリューム: デフォルトで true のことが多い
追加データボリューム: デフォルトで false のことが多い

つまり、インスタンス終了時は通常ルートストレージは削除されますが、非ルートのデータボリュームは別設定にしない限り保持されます。

EBSボリュームタイプ（試験で重要な見方）

汎用SSD

gp3: ベースライン性能を持ち、IOPSとスループットを独立して設定可能
gp2: 旧世代モデルで、性能とボリュームサイズの結びつきが強い

一般的なワークロード、ブートボリューム、開発/テスト、価格と性能のバランス用途に適しています。

プロビジョンドIOPS SSD

io1 / io2（io2 Block Expressを含む）
低レイテンシ・高一貫性が必要なミッションクリティカル用途（多くはデータベース）向け
非常に高いIOPSと高度な性能保証をサポート

HDDオプション

st1（スループット最適化HDD）: 大容量シーケンシャルスループット用途
sc1（コールドHDD）: 最低コストの低頻度アクセス用途

st1 と sc1 はブートボリュームには使えません。

EBSスナップショット: バックアップと可搬性

スナップショットはEBSボリュームの状態を取得し、次の基盤になります。

バックアップと復元
AZ間移行（別AZでスナップショットを復元）
DR向けのリージョン間コピー
コピー/復元ワークフロー中にKMSを使った暗号化コピー/暗号化ボリュームの作成

ベストプラクティスとして、整合性の問題を避けるため、書き込みアクティビティを抑えているタイミングでのスナップショット取得がより安全です。

スナップショット運用とコスト最適化機能

Data Lifecycle Manager（DLM）

タグベースのポリシーにより、スナップショット/AMIの作成、保持、クリーンアップを自動化します。

定期バックアップのスケジュール
固定数のスナップショット保持
クロスアカウント/クロスリージョンコピーのポリシー対応

Fast Snapshot Restore（FSR）

復元ボリュームのブロックを事前初期化し、初回読み取りレイテンシを削減します。

復元直後から高性能が必要な場合に有用
有効化し続けると高コスト
実用パターン: 一時的に有効化 → ボリューム復元 → 無効化

スナップショットアーカイブ階層

スナップショットをアーカイブ階層へ移動すると、ストレージコストを低減できます（多くの場合大幅削減）。その代わり復元は即時ではなく、時間単位で遅くなります。

スナップショット用Recycle Bin

保持ルールにより、誤削除から保護します（例: 完全削除まで数日〜数か月保持）。

EFSの基礎

Amazon EFS（Elastic File System）は、マネージドNFSファイルシステムです。

複数のEC2インスタンスから同時にマウント可能
1リージョン内の複数AZにまたがって利用可能
共有ファイル用途（CMS、Webコンテンツ、共有アプリデータ）に最適
Linux中心（NFS/POSIXセマンティクス）
従量課金で容量を自動スケール

EBSと比べると、EFSは一般に高価ですが、共有かつマルチAZでのファイルアクセスを提供します。

EFSの性能モードとスループットモード

性能モード

General Purpose: 低レイテンシ、多くのアプリでデフォルト
Max I/O: 高スループット・高並列性、ただしレイテンシは高め

スループットモード

Bursting: 保存データ量に応じてスループットが増加
Provisioned: スループット目標値を明示的に設定
Elastic: 需要に応じてスループットを自動調整（トラフィック変動が読みにくい場合に有効）

EFSストレージクラスとライフサイクル

EFSはライフサイクルポリシーでファイルを階層間移動できます。

Standard: 頻繁にアクセスするデータ向け
EFS-IA: 低頻度アクセス向け
Archive: ほとんどアクセスしないデータ向け

ライフサイクルを適切に調整すると、共有ファイルアーキテクチャを維持しながらストレージコストを大きく下げられます。

覚えておきたいハンズオンの気づき

EBSはEC2のブロックデバイスとして表示され、アタッチ/デタッチ操作は分かりやすい
AZ不一致だと対象インスタンスへEBSをアタッチできない
EC2の終了操作で DeleteOnTermination の影響をすぐ確認できる
EFSではマウントターゲット/セキュリティグループ設定がAZ間アクセスの要
異なるAZの2インスタンスが同じEFSマウントパスを同時に読み書きできる

EBS vs EFS クイック判断ガイド

次の要件があるなら EBS:

単一インスタンス向けブロックストレージ
ブートボリューム
ボリューム単位で予測しやすい性能

次の要件があるなら EFS:

多数のLinuxインスタンス向け共有ファイルシステム
マルチAZ同時アクセス
サイズを事前確保せずに弾力的な容量

重要ポイント

EBSはAZスコープのブロックストレージで、EC2中心のディスクやブートボリュームに最適
スナップショットはバックアップ、移行、DRワークフローの中核
EFSはLinuxワークロード向けにAZをまたいで共有・拡張可能なNFSストレージ
コスト/性能最適化は、適切なボリュームクラス、スループットモード、ライフサイクルポリシーの選択で決まる
試験問題では多くの場合、スコープ（単一インスタンス vs 共有）、AZ挙動、コスト/性能トレードオフが問われる

Claudeによる翻訳