CloudWatch Metrics、Alarms 與 Dashboards

Amazon CloudWatch 是所有 AWS 工作負載的運維神經中樞，在 SOA-C02 中也是考試比重最高的單一服務。Domain 1（監控、日誌與補救）佔全卷 20%——高於其他任何 domain——而 Task Statement 1.1 明確要求考生「使用 CloudWatch 實作 metrics、alarms 與 filters」。SAA-C03 考的是設計階段「要對哪個 metric 設 alarm」，SOA-C02 考的則是「凌晨三點 alarm 觸發後該怎麼辦」：threshold 設定錯誤、instance 終止後 alarm 卡在 INSUFFICIENT_DATA、因為從未安裝 CloudWatch agent 導致記憶體 metrics 消失，以及需要橫跨三個帳號和兩個 region 才能完成事故回顧的 dashboard。

本指南從 SysOps 角度走過 CloudWatch 全流程：metrics 如何進入 CloudWatch、EC2 預設 metrics 為何永遠不含記憶體或磁碟、alarm 狀態如何轉換以及 treatMissingData 對各狀態的實際影響、何時選擇 anomaly detection 而非靜態 threshold、composite alarms 如何在故障切換期間降低 alarm 噪音，以及各類 dashboard widget 適合哪種運維視角。你也會看到反覆出現的 SOA-C02 場景：agent 未發布 metrics 的診斷流程、Auto Scaling 縮減後出現的 INSUFFICIENT_DATA、調整 datapoints-to-alarm 以阻止 ASG 反覆震盪、透過 CloudWatch 串接 Service Quotas 通知，以及作為 CloudWatch alarms 補充訊號的 AWS Health Dashboard 事件。

為什麼 CloudWatch 是 SOA-C02 的核心

官方 SOA-C02 Exam Guide v2.3 在 Task Statement 1.1 下列出六項技能，其中五項出現 CloudWatch：從 CloudWatch Logs 與 Logs Insights 收集日誌、使用 CloudWatch agent 收集 metrics 與日誌、建立 CloudWatch alarms、建立 metric filters、建立 CloudWatch dashboards，以及透過 SNS、Service Quotas、CloudWatch alarms 和 AWS Health events 設定通知。Task Statement 1.2 則在上層疊加補救動作——alarm 觸發後，EventBridge 或 SNS 將其路由，再由 Systems Manager Automation 或 Lambda 執行修正動作。CloudWatch 是所有這些流程的唯一事實來源。

在 SysOps 層級，問題的框架是運維而非架構設計。SAA-C03 問「應該對 Auto Scaling group 的哪個 CloudWatch metric 設 alarm？」SOA-C02 問「ASG 正在反覆震盪——instance 每五分鐘就啟動再終止，alarm 不斷在 OK 與 ALARM 之間振盪，你要改什麼？」答案很少是換一個 metric；而是 Datapoints to alarm、evaluation periods、scaling cooldown 或 treatMissingData。CloudWatch Metrics、Alarms 與 Dashboards 是所有後續 SOA-C02 主題的插槽：ELB health checks（Domain 2）、Auto Scaling target tracking policies（Domain 2）、CloudFormation stack 事件監控（Domain 3）、KMS key 使用量追蹤（Domain 4）、VPC Flow Log metric 萃取（Domain 5）、EBS BurstBalance 與 RDS Performance Insights 基準（Domain 6）。

白話文解釋 CloudWatch Metrics, Alarms, and Dashboards

CloudWatch 的術語堆疊很快。三個類比能讓這些概念變得具體好記。

類比一：醫院急診分診中心

CloudWatch 是你 AWS 工作負載的醫院急診分診中心。Metrics 是生命徵象——心跳（CPU）、血壓（NetworkOut）、呼吸頻率（DiskWriteOps）——從每位病患（resource）持續串流而來。Namespaces 是病房，將相似病患分門別類：心臟科（AWS/RDS）、外科（AWS/EC2）、兒科（AWS/Lambda）。Dimensions 是病患識別手環，精確標記這組生命徵象屬於哪個人。Alarms 是床邊監視器，預先設定 threshold——若心跳連續三次超過 120 下，護理站就會被呼叫。Alarm 狀態對應急診分診顏色：綠色（OK，病患穩定）、紅色（ALARM，需立即介入）、灰色（INSUFFICIENT_DATA，監視器停止回報——也許接線鬆了，也許病患暫時離開，但我們無從判斷）。treatMissingData 設定是灰色病患的常備醫囑：是假設他們安然無恙（notBreaching）、假設他們處於危急狀態（breaching）、維持上一次的狀態（ignore）、還是把這段空缺視為 threshold 評估時的缺失資料（missing）？Dashboards 是中央指揮監控牆，一眼盡覽所有病患的生命徵象。Composite alarms 是主治醫師的臨床判斷——只有在心跳過快而且血氧偏低時才通知家屬，單一指標異常隨時都會發生。

類比二：智慧型恆溫器與 Anomaly Detection

靜態 threshold alarm 是老式壁掛溫度計——房間超過 28 度就開冷氣，不分季節、不論時段。CloudWatch anomaly detection alarm 是現代智慧恆溫器——它學習「這棟公寓在平日下午，室溫通常在 26 到 29 度之間漂移，但週末早上冷氣關著、32 度也屬正常」，只有當現實偏離學習出來的正常區間才發出警示。對 SOA-C02 考生而言，這就是每週一早上九點固定收到誤報（靜態 threshold 誤判流量高峰）和只在週一高峰看起來異常地不同於過去才收到通知（anomaly detection band）之間的差異。

類比三：社區管委會的火警系統

CloudWatch dashboard 是社區管委會辦公室的火警總盤。Metric widget 是其中一個煙霧偵測器指示燈，顯示當前感測器讀數。附迷你趨勢圖的單值 widget 是指示燈加上最近五分鐘的微型圖表。Alarm status widget 是一排狀態燈，任何住戶一觸發就立刻從綠轉紅。內嵌 Logs Insights 查詢的 log widget 是列印出最近 50 條感測器訊息的紙帶。跨帳號跨 region dashboard 是保全公司的多社區指揮中心——保全公司在一個螢幕上監看數十個社區，他們與每棟大樓的管委會簽署了分享協議（CloudWatch-CrossAccountSharingRole），才能從遠端看到各社區的總盤。

CloudWatch Metrics 基礎：Namespaces、Dimensions 與 Resolution

在理解 alarms 之前，你需要對 metric 如何進入 CloudWatch 以及如何被識別有一個精確的心智模型。

Namespaces — 頂層容器

Namespace 是 metrics 的第一層分組。AWS 保留 AWS/ 前綴給服務發布的 metrics——AWS/EC2、AWS/RDS、AWS/ApplicationELB、AWS/Lambda、AWS/S3，以及更多。自訂 metrics 住在你自選的任何 namespace；CloudWatch agent 預設發布到 CWAgent。Namespaces 是隔離的：AWS/EC2 中名為 CPUUtilization 的 metric 與 MyApp/Prod 中同名的 metric 是不同的時間序列，即使兩者描述同一件事。

Dimensions — metric 上的識別標籤

Dimension 是將 metric 固定到特定 resource 的名稱-值對。AWS/EC2 以 InstanceId=i-0abc123、AutoScalingGroupName=web-asg 或 InstanceType=m5.large 等 dimensions 公開 CPUUtilization。每個唯一的 dimensions 組合就是一條獨立的 metric——可獨立設定 alarm 和繪圖。CloudWatch 每個 metric 最多支援 30 個 dimensions，但每個唯一組合都算作一個獨立的 metric 並分別計費，因此 SysOps 工程師必須謹慎規劃。

Resolution — standard vs high-resolution

Standard-resolution metrics 以 60 秒粒度儲存。所有 AWS 發布的 metrics 預設都是 standard resolution，但有一個例外，下文會說明。High-resolution metrics 是以 StorageResolution 為 1 秒發布的自訂 metrics；可以接受 1、5、10 或 30 秒間隔的資料點，並能以最短 10 秒的 period 設定 alarm。High-resolution metrics 費用較高，應僅保留給一分鐘延遲就會掩蓋問題的工作負載（即時交易、遊戲 session 品質、IoT telemetry）。

Metric 保留期

CloudWatch 自動將較舊的 metric 資料捲成更粗粒度的 buckets：

• Sub-minute（high-resolution）資料保留 3 小時。
• 1-min 資料保留 15 天。
• 5-min 資料保留 63 天。
• 1-hour 資料保留 15 個月（455 天）。

超過 15 個月後，metric 資料不再保存。若你的 SysOps 職責需要更長的保留期用於容量規劃，可透過 metric streams 匯出到 S3，或排程呼叫 GetMetricData 後自行儲存。

CloudWatch Agent：在 EC2 與地端主機安裝以取得 OS 層級 Metrics

SOA-C02 上最常考的運維陷阱，就是 EC2 預設由 hypervisor 發布的 metrics 永遠不包含作業系統內部的記憶體或磁碟用量。Hypervisor 無法看到 guest OS 如何使用已分配的 RAM。若要收集記憶體、swap、磁碟已用量和行程層級的 metrics，你必須在每個 instance 內部安裝 CloudWatch agent，並授予其呼叫 cloudwatch:PutMetricData 的權限。

Agent 提供的功能

統一版 CloudWatch agent 可在 Amazon Linux 2 / 2023、Ubuntu、RHEL、SUSE、Windows Server，以及地端 Linux/Windows 主機上執行。它收集：

• Linux metrics：mem_used_percent、swap_used_percent、每個掛載點的 disk_used_percent、processes_running、透過 procstat 取得的網路與 TCP 狀態計數器、collectd 整合。
• Windows metrics：對等的 Performance Counter——Memory % Committed Bytes In Use、LogicalDisk % Free Space、Paging File % Usage、自訂 counter sets。
• 自訂應用程式 metrics——透過 StatsD（UDP）或 collectd 整合。
• Log 檔案——應用程式日誌、系統日誌、IIS 日誌——推送到 CloudWatch Log Groups（詳見 Logs 主題）。

Agent 預設發布到 CWAgent namespace（可自訂）。預設 dimensions 包含 InstanceId，以及依 metric 而定的 host、cpu、device 和 path。

安裝路徑

三條運維安裝路徑：

1. AWS Systems Manager State Manager + Run Command + AWS 管理的 AmazonCloudWatch-ManageAgent document 是 SOA-C02 認可的艦隊規模安裝與設定更新路徑。
2. EC2 Image Builder 將 agent 烘焙進 golden AMI，適合情境強調「每個新 instance 在首次開機時就必須具備監控」的答案。
3. User-data script 呼叫平台專屬安裝程式，適合臨時或非 Systems Manager 環境。

IAM 需求（最常見的失敗點）

Instance 需要一個 IAM instance profile，授予 agent 兩組權限：

• CloudWatchAgentServerPolicy——管理型政策，授予 cloudwatch:PutMetricData、ec2:DescribeVolumes、ec2:DescribeTags、logs:PutLogEvents、logs:CreateLogGroup、logs:CreateLogStream、logs:DescribeLogStreams、ssm:GetParameter（用於從 Parameter Store 取得 agent 設定）。
• AmazonSSMManagedInstanceCore——若你希望 Systems Manager Run Command 和 State Manager 管理 agent 生命週期，則需要此政策。

若缺少任一政策，agent 會執行但靜默地無法發布——你預期的 metric 永遠不會出現在 console 上。SOA-C02 例行考測這個確切的模式。

SysOps 考生看到 AWS/EC2 中有 CPUUtilization、NetworkIn、NetworkOut、DiskReadOps、DiskWriteOps、StatusCheckFailed_System 和 StatusCheckFailed_Instance，便以為「DiskWriteOps」涵蓋磁碟滿載監控。事實並非如此——該 metric 只計算 EBS volume 的 I/O 操作次數。若要對檔案系統達到 90% 設定 alarm，你必須安裝 CloudWatch agent，並對 CWAgent namespace 的 disk_used_percent 設 alarm。記憶體使用率根本不由 hypervisor 公開。參考：https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html ::

地端主機

同一個 agent 可在透過 Systems Manager 以混合式受管 instance 形式登錄的地端伺服器上執行。主機需要一個 IAM 服務角色（不是 instance profile，因為它不是 EC2）和一個 Systems Manager 啟動碼。登錄後，相同的 cloudwatch:PutMetricData 權限適用，metrics 以你選擇的 namespace 和 dimensions 進入 CloudWatch。SOA-C02 可能會問「在單一 CloudWatch dashboard 上同時監控一批地端 Linux 伺服器和 EC2」——答案就是統一版 CloudWatch agent + SSM hybrid activation。

EC2 預設 vs 詳細監控：5-Minute vs 1-Minute 粒度

即使在 agent 加入之前，EC2 本身就能以兩種節奏發布 hypervisor 層級的 metrics。

預設（基本）監控

預設監控自動啟用且免費。它以 5-minute（300 秒）period 發布七個核心 EC2 metrics：CPUUtilization、NetworkIn、NetworkOut、NetworkPacketsIn、NetworkPacketsOut、DiskReadOps、DiskWriteOps、DiskReadBytes、DiskWriteBytes，以及 1-minute 的 StatusCheckFailed_System / StatusCheckFailed_Instance / StatusCheckFailed（這些狀態檢查是例外——即使在預設監控下也永遠是 1-minute）。

詳細監控

詳細監控以 1-minute（60 秒）period 發布標準 EC2 metrics。它是按 instance 選擇加入、按 metric 按月計費，並在以下情況時必須開啟：

• Auto Scaling target tracking 或 step scaling policies 使用 1-minute period——多數生產環境的 scaling 設定都希望 metric 來源 instance 開啟詳細監控。
• Alarm 需要 1 分鐘或更短的 evaluation period。
• Dashboard 需要 1-minute 粒度的近即時圖表用於 SLO 審查。

詳細監控可透過 EC2 console、launch template、RunInstances API 或標籤式補救按 instance 啟用。它不會新增記憶體、磁碟使用率或任何新 metric——它只改變現有 hypervisor 層級 metrics 的 period。對未安裝 CloudWatch agent 的 instance 啟用詳細監控，對記憶體和磁碟用量仍是盲目的。

Metric Math：以表達式組合 Metrics

Metric math 讓你無需發布自訂 metrics，就能組合、轉換並從既有 CloudWatch metrics 衍生新值。Metric math 表達式在伺服器端評估，因此不額外計費，並在 alarm 或 dashboard 時隨需執行。

常用 metric math 模式

• 錯誤率：(errors / requests) * 100 從兩個計數器計算百分比。ALB 的經典模式為 100 * (m_5xx + m_target_5xx) / m_request_count。
• 跨 instance 加總：SUM(METRICS()) 將 Auto Scaling group 中每個 instance 的 CPUUtilization 聚合，解決 per-instance dimension 造成的視角破碎問題。
• 剩餘可用容量：100 - mem_used_percent 對可用記憶體而非已用記憶體設 alarm。
• Anomaly band：ANOMALY_DETECTION_BAND(m1, 2) 以兩個標準差為 metric 包上一個學習出來的上下限帶。
• 填補缺失值：FILL(m1, 0) 以零替代缺失資料（有時是稀疏 metric 的正確選擇）。
• 變化率：RATE(m1) 計算計數器的每秒變化量。

在 alarms 中使用 metric math

CloudWatch alarm 可監看原始 metric 或 metric math 表達式。Alarm 引用你定義的 metric IDs（m1、m2），再設定 ThresholdMetricId: e1 指向表達式。兩個常見的 SOA-C02 模式：

• SLO 的 composite metric alarm——錯誤率在 5 分鐘內超過 1% 時觸發 alarm。表達式 (m1 / m2) * 100 > 1，其中 m1 = HTTPCode_Target_5XX_Count，m2 = RequestCount。
• 批次艦隊的容量型 alarm——當艦隊整體（加總）的可用 CPU 低於 threshold 時觸發。

Alarm 狀態：OK、ALARM、INSUFFICIENT_DATA 與 treatMissingData

CloudWatch alarms 任何時刻都精確地處於三種狀態之一。

• OK — 最近幾個 evaluation periods 有資料，且 metric 依 M-of-N 規則未突破 threshold。
• ALARM — 最近幾個 evaluation periods 依 M-of-N 規則突破了 threshold。
• INSUFFICIENT_DATA — 資料不足以做出判斷：alarm 剛建立，或 metric 在 evaluation 視窗內停止發布。

狀態轉換會觸發 alarm actions——OK -> ALARM 呼叫 AlarmActions，ALARM -> OK 呼叫 OKActions，進入 INSUFFICIENT_DATA 則呼叫 InsufficientDataActions。每組都是可獨立設定的 action ARN 列表（通常是 SNS topics，但也包含 EC2 stop/reboot/recover、Auto Scaling policies、Systems Manager，以及透過 EventBridge 的 Lambda）。

Period vs evaluation periods vs datapoints to alarm

三個數值設定決定何時發生狀態轉換：

• Period（例如 60 秒）：CloudWatch 為 metric 計算單一統計值（Average、Sum、p99、Max、Min）的 bucket 大小。
• Evaluation periods（常縮寫為 N）：CloudWatch 檢查多少個最近的 periods。
• Datapoints to alarm（常縮寫為 M）：那 N 個 periods 中需要有多少個突破 threshold 才能觸發 alarm（M-of-N 規則）。

常見的 SysOps 層級設定是 Period = 60、Evaluation periods = 5、Datapoints to alarm = 3——意思是當最近 5 個 1-minute 資料點中有 3 個突破時才觸發 alarm。這比 M = N = 1（單一突破期就 alarm）抗震盪得多，但仍能在五分鐘內偵測到持續性問題。

treatMissingData 模式

當某個 period 完全沒有資料點（metric 未發布）時，CloudWatch 必須決定怎麼做。四種模式：

• missing（預設）——缺失的 period 從 M-of-N 評估中排除。若太多 periods 缺失，alarm 轉換到 INSUFFICIENT_DATA。
• notBreaching——缺失的 period 被視為未突破的值。Alarm 傾向維持在 OK。
• breaching——缺失的 period 被視為突破的值。Alarm 傾向觸發。
• ignore——alarm 狀態鎖定在當前值；缺失資料不改變它。

正確選擇取決於 alarm 驅動的動作：

• Auto Scaling scale-out alarm：通常應設為 notBreaching。instance 終止後 metric 停止發布；你不希望把靜默解讀為「CPU 高，需要 scale out」。
• 應用程式 heartbeat alarm：應設為 breaching。靜默表示應用程式停止發布 heartbeat——那就是你想偵測的故障。
• EC2 recovery 的 status check failed alarm：missing（預設）即可——如果 instance 消失了就沒有東西可以復原，INSUFFICIENT_DATA 不會呼叫 recover action。
• 長時間執行的批次工作 alarm：有時 ignore 是正確的，讓 alarm 在預期的資料空缺期間維持 OK 狀態。

Anomaly detection alarms

靜態 threshold 不適合具有每日或每週季節性的流量。CloudWatch anomaly detection 會在 metric 的歷史資料（通常 14 天）上訓練一個機器學習模型，並產生一個 anomaly band——每個時段的預期值學習包絡線。Alarms 可在 metric：

• 向任一側越出 band 時觸發（GreaterThanUpperThreshold OrLowerThanLowerThreshold）。
• 僅超過上限時觸發（典型用於延遲或錯誤數）。
• 僅跌破下限時觸發（典型用於請求量——沉默就是故障）。

Band 寬度以標準差設定（預設 2）。更寬的 band 減少誤報但提高偵測延遲。Anomaly detection 按 metric 啟用，可以標記排除期間，讓模型學到已排程的高峰（大特賣、週一早上九點流量）不是異常。

Composite Alarms：組合多個子 Alarms

Composite alarm 是一個由其他 alarms 的 Boolean 表達式計算狀態的 alarm。一般 alarm 監看 metric，composite alarm 則監看 ALARM("alarm-name")、OK("alarm-name") 和 INSUFFICIENT_DATA("alarm-name") 謂詞，以 AND、OR 和 NOT 組合。

Composite alarms 存在的原因

真實工作負載會產生 alarm 風暴：當可用區發生故障時，數十個 per-instance alarms 同時觸發，值班人員的收件匣爆炸。Composite alarms 將噪音折疊成單一的高層級訊號：

• ALARM(asg-cpu-high) AND ALARM(asg-error-rate-high)——只有在運算飽和度和錯誤率都升高時才呼叫；任一單獨升高都是正常流量。
• (ALARM(rds-cpu) OR ALARM(rds-iops)) AND ALARM(rds-replica-lag)——只有在資料庫同時承受壓力且開始落後時才呼叫，忽略短暫高峰。
• NOT OK(maintenance-window)——排程維護期間抑制呼叫。

設定機制

Composite alarm 以 ARN 或名稱在同一個帳號和 region 內引用子 alarms。子 alarms 本身也可以是 composite（最多巢狀 10 層）。Composite alarm 有自己的 AlarmActions、OKActions 和 InsufficientDataActions ARNs——通常是高保真呼叫用的 SNS topic。關鍵在於，你可以設定 composite alarm 在其處於 ALARM 狀態時抑制子 alarm actions，讓值班人員只收到一則通知而非五十則。

Suppressor alarms

Composite alarm 可指定一個 suppressor alarm 和一個等待期。當 suppressor 處於 ALARM 狀態時，composite alarm 不管規則如何都不會轉換到 ALARM。常見模式：在計畫性視窗期間翻轉到 ALARM 的 MaintenanceWindow alarm，抑制所有運維 composite alarms，讓修補週期不會呼叫任何人。

CloudWatch Dashboards：Widgets、跨帳號、跨 Region 與分享

CloudWatch dashboard 是一個可自訂、JSON 為底的 widgets 頁面，視覺化跨帳號、跨 region 的 metrics、alarms、logs 和 metric math 表達式。Dashboard 是 SysOps 團隊的情境感知工具——事故發生時值班人員打開的那個 URL。

Widget 類型

• Line widget——一個或多個 metrics 的經典時間序列圖；支援左右 Y 軸和覆蓋標註。
• Stacked area widget——與 line 相同但堆疊，適合艦隊層級的視覺化。
• Number widget（單值）——當前值加上迷你趨勢圖；適合「現在有多少 active alarms」。
• Gauge widget——圓形儀表顯示值在定義範圍內的位置；適合 SLO 消耗速率。
• Bar / pie——類別比較。
• Alarm status widget——依當前狀態色彩標記的 alarm 列表；事故 dashboard 最重要的 widget。
• Text widget——Markdown 格式的 runbook 連結和擁有者標籤。
• Logs widget——在 dashboard 中嵌入 CloudWatch Logs Insights 查詢結果。
• Custom widget（Lambda-backed）——由 Lambda 函數回傳的任意內容（表格、圖片、JSON）。適合按標籤分類的成本面板或 AWS Health 事件摘要。

跨帳號、跨 region dashboards

單一 dashboard 可顯示來自多個 AWS 帳號和 regions 的資料。需要先完成兩個前提：

1. 分享帳號（持有來源 metrics 的帳號）安裝 CloudWatch-CrossAccountSharingRole IAM role，信任政策允許監控（查看）帳號來承擔它。這在 CloudWatch console 的 Settings 中一鍵完成。
2. 監控帳號在 Settings → "Manage source accounts" 下登錄分享帳號。

設定完成後，新增 widget 時只需從下拉選單選擇帳號。SOA-C02 常問「將 12 個帳號的 metrics 整合到一個運維 dashboard」——答案是透過 sharing role 的跨帳號 dashboards，而非自訂 Lambda 聚合。

跨 region widgets 的 dashboard JSON 每個 widget 包含 region 欄位；同一個 metric 圖表可以並排顯示 us-east-1 和 eu-west-1。跨 region 如果帳號間已互信，則不需要額外的 IAM。

對外分享 dashboards

Dashboard 可透過三種選項分享給沒有 AWS console 存取權的使用者：

• 公開連結（可選擇加上電子郵件/Google/SAML SSO 登入）——適合給高階主管查看。
• 特定電子郵件地址加上登入。
• 透過 Cognito identity pools 的第三方 SSO。

分享出去的 dashboards 是唯讀的，遵循來源帳號的資料權限。

Service Quotas 通知：將 CloudWatch 與 Service Quotas 整合

AWS Service Quotas 是顯示帳號中 AWS 服務當前用量和限制的服務。SOA-C02 明確考測在用量接近配額時設定通知。

運作方式

對於支援的配額（多數服務配額均支援，包含 EC2 vCPUs、EBS volume 數量、Lambda concurrent executions、VPC 數量、每個 VPC 的 security groups），Service Quotas 會在 AWS/Usage namespace 中向 CloudWatch 發布 metric。你接著對該用量 metric 建立一個 CloudWatch alarm，threshold 以配額百分比表示——通常 80% 作為黃色警示，95% 作為紅色警示。

Alarm action 是一個通知 SysOps 團隊的 SNS topic。團隊隨後（a）透過 Service Quotas 申請配額增加、（b）清理未使用的資源以釋放配額，或（c）重構至不消耗該配額的不同服務。

配額申請流程

配額增加申請由 Service Quotas 本身或 AWS Support 處理。運維成熟度要求你在 80% 時就設定 alarm，讓你有時間在飽和前提交申請，而不是在 100% 時生產環境已經出問題才行動。

Service Quotas vs Trusted Advisor

Trusted Advisor 的「Service Limits」檢查涵蓋較少、較舊的一組配額，且每日更新一次。Service Quotas 是現代、即時、可程式化的來源。SOA-C02 對所有「在接近服務限制時發出警示」的問題偏好 Service Quotas。

Health Dashboard 整合：AWS Health Events vs CloudWatch Alarms

CloudWatch alarms 偵測的是你的運維問題。AWS Health Dashboard 事件告訴你的是影響你帳號的 AWS 運維問題——計畫性維護、服務中斷、安全公告，以及生命週期異動（例如即將淘汰的 AMI 退役）。成熟的監控策略會疊加這兩種訊號。

兩種 AWS Health 介面

• Service Health Dashboard（前身為 status.aws.amazon.com）：公開、依 region、所有客戶均可見。
• AWS Health Dashboard（前身為 Personal Health Dashboard）：按帳號、帳號專屬，包含針對你的資源的排程事件（例如：instance ID i-0abc123 的 EC2 instance 將於下週二退役）。

SOA-C02 考試所說的「Health events」指的是 AWS Health Dashboard。

將 AWS Health 接入 alarm pipeline

AWS Health 以 aws.health 事件來源將事件發布到 EventBridge。SysOps 團隊建立 EventBridge rules 來匹配事件類別（scheduledChange、issue、accountNotification），並路由到：

• 用於人工通知（電子郵件、SMS、聊天）的 SNS topic。
• 開立 Jira 工單或執行 Systems Manager Automation runbook 的 Lambda function。
• 在 CloudWatch alarms 旁邊呈現當前 Health 事件的 CloudWatch dashboard custom widget。

若要取得整個組織的可見性，可啟用 AWS Health Organizational View（需要 AWS Organizations），讓每個成員帳號的事件聚合在管理帳號或委派管理員帳號中。

何時使用哪個

場景模式：EC2 記憶體使用率從未出現在 CloudWatch Console

這是 SOA-C02 的典型疑難排解場景。操作手冊如下：

1. 確認 namespace。 記憶體 metrics 位於 CWAgent namespace，而非 AWS/EC2。如果 SysOps 工程師在搜尋 AWS/EC2，永遠找不到它。
2. 確認 agent 已安裝並執行中。 透過 SSH 或 Session Manager 登入 instance：sudo systemctl status amazon-cloudwatch-agent（Linux）或 Get-Service AmazonCloudWatchAgent（Windows）。如果服務不存在，表示 agent 從未安裝——使用 Systems Manager Run Command 搭配 AWS-ConfigureAWSPackage 安裝 AmazonCloudWatchAgent。
3. 確認 agent 有設定檔。 Agent 沒有設定就不會做任何事。設定為 /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json 的 JSON，或從 SSM Parameter Store 取得。使用精靈 amazon-cloudwatch-agent-config-wizard 互動式建立，或從 Parameter Store 推送。
4. 確認 IAM instance profile。 Instance 必須有附加 CloudWatchAgentServerPolicy 的角色。透過 EC2 console → Instance → Security 標籤 → IAM Role 確認。若缺少，附加它（不需要重新啟動 instance，但 agent 可能需要重啟：sudo systemctl restart amazon-cloudwatch-agent）。
5. 確認 agent log。 /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log 會顯示發布失敗。尋找 AccessDenied（IAM 問題）、NetworkUnreachable（security group / NACL / VPC endpoint）或 ConfigError（格式錯誤的 JSON）。
6. 確認網路路徑。 若 instance 位於沒有 NAT gateway 的私有子網路，你需要 monitoring.region.amazonaws.com（CloudWatch metrics）的 VPC endpoint，讓 agent 能私下存取 API。

依頻率排列的最常見根本原因：IAM role policy 缺失、agent 設定 JSON 缺失或錯誤、agent 已安裝但未啟動，以及私有子網路缺少 VPC endpoint。

場景模式：Instance 終止後 Alarm 卡在 INSUFFICIENT_DATA

另一個 SOA-C02 典型場景。Auto Scaling group 在縮減時終止一個 instance。監看該 instance 的 per-instance CPU alarm 進入 INSUFFICIENT_DATA 並停在那裡，因為再也沒有資料點到來。Alarm 的 treatMissingData 模式決定接下來會發生什麼：

• missing（預設） — alarm 永久停留在 INSUFFICIENT_DATA。對診斷用 alarms 通常可接受。
• notBreaching — alarm 轉換回 OK。適合 Auto Scaling scale-out alarms，讓已終止的 instance 不會持續觸發 scale-out actions。
• breaching — alarm 轉換到 ALARM。僅在靜默真的代表故障時才適用（例如 heartbeat metric）。
• ignore — alarm 維持在之前的狀態。

修法很少是「刪除 alarm」。正確答案通常是：

1. 確認 alarm 的用途（診斷用、驅動動作，或呼叫人員）。
2. 據此選擇 treatMissingData。
3. 若 alarm 針對的是穩定資源（ASG 層級的 metric 如 GroupInServiceInstances，而非 per-instance metric），改用 ASG 層級的 metric，讓 alarm 不因 instance 終止而成為孤兒。

對於 ASG，標準模式是：以 AWS/EC2 CPUUtilization 搭配 dimension AutoScalingGroupName=web-asg（而非 InstanceId）設 alarm，如此 metric 就能在整個艦隊上聚合，並在 instance 流動中存活。

常見陷阱：標準 EC2 Metrics 與詳細監控混淆

SOA-C02 的持續性混淆：考生把「詳細監控」與「更多 metrics」混為一談，因為詳細這個詞暗示更多。它不是。詳細監控只是把現有 hypervisor metrics 的發布 period 從 5 分鐘改為 1 分鐘。它新增零個 metric 類型。記憶體、swap、磁碟已用百分比和行程數，完全來自 CloudWatch agent，不論是否開啟詳細監控都一樣。詳細監控還按 metric 按月計費，因此在 200 個 instance 的艦隊上啟用它會產生你應該能說明的帳單影響。

清楚的心智區隔：

• 更頻繁地取得現有 metrics 的資料 → 啟用詳細監控。
• 更多 metric 類型（記憶體、磁碟使用量、行程） → 安裝 CloudWatch agent。
• 自訂應用程式 metrics（佇列深度、業務 KPI） → 透過 PutMetricData API 或透過 agent 的 StatsD/collectd 發布。

常見陷阱：High-Resolution 自訂 Metric 的費用

High-resolution metrics 很誘人——1 秒粒度、10 秒 alarms——但費用明顯較高。每個 high-resolution metric 按 per-metric 費率計費，high-resolution alarms 也比 standard alarms 貴（10 秒 alarm SKU vs 60 秒 SKU）。把每個 metric 都設為 high-resolution 以「保留選項」的 SysOps 工程師，可能讓 CloudWatch 帳單暴增 10 到 60 倍。考試正確規則：high-resolution 僅用於一分鐘延遲就會掩蓋問題的 metrics——即時交易、遊戲、IoT telemetry——其他地方一律使用 standard resolution。

常見陷阱：Metric 發布延遲

CloudWatch 不是即時的。AWS 發布的 metrics 通常在底層事件發生後 1–2 分鐘才到達。自訂 PutMetricData 幾秒內到達，但 alarm 評估引擎仍需等 period 關閉才進行評估。1-minute period 加 1 evaluation period 的 alarm，通常在突破條件出現後 60–120 秒才觸發，而非立即。SOA-C02 有時會問「團隊需要在 30 秒內偵測到故障並觸發補救」——誠實的答案是 CloudWatch alarms 無法保證 30 秒以內的偵測；需要那種速度就得使用應用程式層級的 health checks、ELB health checks（有自己獨立於 CloudWatch 的 threshold），或 Route 53 health checks，視架構而定。

SOA-C02 vs SAA-C03：運維視角的差異

SAA-C03 和 SOA-C02 都考 CloudWatch，但視角不同。

SAA 考生選擇 metric；SOA 考生正確設定 alarm、在出問題時疑難排解，並在事故期間操作 dashboard。

考試訊號：如何辨識 Domain 1.1 的題目

SOA-C02 的 Domain 1.1 題目遵循可預測的模式。認出它們後，每題的作答時間會大幅縮短。

• 「metric 消失了」 — 答案涉及 CloudWatch agent、IAM 權限缺口或 VPC endpoint 缺失。記憶體和磁碟 metrics 幾乎必定是 agent 問題。
• 「alarm 觸發太頻繁 / 太不靈敏」 — 答案調整 Datapoints to alarm、Evaluation periods 或 period 本身。有時答案是以 anomaly detection 取代靜態 threshold。
• 「alarm 卡在 INSUFFICIENT_DATA」 — 答案是 treatMissingData 設定，通常是 ASG alarms 的 notBreaching。
• 「值班人員被 alarms 淹沒」 — 答案是帶有子 alarm action 抑制的 composite alarms。
• 「運維需要跨帳號和 region 的可見性」 — 答案是透過 sharing role 的跨帳號跨 region CloudWatch dashboards。
• 「接近服務限制」 — 答案是 Service Quotas + CloudWatch alarm 設在 80% + SNS 通知。
• 「錯過了 AWS 端的維護」 — 答案是對 aws.health 事件設 EventBridge rule 路由到 SNS / dashboard。
• 「計算衍生值（錯誤率、可用容量）」 — 答案是 metric math，而非自訂 metric。

決策矩陣 — 各 SysOps 目標對應的 CloudWatch 構件

考試期間使用這份速查表。

常見陷阱總整理 — CloudWatch Metrics、Alarms 與 Dashboards

每次 SOA-C02 考試都會出現其中兩三個干擾選項。

陷阱 1：詳細監控新增新的 metrics

它只改變現有 hypervisor metrics 的 period。記憶體、磁碟使用量和行程 metrics 仍需要 CloudWatch agent。

陷阱 2：treatMissingData=missing 讓 alarm 維持有用

missing 只是從 M-of-N 評估中排除缺失 periods；若所有 periods 都缺失，alarm 就停在 INSUFFICIENT_DATA，永遠不會到達 OK 或 ALARM。對於驅動動作的 alarms，請刻意選擇 notBreaching 或 breaching。

陷阱 3：每個 instance 一個 alarm 能夠擴展

Per-instance alarms 在 instance 終止後會成為孤兒 alarm。改用 ASG 層級的 dimensions（AutoScalingGroupName），讓 metric 在整個艦隊上聚合。

陷阱 4：Alarm period 等於 evaluation period

兩者是獨立的。Period 是統計值的 bucket 大小；evaluation periods 是檢查的 bucket 數量。混淆兩者會產生觸發太快或太慢的 alarms。

陷阱 5：衍生值使用自訂 metric

如果值能從現有 metrics 計算，使用 metric math。自訂 metrics 按 metric 按 dimension 計費，對比率和聚合來說是不必要的。

陷阱 6：以 Console 建立的 dashboards 作為事實來源

Console dashboards 會產生偏移、可能被意外刪除，且無法被 review。改用 Git 中的 CloudFormation AWS::CloudWatch::Dashboard JSON 管理 dashboards。

陷阱 7：所有 metrics 都使用 high-resolution

費用是 standard 的 10x 到 60x。僅保留給真正需要 sub-minute 的 metrics。

陷阱 8：在服務配額的 100% 設定 alarm

突破 100% 時，生產環境已經故障。在 80% 設定 alarm，留時間提交增加申請。

陷阱 9：預期 CloudWatch 在幾秒內偵測到故障

AWS metrics 在事件發生後 1–2 分鐘才到達；alarm 評估還要加上 period 長度。Sub-minute 偵測需要應用程式層級、ELB 或 Route 53 health checks。

陷阱 10：忘記 AWS Health Dashboard

CloudWatch 只知道你的工作負載說了什麼。AWS 端的維護和服務問題來自透過 EventBridge aws.health 事件的 AWS Health。

FAQ — CloudWatch Metrics、Alarms 與 Dashboards

Q1：Period 與 Evaluation Periods 有什麼差別？

Period 是 bucket 大小——CloudWatch 在計算 metric 的單一統計值（Average、Sum、Max、Min、p99）前要等多久。常用值為 60、300 或更高的秒數。Evaluation periods 是計數 N，是 alarm 與 Datapoints to alarm（M）一起用來套用 M-of-N 規則的最近 buckets 數量。所以 Period = 60、Evaluation periods = 5、Datapoints to alarm = 3 表示：每分鐘，檢查最近 5 個 1-minute 平均值中是否有 3 個突破。Period 設定解析度；evaluation periods 設定規則套用的視窗。混淆兩者是 SOA-C02 上最常見的 alarm 調整錯誤。

Q2：我的 CloudWatch alarm 為何永遠停在 INSUFFICIENT_DATA？

INSUFFICIENT_DATA 表示 alarm 因 evaluation 視窗內的 metric 資料不足而無法判斷。三個典型原因：（a）metric 完全未發布——安裝 CloudWatch agent、修正 IAM role，或確認 VPC endpoint；（b）metric 是稀疏的——對 scale-out alarms 設定 treatMissingData 為 notBreaching，對 heartbeat alarms 設為 breaching；（c）來源資源已終止——改用 ASG 層級或服務層級的 dimension 取代 per-instance dimension，讓 metric 在 instance 流動中存活。正確的修法取決於 alarm 的用途，沒有一體適用的預設值。

Q3：如何在跨帳號 dashboards 和自訂 Lambda 聚合器之間選擇？

大多數情況使用跨帳號 dashboards——一鍵設定、無需維護 Lambda 程式碼、同一設定支援跨 region，且與跨帳號 metric math 相容。僅在需要將聚合資料推送到第三方 SaaS（Datadog、Grafana Cloud）、套用 AWS 原生不支援的業務邏輯（例如跨帳號的加權 SLO），或需要儲存超過 CloudWatch 15 個月保留期的長期摘要時，才使用自訂 Lambda 聚合器。SOA-C02 偏好 AWS 原生答案；只在題目明確排除跨帳號 dashboards 時才選自訂 Lambda。

Q4：anomaly detection 何時勝過靜態 threshold，反之亦然？

Anomaly detection 在 metric 具有每日或每週季節性時勝出——公共網站流量、電商結帳量、登入率。模型學習「週一早上九點的正常和週日凌晨三點的正常不同」，只對脫離學習正常值的情況發出 alarm。靜態 threshold 在 metric 有不隨時段變化的絕對意義時勝出——disk_used_percent > 90、replication lag seconds > 60、5xx error count > 100。SOA-C02 的暗示用語是「厭倦了預期高峰的誤報」→ anomaly detection；「SLO 要求延遲低於 200ms」→ threshold 設在 200 的靜態 alarm。

Q5：M-of-N 規則（Datapoints to alarm）實際如何評估？

CloudWatch 檢查最近的 N 個 evaluation periods，計算其中有多少個突破 threshold。如果至少 M 個突破，alarm 轉換到 ALARM（或維持在那裡）。如果最近 N 個 periods 中突破的少於 M 個，alarm 轉換到 OK。缺失 periods 依 treatMissingData 處理。M-of-N 規則將靈敏度（低 M）與持續條件偵測（高 N）解耦：M=3, N=5 意味著「在過去幾分鐘內突破相當頻繁」，能抵抗單分鐘高峰；M=1, N=1 意味著「在下一次突破時立即 alarm」，僅適合 status checks 等二元訊號。

Q6：將 alarm 傳送到 Lambda function 的最清晰方式是什麼？

兩條路徑。（a）簡單方式：alarm action → SNS topic → Lambda subscription。（b）健壯方式：alarm action → SNS topic，加上 EventBridge rule 監聽 aws.cloudwatch 事件來源中的 CloudWatch Alarm State Change → Lambda target。EventBridge 路徑提供重試、死信佇列和解耦，無需自行管理 SNS subscription。SOA-C02 對任何「自動化補救」答案偏好 EventBridge 路徑，因為它能自然地與 Systems Manager Automation、Step Functions 和跨帳號 event buses 組合。Alarm 直接觸發 Lambda 的 action 雖然也可行，但緊耦合且缺乏內建重試。

Q7：單一 alarm 能監看另一個帳號或 region 的 metric 嗎？

不能直接做到。CloudWatch alarm 永遠在它被定義的帳號和 region 中評估，並監看同一範圍內的 metrics。若要對跨帳號或跨 region 的 metric 設 alarm，有三個選項：（a）以 Lambda + PutMetricData 將 metric 複製到 alarm 所在的帳號/region；（b）使用 CloudWatch metric streams 將 metrics 傳送到中央帳號；（c）將 alarm 本身部署到每個來源帳號/region，並將 alarm 狀態異動事件路由到中央 EventBridge bus。選項（c）是 SOA-C02 建議的組織範圍監控模式——alarms 保持靠近 metric，聚合發生在 event-bus 層。

Q8：對 AWS Health Dashboard 設 alarm 的正確方式是什麼？

AWS Health 事件不是 CloudWatch metrics——它們是 EventBridge 上 aws.health 事件來源的事件。建立 EventBridge rule 匹配你關心的事件類別和服務（scheduledChange、issue、accountNotification，針對相關服務），然後路由到：用於人工通知的 SNS topic、更新 Jira/ServiceNow 工單的 Lambda function，以及在 CloudWatch alarms 旁邊呈現持續 Health 事件的 CloudWatch dashboard custom widget。若要多帳號覆蓋，啟用 AWS Health Organizational View，讓每個成員帳號的事件在進入你的 EventBridge pipeline 前聚合到管理帳號或委派管理員帳號。

Q9：CloudWatch 會保留我的 metric 資料多長時間？

CloudWatch 自動將 metric 資料捲成更粗粒度的 buckets：high-resolution（sub-minute）資料 3 小時、1-minute 資料 15 天、5-minute 資料 63 天、1-hour 資料 15 個月（455 天）。超過 15 個月後，資料消失。若你的 SysOps 職責需要更長的保留期用於容量規劃、稽核或合規，你必須匯出——透過 metric streams 到 S3/Firehose/第三方，或透過排程的 GetMetricData 呼叫進入你自己的資料湖。考試可能直接考這個數字：「CloudWatch 在不手動匯出的情況下最長保留 metric 多久？」——15 個月。

Q10：組合訊號時應該使用 composite alarm 還是 metric math？

當組合訊號是一個值——錯誤率、可用容量、加權平均——且你想對計算值設 alarm 時，使用 metric math。Alarm 是單一個 metric-math alarm。當組合訊號是跨 alarm 狀態的 Boolean 運算——「只有在 A 和 B 都處於 ALARM 時才呼叫」或「維護視窗 alarm 啟動時抑制呼叫」——時，使用 composite alarm。Composite alarms 還讓你抑制子 alarm actions，這是 metric math 做不到的。SOA-C02 常見的陷阱是在正確答案是 composite（狀態組合）時提供 metric math，或在正確答案是 metric math（值組合）時提供 composite；閱讀情境時注意它討論的是值還是 alarm 狀態。

延伸閱讀與相關運維模式

• What is Amazon CloudWatch — User Guide
• CloudWatch Concepts — Metrics, Namespaces, Dimensions, Resolution
• Using Amazon CloudWatch Alarms
• Configuring How CloudWatch Alarms Treat Missing Data
• CloudWatch Anomaly Detection
• CloudWatch Composite Alarms
• Using CloudWatch Dashboards
• Cross-Account Cross-Region CloudWatch Dashboards
• Installing the CloudWatch Agent
• Using Metric Math
• Basic vs Detailed EC2 Monitoring
• Service Quotas — Configure CloudWatch Alarms
• AWS Health Dashboard — Getting Started
• CloudWatch Alarm Actions Reference
• AWS SOA-C02 Exam Guide v2.3 (PDF)

Metrics 就位後，接下來的運維層次是：CloudWatch Logs 和 Logs Insights，用於應用程式與系統日誌分析（SOA-C02 Domain 1 中 metrics 之後自然延伸的主題）；EventBridge rules 和 SNS 通知，用於將 alarms 路由進自動化補救 pipeline；CloudTrail 和 AWS Config，用於稽核與設定合規訊號，這些訊號會輸入同一套 alarm 和 dashboard 架構；以及 EC2 Auto Scaling 和 ELB 高可用性，用於這些 alarms 所監控的工作負載層。

• CloudWatch Logs and Logs Insights — SOA-C02 學習筆記
• CloudTrail and AWS Config for Audit and Compliance — SOA-C02 學習筆記
• EventBridge Rules, SNS, and Automated Remediation — SOA-C02 學習筆記
• EC2 Auto Scaling, ELB, and Multi-AZ High Availability — SOA-C02 學習筆記