Savings Plan購入検討用にAmazon QuickでEC2利用料金を可視化してみた

Savings Plan購入検討用にAmazon QuickでEC2利用料金を可視化してみた

2026.02.26

こんにちは。クラウド事業本部の木村です。

今回はSavings Plan購入の検討に使えるようなEC2の利用を可視化できるダッシュボードを作成していきたいと思います。CURの請求情報を使用して、1時間単位でSP,Ondemand,Spotの各タイプでどの程度の費用が発生しているのかを確認できる状態を目指します。

はじめに

なぜ時間単位での可視化が必要なのか

突然ですが、クイズです。以下の2つの環境があり同じインスタンスタイプのインスタンスがオンデマンド料金で起動しているとき、どちらがSPを購入した際に割引の適用額が大きくなりますでしょうか?

  • 環境A: 1年間継続して、EC2の利用料金が1日あたりのオンデマンド利用費が240USD。5USD/hのSPを購入する。
  • 環境B: 1年間継続して、EC2の利用料金が1日あたりのオンデマンド利用費が2400USD。50USD/hのSPを購入する。

突然このようなクイズを出す時点でお分かりかもしれませんが、正解はこの情報だけでは判断できません。なぜなら、インスタンスの起動パターンが分からないためです。

極端な例ですが以下のようなパターンでは環境Bにて環境Aの10倍ほどのSPを購入していても、割引の適用額においても環境Aの方が大きくなります。これはSPの割引の適用が1時間単位で行われるためです。

  • 環境A : 24時間に渡って10USD分の利用されている
  • 環境B : 1時間に集中して2400USD分の利用をしている

実際計算すると以下の額がSPによって割引が適用されます。わかりやすく適用される割引率は50%とします。

  • 環境A : 24時間 * 5USD = 120USD
  • 環境B : 1時間 * 50USD = 50USD

この辺りのSPの割引の適用の説明は以下のブログが大変わかりやすいので、適用イメージがあやふやな方はご参照いただければと思います。

https://dev.classmethod.jp/articles/ec2-reserved-instances-savings-plans-comparison-seminar/

イメージを持っていただくため、まず割引適用額での比較をしましたが、SP購入による実際の収支の観点でも比較してみたいと思います。

環境A:1日あたり240USDオンデマンド利用、5USD/hのSPを購入

  1. オンデマンド利用時: 240 USD/日
  2. SP購入後:
    • SPコミット費用: 120USD(5USD/h × 24h)
    • オンデマンド費用: 0USD(全てSPでカバー)
    • 合計: 120 USD/日
  3. 収支: 240 - 120 = ▲120USD/日(削減)

環境B : 1日あたり2400 USDのオンデマンド利用、50USD/hのSPを購入

  1. オンデマンド利用時: 2400USD/日
  2. SP購入後:
    • SPコミット費用: 1200USD(50USD/h × 24h)
    • オンデマンド費用: 2300USD(SP適用外分)
    • 合計: 3,500 USD/日
  3. 収支: 2400 - 3500 = +1100USD/日(増加)

環境Aでは1日120USDの削減になる一方、環境Bではコストが1100USDも増加してしまいます。
購入したSPの大部分(23時間分)が使われず、無駄なコミットメント費用だけが発生しているためです。

上記は極端な例ですが、時間単位の利用状況を確認せずにSPを購入すると、割引率次第ではコスト最適化のつもりが逆にコスト増加となってしまう可能性があります。

このような事態を避けるため、「1日いくらのコストが発生しているか」だけでなく、「どのような起動パターンで利用料金が発生しているか」を時間単位で把握することが重要です。

それではどのように可視化を行うことができるのかをご紹介したいと思います。

利用パターンの可視化について

今回紹介するQuick Suiteを利用したダッシュボードをカスタマイズする以外にも時間単位でEC2の利用状況を可視化する方法がいくつかありますのでご紹介させていただきます。ご自身の利用している環境に合った方法で確認を進めていただければと思います。

1. Cost Explorerの時間単位表示

  • 概要

管理アカウントから時間単位とリソースレベルのデータを有効化することで、Cost ExplorerのGUIで時間単位の利用状況を確認できます。

https://dev.classmethod.jp/articles/cost-explorer-supports-hourly-resource-level-granularity/

  • メリット:
    • セットアップが簡単(管理アカウントから数クリックで有効化)
    • AWSコンソール上で直感的に操作可能
    • 追加のツールやサービスが不要
  • デメリット:
    • 表示可能な期間が最大14日間と制限がある
    • データ保存に料金が発生(1,000行あたり$0.01)
    • 準備された項目の中からしか確認できない
    • 一部リセラーにて利用に制限がある
  • こんな方におすすめ
    • 利用パターンに変動が少なく短期間(2週間)のみの把握で問題がない
    • 簡易的に時間単位の利用状況を把握したい
    • すぐに確認を始めたい

2. SP購入アナライザー

  • 概要

AWS Billing and Cost Managementコンソールで、過去の利用パターンに基づいたSPの購入推奨事項を確認できます。AWSが自動的に最適な購入量を提案してくれます。

https://dev.classmethod.jp/articles/check-ri-sp-utilization/

  • メリット:
    • AWSが自動的に推奨値を計算してくれる
    • 購入後の利用率やカバー率も確認可能
    • 追加のツールやセットアップが不要
    • SPの効果をすぐに確認できる
  • デメリット:
    • 分析期間が過去60日に限定される
    • カスタマイズや詳細な分析ができず、推奨アルゴリズムの詳細が不明のため根拠の説明が難しい
    • 一部リセラーにて利用に制限がある
  • こんな方におすすめ
    • AWSの推奨値を参考にしてすぐにSPを購入したい
    • 複雑な分析は不要で、シンプルに推奨値が知りたい
    • 購入後の利用率をモニタリングしたい

3. Cloud Intelligence Dashboards (CUDOS)

  • 概要

AWSが公式に提供するQuickダッシュボードのテンプレート集です。CURデータを元に、CUDOS Dashboard、Cost Intelligence Dashboard、KPI Dashboardなど複数の高機能ダッシュボードを一括でデプロイできます。

https://dev.classmethod.jp/articles/aws-cloud-intelligence-dashboards-with-cur-2-0/

https://dev.classmethod.jp/articles/how-to-create-cid-with-mcur/

  • メリット:

    • AWS公式のベストプラクティスに基づいた高機能ダッシュボード
    • EC2のSP適用状況、利用率、カバー率などを包括的に分析可能
    • 時間単位の利用パターンを長期間(CURデータがある限り)分析可能
    • 複数のダッシュボード(CUDOS、KPI、Compute Optimizerなど)を一括デプロイ
    • コミュニティによる継続的なアップデート
  • デメリット:

    • セットアップがやや複雑(cid-cmdツールの利用、Athena/Quickの設定が必要)
    • Quickの利用料金が発生
    • テンプレートが多機能すぎて、初見では使いこなすのが難しい
    • カスタマイズには一定の学習が必要
  • こんな方におすすめ

    • 包括的なコスト分析環境を一度に構築したい
    • AWS公式のベストプラクティスに基づいた分析をしたい
    • EC2だけでなく他のサービスのコストも含めて全体的に分析したい
    • FinOpsの取り組みを本格的に進めたい組織

4. Quickで独自ダッシュボードを作成(今回紹介する方法)

  • 概要

CURデータをQuickで読み込み、自分の用途に合わせてダッシュボードを一から作成する方法です。

  • メリット:
    • 完全に自由なカスタマイズが可能
    • 必要な情報だけに絞ったシンプルなダッシュボードを作成できる
    • 時間単位の利用パターンを長期間(CURデータがある限り)分析可能
    • 自社の分析ニーズに完全に合わせた設計が可能
  • デメリット:
    • ダッシュボードを一から構築する必要がある(セットアップに時間がかかる)
    • Quick Suiteの利用料金が発生
    • Quick Suiteの操作知識が必要
  • こんな方におすすめ
    • 特定の用途に特化したシンプルなダッシュボードが欲しい
    • CUDOSでは過剰で、必要最小限の分析項目に絞りたい
    • 既にQuick Suiteの知識があり、カスタマイズしたい

今回は、SP購入検討のためのシンプルなダッシュボードを作成する方法をご紹介させていただきます。

ダッシュボードを作成する

ではここからダッシュボードの作成方法をご紹介させていただきます。
今回データとしてCURを利用しますので、取得していない場合は以下で設定を行ってください。

CURの準備

CURの設定方法については以下の記事で詳しく解説されていますので、こちらをご参照ください。

https://dev.classmethod.jp/articles/cost-and-usage-report-cur/

本記事では、CURが既に設定済みでS3にデータが出力されている前提で進めていきます。ファイル形式は上記のブログで紹介しているparquetを前提に進めています。

また設定前の過去データをさらに遡って参照したい場合には、最大36ヶ月までバックフィルを行うことができます。必要な場合には以下を参考にしてください。

https://docs.aws.amazon.com/guidance/latest/cloud-intelligence-dashboards/deployment-in-global-regions.html#deployment-global-backfill-data-export

Glueクローラーを利用してAthenaテーブルを作成する

CURが取得できたら、クエリを行うためのAhenaテーブルを作成します。

Glueの画面から作成を行っていきます。

クローラー___AWS_Glue___ap-northeast-1

任意の名前を設定してください。

AWS_Glue___ap-northeast-1

データソースの追加から、対象のS3バケットを選択してください。
AWS_Glue___ap-northeast-1

AWS_Glue___ap-northeast-1

この際curのデータが格納されたフォルダを指定してください。

Crawlers_-_AWS_Glue_Console

続けて除外パターンに以下を設定します。

**.json
**.yml
**.sql
**.csv
**.csv.metadata
**.gz
**.zip
**/cost_and_usage_data_status/*
aws-programmatic-access-test-object

AWS_Glue___ap-northeast-1

任意の名前で新しくロールを作成してください。

AWS_Glue___ap-northeast-1

最後にデータベースと任意でテーブル名を指定して作成してください。

AWS_Glue___ap-northeast-1

作成できたらクローラーを実行してください。

Crawlers_-_AWS_Glue_Console

問題なく成功すると以下のようにテーブルができているかと思います。

Tables_-_AWS_Glue_Console

データセットを作成する

テーブルが作成できたらQuickに移動してデータセットを作成していきます。

Quick_-_データ

まずデータソースが必要なので、データソースを作成します。

Quick_-_データ

Quick_-_データ

Quick_-_データ

データソースができたら、データセットを作成していきます。

Quick_-_データ

Quick_-_データ

以下のSQLを入力してください。<データベース名>と<テーブル名>は適宜変更してください。

SELECT
DATE_TRUNC('hour', line_item_usage_start_date) as usage_hour,
line_item_usage_account_id as account_id,
line_item_usage_account_name as account_name,
product['region'] as region,
product_instance_type as instance_type,
product_instance_family as instance_family,
CASE
WHEN product_instance_type IS NOT NULL
THEN REGEXP_EXTRACT(product_instance_type, '^([a-z]+[0-9]+[a-z]*)')
ELSE product_instance_family
END as instance_family_only,
product['operating_system'] as operating_system,
line_item_usage_type as usage_type,
line_item_operation,
CASE
WHEN line_item_line_item_type IN ('SavingsPlanCoveredUsage', 'SavingsPlanNegation') THEN '1_SavingsPlan'
WHEN line_item_line_item_type = 'Usage' AND line_item_usage_type NOT LIKE '%SpotUsage%' THEN '2_OnDemand'
WHEN line_item_line_item_type = 'Usage' AND line_item_usage_type LIKE '%SpotUsage%' THEN '3_Spot'
WHEN line_item_line_item_type = 'DiscountedUsage' THEN '4_Reserved'
WHEN line_item_line_item_type = 'RIFee' THEN '4_Reserved'
ELSE '5_Other'
END as purchase_option,
SUM(line_item_usage_amount) as usage_hours,
-- Savings Plans の実効コストを計算
SUM(
CASE
WHEN line_item_line_item_type IN ('SavingsPlanCoveredUsage', 'SavingsPlanNegation')
THEN savings_plan_savings_plan_effective_cost
ELSE line_item_unblended_cost
END
) as unblended_cost,
SUM(pricing_public_on_demand_cost) as on_demand_cost,
COUNT(DISTINCT line_item_resource_id) as instance_count
FROM <データベース名>.<テーブル名>
WHERE
line_item_product_code = 'AmazonEC2'
AND product_servicecode = 'AmazonEC2'
AND product_product_family = 'Compute Instance'
AND line_item_line_item_type IN ('Usage', 'SavingsPlanCoveredUsage', 'DiscountedUsage', 'RIFee')
AND line_item_usage_start_date >= DATE('2024-1-01')
AND (product_instance_type IS NOT NULL OR line_item_line_item_type LIKE '%SavingsPlan%')
GROUP BY
DATE_TRUNC('hour', line_item_usage_start_date),
line_item_usage_account_id,
line_item_usage_account_name,
product['region'],
product_instance_type,
product_instance_family,
CASE
WHEN product_instance_type IS NOT NULL
THEN REGEXP_EXTRACT(product_instance_type, '^([a-z]+[0-9]+[a-z]*)')
ELSE product_instance_family
END,
product['operating_system'],
line_item_usage_type,
line_item_operation,
CASE
WHEN line_item_line_item_type IN ('SavingsPlanCoveredUsage', 'SavingsPlanNegation') THEN '1_SavingsPlan'
WHEN line_item_line_item_type = 'Usage' AND line_item_usage_type NOT LIKE '%SpotUsage%' THEN '2_OnDemand'
WHEN line_item_line_item_type = 'Usage' AND line_item_usage_type LIKE '%SpotUsage%' THEN '3_Spot'
WHEN line_item_line_item_type = 'DiscountedUsage' THEN '4_Reserved'
WHEN line_item_line_item_type = 'RIFee' THEN '4_Reserved'
ELSE '5_Other'
END
ORDER BY usage_hour DESC

取り込みができたら分析の作成します。

Quick_-_データ

ダッシュボードを作成する

ここからダッシュボードを作成していきます。

まずビジュアルを作成します。積み上げ面折れ線グラフを選択してください。

Quick_-_sample_cur_aggregated_csv_analysis

それぞれに設定する値を選ぶことができますので、以下の通り3つ選択してください。

Quick_-_sample_cur_aggregated_csv_analysis

選択すると以下の通り、ビジュアルが表示されます。

Quick_-_sample_cur_aggregated_csv_analysis

初期状態だとX軸の集計単位が「日」になっているので、時間単位に変更します。

Quick_-_sample_cur_aggregated_csv_analysis

そうするとこの通り、時間あたりで利用費を確認できるようになります。

Quick_-_sample_cur_aggregated_csv_analysis

この環境の場合、毎時10USD程度をSPで賄っていることがわかるかと思います。

続いてデータの表示できる範囲を広げたいと思います。デフォルトであるとデータポイントが200となっておりますので、最大値の400(16日分)まで拡張したいと思います。

ビジュアルのフォーマットを選択して、オプションから400を入力して画面の任意の箇所をクリックしてください。

Quick_-_sample_cur_aggregated_csv_analysis

Quick_-_sample_cur_aggregated_csv_analysis_と_新しいシークレット_タブ_と_-zsh

変更すると以下のように16日分のデータが確認できるようになります。

Quick_-_sample_cur_aggregated_csv_analysis

続いてインスタンスタイプ別にフィルターを設定してみます。作成したビジュアルを選択してフィルタのボタンを押下してください。

Quick_-_sample_cur_aggregated_csv_analysis

フィルターの追加から、「instance_type」を選択してください。

Quick_-_sample_cur_aggregated_csv_analysis

フィルターを追加できたら、シートからフィルターを選択できるよう以下のようにコントロールをシートの内部に追加してください。

Quick_-_sample_cur_aggregated_csv_analysis

すると以下のようにインスタンスタイプ別にフィルターをかけることができるようになります。Instance SPを検討の際にはこちらを利用して利用費を確認してみてください。

Quick_-_sample_cur_aggregated_csv_analysis

フィルターをかけてみると以下のようにc5.xlargeではかなり増減がある様子を確認できます。

Quick_-_sample_cur_aggregated_csv_analysis

同様に期間やアカウント名もフィルターを設定することで、シートから絞り込みを行うことができるようになります。利用に合わせて追加いただければと思います。

Quick_-_sample_cur_aggregated_csv_analysis

今回のサンプルデータでは含めていないので表示されていませんが、Spotも料金のグラフ内に表示することが可能です。
このように時間単位で確認してSP検討の材料の一つにしていただければと思います。

まとめ

今回はAmazon Quickを利用して、時間単位の利用料金を確認できるようにしました。

SPの購入の支援を行ったのですが、可視化を行うことで購入戦略であったり購入額の決定に決定に大いに役立てる事ができました。
EC2以外のサービスでも同様に可視化することができますので、SQLを変更して作成してみてください。

この記事がコスト最適化の一助になれば幸いです。

以上、クラウド事業本部の木村がお届けしました。

この記事をシェアする

FacebookHatena blogX

関連記事