# CloudWatch コストを分析、最適化、削減する
このセクションでは、Amazon CloudWatch の機能でどのようにコストが発生するかについて説明します。また、CloudWatch のコストを分析、最適化、削減するのに役立つ方法についても説明します。このセクション全体を通して、CloudWatch 機能を説明する際に料金について言及することがあります。料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/?nc1=h_ls)」を参照してください。
**Topics**
+ [Cost Explorer で CloudWatch のコストと使用状況データを分析する](#cloudwatch_billing_costs)
+ [CloudWatch のコストと使用状況データを AWS Cost and Usage Report と Athena で分析する](#cloudwatch_billing_billing_info)
+ [CloudWatch メトリクスのコストを最適化し削減する](#cloudwatch_billing_billing_metric)
+ [CloudWatch アラームのコストを最適化し削減する](#cloudwatch_billing_billing_alarms)
+ [CloudWatch Container Insights のコストを最適化し削減する](#cloudwatch_billing_container-insights)
+ [CloudWatch Database Insights のコストを最適化し削減する](#cloudwatch_billing_database-insights)
+ [CloudWatch Logs のコストを最適化し削減する](#cloudwatch_billing_billing_logs)
## Cost Explorer で CloudWatch のコストと使用状況データを分析する
AWS Cost Explorer では、CloudWatch を含む AWS のサービス のコストと使用状況のデータを時間の経過を追って可視化して分析できます。詳細については、「[AWS Cost Explorer の開始方法](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/getting-started/)」を参照してください。
以下の手順では、Cost Explorer を使用して CloudWatch のコストと使用状況データを可視化および分析する方法について説明します。
### CloudWatch のコストと使用状況データを可視化して分析するには
1. Cost Explorer コンソールにサインインします [https://console.aws.amazon.com/cost-management/home\$1/custom](https://console.aws.amazon.com/cost-management/home#/custom)。
1. **[FILTERS]** (フィルター) で、**[Service]** (サービス) に **[CloudWatch]** を選択します。
1. **[Group by]** (グループ化の条件) には **[Usage Type]** (使用タイプ) を選択します。また、次のような他のカテゴリ別に結果をグループ化することもできます。
+ **[API Operation]** (API オペレーション) – 最もコストがかかった API オペレーションを確認する。
+ **[Region]** (リージョン) – 最もコストがかかったリージョンを確認する。
次の画像は、CloudWatch の機能によって 6 か月間に発生したコストの例を示しています。
![\[使用タイプのコストを棒グラフ形式で表示している AWS Cost Explorer インターフェイススクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/ce.png)
最もコストがかかった CloudWatch 機能を知るには、`UsageType` の値を確認します。例えば、`EU-CW:GMD-Metrics` は、CloudWatch バルク API リクエストによって発生したコストを表します。
**注記**
`UsageType` の文字列は、特定の機能およびリージョンと一致します。例えば、`EU-CW:GMD-Metrics` の最初の部分 (`EU`) は欧州 (アイルランド) リージョンと一致し、`EU-CW:GMD-Metrics` の後半の部分 (`GMD-Metrics`) は CloudWatch バルク API リクエストと一致します。
`UsageType` の文字列全体は `-CW:` または `-` の形式になっています。
ログやアラームなどの一部の CloudWatch 機能は、`Global` リージョンを使用して無料利用枠の使用状況を特定します。例えば、`Global-DataScanned-Bytes` は無料の CloudWatch Logs データインジェストの使用状況を表します。
読みやすくするために、このドキュメント全体を通して、表の中の `UsageType` の文字列は、文字列の後半の部分に短縮されています。例えば、`EU-CW:GMD-Metrics` は `GMD-Metrics` に短縮されます。
次の表に、各 CloudWatch 機能の名前、各サブ機能の名前、および `UsageType` の文字列を示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/cloudwatch_billing.html)
## 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 とは?](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)」を参照してください。
**注記**
AWS Cost and Usage Report の使用料は発生しません。ストレージに対して料金が発生するのは、Amazon Simple Storage Service (Amazon S3) にレポートを発行するときのみです。詳細については、「AWS Cost and Usage Report ユーザーガイド」の「[クォータと制限](https://docs.aws.amazon.com/cur/latest/userguide/billing-cur-limits.html)」を参照してください。
Athena は、コストと使用状況データを分析するために AWS Cost and Usage Report で使用できるクエリサービスです。S3 バケット内のレポートは、最初にダウンロードしなくてもクエリできます。詳細については、「Amazon Athena ユーザーガイド」の「[Amazon Athena とは](https://docs.aws.amazon.com/athena/latest/ug/what-is.html)」を参照してください。詳細については、「Amazon Athena ユーザーガイド」の「[Amazon Athena とは](https://docs.aws.amazon.com/athena/latest/ug/what-is.html)」を参照してください。料金に関する詳細については、「[Amazon Athena の料金](https://aws.amazon.com/athena/pricing/)」を参照してください。
以下の手順では、AWS Cost and Usage Report を有効にして、このサービスを Athena と統合するプロセスを説明します。この手順には、CloudWatch のコストと使用状況データを分析するために使用できる 2 つのクエリ例が含まれています。
**注記**
このドキュメント内のクエリ例は、どれでも使用してかまいません。このドキュメント内のクエリ例はすべて、***costandusagereport*** という名前のデータベースに対応しており、2025 年 4 月の結果を表示します。この情報は、変更することができます。ただし、クエリを実行する前に、データベースの名前がクエリ内のデータベースの名前と一致していることを確認してください。
### AWS Cost and Usage Report と Athena を使用してコストと使用状況のデータを分析するには
1. AWS Cost and Usage Report を有効にします。詳細については、「AWS Cost and Usage Report ユーザーガイド」の「[コストと使用状況レポートを作成する](https://docs.aws.amazon.com/cur/latest/userguide/cur-create.html)」を参照してください。
**ヒント**
レポートを作成するときは、**[Include resource IDs]** (リソース ID を含める) を必ず選択してください。そうしないと、レポートに `line_item_resource_id` の列が含まれません。この行は、コストと使用状況データを分析するときにコストをさらに特定するのに役立ちます。
1. AWS Cost and Usage Report を Athena と統合します。詳細については、「AWS Cost and Usage Report ユーザーガイド」の「[CloudFormation テンプレートを使用した Athena の設定](https://docs.aws.amazon.com/cur/latest/userguide/use-athena-cf.html)」を参照してください。
1. コストと使用状況のレポートをクエリします。
**Example 1 か月あたりの CloudWatch コストを表示する 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'
-- Contributor Insights
WHEN line_item_usage_type LIKE '%%Contributor%%' THEN 'Contributor Insights'
-- 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)'
-- Container Insights with enhanced observability
WHEN (line_item_usage_type LIKE '%%MetricsUsage%%' OR line_item_usage_type LIKE '%%ObservationUsage%%') THEN 'Container Insights (Enhanced Observability)'
-- Database Insights
WHEN line_item_usage_type LIKE '%%DatabaseInsights%%' THEN 'Database Insights'
-- 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%%') THEN 'Vended Logs (Delivered to S3)'
-- Network Monitoring
WHEN line_item_usage_type LIKE '%%CWNMHybrid-Paid%%' THEN 'Network Monitor'
WHEN line_item_usage_type LIKE '%%InternetMonitor%%' THEN 'Internet Monitor'
-- 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 '%%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='2025'
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;
```
**Example CloudWatch 機能でコストがどのように発生したかを示す 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='2025'
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 メトリクスを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)」を参照してください。
### カスタムメトリクス
カスタムメトリクスを作成して、データポイントを任意の順序や比率で整理できます。
すべてのカスタムメトリクスは時間単位で比例配分されます。CloudWatch に送信されたときにのみ計測されます。メトリクスの料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/?nc1=h_ls)」を参照してください。
次の表に、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 のサービス の場合は、そのサービスに対して有効にするかどうかを選択できます。詳細については、「[基本モニターリングと詳細モニターリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-basic-detailed.html)」を参照してください。
**注記**
その他の AWS のサービス では、詳細モニターリングをサポートしていても、この機能を別の名前で参照している場合があります。例えば、Amazon S3 の詳細モニターリングは**リクエストメトリクス**と呼ばれます。
カスタムメトリクスと同様に、詳細モニターリングは時間単位で比例配分され、データが CloudWatch に送信されたときにのみ計測されます。詳細モニターリングでは、CloudWatch に送信されるメトクスの数によってコストが発生します。コストを削減するには、必要な場合にのみ詳細モニターリングを有効にします。詳細モニターリングの料金については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/?nc1=h_ls)」を参照してください。
**例: 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='2025'
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 埋め込みメトリクス形式によるメトリクスの生成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html)」を参照してください。
埋め込みメトリクスでは、取り込まれたログの数、アーカイブされたログの数、生成されたカスタムメトリクスの数によってコストが発生します。
次の表に、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 は一意のディメンションの組み合わせごとにカスタムメトリクスを作成しません。詳細については、「[ディメンション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension)」を参照してください。
### 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 オペレーション**によってグループ化します。
請求コンソールでは、*Requests* という UsageType の下に汎用 API リクエストが表示されます。具体的には、*1,000 件のリクエストあたり X.XX USD - [リージョン]* というように表示されます。このレートは、UsageType が Requests のすべてのリクエストに適用され、無料利用枠の上限を超えて集計されます。
API リクエストのコストはさまざまで、AWS 無料利用枠の制限以下で提供される API 呼び出しの数を超えるとコストが発生します。
**注記**
AWS 無料利用枠の制限に含まれているのは、UsageType が *Requests* の API リクエストのみです。UsageType がそれ以外の API リクエストでは、最初の呼び出しから料金が発生します。詳細については、「AWS Billing ユーザーガイド」の「[AWS 無料利用枠の使用](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-free-tier.html)」を参照してください。
一般的にコストがかかる API リクエストは、`Put` と `Get` リクエストです。
API リクエストの発生元をモニタリングし、アカウント内のユーザーを識別するには、CloudTrail でデータイベントを有効にし、次のいずれかを使用して記録されたイベントを分析します。
+ Amazon CloudWatch Logs で Log Insights を使用する
+ Amazon S3 で Amazon Athena を使用する
**注記**
データイベントは、証跡とイベントデータストアによって自動的にログに記録されるわけではありません。データイベントをログに記録するには、追加コストが発生します。詳細については、[AWS CloudTrail の料金](https://aws.amazon.com/cloudtrail/pricing/)を参照してください。
詳細については、「[データイベントをログ記録する](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html)」と「[Identifying resources driving CloudWatch GetMetricData charges using AWS CloudTrail](https://aws.amazon.com/blogs/mt/identifying-resources-driving-amazon-cloudwatch-getmetricdata-charges-using-aws-cloudtrail/)」を参照してください。
***`API calls not incurring charges`***
CloudTrail で CloudWatch データイベントをログに記録したときに、開始した数よりも多くの呼び出しが表示されることがあります。これが発生するのは、CloudTrail で CloudWatch データイベントをログに記録すると、内部コンポーネントによる API アクションがキャプチャされるためです。内部コンポーネントによる呼び出しでは、CloudWatch の料金は発生しません。ただし、こうしたイベントは CloudTrail イベントログ記録の合計に加算されるため、CloudTrail の料金に影響を与える可能性があります。
例えば、CloudTrail はソースアカウントからデータを取得するためにモニタリングアカウントが開始した GetMetricData コールを記録し、さらにウィジェットデータを更新するために CloudWatch ダッシュボードが開始した GetMetricData コールを記録します。こうした API コールでは、CloudWatch の料金は発生しません。
***`PutMetricData`***
CloudWatch `PutMetricData` API コールでは、コールのたびに料金が発生します。頻繁に呼び出すと、コストが大幅に増大することがあります。大量のデータをモニタリングしている場合には特にそうです。コストを削減するには、各 API コールで複数のメトリクスをバッチ処理する、モニタリングの頻度を調整するといったことを検討してみてください。詳細については、「Amazon CloudWatch API リファレンス」の「[PutMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricData.html)」を参照してください。
`PutMetricData` によって発生するコストを最大限に活用するには、より多くのデータを一括して API 呼び出しをします。ユースケースによっては、CloudWatch Logs または CloudWatch 埋め込みメトリクス形式を使用して、メトリクスデータを盛り込むことを検討してください。詳細については、以下のリソースを参照してください。
+ *Amazon CloudWatch Logs ユーザーガイド*の「[Amazon CloudWatch Logs とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)」
+ [高カーディナリティログの取り込みと CloudWatch 埋め込みメトリクス形式によるメトリクスの生成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html)
+ [Amazon CloudWatch 埋め込みカスタムメトリクスでコストを削減し、お客様に重点を置く](https://aws.amazon.com/blogs/mt/lowering-costs-and-focusing-on-our-customers-with-amazon-cloudwatch-embedded-custom-metrics/)
***`GetMetricData`***
CloudWatch `GetMetricData` API オペレーションによっても、コストが大幅に増大することがあります。サードパーティのモニタリングツールでは、インサイトを生成するために頻繁にデータを取得してコストが増大することがよくあります。`GetMetricData` の使用料金とベストプラクティスの詳細については、「*Amazon CloudWatch API Reference*」の「[GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)」を参照してください。
`GetMetricData` によって発生するコストを削減するには、モニターリングし使用するデータのみを取得することを検討するか、データを取得する頻度を減らすことを検討してください。ユースケースによっては、`GetMetricData` ではなくメトリクスストリームを使用することを検討するとよいかもしれません。これにより、低コストでデータをほぼリアルタイムでサードパーティにプッシュできます。詳細については、以下のリソースを参照してください。
+ [メトリクスストリームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html)
+ [CloudWatch メトリクスストリーム - AWS メトリクスをパートナーとアプリケーションにリアルタイムで送信する](https://aws.amazon.com/blogs/aws/cloudwatch-metric-streams-send-aws-metrics-to-partners-and-to-your-apps-in-real-time/)
***`GetMetricStatistics`***
ユースケースによっては、`GetMetricData` ではなく `GetMetricStatistics` を使用することを検討するとよいかもしれません。`GetMetricData` を使用すると、データを迅速かつ大規模に取得できます。しかし、`GetMetricStatistics` は最大 100 万回の API リクエストに対する AWS 無料利用枠の制限に含まれます。1 回の呼び出しでそれほど多くのメトリクスとデータポイントを取得する必要がない場合に、コストを削減できます。詳細については、以下のリソースを参照してください。
+ 「Amazon CloudWatch API リファレンス」の「[GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)」
+ [GetMetricData を使うべきでしょうか、それとも GetMetricStatistics を使うべきでしょうか。](https://aws.amazon.com/premiumsupport/knowledge-center/cloudwatch-getmetricdata-api/)
**注記**
外部呼び出し元は API 呼び出しを行います。CloudTrail データイベント (**GetMetricData** や **GetMetricWidgetImage** など) でサポートされている API の場合、CloudTrail を使用して最上位の CloudWatch API 呼び出し元を特定し、予期しない呼び出しを軽減または特定できます。詳細については、「[CloudTrail を使用して CloudWatch API 使用状況を分析する方法](https://community.aws/content/2iyFpJMy6oRlAXFgAL1dbJLUXbh/how-to-use-cloudwatch-api-with-cloudtrail)」を参照してください。CloudTrail でサポートされていない他の CloudWatch API については、CloudWatch チームへのテクニカルサポートリクエストを開き、その情報を請求してください。テクニカルサポートリクエストの作成の詳細については、「[AWS の技術サポートを受けるにはどうすればよいですか?](https://aws.amazon.com/de/premiumsupport/knowledge-center/get-aws-technical-support/)」を参照してください。
### CloudWatch メトリクスストリーム
CloudWatch メトリクスストリームを使用すると、メトリクスを継続的に AWS の送信先とサードパーティのサービスプロバイダーの送信先に送信できます。
メトリクスストリームは、メトリクス更新の件数によってコストが発生します。メトリクス更新には、常に次の統計情報の値が含まれています。
+ `Minimum`
+ `Maximum`
+ `Sample Count`
+ `Sum`
詳細については、「[ストリーミングできる統計情報](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-metric-streams-statistics.html)」を参照してください。
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='2025'
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 アラームの大規模なクリーンアップを自動化する](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarm-cleanup-at-scale/)」を参照してください。
### メトリクスのアラーム
メトリクスアラームには次の解像度設定があります。
+ **標準** (60 秒ごとに評価)
+ **高解像度** (10 秒ごとに評価)
メトリクスアラームを作成する場合、コストはアラームの解像度の設定と、アラームが参照するメトリクスの数に基づきます。たとえば、1 つのメトリクスを参照するメトリクスアラームには、1 時間あたり 1 つのアラームメトリックのコストが発生します。詳細については、「[Using Amazon CloudWatch alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Alarms.html)」(Amazon CloudWatch アラームを使用する) を参照してください。
複数のメトリクスを参照するメトリクス数式を含むメトリクスアラームを作成する場合、メトリクスの数式で参照されるアラームメトリクスごとにコストが発生します。メトリクス数式を含むメトリクスアラームを作成する方法については、「[メトリクスの数式に基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html)」を参照してください。
アラームが過去のメトリクスデータを分析して期待値のモデルを作成する異常検出アラームを作成する場合、アラームで参照される各アラームメトリクスと 2 つの追加メトリクス (異常検出モデルが作成する上限および下限帯域メトリクス用に 1 つ) のコストが発生します。異常検出アラームを作成する方法については、「[異常検出に基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)」を参照してください。
### Metrics Insights クエリアラーム
Metric Insights クエリアラームは特定のタイプのメトリクスアラームで、標準解像度 (60 秒ごとに評価) でのみ使用できます。
Metric Insights クエリアラームを作成する場合、コストはアラームが参照するクエリによって分析されるメトリクスの数に基づきます。例えば、フィルターが 10 個のメトリクスに一致するクエリを参照する Metric Insights クエリアラームでは、1 時間あたりメトリクス 10 個分の分析コストが発生します。詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/?nc1=h_ls)」で料金の例を確認してください。
Metrics Insights クエリとメトリクスの数式の両方を含むアラームを作成する場合、Metrics Insights クエリアラームとして報告されます。Metrics Insights クエリで分析されるメトリクスに加え、他のメトリクスを参照するメトリクスの数式がアラームに含まれる場合、メトリクスの数式で参照されるアラームメトリクスごとにコストが発生します。メトリクス数式を含むメトリクスアラームを作成する方法については、「[メトリクスの数式に基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html)」を参照してください。
### 複合アラーム
複合アラームには、他のアラームの状態を評価して自身の状態を判断する方法を指定するルール式が含まれています。複合アラームは、評価される他のアラームの数に関係なく、1 時間あたりの標準コストが発生します。複合アラームがルール式で参照するアラームには、個別のコストが発生します。詳細については、「[複合アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)」を参照してください。
**[Alarm usage types]** (アラームの使用タイプ)
次の表に、CloudWatch アラームに関連するサブ機能の名前を示します。表には、`UsageType` の文字列が含まれています。これは、アラーム関連のコストを分析して特定するのに役立ちます。
| *CloudWatch サブ機能* | `UsageType` |
| --- | --- |
| 標準メトリクスアラーム | `AlarmMonitorUsage` |
| 高解像度メトリクスアラーム | `HighResAlarmMonitorUsage` |
| Metrics Insights クエリアラーム | `MetricInsightAlarmUsage` |
| 複合アラーム | `CompositeAlarmMonitorUsage` |
#### アラームコストの削減
4 つ以上のメトリクスを集計するメトリクス演算アラームによって発生するコストを最大限に活用するために、データが CloudWatch に送信される前にデータを集計するカスタムメトリクスを作成できます。こうすると、複数のメトリクスのデータを集計するアラームではなく、単一のメトリクスのアラームを作成できます。詳細については、[カスタムメトリクスの発行](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html#publishingDataPoints1)を参照してください。
Metrics Insights クエリアラームによって発生するコストを最大限に活用するには、クエリに使用されるフィルターがモニターリング対象のメトリクスにのみ一致するようにします。
コストを削減する最善の方法は、不要なアラームや使用していないアラームをすべて削除することです。たとえば、すでに存在しない AWS リソースによって発行されたメトリクスを評価するアラームを削除できます。
**Example `DescribeAlarms` を使用して `INSUFFICIENT_DATA` 状態のアラームがないかチェックする例**
リソースを削除しても、そのリソースが発行するメトリックアラームを削除しない場合、アラームは引き続き存在し、通常 `INSUFFICIENT_DATA` の状態になります。アラームが `INSUFFICIENT_DATA` の状態になっているかどうかを確認するには、次の AWS Command Line Interface (AWS CLI) コマンドを使用します。
```
aws cloudwatch describe-alarms –state-value INSUFFICIENT_DATA
```
詳細については、「[Amazon CloudWatch アラームの大規模なクリーンアップを自動化する](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarm-cleanup-at-scale/)」を参照してください。
その他に次のようなコスト削減方法があります。
+ 正しいメトリクスのアラームを作成していることを確認してください。
+ 作業していないリージョンでアラームが有効になっていないことを確認してください。
+ 複合アラームはノイズを低減しますが、追加コストも発生することに留意してください。
+ 標準アラームと高解像度アラームのどちらを作成するかを決めるときは、ユースケースと、各タイプのアラームがもたらす価値を考慮してください。
## CloudWatch Container Insights のコストを最適化し削減する
CloudWatch Container Insights は、Amazon ECS と Amazon EKS でコンテナ化されたアプリケーションをモニタリングするための標準オブザーバビリティ機能と拡張オブザーバビリティ機能の両方を提供します。CloudWatch Container Insights は、埋め込みメトリクス形式を活用して、コンテナ環境からテレメトリを取り込みます。
**標準オブザーバビリティを備えた Container Insights:**
Standard Container Insights は、クラスターレベルとノードレベルで集計されたメトリクスを収集して視覚化します。CloudWatch エージェントまたは AWS Distro for Open Telemetry (ADOT) を使用して、Container Insights の標準モードを開始できます。ADOT を使用すると、CloudWatch に送信するメトリクスとディメンションをカスタマイズできます。
Container Insights のメトリクスは「埋め込みメトリクス」として扱われます。これらのメトリクスに関連するコストは、使用タイプ `MetricStorage:AWS/Logs-EMF` および `DataProcessing-Bytes` に反映されます。料金情報の詳細については、「[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing/?nc1=h_ls)」の「埋め込みメトリクス」セクションを参照してください。
**拡張オブザーバビリティを備えた Container Insights:**
詳細な可視性には、拡張オブザーバビリティを備えた Container Insights が付属しています。これにより、アプリケーションのポッドレベルとコンテナレベルまで詳細なテレメトリが提供されます。標準の Container Insights と同様に、拡張オブザーバビリティには、CloudWatch エージェントで実行されている CloudWatch Observability アドオンを使用して開始できる重要なメトリクスの標準セットも付属しています。Container Insights は、利益を正当化する費用対効果の高い請求を保証にするために、新しい観測ベースの料金で拡張オブザーバビリティを提供します。詳細については、「[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing/?nc1=h_ls)」をご覧ください。
拡張オブザーバビリティを備えたこの Container Inisghts に関連付けられている UsageType と Operation は次のとおりです。
| *CloudWatch サブ機能* | `UsageType` | `Operation` |
| --- | --- | --- |
| Amazon EKS 向けに拡張オブザーバビリティを備えた Container Insights | `ObservationUsage` | `ObservationCount:CI-EKScode` |
| Amazon ECS 用に拡張オブザーバビリティを備えた Container Insights | `MetricsUsage` | `MetricStorage:CI-ECS` |
## CloudWatch Database Insights のコストを最適化し削減する
CloudWatch Database Insights では、標準と拡張の両方のオブザーバビリティ機能により、インスタンスレベルとフリートレベルのどちらでも Amazon Aurora データベースをモニタリングできます。CloudWatch Database Insights では、アプリケーション、データベース、その実行元のオペレーティングシステムから収集したログとメトリクスを同じコンソールにまとめて表示できます。
**Database Insights 標準モード:** 標準の Database Insights は、AWS 無料利用枠に含まれており、データベースの負荷メトリクスに関して 7 日というローリング期間でパフォーマンスデータ履歴を提供します。
**Database Insights 高度なモード:** 高度な Database Insights は、Amazon Aurora と RDS データベースのデータベースメトリクス、SQL クエリ分析、ログを CloudWatch の統一されたエクスペリエンスに統合します。料金は、モニタリング対象のデータベースで使用されたコンピューティングリソースの量に基づいています。
Database Insights の料金の設定方法とその例の詳細については、「[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing/?nc1=h_ls)」を参照してください。
次に、Database Insights に関連付けられた UsageTypes とオペレーションを示します。
| *UsageType* | `Operation` | `Instance Configuration Type` | `Database Engine Type` |
| --- | --- | --- | --- |
| DatabaseInsights-vCPU-Hours | `Aurora-MySQL:Provisioned` | `Provisioned` | `Aurora-MySQL` |
| DatabaseInsights-ACU-Hours | `Aurora-MySQL:Serverless` | `Serverless` | `Aurora-MySQL` |
| DatabaseInsights-vCPU-Hours | `Aurora-PostgreSQL:Provisioned` | `Provisioned` | `Aurora-PostgreSQL` |
| DatabaseInsights-ACU-Hours | `Aurora-PostgreSQL:Serverless` | `Serverless` | `Aurora-PostgreSQL` |
| DatabaseInsights-ACU-Hours | Aurora-PostgreSQL:Limitless | `Limitless` | Aurora-PostgreSQL |
## CloudWatch Logs のコストを最適化し削減する
Amazon CloudWatch Logs には次のログタイプがあります。
+ **カスタムログ** (アプリケーション用に作成するログ)
+ **提供されるログ** (Amazon Virtual Private Cloud (Amazon VPC) や Amazon Route 53 など、他の AWS のサービス がユーザーに代わって作成するログ)
提供されるログの詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「[特定の AWS のサービスからのログの記録を有効にする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html)」を参照してください。
カスタムログと提供されるログでは、収集、保存、分析されたログの数に基づいてコストが発生します。これとは別に、提供されるログでは 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 Explorer Service または Athena で AWS Cost and Usage Report を使用します。どちらの方法でも、どのログがコストを生成しているかを特定し、コストがどのように生成されるかを判断できます。
**AWS Cost Explorer Service の使用**
**[サービス]** フィルターで **[CloudWatch]** を選択し、**[ディメンション]** で **[リソース] **を選択します。Cost Explorerでディメンションとして **[リソース]** を選択すると、過去 14 日間の使用状況のみが表示されます。
![\[[サービス] フィールドで [CloudWatch]、[ディメンション] フィールドで [リソース] を選択した AWS Cost Explorer Service インターフェイスのスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/celogs.png)
**Amazon Athena クエリを使用してコストが発生するログを追跡する**
次のクエリを使用して、リソース ID 別にコストが発生するログを追跡できます。
```
SELECT
line_item_resource_id AS ResourceID,
line_item_usage_type AS Operation,
SUM(CAST(line_item_unblended_cost AS decimal(16,8))) AS TotalSpend
FROM
costandusagereport
WHERE
product_product_name = 'AmazonCloudWatch'
AND year='2025'
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
line_item_resource_id,
line_item_usage_type
ORDER BY
TotalSpend DESC
```
CloudWatch Logs によって発生するコストを最大限に活用するには、以下を考慮してください。
+ 前のクエリを使用して、オペレーションごとの支出別に上位ロググループを特定します。
+ ビジネス価値をもたらすイベントのみをログに記録し、効率的なログ構文を選択します。詳細なログ構文は、ボリュームとコストを左右します。これにより、取り込みコストを削減できます。
+ ログの保持設定を変更して、ストレージにかかるコストを抑えます。詳細については、*「Amazon CloudWatch Logs User Guide」*(Amazon CloudWatch Logs ユーザーガイド) の[「Change log data retention in CloudWatch Logs」](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)(CloudWatch ログでのログデータ保管期間の変更) を参照してください。
+ 必要に応じて低頻度アクセスログクラスの使用を検討してください。低頻度アクセスログは、標準クラスよりも少ない機能を提供します。標準ログクラスの追加機能が必要かどうかを判断し、両方のクラスの違いを理解します。詳細については、ブログ記事[「New Amazon CloudWatch log class for infrequent access logs at a reduced price](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-log-class-for-infrequent-access-logs-at-a-reduced-price/)」を参照してください。低頻度アクセスクラスはサポートする機能が少なくなりますが、ほとんどのユースケースに適しています。
+ CloudWatch Logs Insights が自動的に履歴に保存するクエリを実行します。これにより、分析にかかるコストが少なくなります。詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「[実行中のクエリまたはクエリ履歴を表示する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs-Insights-Query-History.html)」を参照してください。
+ CloudWatch エージェントを使用して、システムログとアプリケーションログを収集し、CloudWatch に送信します。これにより、条件を満たすログイベントのみを収集できます。詳細については、「[Amazon CloudWatch エージェントは、ログフィルター式のサポートを追加](https://aws.amazon.com/about-aws/whats-new/2022/02/amazon-cloudwatch-agent-log-filter-expressions/)」を参照してください。
提供されるログのコストを削減するには、ユースケースを検討し、ログを CloudWatch または Amazon S3 に送信するかどうかを決定します。詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「[Amazon S3 に送信されたログ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-S3)」を参照してください。
**ヒント**
メトリクスフィルター、サブスクリプションフィルター、CloudWatch Logs Insights、Contributor Insights を使用する場合は、公開ログを CloudWatch に送信します。
また、VPC フローログを操作し、監査とコンプライアンスの目的で使用している場合は、提供されるログを Amazon S3 に送信します。
VPC フローログを S3 バケットに公開することで発生する料金を追跡する方法については、「[AWS Cost and Usage Report とコスト配分タグを使用して、Amazon S3 への VPC フローログのデータインジェストのコストを知る](https://aws.amazon.com/blogs/mt/using-aws-cost-usage-reports-cost-allocation-tags-to-understand-vpc-flow-logs-data-ingestion-costs-in-amazon-s3/)」を参照してください。
CloudWatch Logs によって発生するコストを最大限に活用する方法の詳細については、「[CloudWatch Logs の請求が急に増加したのですが、どのロググループが原因でしょうか?](https://aws.amazon.com/premiumsupport/knowledge-center/cloudwatch-logs-bill-increase/)」を参照してください。