Amazon EBS のボリューム設計と運用 - gp3 ・ io2 の選定基準とスナップショット戦略
gp3・io2 のボリュームタイプ選定基準を明確にし、IOPS・スループットの設計指針とスナップショットによるバックアップ戦略を実践的に紹介します。
EBS ボリュームタイプの選定基準
EBS には汎用 SSD (gp3 / gp2)、プロビジョンド IOPS SSD (io2 / io2 Block Express と旧世代の io1)、スループット最適化 HDD (st1)、コールド HDD (sc1) の 4 カテゴリがあります。選定の出発点は gp3 です。gp3 はベースラインとして 3,000 IOPS と 125 MiB/s を追加料金なしで提供し、必要に応じて最大 80,000 IOPS ・ 2,000 MiB/s まで独立してスケールできます (2026 年 8 月時点)。ただし上限まで引き上げるには条件があります。追加 IOPS はボリュームサイズ 1 GiB あたり 500 IOPS の比率で確保でき、最大の 80,000 IOPS にはボリュームサイズ 160 GiB 以上が必要です。追加スループットはプロビジョンド IOPS 1 IOPS あたり 0.25 MiB/s の比率で確保でき、最大の 2,000 MiB/s には 8,000 IOPS 以上 (ボリュームサイズ 16 GiB 以上) が必要です。16,000 IOPS ・ 1,000 MiB/s を gp3 の上限として書いた設計指針が手元に残っている場合は、現行の上限で見直す余地があります。gp2 では IOPS がボリュームサイズに比例するため、IOPS を増やすにはボリュームを大きくする必要がありましたが、gp3 ではこの制約がなくなりました。io2 Block Express はデータベースワークロード向けで、1 ボリュームあたり最大 256,000 IOPS を実現します。io2 / io2 Block Express は 99.999% の設計上の耐久性 (年間故障率 0.001% 以下) を備え、汎用 SSD の 99.8〜99.9% より 1 桁高い水準にあるため、Oracle や SAP HANA のようなミッションクリティカルなワークロードに適しています。これは設計上の耐久性の値であり、サービスレベルアグリーメント (SLA) で保証された数値ではない点に注意してください。st1 はビッグデータやログ処理など、シーケンシャルリードが中心のワークロードに向いており、最大 500 MiB/s のスループットを低コストで提供します。
IOPS とスループットの設計
IOPS の要件を見積もるには、アプリケーションの I/O パターンを把握する必要があります。データベースのようなランダム I/O が多いワークロードでは IOPS が律速になり、ETL やログ分析のようなシーケンシャル I/O ではスループットが律速になります。CloudWatch の VolumeReadOps、VolumeWriteOps メトリクスで実際の IOPS を計測し、VolumeQueueLength が継続的に高い水準で推移している場合は I/O 待ちが発生している可能性があるため、要調査の対象になります (適正な値はボリュームタイプや I/O サイズによって変わるため、単一のしきい値で機械的に判定はできません)。gp3 でベースラインの 3,000 IOPS を超える分を追加する場合、1 IOPS あたり約 0.006 USD/月 (2026 年 8 月時点・東京リージョン) のコストが発生します。必要な IOPS が gp3 の上限に収まるうちは、まず gp3 側で引き上げるのが基本方針です。io2 への移行を検討するのは、gp3 の上限を超える IOPS が必要な場合、99.999% の耐久性が要件として求められる場合、あるいはミリ秒未満の安定した低レイテンシが求められる場合です。io2 のプロビジョンド IOPS 単価は使用量に応じた段階制で、東京リージョンでは 32,000 IOPS までが 1 IOPS あたり約 0.074 USD/月、32,001 IOPS から 64,000 IOPS までが約 0.0518 USD/月、64,000 IOPS を超える分が約 0.0363 USD/月となります (2026 年 8 月時点)。最初の段階では gp3 の 10 倍以上の単価になるため、本当に必要な IOPS を正確に見積もることがコスト最適化の鍵です。
スナップショット戦略とバックアップ設計
EBS スナップショットは増分方式で、前回のスナップショット以降に変更されたブロックのみを S3 に保存します。初回は全データをコピーしますが、 2 回目以降は差分のみのため、ストレージコストと作成時間が大幅に削減されます。スナップショットの自動化には Amazon Data Lifecycle Manager (DLM) を使用します。 DLM ポリシーでタグベースのスケジュールを定義し、日次・週次のスナップショット作成と世代管理を自動化できます。本番環境の構成例としては、 DLM で日次スナップショットを 7 世代、週次スナップショットを 4 世代保持するといった組み合わせが挙げられます。保持世代数は復旧目標 (RPO / RTO) とコンプライアンス要件から決めるものなので、この数値は出発点として捉えてください。クロスリージョンコピーを有効にすれば、リージョン障害時の DR にも対応できます。 Fast Snapshot Restore (FSR) は、スナップショットから復元したボリュームの初回アクセス時に発生するレイテンシペナルティを排除する機能です。データベースのように初回アクセスのレイテンシが許容できないワークロードでは FSR の有効化を推奨します。
EBS の料金
(2026 年 8 月時点・東京リージョン (ap-northeast-1) のオンデマンド料金) gp3 は 1 GB あたり月額 0.096 ドルで、3,000 IOPS と 125 MiB/s のスループットが追加料金なしで含まれます。これを超える分は、1 IOPS あたり月額 0.006 ドル、1 MiB/s あたり月額 0.048 ドルで追加します。gp2 は 1 GB あたり月額 0.12 ドルなので、同じ容量なら gp3 が 20% 安く、しかも IOPS とスループットを容量から切り離して設定できる点が優位です。io2 は 1 GB あたり月額 0.142 ドルに加えてプロビジョンド IOPS 分が課金され、その単価は使用量に応じた段階制です (32,000 IOPS までが 1 IOPS あたり月額 0.074 ドル、32,001 IOPS から 64,000 IOPS までが 0.0518 ドル、64,000 IOPS を超える分が 0.0363 ドル)。HDD 系は IOPS の課金がなく、st1 (スループット最適化 HDD) が 1 GB あたり月額 0.054 ドル、sc1 (コールド HDD) が 0.018 ドルです。単価はリージョンによって異なるため、上記はあくまで東京リージョンでの比較として読み、実際の見積もりは利用リージョンの公式料金表で確認してください。方針としては gp3 をデフォルトの選択肢とし、gp3 の上限を超える IOPS や 99.999% の耐久性が必要な場合にのみ io2 を選びます。あわせて、アタッチされていないボリュームや不要になったスナップショットの棚卸しも効果があります (使っていないボリュームにも容量分の課金が続きます)。
ワークロード別のボリューム選定
EBS のボリュームタイプは、ワークロードの特性に合わせて選びます。多くの一般的な用途には、コストと性能のバランスが良い汎用タイプが適しており、性能を独立して調整できるため柔軟に使えます。データベースのように、高い IOPS と安定した低レイテンシが求められる用途には、性能を保証する高性能タイプが向きます。大きなファイルを連続して読み書きするような、スループット重視の処理には、それに最適化されたタイプを選びます。一律に高性能なものを選ぶとコストが無駄になり、性能不足だと処理が滞ります。ワークロードが求める性能特性を見極めて選定することが重要です。
性能監視とボリュームの変更
EBS の運用では、ボリュームの性能が実際のワークロードに見合っているかを監視します。IOPS やスループット、レイテンシ、キューの状況を計測し、性能が頭打ちになっていないかを確認します。性能が不足している場合や、逆に過剰な場合は、ボリュームの設定を調整します。EBS は、稼働を止めずにサイズや性能、タイプを変更できるため、需要の変化に応じて柔軟に対応できます。最初から過剰に確保するのではなく、実際の使用状況を見ながら適正なサイズと性能へ調整していくことで、性能を保ちつつコストの無駄を抑えた運用が可能になります。
まとめ - EBS 設計のベストプラクティス
EBS ボリューム設計の基本方針は、gp3 から始めて CloudWatch メトリクスで実測し、必要に応じてスケールアップすることです。IOPS とスループットを独立して調整できる gp3 の柔軟性を活かし、過剰プロビジョニングを避けます。スナップショットは DLM で自動化し、クロスリージョンコピーで DR に備えます。ボリュームタイプの変更はオンラインで実行可能なため、最初から最適解を狙う必要はなく、実測データに基づいて段階的に最適化するアプローチが有効です。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。