Amazon SAA-C03: 管理、維運、可觀測性與成本 — 學習指南

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

屬於 AWS SAA-C03 — 完整學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

CloudWatch：指標、命名空間、儀表板與警報

CloudWatch 是 AWS 服務預設的遙測資料平台，但它的功用完全取決於您是否知道服務將指標發佈到哪個命名空間。命名空間是指標的容器，用來避免服務之間的衝突——AWS/Lambda 存放函式的 Invocations、Errors 和 Throttles 指標，而 AWS/Events 則存放 EventBridge 規則的 Invocations、FailedInvocations、TriggeredRules 和 MatchedEvents 指標。在診斷事件驅動的管線時，這種區別至關重要。如果一個 EventBridge 規則透過 API destination 叫用第三方 API，而下游沒有任何流量，那麼答案不在 AWS/Lambda 中，而是在 AWS/Events 裡。檢查 TriggeredRules 可以告訴您規則模式是否真的匹配成功，而 Invocations/FailedInvocations 則告訴您目標本身是否被呼叫以及呼叫是否成功。如果因為 Lambda 是比較熟悉的服務就去搜尋 Lambda 的指標，就會忽略規則可能從未匹配到任何傳入事件這個事實。

指標精細度是各個資源的設定，且會影響成本。基本監控每五分鐘發佈一次指標，不需額外費用，這對於長時間運行的穩定狀態工作負載來說已經足夠，但對於需要每分鐘解析度的自動擴展反應、突波偵測或 SLO 計算來說，則太過粗略。詳細監控將間隔縮短到一分鐘（對於自訂的高解析度指標，可縮短到一秒），當擴展群組需要快速反應時，您就應該啟用它。這是一項付費功能——這也是為什麼它預設不是開啟的。

每個服務都會原生發佈一組預設指標，但 hypervisor 無法看到客體作業系統（guest OS）內部的情況。CPUUtilization、NetworkIn 和 DiskReadOps 這些 EC2 指標無需額外設定即可看見；但記憶體使用率和檔案系統已用百分比則需要 CloudWatch agent，這是取得這些指標的唯一方法。自訂的應用程式指標也是透過 agent 或 PutMetricData API 來傳送。

警報應該要能從雜訊中分辨出信號。一個單純設定 CPU > 50% 的警報在正常突波期間會不斷觸發，這會讓維運人員習慣性地忽略它。複合警報（Composite alarms）會將子警報的狀態與一個布林規則運算式結合，如此一來，只有在真正需要採取行動的條件成立時，才會通知待命人員。對於一個暫時性的 CPU 突波是良性、但持續的 CPU 壓力和升高的磁碟讀取 IOPS 合在一起才代表真正問題的工作負載來說：

HighCPUAlarm:
  MetricName: CPUUtilization
  Threshold: 50
  EvaluationPeriods: 3
  Period: 60
  ComparisonOperator: GreaterThanThreshold

HighDiskReadAlarm:
  MetricName: DiskReadOps
  Threshold: 1000
  EvaluationPeriods: 3
  Period: 60

CompositeAlarm:
  AlarmRule: >
    ALARM("HighCPUAlarm") AND ALARM("HighDiskReadAlarm")
  AlarmActions:
    - arn:aws:sns:us-east-1:111122223333:ops-pager

子警報在內部可能仍會轉換到 ALARM 狀態，但只有複合警報會觸發 SNS。如果用兩個獨立的警報都去通知待命人員，只會重現雜訊問題；而單純將單一警報的閾值設高，則會錯失這種關聯性。

儀表板彙總了指標小工具、日誌小工具和文字。有兩種共享模式，混淆它們是常見的陷阱。如果檢視者已經有 AWS 帳戶，請授予他們一個具有 cloudwatch:GetDashboard 和 cloudwatch:GetMetricData 權限的 IAM 身分（或透過跨帳戶可觀測性提供一個角色）。如果檢視者沒有 AWS 帳戶——例如產品經理、客戶方的利害關係人——請使用內建的儀表板共享功能，它會產生一個可共享的連結，並透過單一的電子郵件/密碼、一個 Cognito 使用者集區或一個公開 URL（很少適用）來保護。用電子郵件寄送螢幕截圖不算是可觀測性，而為非 AWS 使用者建立一個有主控台存取權限的 IAM 使用者，也不符合最低權限原則。

使用 OAM 達成跨帳戶可觀測性

在數十個帳戶之間來回切換以檢視指標是不可行的。CloudWatch 跨帳戶可觀測性會指定一個監控帳戶（monitoring account）作為中央接收器（sink），以及任意數量的來源帳戶（source accounts），來源帳戶會透過接收器和連結（link）資源與監控帳戶共享指標、日誌和追蹤資料。要大規模快速部署，最好的方法是在監控帳戶中開啟 CloudWatch 主控台，建立一個接收器，然後將產生的 CloudFormation StackSet 範本部署到整個組織，以便在每個來源帳戶中建立 AWS::Oam::Link 資源：

Resources:
  ObservabilityLink:
    Type: AWS::Oam::Link
    Properties:
      LabelTemplate: "$AccountName"
      ResourceTypes:
        - AWS::CloudWatch::Metric
        - AWS::Logs::LogGroup
        - AWS::XRay::Trace
      SinkIdentifier: arn:aws:oam:us-east-1:111122223333:sink/abc-123

雖然技術上可以用跨帳戶 IAM 角色和手動查詢來解決這個問題，但這樣做無法提供統一的儀表板、跨帳戶的 Metrics Insights 查詢，也無法像 OAM 連結那樣自動豐富帳戶名稱標籤。

Container Insights 與分散式追蹤

對於容器化工作負載，Container Insights 是 CloudWatch 的標準功能。在 EKS 上，它會將 CloudWatch agent（或 ADOT collector）部署為一個 DaemonSet，並加上用來轉發日誌的 Fluent Bit。Agent 會抓取 cAdvisor 和 kubelet 的指標，並將它們發佈到 ECS/ContainerInsights 和 ContainerInsights 命名空間（每個 pod、節點、命名空間和叢集的 CPU/記憶體），而 Fluent Bit 則會將 stdout/stderr 傳送到像是 /aws/containerinsights/<cluster>/application、/dataplane 和 /host 等日誌群組。自行建置 Prometheus/Grafana 堆疊是可行的；但託管模式則是採用 Container Insights 加上 Logs Insights：

fields @timestamp, kubernetes.pod_name, log
| filter kubernetes.namespace_name = "payments"
| filter log like /ERROR/
| stats count() by kubernetes.pod_name

指標告訴您有東西變慢了；追蹤資料則告訴您在哪裡變慢了。X-Ray 會檢測請求路徑中的每個服務，透過 X-Amzn-Trace-Id 標頭傳遞追蹤 ID，並將區段（segments）和子區段（subsegments）發佈到 X-Ray daemon 或 ADOT collector。服務地圖會將節點和邊緣視覺化，並標示延遲、錯誤和故障百分比。如果沒有 X-Ray，p99 延遲飆高只會以一個無法歸因的 CloudWatch 指標呈現出來。

from aws_xray_sdk.core import xray_recorder, patch_all
patch_all()  # instruments boto3, requests, sqlalchemy, etc.

@xray_recorder.capture('checkout')
def checkout(order_id): ...

Container Insights、X-Ray 加上 CloudWatch Logs，是微服務可觀測性的三大支柱。

三大日誌串流：CloudTrail、VPC Flow Logs、CloudWatch Logs

任何 AWS 可觀測性策略都會區分三種不同的日誌串流：管理層 API 活動 (CloudTrail)、資料層網路活動 (VPC Flow Logs)，以及應用程式/作業系統輸出 (CloudWatch Logs)。每種日誌都回答了不同的鑑識問題，混淆它們是一個常見的設計錯誤。

CloudTrail 記錄每一次的 AWS API 呼叫——由誰 (userIdentity) 叫用、從哪個 IP、針對哪個資源、使用什麼參數，以及是否成功。它是唯一能夠可靠地將變更追溯到特定 IAM 主體的服務。一個常見的誤解是認為 CloudWatch Logs 是尋找 API 活動的正確地方；CloudWatch Logs 擷取的是應用程式/系統的輸出，而不是主體層級的稽核資料。CloudTrail 可以 將其事件傳遞到 CloudWatch Logs 以進行即時的指標篩選，但底層的稽核記錄源自於 CloudTrail。

在 AWS Organizations 環境中，正確的模式是從管理帳戶（或委派管理員帳戶）建立一個 organization trail，它會自動納入新的成員帳戶，並將事件串流到一個專用的日誌封存帳戶中的單一 S3 儲存貯體：

CentralTrail:
  Type: AWS::CloudTrail::Trail
  Properties:
    IsOrganizationTrail: true
    IsMultiRegionTrail: true
    IncludeGlobalServiceEvents: true
    EnableLogFileValidation: true       # SHA-256 digest chain
    S3BucketName: org-cloudtrail-logs
    KMSKeyId: !Ref TrailKmsKey

目標儲存貯體需要啟用版本控制、一個限制 s3:PutObject 只能由 CloudTrail 服務主體執行的儲存貯體政策、SSE-KMS 加密、供稽核員使用的跨帳戶唯讀權限，以及最好是啟用 S3 物件鎖定的合規模式 (S3 Object Lock in compliance mode) 以提供 WORM (Write Once, Read Many) 保證。日誌檔案驗證會產生簽署過的摘要檔案，因此任何竄改都是可偵測的。管理事件預設會開啟並保留 90 天；若要保留更久則需要建立一個 trail。資料事件 (S3 物件層級、Lambda 叫用、DynamoDB 項目層級) 因為量大且成本高，所以是選擇性加入的。對於臨時性的歷史查詢，可以使用 CloudTrail Lake 或在 trail 儲存貯體上執行 Athena 來進行 SQL 查詢：

SELECT userIdentity.arn, eventTime, requestParameters
FROM cloudtrail_logs
WHERE eventName = 'AuthorizeSecurityGroupIngress'
  AND eventTime BETWEEN '2024-01-08' AND '2024-01-12';

VPC Flow Logs 擷取關於 IP 流量的中繼資料——5 元組 (5-tuple)、位元組數、封包數、動作 (ACCEPT/REJECT)，以及日誌狀態——適用於 VPC、子網路或 ENI。它們不擷取酬載 (payloads)。交付目標可以是 CloudWatch Logs、S3 或 Kinesis Data Firehose。當需要封存時選擇 S3；當需要指標篩選條件來觸發可疑流量模式的警報時選擇 CloudWatch Logs；當需求是近乎即時的分析時選擇 Firehose。一個包含 NLB、ASG 和資料庫的 VPC 的標準近乎即時管線如下：

ENIs → VPC Flow Logs (delivery: Kinesis Data Firehose)
      → Firehose delivery stream (optional Lambda transform)
      → Amazon OpenSearch Service (index: vpc-flow-*)
      → OpenSearch Dashboards

另一種 CloudWatch Logs → 訂閱篩選條件 → Firehose → OpenSearch 的路徑也行得通，但增加了一個躍點和成本。當需求是「近乎即時」時，選擇 S3 是錯誤的。完全不啟用 Flow Logs 是最具破壞性的陷阱：當安全事件發生時，將沒有來源/目的地/連接埠的記錄，也無法看到 ACCEPT vs REJECT 的情況。同樣的道理也適用於 ALB 存取日誌——它們是選擇性加入的，交付到 S3，若沒有它們，就沒有請求層級的用戶端 IP、回應碼、目標延遲或使用者代理程式的記錄。Flow Logs (L3/L4) 和 ALB 存取日誌 (L7) 共同構成了流量鑑識的基準線。

CloudWatch Logs 透過 CloudWatch 代理程式接收應用程式、Lambda 和作業系統的日誌。其強大之處在於指標篩選條件 (metric filters)：這是一種模式表達式，可以掃描傳入的事件，並在匹配時遞增一個自訂指標，進而驅動警報：

# Metric filter detecting inbound SSH sessions from Flow Logs
[version, account, eni, source, dest, srcport, destport=22,
 protocol=6, packets, bytes, start, end, action=ACCEPT, status]

一個平行的篩選條件監控 3389 埠則涵蓋了 RDP。只擷取日誌而不設定警報，只能做事後鑑識，無法做到預防。

對於大型叢集，標準作法是透過日誌群組上的訂閱篩選條件 (subscription filter) 將日誌分發到一個處理管線中，以近乎即時的方式將匹配的事件串流到 Kinesis Data Stream、Firehose 或 Lambda：

{
  "filterPattern": "",
  "destinationArn": "arn:aws:firehose:us-east-1:111122223333:deliverystream/logs-to-os"
}

常見的陷阱是將原始日誌送到儲存體而沒有處理管線：直接傾印到 S3，卻沒有 Glue 型錄、沒有 OpenSearch 索引、也沒有 Athena 工作群組，這意味著日誌雖然存在，但在事件發生時無法採取行動。可觀測性需要一個可查詢的介面，而不僅僅是持久化的位元組。日誌群組也需要明確的保留政策——預設是「永不過期」，這會悄悄地燒錢——並且可以匯出到 S3，透過生命週期規則進行長期封存。

以最低開銷進行 API 層級的事件偵測

對於高價值的控制層事件——例如 CreateImage、AuthorizeSecurityGroupIngress、StopLogging、非 MFA 的 ConsoleLogin——開銷最低的模式是 CloudTrail → EventBridge 規則 → SNS。EventBridge 原生就能接收每一個 CloudTrail 管理事件，而一個帶有事件模式的規則不需要任何 Lambda 膠水程式碼：

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["CreateImage"]
  }
}

將 CloudTrail 送到 CloudWatch Logs 並應用指標篩選條件也行得通，但這會增加日誌群組、篩選條件、警報和成本，所以當需求只是「針對 API X 發出警報」時，這種作法在維運開銷上就輸了。

AWS Config：持續組態與漂移

Config 和 CloudTrail 常常被搞混，但它們回答的是根本上不同的問題。CloudTrail 記錄誰呼叫了什麼；Config 記錄資源現在長什麼樣子，以及它如何隨著時間變化。期待 Config 記錄 API 呼叫是一個典型的錯誤答案——Config 不知道有使用者叫用了 PutBucketAcl；它只知道在 14:03:22 時，儲存貯體的 ACL 從狀態 A 變成了狀態 B。要識別出 principal (委託人)，可以將 Config 的變更記錄與相同時間戳記的 CloudTrail 事件關聯起來 (Config 在主控台中有提供指向該事件的深層連結)。

Config 規則會根據期望的狀態來評估資源。受管規則 (Managed rules) 涵蓋了常見的檢查 (restricted-ssh、s3-bucket-public-read-prohibited、required-tags、ec2-instance-no-public-ip、s3-bucket-versioning-enabled、desired-instance-type)，而自訂規則則以 Lambda 函數的形式執行，或使用 CloudFormation Guard。規則會在組態變更時以及按排程進行評估，將資源標記為 COMPLIANT (合規) 或 NON_COMPLIANT (不合規)，並可透過 SSM Automation 文件觸發自動修復。對於「偵測開放的 SSH」或「偵測過大的執行個體類型」這類需求，這是營運開銷最低的解決方案——因為這些規則都已經存在，並且與 SNS 和 Security Hub 原生整合。若提議採用定期手動稽核、排程掃描或自行開發掃描器，就需要您去建置和維護 Config 已經內建提供的程式碼。

Config 會將評估結果發佈到 SNS。要自動化修復，可以設定一個 EventBridge 規則來串接合規性變更事件，並叫用一個 SSM Automation 文件或 Lambda：

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

彙總器 (Aggregators) 可整合整個組織的合規性狀態；合規包 (conformance packs) 則針對 PCI-DSS 或 HIPAA 等框架捆綁了一系列規則。Workload Discovery on AWS (前身為 AWS Perspective) 是一個建構在 Config 之上的解決方案，它可以將資源關係視覺化並產生架構圖——當問題問到需要一個能夠繪製現有環境架構圖的盤點工具時，這就是標準答案。Config 是其先決條件。

Security Hub、GuardDuty 與 Control Tower

Security Hub 是用於彙總安全性發現項目的平台。它會從 GuardDuty (基於 VPC Flow Logs、DNS 和 CloudTrail 的威脅偵測)、Inspector (弱點發現項目)、Macie、IAM Access Analyzer 和 Config 接收資料，然後將所有內容標準化為 AWS Security Finding Format (ASFF)。啟用 Security Hub 同時也會啟用安全性標準，其中最著名的是 AWS Foundational Security Best Practices (FSBP) 標準——數十項自動檢查 (根帳號 MFA、公開的 S3、未加密的 EBS、多區域 CloudTrail) 在底層都對應到 Config 規則。

在組織規模下，應為 Security Hub (以及 GuardDuty 和 Config) 指定一個委派管理員帳戶，並透過「自動為新帳戶啟用」的切換開關為整個組織啟用該服務和 FSBP 標準，然後透過 EventBridge 將發現項目路由到 SNS。做法是比對 Security Hub Findings - Imported 事件，並篩選 FSBP 標準的 ARN 以及 Compliance.Status = FAILED。自行開發解析 CloudTrail 的 Lambda 或為每個帳戶建立儀表板，會增加 Security Hub 已經承擔掉的營運負擔。

一個關鍵的概念區別：Security Hub 是偵測性和彙總性的，而不是預防性的。預防漂移是 AWS Control Tower 的工作，它負責協調一個架構完善的多帳戶登陸區 (landing zone)。Account Factory 會為新帳戶佈建基準的網路、日誌記錄和 IAM。治理是透過三種類型的護欄 (guardrails) 來實現的：

主動性控制會在堆疊部署之前評估 CloudFormation 範本，並拒絕建立不合規的資源，例如一個未加密的 RDS 執行個體。而 Security Hub 只會在未加密的執行個體已經在執行後，才告訴你它的存在。如果需求是「預防」，就考慮 Control Tower。如果需求是「偵測、通知或彙總」，就考慮 Security Hub 或 Config。

Macie：敏感資料探索

Macie 使用機器學習 (ML) 和模式比對來識別 S3 物件內的敏感資料——例如 PII (個人識別資訊)、財務資料、憑證等。一個關鍵的陷阱是假設 Macie 會保護資料。它不會。Macie 的功能是發現和回報。正確的使用方式：

1. 在目標帳戶/區域中啟用 Macie。
2. 設定一個敏感資料探索任務 (sensitive data discovery job)，按排程針對特定的儲存貯體/前綴/標籤執行。
3. 透過 EventBridge (source: aws.macie) 將發現項目路由出去，送到 SNS 進行通知、送到 Lambda 進行修復 (例如隔離、收緊儲存貯體政策)，或送到 Security Hub。

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

如果沒有設定探索任務，Macie 不會產生任何結果。如果沒有設定 EventBridge → SNS 的串接，發現項目就只會靜靜地躺在 Macie 主控台裡，無人問津。

Organizations、SCPs 與標籤政策

AWS Organizations 在此揭露了三種相關的政策類型。標籤政策 (Tag policies) 定義了允許的標籤鍵、大小寫和值 — 它們會回報不合規的情況，並且可以結合 aws:ResourceTag/aws:RequestTag 條件來強制執行。服務控制政策 (Service Control Policies, SCPs) 定義了成員主體 (principal) 可用的最大權限。備份政策 (Backup policies) 和 AI 選擇退出政策 (AI opt-out policies) 構成了完整的政策組合。

一個關鍵的心智模型是：SCPs 絕不會授予權限。它們是一個過濾器，作用於 IAM (身分政策、資源政策、權限邊界) 原本可能允許的權限之上。一個主體必須擁有 IAM 的 Allow 而且 SCP 不得 Deny (或者必須在其 Allow 清單中包含該動作)。「只要附加一個 SCP」從來不是權限問題的完整答案 — 如果沒有 IAM 的 Allow，無論 SCP 的內容為何，主體預設都會被拒絕。

要在建立資源時強制要求標籤，可以將標籤政策與 SCP 結合使用，例如：

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Resource": "*",
  "Condition": {
    "Null": { "aws:RequestTag/CostCenter": "true" }
  }
}

標籤政策宣告了結構 (schema)；SCP 拒絕沒有標籤的建立動作；IAM 政策授予建立動作的權限。這三者缺一不可。AWS Config 的 required-tags 規則可以偵測並修復現有的不合規資源。

Systems Manager Automation 與修補

Systems Manager (SSM) 是跨 EC2 和混合節點 (hybrid nodes) 機群執行生命週期活動的營運骨幹。對於修補作業而言，有兩個結構最為重要：Automation 文件 (Automation documents) (呼叫 AWS API 或腳本的宣告式 YAML/JSON runbook) 和 維護時段 (Maintenance Windows) (在變更時段內，根據標籤指定的目標或資源群組來排程執行這些 runbook，並設定並行和錯誤閾值)。

標準的修補流程是執行 AWS-RunPatchBaseline (一個 Command 文件)，針對由 Patch Group 標籤選定的執行個體 (instance)，並使用一個定義了各作業系統核准規則的 Patch Baseline。對於負載平衡器後方的執行個體，直接執行 AWS-RunPatchBaseline 會在修補過程中中斷連線，因為執行個體在目標群組 (target group) 中仍保持 InService 狀態。正確的模式是使用 AWSEC2-PatchLoadBalancerInstance，它會：

1. 從其 CLB 或 ALB 目標群組中取消註冊該執行個體。
2. 等待連線耗盡 (connection draining) / 取消註冊延遲。
3. 叫用 (invoke) patch baseline 的掃描和安裝步驟。
4. 如果 baseline 要求，則重新啟動。
5. 重新註冊該執行個體，並等待目標健康狀態返回 healthy。

有兩個先決條件會導致「產生錯誤」的失敗模式。首先，作為 AutomationAssumeRole 傳入的 IAM 角色，除了標準的 SSM 修補權限外，還必須包含 elasticloadbalancing:DeregisterTargets、RegisterTargets 和 DescribeTargetHealth。其次，該執行個體必須是一個受管節點 (managed node) — 也就是 SSM Agent 正在執行，且執行個體設定檔 (instance profile) 包含 AmazonSSMManagedInstanceCore。若缺少這些，取消註冊的呼叫會失敗，或者 SSM 無法看見該執行個體。

schemaVersion: '0.3'
description: Patch instance behind ALB
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  InstanceId: { type: String }
  TargetGroupArn: { type: String }
  AutomationAssumeRole: { type: String }
mainSteps:
  - name: deregister
    action: aws:executeAwsApi
    inputs:
      Service: elbv2
      Api: DeregisterTargets
      TargetGroupArn: '{{ TargetGroupArn }}'

← 安全性、IAM、KMS 與治理 · 所有領域 · 高可用性、容錯與災難復原 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Amazon →