Amazon SAP-C02: 網路與混合式連線 — 學習指南

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

VPC 架構與分段模式

設計 VPC 拓撲始於爆炸半徑管理和可預測的路由。對於小型部署，一個擁有多個子網路和嚴格 security groups 的單一 VPC 可能很有效率，但隨著團隊和應用程式的增長，單一 VPC 模式會變得脆弱：資源配額、跨團隊治理以及「吵雜鄰居」問題會增加營運風險。每個團隊多個 VPC 或每個團隊一個帳戶的模型改善了隔離性和 IAM 邊界；使用 AWS Organizations 為不同團隊建立獨立帳戶，並設立一個共享服務帳戶來處理 DNS、日誌記錄和身份識別。對於 VPC 之間的連線，VPC peering 雖然簡單且延遲低，但它不具備可轉移性，且大規模部署時營運負擔很重。Transit Gateway (TGW) 取代了「transit VPC」模式：它支援數千個附件、集中化路由表，並簡化了多點傳播或 hub-and-spoke 模式。PrivateLink (Interface VPC Endpoints) 能實現服務層級的隔離，無需將服務暴露於網際網路，這對於跨帳戶的微服務至關重要。常見的陷阱包括僅依賴 security groups 進行分段（它們是 stateful 的，對於東西向流量過濾而言粒度太粗）、忘記 NACL 的 stateless 行為，以及未規劃 CIDR 分配（重疊的 CIDR 會阻礙 peering 和 DX 的運作）。決策取決於成本與可管理性之間的權衡：TGW 有附件成本，但降低了每個 peering 的複雜性；多帳戶隔離雖然增加了 landing zone 的開銷，但降低了爆炸半徑。務必記錄 CIDR 計畫、路由傳播規則以及共享服務的所有權，以避免組態飄移。

混合雲連線、路由與彈性

混合雲連線的選擇取決於吞吐量、抖動、延遲以及一致的公有出口 IP 位址。對於大量穩定的流量，AWS Direct Connect (DX) 的 private VIFs 提供可預測的頻寬和比 Internet VPN 更低的出口成本；使用 Direct Connect Gateway 來橫跨多個 Region，或附加到 Transit Gateway 以進行集中式路由。Site-to-Site VPN（使用 BGP 的託管式 IPsec）可用於快速設定，或作為 DX 的彈性備援；設定 BGP 時需使用適當的 ASN 和路由優先級，以避免非對稱路由。關鍵的路由陷阱包括地端與雲端 CIDR 重疊、TGW 中不正確的路由傳播，以及假設 peered VPC 之間具有可轉移路由。MTU 和分片問題可能會中斷 VPN 流量——應測試路徑 MTU 並在設備上調整 MSS。對於多 Region 架構，可考慮在多個地點設置 active/active 的 DX，或結合 DX 與 VPN 進行故障轉移。權衡之處：專用 DX 線路成本較高，但能減少抖動和出口費用；VPN 較便宜且簡單，但在高吞吐量下較不穩定。應透過兩個獨立的通道、位於不同地點的備援 DX 連線，以及明確的 TGW 路由表來設計可預測的故障轉移，以控制路徑選擇和限制。

DNS、PrivateLink 與服務連線模式

DNS 是混合雲與多帳戶網路的核心。使用 Route 53 Private Hosted Zones 進行 VPC 範圍內的解析，並使用 Route 53 Resolver 的 inbound/outbound endpoints 來啟用地端與 AWS DNS 之間的條件式轉發。這支援 split-horizon DNS，讓內部名稱解析為私有 IP，而公開紀錄則維持全域性。PrivateLink (interface endpoints) 提供私有的、由 ENI 支援的連線至 AWS 服務或 SaaS 合作夥伴，流量無需繞行公有網際網路；這與用於 S3 和 DynamoDB 的 Gateway Endpoints 不同，後者更便宜且使用路由表而非 ENI。PrivateLink 避免了服務暴露於 VPC CIDR 衝突的風險，並透過服務接受政策支援跨帳戶的消費者。常見的陷阱包括忘記將 private hosted zones 關聯到所有消費者 VPC、未為地端網域建立 Route 53 Resolver 規則，以及低估了每個 endpoint ENI 的 IP 消耗量。決策標準：對於高吞吐量的 S3/DynamoDB 存取，優先選擇 Gateway endpoints 以避免 NAT 成本；當需要以更嚴格的安全性私有存取 API 端點或第三方服務時，則使用 Interface endpoints。應監控 DNS 延遲，並透過變更控制來設定 TTLs，以管理故障轉移行為。

出向流量、NAT 設計、安全控制與維運實務

出向流量架構會影響成本、可稽核性以及與第三方整合。NAT Gateway 為私有子網路提供託管式、高可用性的 IPv4 出向流量，並能依 AZ 自動擴展；NAT Instances 在低吞吐量使用情境下較便宜，但需要維運和故障轉移的腳本。透過連接到 Transit Gateway 的專用出向 VPC 來集中化出向流量，可以強制執行一致的對外 IP、檢查點和簡化的政策，但會引入髮夾彎路由 (hairpin routing) 和潛在的頻寬瓶頸。對於 IPv6，請使用 Egress-Only Internet Gateway。用 AWS Systems Manager Session Manager 取代 SSH 堡壘主機，以利稽核並消除公開的入向憑證；Session Manager 透過 SSM agent 運作，無需開啟 SSH 連接埠。若需進階過濾和 DPI，可在 TGW 後方部署 AWS Network Firewall 或第三方設備。成本與效能的權衡：NAT Gateway 雖然簡單，但會產生每 GB 的費用——使用 VPC endpoint 可減少 S3 的出向流量和 NAT 成本。維運上的陷阱包括：未啟用 VPC Flow Logs 進行流量疑難排解、保留過於寬鬆的出向規則而導致資料外洩、以及使用 SCPs 或 IAM 政策無意中阻擋了生命週期操作；應強制執行最低權限原則，並將所有日誌記錄到中央帳戶進行分析。

實務問題：Acme Financial Services — 為第三方白名單建立集中且可預測的出向流量

情境：Acme Financial Services 在兩個 AWS 區域中運行多個應用程式 VPC，這些 VPC 透過 Transit Gateway 互相連接，並透過 Direct Connect 和 VPN 與地端資料中心連接。多個不同帳戶中的應用程式必須呼叫一個合作夥伴的 API，而該 API 只接受來自單一公有 CIDR 區塊的請求。

挑戰：為所有跨區域的應用程式 VPC 提供一個高可用、可稽核的出向路徑，此路徑需具備一個可預測的單一公有 CIDR 區塊，同時要將延遲和維運開銷降至最低。

建議方法：

使用 BYOIP (Bring Your Own IP) 將一個公有 IPv4 CIDR 帶入 AWS，並從該 CIDR 中分配 Elastic IPs 作為出向流量的地址。
在每個區域中建立一個集中式的出向 VPC，並在多個 AZ 中配置 NAT Gateway；將 BYOIP 的 Elastic IPs 與這些 NAT Gateway 關聯，然後將出向 VPC 連接到 Transit Gateway。
更新 TGW 路由表，讓所有應用程式 VPC 將 0.0.0.0/0 路由到出向 VPC 的 attachment，啟用路由傳播和跨 AZ 的健康檢查故障轉移；根據需求設定地端路由，使其優先使用本地的出向路徑。
在出向 VPC 中部署 Network Firewall 或託管式 IDS 進行對外流量過濾，啟用 VPC Flow Logs 和 CloudWatch 警報，並使用 Route 53 Resolver 處理任何 DNS 轉發需求。

基本原理：透過 TGW 和 NAT Gateway 集中化出向流量，並使用 BYOIP 提供的 IP 空間，可以為白名單提供一個可預測的 CIDR，同時保有高可用性和集中監控的能力。這種方法在維運簡易性、安全控制以及合作夥伴對單一公有 CIDR 的要求之間取得了平衡。

← 組織複雜性與多帳戶策略 · 所有領域 · 安全性、身分識別與合規性 →

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