Amazon EBSのボリュームタイプ・性能・データ保護

Amazon EBSの役割

**Amazon Elastic Block Store（Amazon EBS）**は、Amazon EC2などのコンピューティングリソースにアタッチして利用するブロックレベルのストレージサービスです。OSからはブロックデバイスとして認識され、ファイルシステム、アプリケーションデータ、データベース領域などに利用できます。

EBSボリュームはEC2インスタンスの物理ホストに直接結び付くインスタンスストアとは異なり、インスタンスの停止後も保持できます。インスタンス終了後もデータを残せるかは、ボリュームのDelete on termination設定などに左右されます。したがって、永続性を前提にする場合はボリュームのライフサイクル設定とバックアップ方針も確認します。

EBSボリュームは作成した1つのアベイラビリティーゾーン（AZ）に属し、その同じAZにあるEC2インスタンスに接続します。異なるAZへボリュームを直接アタッチすることはできません。別AZにデータを用意するには、スナップショットからそのAZに新しいボリュームを作成します。

EBSはボリュームデータを保護するため、AZ内で冗長化された設計になっています。これはハードウェア障害への耐性を高めますが、ボリュームが複数AZに自動複製されることや、誤削除・アプリケーションの論理破損から復元できることを意味しません。可用性・耐久性の設計には、必要に応じてスナップショット、別AZでの復元、アプリケーション側の複製を組み合わせます。

容量・性能の変更

EBSはボリュームサイズを必要に応じて変更でき、Elastic Volumesに対応したインスタンスでは、ボリュームをデタッチしたりインスタンスを再起動したりせずにサイズやタイプ、性能を変更できる場合があります。利用中のインスタンス、ボリュームタイプ、現在の状態などの条件は事前に確認してください。

重要な制約として、既存ボリュームのサイズは増やすことはできますが、直接小さくすることはできません。小さい容量に移行したい場合は、より小さなボリュームを別に用意し、ファイルコピーやアプリケーションレベルの移行でデータを移します。サイズ変更後にOSから使用可能容量を認識させるには、パーティションやファイルシステムの拡張が必要になることがあります。ボリューム容量を増やしただけで、ファイルシステムまで自動的に拡張されたと決めつけないようにします。

EBSはAmazon S3のようにオブジェクトを追加するだけで保存領域が自動拡大するサービスではありません。ボリュームをどのサイズで確保するか、またワークロードのIOPS・スループット要件をどう満たすかを利用者が決定します。gp3など一部のタイプでは性能を容量から切り離して設定できますが、ボリュームやEC2インスタンスの上限、ワークロードのI/O特性も性能に影響します。

ボリュームタイプをワークロードで選ぶ

EBSのボリュームタイプは、SSDとHDD、さらにIOPSを重視するかスループットを重視するかで選びます。SSDは小さな読み書きを多数行うトランザクション処理に向き、HDDは大きなデータを連続的に読み書きする処理に向きます。どのタイプでも「高性能なタイプなら、あらゆる指標で必ず速い」とは限りません。必要なIOPS、スループット、レイテンシ、容量と費用を一緒に見ます。

分類	ボリュームタイプ	向いているワークロード	選定上の要点
汎用SSD	gp3	ブートボリューム、開発・テスト、仮想デスクトップ、中規模の単一インスタンスDBなど幅広い用途	汎用SSDの最新世代。IOPSとスループットをボリューム容量とは独立して調整できる。gp3自体はバーストクレジット方式ではない
汎用SSD	gp2	従来型の汎用SSDを使う既存環境	性能は容量に応じて増加し、小さなボリュームではIOPSクレジットによるバーストが関係する。必要に応じてgp3への変更を検討
Provisioned IOPS SSD	io2 Block Express	高いIOPS、安定した性能、低レイテンシ、耐久性が求められるI/O集約型の重要システム	io2の現行アーキテクチャ。高い性能上限を活かすには対応するNitroベースのインスタンスなどが必要
Provisioned IOPS SSD	io1	一貫したプロビジョンドIOPSを必要とするI/O集約型DBなど	IOPSを指定して利用するSSD。io2とは上限や耐久性などの特性が異なる
スループット最適化HDD	st1	ログ処理、ビッグデータ、データウェアハウスなどの大きな連続I/O	IOPSよりスループットを重視。ランダムI/O中心の用途には適さず、ブートボリュームにはできない
Cold HDD	sc1	アクセス頻度が低く、低価格を重視するスループット中心のデータ	HDDの中でも低頻度アクセス向け。ブートボリュームにはできない

汎用SSD：gp3とgp2

gp3は汎用SSDの最新世代で、多くの一般的な用途に使えます。IOPSやスループットをボリュームサイズとは独立して設定できるため、性能を上げる目的だけで容量を余分に確保する必要を抑えられます。ベースライン性能を超える追加IOPSやスループットには追加料金がかかるため、必要量を見積もって設定します。

gp2ではボリュームサイズが性能に影響し、サイズの小さいボリュームで一時的にベースラインを超えるときはIOPSクレジットが関係します。gp2とgp3は同じ汎用SSDでも性能の決まり方が異なります。数字だけを見て差を判断するのではなく、IOPS・スループットの設定方法やワークロードに対する性能を比較してください。

Provisioned IOPS SSD：io1とio2

アプリケーションに安定した高IOPSや低レイテンシが求められる場合は、IOPSを指定する Provisioned IOPS SSD を検討します。代表例は、ストレージI/Oが性能に直結する重要なデータベースなどです。io2 Block Expressは高性能・高耐久の要件に対応する世代で、現行のio2ボリュームはBlock Expressを使用します。一方、実際に達成できる性能は、ボリュームだけでなくEC2インスタンスタイプやI/Oサイズなどにも左右されます。

プロビジョンドIOPSは指定した性能に応じて費用が発生します。gp3より高性能な選択肢というだけで常に採用するのではなく、アプリケーションのI/O要件とコストを照合します。

HDD：st1とsc1

st1とsc1は、ランダムな小規模I/Oを多数行う用途ではなく、連続した大きなデータ転送でスループットを活用するHDDです。st1はログ分析やビッグデータ処理など、スループットを必要とする用途向けです。sc1はアクセス頻度が低く、コストを抑えたい用途向けです。どちらもブートボリュームとして利用できないため、EC2のOS起動ディスクにはSSD系など対応するタイプを選びます。

世代番号の読み方

タイプ名の数字は、その系統の世代を区別する手掛かりになることがあります。たとえば汎用SSDでは gp3がgp2より新しい世代です。ただし、数字が付いていればどのタイプでも単純に「数字の大きい方が常に新しく、あらゆる性能が高い」と一般化できるわけではありません。io1/io2、gp2/gp3のように同じ系統の世代関係を確認し、最新の仕様表で選択肢ごとの性能と対応機能を照合します。

暗号化とスナップショット

AWS KMSによる暗号化

EBSはAWS Key Management Service（AWS KMS）のキーを使った暗号化に対応しています。EBSボリューム作成時に暗号化を有効にし、必要に応じて使用するKMSキーを指定します。暗号化によって、ボリュームとスナップショットの保存データに加えて、EC2インスタンスとEBSの間で転送されるデータも保護されます。

アカウントやリージョンでEBS暗号化のデフォルト設定を有効にすれば、新たに作成するボリュームやスナップショットを暗号化する運用を標準化できます。KMSキーを利用するには、そのキーを使用するための権限も必要です。暗号化されていない既存ボリュームをそのまま暗号化状態へ切り替えるのではなく、スナップショットを取得し、暗号化したコピーから新しいボリュームを作成する方法を使います。

スナップショットによるバックアップ

EBSスナップショットは、ボリュームのある時点の状態から新しいボリュームを復元するためのバックアップです。スナップショットは増分方式で、前回のスナップショットから変更されたブロックを保存します。データの保存先はAWSが管理するAmazon S3ですが、利用者が自分のS3バケットやS3 APIからスナップショットデータを直接参照するものではありません。

スナップショットのデータはリージョン内の複数AZに複製され、そのリージョン内の任意のAZに新しいEBSボリュームを作成できます。必要に応じて別リージョンや別アカウントへコピーすることもでき、バックアップ、長期保管、災害復旧、環境複製に利用できます。

EBSのデータが自動的に定期バックアップされるわけではありません。 復旧要件に合わせてスナップショットを定期取得し、保持期間を管理します。Amazon Data Lifecycle ManagerやAWS Backupを使うと、スナップショット取得やライフサイクル管理を自動化できます。スナップショットのコピーや復元で暗号化KMSキーを使う場合は、必要なKMS権限も確認します。

Multi-Attachによる複数インスタンス接続

通常のEBSボリュームは1つのEC2インスタンスに接続して利用します。Multi-Attachを有効にすると、1つの対応ボリュームを複数のEC2インスタンスへ同時にアタッチできます。

Multi-Attachがサポートされるのはio1またはio2のProvisioned IOPS SSDのみです。接続先は同一AZ内で、Nitro Systemベースのインスタンスでは最大16台までです。OSやインスタンスタイプなどにも条件があります。Windowsインスタンスではio2のみがサポート対象となるなど、OSによる違いもあります。

Multi-Attachは共有ブロックデバイスを接続する機能で、通常のファイルシステムを複数ホストから安全に同時書き込みできるよう自動調整する機能ではありません。データ破損を防ぐには、クラスターファイルシステムやアプリケーション側の書き込み制御が必要です。また、Multi-Attachボリュームをブートボリュームとして使うことはできません。複数AZにまたがる共有ストレージやファイル共有が要件なら、EFSなど別の方式を検討します。

選択の要点

要件	選択の考え方
一般的なEC2ブートディスクや、幅広い用途のSSDボリューム	gp3を基本候補とし、必要な容量・IOPS・スループットを設定
ストレージ性能が必要なI/O集約型データベース	io1/io2を検討し、必要なIOPS・レイテンシとインスタンス側の上限を確認
ログや分析データを連続的に大量処理	スループット重視のst1を検討
低頻度にアクセスするHDDデータを低コストで保管	sc1を検討。ブート用途には使用しない
ボリュームの容量不足を解消	ボリュームサイズを拡張し、必要に応じてOS側のパーティションやファイルシステムも拡張
ボリュームを小さくして費用を抑えたい	既存ボリュームを縮小するのではなく、小さな新規ボリュームへデータを移行
バックアップやAZ障害に備えた復旧	スナップショットを定期取得し、復旧先AZや必要なリージョンへのコピーを計画
複数EC2から1つのブロックボリュームにアクセス	同一AZのio1/io2 Multi-Attachを検討し、クラスタ整合性とブート不可の制約を確認

公式ドキュメント

• Amazon EBSボリュームタイプ
• 汎用SSD gp3とgp2
• Provisioned IOPS SSD io2 Block Expressとio1
• EBSボリュームの変更とElastic Volumes
• EBSスナップショット
• Amazon EBS暗号化
• EBS Multi-Attach
• Amazon EBSの料金