Amazon SOA-C02: 網路與內容交付 — 學習指南

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

「網路與內容交付」涵蓋了 VPC 基礎、混合式連線、DNS 與全球路由、使用 CloudFront 的邊緣快取，以及 TLS 憑證生命週期 — 這一切對於可用性、安全性與效能都至關重要。營運上的熟練能確保工作負載無論在本地端或雲端，都是可連線、具備故障恢復能力且安全的。本節著重於實用的組態設定模式、CLI/主控台範例，以及您作為支援生產環境系統的 SysOps 管理員會用到的決策標準。

VPC 設計、子網路、路由與連線能力

設計 VPC CIDR 空間時需考量未來的成長：分配一個足夠大的 VPC (例如，根據規模大小選擇 /16 或 /20)，並將其分割為各個 AZ 內的子網路 (例如，每個 AZ 使用 10.0.0.0/24, 10.0.1.0/24)，以避免跨 AZ 的相依性。為每種子網路類型建立明確的路由表：公有子網路使用一條通往 Internet Gateway (IGW) 的路由 — 例如，

undefined

；私有子網路將 0.0.0.0/0 路由到同一個 AZ 中的 NAT Gateway，以獲得可預測的出口成本和較低的延遲。

了解 NAT 的行為和路由的細微之處：NAT Gateway/Instance 會對向外的 IPv4 連線執行來源 NAT，並要求回傳的流量遵循子網路的路由表，經由 NAT 回來。對於 IPv6，請使用僅供輸出的網際網路閘道 (egress-only internet gateway)。使用 AWS CLI 建立 NAT Gateway 並關聯 Elastic IP：

undefined

。搭配 Transit Gateway 或 VPN 附件使用路由傳播 (route propagation)，以自動管理動態路由。

Security groups 與 NACL 的比較以及流量的走向必須經過深思熟慮：security groups 是 stateful (有狀態的) (您允許傳入流量，回傳流量會自動放行)，且附加到 ENI 上；NACL 是 stateless (無狀態的)，並以子網路為單位依序評估規則，因此您必須同時允許傳入和傳出的臨時埠 (ephemeral ports)。範例指令：

undefined

；

undefined

。決策標準：使用 security groups 進行執行個體層級的存取控制，而 NACL 則用於邊界防護、高效能過濾和跨帳戶隔離。

VPN、Direct Connect 與混合式網路

根據頻寬、延遲和彈性需求來選擇連線方式。Site-to-Site VPN 透過網際網路提供加密的 IPsec 通道，且能快速部署，可使用

undefined

。設定兩個 VPN 通道以實現 HA；使用 BGP 進行動態路由，並透過 Virtual Private Gateway 或 Transit Gateway 進行路由傳播。使用 AWS Managed VPN 進行快速部署，並作為 Direct Connect 的故障轉移備援。

Direct Connect 提供私有、高頻寬、低延遲的連線。使用 Direct Connect 主控台佈建一個連線 (或 LAG)，並透過 Direct Connect Gateway 建立私有虛擬介面 (VIF) 連接到 VPC，以實現多區域存取。使用 BGP 搭配適當的 ASN，並優先考慮 DX + VPN 的混合模式：透過 DX 公告關鍵的字首，並將 VPN 作為自動備援。決策標準：

• 對於短期、中低頻寬需求，或需要基於網際網路的加密備援時，使用 VPN。
• 當持續的高吞吐量和可預測的延遲，證明其連接埠和交叉連線 (cross-connect) 成本是值得的時候，使用 Direct Connect。
• 如果您需要 hub-and-spoke 的規模擴展和簡化的路由管理，可使用 Transit Gateway 來集中管理多個 VPC 和本地端的連線。

營運檢查清單：確認 BGP 會話 (session) 已建立，確保路由表已傳播 (對於 TGW，可使用

undefined

)，並透過關閉一個通道或切換 BGP 路徑來測試故障轉移。

Route 53 DNS、運作狀態檢查與路由政策

Route 53 既是權威 DNS (authoritative DNS)，也是一個路由控制平面。為端點 (HTTP/HTTPS/TCP) 實作運作狀態檢查，並將其與故障轉移 (failover) 或加權 (weighted) 記錄配對。範例：在 Route 53 主控台上建立一個具有主要/次要記錄類型的故障轉移記錄，或使用

undefined

搭配 Failover 路由政策和一個 HealthCheckId。根據預期的故障轉移 SLA 來調整 TTL — 對於主動式故障轉移使用較低的 TTL (30-60秒)，對於穩定的端點則使用較長的 TTL (300秒以上)。

根據意圖選擇路由政策：

• 簡易 (Simple)：回傳單一值；用於非關鍵或單一端點。
• 故障轉移 (Failover)：主要/次要端點搭配運作狀態檢查，用於災難處理。
• 加權 (Weighted)：用於藍/綠部署或金絲雀部署的漸進式流量轉移。
• 延遲 (Latency-based)：將使用者路由到延遲最低的區域。
• 地理位置/地理鄰近性 (Geolocation/geoproximity)：用於遵循資料落地或提供目標式內容。

決策要點：

• 對於具有 active-active 區域和 ELB 的全球應用程式：使用指向 ALB/ELB 的 Alias 記錄，以避免額外費用並利用端點的運作狀態。
• 對於計畫性的遷移或流量塑形：使用加權記錄，並透過 CLI (

undefined

) 逐步變更權重。

• 為了從資料中心故障中快速恢復：使用故障轉移路由搭配低 TTL 和穩健的運作狀態檢查。

CloudFront CDN、快取策略與失效處理

CloudFront 透過在邊緣站點 (edge locations) 快取內容來加速，並減少來源伺服器 (origin) 的負載。您可以依據路徑模式設定快取行為 (Cache Behaviors)；使用來源伺服器發出的 Cache-Control 和 Expires 標頭來控制快取，或是在 distribution 設定中透過轉發值 (Forwarded Values) 和最小/最大 TTL 來覆寫。使用 Origin Shield 來減少多個邊緣站點對來源伺服器造成的負載。

關鍵快取策略：

• 靜態資產：使用長的 TTL，並透過指紋碼 (fingerprinting) (即物件版本控制) 的方式，讓失效處理變得非必要。
• 動態內容：設定 Cache-Control: no-cache 或極短的 TTL，並使用 Lambda@Edge 或快取策略 (Cache Policy) 根據標頭/Cookie 選擇性地快取。
• API：考慮使用區域性快取 (API Gateway + CloudFront) 並搭配短 TTL。

失效處理與管理模式：

• 使用

undefined

或

undefined

來立即移除快取；請注意，大範圍的模式會產生失效處理成本。

• 優先使用物件版本控制 (更改檔名或使用查詢字串版本)，以避免頻繁的失效處理。
• 確保來源伺服器設定正確：S3 來源應使用 Origin Access Control (OAC) 或 OAI 鎖定，以便只有 CloudFront 可以讀取；對於 ALB 來源，請確保健康檢查和黏性會話 (stickiness) 設定與 CloudFront 的行為一致。

TLS 憑證、ACM 與憑證生命週期

使用 AWS Certificate Manager (ACM) 為 ELB、CloudFront 和 API Gateway 佈建憑證。使用

undefined

請求公開憑證，並採用 DNS 驗證，這能讓憑證自動續期。重要：CloudFront 需要使用位於 us-east-1 區域的 ACM 憑證；區域性服務 (如 ALB、API Gateway regional) 則需要使用目標區域的憑證。

驗證與輪替模式：

• DNS 驗證能自動化續期，是生產環境的首選方法；可透過主控台或

undefined

在 Route 53 中建立 CNAME 記錄。

• 對於手動或匯入的憑證，請使用

undefined

，並透過

undefined

來追蹤到期日。

• 輪替憑證的方式是將新憑證與舊憑證並行部署 (例如，同時加入到 ALB 或 CloudFront distribution)，驗證流量後，在舊憑證到期前將其移除。

決策標準：對於附加到 AWS 受管端點的公開憑證，請使用 ACM。僅在需要私有 CA 或外部信任錨點時，才使用匯入的憑證。

常見陷阱與決策標準

• 不正確的安全群組或路由表規則導致執行個體無法連線 — 驗證安全群組的傳入和傳出規則，以及路由表中

undefined

的條目；請記住，安全群組 (security groups) 是有狀態的，而 NACL 是無狀態的，需要明確允許臨時埠口 (ephemeral port)。

• DNS TTL 設定錯誤導致故障轉移後出現過時的路由 — 根據故障轉移的窗口時間設定 TTL (對於主動故障轉移使用短 TTL)，並啟用健康檢查來測試故障轉移。
• 忽略 CloudFront 來源設定和 OAC/OAI — 鎖定 S3 來源，使儲存貯體不公開，並確保 CloudFront 的來源身分可以讀取物件。
• 僅依賴 Direct Connect 而沒有 VPN 備援 — 務必建構 DX + VPN 的混合架構以實現彈性，並驗證 BGP 的故障轉移行徑。
• 僅在單一 AZ 放置 NAT Gateway — 應為每個 AZ 建立 NAT Gateway，以避免跨 AZ 的資料路徑和單一 AZ 的出口故障。
• 忘記 ACM 對於 CloudFront 的區域規則 — 為 CloudFront 請求的公開憑證必須在 us-east-1；聯合或區域性服務則需要區域性憑證。

實務問題：使用情境

AcmePayments 公司營運一個全球支付應用程式，其架構包含區域性的 ALB、一個由 S3 支援的靜態網站，以及一個需要高吞吐量結算連結的本地資料中心。他們需要可預測的延遲、安全的靜態內容分發，以及在某個區域效能下降時的快速故障轉移。

1. 設計 VPC，包含每個 AZ 內的公有和私有子網路；為每個 AZ 部署 NAT Gateway，並設定路由表，使私有子網路透過本地的 NAT 進行出口通訊。
2. 佈建一條 Direct Connect，透過私有 VIF 連接到最近的 Region，並設定一條備援的 Site-to-Site VPN 作為自動故障轉移，使用 BGP 並將路由適當傳播到一個 Transit Gateway。
3. 對 ALB 使用 Route 53 的延遲型路由 (latency-based routing)，並為關鍵端點設定健康檢查和低 TTL；實作加權記錄 (weighted records) 以進行分階段的故障轉移測試。
4. 為靜態網站部署 CloudFront，其 S3 來源透過 Origin Access Control 保護，並設定長 TTL 加上物件版本控制以避免失效處理；使用 Lambda@Edge 進行必要的標頭操作。
5. 透過 DNS 驗證請求 ACM 憑證 (CloudFront 的憑證需在 us-east-1)，並將新憑證與現有憑證並行部署以進行藍/綠部署輪替，然後在舊憑證到期前將其移除。

理由：這些步驟隔離了故障域 (failure domains)，提供了低延遲的全球路由，在邊緣安全地快取靜態資產，並確保憑證生命週期是自動化且無中斷的 — 這符合營運可用性與安全性的最佳實踐。

← 安全性、身分與合規性 · 所有領域 · 儲存與資料管理 →

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

瀏覽 Amazon →