Cost Explorer で CloudWatch のコストと使用状況データを分析する CloudWatch のコストと使用状況データを AWS Cost and Usage Report と Athena で分析するコスト削減と最適化のためのベストプラクティス

CloudWatch の請求とコスト

このセクションでは、Amazon CloudWatch の機能でどのようにコストが発生するかについて説明します。また、CloudWatch のコストを分析、最適化、削減するのに役立つ方法についても説明します。このセクション全体を通して、CloudWatch 機能を説明する際に料金について言及することがあります。料金の詳細については、「Amazon CloudWatch の料金」を参照してください。

トピック

Cost Explorer で CloudWatch のコストと使用状況データを分析する
CloudWatch のコストと使用状況データを AWS Cost and Usage Report と Athena で分析する
コスト削減と最適化のためのベストプラクティス

Cost Explorer で CloudWatch のコストと使用状況データを分析する

AWS Cost Explorer では、CloudWatch を含む AWS サービスのコストと使用状況のデータを時間の経過を追って可視化して分析できます。詳細については、「AWS Cost Explorer の開始方法」を参照してください。

以下の手順では、Cost Explorer を使用して CloudWatch のコストと使用状況データを可視化および分析する方法について説明します。

CloudWatch のコストと使用状況データを可視化して分析するには

Cost Explorer コンソールにサインインします https://console.aws.amazon.com/cost-management/home#/custom。
[FILTERS] (フィルター) で、[Service] (サービス) に [CloudWatch] を選択します。
[Group by] (グループ化の条件) には [Usage Type] (使用タイプ) を選択します。また、次のような他のカテゴリ別に結果をグループ化することもできます。
- [API Operation] (API オペレーション) – 最もコストがかかった API オペレーションを確認する。
- [Region] (リージョン) – 最もコストがかかったリージョンを確認する。

次の画像は、CloudWatch の機能によって 6 か月間に発生したコストの例を示しています。

使用タイプのコストを棒グラフ形式で表示している AWS Cost Explorer インターフェイススクリーンショット。

最もコストがかかった CloudWatch 機能を知るには、UsageType の値を確認します。例えば、EU-CW:GMD-Metrics は、CloudWatch バルク API リクエストによって発生したコストを表します。

注記

UsageType の文字列は、特定の機能およびリージョンと一致します。例えば、EU-CW:GMD-Metrics の最初の部分 (EU) は欧州 (アイルランド) リージョンと一致し、EU-CW:GMD-Metrics の後半の部分 (GMD-Metrics) は CloudWatch バルク API リクエストと一致します。

UsageType の文字列全体は <Region>-CW:<Feature> または <Region>-<Feature> の形式になっています。

ログやアラームなどの一部の CloudWatch 機能は、Global リージョンを使用して無料利用枠の使用状況を特定します。例えば、Global-DataScanned-Bytes は無料の CloudWatch Logs データインジェストの使用状況を表します。

読みやすくするために、このドキュメント全体を通して、表の中の UsageType の文字列は、文字列の後半の部分に短縮されています。例えば、EU-CW:GMD-Metrics は GMD-Metrics に短縮されます。

次の表に、各 CloudWatch 機能の名前、各サブ機能の名前、および UsageType の文字列を示します。

CloudWatch 機能	CloudWatch サブ機能	`UsageType`
CloudWatch メトリクス	カスタムメトリクス	`MetricMonitorUsage`
	詳細モニターリング	`MetricMonitorUsage`
	埋め込みメトリクス	`MetricMonitorUsage`
CloudWatch API リクエスト	API リクエスト	`Requests`
	バルク (取得)	`GMD-Metrics`
	Contributor Insights	`GIRR-Metrics`
	ビットマップイメージスナップショット	`GMWI-Metrics`
CloudWatch メトリクスストリーム	メトリクスストリーム	`MetricStreamUsage`
CloudWatch ダッシュボード	メトリクスが 50 以下のダッシュボード	`DashboardsUsageHour-Basic`
	メトリクスが 50 を超えるダッシュボード	`DashboardsUsageHour`
CloudWatch アラーム	標準 (メトリクスアラーム)	`AlarmMonitorUsage`
	高解像度 (メトリクスアラーム)	`HighResAlarmMonitorUsage`
	Metrics Insights クエリアラーム	`MetricInsightAlarmUsage`
	複合 (集約アラーム)	`CompositeAlarmMonitorUsage`
CloudWatch Application Signals	Application Signals	`Application-Signals`
CloudWatch カスタムログ	収集 (標準ログクラスのデータインジェスト)	`DataProcessing-Bytes`
	収集 (低頻度アクセスログクラスのデータインジェスト)	`DataProcessingIA-Bytes`
	分析 (クエリ)	`DataScanned-Bytes`
	分析 (Live Tail)	`Logs-LiveTail`
	保存 (アーカイブ)	`TimedStorage-ByteHrs`
	検出とマスク (データ保護)	`DataProtection-Bytes`
CloudWatch 出力ログ	配信 (Amazon CloudWatch Logs 標準ログクラス)	`VendedLog-Bytes`
	配信 (CloudWatch Logs 低頻度アクセスログクラス)	`VendedLogIA-Bytes`
	配信 (Amazon S3)	`S3-Egress-Bytes`
	Parquet 形式の配信 (Amazon S3)	`S3-Egress-InputBytes`
	配信 (Amazon Data Firehose)	`FH-Egress-Bytes`
Contributor Insights	CloudWatch Logs (ルール)	`ContributorInsightRules`
	CloudWatch Logs (イベント)	`ContributorInsightEvents`
	Amazon DynamoDB (ルール)	`ContributorRulesManaged`
	DynamoDB イベント)	`ContributorEventsManaged`
Canary (合成)	実行	`Canary-runs`
Evidently	イベント	`Evidently-event`
	分析ユニット	`Evidently-eau`
RUM	イベント	`RUM-event`

CloudWatch のコストと使用状況データを AWS Cost and Usage Report と Athena で分析する

CloudWatch のコストと使用状況データを分析するもう 1 つの方法は、AWS Cost and Usage Report を Amazon Athena とともに使用することです。AWS Cost and Usage Report には、コストと使用状況データが包括的にまとめて含まれています。コストと使用状況を追跡するレポートを作成し、これらのレポートを、任意の S3 バケットに発行できます。S3 バケットからレポートをダウンロードして削除することもできます。詳細については、「AWS Cost and Usage Report ユーザーガイド」の「AWS Cost and Usage Report とは?」を参照してください。

注記

AWS Cost and Usage Report の使用料は発生しません。ストレージに対して料金が発生するのは、Amazon Simple Storage Service (Amazon S3) にレポートを発行するときのみです。詳細については、「AWS Cost and Usage Report ユーザーガイド」の「クォータと制限」を参照してください。

Athena は、コストと使用状況データを分析するために AWS Cost and Usage Report で使用できるクエリサービスです。S3 バケット内のレポートは、最初にダウンロードしなくてもクエリできます。詳細については、「Amazon Athena ユーザーガイド」の「Amazon Athena とは」を参照してください。詳細については、「Amazon Athena ユーザーガイド」の「Amazon Athena とは」を参照してください。料金に関する詳細については、「Amazon Athena の料金」を参照してください。

以下の手順では、AWS Cost and Usage Report を有効にして、このサービスを Athena と統合するプロセスを説明します。この手順には、CloudWatch のコストと使用状況データを分析するために使用できる 2 つのクエリ例が含まれています。

注記

このドキュメント内のクエリ例は、どれでも使用してかまいません。このドキュメント内のクエリ例はすべて、costandusagereport という名前のデータベースに対応していて、2022 年 4 月の結果を表示します。この情報は、変更することができます。ただし、クエリを実行する前に、データベースの名前がクエリ内のデータベースの名前と一致していることを確認してください。

AWS Cost and Usage Report と Athena を使用してコストと使用状況のデータを分析するには

AWS Cost and Usage Report を有効にします。詳細については、「AWS Cost and Usage Report ユーザーガイド」の「コストと使用状況レポートを作成する」を参照してください。

ヒント
レポートを作成するときは、[Include resource IDs] (リソース ID を含める) を必ず選択してください。そうしないと、レポートに line_item_resource_id の列が含まれません。この行は、コストと使用状況データを分析するときにコストをさらに特定するのに役立ちます。
AWS Cost and Usage Report を Athena と統合します。詳細については、「AWS Cost and Usage Report ユーザーガイド」の「AWS CloudFormation テンプレートを使用した Athena の設定」を参照してください。
コストと使用状況のレポートをクエリします。

例: Athena クエリ

次のクエリを使用して、特定の月に最もコストが発生した CloudWatch 機能を表示できます。


SELECT
CASE
-- Metrics
WHEN line_item_usage_type LIKE '%%MetricMonitorUsage%%' THEN 'Metrics (Custom, Detailed monitoring management portal EMF)'
WHEN line_item_usage_type LIKE '%%Requests%%' THEN 'Metrics (API Requests)'
WHEN line_item_usage_type LIKE '%%GMD-Metrics%%' THEN 'Metrics (Bulk API Requests)'
WHEN line_item_usage_type LIKE '%%MetricStreamUsage%%' THEN 'Metric Streams'
-- Dashboard
WHEN line_item_usage_type LIKE '%%DashboardsUsageHour%%' THEN 'Dashboards'
-- Alarms
WHEN line_item_usage_type LIKE '%%AlarmMonitorUsage%%' THEN 'Alarms (Standard)'
WHEN line_item_usage_type LIKE '%%HighResAlarmMonitorUsage%%' THEN 'Alarms (High Resolution)'
WHEN line_item_usage_type LIKE '%%MetricInsightAlarmUsage%%' THEN 'Alarms (Metrics Insights)'
WHEN line_item_usage_type LIKE '%%CompositeAlarmMonitorUsage%%' THEN 'Alarms (Composite)'
-- Logs
WHEN line_item_usage_type LIKE '%%DataProcessing-Bytes%%' THEN 'Logs (Collect - Data Ingestion)'
WHEN line_item_usage_type LIKE '%%DataProcessingIA-Bytes%%' THEN 'Infrequent Access Logs (Collect - Data Ingestion)'
WHEN line_item_usage_type LIKE '%%DataProtection-Bytes%%' THEN 'Logs (Data Protection - Detect and Mask)'
WHEN line_item_usage_type LIKE '%%TimedStorage-ByteHrs%%' THEN 'Logs (Storage - Archival)'
WHEN line_item_usage_type LIKE '%%DataScanned-Bytes%%' THEN 'Logs (Analyze - Logs Insights queries)'
WHEN line_item_usage_type LIKE '%%Logs-LiveTail%%' THEN 'Logs (Analyze - Logs Live Tail)'
-- Vended Logs
WHEN line_item_usage_type LIKE '%%VendedLog-Bytes%%' THEN 'Vended Logs (Delivered to CW)'
WHEN line_item_usage_type LIKE '%%VendedLogIA-Bytes%%' THEN 'Vended Infrequent Access Logs (Delivered to CW)'
WHEN line_item_usage_type LIKE '%%FH-Egress-Bytes%%' THEN 'Vended Logs (Delivered to Data Firehose)'
WHEN (line_item_usage_type LIKE '%%S3-Egress-Bytes%%') THEN 'Vended Logs (Delivered to S3)'
-- Other
WHEN line_item_usage_type LIKE '%%Application-Signals%%' THEN 'Application Signals'
WHEN line_item_usage_type LIKE '%%Canary-runs%%' THEN 'Synthetics'
WHEN line_item_usage_type LIKE '%%Evidently%%' THEN 'Evidently' 
WHEN line_item_usage_type LIKE '%%RUM-event%%' THEN 'RUM'
ELSE 'Others'
END AS UsageType,
-- REGEXP_EXTRACT(line_item_resource_id,'^(?:.+?:){5}(.+)$',1) as ResourceID,
-- SUM(CAST(line_item_usage_amount AS double)) AS UsageQuantity,
SUM(CAST(line_item_unblended_cost AS decimal(16,8))) AS TotalSpend
FROM
costandusagereport 
WHERE
product_product_name = 'AmazonCloudWatch'
AND year='2022' 
AND month='4' 
AND line_item_line_item_type NOT IN ('Tax','Credit','Refund','EdpDiscount','Fee','RIFee')
-- AND line_item_usage_account_id = '123456789012' – If you want to filter on a specific account, you can
remove this comment at the beginning of the line and specify an AWS account.
GROUP BY
1
ORDER BY
TotalSpend DESC,
UsageType;

例: Athena クエリ

次のクエリを使用して、UsageType と Operation の結果を表示できます。これは、CloudWatch の機能でどのようにコストが発生したかを示しています。結果には UsageQuantity と TotalSpend の値も表示されます。これによって、総使用コストを確認できます。

ヒント

UsageType の詳細を確認するには、次の行をこのクエリに追加します。

line_item_line_item_description

この行によって、[Description] (説明) という名前の列が作成されます。


SELECT
bill_payer_account_id as Payer,
line_item_usage_account_id as LinkedAccount,
line_item_usage_type AS UsageType,
line_item_operation AS Operation,
line_item_resource_id AS ResourceID,
SUM(CAST(line_item_usage_amount AS double)) AS UsageQuantity,
SUM(CAST(line_item_unblended_cost AS decimal(16,8))) AS TotalSpend
FROM
costandusagereport 
WHERE
product_product_name = 'AmazonCloudWatch'
AND year='2022' 
AND month='4' 
AND line_item_line_item_type NOT IN ('Tax','Credit','Refund','EdpDiscount','Fee','RIFee')
GROUP BY
bill_payer_account_id,
line_item_usage_account_id,
line_item_usage_type,
line_item_resource_id,
line_item_operation

コスト削減と最適化のためのベストプラクティス

CloudWatch メトリクス

Amazon Elastic Compute Cloud (Amazon EC2)、Amazon S3、Amazon Data Firehose など多くの AWS サービスは、メトリクスを CloudWatch に自動的に無料で送信します。ただし、次のカテゴリに分類されたメトリクスには、追加コストが発生する可能性があります。

カスタムメトリクス、詳細モニターリング、埋め込みメトリクス
API リクエスト
メトリクスストリーム

詳細については、「Amazon CloudWatch メトリクスを使用する」を参照してください。

カスタムメトリクス、詳細モニターリング、埋め込みメトリクス

カスタムメトリクス

カスタムメトリクスを作成して、データポイントを任意の順序や比率で整理できます。

すべてのカスタムメトリクスは時間単位で比例配分されます。CloudWatch に送信されたときにのみ計測されます。メトリクスの料金の詳細については、「Amazon CloudWatch の料金」を参照してください。

次の表に、CloudWatch メトリクスに関連するサブ機能の名前を示します。表には、UsageType と Operation の文字列が含まれています。これは、メトリクス関連のコストを分析して特定するのに役立ちます。

注記

Athena でコストと使用状況のデータをクエリしているときに、次の表に示すメトリクスの詳細を取得するには、Operation の文字列を line_item_operation に示された結果と一致させます。

CloudWatch サブ機能	`UsageType`	`Operation`	目的
カスタムメトリクス	`MetricMonitorUsage`	`MetricStorage`	カスタムメトリクス
詳細モニターリング	`MetricMonitorUsage`	`MetricStorage:AWS/{Service}`	詳細モニターリング
埋め込みメトリクス	`MetricMonitorUsage`	`MetricStorage:AWS/Logs-EMF`	埋め込みメトリクスのログを記録する
ログフィルター	`MetricMonitorUsage`	`MetricStorage:AWS/CloudWatchLogs`	ロググループメトリクスフィルター

詳細モニターリング

CloudWatch には、次の 2 つのタイプのモニターリングがあります。

基本モニターリング

基本モニターリングは無料で、機能をサポートしているすべての AWS サービスで自動的に有効になります。
詳細モニターリング

詳細モニターリングにはコストがかかり、AWS サービスによってさまざまな機能拡張が追加されています。詳細モニターリングをサポートしている AWS サービスの場合は、そのサービスに対して有効にするかどうかを選択できます。詳細については、「基本モニターリングと詳細モニターリング」を参照してください。

注記

その他の AWS サービスでは、詳細モニターリングをサポートしていても、この機能を別の名前で参照している場合があります。例えば、Amazon S3 の詳細モニターリングはリクエストメトリクスと呼ばれます。

カスタムメトリクスと同様に、詳細モニターリングは時間単位で比例配分され、データが CloudWatch に送信されたときにのみ計測されます。詳細モニターリングでは、CloudWatch に送信されるメトクスの数によってコストが発生します。コストを削減するには、必要な場合にのみ詳細モニターリングを有効にします。詳細モニターリングの料金については、「Amazon CloudWatch の料金」を参照してください。

例: Athena クエリ

次のクエリを使用して、詳細モニターリングが有効になっている EC2 インスタンスを確認できます。


SELECT
bill_payer_account_id as Payer,
line_item_usage_account_id as LinkedAccount,
line_item_usage_type AS UsageType,
line_item_operation AS Operation,
line_item_resource_id AS ResourceID,
SUM(CAST(line_item_usage_amount AS double)) AS UsageQuantity,
SUM(CAST(line_item_unblended_cost AS decimal(16,8))) AS TotalSpend
FROM
costandusagereport 
WHERE
product_product_name = 'AmazonCloudWatch'
AND year='2022' 
AND month='4' 
AND line_item_operation='MetricStorage:AWS/EC2'
AND line_item_line_item_type NOT IN ('Tax','Credit','Refund','EdpDiscount','Fee','RIFee')
GROUP BY
bill_payer_account_id,
line_item_usage_account_id,
line_item_usage_type,
line_item_resource_id,
line_item_operation,
line_item_line_item_description
ORDER BY line_item_operation

埋め込みメトリクス

CloudWatch 埋め込みメトリクス形式を使用すると、アプリケーションデータをログデータとして取り込むことができるため、実用的なメトリクスを生成できます。詳細については、「高カーディナリティログの取り込みと CloudWatch 埋め込みメトリクスフォーマットによるメトリクスの生成」を参照してください。

埋め込みメトリクスでは、取り込まれたログの数、アーカイブされたログの数、生成されたカスタムメトリクスの数によってコストが発生します。

次の表に、CloudWatch 埋め込みメトリクス形式に関連するサブ機能の名前を示します。表には、UsageType と Operation の文字列が含まれています。これは、コストを分析して特定するのに役立ちます。

CloudWatch サブ機能	`UsageType`	`Operation`	目的
カスタムメトリクス	`MetricMonitorUsage`	`MetricStorage:AWS/Logs-EMF`	埋め込みメトリクスのログを記録する
ログの取り込み	`DataProcessing-Bytes`	`PutLogEvents`	一連のログイベントのバッチを指定されたロググループまたはログストリームにアップロードする
ログのアーカイブ	`TimedStorage-ByteHrs`	`HourlyStorageMetering`	CloudWatch Logs に 1 時間あたりのログとバイトあたりのログを保存する

コストを分析するには、AWS Cost and Usage Report を Athena とともに使用すると、コストを発生させているメトリクスを特定し、コストがどのように発生するかを判断できます。

CloudWatch 埋め込みメトリクス形式によって発生するコストを最大限に活用するには、カーディナリティの高いディメンションに基づくメトリクスの作成は避けてください。そうすれば、CloudWatch は一意のディメンションの組み合わせごとにカスタムメトリクスを作成しません。詳細については、「ディメンション」を参照してください。

埋め込みメトリクス形式を活用するために CloudWatch Container Insights を使用している場合は、メトリクス関連のコストを最大限に活用するための代替手段として AWS Distro for Open Telemetry を使用できます。Container Insights を使用して、コンテナ化されたアプリケーションとマイクロサービスのメトリクスとログを収集、集計、要約できます。Container Insights を有効にすると、CloudWatch エージェントはログを CloudWatch に送信し、ログを使用して埋め込みメトリクスを生成できるようにします。ただし、CloudWatch エージェントは CloudWatch に単に一定数のメトリクスを送信し、使用していないものも含め、使用可能なすべてのメトリクスに対して課金されます。AWS Distro for Open Telemetry では、CloudWatch に送信されるメトリクスとディメンションを設定およびカスタマイズできます。これにより、Container Insights が生成するデータ量とコストを削減できます。詳細については、以下のリソースを参照してください。

API リクエスト

CloudWatch には次のタイプの API リクエストがあります。

API リクエスト
バルク (取得)
Contributor Insights
ビットマップイメージスナップショット

API リクエストでは、リクエストタイプとリクエストされたメトリクスの数によってコストが発生します。

次の表に、API リクエストのタイプと、UsageType と Operation の文字列を示します。これは、API 関連のコストを分析して特定するのに役立ちます。

API リクエストのタイプ	`UsageType`	`Operation`	目的
API リクエスト	`Requests`	`GetMetricStatistics`	指定されたメトリクスの統計情報を取得する
	`Requests`	`ListMetrics`	指定されたメトリクスを一覧表示する
	`Requests`	`PutMetricData`	メトリックスのデータポイントを CloudWatch に発行する
	`Requests`	`GetDashboard`	指定されたダッシュボードの詳細を表示する
	`Requests`	`ListDashboards`	アカウントのダッシュボードを一覧表示する
	`Requests`	`PutDashboard`	ダッシュボードを作成または更新する
	`Requests`	`DeleteDashboards`	指定されたダッシュボードをすべて削除する
バルク (取得)	`GMD-Metrics`	`GetMetricData`	CloudWatch メトリクス値を取得する
Contributor Insights	`GIRR-Metrics`	`GetInsightRuleReport`	Contributor Insights ルールによって収集された時系列データを返す
ビットマップイメージスナップショット	`GMWI-Metrics`	`GetMetricWidgetImage`	1 つまたは複数の CloudWatch メトリクスのスナップショットをビットマップイメージとして取得する

コストを分析するには、Cost Explorer を使用して、結果を API オペレーションによってグループ化します。

API リクエストのコストはさまざまで、AWS 無料利用枠の制限以下で提供される API 呼び出しの数を超えるとコストが発生します。

注記

GetMetricData と GetMetricWidgetImage は、AWS 無料利用枠の制限には含まれません。詳細については、「AWS Billing ユーザーガイド」の「AWS 無料利用枠の使用」を参照してください。

一般的にコストがかかる API リクエストは、Put と Get リクエストです。

PutMetricData

PutMetricData が呼び出されるたびにコストが発生し、ユースケースによっては多大なコストが発生する可能性があります。詳細については、「Amazon CloudWatch API リファレンス」の「PutMetricData」を参照してください。

PutMetricData によって発生するコストを最大限に活用するには、より多くのデータを一括して API 呼び出しをします。ユースケースによっては、CloudWatch Logs または CloudWatch 埋め込みメトリクス形式を使用して、メトリクスデータを盛り込むことを検討してください。詳細については、以下のリソースを参照してください。

Amazon CloudWatch Logs ユーザーガイドの「Amazon CloudWatch Logs とは」
高カーディナリティログの取り込みと CloudWatch 埋め込みメトリクスフォーマットによるメトリクスの生成
Amazon CloudWatch 埋め込みカスタムメトリクスでコストを削減し、お客様に重点を置く

GetMetricData

また、GetMetricData でも多大なコストが発生する可能性があります。コストを押し上げる一般的なユースケースには、データを取得してインサイトを生成するサードパーティのモニターリングツールが関連しています。詳細については、「Amazon CloudWatch API リファレンス」の「GetMetricData」を参照してください。

GetMetricData によって発生するコストを削減するには、モニターリングし使用するデータのみを取得することを検討するか、データを取得する頻度を減らすことを検討してください。ユースケースによっては、GetMetricData ではなくメトリクスストリームを使用することを検討するとよいかもしれません。これにより、低コストでデータをほぼリアルタイムでサードパーティにプッシュできます。詳細については、以下のリソースを参照してください。

GetMetricStatistics

ユースケースによっては、GetMetricData ではなく GetMetricStatistics を使用することを検討するとよいかもしれません。GetMetricData を使用すると、データを迅速かつ大規模に取得できます。しかし、GetMetricStatistics は最大 100 万回の API リクエストに対する AWS 無料利用枠の制限に含まれます。1 回の呼び出しでそれほど多くのメトリクスとデータポイントを取得する必要がない場合に、コストを削減できます。詳細については、以下のリソースを参照してください。

「Amazon CloudWatch API リファレンス」の「GetMetricStatistics」
GetMetricData を使うべきでしょうか、それとも GetMetricStatistics を使うべきでしょうか。

注記

外部呼び出し元は API 呼び出しを行います。CloudTrail データイベント (GetMetricData や GetMetricWidgetImage など) でサポートされている API の場合、CloudTrail を使用して最上位の CloudWatch API 呼び出し元を特定し、予期しない呼び出しを軽減または特定できます。詳細については、「CloudTrail を使用して CloudWatch API 使用状況を分析する方法」を参照してください。CloudTrail でサポートされていない他の CloudWatch API については、CloudWatch チームへのテクニカルサポートリクエストを開き、その情報を請求してください。テクニカルサポートリクエストの作成の詳細については、「AWS の技術サポートを受けるにはどうすればよいですか?」を参照してください。

CloudWatch メトリクスストリーム

CloudWatch メトリクスストリームを使用すると、メトリクスを継続的に AWS の送信先とサードパーティのサービスプロバイダーの送信先に送信できます。

メトリクスストリームは、メトリクス更新の件数によってコストが発生します。メトリクス更新には、常に次の統計情報の値が含まれています。

Minimum
Maximum
Sample Count
Sum

詳細については、「ストリーミングできる統計情報」を参照してください。

CloudWatch メトリクスストリームによって発生するコストを分析するには、AWS Cost and Usage Report を Athena とともに使用します。これにより、コストが発生しているメトリクストリームを特定し、コストがどのように発生するかを判断できます。

例: Athena クエリ

次のクエリを使用して、Amazon リソースネーム (ARN) ごとにコストが発生するメトリクスストリームを追跡できます。


SELECT
SPLIT_PART(line_item_resource_id,'/',2) AS "Stream Name",
line_item_resource_id as ARN,
SUM(CAST(line_item_unblended_cost AS decimal(16,2))) AS TotalSpend
FROM
costandusagereport 
WHERE
product_product_name = 'AmazonCloudWatch'
AND year='2022' 
AND month='4' 
AND line_item_line_item_type NOT IN ('Tax','Credit','Refund','EdpDiscount','Fee','RIFee')
-- AND line_item_usage_account_id = '123456789012' – If you want to filter on a specific account, you can
remove this comment at the beginning of the line and specify an AWS account.
AND line_item_usage_type LIKE '%%MetricStreamUsage%%'
GROUP BY line_item_resource_id
ORDER BY TotalSpend DESC

CloudWatch メトリクスストリームによって発生するコストを削減するには、ビジネス価値をもたらすメトリクスのみをストリーミングします。また、使用していないメトリクスストリームを停止または一時停止することもできます。

CloudWatch アラーム

CloudWatch アラームでは、1 つのメトリクスに基づくアラーム、Metrics Insights のクエリに基づくアラーム、他のアラームを監視する複合アラームを作成できます。

注記

メトリクスアラームおよび複合アラームのコストは、1 時間単位で比例配分されます。アラームのコストが発生するのは、アラームが存在している間のみです。コストを最適化するためには、設定ミスのあるアラームや価値の低いアラームを残さないことが必要です。これを解決するため、不要になった CloudWatch アラームのクリーンアップを自動化できます。詳細については、「Amazon CloudWatch アラームの大規模なクリーンアップを自動化する」を参照してください。

[Metric alarms] (メトリクスアラーム)

メトリクスアラームには次の解像度設定があります。

標準 (60 秒ごとに評価)
高解像度 (10 秒ごとに評価)

メトリクスアラームを作成する場合、コストはアラームの解像度の設定と、アラームが参照するメトリクスの数に基づきます。たとえば、1 つのメトリクスを参照するメトリクスアラームには、1 時間あたり 1 つのアラームメトリックのコストが発生します。詳細については、「Using Amazon CloudWatch alarms」(Amazon CloudWatch アラームを使用する) を参照してください。

複数のメトリクスを参照するメトリクス数式を含むメトリクスアラームを作成する場合、メトリクスの数式で参照されるアラームメトリクスごとにコストが発生します。メトリクス数式を含むメトリクスアラームを作成する方法については、「メトリクスの数式に基づく CloudWatch アラームの作成」を参照してください。

アラームが過去のメトリクスデータを分析して期待値のモデルを作成する異常検出アラームを作成する場合、アラームで参照される各アラームメトリクスと 2 つの追加メトリクス (異常検出モデルが作成する上限および下限帯域メトリクス用に 1 つ) のコストが発生します。異常検出アラームを作成する方法については、「異常検出に基づく CloudWatch アラームの作成」を参照してください。

Metrics Insights クエリアラーム

Metric Insights クエリアラームは特定のタイプのメトリクスアラームで、標準解像度 (60 秒ごとに評価) でのみ使用できます。

Metric Insights クエリアラームを作成する場合、コストはアラームが参照するクエリによって分析されるメトリクスの数に基づきます。例えば、フィルターが 10 個のメトリクスに一致するクエリを参照する Metric Insights クエリアラームでは、1 時間あたりメトリクス 10 個分の分析コストが発生します。詳細については、「Amazon CloudWatch の料金」で料金の例を確認してください。

Metrics Insights クエリとメトリクスの数式の両方を含むアラームを作成する場合、Metrics Insights クエリアラームとして報告されます。Metrics Insights クエリで分析されるメトリクスに加え、他のメトリクスを参照するメトリクスの数式がアラームに含まれる場合、メトリクスの数式で参照されるアラームメトリクスごとにコストが発生します。メトリクス数式を含むメトリクスアラームを作成する方法については、「メトリクスの数式に基づく CloudWatch アラームの作成」を参照してください。

[Composite alarms] (複合アラーム)

複合アラームには、他のアラームの状態を評価して自身の状態を判断する方法を指定するルール式が含まれています。複合アラームは、評価される他のアラームの数に関係なく、1 時間あたりの標準コストが発生します。複合アラームがルール式で参照するアラームには、個別のコストが発生します。詳細については、「複合アラームの作成」を参照してください。

[Alarm usage types] (アラームの使用タイプ)

次の表に、CloudWatch アラームに関連するサブ機能の名前を示します。表には、UsageType の文字列が含まれています。これは、アラーム関連のコストを分析して特定するのに役立ちます。

CloudWatch サブ機能	`UsageType`
標準メトリクスアラーム	`AlarmMonitorUsage`
高解像度メトリクスアラーム	`HighResAlarmMonitorUsage`
Metrics Insights クエリアラーム	`MetricInsightAlarmUsage`
複合アラーム	`CompositeAlarmMonitorUsage`

アラームコストの削減

4 つ以上のメトリクスを集計するメトリクス演算アラームによって発生するコストを最大限に活用するために、データが CloudWatch に送信される前にデータを集計するカスタムメトリクスを作成できます。こうすると、複数のメトリクスのデータを集計するアラームではなく、単一のメトリクスのアラームを作成できます。詳細については、カスタムメトリクスの発行を参照してください。

Metrics Insights クエリアラームによって発生するコストを最大限に活用するには、クエリに使用されるフィルターがモニターリング対象のメトリクスにのみ一致するようにします。

コストを削減する最善の方法は、不要なアラームや使用していないアラームをすべて削除することです。たとえば、すでに存在しない AWS リソースによって発行されたメトリクスを評価するアラームを削除できます。

Example: Check for alarms in INSUFFICIENT_DATA state with DescribeAlarms

リソースを削除しても、そのリソースが発行するメトリックアラームを削除しない場合、アラームは引き続き存在し、通常 INSUFFICIENT_DATA の状態になります。アラームが INSUFFICIENT_DATA の状態になっているかどうかを確認するには、次の AWS Command Line Interface (AWS CLI) コマンドを使用します。


$ aws cloudwatch describe-alarms –state-value INSUFFICIENT_DATA

詳細については、「Amazon CloudWatch アラームの大規模なクリーンアップを自動化する」を参照してください。

その他に次のようなコスト削減方法があります。

正しいメトリクスのアラームを作成していることを確認してください。
作業していないリージョンでアラームが有効になっていないことを確認してください。
複合アラームはノイズを低減しますが、追加コストも発生することに留意してください。
標準アラームと高解像度アラームのどちらを作成するかを決めるときは、ユースケースと、各タイプのアラームがもたらす価値を考慮してください。

CloudWatch ログ

Amazon CloudWatch Logs には次のログタイプがあります。

カスタムログ (アプリケーション用に作成するログ)
提供されるログ (Amazon Virtual Private Cloud (Amazon VPC) や Amazon Route 53 など、他の AWS サービスがユーザーに代わって作成するログ)

提供されるログの詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「特定の AWS のサービスからのログの記録を有効にする」を参照してください。

カスタムログと提供されるログでは、収集、保存、分析されたログの数に基づいてコストが発生します。これとは別に、提供されるログでは Amazon S3 と Firehose への配信コストが発生します。

次の表に、CloudWatch Logs 機能の名前と関連するサブ機能の名前を示します。表には、UsageType と Operation の文字列が含まれます。これは、ログ関連のコストを分析して特定するのに役立ちます。

CloudWatch Logs の機能	CloudWatch Logs のサブ機能	`UsageType`	`Operation`	目的
カスタムログ	収集 (標準ログクラスのデータインジェスト)	`DataProcessing-Bytes`	`PutLogEvents`	標準クラスのロググループ内の特定のログストリームにログのバッチをアップロードします。
	収集 (低頻度アクセスログクラスのデータインジェスト)	`DataProcessingIA-Bytes`	`PutLogEvents`	低頻度アクセスクラスのロググループ内の特定のログストリームにログのバッチをアップロードします。
	検出とマスク (データ保護)	`DataProtection-Bytes`	`PutLogEvents`	ログイベント内の保護されたデータを検出してマスクします。
	保存 (アーカイブ)	`TimedStorage-ByteHrs`	`HourlyStorageMetering`	CloudWatch Logs に 1 時間あたりのログとバイトあたりのログを保存します。
	分析 (Logs Insights クエリ)	`DataScanned-Bytes`	`StartQuery`	CloudWatch Logs Insights クエリによってスキャンされたデータをログに記録する
	分析 (Logs Live Tail)	`Logs-LiveTail`	`StartLiveTail`	CloudWatch Logs Live Tail セッション中に分析されたログ
提供されるログ	配信 (CloudWatch Logs 標準ログクラス)	`VendedLog-Bytes`	`PutLogEvents`	標準ログクラスのロググループ内の特定のログストリームにログのバッチをアップロードします。
	配信 (CloudWatch Logs 低頻度アクセスログクラス)	`VendedLogIA-Bytes`	`PutLogEvents`	低頻度アクセスログクラスのロググループ内の特定のログストリームにログのバッチをアップロードします。
	配信 (Amazon S3)	`S3-Egress-Bytes`	`LogDelivery`	提供されたログのバッチを特定の S3 バケットにアップロードします。
	Parquet 形式の配信 (Amazon S3)	`S3-Egress-InputBytes`	`ParquetConversion`	Amazon S3 に配信されたログに対して Parquet 変換を実行する
	配信 (Firehose)	`FH-Egress-Bytes`	`LogDelivery`	提供されたログのバッチを Amazon Data Firehose にアップロードします。

コストを分析するには、AWS Cost and Usage Report を Athena とともに使用して、コストを発生させているログを特定し、コストがどのように発生しているかを判断できます。

例: Athena クエリ

次のクエリを使用して、リソース ID 別にコストが発生するログを追跡できます。


SELECT
bill_payer_account_id as Payer,
line_item_usage_account_id as LinkedAccount,
line_item_resource_id AS ResourceID,
line_item_usage_type AS UsageType,
SUM(CAST(line_item_unblended_cost AS decimal(16,8))) AS TotalSpend,
SUM(CAST(line_item_usage_amount AS double)) AS UsageQuantity
FROM
costandusagereport 
WHERE
product_product_name = 'AmazonCloudWatch'
AND year='2022'
AND month='4'
AND line_item_operation IN ('PutLogEvents','HourlyStorageMetering','StartQuery','LogDelivery','StartLiveTail','ParquetConversion')
AND line_item_line_item_type NOT IN ('Tax','Credit','Refund','EdpDiscount','Fee','RIFee')
GROUP BY
bill_payer_account_id,
line_item_usage_account_id,
line_item_usage_type,
line_item_resource_id,
line_item_operation
ORDER BY
TotalSpend DESC

CloudWatch Logs によって発生するコストを最大限に活用するには、以下を考慮してください。

ビジネス価値をもたらすイベントのみをログに記録します。これにより、取り込みコストが削減されます。
ログの保持設定を変更して、ストレージにかかるコストを抑えます。詳細については、「Amazon CloudWatch Logs User Guide」(Amazon CloudWatch Logs ユーザーガイド) の「Change log data retention in CloudWatch Logs」(CloudWatch ログでのログデータ保管期間の変更) を参照してください。
CloudWatch Logs Insights が自動的に履歴に保存するクエリを実行します。これにより、分析にかかるコストが少なくなります。詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「実行中のクエリまたはクエリ履歴を表示する」を参照してください。
CloudWatch エージェントを使用して、システムログとアプリケーションログを収集し、CloudWatch に送信します。これにより、条件を満たすログイベントのみを収集できます。詳細については、「Amazon CloudWatch エージェントは、ログフィルター式のサポートを追加」を参照してください。

提供されるログのコストを削減するには、ユースケースを検討し、ログを CloudWatch または Amazon S3 に送信するかどうかを決定します。詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「Amazon S3 に送信されたログ」を参照してください。

ヒント

メトリクスフィルター、サブスクリプションフィルター、CloudWatch Logs Insights、Contributor Insights を使用する場合は、公開ログを CloudWatch に送信します。

また、VPC フローログを操作し、監査とコンプライアンスの目的で使用している場合は、提供されるログを Amazon S3 に送信します。

VPC フローログを S3 バケットに公開することで発生する料金を追跡する方法については、「AWS Cost and Usage Report とコスト配分タグを使用して、Amazon S3 への VPC フローログのデータインジェストのコストを知る」を参照してください。

CloudWatch Logs によって発生するコストを最大限に活用する方法の詳細については、「CloudWatch Logs の請求が急に増加したのですが、どのロググループが原因でしょうか?」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

リソースグループの事前構築済みダッシュボードを表示する

ダッシュボード