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 個節點 (points of presence) 上。它的工作是在最接近的邊緣節點終止檢視者的 TLS 連線，並立即提供快取的回應，或將快取未命中 (cache misses) 的請求透過 AWS 的私有骨幹網路代理到來源 (origin)。效能上的好處是雙重的：快取命中 (cache hits) 將來回時間 (round-trip time) 縮短到個位數毫秒，並完全卸載來源的負載；而快取未命中仍然能從邊緣節點上優化的 TLS/TCP 終止、HTTP/2 和 HTTP/3 支援、與來源之間保持連線 (keep-alive) 的重複使用，以及避免嘈雜公用網際網路的骨幹網路傳輸中獲益。

一個常見的誤解是 CloudFront 只加速靜態資產。即使將 ALB 放在 CloudFront 後方並使用 CachingDisabled 策略，仍然能改善動態 API 的效能，因為檢視者的交握 (handshake) 是在本地 PoP 完成，而不是穿越整個網際網路到達來源所在的 Region。如果再結合一個混合型的工作負載——例如 /static/* 由 S3 提供，而 /api/* 由 ALB 提供——那麼一個 distribution 就可以同時處理這兩種情況：

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 的 alias 記錄會將 www.example.com 指向 distribution 的 d123.cloudfront.net——alias 記錄是免費的，並且會直接解析到 CloudFront 的 anycast IP。

憑證存放在 us-east-1

對於任何在自訂網域上提供服務的 CloudFront distribution，其面向檢視者的 TLS 憑證在 AWS Certificate Manager 中 必須在 us-east-1 (N. Virginia) 區域簽發，無論來源儲存貯體、ALB 或使用者位於何處。CloudFront 是一個全球性服務，其控制平面 (control plane) 固定在 us-east-1；邊緣節點會從該 Region 拉取憑證。因為您的 S3 儲存貯體恰好在 eu-west-1 就去該區域申請 ACM 憑證是一種錯誤的模式——distribution 將永遠看不到它。

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

如果您在 CloudFront 和 ALB 來源之間進行第二次 TLS 終止，那麼該面向來源的憑證就存放在 ALB 所在的 Region。只有面向檢視者的憑證被鎖定在 us-east-1。同樣的規則也適用於 API Gateway 邊緣優化 (edge-optimized) 的自訂網域（其內部使用 AWS 管理的 CloudFront distribution）：憑證必須在 us-east-1。相對地，區域性 (Regional) API Gateway 端點則使用 API 本身所在 Region 的憑證。

針對 S3 來源的 Origin Access Control

將 S3 儲存貯體放在 CloudFront 後面，卻又讓儲存貯體保持公開，這樣就失去了意義：檢視者可以直接存取 S3 REST 端點來繞過 CloudFront，從而規避了 WAF、地理限制、簽章 URL 和快取帶來的好處——並可能暴露資料。

現代的解決方案是 Origin Access Control (OAC)，它取代了舊版的 Origin Access Identity (OAI)。OAC 使用 SigV4 簽章，支援 SSE-KMS，適用於所有 S3 Region（包括 2022 年後推出的），並支援動態請求。「封鎖公開存取」保持開啟，不需要 ACL，且儲存貯體政策只授予 CloudFront 服務主體讀取權限，並由特定的 distribution 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。加上指紋 (Fingerprinted)、不可變的資產應該積極地快取；引用這些資產的 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 會退回到使用 distribution 的預設 TTL，並可能在無聲無息中將動態回應快取數小時。第二，在 應該 被快取的資產上全面使用 Cache-Control: no-cache，會迫使每個請求都回到來源，從而使 CDN 失去作用。

最危險的陷阱是在沒有適當標頭的情況下快取個人化回應。如果 /account/dashboard 回傳了特定於使用者 A 的 HTML，但來源省略了 no-store，且快取策略沒有將身份驗證標頭或 cookie 包含在快取金鑰 (cache key) 中，那麼邊緣節點會很樂意地將使用者 A 的頁面提供給使用者 B。要麼將這類回應標記為 private, no-store，要麼將會話識別碼包含在快取金鑰中，並接受較低的命中率。

在一個成本優化的情境中，若一個由 EC2 隨需執行個體組成的 Auto Scaling 群組正在提供靜態內容，正確的重新設計是將這些資產移至 S3，在前面加上帶有 OAC 的 CloudFront，然後移除或縮小該 ASG。這會將成本從按小時計費的運算轉移到按請求計費的交付，對於靜態工作負載來說，後者要便宜好幾個數量級。

簽章 URL、簽章 Cookie 與地理限制

CloudFront 支援 簽章 URL (對單一物件提供有時間限制、可選用 IP 限制的存取——例如購買的影片下載、一次性的 PDF 連結) 和 簽章 Cookie (對符合路徑模式的多個物件提供存取——例如已驗證的訂閱者瀏覽目錄)。兩者都使用一個受信任的金鑰群組 (trusted key group)，其公鑰被上傳到 CloudFront；私鑰則用來簽署一個指定到期時間、來源 IP 範圍或 URL 模式的政策。

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

這與 S3 預先簽章 URL (presigned URL) 不同，後者會繞過 CloudFront 並直接授予儲存貯體的存取權限。將 CloudFront 簽章 URL 與 OAC 搭配使用，儲存貯體就能保持端到端的私有。

地理限制 (Geo-restriction) 在 distribution 層級強制執行國家層級的允許清單或封鎖清單，這是在請求到達快取或來源之前進行的。它使用 CloudFront 維護的 GeoIP 資料庫，是強制執行授權禁令的一種低成本、無法繞過快取的方法。若需要更精細的邏輯（例如州層級、標頭組合），請使用 CloudFront Function 或 Lambda@Edge；若需要完整的規則引擎，請使用 WAF。

AWS Global Accelerator

Global Accelerator 不是 CDN，也不會進行快取。它會佈建兩個靜態的 anycast IPv4 位址（或使用 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 處理連線。三種策略主導了全球架構。

延遲型路由 (Latency-based routing) 會測量從解析器位置到每個區域的實際網路延遲，並回傳最快的那個。當您在多個區域有相同的堆疊，並希望使用者被導向當下對他們最快的區域時，請使用此策略。

地理鄰近性路由 (Geoproximity routing) 是基於座標而非延遲：您宣告每個端點的位置（或 AWS 區域），Route 53 會將使用者傳送到地理上最近的端點。其獨特功能是偏差 (bias) 值（-99 到 +99），可用於擴大或縮小有效的服務區域——這在區域性服務上線時逐步轉移流量，或為了維護而清空一個區域的流量時很有用。地理鄰近性路由需要使用 Route 53 traffic flow（流量策略），且通常與每個區域的區域性 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

容錯移轉路由 (Failover routing) 使用與運作狀態檢查綁定的主要/次要配對。這是 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 vs. 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 進行第七層保護

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 的方式無法規模化。在一個 Organization 中，若有團隊建立了一個新的 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 是針對到達它的請求進行操作——它對於應用程式層的洪水攻擊、憑證填充 (credential stuffing) 和已知的漏洞利用簽章非常有效——但是大規模的第 3/4 層 (L3/L4) 容量攻擊 (volumetric attacks)，例如 SYN floods 和 UDP reflection，則是由 AWS Shield 來吸收。

Shield Standard 預設開啟且無需額外費用。它會自動防禦常見的 L3/L4 攻擊，並適用於 CloudFront、Route 53 和 Global Accelerator，同時也為 ELB、EC2 和其他資源提供基本保護。它不提供針對特定攻擊的可見性、Shield Response Team 的介入支援，或成本保護。

Shield Advanced (每個組織每月 3,000 美元，需承諾一年) 增加了以下功能：

認為 Shield Standard 足以應對「具備成本保護和專家應對的大規模 DDoS」是錯誤的，這正是因為 Standard 版本缺乏可見性、成本保護和 SRT 的存取權限。當來源 (origin) 是位於 ELB 後方的 EC2，且 DNS 由第三方管理 (因此無法使用 Route 53 的別名技巧) 時，建議的模式是在 ELB 上啟用 Shield Advanced，並在應用程式前端使用 CloudFront (同樣受 Shield Advanced 保護)，將緩解邊界移至邊緣 (edge)，並縮小到達 Region 的攻擊面。

正確的分層防禦架構是：使用 Shield 應對 L3/L4 的容量攻擊，使用 WAF 進行 L7 過濾，使用 CloudFront 或 Global Accelerator 作為這兩項服務所附加的邊緣進入點，並使用 Firewall Manager 在所有帳戶中強制執行此策略。

← 網路與連線 · 所有領域 · 資料庫與快取 →

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

瀏覽 Amazon →