Amazon EBS
EC2 インスタンスにアタッチして使用するブロックストレージサービスで、SSD と HDD の複数のボリュームタイプから用途に応じて選択できる
概要
Amazon Elastic Block Store (EBS) は、EC2 インスタンスに接続して使用する高性能なブロックストレージサービスです。ファイルシステムやデータベースのストレージとして利用でき、インスタンスを停止・再起動してもデータが永続化されます。主要なボリュームタイプは汎用 SSD (gp3)、プロビジョンド IOPS SSD (io2)、スループット最適化 HDD (st1)、コールド HDD (sc1) の 4 つで、このほかに従来型の gp2 や io1 も引き続き利用でき、IOPS 性能、スループット、コストのバランスに応じて選択できます。EBS ボリュームは同一アベイラビリティゾーン内で自動的に複製されるため、単一ハードウェアの障害からデータを保護します。スナップショット機能を使えば、ボリュームのポイントインタイムバックアップを S3 に保存し、別のアベイラビリティゾーンやリージョンに復元することも可能です。
gp3 と io2 - IOPS 要件で分かれるボリューム選定
EBS のボリューム選定は、ワークロードが求める IOPS とスループットの数値から逆算します。gp3 (汎用 SSD) はベースラインの IOPS とスループットが料金に含まれ、追加料金でベースラインを超える性能まで拡張できます。ただし IOPS の上限は容量に比例するため、上限に近い IOPS を割り当てるにはそれに見合う容量が必要です。ベースライン値と上限値はボリューム種別ごとに定められているので、設計時は AWS 公式ドキュメントの記載値を確認します。Web サーバーのルートボリューム、中小規模の RDS、開発環境のほとんどは gp3 で十分です。gp2 から gp3 への移行はオンラインで実行でき、同等以上の性能を維持しつつコストを抑えられる場合があります。一方、io2 Block Express は gp3 より高い IOPS 上限に対応し、Oracle や SAP HANA のような大規模データベースで求められるサブミリ秒レイテンシを実現します。Azure Managed Disks でも Premium SSD v2 や Ultra Disk が容量から独立した IOPS 設定に対応しており、両者の違いは上限値よりも運用条件に表れます。Ultra Disk と Premium SSD v2 は OS ディスクとして使えずデータディスク専用である一方、io2 は EC2 のルートボリュームにも選択できます。課金モデルも、io2 が容量とプロビジョンド IOPS の従量課金であるのに対し、Ultra Disk は容量・IOPS・スループットを個別にプロビジョニングし、加えて VM 側で Ultra Disk 対応を有効化する必要があります。Ultra Disk は対応リージョンと VM サイズ・可用性ゾーンの組み合わせにも制約があるため、移行検討時は上限スペックだけでなくこうした条件を確認します。HDD 系では、st1 がログ処理やビッグデータのシーケンシャル読み取りに、sc1 がアクセス頻度の低いアーカイブデータに適しており、GB 単価を大幅に抑えられます。
スナップショットと暗号化の設計
EBS スナップショットは増分バックアップ方式を採用しており、初回のフルコピー以降は変更されたブロックだけを S3 に保存します。この仕組みにより、数 TB のボリュームでも日次スナップショットのコストと作成時間を最小限に抑えられます。スナップショットは別の AZ やリージョンに復元できるため、災害復旧 (DR) 戦略の基盤としても機能します。Amazon Data Lifecycle Manager (DLM) を使えば、スナップショットの作成・保持・削除をスケジュールベースで自動化でき、手動管理の負担を排除できます。暗号化については、アカウントレベルで EBS のデフォルト暗号化を有効にし、KMS のカスタマーマネージドキーを指定するのがベストプラクティスです。キーポリシーで暗号化・復号を実行できるプリンシパルを制限し、CloudTrail でキー使用履歴を監査することで、コンプライアンス要件にも対応できます。
コスト最適化とサイジングの勘所
EBS のコスト最適化で最も効果が大きいのは、ボリュームタイプの見直しです。gp2 のまま放置されているボリュームを gp3 に変更することで、性能を維持しつつコストを下げられる場合があります。CloudWatch の VolumeReadOps / VolumeWriteOps メトリクスを確認し、実際の IOPS 消費がベースラインを大幅に下回っているボリュームは過剰スペックの可能性があります。逆に、gp3 の IOPS 上限を超える要件がある場合や、サブミリ秒レイテンシ・複数インスタンスからの Multi-Attach が必要な場合にのみ io2 への移行を検討します。未使用ボリュームの検出も重要で、EC2 インスタンスを終了した後にデタッチ状態で残り続けるボリュームは課金が継続します。AWS Cost Explorer のリソース別コストビューや Trusted Advisor の「使用率の低い Amazon EBS ボリューム」チェックを活用して、定期的に棚卸しを行いましょう。スナップショットについても、DLM で保持期間を適切に設定し、不要な世代が蓄積しないよう管理します。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。