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 目标调用了第三方 API，但下游没有流量到达，那么答案不在 AWS/Lambda 中，而是在 AWS/Events 中。检查 TriggeredRules 可以告诉您规则模式是否真的匹配成功，而 Invocations/FailedInvocations 则告诉您目标本身是否被调用以及调用是否成功。仅仅因为 Lambda 是更熟悉的服务就去搜索 Lambda 指标，会忽略规则可能从未匹配到传入事件这一事实。

指标分辨率是一项按资源设置的配置，并会产生相应的成本。基本监控每五分钟发出一次指标，不收取额外费用，这对于长时间运行的稳态工作负载来说足够了，但对于需要分钟级分辨率的自动扩展反应、峰值检测或 SLO 计算而言，粒度则太粗。详细监控将时间间隔缩短到一分钟（对于自定义高分辨率指标可缩短到一秒），当扩展组需要快速反应时，您就需要启用它。这是一项付费功能——这也是它默认不开启的原因。

每个服务都会原生发出一组默认指标，但虚拟机监控程序（hypervisor）无法看到客户操作系统（guest OS）内部的情况。对于 EC2，CPUUtilization、NetworkIn 和 DiskReadOps 等指标无需额外操作即可查看；但内存利用率和文件系统已用百分比则需要 CloudWatch 代理，这是获取这些指标的唯一方法。自定义应用程序指标也通过该代理或 PutMetricData API 推送。

警报应该能够区分信号和噪声。一个简单的 CPU > 50% 的警报会在正常的突发期间不断触发，这会让运维人员习惯性地忽略它。复合警报将子警报的状态与布尔规则表达式相结合，这样只有在真正需要采取行动的条件成立时，才会向运维人员发送通知。对于一个瞬时 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 账户，请授予他们一个 IAM 身份（或通过跨账户可观测性授予一个角色），并赋予 cloudwatch:GetDashboard 和 cloudwatch:GetMetricData 权限。如果查看者没有 AWS 账户——例如产品经理、客户利益相关者——请使用内置的控制面板共享功能，该功能会生成一个可共享的链接，受单个电子邮件/密码、Cognito 用户池或公共 URL（很少适用）的保护。通过电子邮件发送屏幕截图不是可观测性，而为非 AWS 用户创建具有控制台访问权限的 IAM 用户也不符合最小权限原则。

使用 OAM 实现跨账户可观测性

在数十个账户之间来回切换以查看指标是不可行的。CloudWatch 跨账户可观测性指定一个监控账户作为中央接收器 (sink)，以及任意数量的源账户，这些源账户通过接收器和链接资源与监控账户共享指标、日志和跟踪。大规模部署的最快方法是在监控账户中打开 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 代理（或 ADOT 收集器）部署为 DaemonSet，并使用 Fluent Bit 进行日志转发。代理会抓取 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，并向 X-Ray 守护进程或 ADOT 收集器发出分段 (segment) 和子分段 (subsegment)。服务地图会可视化节点和边，并附带延迟、错误和故障百分比。没有 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 环境中，正确的模式是从管理（或委托管理员）账户创建一个组织跟踪，它会自动纳入新的成员账户，并将事件流式传输到专用的日志归档账户中的单个 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 Object Lock 以提供 WORM（一次写入，多次读取）保证。日志文件验证会生成带签名的摘要文件，因此任何篡改都是可检测的。管理事件默认开启并保留 90 天；要保留更长时间则需要创建跟踪。数据事件（S3 对象级别、Lambda 调用、DynamoDB 项目级别）由于数据量大和成本高，需要选择性开启。对于即席历史查询，可以使用 CloudTrail Lake 或针对跟踪存储桶的 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 流量的元数据——五元组、字节数、数据包数、操作（ACCEPT/REJECT）和日志状态——适用于 VPC、子网或 ENI。它们不捕获流量负载。交付目标可以是 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 还是 REJECT。同样的道理也适用于 ALB 访问日志——它们是选择性开启的，交付到 S3，如果没有它们，就没有关于客户端 IP、响应代码、目标延迟或用户代理的请求级记录。Flow Logs (L3/L4) 和 ALB 访问日志 (L7) 共同构成了流量取证的基线。

CloudWatch Logs 通过 CloudWatch 代理接收应用程序、Lambda 和操作系统的日志。其强大之处在于指标筛选器：通过模式表达式扫描传入的事件，在匹配时递增一个自定义指标，进而驱动警报：

# 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。只收集日志而不设置警报，只能做到事后取证，而无法做到事前预防。

对于大规模实例集群，标准做法是通过日志组上的订阅筛选器将日志扇出到一个处理管道中，近实时地将匹配的事件流式传输到 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。要识别操作主体，需要将 Config 的变更记录与同一时间戳的 CloudTrail 事件关联起来（Config 在控制台中提供了指向该事件的深层链接）。

Config 规则 (Config 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 安全调查发现格式 (ASFF)。启用 Security Hub 也会启用安全标准，其中最著名的是 AWS 基础安全最佳实践 (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. 配置一个敏感数据发现作业，按计划针对特定的存储桶/前缀/标签运行。
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、SCP 和标签策略

AWS Organizations 提供了三种与此相关的策略类型。标签策略 (Tag policies) 定义了允许的标签键、大小写和值——它们会报告不合规的情况，并可与 aws:ResourceTag/aws:RequestTag 条件结合强制执行。服务控制策略 (Service Control Policies, SCP) 定义了成员账户中的主体可用的最大权限。备份策略 (Backup policies) 和 AI 服务选择退出策略 (AI opt-out policies) 完善了这一策略集合。

一个至关重要的心智模型是：SCP 从不授予权限。它们是一个过滤器，作用于 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 自动化和修补

Systems Manager (SSM) 是跨 EC2 和混合节点实例集群执行生命周期活动的运营支柱。在修补方面，最重要的两个构造是：自动化文档 (Automation documents)（调用 AWS API 或脚本的声明式 YAML/JSON 运行手册）和维护时段 (Maintenance Windows)（在具有并发和错误阈值的变更窗口内，针对基于标签的目标或资源组来调度这些运行手册）。

典型的修补流程是 AWS-RunPatchBaseline（一个命令文档）针对由 Patch Group 标签选择的实例执行，并使用一个为每个操作系统定义了批准规则的补丁基线 (Patch Baseline)。对于负载均衡器后面的实例，直接运行 AWS-RunPatchBaseline 会在修补过程中中断连接，因为实例在目标组中仍保持 InService 状态。正确的模式是使用 AWSEC2-PatchLoadBalancerInstance，它会：

1. 从其 CLB 或 ALB 目标组中取消注册实例。
2. 等待连接耗尽/取消注册延迟。
3. 调用补丁基线扫描和安装步骤。
4. 如果基线要求，则重新启动实例。
5. 重新注册实例，并等待目标健康检查状态恢复为 healthy。

有两个先决条件会导致“产生错误”的失败模式。首先，作为 AutomationAssumeRole 传递的 IAM 角色除了标准的 SSM 修补权限外，还必须包含 elasticloadbalancing:DeregisterTargets、RegisterTargets 和 DescribeTargetHealth。其次，实例必须是一个托管节点 (managed node)——即 SSM Agent 正在运行，并且实例配置文件包含了 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 →