CloudWatch、CloudTrail 與資料管線監控

用於資料管道的 CloudWatch 監控與儀表板是每個生產環境 AWS 資料工程工作負載所依賴的觀測能力 (Observability) 基礎，而在 DEA-C01 考試中，網域 3 的問題中大約每四題就有一題涉及 CloudWatch。陷阱模式非常一致：考生知道 CloudWatch 的存在，也使用過 CloudWatch 警報，但他們無法區分那些取決於「指標對比日誌 (metric-versus-log)」區分或「CloudWatch 對比 CloudTrail」界限的情境。來自 VivekR 的 30 天路線圖、Tutorials Dojo 和 ExamCert.App 的社群研究指南都指出了 DEA 考生常低估 CloudWatch 和 CloudTrail 的深度 — 大多數準備教材在 CloudWatch 上僅花十分鐘，而考試則會詢問六個相關問題。

本指南旨在從資料工程師的視角，將 CloudWatch 監控與儀表板轉化為維運肌肉記憶。它涵蓋了管道觀測能力的四大支柱、指標與日誌的區分、關鍵資料服務指標（Glue DPU 使用量、Kinesis IteratorAge、Redshift 查詢持續時間）、CloudWatch Logs 和 Logs Insights 查詢語言、閾值/異常偵測/複合警報、橫跨 Kinesis/Glue/Redshift 的儀表板、用於自動修復的 EventBridge 警報整合、CloudTrail 的差異、CloudTrail Lake SQL 稽核、用於合規性追蹤的 AWS Config，以及規範的指標 vs 日誌與 CloudWatch vs CloudTrail 考試陷阱。

資料管道觀測能力 — 四大支柱

生產環境資料管道需要四種遙測 (telemetry) 數據，CloudWatch 原生提供了其中的三種（第四種是追蹤，屬於 X-Ray 的範疇）。

支柱 1 — 指標 (Metrics)

隨時間採樣的數值 — Glue 作業 DPU 消耗量、Kinesis IteratorAge、Redshift 查詢持續時間。指標回答了「管道是否健康」的問題，是主要的警報信號。

支柱 2 — 日誌 (Logs)

僅附加 (append-only) 的事件串流 — Glue 驅動程式日誌、Lambda 呼叫日誌、EMR 步驟日誌。日誌回答了「在特定執行期間發生了什麼」的問題，是主要的除錯來源。

支柱 3 — 警報 (Alarms)

指標上的閾值或異常條件，用於觸發通知或自動化操作。警報回答了「當健康狀況下降時喚醒某人」的問題。

支柱 4 — 追蹤 (Traces, 在 DEA 範圍之外)

將跨服務的請求聯繫在一起的分散式追蹤。對於疑難排解跨服務延遲很有用。DEA-C01 不會深入測試 X-Ray；AWS 考試重點在於 CloudWatch 的指標、日誌和警報。

CloudWatch 指標 — 數值核心

CloudWatch 指標是由 AWS 服務自動發佈或由您的應用程式透過 PutMetricData API 發佈的數值樣本。

標準對比高解析度指標

標準指標具有 1 分鐘的細粒度；高解析度指標具有 1 秒的細粒度。AWS 服務指標大多是標準的；自定義應用程式指標可以是兩者之一。高解析度指標成本較高，但對於亞分鐘級的警報是必要的。

命名空間與維度

指標按命名空間 (AWS/Glue, AWS/Kinesis, AWS/Redshift) 進行組織，並具有維度 (dimension)（如作業名稱、串流名稱、叢集識別碼）。維度是過濾軸 — 「顯示 job_name=daily_etl 的 Glue DPU 使用量」。

資料工程的關鍵指標

Glue：glue.driver.aggregate.numCompletedTasks、按作業劃分的 DPU 使用量、作業持續時間、錯誤率。Kinesis Data Streams：IncomingRecords、IncomingBytes、IteratorAgeMilliseconds（取用者延遲指標 — 這是最受關注的 Kinesis 指標）。Kinesis Firehose：IncomingRecords、DeliveryToS3.Records、DeliveryToS3.DataFreshness。Redshift：CPUUtilization、DatabaseConnections、WLMQueryDuration、QueriesCompletedPerSecond。Step Functions：執行次數、執行持續時間、失敗執行次數。Lambda：呼叫次數、錯誤、持續時間、節流、並行執行。

指標數學 (Metric Math)

CloudWatch 支援指標數學表達式：(metric_a / metric_b) * 100 用於衍生值、RATE(metric_a) 用於每秒速率、ANOMALY_DETECTION_BAND(metric_a, 2) 用於異常區間。用於儀表板和警報中的衍生 KPI。

CloudWatch Logs — 集中化日誌儲存

CloudWatch Logs 是 AWS 服務和您的應用程式寫入的集中化日誌儲存。

日誌群組與日誌串流

日誌群組 (log group) 是容器，通常以服務和資源命名 (/aws-glue/jobs/output, /aws/lambda/my-function)。在群組內，日誌串流 (log stream) 是單個來源 — 每個 Lambda 執行環境一個串流、每個 Glue 工作節點一個、每個 EMR 應用程式一個。保留期按日誌群組設定（1 天到 10 年，或永遠不逾期）。

組態日誌保留期

預設情況下，由 AWS 服務自動建立的日誌群組具有無限期保留期 — 這會為沒人閱讀的日誌永遠花錢。推薦基準：對大多數日誌群組設定 30 天保留，對合規性相關日誌設定 90 天，對安全稽核日誌設定 1 年。DEA-C01 考試會透過成本控制情境來測試這一點。

日誌訂閱與轉發

訂閱篩選器 (subscription filters) 將日誌近乎即時地串流傳輸到 Lambda、Kinesis Data Streams 或 Kinesis Firehose。模式：透過訂閱篩選器將 Glue 或 Lambda 日誌轉發到中央日誌分析目的地，通常進入 Firehose 到 S3 進行長期封存。

即時結尾 (Live Tail)

Live Tail 是傳入日誌的串流主控台視圖 — 對於在開發期間觀察 Glue 作業非常有用。每個帳戶受限於少量並行工作階段。

CloudWatch Logs Insights — 類 SQL 查詢

Logs Insights 是一種查詢語言，可讓工程師搜尋和聚合 CloudWatch Logs。

查詢語法

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 100

命令：fields (欄位), filter (過濾), stats (統計), sort (排序), limit (限制), parse (解析), dedup (去重)。輸出到資料表。統計命令可進行聚合：stats count(*) by bin(5m) 用於按 5 分鐘時間桶計數，stats avg(@duration) by serviceName 用於按服務名稱分組的平均值。

資料工程的使用案例

尋找過去一小時內的所有 Glue 作業錯誤：filter @message like /Exception/ | stats count(*) by job_name。尋找最慢的 Lambda 呼叫：stats max(@duration) by @logStream | sort by max desc | limit 10。追蹤 Redshift 查詢持續時間離群值：parse @message "Query * completed in *ms" as queryId, ms | filter ms > 60000。

跨日誌群組查詢

單個 Logs Insights 查詢可以橫跨多達 50 個日誌群組，對於追蹤跨服務的請求非常有用（例如，一個呼叫 Lambda 再寫入 S3 的 Glue 作業 — 可以同時查詢這三個日誌群組）。

CloudWatch 警報 — 閾值與異常偵測

警報是 CloudWatch 指標上的主要警報機制。

閾值警報 (Threshold Alarms)

靜態閾值：「當 Glue 作業持續時間 > 60 分鐘（持續 1 個資料點）時發出警報」。簡單、可預測，適用於理解透徹的指標。閾值必須由工程師設定；不良的閾值會導致警報疲勞或遺漏信號。

異常偵測警報 (Anomaly Detection Alarms)

異常偵測會在 2 週的視窗內學習指標的正常模式（包括季節性），並在指標超過 N 個標準差區間時發出警報。最適用於具有每日或每週週期的指標，靜態閾值無法捕捉「正常」情況 — 例如，Kinesis 傳入記錄在工作時間正常較高而在夜間較低。組態方式是在警報精靈中選擇「異常偵測」並設定標準差倍數（通常為 2 或 3）。

複合警報 (Composite Alarms)

複合警報使用 AND/OR 邏輯結合多個警報 — 僅當 Glue 作業警報和 Redshift WLM 警報同時觸發時才發出警報，只要其中一個處於 OK 狀態就抑制另一個。複合警報可減少級聯故障中的警報噪音，在這種情況下，一個根源會觸發許多下游症狀警報。

警報動作

警報觸發 SNS 通知、EventBridge 事件、Auto Scaling 動作或 Systems Manager OpsItem 建立。EventBridge 整合是實現自動化修復的路徑 — 警報觸發，EventBridge 規則路由到執行糾正動作的 Step Functions 或 Lambda。

CloudWatch 儀表板 — 維運視圖

儀表板是視覺化小組件 (widgets) 的集合 — 線圖、數字顯示、日誌表、警報狀態 — 用於一目了然的維運可見性。

構建資料管道儀表板

典型的管道儀表板結合了：橫跨所有串流的 Kinesis IteratorAge（線圖）、7 天內的 Glue 作業持續時間趨勢（線圖）、Redshift WLM 查詢佇列長度（數字顯示）、Step Functions 執行成功率（帶有異常區間的線圖）以及當前正在觸發的警報清單（警報組件）。儀表板成為每日站會的視圖。

跨帳戶儀表板

跨帳戶觀測能力允許一個監控帳戶透過 CloudWatch 的跨帳戶觀測能力功能，查看來自許多來源帳戶的指標和儀表板。對於監督分佈在各個業務單元的資料工程帳戶的集中式 SRE 團隊非常有用。

儀表板共享與權限

儀表板可以透過簽署的 URL 公開共享（唯讀、有時間限制），或透過 IAM 權限供帳戶內檢視者使用。公開共享適用於狀態頁面；敏感的維運資料應保持受 IAM 管控。

EventBridge 與自動化修復

CloudWatch 警報會發佈到 EventBridge，從而實現自動化修復。

警報到動作模式 (Alarm-To-Action Pattern)

警報觸發 => 警報狀態更改事件發佈到預設 EventBridge 匯流排 => EventBridge 規則對事件進行模式匹配 => 目標 Lambda 或 Step Functions 執行修復。範例：串流取用者延遲觸發 Kinesis IteratorAge 警報 => Lambda 觸發 Lambda 並行度增加或擴展 ECS 取用者服務。

為什麼不直接將警報發送到 Lambda

警報與 Lambda 直接整合是存在的，但缺乏 EventBridge 提供的路由靈活性、多目標支援和跨帳戶路由。對於可擴展的維運，推薦「警報發佈到 EventBridge，EventBridge 進行路由」的模式。

CloudWatch Agent — 來自 EC2 和 EMR 的自定義指標

CloudWatch Agent 是安裝在主機上的代理程式，用於發佈來自 EC2、EMR 叢集節點和本地部署伺服器的 OS 層級指標（記憶體、磁碟、自定義日誌檔案）。AWS 服務層級指標是自動發佈的；OS 層級指標則需要代理程式。

為什麼工程師需要在 EMR 上安裝代理程式

EMR 叢集節點公開了 YARN ResourceManager 和 Spark UI 指標，預設的 AWS/EMR 命名空間無法詳細捕捉這些指標。安裝 CloudWatch Agent 並將其組態為從 Spark 和 YARN 發佈 JMX 指標，可以深入了解叢集健康狀況。

CloudWatch vs CloudTrail — 關鍵區分

這是 DEA-C01 網域 3 中價值最高的區分。考試經常設置這兩者之間的混淆。

CloudWatch

CloudWatch 監控指標和日誌 — 正在執行的服務中發生了什麼。Glue DPU 使用量、Kinesis IteratorAge、Lambda 錯誤、來自您應用程式碼的日誌行。CloudWatch 告訴您服務健康狀況和應用程式行為。

CloudTrail

CloudTrail 監控 API 呼叫 — 誰對 AWS 資源做了什麼。「使用者 X 在 Y 時間從 IP Z 呼叫了 CreateGlueJob」屬於 CloudTrail。CloudTrail 告訴您身份和存取事件，而不是服務健康狀況。

CloudTrail 事件類型

管理事件 (Management events)：控制平面 API 呼叫 (CreateBucket, RunInstances, CreateGlueJob)。資料事件 (Data events)：資料平面 API 呼叫 (S3 GetObject/PutObject, Lambda Invoke, DynamoDB Query)。管理事件在您帳戶中的第一份副本是免費的；資料事件按事件計費，通常需要針對特定資源選擇性開啟，因為量很大。

Insights 事件

CloudTrail Insights 事件會標記異常的 API 呼叫模式 — 例如 IAM 角色建立突然激增、S3 刪除出現非預期模式。對於安全性異常偵測非常有用。

CloudTrail Lake — 可使用 SQL 查詢的稽核存放區

CloudTrail Lake 是一個受管的稽核存放區，可將 CloudTrail 事件保留 7 年，並透過 SQL 查詢公開這些事件。

工作原理

CloudTrail Lake 事件資料存放區從 CloudTrail（或從 CloudTrail 追蹤）擷取事件，將其儲存在不可變、可搜尋的格式中，並在 CloudTrail 主控台中公開 SQL 介面。查詢範例：SELECT eventName, userIdentity.arn FROM event_data_store WHERE eventName = 'DeleteBucket' AND eventTime > '2026-01-01'。

何時使用 CloudTrail Lake

當需要針對合規性或調查進行長期的稽核保留（數年）以及針對稽核歷史進行隨機 SQL 查詢時，請使用 Lake。當 CloudTrail 的基本事件歷史（主控台 90 天）足夠，且 S3 封存的追蹤日誌能以較低成本滿足長期需求時，則跳過 Lake。

成本模型

按擷取的 GB 數加上查詢掃描的 GB 數計費。顯著比透過 Athena 查詢 S3 封存的 CloudTrail 日誌昂貴，但提供了更簡單的維運體驗和不可變儲存保證。

AWS Config — 組態更改追蹤

AWS Config 記錄一段時間內 AWS 資源的組態更改，並評估合規性規則。

Config 與 CloudTrail 的區別

CloudTrail 記錄 API 呼叫（「使用者 X 呼叫了 CreateBucket」）；Config 記錄產生的資源狀態（「該儲存貯體已停用版本控制」）。Config 為每個資源維護組態時間軸 — 資源在每個時間點的樣子。

Config 規則

內建規則用於檢查合規性 — 例如「S3 儲存貯體必須啟用加密」、「RDS 執行個體必須啟用備份」、「Glue 作業必須啟用 CloudWatch Logs」。自定義規則由 Lambda 提供支援。

在資料工程中的用途

Config 規則可確保資料工程資源保持合規 — 加密需求、保留政策、網路組態。結合 EventBridge，不合規的資源會觸發自動化修復。

白話文解釋 CloudWatch Monitoring And Dashboards

三個具體的類比可以使 CloudWatch 的作用以及 CloudWatch 與 CloudTrail 的區分變得直觀。

類比 1 — 醫院病患生命體徵對比訪客登記簿

想像一間醫院。每間病房都有一台壁掛式螢幕顯示即時生命體徵 — 心率、血壓、血氧飽和度 — 這些讀數會串流到中央護理站，以便一目了然地觀察。這就是您資料管道的 CloudWatch 指標：Glue DPU 使用量是心率，Kinesis IteratorAge 是血壓，Redshift 查詢持續時間是血氧飽和度。護理站設有警報 — 「如果心率超過 120，呼叫心臟科醫生」 — 這正是具有閾值的 CloudWatch 警報。異常偵測警報就是那些經驗豐富的護士，他們知道早上 6 點巡房期間心率上升是正常的，但凌晨 3 點同樣的上升就令人擔憂。病房裡的病歷表 — 醫生記錄的所做所見 — 就是 CloudWatch Logs：應用程式的敘述性輸出。護理站同時顯示每間病房生命體徵的儀表板就是 CloudWatch 儀表板。現在想像醫院門口的訪客登記簿 — 姓名、時間、拜訪對象。這就是 CloudTrail：誰進入了建築物以及他們來做什麼。如果病人的藥物被更改了，病歷表 (Logs) 會顯示更改了什麼以及生命體徵 (metrics) 會顯示病人的反應；訪客登記簿 (CloudTrail) 會顯示更改藥物的醫生是在下午 2 點簽到的。查看訪客登記簿來尋找為什麼病人血壓下降是找錯了工具 — 那是 CloudWatch 的工作。

類比 2 — 擁有多種感測器類型的工廠生產線

想像一家工廠，輸送帶將產品帶往各個階段。工廠在每個站點都設有溫度感測器、振動感測器和計數感測器 — 這些讀數會串流到中央控制室，操作員在那裡觀察儀表板。這就是 CloudWatch 指標。每台機器都有維護日誌，機械師在那裡寫下「上午 10 點更換了皮帶，下午 2 點觀察到異常噪音」 — 這就是 CloudWatch Logs，由應用程式編寫的敘事。控制室有一個警報面板 — 當溫度超過閾值或計數低於底限時，紅燈閃爍並響起蜂鳴器 — 這就是 CloudWatch 警報。工廠的識別證門禁系統記錄了誰進入了工廠以及他們存取了哪些區域 — 姓名、時間、訪問區域。這就是 CloudTrail。如果機器壞了，感測器 (metrics) 和維護日誌 (Logs) 會告訴您發生了什麼故障；門禁日誌 (CloudTrail) 會告訴您最後一個接觸機器的人是誰。詢問門禁日誌為什麼溫度飆升是錯誤的；詢問感測器誰進入了工廠也是錯誤的。異常偵測警報就像領班，他知道夜班的運轉通常比早班有更高的振動；靜態閾值警報則是底層的「如果溫度超過 95°C 則停機」。複合警報則是「冷卻器警報和溫度警報同時觸發時不要呼叫我 — 它們總是一起觸發」。

類比 3 — 餐廳廚房攝影機對比預約簿

想像一家繁忙的餐廳廚房，每個工作站都有攝影機對著，每個冰箱都有溫度探針，還有一個數位點餐系統。攝影機和探針串流傳輸到經理的監控螢幕 — 這就是 CloudWatch 指標加上儀表板。主廚在整晚的服務筆記中記錄發生的事情 — 「3 號爐火滅了，改用 4 號爐」 — 這就是 CloudWatch Logs。餐廳有一本預約簿和一個員工打卡機 — 誰進來了以及誰進入了廚房。這就是 CloudTrail。預約簿不會告訴您為什麼爐火滅了；攝影機和主廚的筆記會告訴您。主廚的筆記不會告訴您誰在晚上 11 點進入了後端辦公室；打卡機和預約簿會告訴您。當溫度超過閾值時，冰箱探針警報會觸發 (CloudWatch 靜態閾值警報)；經驗豐富的副主廚注意到洗碗機的噪音模式異常 (人肉版的異常偵測)。DEA-C01 考試要求您閱讀情境，辨別問題是關於服務健康還是關於身份稽核，並據此選擇 CloudWatch 或 CloudTrail。

CloudWatch 監控的常見考試陷阱

DEA-C01 考試設置了一套穩定的陷阱。請記住這五個。

陷阱 1 — 使用 CloudWatch Logs 進行 API 稽核

情境詢問「尋找上週是誰刪除了 IAM 角色」。錯誤答案：搜尋 CloudWatch Logs。正確答案：CloudTrail 事件歷史記錄。

陷阱 2 — 使用 CloudTrail 尋找應用程式錯誤

情境詢問「尋找昨晚 Glue 作業失敗的原因」。錯誤答案：CloudTrail。正確答案：CloudWatch Logs（Glue 將作業輸出寫在那裡）。

陷阱 3 — 在週期性指標上使用靜態閾值

情境描述了 Kinesis IncomingRecords 具有每日高峰，團隊設定了靜態閾值導致錯誤警報。正確答案：異常偵測警報。

陷阱 4 — 無限期的日誌保留

情境描述了不斷增加的 CloudWatch Logs 成本。正確答案：組態每個日誌群組的保留期（非合規性為 30/90 天，稽核日誌則更長）。錯誤：先封存到 S3（如果合規性要求以較低成本長期保留，這才是正確答案）。

陷阱 5 — 將 Logs Insights 用於跨帳戶

情境需要跨帳戶查詢日誌。Logs Insights 在帳戶內查詢；跨帳戶需要 CloudWatch 跨帳戶觀測能力，或透過訂閱篩選器將日誌集中到中央帳戶。

關鍵數字與必須記住的 CloudWatch 事實

指標

• 標準細粒度：1 分鐘
• 高解析度：1 秒
• 透過 PutMetricData 的自定義指標
• 命名空間：AWS/Glue, AWS/Kinesis, AWS/Redshift 等
• 指標數學：儀表板和警報中的衍生表達式

日誌

• 預設保留期：無限期（應設定明確的保留期）
• Log Insights：類 SQL 的查詢語言
• 跨日誌群組查詢：多達 50 個群組
• 訂閱：即時轉發到 Lambda, Kinesis, Firehose

警報

• 閾值：靜態條件
• 異常偵測：2 週訓練，N 個標準差區間
• 複合警報：多個警報上的 AND/OR 邏輯
• 動作：SNS, EventBridge, Auto Scaling, OpsItem

儀表板

• 支援跨帳戶觀測能力
• 透過簽署的 URL 公開共享（有時間限制、唯讀）
• 帳戶內存取受 IAM 管控

CloudTrail

• 管理事件：第一份副本免費，屬於控制平面
• 資料事件：選擇性開啟、按次計費、屬於資料平面 (S3 物件, Lambda 呼叫)
• CloudTrail Lake：7 年保留，SQL 查詢
• Insights 事件：異常 API 模式

AWS Config

• 每個資源的組態時間軸
• 規則：內建或自定義 Lambda 支援
• 透過 EventBridge 到 Systems Manager 的自動修復

FAQ — CloudWatch 監控與儀表板常見問題

Q1 — 我什麼時候應該使用閾值警報與異常偵測警報？

當指標具有確定性的可接受範圍時，請使用閾值警報 — 「Lambda 錯誤必須為零」、「Glue DPU 使用量不得超過組態的 DPU」、「Redshift 查詢持續時間在儀表板查詢中必須保持在 60 秒以下」。閾值警報簡單、可預測且便宜。當指標具有靜態閾值無法捕捉的自然變化時，請使用異常偵測 — 「Kinesis IncomingRecords 在工作時間激增並在晚上下降，但突然的午夜激增則是異常的」、「每週批次處理由於週末積壓而在週一運行時間較長」。異常偵測會在 2 週的訓練窗口內學習指標模式，並在出現 N 個標準差偏離時發出警報。DEA-C01 考試會透過描述指標模式來測試這一點；正確的警報類型取決於該模式。

Q2 — 我該如何在情境中區分 CloudWatch 和 CloudTrail？

CloudWatch 追蹤指標和日誌 — 它回答「正在發生什麼」或「應用程式中發生了什麼」。CloudTrail 追蹤 API 呼叫 — 它回答「誰做了什麼」，並附帶身份、時間、來源 IP 和請求參數。如果情境關鍵字是「效能」、「錯誤率」、「日誌行」、「異常」或「應用程式輸出」，CloudWatch 就是答案。如果情境關鍵字是「誰」、「稽核」、「API 呼叫」、「呼叫」、「刪除」或「修改」，CloudTrail 就是答案。AWS Config 位居鄰近位置 — Config 追蹤「資源狀態在每個時間點是什麼樣子」，回答關於組態漂移的合規性問題。DEA-C01 考試中約有一半的網域 3 觀測能力問題涉及這種區分；弄清界限是高效的備考方式。

Q3 — 我該如何控制 CloudWatch Logs 成本？

CloudWatch Logs 的成本主要由擷取量和儲存保留期決定。三種控制措施可以降低成本。首先，組態每個日誌群組的保留期 — 預設情況下，日誌群組具有無限期保留；將大多數群組設定為 30 天保留，關鍵管道設定為 90 天，稽核日誌設定為 1 年，可以大幅削減儲存成本。其次，在應用程式碼中降低日誌詳細程度 — 在生產環境中使用 INFO 級別，而不是 DEBUG。第三，對於必須長期保留的高容量日誌，使用訂閱篩選器透過 Kinesis Firehose 轉發到 S3（對於相同的資料量，S3 儲存成本比 CloudWatch Logs 便宜約 10 倍）。DEA-C01 考試會測試關於成本增加的情境；答案是保留期加上日誌層級加上封存。

Q4 — 我應該在 Kinesis Data Streams 管道上監控哪些指標？

最重要的單一指標是每個碎片的 IteratorAgeMilliseconds — 這是取用者尚未讀取的碎片中最舊記錄的年齡。IteratorAge 上升意味著取用者落後於生產者，管道正在失去即時性。應針對 IteratorAge 同時設定閾值和異常偵測警報。次要指標：用於擷取量的 IncomingRecords 和 IncomingBytes（配合異常偵測）、用於碎片飽和度的 ReadProvisionedThroughputExceeded 和 WriteProvisionedThroughputExceeded、用於取用者端效能的 GetRecords.Latency。建立一個儀表板，在一個視圖中顯示所有串流的 IteratorAge 和擷取量。

Q5 — 什麼是 CloudTrail Lake，我應該在什麼時候使用它？

CloudTrail Lake 是一個受管的事件資料存放區，它擷取 CloudTrail 事件，將其以不可變、可搜尋的格式儲存長達 7 年，並在 CloudTrail 主控台中公開 SQL 查詢介面。當合規性要求超出 CloudTrail 90 天主控台歷史記錄的長期稽核保留時、當調查需要針對歷史事件進行隨機 SQL 查詢時，以及當維運簡單性比透過 Athena 查詢 S3 封存追蹤日誌的較低成本更有價值時，請使用 Lake。當 90 天主控台歷史記錄已足夠，或者團隊已經擁有以較低每 GB 成本查詢封存追蹤 S3 儲存貯體的 Glue + Athena 管道時，則跳過 Lake。DEA-C01 考試會透過合規性情境測試這一點 — 長期稽核需求指向 Lake。

Q6 — 當 CloudWatch 警報觸發時，我該如何構建自動化修復？

推薦模式是「警報到 EventBridge 到動作」。警報將其狀態更改事件發佈到預設 EventBridge 匯流排。EventBridge 規則對警報事件（按警報名稱或命名空間）進行模式匹配，並路由到目標 — 用於程式碼式修復的 Lambda、用於多步驟修復的 Step Functions 或用於參數化 Runbook 的 Systems Manager 自動化文件。範例：Kinesis IteratorAge 警報觸發，EventBridge 路由到 Step Functions，由其擴展取用者 Lambda 的並行度限制並發佈到 Slack Webhook。DEA-C01 考試會透過維運彈性情境測試此模式；EventBridge 是路由樞紐。

Q7 — AWS Config 與 CloudTrail 和 CloudWatch 有什麼關係？

AWS Config 記錄 AWS 資源隨時間變化的組態狀態 — 每個時間戳記的儲存貯體加密設定是什麼，上週的安全性群組規則是什麼。CloudTrail 記錄導致這些更改的 API 呼叫 — 誰在什麼時間使用哪些參數呼叫了 PutBucketEncryption。CloudWatch 記錄執行狀態指標和應用程式日誌 — 儲存貯體是否真的在使用，是否有錯誤。三者共同回答了完整的三角關係：發生了什麼 (CloudTrail)、產生的狀態是什麼 (Config)、維運影響是什麼 (CloudWatch)。對於合規性使用案例，Config 規則會自動強制執行期望狀態；對於安全性調查，CloudTrail 提供稽核追蹤；對於維運問題，CloudWatch 提供執行階段遙測。

延伸閱讀 — CloudWatch 官方 AWS 文件

權威的 AWS 來源包括 CloudWatch 使用者指南（指標、日誌、警報、儀表板）、CloudWatch Logs Insights 查詢參考、CloudTrail 使用者指南（事件類型、Lake）以及 AWS Config 開發人員指南。AWS Operations 部落格有多篇關於資料管道觀測能力模式、異常偵測設定以及 EventBridge 驅動修復的深入探討文章。AWS Well-Architected Operational Excellence 支柱深入涵蓋了與觀測能力相關的實踐。AWS Samples GitHub 存儲庫包含了用於 Glue, Kinesis 和 Redshift 監控的端到端儀表板範本。最後，Skill Builder DEA-C01 Exam Prep Standard Course 有一個專門的觀測能力模組，以情境形式講解了規範的 CloudWatch 對比 CloudTrail 的界限。