CloudWatch 賬單越來越貴？Logs 與 Metrics 的降低成本實戰指南
CloudWatch 很容易從「預設可觀測性工具」變成帳單黑洞。尤其是容器、微服務、Lambda、API Gateway、VPC Flow Logs 全部接入後，Logs ingest、日誌保留、Custom Metrics、Alarms、Dashboards 會一起增長。要降低成本，第一步不是刪監控，而是拆清楚錢花在哪裡。
以下價格以 us-east-1 常見公開價格為例，實際以 AWS 當前區域價格為準：CloudWatch Logs 標準日誌寫入常見約 $0.50/GB，日誌歸檔約 $0.03/GB-month；Logs Insights 查詢常見約 $0.005/GB scanned；Custom Metrics 前 10,000 個常見約 $0.30/metric-month；標準解析度 alarm 常見約 $0.10/alarm metric-month；自訂 dashboard 常見約 $3/dashboard-month。
先定位：Logs 貴，還是 Metrics 貴？
在 Cost Explorer 中依 Service 選擇 CloudWatch，再依 Usage type 拆分。常見高成本項目包括：
DataProcessing-Bytes：日誌寫入。TimedStorage-ByteHrs：日誌保存。MetricMonitorUsage：自訂指標。AlarmMonitorUsage：警報。GMD-Metrics或 API 請求：GetMetricData 查詢。
很多團隊以為是 dashboard 貴，實際通常是日誌寫入或高基數 custom metrics 貴。
Logs 降低成本 1：設定保留週期
CloudWatch Log Group 預設可能永久保留。對於應用程式日誌，很多團隊只需要 7、14、30 或 90 天線上檢索。
批次查看：
aws logs describe-log-groups \
--query 'logGroups[*].[logGroupName,retentionInDays,storedBytes]' \
--output table設定保留：
aws logs put-retention-policy \
--log-group-name /aws/ecs/prod-api \
--retention-in-days 30建議依日誌類型分層：生產錯誤日誌 90 天，一般應用程式日誌 14 到 30 天，偵錯日誌 3 到 7 天，稽核與合規日誌轉 S3 長期保存。
Logs 降低成本 2：在寫入前過濾，而不是寫入後查詢
CloudWatch Logs 最貴的部分通常是 ingest。日誌已經進入 CloudWatch 後，再用 subscription filter 或 Logs Insights 過濾，並不能省下寫入費。
應該在應用程式、sidecar、Fluent Bit、OpenTelemetry Collector 階段過濾：
[FILTER]
Name grep
Match app.*
Exclude log ^.*healthcheck.*$優先捨棄高頻低價值日誌，例如 health check、靜態資源 200、重複 debug、過長 payload。生產環境預設 INFO，疑難排解時臨時提高到 DEBUG，比長期全量 debug 便宜得多。
Logs 降低成本 3：清理無人使用的 Log Group
Lambda、ECS、API Gateway、Step Functions 下線後，log group 不一定自動刪除。可以找出很久沒有寫入的群組：
aws logs describe-log-groups \
--query 'logGroups[?storedBytes>`0`].[logGroupName,storedBytes,retentionInDays]' \
--output table再結合 lastEventTimestamp 檢查是否仍在使用。刪除前建議匯出到 S3，避免誤刪合規資料。
Logs 降低成本 4：謹慎接入高流量廠商日誌
VPC Flow Logs、ALB Access Logs、WAF Logs、CloudFront Logs 都可能非常大。不要預設全部進入 CloudWatch。
更常見的作法是：
- 短期疑難排解日誌進入 CloudWatch。
- 長期存取日誌進入 S3。
- 用 Athena 查詢歷史資料。
- 對 VPC Flow Logs 只採樣必要欄位，或只對關鍵 subnet/ENI 開啟。
S3 + Athena 的互動式體驗不如 CloudWatch Logs，但長期保留成本通常更低，特別適合低頻稽核查詢。
Logs 降低成本 5：替代方案作為補充選擇
如果主要矛盾是 CloudWatch Logs 的寫入和保管成本，可以評估替代方案。例如 S4 Logs 是針對 CloudWatch Logs 成本優化的替代產品，適合日誌量大、保留週期長、CloudWatch 原生查詢能力不是唯一剛需的場景。
它不應該被當成「無腦替換 CloudWatch」。如果你的團隊高度依賴 Logs Insights、CloudWatch Alarm 與現有維運流程，遷移成本要算進去。比較務實的方式是選擇一個高流量、低風險的 log group 做試點，再用 成本試算工具 估算節省區間。
Metrics 降低成本 1：控制 cardinality
Custom Metrics 的核心風險是高基數。CloudWatch 依 namespace、metric name、dimension 組合計費。下面這種維度設計很危險：
MetricName=Latency
Dimensions=service, endpoint, customer_id, pod_id, request_id如果 customer_id 有 10,000 個，endpoint 有 50 個，理論組合會迅速膨脹。更穩妥的作法是只保留疑難排解和警報真正需要的維度：
MetricName=LatencyP95
Dimensions=service, endpoint, environmentpod_id、request_id 這種高基數欄位更適合進入日誌或 trace，不適合做 CloudWatch custom metric 維度。
Metrics 降低成本 2：聚合後再回報
不要每個執行個體、每個租戶、每個介面都直接 PutMetricData。可以在應用程式或 collector 層做聚合，例如每 60 秒回報一次 p50/p95/p99、count、error_count。
PutMetricData API 本身也可能產生請求費用，常見價格約 $0.01/1,000 requests。把 10 秒回報改為 60 秒回報，通常不会影響大多數業務警報，卻能減少 API 請求和指標數量。
Metrics 降低成本 3：正確使用 EMF
Embedded Metric Format 可以從結構化日誌中提取指標，適合把日誌和指標打通。但 EMF 不是「免費指標」。它仍然會產生日誌寫入費用，並可能生成 custom metrics 費用。
使用 EMF 時要注意：
- 不要把 user_id、order_id、container_id 放進 dimensions。
- 控制 namespace 數量。
- 對高頻事件先聚合再輸出 EMF。
- 定期檢查實際生成了多少 unique metrics。
Metrics 降低成本 4：警報與 Dashboard 也要治理
警報常見問題是每個維度組合都建一個 alarm，最後變成幾千個 alarm。更推薦：
- 關鍵 SLO 建少量聚合警報。
- 明細問題透過 dashboard 或日誌排查。
- 對相關 alarm 使用 composite alarm 降低噪音。
- 刪除無人查看的 dashboard。
Dashboard 本身單價不一定高，但頻繁自動重新整理會帶來 GetMetricData API 成本，特別是大螢幕和輪詢系統。
什麼時候考慮 S4 Metrics？
如果 CloudWatch Custom Metrics 的主要問題是高基數帶來的成本，而業務又確實需要保留較細粒度的指標，可以評估 S4 Metrics 這類替代方案。它的定位是降低 CloudWatch 自訂指標的 cardinality 成本，不是替代所有可觀測性系統。適合先從非核心 namespace 或成本最高的指標族群做 A/B 試點。
一個可執行的 7 天計畫
第 1 天：用 Cost Explorer 找出 CloudWatch Top usage type。 第 2 天：列出所有 log group 的大小和 retention。 第 3 天：把預設永久保留改成 7/14/30/90 天分層。 第 4 天：在 Fluent Bit 或 OTel Collector 前置過濾低價值日誌。 第 5 天：把長期日誌導向 S3 + Athena。 第 6 天：匯出 custom metrics 清單，刪除高基數維度。 第 7 天：評估 S4 Logs / S4 Metrics 等替代方案是否值得試點。
CloudWatch 降低成本的原則很簡單：高價值訊號留下，低價值雜訊別寫入；需要長期留存的資料放到更適合長期保存的系統裡。
聲明：本文作者來自 abyo software（AWS Marketplace 上的成本優化產品 S4 的開發方）。