CloudWatchメトリクスの隠れたコストを解明する

クラウド監視はAWSインフラを安定運用し、最適化していくうえで欠かせない取り組みです。なかでもAmazon CloudWatchは、メトリクス・ログ・アラームを一元的に追跡できる中核ツールとして広く使われています。ところが、AWSの利用が拡大するにつれてCloudWatchのコストも膨らみ、その内訳をたどるのが難しくなることがあります。

AWSユーザーがよく直面する悩みのひとつが、Cost & Usage Report(CUR)でCloudWatchのコスト要因をピンポイントに突き止められないことです。CURはコストの大枠は示してくれるものの、高額な支出の発生源を特定するのに必要な粒度の情報までは得られません。

本記事では、DoiT Cloud Intelligenceを使って想定外のCloudWatchコストを診断した実例をご紹介します。コストの大きい操作を特定したうえで、CloudTrailのデータイベントとAmazon Athenaを組み合わせ、その発生源を解明し、実務に活かせる示唆を引き出す手順を解説します。読み終える頃には、見えにくいCloudWatchコストを把握し、コントロールするための明確な道筋が描けるはずです。

Amazon CloudWatchはAWS環境に欠かせない監視ツールであり、メトリクスやログを詳細に把握できます。一方で、コスト構造はわかりにくく、想定外の請求増加の原因を突き止めるのに苦労しがちです。

Cost & Usage Report(CUR)はAWSコストを細かく分解して見せてくれますが、個々の課金項目についてリソース単位の可視性を提供する点では物足りなさが残ります。代表例がCloudWatchのメトリクスデータを取得するAPI操作GetMetricDataです。コストへの影響は無視できないにもかかわらず、CURの情報だけでは、どのサービス・アプリケーション・ユーザーがこの課金を生んでいるのかを判断するのは困難です。

こうした透明性の欠如は、コスト最適化や予算超過の防止、監視設定に関する的確な判断を妨げる要因となっています。

この課題をわかりやすく示すために、クラウドコストデータを可視化・分析できるDoiT Cloud Analyticsレポートを活用しました。コストデータはさまざまなグラフで表現でき、フィルタリングやグルーピングを通じてより深い示唆を引き出せます。

たとえば下の分析では、直近28日間のCloudWatch利用状況をコスト別に分解しており、GMD-Metrics(GetMetricData)の操作に紐づくコストが継続的に高いことがはっきりと浮かび上がっています。

下のコスト一覧では、CloudWatchの費用をSKU(Stock Keeping Unit)、操作タイプ、リソース情報ごとにさらに細かく分類しています。注目すべきポイントは次のとおりです。

• GMD-Metrics(GetMetricData)が最大のコスト要因になっている。
• リソース情報が欠落しており、リクエストの発生源を特定しづらい。
• MetricMonitorUsageもコストを押し上げているが、影響度は相対的に小さい。

GetMetricDataが大きな、しかも理由のつかめないコストを生み出している以上、CloudTrailのデータイベントとAmazon Athenaを使って発生源を掘り下げて調べる必要があります。

AWS CloudTrailは、IAMの変更、セキュリティ設定、リソースのプロビジョニングといった管理イベントをデフォルトで記録します。一方、S3のオブジェクトレベル操作やLambda実行のようなサービス固有のAPI呼び出しを捕捉するデータイベントは、初期状態では有効になっていません。

今回追跡したいのはCloudWatch Metricsイベントなので、CloudTrailのデータイベントを明示的に有効化する必要があります。設定は既存のトレイルに追加するか、新しいトレイルを作成して行います。

CloudTrailのセットアップ

1. CloudTrailトレイルを選ぶ

• 既存のトレイルを変更するか、新しいトレイルを作成します。
• CloudTrailログの保存先となるS3バケットを指定します。

2. オプション機能を設定する

• セキュリティ強化のためのKMS暗号化(任意)。
• ログの整合性検証とSNS通知(任意。改ざん検知やアラート用途)。
• CloudWatch Logsへの保存(今回はAthenaで分析するため対象外)。

CloudWatchメトリクス用のデータイベントを定義する

1. データイベントタイプとして「CloudWatch metric」を選択します。

2. ログセレクタを指定します。

• すべてのイベント(今回はシンプルさを優先してこちらを選択)。
• 読み取り専用イベント、または書き込み専用イベント。
• より細かく制御したい場合はカスタムセレクタを使用します。

有効化すると、CloudTrailログにCloudWatchのGetMetricDataリクエストが記録され始めますが、分析に取りかかる前にログがある程度たまるのを待つ必要があります。

CloudTrailログ用のAthenaテーブルを作成する

CloudTrailがCloudWatchのGetMetricDataリクエストをS3バケットに記録するようになったので、Amazon Athenaを使って分析できる状態になりました。

Amazon AthenaでCloudTrailログを分析するには、S3バケットに保存されたログデータを参照するテーブルを作成する必要があります。

• CloudTrailコンソールを開き、左側メニューからEvent historyに移動します。
• Create Athena tableをクリックし、Storage locationのドロップダウンでCloudTrailログの保存先S3バケットを選択します。

GetMetricDataイベントをクエリする

これで、Amazon Athenaで誰が、あるいは何がGetMetricDataリクエストを発行しているかを調べられます。次のSQLクエリは小さなサンプルデータセットを使った一例で、実データに対しては別のクエリの方が正確な結果を得られる場合があります。

SELECT
    COUNT(*) as count,
    eventname,
    useridentity.principalId,
    useridentity.arn
FROM cloudtrail_logs_aws_cloudtrail_logs_cw_metrics
WHERE eventname = 'GetMetricData'
GROUP BY eventname, useridentity.principalId, useridentity.arn
ORDER BY count DESC
LIMIT 100;

結果を読み解く

クエリ結果(以下に例を示します)から、GetMetricDataリクエストを生み出している発生源が見えてきます。

• 最上位の行は18件のリクエストを記録しており、最大のコスト要因となっています。
• principalIdとarnの列を見れば、リクエストが特定のAWSサービス、IAMユーザー/ロール、アプリケーションのいずれから発行されているかを判別できます。
• 過剰なリクエストが不要だと判断できる場合は、ポーリング頻度の削減、監視設定の最適化、アクセス権の制限などを検討してコストを抑えましょう。