LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

EBSボリュームのコスト最適化とは何か

Amazon EBSボリュームのコスト最適化とは、EC2インスタンスに接続するブロックストレージの構成・使用状況・保管方針を見直し、性能要件を満たしながら無駄な課金要素を減らす取り組みを指します。対象はボリューム本体だけでなく、そこから作成するスナップショットの保管方法にも及びます^*1。

EBSはEC2を停止していてもボリュームが存在する限り課金が続く仕組みであり、削除し忘れたボリュームやスナップショットが積み上がりやすい特性があります。AWS Prescriptive Guidanceでも、未アタッチのEBSボリュームを削除してコストを抑える対応が案内されています^*2。

本稿では、S3や汎用的なバックアップ運用の話には立ち入らず、EBSボリューム本体とEBSスナップショットに絞って最適化の考え方を整理します。まず着手しやすいgp2からgp3への移行から見ていきます。

gp2からgp3への移行で構成を見直す

General Purpose SSD（gp2・gp3）は、幅広いトランザクション処理に対応する汎用ボリュームタイプです。AWS公式ドキュメントでは、gp3をgp2の後継にあたる最新世代と位置づけています^*1。

両者の主な違いは、性能の決まり方です。gp2はボリュームサイズに応じてIOPSが自動的に決まる仕組みで、容量を増やさない限りIOPSを引き上げられません。一方でgp3はIOPSとスループットを容量から切り離し、それぞれ個別にプロビジョニングできます^*1。

gp3はベースラインとして一定のIOPSとスループットが標準で含まれ、それを超える性能が必要な場合のみ追加分を個別に設定する構成です。必要な容量だけを確保し、性能は要件に応じて別立てで積み増せるため、gp2で性能確保のために容量を余分に確保していた構成を見直しやすくなります^*1。

AWS公式は、gp3がgp2と比べて同水準の性能をより低い単価で提供しうるとしています。ただし実際の単価はリージョン・時期によって変動するため、断定的な削減額は示さず、AWSのEBS料金ページで最新の数値を確認することが前提になります^*3。

移行作業自体は、Elastic Volumes機能を使えばEC2インスタンスを止めずにボリュームタイプ・IOPS・スループットを変更できます^*1。ただし、移行前にワークロードの実測IOPS・スループットを把握しておかないと、必要な性能を過小に見積もるリスクがあります。移行後の性能低下は業務システムの応答遅延に直結するため、事前の実測とモニタリング設計が欠かせません。

未アタッチボリュームの棚卸しと削除

EC2インスタンスを終了してもEBSボリュームが自動的に削除されない設定の場合、ボリュームだけが残り続けます。AWS Prescriptive Guidanceは、使われていないEBSボリュームを特定して削除する対応をコスト最適化の手順として明示しています^*2。

棚卸しの基本的な流れは次の通りです。第一に、EC2マネジメントコンソールやAWS CLIで状態が「available」（未アタッチ）のボリュームを一覧化します。第二に、各ボリュームの作成日時・タグ・関連プロジェクトを確認し、業務での要否を判定します。

要否が不明なボリュームをそのまま削除すると、後になって必要なデータだったと判明するリスクがあります。判断に迷う場合は、スナップショットを取得してからボリュームを削除する方法が無難な対応になります^*2。

AWS Trusted Advisorのコスト最適化チェックでは、未アタッチの状態が続くボリュームや、直近の書き込みアクティビティが極めて少ないボリュームを識別する機能が提供されています^*4。定期的にこの種の可視化ツールを回す運用に組み込むと、棚卸しの見落としを減らせます。

棚卸しには、対象アカウント数・リージョン数に応じた工数がかかります。数十アカウント規模のマルチアカウント環境では、タグ設計・削除承認フロー・監査ログの整備まで含めて設計する必要があり、単純な一括削除スクリプトだけでは対応しきれないケースもあります。

サイズ・IOPS・スループットの過剰設定是正

EBSとは、EC2インスタンスにネットワーク経由で接続するブロックストレージサービスを指します^*5。ボリュームは独立したリソースであり、必要以上の容量やIOPSを確保したまま放置されるケースが少なくありません。

典型的な過剰プロビジョニングは、将来の増設を見越して初期段階で大きめの容量を確保し、その後もデータ量が想定ほど増えず未使用領域が残るパターンです。gp2ではIOPSを引き上げるために容量を増やす必要があったため、性能要件が理由で容量が肥大化した構成も見られます^*1。

是正の第一歩は、CloudWatchメトリクスで実際のIOPS・スループット・ディスク使用率を一定期間観測することです。観測結果が現在のプロビジョニング水準を大きく下回っている場合、gp3への移行とあわせてIOPS・スループットの設定値を引き下げる余地があります。

EBS最適化インスタンス（EBS-optimized instance）を使うと、EBSへの入出力専用の帯域が確保され、他のネットワークトラフィックとの競合を避けられます^*6。インスタンス側の性能上限とボリューム側の性能上限は別々に決まるため、片方だけを引き上げても全体の性能は改善しません。両者を合わせて見直す視点が必要です^*6。

過剰設定を安易に絞り込むと、繁忙期のバッチ処理やレポート集計で性能不足が起き、業務停止につながる恐れがあります。是正には、ピーク時の負荷パターンを把握した上で余裕分を残す設計判断が求められます。

スナップショットの世代管理とDLMによる自動化

EBSスナップショットとは、ある時点のボリュームの状態を保存するバックアップの仕組みです。標準（スタンダード）階層のスナップショットは増分方式で保存され、直前のスナップショットからの変更ブロックのみが対象になります^*7。

スナップショットを手動運用のまま放置すると、世代が際限なく増え続け、実際には不要になった古い世代までコストが発生し続けます。世代数の上限・保持期間をルール化し、期限切れの世代を機械的に削除する仕組みが必要です。

Amazon Data Lifecycle Manager（DLM、EBSスナップショットとAMIのライフサイクルを自動化するAWSのマネージドサービス）を使うと、スナップショットの作成・保持・削除をポリシーベースで自動化できます^*8。DLM自体の利用に追加料金は発生しません^*8。

DLMのカスタムポリシーでは、タグを基準に対象リソースを指定でき、高速スナップショット復元・アーカイブ階層への移行・アカウントをまたいだコピーといった機能とも連携します^*8。これにより、古いスナップショットを自動で削除する運用と、長期保管が必要な世代をアーカイブ階層へ回す運用を、同じポリシーの中で組み合わせられます。

DLMポリシーの設計には、業務要件に基づく保持期間の決定、対象リソースを正しく捕捉するタグ設計、障害時のリストア手順の検証が伴います。ポリシー設定を誤ると、必要な世代が意図せず削除される、あるいは不要な世代が残り続けてコスト削減効果が出ないという事態が起こり得ます。

スナップショットアーカイブ層の活用条件

Amazon EBS Snapshots Archiveは、アクセス頻度が低く即時の取り出しを必要としないスナップショットを、低コストで長期保管するための階層です^*9。AWSは、90日以上保管し、かつ滅多にアクセスしないスナップショットを対象とした場合に、標準階層と比べて75%低い水準になりうるとしています^*9。

アーカイブ階層に移すと、増分スナップショットは全ブロックを含むフルスナップショットに変換されます^*9。アーカイブ済みスナップショットはそのままではボリューム作成に使えず、利用する際は標準階層への復元が必要です^*9。

復元には、スナップショットのサイズに応じて最長72時間かかる場合があります^*9。復元は恒久的に行う方法と、一時的な期間だけ標準階層に戻す方法を選べます^*9。障害対応で即座にリストアしたい直近世代をアーカイブ階層に置いてしまうと、復旧までの時間が業務影響に直結するため、対象とする世代の選定が重要です。

アーカイブ階層の最低保管期間は90日です^*9。90日未満で復元・削除した場合は早期削除に関する取り扱いが生じるため、コンプライアンス目的の年次・四半期スナップショットなど、長期保管が確定している世代から適用するのが実務的な進め方です^*9。

内製で進める場合の工数と外注判断の軸

ここまでの施策を比較すると、それぞれ効果と難易度が異なります。以下に主要な最適化施策を整理します。

これらを内製で回すには、AWSコスト管理の知識に加え、CloudWatchメトリクスの分析、DLMポリシーのJSON設計、マルチアカウントでのタグ運用など、複数領域の実務知識が求められます。担当者が本業と兼務する体制では、棚卸しの定例化自体が後回しになりやすいのが実情です。

専門パートナーに委託する場合は、既存の運用保守体制の中でEBS棚卸し・DLMポリシー設計・アーカイブ移行の判断までを継続的に回せる点が内製との違いです。単発の移行作業だけでなく、月次・週次で状態を見続ける運用まで含めて任せられるかどうかが、外注・内製を分ける判断軸になります。

まとめ：EBSコスト最適化を進める3つの判断軸

本稿では、Amazon EBSボリュームのコスト最適化を、gp2からgp3への移行・未使用リソースの棚卸し・スナップショットの世代管理という3つの軸で整理しました。要点を集約すると次の通りです。

第一に、gp3への移行はIOPS・スループットを容量と切り離して設定できる点が構成見直しの起点になります。第二に、未アタッチボリュームの棚卸しと過剰プロビジョニングの是正は、AWS Trusted Advisor等の可視化ツールを組み合わせて継続的に行う必要があります。第三に、スナップショットはDLMによる世代管理の自動化とアーカイブ階層の使い分けまで設計してはじめて、長期的なコスト効果が安定します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「Amazon EBS General Purpose SSD volumes」（AWSドキュメント）
2. *2　出典：Amazon Web Services「Delete unattached Amazon EBS volumes」（AWS Prescriptive Guidance）
3. *3　出典：Amazon Web Services「Amazon EBS pricing」（AWS公式料金ページ）
4. *4　出典：Amazon Web Services「Cost optimization checks – AWS Support」（AWSドキュメント）
5. *5　出典：Amazon Web Services「Amazon EBS volumes」（AWSドキュメント）
6. *6　出典：Amazon Web Services「Amazon EBS-optimized instance types」（AWSドキュメント）
7. *7　出典：Amazon Web Services「How Amazon EBS snapshots work」（AWSドキュメント）
8. *8　出典：Amazon Web Services「Amazon Data Lifecycle Manager」（AWSドキュメント）
9. *9　出典：Amazon Web Services「Archive Amazon EBS snapshots」（AWSドキュメント）

Tweet