EC2ストレージの選び方:EBS・EFS・インスタンスストア

Amazon EC2で使うブロックストレージEBS、共有ファイルストレージEFS、ホスト直結のインスタンスストアを、接続方式、AZ、永続性、共有、拡張、バックアップの観点で比較します。

学習順Step 53 / 101サービスStorage試験ドメイン開発

EC2のストレージを選ぶ視点

Amazon EC2では、インスタンスに接続するストレージの性質がアプリケーションの構成や復旧方法を左右します。選定時は、単に容量や速度だけでなく、ブロック/ファイルのどちらとして扱うか、どのAZから共有するか、インスタンスの停止後もデータを残すか、どの方法でバックアップするかを合わせて考えます。

代表的な選択肢は、ネットワーク経由で接続するブロックストレージの Amazon EBS、複数クライアントで共有するファイルストレージの Amazon EFS、EC2ホストのローカルディスクを使う インスタンスストアです。EFSはインスタンスへブロックデバイスとして「アタッチ」するのではなく、NFSファイルシステムとしてマウントします。

EBS・EFS・インスタンスストアの接続範囲とストレージの種類

3種類のストレージを比較する

観点 Amazon EBS Amazon EFS EC2インスタンスストア
データの形式 ブロックストレージ。OSのファイルシステムやデータベース領域として利用 ファイルストレージ。NFSでディレクトリ/ファイルを共有 ブロックストレージ。インスタンスからローカルディスクのように利用
接続経路 ネットワーク経由でEC2にボリュームをアタッチ VPC内のマウントターゲットを経由してNFSでマウント インスタンスが稼働する物理ホストに直結
主な共有範囲 通常は1つのインスタンス。Multi-Attach対応ボリュームは制約付きで複数台 複数のEC2などのNFSクライアントから同じファイルシステムへアクセス 対応するインスタンス自身に限定
AZとの関係 ボリュームは1つのAZに属し、そのAZ内のインスタンスに接続 Regionalは同一リージョンの複数AZにデータを冗長保存。One Zoneは1つのAZに保存 インスタンスのホストに結び付く。別ホストへ独立したボリュームとして移動できない
永続性 インスタンスと独立して保持可能。終了時に削除する設定には注意 インスタンスのライフサイクルと独立してファイルを保持 一時用途。停止・休止・終了時にデータが失われる
容量・性能の拡張 ボリューム変更や追加で拡張。上限や性能はボリューム/インスタンスタイプに依存 容量はファイルの追加・削除に応じて弾力的に増減。スループット設定なども選択 容量・デバイス数はインスタンスタイプとサイズに依存。インスタンスストアだけを後から拡張する方式ではない
バックアップ EBSスナップショット AWS Backupなどでバックアップ EBSスナップショットの対象ではない。必要なデータは永続ストレージへ複製
典型的な用途 OS起動ボリューム、アプリケーションデータ、データベース 複数サーバーで共有するファイル、共有コンテンツ キャッシュ、バッファー、一時ファイル、再生成可能な作業データ

Amazon EBS:永続的なブロックストレージ

EBSボリュームはEC2にネットワーク経由で接続するブロックデバイスです。OSの起動ディスク、アプリケーションが使うファイルシステム、データベースのデータ領域など、ブロックデバイスを必要とする用途に適しています。インスタンスの停止中もボリュームは保持され、インスタンス終了後も削除設定が無効であればデータを残せます。

AZ内でのアタッチと付け替え

EBSボリュームは作成した同じAZ内のEC2インスタンスにのみアタッチできます。別AZのインスタンスへ直接つなぎ替えることはできません。ボリュームを別AZで使いたい場合は、スナップショットから目的のAZに新しいボリュームを作成します。

データボリュームはインスタンスからデタッチし、同じAZ内の別のインスタンスへ付け替えることができます。これは、インスタンスとデータのライフサイクルを分離する方法です。ただし、ルートボリュームの終了時削除(Delete on termination)設定などにより終了時の扱いが変わるため、重要データでは設定とバックアップの両方を確認します。

EBSのMulti-Attachは限定的な共有

EBS Multi-Attachを有効にすると、対応する io1またはio2 Provisioned IOPS SSD ボリュームを、同一AZにある複数のインスタンスへ同時にアタッチできます。Nitro Systemベースのインスタンスでは最大16台までが上限です(対応OSやインスタンスタイプなどの条件もあります)。

Multi-Attachは、複数ホストで同じブロックデバイスを扱う仕組みです。XFSやEXT4など一般的なファイルシステムを複数サーバーから同時にマウントして安全に書き込めるようにする機能ではありません。データ整合性を保つには、クラスターファイルシステムやアプリケーション側の書き込み制御が必要です。また、同一AZ内の機能であり、複数AZ共有の代替にはなりません。

複数AZのEC2群で同じファイルを同時に扱いたい要件では、ファイル共有を提供するEFSが適切な候補です。反対に、単一インスタンスのOSやデータベースにはEBSが基本です。

EBSスナップショット

EBSスナップショットは、ボリュームのある時点の状態を保存するバックアップです。スナップショットは増分方式で、直近のスナップショット以降に変更されたブロックを保存します。データはAWSが管理するS3上に保存されますが、利用者がS3バケットとして直接参照・操作するものではありません。スナップショットのデータはリージョン内の複数AZに自動的に複製され、同じリージョン内の任意のAZに新しいEBSボリュームを復元できます。

作成しただけで自動的に定期バックアップされるわけではありません。定期取得が必要なら、Amazon Data Lifecycle ManagerやAWS Backupなどでスケジュールを設定します。スナップショットはEBSボリュームを保護するもので、EC2インスタンス全体の設定やアプリケーションの整合性まで自動で保証するものではありません。

Amazon EFS:複数クライアントで使うファイルストレージ

Amazon EFSは、NFSv4プロトコルで利用するマネージド型の弾力的なファイルストレージです。EC2インスタンスはVPC内のマウントターゲットへ接続し、ファイルシステムをマウントして一般的なファイルやディレクトリとして読み書きします。複数のNFSクライアントから同じファイルシステムに同時アクセスできるため、複数インスタンス間のファイル共有に適しています。

EFSの容量は、ファイルを追加・削除すると自動的に増減します。容量を事前に固定して割り当てるEBSボリュームとは異なります。性能にはパフォーマンスモードやスループットモードなどの選択肢があり、アプリケーションのレイテンシや処理量に合わせて設計します。

RegionalとOne Zone

EFSの耐障害性を考える際は、ファイルシステムの種類を区別します。

  • Regional:1つのAWSリージョン内の複数AZにデータを冗長保存します。複数AZで稼働するEC2から共有する構成に適し、AZ障害への耐性が必要なときの標準的な選択肢です。
  • One Zone:データを1つのAZに保存します。Regionalとは冗長化の範囲が異なり、そのAZ全体の障害ではデータを失う可能性があります。コストと可用性要件を比較し、必要に応じてバックアップを設計します。

Regional EFSではAZごとにマウントターゲットを構成でき、同一リージョンの異なるAZにある複数インスタンスから利用できます。One Zoneでも別AZのインスタンスからアクセス自体はできますが、データの配置が複数AZに広がるわけではなく、AZ間通信のコストや遅延も考慮が必要です。したがって、「複数AZからマウント可能」と「データが複数AZに冗長保存されている」は同じ意味ではありません。

EFSはブロックデバイスのようにインスタンスからデタッチするのではなく、クライアント側でアンマウントします。ファイルシステム自体はインスタンスの起動・終了とは別に存続します。バックアップにはAWS Backupを利用でき、バックアップポリシーや復旧要件に合わせて保護を構成します。

EC2インスタンスストア:ホストに直結する一時領域

インスタンスストアは、EC2インスタンスが動作する物理ホストに直結したディスクを使うブロックレベルの一時ストレージです。ネットワーク越しのEBSボリュームではなく、ローカルディスクとして利用します。インスタンスタイプによっては提供されない場合があり、利用可能な容量やデバイス数もインスタンスタイプとサイズで異なります。

ホストローカルの高いI/O性能を活かせるため、再生成できるキャッシュ、バッファー、スクラッチ領域、一時ファイルなどに向いています。一方で、インスタンスストアをEBSのようにインスタンスから独立してデタッチしたり、スナップショットから復元したりすることはできません。インスタンス終了後にも必要なデータは、EBS、EFS、Amazon S3などへ複製してください。

データの保持条件を混同しないことが重要です。 インスタンスの再起動(reboot)ではインスタンスストアのデータは保持されますが、インスタンスの停止(stop)、休止(hibernate)、終了(terminate)では失われます。したがって、停止・休止後に再開しても一時領域の内容が残る前提で設計してはいけません。

インスタンスストアにはインスタンスタイプに応じてNVMe SSDなどのSSDやHDDが使われます。NVMeインスタンスストレージはハードウェア上で暗号化され、暗号鍵はデバイスごとに生成されます。停止または終了で鍵が破棄され、利用者が暗号化を無効にしたり独自鍵を指定したりすることはできません。実際に選べるメディアや仕様はインスタンスタイプごとに確認します。

要件から選ぶ

要件 選択の考え方
1台のEC2にOSディスクやデータベース用の永続ブロックデバイスが必要 EBSを使う。AZ境界、ボリュームタイプ、バックアップと終了時削除設定を確認
複数AZのアプリケーションサーバーで同一のファイルを読み書きしたい Regional EFSを検討する。NFSアクセス、マウントターゲット、ネットワーク/権限、バックアップを設計
同一AZ内で対応インスタンスから共有ブロックボリュームを使う特殊な構成 EBS Multi-Attachを検討する。対応ボリューム・OS・インスタンスの制約とクラスターファイルシステム等の整合性管理が前提
再作成可能な一時データをローカルI/Oで処理したい インスタンスストアを使う。停止・休止・終了で失われる前提でアプリケーションを設計
EBSボリュームを別AZに移したい 元のボリュームを直接移動せず、スナップショットから移動先AZに新規作成

試験で押さえる区別

  • EBS=ブロック、EFS=ファイル、インスタンスストア=ホストローカルの一時ブロック。
  • EBSは永続的だがAZ単位。別AZで利用するにはスナップショットから新しいボリュームを作る。
  • EFSは複数クライアントでファイルを共有する。Regionalは複数AZに冗長化し、One Zoneは単一AZに保存する。
  • EBS Multi-Attachは対応するio1/io2を同一AZの複数インスタンスへ接続する機能であり、一般的なファイルシステムの同時書き込みを自動で安全にする機能ではない。
  • インスタンスストアはローカルで高性能な一時領域。再起動では保持される一方、停止・休止・終了では失われる。
  • 永続データの保護では、EBSはスナップショット、EFSはAWS Backupなどを使う。バックアップは要件に合わせて明示的に設定する。

公式ドキュメント

重要ポイント

  • ▸EBSはAZ単位の永続ブロックストレージで、インスタンスからデタッチして同一AZ内の別インスタンスへ付け替えられる
  • ▸EFSはNFSで複数クライアントから共有する弾力的なファイルストレージ。RegionalとOne Zoneで冗長化範囲が異なる
  • ▸EBS Multi-Attachは対応するio1/io2を同一AZの最大16台のNitroインスタンスに接続する機能で、EFSのような共有ファイルシステムではない
  • ▸インスタンスストアはホストローカルの一時ブロックストレージで、停止・休止・終了でデータが失われる
  • ▸EBSのスナップショットとEFSのAWS Backupは永続データの保護に使えるが、インスタンスストア自体にスナップショット機能はない

このトピックの学習を完了しますか?

完了状態はいつでも切り替えられます