Amazon SAA-C03: 内容分发、边缘与性能优化 — 学习指南

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

属于 AWS SAA-C03 — 完整学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

Amazon CloudFront：简介及其优势

Amazon CloudFront 是一个构建在 600 多个接入点上的全球分布式内容分发网络。它的工作是在最近的边缘节点终止查看者的 TLS 连接，然后立即提供缓存的响应，或者通过 AWS 的私有骨干网络将缓存未命中的请求代理到源站。这带来了双重性能优势：缓存命中将往返时间缩短至个位数毫秒，并完全为源站减负；而缓存未命中时，请求依然能从边缘节点优化的 TLS/TCP 终止、HTTP/2 和 HTTP/3 支持、到源站的持久连接复用以及避免嘈杂公共互联网的骨干网络传输中获益。

一个常见的误解是 CloudFront 只加速静态资产。实际上，即使将 ALB 置于 CloudFront 之后并使用 CachingDisabled 策略，动态 API 的性能仍然会得到提升，因为查看者的 TLS 握手是在本地接入点（PoP）完成的，而不是穿越公共互联网到达源站区域。如果再结合一个混合工作负载——例如，/static/* 由 S3 提供，/api/* 由 ALB 提供——那么一个 CloudFront 分配就可以同时处理这两种请求：

Distribution:
  Aliases: [www.example.com]
  ViewerCertificate: ACM cert in us-east-1
  Origins:
    - Id: s3-static
      DomainName: static-assets.s3.us-east-1.amazonaws.com
      S3OriginConfig:
        OriginAccessControlId: !Ref OAC
    - Id: alb-dynamic
      DomainName: alb-1234.us-east-1.elb.amazonaws.com
      CustomOriginConfig: { OriginProtocolPolicy: https-only }
  DefaultCacheBehavior:
      TargetOriginId: alb-dynamic
      CachePolicyId: CachingDisabled
      OriginRequestPolicyId: AllViewer
  CacheBehaviors:
    - PathPattern: /static/*
      TargetOriginId: s3-static
      CachePolicyId: CachingOptimized
    - PathPattern: /api/*
      TargetOriginId: alb-dynamic
      CachePolicyId: !Ref ShortTtlPolicy

然后，通过 Route 53 别名记录将 www.example.com 指向该分配的 d123.cloudfront.net 域名——别名记录是免费的，并且能直接解析到 CloudFront 的任播 IP 地址。

证书位于 us-east-1

对于任何使用自定义域名的 CloudFront 分配，其面向查看者的 TLS 证书必须在 AWS Certificate Manager 的 us-east-1（弗吉尼亚北部）区域颁发，无论源站存储桶、ALB 或用户位于何处。CloudFront 是一项全球服务，其控制平面锚定在 us-east-1；边缘站点会从该区域拉取证书。如果因为你的 S3 存储桶恰好在 eu-west-1 就在该区域请求 ACM 证书，这是一种错误的模式——CloudFront 分配将永远无法看到这个证书。

aws acm request-certificate \
  --domain-name media.example.com \
  --validation-method DNS \
  --region us-east-1

如果你在 CloudFront 和 ALB 源站之间进行第二次 TLS 终止，那么这个面向源站的证书则位于 ALB 所在的区域。只有面向查看者的证书才被锁定在 us-east-1。同样的规则也适用于 API Gateway 的边缘优化型自定义域名（它在内部使用一个由 AWS 托管的 CloudFront 分配）：证书必须在 us-east-1。相比之下，区域性的 API Gateway 终端节点则使用 API 自身所在区域的证书。

针对 S3 源站的源访问控制 (OAC)

将 S3 存储桶置于 CloudFront 之后，却保持存储桶为公开状态，这违背了初衷：查看者可以通过直接访问 S3 REST 终端节点来绕过 CloudFront，从而规避 WAF、地理限制、签名 URL 和缓存带来的好处——并可能导致数据暴露。

现代的解决方案是源访问控制 (Origin Access Control, OAC)，它取代了传统的源访问身份 (Origin Access Identity, OAI)。OAC 使用 SigV4 签名，支持 SSE-KMS，适用于所有 S3 区域（包括 2022 年之后推出的区域），并支持动态请求。使用 OAC 时，“阻止公有访问”应保持开启，不需要 ACL，存储桶策略仅向 CloudFront 服务主体授予读取权限，并由特定的分配 ARN 进行进一步约束：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipal",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::media-example-com/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF"
      }
    }
  }]
}

OAI 仍然可用，但应被视为传统功能——所有新工作都应选择 OAC。

缓存正确性

缓存的有效性取决于源站返回的 Cache-Control 和 Expires 标头，以及 CloudFront 缓存策略中设置的最小/默认/最大 TTL。带有指纹的、不可变的资产应该被积极缓存；引用这些资产的 HTML 外壳文件应该设置较短的缓存时间以便部署更新能够快速生效；而需要身份验证的 JSON 数据则完全不应在共享的 CDN 上缓存：

Cache-Control: public, max-age=31536000, immutable   # fingerprinted assets
Cache-Control: public, max-age=60, s-maxage=300      # HTML that changes
Cache-Control: private, no-store                      # authenticated JSON

有两种对称的陷阱很常见。第一，如果源站没有发出任何缓存标头，CloudFront 会回退到分配设置的默认 TTL，并可能在不知不觉中将动态响应缓存数小时。第二，对那些本应被缓存的资产一概使用 Cache-Control: no-cache，会强制每个请求都回源，从而使 CDN 失效。

最危险的陷阱是在没有正确标头的情况下缓存个性化响应。如果 /account/dashboard 返回了针对用户 A 的特定 HTML，但源站省略了 no-store 标头，并且缓存策略的缓存键中没有包含身份验证标头或 cookie，那么边缘节点会很乐意地将用户 A 的页面提供给用户 B。解决方案是：要么将此类响应标记为 private, no-store，要么在缓存键中包含会话标识符并接受因此带来的较低缓存命中率。

在一个成本优化场景中，如果一个由 EC2 按需实例组成的 Auto Scaling 组正在提供静态内容，那么正确的重新设计方案是：将这些资产迁移到 S3，在前端使用带 OAC 的 CloudFront，然后移除或缩减该 ASG。这将成本从按小时计算的计算成本转移到按请求计算的交付成本，对于静态工作负载而言，后者要便宜几个数量级。

签名 URL、签名 Cookie 和地理限制

CloudFront 支持签名 URL（对单个对象提供有时间限制、可选 IP 限制的访问——例如一次购买的视频下载、一个一次性的 PDF 链接）和签名 Cookie（对匹配某个路径模式的多个对象提供访问——例如一个已认证的订阅者浏览整个目录）。两者都使用一个可信密钥组，其公钥被上传到 CloudFront；私钥则用于对一个指定了过期时间、源 IP 范围或 URL 模式的策略进行签名。

https://d123.cloudfront.net/premium/movie.mp4
  ?Expires=1735689600
  &Signature=...
  &Key-Pair-Id=APKAI...

这与 S3 预签名 URL 不同，后者会绕过 CloudFront 并直接授予对存储桶的访问权限。将 CloudFront 签名 URL 与 OAC 结合使用，存储桶就能保持端到端的私有性。

地理限制在分配级别、在请求到达缓存或源站之前，强制执行国家级别的允许列表或阻止列表。它使用 CloudFront 维护的 GeoIP 数据库，是一种廉价且能防止缓存绕过的机制，常用于强制执行许可禁令。如果需要更精细的逻辑（例如州级别、结合标头判断），可以使用 CloudFront Function 或 Lambda@Edge；如果需要一个完整的规则引擎，则应使用 WAF。

AWS Global Accelerator

Global Accelerator 不是 CDN，也不进行缓存。它会预置两个静态的任播 IPv4 地址（或使用您自己的 IP 地址，即 BYOIP），这些地址从全球的 AWS 边缘站点进行通告。客户端的 TCP 或 UDP 连接在最近的边缘站点进入 AWS 骨干网，然后通过 AWS 的私有网络路由到一个或多个区域中最健康的终端节点（ALB、NLB、EC2 或 Elastic IP）。这些终端节点被分组到终端节点组中，可以通过流量拨号和权重进行控制。

静态 IP 带来了三个具体的好处：即使后端架构重构，客户端和防火墙的允许列表也无需更改；区域性故障转移可在数秒内完成，通过在健康检查发生变化时切换终端节点组之间的流量，完全绕过了 DNS TTL 的传播延迟；并且 TCP 握手在边缘站点终止，长途传输则在 AWS 的骨干网上进行。

选择 Global Accelerator 的场景：

• 协议非 HTTP：用于游戏或 VoIP 的 UDP、MQTT、SIP、SFTP、自定义 TCP。
• 您需要静态 IP 用于企业允许列表或硬编码地址的移动应用。
• 您需要为有状态的主-主部署实现亚分钟级的区域性故障转移。
• 工作负载是动态且不可缓存的，因此 CDN 提供的价值很小。

选择 CloudFront 的场景：

• 内容是可缓存的（图像、视频片段、静态 HTML、带有 TTL 的 API 响应）。
• 您希望通过 Lambda@Edge 或 CloudFront Functions 进行边缘计算。
• 您需要在边缘使用 WAF、签名 URL/Cookie 或字段级加密。

需要避免的两个陷阱。选择 CloudFront 来“让我们的游戏服务器在全球范围内更快”是行不通的，因为游戏是基于 UDP 且不可缓存的——这种场景需要 Global Accelerator。反之，为静态网站选择 Global Accelerator 不仅昂贵（固定小时费加上每 GB 费用），而且放弃了缓存——CloudFront 会大幅削减源站出口成本。对于一个全球分布但部署在单区域的 HTTP API，如果用户可以容忍延迟，那么简单的 Route 53 基于延迟的路由策略可能就足够了，并且比前两者都便宜。

Route 53 全球流量路由策略

Route 53 决定客户端解析到哪个终端节点；然后由 CloudFront 或 Global Accelerator 处理连接。三种策略在全局架构中占主导地位。

基于延迟的路由衡量从解析器位置到每个区域的实际网络延迟，并返回最快的区域。当您在多个区域部署了相同的堆栈，并希望将用户引导至当前最快的区域时，请使用此策略。

地理邻近路由是基于坐标而非延迟的：您声明每个终端节点的位置（或 AWS 区域），Route 53 会将用户发送到地理上最近的终端节点。其独特功能是**偏差（bias）**值（-99 到 +99），可以扩大或缩小有效的服务区域——这对于在区域发布期间逐步转移流量或排空区域以进行维护非常有用。地理邻近路由需要使用 Route 53 流量流（流量策略），并且通常与每个区域中的区域性 NLB 或 ALB 配对使用。

RecordSets:
  - Region: eu-west-1
    Endpoint: nlb-eu.example.internal
    Bias: +30       # expand EU service area during launch
  - Region: us-east-1
    Endpoint: nlb-us.example.internal
    Bias: 0
  - Region: ap-southeast-1
    Endpoint: nlb-ap.example.internal
    Bias: 0

故障转移路由使用与健康检查绑定的主/备对。这是 DNS 级别的故障转移，受 TTL 和解析器缓存的影响，因此比 Global Accelerator 的数据平面故障转移要慢——对于可以容忍一分钟 DNS 传播延迟的简单主-备模式，选择故障转移路由；当您需要秒级切换时，选择 Global Accelerator。

这些策略可以组合使用。一个常见的全局模式是：使用 Route 53 的延迟或地理邻近记录指向 Global Accelerator（用于 TCP/UDP）或 CloudFront（用于可缓存的 HTTPS），其下再配置带有健康检查的故障转移记录作为安全网。这种分层是精心设计的：Route 53 选择区域，Global Accelerator 或 CloudFront 选择边缘站点和骨干网路径，而区域性负载均衡器则选择区域内的目标。

API Gateway 终端节点类型和自定义域

API Gateway 提供三种具有不同拓扑的终端节点类型：

边缘优化的终端节点将 API 包装在一个由 AWS 托管的 CloudFront 分配中，您无法直接配置它。这对于快速实现全球访问很方便，但当您想要自定义缓存行为、WAF 规则或源请求策略时，限制就很大。为了获得最大控制权，最典型的模式是使用客户管理的 CloudFront 分配来代理一个区域终端节点。

证书的放置遵循 CloudFront 的规则：边缘优化的自定义域需要在 us-east-1 区域中申请 ACM 证书；区域终端节点则需要在与 API 相同的区域中申请证书。HTTP API 强制要求最低 TLS 1.2；REST API 支持最高到 TLS 1.3 的安全策略。

ACM 证书：颁发、验证与导入

ACM 免费颁发并自动续订公共 TLS 证书，并直接与 CloudFront、API Gateway、ALB、NLB 及其他 AWS 服务集成。验证方式有两种：DNS 验证（ACM 会提供一个 CNAME 记录，您可以将其放置在 Route 53 或任何 DNS 提供商中；只要该记录存在，ACM 就会永久自动续订）或电子邮件验证（每次续订都需要手动点击，对于自动化来说很脆弱）。对于任何生产环境，DNS 验证都是正确的默认选择。

ACM 颁发的证书无法导出，也不能在集成的 AWS 服务之外使用。当法规或业务要求强制使用特定的第三方 CA 时——例如，一个 REST API 必须链接到某个特定的商业颁发机构并强制执行 TLS 1.3——您就不能使用 ACM 颁发的证书。您需要从指定的 CA 获取证书，然后将其导入到 ACM 中，再将其附加到具有 TLS 1.3 安全策略的区域性 API Gateway 自定义域。

导入证书有两个陷阱：导入的证书不会自动续订（必须在过期前重新导入，否则端点会彻底失效），并且 ACM 在导入时不会验证证书链——损坏的中间证书只会在真实客户端进行握手时才会暴露出来。在上线前，请使用严格的客户端测试完整的证书链。

S3 Transfer Acceleration 与 CloudFront 对比

CloudFront 优化下载；S3 Transfer Acceleration 优化上传。Transfer Acceleration 反向使用相同的 CloudFront 边缘网络：PUT 请求从最近的边缘节点进入，然后通过 AWS 骨干网传输到目标存储桶所在的区域。当全球分散的用户将大对象上传到单个区域的存储桶时，该功能效果显著——例如，世界各地的现场工程师将数 GB 大小的图纸上传到 us-east-1。

这两个功能可以在同一个存储桶上共存：启用 Transfer Acceleration，并为下载配置一个带有 OAC 的 CloudFront 分发。对于小对象或已经靠近存储桶所在区域的客户端，Transfer Acceleration 只会增加成本而没有收益——在决定使用前，请使用 S3 Transfer Acceleration 速度比较工具进行测量。客户端必须使用 s3-accelerate 端点才能启用加速功能。

使用 AWS WAF 提供第 7 层保护

AWS WAF 在 HTTP(S) 请求到达受保护资源之前对其进行检查。它可以附加到 CloudFront 分发、ALB、API Gateway 阶段、AppSync API、Cognito 用户池、App Runner 服务和 Verified Access 实例。一个 Web ACL 包含多种规则，可基于 URI、标头、查询字符串、正文（默认为 8 KB，在 ALB/API Gateway 上可扩展至 64 KB）、IP 集和地理位置进行匹配。

最常见的构建块是 AWS 托管规则：AWSManagedRulesCommonRuleSet 和 AWSManagedRulesKnownBadInputsRuleSet 涵盖了 OWASP 的主要漏洞利用；AWSManagedRulesSQLiRuleSet 和 XSS 匹配语句处理注入攻击。自定义规则可以添加地理位置匹配（用于合规的国家白名单/黑名单）、IP 集匹配以及基于速率的规则——该规则在五分钟的滚动窗口内统计每个源 IP 的请求数，一旦超过阈值就进行阻止。基于速率的规则是抵御 HTTP 洪水攻击和凭证填充攻击的第一道防线：

{
  "Name": "LoginRateLimit",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 500,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/login",
          "FieldToMatch": {"UriPath": {}},
          "PositionalConstraint": "STARTS_WITH",
          "TextTransformations": [{"Priority":0,"Type":"NONE"}]
        }
      }
    }
  },
  "Action": {"Block": {}}
}

区域规则很重要。 用于 CloudFront 的 Web ACL 是全局性的，必须在 us-east-1 区域创建。用于区域性资源（ALB、API Gateway 等）的 Web ACL 则在资源所在的区域创建。

要保护 S3 上的静态网站，您不能将 WAF 附加到存储桶上——S3 不是 WAF 支持的资源。正确的模式是在存储桶前部署 CloudFront + OAC，并将 Web ACL 附加到该分发上。存储桶只能通过 CloudFront 访问，这才能真正做到“检查所有流量”。

使用 Firewall Manager 进行多账户 WAF 治理

逐个账户地管理 WAF 无法扩展。在一个组织中，如果某个团队启动了一个新的 ALB 却没有附加公司的基线规则，合规状态就会在不知不觉中倒退。AWS Firewall Manager 通过对范围内的账户和资源强制执行组织范围的策略来解决这个问题。

先决条件：启用所有功能的 AWS Organizations、一个指定的 Firewall Manager 管理员账户，以及在每个成员账户中启用 AWS Config。策略类型涵盖 AWS WAF、AWS Shield Advanced、安全组（审计和使用）、Network Firewall、Route 53 Resolver DNS Firewall 以及第三方防火墙。

WAF 策略可以强制执行一个“首要”规则组（在应用程序自有规则之前评估）、一个“末尾”规则组（在之后评估），或者完全替换 Web ACL。匹配资源范围的新 ALB 或 CloudFront 分发会自动接收公司规则集，不合规的资源会被标记，并根据修复设置自动修复。每当场景中提到“多个账户”、“集中管理”或“在整个组织中保持一致的 WAF 规则”时，答案都是 Firewall Manager，而不是逐账户配置 WAF。

Shield Standard 与 Shield Advanced 对比

认为单靠 WAF 就能阻止 DDoS 是一个严重的错误。WAF 对到达它的请求进行操作——它在应对应用层洪水攻击、凭证填充和已知漏洞利用签名方面表现出色——但第 3/4 层的大规模容量攻击（如 SYN 洪水、UDP 反射）则由 AWS Shield 来吸收。

Shield Standard 默认免费开启。它能自动防御常见的 L3/L4 攻击，适用于 CloudFront、Route 53 和 Global Accelerator，并为 ELB、EC2 和其他资源提供基础保护。它不提供针对特定攻击的可见性、Shield Response Team 的介入支持或成本保护。

Shield Advanced（每个组织每月 3000 美元，一年承诺期）增加了以下功能：

认为 Shield Standard 足以应对“需要成本保护和专家响应的大规模 DDoS”是错误的，这正是因为 Standard 缺乏可见性、成本保护和 SRT 访问权限。当源站是 ELB 后面的 EC2，且 DNS 由第三方提供（因此无法使用 Route 53 别名记录的技巧）时，推荐的模式是在 ELB 上启用 Shield Advanced，并使用 CloudFront（同样受 Shield Advanced 保护）作为应用的前端，从而将缓解边界移至边缘，并缩小到达区域的攻击面。

正确的的分层防御态势是：使用 Shield 应对 L3/L4 容量攻击，使用 WAF 进行 L7 过滤，使用 CloudFront 或 Global Accelerator 作为边缘入口点并与之集成，最后使用 Firewall Manager 在所有账户中强制执行策略。

← 网络与连接 · 所有领域 · 数据库与缓存 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Amazon →