【コスト削減】不要なスナップショットを特定・削減し、 コストを最適化する方法

記事タイトルとURLをコピーする

こんにちは!
エンタープライズクラウド部技術2課の日高です。

もし私のことを少しでも知りたいと思っていただけるなら、私の後輩が書いてくれた以下のブログを覗いてみてください。

sabawaku.serverworks.co.jp

本日は11月22日に登壇したウェビナー(不要なスナップショットを特定・削減し、コストを最適化する方法)の内容をブログにもまとめていきます。
また、本ブログに記載するスナップショットは「Amazon EBS スナップショット」を指しています。

【11月22日】『不要なスナップショットを特定・削減し、コストを最適化する方法』ウェビナーを開催します - 株式会社サーバーワークス

はじめに

読書の皆さん、現在スナップショットにかかっている料金がいくらかご存知でしょうか?
過去に私が担当した事例にて下記のようなことがありました。

こちらのお客様はAWSの利用料金の12%(年間600万円)が無駄なコストとして排出されていました。

このような事態にならないよう、下記2つを目的に本ブログを記載していきます。

①スナップショットの料金体系を知り、料金調査ができる。
②本ブログを用いて不要なスナップショットを特定〜削除することができるようになる。(方法の概要を理解する)

上記の目的を達成するために必要な前提知識を「1.スナップショットについて」にまとめています。
目的「①スナップショットの料金体系を知り、料金調査ができる。」を「2.スナップショットの料金について」に、目的「②本ブログを用いて不要なスナップショットを特定〜削除することができるようになる。(方法の概要を理解する)」を「3. 不要スナップショットの削除プロセス」にまとめています。

そのため用途に応じて目次を活用していただければと思います。

スナップショットについて

スナップショットの概要

AWS公式ドキュメントには下記のように記載されています。

Amazon Elastic Block Store (EBS) スナップショットは、EBS ボリューム、ブートボリューム、オンプレミスのブロックデータなどのブロックストレージデータを保護するように設計された、シンプルで安全なデータ保護ソリューションです。

要するにスナップショットは「ある特定の時点におけるデータのコピー」です。
スナップショットが作成されるタイミングの例としては下記になります。

スナップショットのバックアップ方式

スナップショットのバックアップ方式にはフルバックアップと増分バックアップの2種類が存在しています。
下記が簡単な特徴になります。

  • フルバックアップ:ボリュームの全データをコピーして保存する。スナップショットでは、初めてバックアップを取る際はフルバックアップが行われる。
  • 増分バックアップ:前回のバックアップからの変更分だけをコピーして保存する。スナップショットでは最初のフルバックアップの後は、増分バックアップを取得する。

図で示すと下記のようになります。

スナップショットの種類について

スナップショットは EBS Snapshots Standard と EBS Snapshots Archive の2種類が存在しています。
それぞれの特徴を簡単に記載していきます。

EBS Snapshots Standard

  • 一般的なバックアップ用のスナップショットでアクセス頻度が頻繁な場合に向いている。
  • スナップショットを使用する多くの場合、EBS Snapshots Standard を使用するのが適している
  • ストレージ料金(データの容量)が課金される。

EBS Snapshots Archive

  • 長期間保存用のスナップショットで、EBS Snapshots Standard をアーカイブ層に移動することで利用可能。(※1)
  • 保存期間は最低90日以上保存する必要がある。
  • ストレージ料金と、アーカイブからの復元料金(スタンダード層からアーカイブ層への移動)が課金される。
  • アーカイブ移動時に全てフルバックアップとなる。

※1. AMI に関連付けられているスナップショット、AWS Backup で作成したスナップショットはアーカイブ層に移動させることができないのでEBS Snapshots Archiveは利用不可

※2. EBS Snapshots Archiveについて詳しくは下記をご覧ください。

docs.aws.amazon.com

スナップショットの料金について

スナップショットの料金体系

スナップショットは EBS Snapshots Standard と EBS Snapshots Archive の2種類が存在していることを前の章で説明させていただきました。

現在の東京リージョン(2023/12/22時点)では、下記のような料金体系になっています。
※最新の情報はこちらからご確認ください。

以降で、 EBS Snapshots Standard と EBS Snapshots Archiveのそれぞれの料金体系について記述していきます。

EBS Snapshots Standard の料金

EBS Snapshots Standard の料金は下記の表で囲っている箇所になります。

仮に1年間、100,000GBのスナップショットを保存する場合(1USD=150円換算)で料金の試算をすると下記の計算式になります。
100,000GB × 0.05USD × 150円 × 12 = 9,000,000円

「なるほど、1年間 100,000GBのスナップショットを保存する場合(1USD=150円換算)9,000,000円かかるのか」と思った読書の方要注意です!
スナップショットを保存する方法は、増分バックアップもあるため厳密にはこの金額ではない可能性が高いです。

下記の図を使って解説していきます。

例えば、フルバックアップのスナップショット①の料金は下記図の通り100GB × 0.05USD/GB = 5USD/1ヶ月となります。

では、スナップショット④の料金はどうなるでしょうか。

スナップショット④のデータ保存料の実態は40GBになります。
しかし、マネジメントコンソールの保存容量には100GBと記載されています。

そのため計算式は 一見 100GB × 0.05USD/GB = 5USD/1ヶ月 ですが、正確には 40GB × 0.05USD/GB = 2USD/1ヶ月 となります。

つまり冒頭で記載した下記の計算式は全てフルバックアップと想定した金額の試算になります。

仮に1年間、100,000GBのスナップショットを保存する場合(1USD=150円換算)で料金の試算をすると下記の計算式になります。
100,000GB × 0.05USD × 150円 × 12 = 9,000,000円

また、マネジメントコンソールやAWS CLIなどでフル/増分バックアップを見分けることは現状できないため注意してください。

EBS Snapshots Archive の料金

EBS Snapshots Archive の料金は下記の表で囲っている箇所になります。

EBS Snapshots Archive の料金はストレージ料金に加えて、アーカイブからの復元料金(スタンダード層からアーカイブ層への移動)も課金されます。

仮に1年間、100,000GBのスナップショットを保存し復元した場合(1USD=150円換算)で料金の試算をすると下記の計算式になります。

 0.0125USD × 100,000GB × 150円 × 12 + 0.03USD ×100,000GB × 150円
= 2,250,000円 + 450,000円
=2,700,000円

EBS Snapshots Archive では、アーカイブ層に移動したタイミング(EBS Snapshots Archiveになったタイミング)で全てフルバックアップとなるため上記の計算式で問題ありません。

スナップショットの料金確認方法

前の章で、EBS Snapshots Standard は現状マネジメントコンソールやAWS CLIなどでフル/増分バックアップを見分けることはできないとお伝えさせてもらいました。
このままでは、EBS Snapshots Standard の正確な料金を測ることが困難です。

そのためこの章でAWS Cost Explorerを用いてスナップショットの料金を確認する方法を記載します。

まずマネジメントコンソールの検索窓から「cost」と入力し「Billing and Cost Management」に遷移します。

次に、左ペインから「Cost Explorer」に遷移します。

レポートパラメータの日付範囲と粒度にて、検索したい日付範囲と表示したい粒度に設定します。

下記の条件でフィルタリングすることで指定した日付にかかっているスナップショットの料金を確認することができます。

  • ディメンション:「使用タイプ」を選択します
  • サービス:「EC2-Other」を選択します
  • 使用タイプ:「Snap」と入力し当てはまるものを「すべて選択 」します

またグラフの下画面に遷移すると、「コストと使用量の内訳」にて選択した日付の粒度で課金されている金額を確認できます。
CSV形式でダウンロードすることも可能になります。

また、使用タイプの文字列(例:APS1-EBS:SnapshotUsage (GB-Month))には下記のような意味があります。

不要スナップショットの削除プロセス

この章では不要スナップショットの特定〜削除のプロセスについて記載します。
全体像は下記になります。

以降では、下記のスナップショット10個を「不要スナップショットの特定〜削除のプロセス」を通ることでどうなっていくかケースを使って記載していきます。(スナップショットの数が増えても方法は変わりません。)

不要AMIの特定

不要AMIの特定をする以前の状況は下記になります。

不要なAMIをマネジメントコンソールから目視で確認するのは手間がかかります。
そのため、指定した日付以前に作成されたAMI名、AMI ID、作成日時を抽出するスクリプトを作成しました。

blog.serverworks.co.jp

上記のブログに記載されているスクリプトを実行することで不要なAMIと推測されるAMI一覧を抽出することができます。
上記を元に目視で必要/不要の仕分けをすることで不要なAMIの特定をすることができます。

不要AMIの削除

「不要AMIの特定」のステップで特定したAMIにはスナップショットが紐づいています。
そのため、不要なAMIに関連づいているスナップショットも不要となります。

スナップショット削除時には、先にAMIを登録解除しないとスナップショットは消せません。
1つ1つ手作業で行うのは手間がかかるため、AMI IDを指定するとAMIとスナップショットを一括で削除するスクリプトを作成しました。

blog.serverworks.co.jp

上記のブログに記載されているスクリプトを実行することで不要なAMIと、それに紐づく不要なスナップショットを削除することができます。
今回のケースだと、実行後は下記のようになります。

AMIと、EC2のEBSに関連づいてないスナップショットの特定

こちらの章でAMIと、EC2のEBSに関連づいてないスナップショットの特定をしていきます。
こちら文字だけだと理解しづらいので、図解させていただきます。

上記図のように、アカウントに存在するスナップショットを100%とします。
この際に、AMIに紐づくスナップショット(例:35%)と、現在するEC2に紐づくEBSボリュームから作成されたスナップショット(例:40%)は必要な可能性が高いです。

そのためAMIに紐づくスナップショット(例:35%)と、現在するEC2に紐づくEBSボリュームから作成されたスナップショット(例:40%)を除いた25%は不要なスナップショットと推測されます。

前置きが長くなりましたが、AMIと、EC2のEBSに関連づいてないスナップショットの特定をしていきます。
ただこちらをマネジメントコンソールから目視で確認するのは手間がかかるため、スクリプトで簡単に特定していきたいと思います。

blog.serverworks.co.jp

上記のブログに記載されているスクリプトを実行することで、AMIと、EC2のEBSに関連づいてないスナップショットの特定ができました。
今回のケースだと実行後は下記のようになります。

AMIと、EC2のEBSに関連づいてないスナップショットの削除

「AMIと、EC2のEBSに関連づいてないスナップショットの特定」で不要なスナップショットを特定することができました。

こちらをマネジメントコンソールから手動で削除するのは手間がかかるため、スクリプトで一括削除していきたいと思います。

blog.serverworks.co.jp

上記のブログに記載されているスクリプトを実行することで、AMIと、EC2のEBSに関連づいてないスナップショットの削除ができました。
今回のケースだと実行後は下記のようになります。

これで、不要スナップショットの削除プロセスを一通り行うことができました。
今回のケースでは、不要スナップショットの削除プロセスを実行する前と、実行した後では下記のようになります。

まとめ

本ブログにて、下記2つの目的達成できましたでしょうか。

①スナップショットの料金体系を知り、料金調査ができる。
②本ブログを用いて不要なスナップショットを特定〜削除することができるようになる。(方法の概要を理解する)

こちら実行していただいた方はかなり手間がかかったと思います。
不要スナップショットの削除はかなり手間がかかるので、今後不要スナップショットを生まない仕組み、運用を考えていく必要があります。

こちらはまた別途ブログにまとめたいと思います。

日高 僚太(執筆記事の一覧)

EC部技術2課 / AWS認定資格 12冠

2022年IT未経験で新卒入社しました。
最近はダーツとサウナが気になっています!
記事に関するお問い合わせや修正依頼⇒ hidaka@serverworks.co.jp