

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 分析、最佳化和降低 CloudWatch 成本
<a name="cloudwatch_billing"></a>

本節說明 Amazon CloudWatch 功能如何產生成本。此外，還提供可協助您分析、最佳化和降低 CloudWatch 成本的方法。在本節中，我們有時會在描述 CloudWatch 功能時提及定價。如需有關定價的資訊，請參閱 [Amazon CloudWatch 定價](https://aws.amazon.com/cloudwatch/pricing/?nc1=h_ls)。

**Topics**
+ [使用 Cost Explorer 分析 CloudWatch 成本和用量資料](#cloudwatch_billing_costs)
+ [使用 和 Athena 分析 CloudWatch AWS Cost and Usage Report成本和用量資料](#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 成本和用量資料
<a name="cloudwatch_billing_costs"></a>

透過 AWS Cost Explorer，您可以視覺化和分析一段時間內 AWS 服務 的成本和用量資料，包括 CloudWatch。如需詳細資訊，請參閱 [入門 AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/getting-started/)。

下列程序說明如何使用 Cost Explorer 來視覺化並分析 CloudWatch 的成本和用量資料。

### 視覺化和分析 CloudWatch 成本和用量資料
<a name="visualize_cost_usage_data"></a>

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 功能在六個月內產生的成本範例。

![\[介面的螢幕擷取畫面 AWS Cost Explorer ，以長條圖格式顯示用量類型成本。\]](http://docs.aws.amazon.com/zh_tw/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` 的整個字串可格式化如下所示：`<Region>-CW:<Feature>` 或 `<Region>-<Feature>`。  
有些 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/zh_tw/AmazonCloudWatch/latest/monitoring/cloudwatch_billing.html)

## 使用 和 Athena 分析 CloudWatch AWS Cost and Usage Report成本和用量資料
<a name="cloudwatch_billing_billing_info"></a>

分析 CloudWatch 成本和用量資料的另一種方法是搭配 AWS Cost and Usage Report Amazon Athena 使用 。 AWS Cost and Usage Report包含一組完整的成本和用量資料。您可以建立可追蹤成本和用量的報告，並可將這些報告發布至您所選的 S3 儲存貯體。您也可以從您的 S3 儲存貯體下載並刪除您的報告。如需詳細資訊，請參閱 [AWS Cost and Usage Report使用者指南中的什麼是 ？](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)。 *AWS Cost and Usage Report*

**注意**  
使用 無需付費 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 成本和用量資料。

**注意**  
您可以使用本文件中的任何範例查詢。本文件中的所有查詢範例均對應於名為 ***costandusagereport*** 的資料庫，並顯示 2025 年 4 月的結果。您可以變更此資訊。不過，在執行查詢之前，請確定您的資料庫名稱與查詢中的資料庫名稱相符。

### 使用 和 Athena AWS Cost and Usage Report分析成本和用量資料
<a name="analyze-with-athena"></a>

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 顯示 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 指標成本
<a name="cloudwatch_billing_billing_metric"></a>

許多 Amazon Elastic Compute Cloud (Amazon EC2)、Amazon S3 和 Amazon Data Firehose AWS 服務等 都會免費自動將指標傳送至 CloudWatch。不過，歸入以下類別的指標可能會產生額外的成本：
+ ***Custom metrics, detailed monitoring, and embedded metrics*** (自訂指標、詳細監控和內嵌指標)
+ ***API requests*** (API 請求)
+ ***Metric streams*** (指標串流)

如需詳細資訊，請參閱[使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)。

### 自訂指標
<a name="w2aac11c11b9"></a>

您可以建立自訂指標，以任何順序和任何速率來組織資料點。

所有自訂指標均依小時按比例分配。只有在傳送至 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` | 日誌群組指標篩選條件 | 

### 詳細監控
<a name="w2aac11c11c11"></a>

CloudWatch 有兩種類型的監控：
+  ***基本監控*** 

  基本監控免費，並為所有支援此功能的 AWS 服務 自動啟用。
+  ***詳細監控*** 

  詳細監控會產生成本，並根據 新增不同的增強功能 AWS 服務。對於支援詳細監控的每個 AWS 服務 ，您可以選擇是否要為該服務啟用它。如需詳細資訊，請參閱[基本和詳細監控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-basic-detailed.html)。

**注意**  
其他 AWS 服務 支援詳細監控，且可能使用不同的名稱來參考此功能。例如，Amazon S3 的詳細監控稱為 ***request metrics*** (請求指標)。

與自訂指標類似，詳細監控會依小時按比例分配，並且只有在資料傳送至 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
```

### 內嵌指標
<a name="w2aac11c11c13"></a>

透過 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 中儲存每小時日誌和每位元組日誌 | 

若要分析成本，請使用 AWS Cost and Usage Report搭配 Athena，以便識別哪些指標產生成本，並確定如何產生成本。

為了充分利用 CloudWatch 內嵌指標格式產生的成本，請避免根據高基數維度建立指標。如此一來，CloudWatch 就不會為每個唯一的維度組合建立自訂指標。如需詳細資訊，請參閱[維度](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension)。

### API 請求
<a name="w2aac11c11c15"></a>

CloudWatch 具有以下類型的 API 請求：
+  ***API requests*** (API 請求) 
+  ***Bulk (Get)*** (大量 (取得)) 
+  ***Contributor Insights*** 
+  ***Bitmap image snapshot*** (點陣圖影像快照) 

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` | 擷取一或多個 CloudWatch 指標的快照作為點陣圖影像  | 

若要分析成本，請使用 Cost Explorer，並將結果依據 ***API Operation*** (API 操作) 分組。

帳單主控台會在 UsageType *請求*下顯示一般 API 請求。這些顯示為*每 1,000 個請求 X.XX 美元 - [區域]*。此費率適用於 UsageType 為「請求」的所有請求，當這些請求的總量超過您的免費額度時，將彙總計費。

API 請求的成本會有所不同，當您超過 AWS 免費方案限制下提供給您的 API 呼叫數量時，會產生費用。

**注意**  
只有具有 UsageType 請求的 API *請求*才會包含在 AWS 免費方案限制中。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)和[使用 AWS CloudTrail識別驅動 CloudWatch GetMetricData 費用的資源](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)
+ [Lowering costs and focusing on our customers with Amazon CloudWatch embedded custom metrics](https://aws.amazon.com/blogs/mt/lowering-costs-and-focusing-on-our-customers-with-amazon-cloudwatch-embedded-custom-metrics/) (利用 Amazon CloudWatch 內嵌的自訂指標，降低成本並聚焦於我們的客戶) 

***`GetMetricData`***

CloudWatch `GetMetricData` API 操作亦可能導致成本大幅增加。第三方監控工具若頻繁提取資料以產生洞見，往往會增加成本。如需詳細了解如何使用 `GetMetricData` 定價及最佳實務，請參閱《Amazon CloudWatch API 參考》**中的 [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`***

視您的使用案例而定，您可能會考慮使用 `GetMetricStatistics` 而不是 `GetMetricData`。透過 `GetMetricData`，您可以快速且大規模地擷取資料。不過， `GetMetricStatistics` 包含在最多一百萬個 API 請求 AWS 的免費方案限制下，如果您不需要在每次呼叫中擷取任意數量的指標和資料點，這可協助您降低成本。如需詳細資訊，請參閱下列資源：
+  《Amazon CloudWatch API 參考》中的 [GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html) 
+  [Should I use GetMetricData or GetMetricStatistics?](https://aws.amazon.com/premiumsupport/knowledge-center/cloudwatch-getmetricdata-api/) (我應使用 GetMetricData 或 GetMetricStatistics？) 

**注意**  
外部呼叫者進行 API 呼叫。對於 CloudTrail 資料事件支援的 API (例如 **GetMetricData** 和 **GetMetricWidgetImage**)，可以使用 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 指標串流
<a name="w2aac11c11c17"></a>

使用 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 Resource Name (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 警示成本
<a name="cloudwatch_billing_billing_alarms"></a>

使用 CloudWatch 警示，您可以根據單一指標建立警示、根據 Metrics Insights 查詢建立警示，以及建立監看其他警示的複合警示。

**注意**  
指標和複合警示的費用按小時按比例分配。只有當警示存在時，您才會產生警示費用。若要最佳化成本，請務必清除設定錯誤或值較低的警示。為此，可以自動清除不再需要的 CloudWatch 警示。如需詳細資訊，請參閱[大規模自動化清理 Amazon CloudWatch 警示](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarm-cleanup-at-scale/) 

### 指標警示
<a name="metric-alarms"></a>

指標警示具有下列解析度設定：
+  **Standard** (標準) (每 60 秒評估一次) 
+  **High resolution** (高解析度) (每 10 秒評估一次) 

如果建立指標警示，費用會根據警示的解析設定和警示參考的指標數量而定。例如，指標警示每參考一個指標，每小時就會產生一個警示指標成本。如需詳細資訊，請參閱[使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Alarms.html)。

如果建立的指標警示包含參考多個指標的指標數學表達式，則指標數學表達式中參考的每個警示指標都會產生費用。如需有關如何建立包含指標數學表達式的指標警示的詳細資訊，請參閱[根據指標數學表達式建立 CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html)。

如果建立的是異常偵測警示 (警示會分析過去的指標資料來建立預期值模型)，則警示中參考的每個警示指標 (以及兩個額外指標，其中一個用於異常偵測模型建立的上下限範圍指標) 都會產生費用。如需有關如何建立異常偵測警示的詳細資訊，請參閱[建立以異常偵測為基礎的 CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)。

### Metrics Insights 查詢警示
<a name="metrics-insights-query-alarms"></a>

Metric Insights 查詢警示是一種特定類型的指標警示，僅提供標準解析度 (每 60 秒評估一次)。

建立 Metric Insights 查詢警示時，費用會根據警示參考的查詢所分析的指標數量而定。例如，某個 Metric Insights 查詢警示所參考之查詢的篩選條件符合十個指標，那麼此查詢警示每小時會產生分析十個指標的成本。如需詳細資訊，請參閱 [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)。

### 複合警示
<a name="composite-alarms"></a>

複合警示包含指定如何評估其他警示狀態以判斷其自身狀態的規則表達式。複合警示會每小時產生標準費用，無論它們評估了多少個其他警示。複合警示的規則表達式參考的每個警示都會產生費用。如需詳細資訊，請參閱[建立複合警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)。

**警示使用類型**

下表所列為 CloudWatch 警示的相關子功能名稱。資料表包含 `UsageType` 的字串，可協助您分析和識別與警示相關的成本。


| *CloudWatch 子功能* | `UsageType` | 
| --- | --- | 
| 標準指標警示 | `AlarmMonitorUsage` | 
| 高解析度指標警示 | `HighResAlarmMonitorUsage` | 
| Metrics Insights 查詢警示 | `MetricInsightAlarmUsage` | 
| 複合警示 | `CompositeAlarmMonitorUsage` | 

#### 降低警示成本
<a name="reducing-alarm-costs"></a>

若要充分利用彙總四個 (或更多) 指標的指標數學警示優化所產生的成本，您可以在資料傳送至 CloudWatch 之前彙總資料。如此一來，您就可以為單一指標建立警示，而不是為多個指標彙總資料的警示。如需詳細資訊，請參閱[發布自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html#publishingDataPoints1)。

若要最佳化 Metric 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 成本
<a name="cloudwatch_billing_container-insights"></a>

CloudWatch Container Insights 提供標準和增強型可觀測性功能，用於監控 Amazon ECS 和 Amazon EKS 中的容器化應用程式。CloudWatch Container Insights 可利用內嵌指標格式從您的容器環境擷取遙測。

**具標準可觀測性的 Container Insights：**

標準 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 提供細緻的可見性，為您的應用程式提供細粒度的遙測資料，精確至 Pod 和容器層級。與標準 Container Insights 類似，增強型可觀測性功能也隨附一組標準的關鍵指標，您可以開始使用在 CloudWatch 代理程式上執行的 CloudWatch Observability 附加元件。Container Insights 以新的觀測型定價模式提供增強的可觀測性功能，以確保帳單具備成本優勢且能證明效益。如需詳細資訊，請參閱 [Amazon CloudWatch 定價](https://aws.amazon.com/cloudwatch/pricing/?nc1=h_ls)。

以下是與這個具備增強之可觀測性的 Container Inisghts 相關的 UsageType 和操作：


| *CloudWatch 子功能* | `UsageType` | `Operation` | 
| --- | --- | --- | 
| 適用於 Amazon EKS 的具備增強之可觀測性的 Container Insights | `ObservationUsage` | `ObservationCount:CI-EKScode` | 
| 適用於 Amazon ECS 的具有增強可觀測性的 Container Insights | `MetricsUsage` | `MetricStorage:CI-ECS` | 

## 最佳化和降低 CloudWatch Database Insights 成本
<a name="cloudwatch_billing_database-insights"></a>

CloudWatch Database Insights 提供標準和增強型可觀測性功能，可於執行個體和機群層級監控 Amazon Aurora 資料庫。CloudWatch Database Insights 會將來自應用程式、資料庫及其執行之作業系統的日誌和指標合併到主控台的統一檢視中。

**Database Insights 標準模式：**Standard 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 成本
<a name="cloudwatch_billing_billing_logs"></a>

Amazon CloudWatch Logs 具有下列日誌類型：
+  ***自訂日誌** (您為應用程式建立的日誌)* 
+  ***已取代的日誌** （代您建立的其他日誌 AWS 服務，例如 Amazon Virtual Private Cloud (Amazon VPC) 和 Amazon Route 53)* 

如需付費日誌的詳細資訊，請參閱《*Amazon CloudWatch Logs 使用者指南*》中的[啟用特定 AWS 服務的日誌記錄](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html)。

自訂和付費日誌會根據*收集*、*儲存*及*分析*的日誌數量產生成本。另外，付費日誌在傳送至 Amazon S3 和 Kinesis Data 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 中儲存每小時日誌數和每位元組日誌數。 | 
|  | 分析 (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 或 AWS Cost and Usage Report搭配 Athena。不論選取哪種方法，都可以識別哪些日誌會產生成本，並決定成本的產生方式。

**使用 AWS Cost Explorer Service**

選取 **CloudWatch** 作為**服務**篩選條件，然後選取**資源**作為**維度**。當您在 Cost Explorer Service 中選取**資源**作為維度時，只能看到過去 14 天的使用情況。

![\[介面的螢幕擷取畫面 AWS Cost Explorer Service ，其中針對服務欄位選取 CloudWatch，針對維度欄位選取資源。\]](http://docs.aws.amazon.com/zh_tw/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 使用者指南》中的[變更 CloudWatch 日誌中的日誌資料保留期間](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)。
+ 考慮適當時使用不常存取日誌類別。不常存取日誌的功能少於標準類別。判斷您是否需要標準日誌類別的其他功能，並了解兩個類別之間的差異。如需詳細資訊，請參閱部落格文章：[New CloudWatch Logs 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 Agent adds Support for Log Filter Expressions](https://aws.amazon.com/about-aws/whats-new/2022/02/amazon-cloudwatch-agent-log-filter-expressions/) (Amazon CloudWatch 代理程式新增對日誌篩選條件表達式的支援)。

若要降低付費日誌的成本，請考慮您的使用案例，然後判斷是否應將您的日誌傳送至 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 FLow Logs 資料擷取](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 產生的成本的其他資訊，請參閱 [Which log group is causing a sudden increase in my CloudWatch Logs bill?](https://aws.amazon.com/premiumsupport/knowledge-center/cloudwatch-logs-bill-increase/) (哪個日誌群組導致我的 CloudWatch 日誌帳單突然增加？)。