本文是 AWS CloudWatch 的 vendor deep article，深化 overview「Logs Insights query」跟「Logs lifecycle」段。初次接觸 CloudWatch 的讀者建議先讀 CloudWatch 服務頁。

問題情境

CloudWatch Logs 的成本模型跟 self-hosted log stack 不同 — ingestion、storage 跟 query 分開計費，每一層都有明確的 cost lever。理解 log group 設計、retention 設定與 subscription filter 的組合，才能在 AWS-native 環境下控制日誌成本而不犧牲事故判讀能力。

Log group 設計

拆分粒度

Log group 是 CloudWatch Logs 的計費與 retention 邊界。同一個 log group 內的所有 log stream 共用 retention policy 和 access control（IAM resource policy）。

合理的拆分粒度是 一個服務一個 log group，而非一個帳號一個或一個 container 一個。服務級拆分讓 retention、查詢範圍與 IAM 權限自然對齊服務 ownership。

Lambda 的預設行為是每個 function 自動建一個 log group（/aws/lambda/<function-name>）。function 數量超過數十個後，需要用 naming convention 加 tag 控制，否則 retention policy 難以統一套用。

Naming convention

推薦格式：/<environment>/<service>/<component>，例如 /prod/checkout-api/app、/prod/checkout-api/access-log。統一前綴讓 Logs Insights 的 multi-log-group query 用 prefix matching 篩選。

Logs Insights 查詢語法

核心語法

Logs Insights 的查詢結構是 pipe-based：每行用 | 分隔，依序處理。

1fields @timestamp, @message, @logStream
2| filter @message like /ERROR/
3| parse @message "order_id=* status=*" as order_id, status
4| stats count(*) as error_count by status
5| sort error_count desc
6| limit 20

常用 command 對照：

JSON 自動解析

CloudWatch Logs 會自動辨識 JSON 格式的 log event。JSON 欄位用 dot notation 存取：

1fields @timestamp, requestId, level, message
2| filter level = "ERROR"
3| stats count(*) by bin(5m)

如果 log 是 JSON 格式，parse 通常不需要 — 直接用欄位名稱。混合格式（部分 JSON、部分 plain text）時，需要用 isPresent() 判斷欄位是否存在。

效能考量

Logs Insights 的查詢成本按掃描的 data 量計費（每 GB scanned），不按結果數。減少掃描量的方式：

• 縮短時間範圍：事故判讀先查最近 30 分鐘，確認 pattern 後再擴大
• 指定 log group：避免對所有 log group 做全域查詢
• 用 limit 限制結果集大小（不影響掃描量，但減少資料傳輸）

跨 log group 查詢最多同時查 50 個 log group。超過時需要拆成多次查詢或用 subscription filter 把資料匯到集中儲存。

Retention policy

設定方式

Retention policy 在 log group 級別設定。每個 log group 可以獨立選擇 1 天到 10 年、或永不過期。

1aws logs put-retention-policy \
2  --log-group-name /prod/checkout-api/app \
3  --retention-in-days 30

常見 retention 策略按服務性質分：

未設定 retention 的 log group 預設永不過期 — 這是 CloudWatch 日誌成本超支的常見原因。新 log group 建立後應立即設定 retention。

FinTech 合規場景的 log group 分離

FinTech 審計證據案例揭露一個常見問題：audit log 跟 operational log 混在同一個 log group，retention 只能統一設定。結果要嘛 operational log 為了合規被迫留太久（成本浪費）、要嘛 audit log 跟著 operational log 的短 retention 被刪掉（合規風險）。

CloudWatch 的 log group 設計天然支援這種分離 — audit log 跟 operational log 用不同 log group、各自設定 retention：

Audit log group 的額外治理：

• IAM 權限分離：audit log group 的讀取權限（logs:GetLogEvents）限縮到 compliance team 跟 security team，application developer 只能讀 operational log group。避免 audit log 被隨意查詢或汙染
• Immutability：CloudWatch Logs 本身不支援 WORM（write once read many），合規要求 immutable 存檔時用 subscription filter 把 audit log 同步送到 S3 + Object Lock
• Cross-account 集中：audit log 的 cross-account aggregation（見下方段落）的 IAM 權限要比 operational log 嚴格 — aggregated sink 的 destination 只能由 security team 控制

Infrequent Access log class

CloudWatch Logs 提供兩種 log class：Standard（完整查詢、即時 subscription filter、metric filter）跟 Infrequent Access（僅支援 Logs Insights 查詢、不支援即時 subscription filter 跟 metric filter、ingestion 成本約降 50%）。

Audit log 的存取模式通常是「寫入頻繁、查詢極少（只在稽核或事故時才查）」— 正好符合 Infrequent Access 的定位。把 7 年 retention 的 audit log group 設成 Infrequent Access，ingestion 成本直接砍半。

注意 Infrequent Access 的限制：不能用 subscription filter 即時轉發到 Lambda 或 Kinesis，不能用 metric filter 從 log 產生 CloudWatch metric。如果 audit log 需要即時異常偵測（例如偵測大量失敗交易），要用 Standard class + subscription filter 做即時處理、再用 Lambda 寫到長期 audit log group（Infrequent Access）。

自動化套用

用 AWS Config rule 或 CloudFormation / CDK 的 log group 定義統一設定 retention。Lambda function 自動建立的 log group 不會自動套用 retention，需要額外自動化（Lambda post-hook 或 EventBridge rule + Lambda 設定 retention）。

Cross-account log aggregation

架構模式

多帳號環境下，常見做法是設立一個「觀測帳號」（observability account），把其他帳號的 logs 匯入。

兩種匯入方式：

Subscription filter + Kinesis Data Firehose：每個 source 帳號的 log group 設 subscription filter，把 log event 送到 observability 帳號的 Kinesis Data Firehose，再寫到 S3 或 OpenSearch。適合需要長期存檔或進階查詢的場景。

CloudWatch cross-account observability：AWS 原生功能，在 monitoring account 直接查詢 source accounts 的 CloudWatch 資料（metrics、logs、traces）。設定較簡單，但查詢延遲較高，且 Logs Insights 的 cross-account 查詢有 region 限制。

Subscription filter 實務

Subscription filter 可以把 log event 送到 Lambda（即時處理）、Kinesis Data Stream（緩衝）、Kinesis Data Firehose（直接寫 S3/OpenSearch）或另一個 log group。

每個 log group 最多 2 個 subscription filter — 這是硬限制。如果同一個 log group 需要同時送 S3 archive 跟即時 alerting，要用 Kinesis Data Stream 做 fan-out，讓 stream 下游各自消費。

filter pattern 語法支援 JSON 欄位匹配：

1{ $.level = "ERROR" }

只把 ERROR 級別的 log 送到 alerting pipeline，可以大幅降低下游處理量跟成本。

Cost governance

計費結構

CloudWatch Logs 的成本由三個維度組成：

Ingestion 是最大成本。降低 ingestion 的手段：

• 調整 log level：production 只保留 INFO 以上，DEBUG 只在問題排查時短暫開啟
• 去除重複資訊：access log 跟 application log 不要記錄相同欄位
• 用 metric filter 替代 log query：高頻計數（error count、request count）用 CloudWatch Metric Filter 從 log 產生 metric，查詢成本從 log scan 轉成 metric query

成本觀測

用 CloudWatch 自己的 metric 觀測 log 成本：

• IncomingBytes（per log group）：監控哪個 log group ingestion 最大
• IncomingLogEvents（per log group）：監控 event 數量
• AWS Cost Explorer 按 CloudWatch 拆分：看 log ingestion vs storage vs API call 的比例

降本決策樹

判斷成本是否合理的順序：

1. 最大 ingestion 的 log group 是哪個？是否合理（核心服務的 access log 量大是正常的）
2. Retention 是否都有設定？未設定的 log group 會持續累積 storage 成本
3. 是否有 DEBUG 級別 log 在 production 長期開啟？
4. 是否有 subscription filter 把全量 log 送到外部？能否加 filter pattern 只送需要的部分

整合與下一步

• 觀測管線整合：CloudWatch Logs → Subscription Filter → Kinesis Firehose → S3 / OpenSearch，見 4.11 Telemetry Pipeline
• Audit log 治理：合規場景的 log retention 跟 access control，見 4.12 Audit Log Governance
• Evidence package：把 Logs Insights query link 跟時間窗放進 evidence，見 4.20 Observability Evidence Package
• OTel 整合：ADOT 可以把 log 送到 CloudWatch Logs 或其他 backend，見 OpenTelemetry Collector 部署模式

本文是 AWS CloudWatch 的 vendor deep article，深化 overview「Alarm + Composite alarm + EventBridge rule」段。初次接觸 CloudWatch 的讀者建議先讀 CloudWatch 服務頁。

問題情境

CloudWatch Alarm 是 AWS 原生的告警機制，跟 Prometheus Alertmanager 或 Datadog Monitor 的定位相同 — 把 metric 異常轉成可操作通知。CloudWatch Alarm 的特性是跟 AWS 服務深度整合（Auto Scaling、SNS、Lambda、Systems Manager），但告警邏輯表達力比 PromQL alerting rule 弱。Composite Alarm 是 CloudWatch 用來降低 alert noise 的方式，把多個 alarm 的布林組合當成觸發條件。

Metric Alarm 基礎

Alarm 參數

每個 metric alarm 由五個參數決定行為：

Evaluation periods 的意義是「連續 N 個 period 都違反閾值才進入 ALARM 狀態」。設太低（1 個 period）容易 flapping，設太高（10 個 period）會延遲告警。多數場景 3 個 period × 60 秒 = 3 分鐘是合理起點。

Datapoints to Alarm

除了 evaluation periods，CloudWatch 還有 Datapoints to Alarm 參數 — 在 evaluation periods 的窗口中，至少幾個 datapoint 超過閾值就觸發。例如 3 of 5 代表最近 5 個 period 中有 3 個超過閾值就觸發。

這個設計讓告警在有缺失 datapoint 的環境下更穩健。容器重啟、Lambda cold start 或 scrape timeout 都可能造成某些 period 沒有 datapoint，M of N 模式避免因為缺失資料而延遲告警。

Anomaly Detection Alarm

用途

Anomaly Detection alarm 用機器學習模型建立 metric 的 baseline band，metric 偏離 band 就觸發。適合沒有固定閾值的 metric — 例如 request count 在白天高、晚上低，用固定閾值會在晚上誤報或白天漏報。

設定

1aws cloudwatch put-anomaly-detector \
2  --namespace AWS/ApplicationELB \
3  --metric-name RequestCount \
4  --dimensions Name=LoadBalancer,Value=app/my-alb/xxx \
5  --stat Sum

Anomaly Detection 需要至少兩週的歷史資料才能建立可靠 baseline。新服務上線初期先用固定閾值 alarm，等累積足夠資料後再切換。

Band width 控制

Anomaly Detection band 的寬度用標準差倍數控制（預設 2）。band 太窄（1x）容易誤報，太寬（3x）漏報。生產經驗是 API latency 用 2x、batch job duration 用 3x（batch 的自然波動較大）。

Composite Alarm

問題：Alert noise

單一 metric alarm 太多時，on-call 會收到大量相關但重複的通知。一個下游服務故障可能同時觸發 latency alarm、error rate alarm、timeout alarm、queue lag alarm — 都指向同一個根因，但各自通知。

解法：布林組合

Composite Alarm 用布林表達式組合多個 alarm，只在組合條件成立時觸發。

1ALARM("checkout-latency-high")
2AND ALARM("payment-error-rate-high")
3AND NOT ALARM("scheduled-maintenance-window")

這個組合代表：checkout latency 高且 payment error rate 也高，但排除了計畫維護視窗 — 才通知 on-call。

設計原則

Composite Alarm 的設計應該反映事故判讀邏輯，而非機械式組合。三個常見模式：

Symptom + cause 組合：外部症狀（latency 高）加上內部原因（DB connection pool 飽和）同時成立才通知。避免 latency 短暫抖動就告警。

Cross-service correlation：多個服務同時出現異常時觸發「可能是 shared dependency 問題」的 composite alarm。一個服務異常可能是部署問題，多個同時異常更可能是共用依賴（load balancer、DNS、shared database）。

Suppression window：用 maintenance window alarm 做 NOT 條件，在計畫維護期間抑制告警。

限制

• Composite Alarm 最多引用 5 個 child alarm
• 巢狀深度最多 1 層（composite 不能引用另一個 composite）
• Composite Alarm 本身不產生 metric，只做觸發邏輯

超過 5 個 child alarm 時，需要把相關 alarm 先組成一個 composite，再讓上層 composite 引用。但因為不支援巢狀，實際能組合的 alarm 數量有限。複雜告警邏輯需要用 EventBridge rule 搭配 Lambda 處理。

Alarm actions

常見 action 類型

Alarm 進入 ALARM 狀態時可以觸發多種 action：

生產環境通常同時設定 ALARM 跟 OK action — ALARM 時通知 on-call，回到 OK 時自動 resolve incident。忘記設 OK action 會造成 on-call 收到告警但不知道何時恢復。

跟 EventBridge 整合

CloudWatch Alarm 狀態變更會自動送到 EventBridge（事件類型 CloudWatch Alarm State Change）。EventBridge rule 可以做更靈活的路由：

• 根據 alarm name pattern 路由到不同 SNS topic
• 根據 alarm description 中的 severity tag 決定通知管道
• 多個 alarm 同時進入 ALARM 時觸發 incident 建立

EventBridge 的路由能力彌補了 CloudWatch Alarm 本身路由邏輯簡單的限制。

Missing data 處理

四種策略

Alarm evaluation 遇到缺失 datapoint 時，有四種處理方式：

breaching 適合 heartbeat 類型的 metric — 服務應該持續回報 metric，停止回報代表服務掛了。notBreaching 適合流量驅動的 metric — 凌晨沒有 request 時自然沒有 latency datapoint，不應該觸發告警。

選錯 missing data 策略是 alarm flapping 的常見原因。Lambda function 的 metric 在沒有 invocation 時沒有 datapoint，用預設的 missing 或 breaching 都會造成問題。Lambda metric alarm 應該用 notBreaching。

Cross-region 限制

CloudWatch Alarm 跟 metric 綁定在同一個 region。跨 region 告警的兩種方式：

Cross-account observability：monitoring account 可以看到 source account 的 CloudWatch 資料，但 alarm 仍然必須建在 metric 所在的 region。

Custom metric replication：用 Lambda 或 Kinesis 把 metric 從 source region publish 到 central region，在 central region 建立統一 alarm。增加複雜度跟延遲，但能集中管理告警。

多數團隊選擇在每個 region 建各自的 alarm，用統一的 SNS topic（跨 region publish 到 central topic）收斂通知。告警邏輯去中心化，通知管道集中化。

Cost 考量

CloudWatch Alarm 的主要成本來自：

數量控制的判準：每個服務 10-30 個 metric alarm 加 2-5 個 composite alarm 是合理範圍。超過 100 個 alarm 時先檢查是否有冗餘（同一 metric 不同 period 的重複 alarm）。

整合與下一步

• 告警設計原則：alarm 跟 dashboard 的搭配，見 4.4 Dashboard 與 Alert 設計
• SLI/SLO 對齊：把 alarm 閾值跟 SLO 對齊，見 4.6 SLI 量測與 SLO 訊號設計
• Log-based alerting：從 log 產生 metric 再建 alarm，見 CloudWatch Logs Insights 查詢與日誌治理
• 事故響應整合：alarm → EventBridge → PagerDuty / incident tool，見 08 Incident Response 模組