CloudWatch 指標與 CloudWatch Logs Insights 構成了可觀察性的骨幹，每個 DOP-C02 監控情境都假設你已在實作層級理解了這些內容。Associate 級別的考試測試的是「你能否建立警示」，而 DevOps 工程師專業級 (Professional) 考試則測試你是否能選擇正確的擷取路徑 (代理程式 vs PutMetricData API vs 指標篩選器 vs 內嵌指標格式)、選擇正確的查詢工具 (Logs Insights vs Athena vs OpenSearch)、選擇正確的保留與生命週期計畫 (日誌群組保留期 vs S3 封存 vs Firehose 到 S3)，以及選擇正確的基數 (cardinality) 策略 (維度 vs Contributor Insights vs 結構化欄位)。這四項選擇中的任何一項錯誤，都可能導致成本過高、在事故發生時遺漏所需資料，或是讓自己陷入無法在不重新插樁 (re-instrumenting) 的情況下進行重構的困境。
本指南假設你已了解基礎的 CloudWatch 概念（指標、警示、儀表板）和基礎的 CloudWatch Logs 概念（日誌群組、日誌串流）。它專注於 DOP-C02 的實作深度 —— 用於控制基數的命名空間與維度設計、EC2 與內部部署伺服器上的統一 CloudWatch 代理程式、標準與高解析度指標的區別、在不呼叫 PutMetricData 的情況下從 Lambda 與容器發出指標的內嵌指標格式 (EMF)、將日誌事件轉化為指標的指標篩選器、將每個指標傳送到 Firehose 以進行廉價長期分析的指標串流、考試情境要求的 Logs Insights 查詢語言、將日誌發散到 Lambda 或 Kinesis 的訂閱篩選器、降低儲存成本的保留政策、日誌群組的 KMS 加密、跨帳戶可觀察性監控帳戶，以及受管日誌 (vended logs) vs 自訂日誌 vs 容器日誌中充滿陷阱的角落。網域 4 (監控與記錄，佔 15%) 和網域 5.3 (排查系統與應用程式故障) 都依賴這些內容。
為什麼 CloudWatch 指標與 Logs Insights 在 DOP-C02 中很重要
DOP-C02 中監控佔 15%，事故回應佔 14% —— 兩者合計佔考試內容的 29%，幾乎佔了分數的三分之一。這兩個網域都透過 CloudWatch 指標和 CloudWatch Logs Insights 運作，因為幾乎所有關於「觸發什麼警示」、「什麼查詢能找到錯誤請求」、「如何為值班工程師建立儀表板」的情境最後都會落在這裡。考試需要的是能夠以正確層級擷取、以正確延遲查詢、並以正確成本保留資料的 DevOps 工程師。CloudWatch 指標與 Logs Insights 不僅僅是監控功能；它們是 EventBridge 規則、警示、執行手冊和回滾訊號所共同消耗的共享詞彙。
考試風格富有實作細節。一個典型的題目背景可能是：「一個 ECS Fargate 工作負載每分鐘發出 12,000 個唯一客戶 ID，每個 ID 都標記在一個指標上。團隊需要按客戶顯示 P95 延遲視圖，但 CloudWatch 帳單超過預算 8 倍。哪兩項變更可以在保留按客戶追溯能力的同時降低成本？」答案不是「以不同方式使用 CloudWatch」 —— 而是停止按客戶維度的基數爆炸，轉而使用 Contributor Insights 處理前 N 名客戶的基數，並將原始事件移動到具備 EMF 的 CloudWatch Logs，這樣你既能保留資料又無需支付按指標計算的成本。了解這些工具及其成本模型是 DevOps 工程師專業級必備的技能。
- 命名空間 (Namespace)：指標的邏輯容器。AWS 提供的命名空間以
AWS/開頭 (例如AWS/EC2)；自訂命名空間則是其他任何名稱。命名空間對指標進行分割，以便儀表板和警示可以乾淨地過濾。 - 維度 (Dimension)：在命名空間內唯一識別指標的名稱-值對。每個唯一的組合都是一個獨立計費的指標。每個指標最多 30 個維度，而高基數 (high cardinality) 維度是 CloudWatch 成本的第一大驅動因素。
- 解析度 (Resolution)：標準解析度為 1 分鐘粒度 (預設)；高解析度為 1 秒粒度 (額外付費，僅用於次分鐘級警示)。
- 內嵌指標格式 (Embedded Metric Format, EMF)：一種 JSON 日誌格式，CloudWatch 會自動解析為指標。寫入一行 JSON 日誌即可獲得指標 —— 無需 PutMetricData 呼叫，無需 SDK，原生支援 Lambda 和容器。
- 指標篩選器 (Metric filter)：套用於日誌群組的篩選器，每當日誌事件與模式匹配時就發出一個 CloudWatch 指標。用於將非結構化日誌 (例如
ERROR文本) 轉化為可計數的指標。 - 指標串流 (Metric stream)：將每個 CloudWatch 指標持續近乎即時地串流到 Firehose，以 JSON 或 OpenTelemetry 格式交付。用於廉價地長期封存到 S3 或第三方分析工具。
- Logs Insights：專為 CloudWatch Logs 設計的查詢語言，具備
fields,filter,stats,parse,sort, 和limit運算子。按掃描的資料量 (GB) 計費。 - 訂閱篩選器 (Subscription filter)：日誌群組上的實時交付規則，將匹配的事件傳送到 Lambda、Kinesis Data Streams、Firehose 或 OpenSearch。
- Contributor Insights：一種內建的 CloudWatch 工具，用於尋找指標的前 N 個貢獻者 (例如前幾名 IP、前幾名客戶)，而不會造成維度基數爆炸。
- 跨帳戶可觀察性 (Cross-account observability)：一種監控帳戶模型，讓一個帳戶可以透過單一登入連結查看多個來源帳戶的指標、日誌和追蹤。
- 參考：https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html
白話文解釋 CloudWatch 指標與 Logs Insights
CloudWatch 的涵蓋面非常廣，如果沒有類比，命名空間、維度、解析度、EMF 和指標串流等概念很容易混淆。以下三個類比隔離了系統的不同部分。
類比 1：醫院生命徵象監測器與病歷室
想像一個繁忙的病房。每位病人 (每個 EC2 執行個體、每個 Lambda 調用、每個容器任務) 都連接到生命徵象監測器 —— 心率、血壓、血氧飽和度、體溫。這些讀數就是 CloudWatch 指標：在固定間隔內連續的數值取樣。醫院不會把每個讀數都存在剪貼簿上，而是儲存在一個按病房、按床位、按病人 (即命名空間與維度) 索引的中央監測站。同時，護理師會寫下病歷記錄 —— 關於發生了什麼的敘事性文字 (「凌晨 03:14 病人感到焦慮，給予安撫」)。這些就是 CloudWatch Logs：帶有時間戳記，主要是文本，可以使用 Logs Insights 查詢，就像醫生查閱病歷以重構輪班情況一樣。當醫生需要知道「這一小時內有多少病人發燒」時，這就是一個指標篩選器 —— 在病歷記錄中進行模式匹配並發出一個指標。當心臟科主任希望將每個監測器的每個讀數匯出到研究資料庫以進行長期研究時，這就是到 Firehose 的指標串流。DOP-C02 考試希望你選擇正確的成品：永遠不要將敘事性病歷存為數值指標 (高基數，昂貴)，也永遠不要嘗試在病歷室查詢數值生命徵象 (請使用指標監測站)。選錯工具就是 DOP-C02 的陷阱。
類比 2：餐廳收銀機與點餐單
餐廳執行兩套並行的記錄系統。收銀機記錄流水帳 —— 按小時、按工作站、按服務員計算的總銷售額。這就是 CloudWatch 指標：經過彙整、具有維度、專為快速查詢而設計。點餐單則整疊釘在牆上的釘子上 —— 每一份點餐及其詳細項目。這就是 CloudWatch Logs：高流量、半結構化，稍後當經理想要調查某個特定的投訴時再進行查詢。主廚不會透過閱讀每張點餐單來查詢「今天賣了多少個漢堡」 —— 那會很慢，而且點餐單堆會塞滿廚房。主廚看的是收銀機的存根聯 (一個 CloudWatch 指標)。但當客戶對費用有爭議時，主廚會從那一疊單子中找出特定的那張 (一個帶有 filter 和 parse 的 Logs Insights 查詢)。如果餐廳想要預測下週的漢堡需求，他們每週會將點餐單歸檔到研究室地下室 (到 S3 的指標串流)，資料科學家在那裡對歸檔檔案執行 Athena 查詢。EMF 就是廚房的聰明技巧：點餐單本身包含一張可撕下的收據，直接進入收銀機 —— 一張紙，同時更新兩套記錄系統。
類比 3：天文台的光感測器與底片
天文台有兩種儀器。光感測器以一秒的解析度持續採樣亮度，並將讀數存入數值資料庫。這就是高解析度 CloudWatch 指標 —— 快速、每個頻道昂貴、用於短期精密測量。底片 (Image plates) 是每 10 分鐘拍攝一次的廣角攝影曝光，以原始形式捕捉整個天空。這就是 CloudWatch Logs：大量、低頻、存檔多年，僅在發生有趣的事情時才查詢。當天文學家想要尋找「過去一小時內仙女座象限中最亮的物體」時，他們會執行 Logs Insights 查詢，掃描按區域過濾的底片。當他們想要追蹤北極星一整年的亮度時，他們會查看冷儲存中的指標串流歸檔。Contributor Insights 是一張智慧卡，可以排列「昨晚整個天空中最亮的前 10 個物體」，而無需為每個物體儲存單獨的指標 —— 這是對日誌串流進行的 count-min sketch。天文台不會把每顆恆星都作為其亮度指標的一個單獨維度；那會產生數百萬個指標並導致機構破產。它使用 Contributor Insights 來總結長尾資料。
對於專注於「指標 vs 日誌擷取選擇」的 DOP-C02 題目，請參考醫院生命徵象 vs 病歷記錄類比。對於專注於「高基數成本爆炸及其修復」的題目，請參考餐廳收銀機 vs 點餐單堆類比。對於專注於「長期封存 vs 即時查詢」的題目，請參考天文台感測器 vs 底片類比。參考：https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html
CloudWatch 指標組成解析 — 命名空間、維度、解析度
DOP-C02 的第一個實作選擇是指標的形狀。形狀不正確會導致帳單激增，或讓你的警示找不到所需的資料。
命名空間對指標進行分類以確保清晰
每個指標都存在於一個命名空間中。AWS 服務指標使用 AWS/<Service> (例如 AWS/Lambda, AWS/ECS)。你的自訂指標應使用清晰的應用程式或團隊前綴 (例如 MyCompany/Checkout)。命名空間在帳戶間永遠不會衝突。考試會測試你是否知道 AWS/EC2 僅包含虛擬化管理程式 (hypervisor) 可見的指標 (如 CPUUtilization 和 NetworkIn)；作業系統層級的指標 (如記憶體和磁碟使用率) 需要安裝 CloudWatch 代理程式，並歸類在 CWAgent (預設自訂命名空間) 下。
維度識別指標執行個體
維度是一個名稱-值對，它與指標名稱和命名空間一起唯一地識別一個計費的時間序列。帶有維度 {InstanceId=i-abc123} 的 CPUUtilization 是一個指標；帶有 {InstanceId=i-def456} 的同一個 CPUUtilization 是另一個獨立指標。每個唯一的維度組合都是一個新指標 —— 而 CloudWatch 按指標計費。DOP-C02 的基數陷阱：為指標標記 customer_id、request_id 或任何高基數欄位會使你的指標數量乘以該欄位的基數。切勿將無限制的欄位放入維度中；請改用 Contributor Insights 或 EMF 日誌。
解析度決定粒度與成本
標準解析度指標每 60 秒採樣一次。高解析度自訂指標支援 1, 5, 10, 30, 和 60 秒的粒度。只有在你真正需要次分鐘級警示 (例如熱點路徑 API 延遲) 時才設定高解析度。標準警示每分鐘評估一次；高解析度警示每 10 或 30 秒評估一次，成本更高。來自 EC2 的 AWS 提供指標預設為 5 分鐘，啟用詳細監控 (額外付費) 後可達到 1 分鐘。
從發佈具有唯一命名空間 + 名稱 + 維度組合的資料那一刻起，自訂指標就存在了。停止發佈不會刪除指標 —— 它會在停止活動 15 個月後過期。如果你意外發佈了一百萬個唯一維度組合的指標，你必須支付費用直到它們過期。在規模化開啟 PutMetricData 之前，務必驗證維度基數，並對高基數資料優先使用 EMF 日誌欄位，因為日誌是按擷取量計費，而非按唯一欄位組合計費。參考：https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html
統一的 CloudWatch 代理程式 — 一個代理程式同時處理指標與日誌
統一的 CloudWatch 代理程式取代了舊有的 SSM CloudWatch 外掛程式和獨立的 CloudWatch Logs 代理程式。它可以執行在 EC2 (Linux 和 Windows)、內部部署伺服器以及 ECS-on-EC2 節點上。代理程式讀取一個 JSON 組態檔案，該檔案定義了：
- 要收集的指標：每核心 CPU、記憶體、磁碟使用率、交換空間、網路連線、程序計數 —— 任何虛擬化管理程式不可見的內容。
- 要傳送的日誌：追蹤的檔案路徑、日誌群組名稱、日誌串流名稱、保留期。
- StatsD 與 collectd 擷取：代理程式接聽 UDP 埠以接收來自任何用戶端的應用程式發出指標。
- Procstat 外掛程式：針對特定二進位檔案的單一程序 CPU 與記憶體追蹤。
你在本地配置代理程式，然後將組態儲存在 SSM Parameter Store 中，並使用 SSM Run Command (AWS-ConfigureAWSPackage / AmazonCloudWatch-ManageAgent) 將其推送到機群。這個模式在考試中會被重點測試：在 DOP-C02 中不要編寫自訂 Ansible role 來部署代理程式；正確答案是使用 SSM Distributor + State Manager 以正確的配置來維持代理程式的安裝與執行。
一個常見的 DOP-C02 題目背景是回報記憶體洩漏，而團隊在 OOM 刪除程序後才發現。陷阱干擾項是「在 EC2 執行個體上啟用詳細監控」。詳細監控僅將 AWS 提供之指標的解析度從 5 分鐘更改為 1 分鐘 —— 它不會增加記憶體或磁碟指標。正確答案是安裝統一的 CloudWatch 代理程式，並將 mem_used_percent 和 disk_used_percent 傳送到 CWAgent 命名空間，然後針對這些自訂指標設定警示。參考：https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html
內嵌指標格式 (EMF) — 同一次寫入完成日誌與指標
EMF 是一種 JSON 日誌格式，CloudWatch 會自動解析以提取指標。寫入一條結構化日誌；CloudWatch 會讀取它並發出日誌事件 (可在 Logs Insights 中查詢) 和指標 (可設定警示、顯示在儀表板上)。該格式聲明了一個 _aws.CloudWatchMetrics 封裝，描述哪些欄位是維度、哪些是指標值以及其單位。EMF 對於 Lambda 和 ECS Fargate 來說非常理想，因為：
- 沒有同步的 PutMetricData API 呼叫 (這會增加延遲且可能失敗)。
- 高基數維度保留在日誌負載中，而不會成為計費指標。
- 一次寫入產生兩種遙測成品。
AWS Lambda Powertools 和 CloudWatch Embedded Metric Format 用戶端程式庫可以在 Python, Node.js, Java, 和 Go 中為你產生 JSON。EMF 在 DOP-C02 中備受強調，因為它在不犧牲可見性的情況下解決了基數問題。
指標篩選器 — 將日誌事件轉化為指標
指標篩選器是日誌群組上的一個儲存模式，每當匹配的事件到達時，它就會發出一個 CloudWatch 指標。經典的使用案例是將自由文本的 ERROR 日誌轉換為用於警示的計數指標。篩選器語法支援 JSON 日誌 ({ $.level = "ERROR" })、以空格分隔的權杖 ([ip, user, ..., status_code=5*, size]) 以及簡單的子字串匹配。
指標篩選器的值可以來自日誌欄位 (例如使用 $.duration 來追蹤請求時長) 或是一個字面值 1 來計算事件。然後你針對產生的指標設定警示。指標篩選器僅套用於建立篩選器後擷取的事件 —— 它們不會追溯掃描舊日誌。這是一個常見的 DOP-C02 陷阱干擾項。
Logs Insights 查詢語言 — CloudWatch 的 DevOps SQL
Logs Insights 是事故發生時進行按需日誌查詢的正確工具。它使用具有以下運算子的管道語法：
fields @timestamp, @message, @logStream—— 選擇欄位。filter status >= 500—— 篩選行。parse @message "user=* path=*" as user, path—— 從非結構化文本中提取。stats count() by bin(5m), service—— 彙整。sort @timestamp desc—— 排序。limit 100—— 限制數量。
Logs Insights 按掃描的資料量 (GB) 計費。它不是為持續查詢而設計的 —— 為此請使用指標篩選器或訂閱篩選器。它可以跨多個日誌群組 (一次查詢最多 50 個) 進行掃描。結果保留 7 天。常見的 DOP-C02 查詢模式：
- 尋找過去一小時內返回 5xx 錯誤的前 10 個路徑。
- 計算按端點分組的 P95 請求延遲。
- 使用請求 ID 在多個微服務日誌群組中追蹤使用者工作階段。
考試可能會顯示缺少一個運算子的部分查詢。背熟順序：fields → filter → parse → stats → sort → limit。彙整需要 stats (count, sum, avg, min, max, count_distinct 以及透過 pct(field, 95) 得到的百分位數)。時間分組使用 bin(<duration>)。跨日誌群組查詢同時支援最多 50 個日誌群組。Logs Insights 不支援 SQL 意義上的跨日誌群組 join —— 請改用共享欄位名稱 (如請求 ID) 並搭配 stats by。參考：https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html
訂閱篩選器 — 即時日誌發散 (Fan-Out)
訂閱篩選器將匹配的日誌事件實時交付到以下四個目標之一：
- AWS Lambda —— 用於低容量、低吞吐量的處理。
- Kinesis Data Streams —— 用於高吞吐量、多取用者發散。
- Amazon Data Firehose —— 用於批量交付到 S3, Redshift, OpenSearch, 或第三方工具。
- OpenSearch Service —— 用於全文檢索與 Kibana 儀表板。
每個日誌群組最多支援兩個訂閱篩選器。篩選器模式語法與指標篩選器語法相同。對於說明「將每個錯誤日誌實時發送到安全團隊帳戶」的 DOP-C02 情境，答案是到 Kinesis Data Streams 的訂閱篩選器 (它支援跨帳戶交付)，而不是「使用 S3 事件通知」或「排程一個 Lambda」。
指標串流 — 廉價的長期指標封存
指標串流會以近乎即時的方式，將每個 CloudWatch 指標 (或其過濾後的子集) 持續交付到 Amazon Data Firehose，格式為 JSON 或 OpenTelemetry 0.7 / 1.0。串流進入 Firehose 後，可以落地到 S3, Splunk, Datadog, New Relic 或任何 HTTP 端點。使用案例：
- 超過 CloudWatch 15 個月上限的廉價長期保留。
- 第三方 APM 整合，無需受限於按指標收費的 pull-API 限制。
- 成本最佳化：在 Athena 中查詢封存的指標，而無需支付 CloudWatch 指標資料 API 成本。
常見的題目背景：「合規性要求指標資料保留 7 年」。正確答案是到 Firehose 到 S3 的指標串流 並套用生命週期政策，而不是「增加 CloudWatch 保留期」 (它最高僅達 15 個月)。
日誌群組保留與 KMS 加密
根據預設，CloudWatch Logs 永久保留資料。這是成熟帳戶中 CloudWatch 成本的第一大驅動因素。請根據使用案例明確設定日誌群組保留期 (1, 3, 5, 7, 14, 30, 60, 90, 120, 150, 180, 365, 400, 545, 731, 1827, 2192, 2557, 2922, 3288, 3653 天，或永不逾期)。對於超出合規保留期的長期封存，請透過 Firehose 訂閱篩選器將日誌傳送到 S3，並套用 S3 生命週期政策 (Glacier Instant, Glacier Flexible, Deep Archive)。
KMS 加密是透過 associate-kms-key API 針對每個日誌群組配置的。KMS 金鑰政策必須允許 logs.<region>.amazonaws.com 進行加密，且政策條件應限制在特定的日誌群組 ARN，以防止混淆代理人問題。日誌群組不能使用 AWS 受管金鑰 —— 你必須使用客戶受管金鑰 (CMK)。
一個常見的 DOP-C02 成本最佳化情境是，由於多年前 Lambda 函數建立的日誌群組，CloudWatch 帳單穩定增長。陷阱干擾項是「單獨刪除舊的日誌串流」。正確答案是設定日誌群組保留期 (例如 30 天)，讓舊串流自動逾期，並透過 Config 規則 (cloudwatch-log-group-retention-period-check) 搭配 SSM Automation 執行手冊來補救不合規的日誌群組。參考：https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html
Contributor Insights — 無需基數爆炸即可獲取前 N 名
Contributor Insights 專為「誰是此指標的前幾名貢獻者」這個問題而設計。範例：
- 存取 ALB 的前 10 名來源 IP。
- 消耗 DynamoDB 容量的前 10 名客戶。
- 觸發 500 錯誤的前 10 名使用者代理。
你定義一個指向日誌群組的規則，識別貢獻者欄位 (例如 srcaddr)，Contributor Insights 就會計算滑動的前 N 名，而無需為每個貢獻者儲存指標。結果是一個顯示長尾資料與主要佔用者的圖表。只要基數是無限制的，請使用 Contributor Insights 而非 dimensions=customer_id。
跨帳戶可觀察性
CloudWatch 支援一個監控帳戶，它可以透過單一登入連結查看多達 100,000 個來源帳戶的指標、日誌和 X-Ray 追蹤。此模型在監控帳戶中使用 可觀察性存取管理員 (OAM) 接收器 (sink)，並在每個來源帳戶中建立一個 OAM 連結。這是實現跨 Organizations 組織單元 (OU) 集中式 DevOps 可見性的正確模式。考試非常喜歡這個功能，因為它是 2022 年後推出的，舊的學習教材通常會遺漏。
高頻考試陷阱
以下是 DOP-C02 經常出現的考點。請背熟陷阱形狀和正確答案。
陷阱 1：CloudWatch 代理程式 vs CloudWatch Logs 代理程式
舊有的 CloudWatch Logs 代理程式 (awslogs) 已棄用。考試偶爾仍會將其列為干擾項。對於指標和日誌，務必選擇統一的 CloudWatch 代理程式。
陷阱 2：指標篩選器無法追溯回補
指標篩選器僅發出建立篩選器後擷取之日誌事件的指標。干擾項說「建立指標篩選器以計算上週日誌中的錯誤」 —— 錯誤；正確答案是使用 Logs Insights 查詢獲取歷史資料。
陷阱 3：Logs Insights 無法取代即時警示
Logs Insights 是按需叫用的，不是持續執行的。要實時針對日誌模式設定警示，你需要 指標篩選器 → 指標 → 警示，而不是排程的 Logs Insights 查詢。
陷阱 4：VPC Flow Logs 與受管日誌計費
傳送到 CloudWatch Logs 的 VPC Flow Logs 按受管日誌 (vended-logs) 擷取率計費 (比自訂日誌便宜)。考試會測試你是否知道受管日誌 (VPC Flow Logs, Route 53 查詢日誌, Global Accelerator, AWS Network Firewall) 的計費方式與你的應用程式日誌不同。
陷阱 5：內嵌指標格式 (EMF) 需要 JSON 封裝
EMF 要求 JSON 日誌行中包含 _aws 封裝。沒有封裝的純 JSON 僅被視為日誌事件 —— 不會建立指標。陷阱干擾項是「將 JSON 記錄到 CloudWatch Logs，CloudWatch 就會自動建立指標」。錯誤 —— 你必須使用 EMF 封裝。
陷阱 6：Lambda 函數日誌預設沒有保留期
Lambda 建立的 /aws/lambda/<function> 日誌群組預設為永不逾期。建立 Lambda 的 CDK 和 CloudFormation 模板應明確設定 LogRetentionInDays。
陷阱 7：訂閱篩選器限制
每個日誌群組支援兩個訂閱篩選器。如果情境說明「將日誌傳送到 SIEM、安全分析 Lambda 和 OpenSearch」，你無法僅透過訂閱篩選器完成這三項。正確答案是建立一個訂閱篩選器到 Kinesis Data Streams，然後從 Kinesis 發散到多個取用者。
ECS 容器透過任務定義中的 awslogs 日誌驅動程式將 stdout/stderr 傳送到 CloudWatch Logs。這是一個 Docker 驅動程式，不是 CloudWatch 代理程式。代理程式用於 EC2 主機 (EC2 啟動類型) 的作業系統級指標，或用於側車 (sidecar) 指標收集 (在 Fargate 中透過 AWS Distro for OpenTelemetry)。混淆這兩條擷取路徑是高頻率的 DOP-C02 陷阱。參考：https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html
DOP-C02 考試模式與案例解析
情境 1：EC2 Auto Scaling 群組上的記憶體警示
題目背景：「團隊需要在 Auto Scaling 群組上的記憶體使用率超過 85% 並持續五分鐘時發出警示。」錯誤答案：啟用詳細監控。正確答案：透過 SSM Distributor + State Manager 安裝統一的 CloudWatch 代理程式，將 mem_used_percent 傳送到 CWAgent 命名空間並帶有 AutoScalingGroupName 維度，然後針對 5 分鐘內的 5 個資料點建立 85% 的 CloudWatch 警示。
情境 2：在事故發生時尋找緩慢的端點
題目背景：「值班工程師需要識別過去一小時內 P95 延遲高於 2 秒的 API 路徑。」錯誤答案：使用 Athena 掃描 S3 (擷取路徑太慢)。正確答案：CloudWatch Logs Insights 查詢，使用 parse, stats pct(duration, 95) by path, filter pct95 > 2000。提到 bin(5m) 以查看趨勢。
情境 3：削減按客戶計算的指標成本
題目背景：「每個指標都標記了 12,000 個客戶；成本超出預算 8 倍。」錯誤答案：縮短保留期。正確答案：停止按客戶的維度，切換到將 customer_id 作為日誌欄位的 EMF 日誌，使用 Contributor Insights 進行前 N 名追蹤。彙整指標保持低基數；按客戶追蹤的能力透過日誌保留。
情境 4：符合合規要求的 7 年指標保留
題目背景：「合規性要求指標資料保留 7 年。」錯誤答案：增加 CloudWatch 保留期。正確答案：到 Firehose 到 S3 的 CloudWatch 指標串流，並透過生命週期轉換到 Glacier；透過 Athena 查詢歷史資料。
情境 5：多帳戶集中式日誌
題目背景：「100 個來源帳戶；安全團隊需要單一視窗日誌搜尋。」正確答案：CloudWatch 跨帳戶可觀察性，配置監控帳戶 OAM 接收器和每個來源帳戶的 OAM 連結；對於日誌封存，透過 Firehose 傳送到中央 S3 儲存桶並使用 Athena 查詢。
成本最佳化手冊
在成熟的帳戶中，CloudWatch 是前三大帳單項目之一。DOP-C02 的成本最佳化問題圍繞著這些槓桿：
- 設定日誌群組保留期 —— 絕不保留預設值。應用程式日誌通常為 30-90 天；詳細偵錯日誌為 1-7 天；除非有明確合規需求，否則不應更長。
- 消除高基數維度 —— 轉向 EMF + Contributor Insights。
- 對 VPC Flow Logs、Route 53 查詢日誌使用受管日誌 (vended-logs) 路徑 (比自訂日誌便宜)。
- 使用指標串流進行長期封存，而不是延長 CloudWatch 的保留期。
- 對封存日誌使用 S3 Storage Lens + 生命週期政策。
- 在應用程式層對偵錯日誌進行抽樣；不要將每個事件都傳送到 CloudWatch。
- 當基數真的很高時，使用 AWS Distro for OpenTelemetry 將指標傳送到受管 Prometheus 而非 CloudWatch。
FAQ
Q1：我什麼時候該使用 CloudWatch 指標、CloudWatch Logs 或是透過 EMF 同時使用兩者？ 對於持續設定警示的低基數數值序列 (CPU, 延遲, 錯誤率)，請使用指標。對於按需查詢的高容量敘事性事件 (請求追蹤, 偵錯輸出)，請使用日誌。當你兩者都想要時 (一個帶有內嵌指標值和維度的結構化日誌行)，請使用 EMF。EMF 是 DOP-C02 中來自 Lambda 和 Fargate 應用遙測的最佳選擇，因為它解決了基數成本問題並保留了追溯能力。
Q2：Logs Insights 與 Athena 查詢日誌相比如何？ Logs Insights 直接查詢 CloudWatch Logs，具備秒級延遲和 7 天結果保留期。Athena 查詢已匯出到 S3 的日誌，在規模化時轉換為 Parquet 格式會便宜 10-100 倍。事故調查時 (過去幾小時到幾天) 使用 Logs Insights。長期分析、合規報告和對成本敏感的大量查詢則使用 Athena。
Q3：如何在不增加指標帳單的情況下監控 Lambda 函數？
透過 AWS Lambda Powertools 程式庫使用 EMF。將指標作為結構化日誌事件的一部分發出；CloudWatch 會自動提取指標。將 customer_id 等高基數欄位標記為日誌欄位，而非維度。使用 Contributor Insights 進行前 N 名客戶的追蹤。
Q4：指標串流與訂閱篩選器有什麼區別？ 指標串流將指標傳送到 Firehose；訂閱篩選器將日誌事件傳送到 Lambda, Kinesis, Firehose, 或 OpenSearch。它們是互補的 —— 兩者都可以將資料落地到 S3 進行封存，但資料形狀不同。
Q5：我可以用自己的 KMS 金鑰加密 CloudWatch Logs 嗎？
可以，使用客戶受管金鑰 (CMK)。KMS 金鑰政策必須允許 logs.<region>.amazonaws.com，且理想情況下應透過 kms:EncryptionContext:aws:logs:arn 條件限制到特定的日誌群組 ARN。AWS 受管金鑰無法加密日誌群組。
Q6：我該如何追溯分析已經擷取的日誌？
針對過去 7 天的儲存資料使用 Logs Insights 執行單次查詢，或是將日誌匯出到 S3 (透過手動 CreateExportTask API 或透過 Firehose 訂閱篩選器) 並使用 Athena 查詢。
Q7：為什麼我的 Lambda 日誌群組永遠不會過期？
Lambda 預設建立 /aws/lambda/<function> 日誌群組且保留期為永不逾期。請在 IaC 中設定 LogRetentionInDays，或使用 AWS Config 規則 cloudwatch-log-group-retention-period-check 來偵測不合規的群組並透過 SSM Automation 進行補救。
交叉參考
- CloudWatch 警示與 EventBridge 涵蓋在
cloudwatch-alarms-eventbridge-integration中，用於警示與修復流程。 - X-Ray 分佈式追蹤 涵蓋在
xray-distributed-tracing中，用於請求路徑的可觀察性。 - CloudTrail 與 Config 儀表板 涵蓋在
cloudtrail-config-audit-dashboards中，用於治理稽核。 - EventBridge 自動修復執行手冊 涵蓋在
eventbridge-auto-remediation-runbooks中，用於完成警示的回饋循環。 - 部署失敗故障排除 使用相同的 Logs Insights 和指標模式，涵蓋在
deployment-failure-troubleshooting中。