VPC 設定、Subnet、NACL 與私有連線

Amazon VPC 是每一個 AWS 工作負載的基礎骨架，在 SOA-C02 中也是 Domain 5（網路與內容交付，佔全卷 18%）的核心主軸。Task Statement 5.1 的原文是「實作網路功能與連線」——而 SysOps 的考試視角與架構師截然不同。SAA-C03 問的是「哪種網路選項符合這個設計」，SOA-C02 問的是「private subnet 裡的 EC2 instance 無法連到 S3，請列出你會逐一排查的每個步驟」，或是「VPC peering connection 已建立但流量不通，原因為何」，又或是「SSM agent 正常執行，但 instance 不出現在 Fleet Manager——缺少哪個 private connectivity？」。考試想確認的，是你能否設定出一個正常運作的網路，並在不對 0.0.0.0/0 全開的前提下診斷網路故障。

本指南從操作角度帶 SOA-C02 考生走過 VPC 設定與連線：subnets、route tables、internet gateway 和 NAT gateway 如何組合出 public 與 private subnet；stateful 的 security groups 與 stateless 的 network ACLs 在哪裡重疊、ephemeral port 陷阱又在哪裡咬人；Gateway VPC endpoint 什麼時候優於 Interface VPC endpoint，兩者的費用差距；VPC peering 為何不支援 transitive routing，以及何時 Transit Gateway 才是正確的脫身之道；Site-to-Site VPN 端對端實際設定了什麼；以及 Session Manager 搭配 SSM Interface endpoints 如何完全取代公開的 SSH bastion。每個章節以 SysOps 級別的疑難排解思路與考試訊號收尾。

為什麼 VPC 設定是 SOA-C02 Domain 5 的核心

官方 SOA-C02 Exam Guide v2.3 在 Task Statement 5.1 下列出三項技能，每一項都對應本指南的主題：設定 VPC（subnets、route tables、NACLs、security groups、NAT gateway、internet gateway）；設定 private connectivity（Session Manager、VPC endpoints、VPC peering、VPN）；以及設定 AWS 網路保護服務（WAF、Shield——於專屬的 WAF 與 Shield 主題深入介紹）。Task Statement 5.3 再疊加疑難排解，VPC Flow Logs、ELB access logs 和 Reachability Analyzer 就在這裡登場（詳見網路疑難排解主題）。

在 SysOps 層級，問題框架是操作而非架構設計。SAA-C03 問「架構師應為 private VPC 中的 S3 存取選擇哪種 VPC endpoint 類型？」SOA-C02 問「private subnet 中的應用程式在呼叫 S3 時收到 403 Forbidden，security group 已允許 443 outbound，route table 也有 gateway endpoint 路由——還有什麼可能出錯？」答案很少是換一種架構；通常是缺少的 endpoint policy、錯誤的 region、NACL ephemeral port 規則，或是 VPC 的 DNS resolution 旗標未啟用。

VPC 設定是所有其他 Domain 5 主題的插槽。Route 53 health checks 需要網路可達性。CloudFront origin access control 需要 VPC 作為 origin。WAF 附加到住在 subnet 裡的 ALBs。網路疑難排解讀取的 VPC Flow Logs，就來自你在這裡設定的 subnet。把 VPC 搞定，Domain 5 其餘部分就順了；搞錯了，每道連線題都是碰運氣。

白話文解釋 VPC Configuration and Connectivity

VPC 術語堆得很快——subnets、route tables、gateways、endpoints、peering、transit。三個類比讓這些概念更容易記住。

類比一：大樓平面圖

VPC 是一棟量身打造的私有辦公大樓。它的 CIDR block 是大樓擁有的門牌號碼段——例如 10.0.0.0/16，涵蓋 10.0.0.0 到 10.0.255.255。Subnet 是大樓的各個樓層，每層對應一個 Availability Zone 翼。Route table 是每個電梯口的樓層指示牌——「要離開大樓（0.0.0.0/0），走大廳正門（IGW）；要前往倉庫（S3 prefix list），搭服務電梯 A（Gateway endpoint）；要拜訪隔棟大樓（peer VPC CIDR），走連棟走廊（peering connection）」。Internet gateway 是大廳正門——對外開放，但只有指示牌指向這裡的樓層才能出去。NAT gateway 是收發室——後棟樓層（private subnet）的住戶可以把寄件交給收發室轉寄、收取回信，但外人無法直接送件進後棟。Security group 是每戶的智慧門鎖，記得你讓誰進來過（stateful——回傳流量自動允許）。Network ACL 是樓層入口的保全閘門，每個人進出都要查驗、沒有記憶（stateless——回傳流量必須在自己的 allow 清單裡，因此需要 ephemeral port 規則）。VPC peering 是兩棟大樓之間的直連走廊，但不允許中繼——你不能穿過 A 棟走廊去到 C 棟。Transit Gateway 是市中心的大型轉運站——每棟大樓只需連接轉運站一次，由它統一處理所有樓棟之間的路由。

類比二：辦公室門禁與訪客管理

Public subnet 是一樓大廳——任何持有正確識別證（security group rule）的人都可以從街上走進來。Private subnet 是有管制的高樓層——沒有直接對外的入口；訪客從大廳進入後搭乘受管理的電梯（NAT gateway）辦理外出事務，但電梯不讓外人進來。Session Manager 是視訊通話門房服務——不必給每位員工一把主鑰匙（SSH key）和一個公開走廊入口（port 22 對外開放），門房透過視訊通話接聽每位授權員工的請求、驗證他們的 IAM 識別證，然後從內部解鎖辦公室門。SSM Interface VPC endpoint 是讓門房不需要外線電話就能運作的內部電話線——辦公樓層完全不需要對外開放。Bastion host 是舊式的門衛亭——曾經很有用，但就 SOA-C02 而言，門房服務已經取代了它。

類比三：郵件分揀中心

Route table 是郵件分揀輸送帶——一封寫著目的地 CIDR 0.0.0.0/0 的信，落入 IGW 出口；一封寫著 S3 prefix list 的信，落入 Gateway endpoint 出口；一封寫著 10.20.0.0/16（peer VPC）的信，落入 peering 出口。最長前綴優先——一封寄往 10.20.5.0/24 的信，會在 /24 分揀帶先被分流，/16 分揀帶根本看不到它。Internet gateway 是開往城市的外送貨車。NAT gateway 是改寫回郵地址的服務站——從 private 樓層寄出的信，都會把回郵地址改成大樓統一地址，回信送回大樓後，服務站再把地址改回原來的樓層。VPC endpoint 是直達特定收件方（S3、DynamoDB、SSM）的專屬快遞專線，完全繞過城市郵局——信件從不離開 AWS 私有網路。VPN tunnel 是外交郵袋——每封信都密封認證後才出樓，只有在合作地點才解密。

VPC 基礎：CIDR Blocks、Subnets、Route Tables、IGW 與 NAT

在任何連線問題說得通之前，你需要對 VPC 各基礎元件如何組合有精確的心智模型。

CIDR blocks 與 subnet 大小

VPC 在建立時選定一個主要 IPv4 CIDR block，大小介於 /16（65,536 個位址）到 /28（16 個位址）之間。之後最多可以新增四個 secondary CIDRs。CIDR block 必須來自 RFC 1918 私有範圍——10.0.0.0/8、172.16.0.0/12、192.168.0.0/16——或者是你自有的非重疊 public 範圍。CIDR 是根本性的設定：建立後無法更改主要 CIDR（你得建立新的 VPC），而且重疊的 CIDR 會使 VPC peering 和 Transit Gateway routing 完全無法運作。

Subnet 是從 VPC CIDR 中劃出的範圍，限定在單一 AZ。一個 /24 subnet 有 256 個位址，其中 AWS 保留五個：網路位址（.0）、VPC router（.1）、DNS（.2）、未來用途（.3）和廣播（.255）。所以一個 /24 subnet 有 251 個可用位址。/28 subnet（最小允許）有 11 個可用位址。SOA-C02 有時會問「團隊需要在一個 subnet 裡容納至少 100 台 instance，最小的 CIDR 是什麼？」——答案是 /25（128 - 5 = 123 個可用位址）。

Public vs private subnet——由 route table 決定

Subnet 若其 route table 有一條 default route 0.0.0.0/0 指向 internet gateway，則為 public；否則為 private。沒有「public subnet」開關；這個屬性由路由決定。

一個 instance 要能從 public subnet 真正連上網際網路，必須同時滿足三個條件：

1. Subnet 的 route table 有 0.0.0.0/0 → IGW。
2. Instance 有 public IP 或 Elastic IP（啟用自動指派 public IPv4，或附加 EIP）。
3. Security groups 和 NACLs 在雙向都允許該流量。

缺少任何一個，instance 的網路連線看起來設定正確但就是不通——這是經典的 SOA-C02 場景。

Route table 運作機制

Route table 是一份路由清單，每條路由都有目的地 CIDR 和目標。最長前綴優先（最精確路由優先）：若 10.0.0.0/16 → local 和 10.0.5.0/24 → peering connection 同時存在，去往 10.0.5.10 的流量會走 peering connection。每個 VPC 都有一個預設的 main route table，所有 subnet 若未明確關聯自訂 route table 就繼承它；SysOps 最佳實踐是為每個 subnet 層建立明確的自訂 route table（public 一張、private 一張或多張），讓 main route table 保持最精簡。

隱含的 local 路由涵蓋整個 VPC CIDR——VPC 內任何 subnet 的 instance 都可以透過 private IP 互相連通，無需額外路由。你無法刪除或修改 local 路由。

Internet gateway

Internet gateway 是水平擴展、冗餘、region 層級的 VPC 元件。不需要調整吞吐量大小，不需要選擇 AZ——每個 VPC 一個 IGW，附加到 VPC，然後在 public route table 中引用它。IGW 對有 public IP 的 instance 執行來源/目的地 IP 轉換，所以一個 public IP 為 54.x.x.x 的 EC2 instance 發出的封包，在網際網路上看起來就是來自 54.x.x.x，即使 instance 內部的 private IP 是 10.0.x.x。

NAT gateway

NAT gateway 讓 private subnet 中的 instance 能主動發起對外連線，同時使其無法接收 inbound 連線。操作重點：

• AZ 範圍：NAT gateway 存在於一個 AZ，使用一個 Elastic IP。要在跨 AZ 環境中達到 HA，每個 AZ 部署一個 NAT gateway，並讓各 AZ 的 private subnet route table 指向同 AZ 的 NAT gateway。
• 計費：按 NAT gateway 存在的時數以及每 GB 處理資料量計費。資料處理費用是驚喜——在高流量下，NAT gateway 可能成為帳單最大的單一項目。
• 頻寬：自動擴展，最高支援 100 Gbps 和每秒 1000 萬封包。
• 位置：放在 public subnet 中，設定 0.0.0.0/0 → IGW；private subnet 的 route table 設定 0.0.0.0/0 → NAT gateway。

傳統的替代方案是 NAT instance——一台自行管理、執行 NAT 軟體的 EC2 instance。流量極低時較便宜，但你要自己負責修補、HA、擴展和關閉 source/destination check。SOA-C02 強烈偏好受管的 NAT gateway，除非是成本敏感的低流量場景。

Security Groups vs Network ACLs：Stateful vs Stateless 與 Ephemeral Port 陷阱

每個 VPC 內部有兩道防火牆，兩者的行為方式根本不同。SOA-C02 對這個差異的考察比 Domain 5 任何其他主題都多。

Security groups——stateful、只有 allow、附加到 ENI

Security group 附加到 Elastic Network Interface（ENI）。它只包含 allow 規則；沒有 deny 規則（拒絕是 allow 缺席的結果）。關鍵在於，security groups 是 stateful 的：若 inbound 規則允許流量進入，回傳流量不論 outbound 規則如何都會自動被允許出去。同樣地，若 outbound 規則允許流量出去，回傳流量也會自動被允許進來。

操作重點：

• 一個 ENI 最多可以附加 5 個 security groups（可提升至 16）。
• 新 SG 的預設 outbound 規則是 allow all；預設 inbound 規則是 deny all（空清單）。
• 規則來源可以是 CIDR 範圍、另一個 security group ID（最實用的模式——「允許來自 sg-web 的 443 port」），或 managed prefix list。
• SG 規則變更立即對現有連線生效。

Security group 相互引用是最佳的操作模式。不用列舉 IP，而是寫「允許來自 sg-app 的 5432 port 到 sg-db」。當 instance 啟動或終止時，規則自動生效；你永遠不需要再次編輯規則。

Network ACLs——stateless、有 allow + deny、附加到 subnet

Network ACL（NACL）附加到 subnet。它包含 allow 和 deny 兩種規則，按規則號碼從小到大依序評估。關鍵在於，NACLs 是 stateless 的：回傳流量不會自動被允許。每個方向都必須明確允許。

Ephemeral port 陷阱就在這裡。當 client 建立一個 outbound TCP 連線時，作業系統會從 ephemeral 範圍中隨機選擇一個來源 port：

• Linux（多數現代發行版）：32768–60999。
• Windows Server 2008+：49152–65535。
• AWS NAT gateway、AWS Lambda、AWS ELBs：1024–65535。

若 client 在 AWS 端，而 NACL 只允許 outbound 到 443 port，卻沒有允許 inbound 在 ephemeral 範圍，則回應封包在 NACL 就被丟棄，即使 security group 設定沒問題。反過來也一樣：一個在有限制 outbound NACL 的 subnet 中的 server，必須允許 outbound 的 ephemeral 範圍，讓它對 client 的回應能送達。

考試正確做法：NACL inbound 和 outbound 都加上一條 TCP 1024–65535 ALLOW 規則，涵蓋所有作業系統和 AWS 服務的 ephemeral return traffic。

操作重點：

• 每個 subnet 只能有一個 NACL（一個 subnet 同時只能關聯一個 NACL，但一個 NACL 可以關聯多個 subnet）。
• 預設 NACL 允許所有 inbound 和 outbound。自訂 NACL 在你加入 allow 規則之前，預設拒絕所有流量。
• 規則號碼在同一個 NACL 內必須唯一；號碼較小的優先評估；第一個符合的規則優先。
• 明確的 deny 規則不能被較高號碼的 allow 規則覆蓋——一旦被 deny，永遠被 deny。

VPC Endpoints——Gateway 類型（S3 與 DynamoDB）

VPC endpoint 是從你的 VPC 到 AWS 服務的私有連線，不需要穿越公共網際網路。有兩種類型，SOA-C02 都會考。

Gateway VPC endpoints——只有 S3 和 DynamoDB

Gateway endpoints 只為兩個服務存在：Amazon S3 和 Amazon DynamoDB。操作重點：

• 免費——Gateway endpoints 不收費。沒有小時費，沒有資料處理費。
• 以 route table 項目設定——建立 endpoint 時，AWS 會在所選的 route tables 中新增一條路由：目的地 = 服務的 prefix list（由 AWS 管理，例如 us-east-1 的 S3 是 pl-63a5400a），目標 = Gateway endpoint。
• Region 範圍——endpoint 只服務同 region 的 S3 buckets 或 DynamoDB tables。跨 region 的 S3 存取仍然走網際網路（或其他路徑）。
• 沒有 security group；存取由 endpoint policy（endpoint 本身的 IAM resource policy）加上 IAM identity policies 和 bucket/table policies 控制。
• 不改變 DNS——instance 仍然使用 S3 的 public hostname s3.region.amazonaws.com，由 route table 把流量私下重新導向。

設定步驟：

1. 在 VPC 中為 com.amazonaws.region.s3（或 dynamodb）服務建立 Gateway endpoint。
2. 將它關聯到需要此 endpoint 的 subnet 的 route tables。
3. 可選擇收緊 endpoint policy（預設：allow all）。常見的 SOA 模式是將 endpoint policy 限制在特定的 bucket ARNs，以防止資料外洩到外部 buckets。

使用理由：成本（S3 流量不再產生 NAT gateway 資料處理費）、安全（流量留在 AWS 網路內）、可靠性（不依賴網際網路）。

S3 NAT gateway 費用陷阱

一個典型的 SOA-C02 場景：帳單出現大量的 NAT gateway 資料處理費用，團隊查詢 VPC Flow Logs 發現大多是流向 52.x.x.x（S3 public IPs）的流量。解法只需一個動作——在相關的 route tables 中加入 S3 的 Gateway VPC endpoint。資料改走 endpoint 而非 NAT，資料處理費消失，應用程式的 URL 不需要任何更改。

VPC Endpoints——Interface 類型（PrivateLink）的其餘服務

其他所有支援 VPC endpoint 的 AWS 服務都使用 Interface VPC endpoint（又稱 AWS PrivateLink）。這是功能更完整、費用更高、彈性更大的類型。

Interface endpoint 運作機制

Interface endpoint 會在你選擇的每個 AZ 中，從 subnet 的 CIDR 中建立一個附有 private IP 的 Elastic Network Interface（ENI）。ENI 是進入點——你的應用程式呼叫服務的正常 hostname，Route 53（endpoint 的 private DNS）將其解析到 ENI 的 private IP，流量就留在 AWS private 網路上。

操作重點：

• 每個 AZ 一個 ENI——在你希望 endpoint 可達的每個 AZ 選擇 subnet。為了 HA，至少啟用兩個 AZ。
• 每個 AZ 按小時計費加上每 GB 資料處理費。在非常高流量下，資料處理費可能接近 NAT 的費用，但對於中等 API 流量，endpoint 通常比 NAT 便宜得多。
• Security group 附加到 endpoint ENI——控制哪些來源可以到達它（通常允許來自應用程式 SG 的 443 port）。
• Endpoint policy 用於 IAM 風格的存取控制。
• Private DNS——啟用時（多數 AWS 服務預設啟用），呼叫 secretsmanager.region.amazonaws.com 或 ssm.region.amazonaws.com 的 instance 會自動解析到 ENI 的 private IP。VPC 必須同時啟用 enableDnsSupport 和 enableDnsHostnames。

SOA-C02 常考的 Interface endpoints

Systems Manager 三元組是測試頻率最高的：

• com.amazonaws.region.ssm — Systems Manager API（Run Command、State Manager、Parameter Store）。
• com.amazonaws.region.ssmmessages — Session Manager 的 shell session 資料通道。
• com.amazonaws.region.ec2messages — SSM agent 舊版通訊所需。

要讓 private EC2 instance 能被 Session Manager 連線而不需要 NAT gateway，這三個 endpoint 都必須存在且可從 instance 的 subnet 連達，security groups 也必須允許 instance 到 endpoint ENIs 的 443 port。

其他常考的 Interface endpoints：kms、secretsmanager、logs（CloudWatch Logs）、monitoring（CloudWatch metrics）、events（EventBridge）、sns、sqs、ec2、ecr.api 和 ecr.dkr（SOA 考試範圍外，但屬於相關背景知識）、lambda。

DNS 解析需求

Private DNS 只有在 VPC 同時啟用 enableDnsSupport 和 enableDnsHostnames 時才有效。若其中一個為 false，試圖解析 secretsmanager.us-east-1.amazonaws.com 的 instance 就不會得到 endpoint 的 private IP——它會得到 public IP，然後呼叫失敗（或若 NAT 存在則走 NAT，違背使用 endpoint 的目的）。這是 SOA-C02 最高頻的陷阱設定之一。

VPC Peering：限制、Non-Transitive Routing 與 Hub 陷阱

VPC peering connection 是兩個 VPC 之間的一對一網路連結，允許它們之間的 private IP 路由。支援跨帳號和跨 region（inter-region peering，自 2017 年起）。

機制與設定

Peering connection 透過 request/accept 握手建立：

1. VPC-A 的擁有者向 VPC-B 發起 peering 請求（同帳號或不同帳號）。
2. VPC-B 的擁有者接受請求。
3. 雙方都在 route table 中加入路由，指向對方 VPC 的 CIDR 到 peering connection ID（pcx-...）。若沒有這些路由，peering 存在但流量不通。
4. 雙方的 security groups 和 NACLs 都必須允許所需的流量。

跨帳號 peering 的請求方和接受方是不同的 AWS 帳號；inter-region peering 時，兩個 VPC 在不同 region，peering 走 AWS 骨幹網路，不走公共網際網路。

Non-transitive routing——最常考的陷阱

VPC peering 不支援 transitive routing。若 VPC-A 與 VPC-B peering，VPC-B 又與 VPC-C peering，VPC-A 無法透過 B 連到 VPC-C，即使你在 A 的 route table 加入指向 pcx-AB 的 C CIDR 路由也一樣。AWS 明確不允許跨 peering connections 轉送流量。讓 A 和 C 通訊的唯一方法是：

• 直接 peer A 與 C（全網狀——在 VPC 數量少時可行，但 N 個 VPC 需要 N(N-1)/2 個連線，超過約 5 個就難以管理）。
• 使用 AWS Transit Gateway 作為中樞（現代解法）。
• 使用第三方傳輸設備（SOA 考試範圍外）。

VPC peering 其他限制

• CIDR 不能重疊。兩個有相同 CIDR（或任何重疊）的 VPC 無法 peer。
• 不支援 edge-to-edge routing——VPC-B 的 IGW、NAT gateway、VPN 或 Transit Gateway，無法透過 peering 讓 VPC-A 存取。Peering 只承載直接的 VPC 對 VPC 流量。
• 預設不解析 DNS——VPC-A 解析 VPC-B 的 private hosted zone 中的 private DNS 名稱，需要明確的 DNS 共享（透過 Route 53 Resolver rules 或啟用 peering 的 DNS 解析）。Peering 本身不傳播 DNS。
• 每個 VPC 最多 125 個 active peering connections（可申請提升）。超過後切換到 Transit Gateway。

AWS Transit Gateway：取代 Peering 全網狀的 Hub-and-Spoke 架構

AWS Transit Gateway（TGW） 是 region 層級的網路傳輸中樞，透過 hub-and-spoke 拓撲連接 VPCs 和本地端網路。它是 peering non-transitive 限制的解答，也是大規模網狀管理問題的解答。

Transit Gateway 存在的原因

N 個 VPC 的全網狀需要 N(N-1)/2 個 peering connections。超過約 5 個 VPC，操作負擔——雙方加路由、追蹤哪個帳號擁有哪條連線、傳播 DNS——就變得難以承受。Transit Gateway 讓你只需把每個 VPC、本地端 VPN 和 Direct Connect 各連接一次，然後透過 TGW route tables 集中控制路由。

操作元件

• Transit Gateway——中樞本身，region 層級，按 attachment 小時數和每 GB 處理流量計費。
• Attachments——VPC attachments（每個 VPC 一個，在所選 subnets 中建立跨 AZ 的 ENIs）、VPN attachments、Direct Connect Gateway attachments、與其他 TGW 的 peering attachments（跨 region）。
• TGW Route tables——控制哪些 attachments 可以路由到哪裡。多個 route tables 讓你實現隔離：production VPCs 只能路由到 production route table，dev VPCs 到 dev table，shared services VPCs 則可從兩者存取。
• Route propagation vs 靜態路由——VPN attachments 可以 BGP propagate 路由；VPC 路由是靜態的。
• Resource Access Manager（RAM）——跨 AWS Organizations 帳號共享 TGW，讓成員帳號的 VPC 可以連接到 TGW，無需擁有 TGW。

跨 region Transit Gateway Peering

不同 region 的 TGW 可以相互 peer，建構全球性的 hub-and-spoke 架構。跨 region 流量走 AWS 骨幹網路。

SOA-C02 選擇 Transit Gateway 的時機

• 「我們有 30 個 VPC，都需要連到一個 shared services VPC」→ TGW。
• 「每對 VPC 之間都有 peering connections，route table 異動難以管理」→ 遷移到 TGW。
• 「一個 spoke VPC 需要透過與另一個 spoke 相同的路徑連到本地端網路」→ TGW 搭配 VPN/DX attachment。

Site-to-Site VPN：IPsec Tunnels、BGP 與 Customer Gateways

Site-to-Site VPN 透過走公共網際網路的 IPsec tunnels，將本地端網路連接到 VPC。它是成本低、彈性高的混合連線路徑；AWS Direct Connect 是費用更高的專線替代方案（在 SOA-C02 中不做深入考察）。

元件

• Customer gateway（CGW）——本地端設備：一台有 public IP 的實體或虛擬 VPN 設備。AWS 以 CGW resource 的形式記錄其 IP 和 BGP ASN。
• Virtual private gateway（VGW）——附加到單一 VPC 的 AWS 端 VPN concentrator。或：
• Transit Gateway VPN attachment——直接把 VPN 附加到 TGW，實現多 VPC 的混合連線。
• VPN connection——將 CGW 與 VGW（或 TGW）配對，建立兩條 IPsec tunnels（用於跨 AWS 資料中心的冗餘），並產生一份你載入本地端 VPN 設備的設定檔。

每條 VPN connection 有兩條 IPsec tunnels

每條 Site-to-Site VPN connection 都會佈建兩條 tunnels，分別連到同 region 中不同資料中心的兩個不同 AWS public IP 端點。這是為了 HA：一條 tunnel 失效不影響服務。要達到完整 HA，你還需要在本地端設定第二台 customer gateway（獨立的實體設備、獨立的 ISP）和第二條 VPN connection——這樣就有四條 tunnels。

靜態路由 vs BGP

兩種路由模式：

• 靜態——在 VPN connection 設定中列出本地端可達的 CIDR blocks；AWS 在 VGW/TGW route table 中加入路由；本地端設備同樣設定靜態路由。
• BGP（動態）——本地端設備與 AWS 端點執行 BGP，廣告本地端 CIDRs 並學習 VPC CIDRs。BGP 能實現 tunnels 之間的自動故障切換和動態路由傳播。

SOA-C02 在任何強調「自動故障切換」或「動態路由」的場景中偏好 BGP，在「簡單的單一 tunnel 低流量站點」時選靜態。

Pre-shared key

每條 tunnel 使用一個 pre-shared key（PSK） 進行 IPsec 認證。AWS 會產生預設 PSK，但允許你在建立 VPN connection 時自行設定；對於安全團隊要自行掌控金鑰生成的合規場景，這是你需要的設定。

Site-to-Site VPN 疑難排解清單

當 VPN connection 在 AWS console 顯示連線成功，但本地端流量仍無法通過：

1. AWS console 中兩條 tunnels 都顯示 UP？若只有一條 UP，流量仍然可以通，但冗餘已喪失。
2. AWS 端的 route table 有本地端 CIDR 指向 VGW（或 TGW）的路由嗎？若沒有啟用 route propagation，BGP 學到的路由不會自動出現。
3. 本地端設備的 tunnel interfaces 有依照 AWS 提供的設定檔設定 inside IPs 嗎？
4. EC2 instances 的 security groups 允許來自本地端 CIDR 的流量嗎？
5. 相關 subnets 的 NACLs 允許來自本地端 CIDR 的 inbound，以及 outbound 的 ephemeral 範圍嗎？
6. 本地端防火牆允許 outbound 到 AWS VPN endpoint IPs 的 ESP（IP protocol 50）、UDP 500（IKE）和 UDP 4500（NAT-T）嗎？

Session Manager：完全取代 SSH Bastion

對 SOA-C02 而言，AWS Systems Manager Session Manager 是「如何在不使用 SSH 或 bastion host 的情況下管理 private subnet 中的 EC2 instances？」的標準答案。它也是 Domain 3 和 Domain 5 中測試頻率最高的 SSM 場景之一。

Session Manager 取代什麼

傳統模式：public subnet 中有一台對公司 IP 範圍開放 22 port 的 public bastion host（跳板機）。工程師 SSH 到 bastion，再從 bastion SSH 到 private subnet 的 instances。操作痛點：SSH key 的派發和輪換、bastion host 的強化和修補、稽核日誌分散各處、bastion 的 public IP 暴露、即使範圍縮小 port 22 仍然對外開放。

Session Manager 以下列方式取代這一切：

• 瀏覽器或 AWS CLI 的 shell 存取，不需要 SSH client，不需要 SSH keys。
• 目標 instance 不需要 public IP。
• 目標 instance 的 security group 不需要開放任何 inbound port——Session Manager 透過 SSM agent 主動發起的 outbound HTTPS（443 port）連線運作。
• 完整的稽核軌跡，每個按鍵都記錄到 CloudWatch Logs 或 S3。
• IAM 控制存取——使用者需要 ssm:StartSession 權限，instance 必須透過 instance profile 信任 SSM。

Session Manager 對 instance 的要求

• SSM agent 已安裝且正在執行。多數現代 AWS 官方 AMI（Amazon Linux 2 / 2023、Ubuntu LTS、Windows Server 2016+）已預先安裝。
• IAM instance profile 已附加，包含受管政策 AmazonSSMManagedInstanceCore（允許 ssm:UpdateInstanceInformation、messaging APIs 等）。
• 可連到 Systems Manager endpoints 的網路。三個選項：
  • Public subnet 加網際網路路由——agent 透過網際網路連到 ssm.region.amazonaws.com。
  • Private subnet 加 NAT gateway——同上，透過 NAT。
  • Private subnet 加 Interface VPC endpoints（com.amazonaws.region.ssm、com.amazonaws.region.ssmmessages、com.amazonaws.region.ec2messages）——不需要 NAT 或網際網路。

第三個選項是 SOA-C02 認可的「在沒有網際網路存取的 private subnet 中管理 instances」答案。

Session Manager + Interface endpoints——SOA 標準架構

對於需要操作存取的完全 private subnet 工作負載：

1. 在 VPC 中為 ssm、ssmmessages、ec2messages 建立三個 Interface VPC endpoints。
2. 將它們附加到 instances 執行所在的每個 AZ 的 subnet。
3. 在 endpoints 上附加 security group，允許來自 instance security group 的 inbound 443。
4. 將 AmazonSSMManagedInstanceCore 政策附加到 instance role。
5. 確認 instance 出現在 Systems Manager Fleet Manager → Managed instances。
6. 工程師從自己的電腦執行 aws ssm start-session --target i-0abc123（需要適當的 IAM 權限），取得互動式 shell。

沒有 bastion host。沒有 public IP。沒有 22 port。沒有 SSH keys。完整稽核軌跡。

AWS WAF 和 Shield——簡要提及（詳見專屬主題）

Task Statement 5.1 也列出 AWS WAF 和 AWS Shield 作為網路保護服務。這兩個服務的深入說明在 WAF、Shield 與網路保護服務 學習筆記中。在閱讀本指南其餘部分時，有兩個操作重點需要記住：

• WAF 在 Layer 7（HTTP）運作，附加到 CloudFront、ALB、API Gateway 或 AppSync。它不附加到 VPC、NACL 或 security group。它檢查的是請求內容，而不只是 IP/port。
• Shield Standard 對每個 AWS 資源自動提供免費的 L3/L4 DDoS 保護。Shield Advanced 是付費服務，提供額外的 L7 保護、DDoS 引發的擴展費用保護，以及存取 AWS Shield Response Team 的權限。

VPC 基礎元件（subnets、NACLs、security groups）是 Layer 3/4 防禦；WAF 是 Layer 7 防禦；Shield 將兩者包裹起來。專屬主題涵蓋 rate-based rules、managed rule groups、Firewall Manager 多帳號部署和 Global Accelerator 內建的 DDoS 保護。

場景模式：Private Subnet 的 EC2 無法連到 S3

這是 SOA-C02 最典型的疑難排解場景。處理步驟：

1. 確認 instance 有有效的 IAM role。 若 instance profile 沒有授予 s3:GetObject（或任何所需操作），即使網路路徑完全正常也會回傳 403。在 EC2 console → Instance → Security 標籤確認。
2. 確認 security group 允許 outbound 443。 多數預設 SG 允許所有 outbound，但有些團隊會鎖定。SG 必須允許到 S3 prefix list（或 0.0.0.0/0）的 443 port。
3. 確認 NACL 允許 outbound 443 並且允許 inbound 的 ephemeral 範圍（1024–65535）。NACL 是 stateless 的；只有 outbound 443 會讓回應封包卡在 NACL。
4. 確認 route table 有到 S3 的路徑。 透過 NAT gateway（0.0.0.0/0 → NAT，再 NAT → IGW）或 S3 的 Gateway VPC endpoint（S3 prefix list → endpoint）都可以。
5. 若使用 Gateway endpoint，確認 endpoint 已關聯到 subnet 的 route table。 建立 endpoint 但沒關聯到正確 route table，是最常見的設定錯誤。
6. 檢查 endpoint policy。 預設 endpoint policy 是 allow-all；若安全團隊縮限到特定 bucket ARNs，而請求打到不在清單的 bucket，就會被 endpoint 拒絕。
7. 檢查 bucket policy 和 ACL。 要求 aws:SourceVpce = vpce-... 的 bucket policy，會封鎖任何不在指定 endpoint IDs 清單中的存取。
8. 檢查 region。 Gateway endpoints 是 region 範圍——它們只服務同 region 的 bucket。從 us-west-2 的 VPC 存取 us-east-1 的 bucket，不會使用 us-west-2 的 S3 endpoint。

依頻率排列的最常見根本原因：subnet route table 缺少 endpoint 路由、NACL ephemeral port 規則缺失、IAM role 缺失、跨 region bucket 存取。

場景模式：VPC Peering 不路由——Transitive 陷阱

SOA-C02 第二個典型場景。三個 VPC：

• VPC-A 10.0.0.0/16
• VPC-B 10.1.0.0/16
• VPC-C 10.2.0.0/16

A 與 B peering（pcx-AB）。B 與 C peering（pcx-BC）。團隊在 A 的 route table 中加入：10.2.0.0/16 → pcx-AB，期望 A 的流量被路由到 B 再到 C。封包離開 A，到達 B，然後被悄悄丟棄。

診斷步驟：

1. 確認 peering connections 是 Active 狀態。 Pending 或 failed 的 peering 會造成靜默丟包。
2. 檢查每一段的 route tables。 A→B 需要：A 有 10.1.0.0/16 → pcx-AB，B 有 10.0.0.0/16 → pcx-AB。A→C 透過 B 需要：A 有 10.2.0.0/16 → pcx-AB，B 有 10.2.0.0/16 → pcx-BC，C 有 10.0.0.0/16 → pcx-BC。即使三段路由都設好，AWS 也不會跨 peerings 轉送流量。
3. 解法之一：
   • 直接加入 A↔C 的 peering 並設定對應路由。
   • 以 Transit Gateway 取代 peering 全網狀：將 A、B、C 都附加到 TGW，設定 TGW route tables。
   • 若只需要跨 VPC 暴露特定服務，使用 PrivateLink（Interface endpoint 搭配 NLB origin），從 B 把特定服務暴露給 A 和 C，無需完整的網路可達性。

這個陷阱的「啊哈！」在於 AWS 明確記載了 non-transitive 行為——這不是 bug，而是設計如此。請背起來。

常見陷阱：NAT Gateway 按每 GB 計費

高頻的 SOA-C02 費用陷阱。NAT gateway 有兩個計費維度：按小時計費（多數 region 每小時 $0.045）以及按每 GB 處理資料量計費（多數 region 每 GB $0.045）。資料處理費適用於通過 NAT 的每個 byte，雙向都計。

對於每天從網際網路拉取 1 TB 資料的 private subnet，大約是每月 30 TB × $0.045 = $1,350 的資料處理費，還不算小時費。加上 S3 的 Gateway VPC endpoint（免費）或相關 AWS 服務的 Interface endpoint（對大多數流量量而言遠比 NAT 便宜），帳單就會大幅下降。

考試模式：「團隊注意到帳單上 NAT gateway 資料處理費是 $X——最可能的解法是什麼？」答案幾乎總是「為高流量服務加入 VPC endpoint」。

常見陷阱：Gateway Endpoint vs Interface Endpoint 計費差異

考生有時把「VPC endpoint」當作單一概念，忽略費用差異：

• Gateway endpoint（只有 S3、DynamoDB）——免費。沒有小時費，沒有資料處理費。
• Interface endpoint——付費。每個有 endpoint ENI 的 AZ 按小時計費，加上每 GB 資料處理費。

對 S3 和 DynamoDB 一律使用 Gateway endpoint——沒有任何場景下 Interface endpoint 的變體是 SOA-C02 一般存取的正確答案（S3 有 PrivateLink 形式的 Interface endpoint，但費用更高，SOA-C02 很少是正確答案）。

其他所有服務，Interface endpoint 是你唯一的選擇，費用與 NAT 的取捨取決於流量量以及工作負載是否允許網際網路 egress。

常見陷阱：NACL vs SG Deny 覆蓋

這是 SOA-C02 反覆出現的混淆點。Security group 只有 allow 規則；缺少 allow 就是 deny，但任何 SG 都無法表達一個可覆蓋另一個 SG 的明確 deny。NACL 同時有 allow 和 deny 規則；NACL 中的明確 deny 無法被 instance 上的任何 SG allow 覆蓋。

封包流程是：

• Inbound 到 instance：route table → NACL inbound（subnet）→ security group inbound（ENI）→ instance。
• Outbound 從 instance：instance → security group outbound（ENI）→ NACL outbound（subnet）→ route table。

若 NACL deny 了 X port 的 inbound，該 subnet 中任何 instance 上的 SG 都無法接受 X port。這就是 NACLs 的架構使用案例——subnet 層級的封鎖，instance 擁有者無法覆蓋（例如：「在 subnet 層級禁止所有 IP 的 SSH，即使開發者不小心開了 SG 規則 22 from 0.0.0.0/0」）。

SOA-C02 vs SAA-C03：操作視角的差異

SAA-C03 和 SOA-C02 都考 VPC，但視角不同。

SAA 考生選擇架構；SOA 考生設定 route table、開對 port、選對 endpoint，並診斷封包為什麼沒有到達。

考試訊號：如何辨識 Domain 5.1 題目

SOA-C02 的 Domain 5.1 題目有可預測的形式。辨識出來，每題的答題時間就會大幅縮短。

• 「Instance 無法連到網際網路」——檢查 route table 0.0.0.0/0 目的地、public IP/EIP、security group outbound、NACL outbound + ephemeral inbound。
• 「Instance 無法連到 S3 / DynamoDB」——檢查 IAM role、security group、NACL ephemeral、route table 的 Gateway endpoint 或 NAT、endpoint policy、bucket policy 的 aws:SourceVpce 限制。
• 「Instance 無法從 private subnet 連到 Secrets Manager / SSM / KMS 等 AWS API」——檢查 Interface VPC endpoint 是否存在、endpoint 上的 security group 是否允許來自 instance 的 443、VPC 是否啟用 enableDnsSupport 和 enableDnsHostnames、instance subnet 所在的 AZ 是否在 endpoint 的 AZ 清單中。
• 「VPC peering 不把流量轉發到第三個 VPC」——non-transitive 陷阱；改用 TGW 或加入直接 peering。
• 「VPN tunnel 已連上但本地端路由不出現」——在 VPC route table 對 VGW 啟用 route propagation，或檢查本地端 BGP 廣告。
• 「取消 bastion host」——Session Manager + SSM Interface endpoints + AmazonSSMManagedInstanceCore instance profile。
• 「降低 NAT gateway 資料處理費用」——S3/DynamoDB 的 Gateway endpoint（免費）；或高流量 AWS API 的 Interface endpoint。
• 「NACL 允許 outbound 但回應被丟棄」——NACL 的 ephemeral port 範圍 1024–65535 inbound 規則。
• 「Security group 規則無法豁免 deny」——NACL deny 是底線；SG 無法覆蓋。
• 「Route table 異動後連線中斷」——確認 subnet 仍關聯到正確的 route table；確認最精確路由是預期的目標。

決策矩陣——各 SysOps 目標對應的 VPC 元件

考試時使用此查閱表。

常見陷阱總整理——VPC 設定與連線

每次 SOA-C02 考試都會出現其中兩三個誤導選項。

陷阱一：NACL 是 stateful 的

它不是。NACLs 是 stateless 的；outbound 和 inbound 規則是獨立的。每個 TCP 回應都需要在 ephemeral port 範圍有明確的 inbound（或 outbound）規則。

陷阱二：開啟 Detailed Monitoring 能修復網路問題

VPC 連線問題無法單靠啟用 Detailed Monitoring 或 VPC Flow Logs 來解決。Flow Logs 有助於事後診斷；解法在於 route table、SG、NACL 或 endpoint 的設定。

陷阱三：VPC Peering 支援 Transitive Routes

它不支援。A → B 和 B → C 不等於 A → C。使用 Transit Gateway 或直接 peering。

陷阱四：Interface Endpoint 沒有 DNS 屬性

enableDnsSupport 和 enableDnsHostnames 兩者都必須為 true，Interface endpoints 的 private DNS 才能正確解析。

陷阱五：Gateway Endpoint 沒有加入 Subnet 的 Route Table

建立 endpoint 還不夠；你必須把它關聯到每個需要它的 subnet 的 route table。

陷阱六：NACL Ephemeral 範圍太窄

不同作業系統使用不同的 ephemeral 範圍。安全的規則是 NACL inbound 和 outbound 都設 TCP 1024–65535 ALLOW。

陷阱七：Security Group Rule 試圖表達 Deny 意圖

你無法在 security group 中寫「deny」。若規則必須是硬性拒絕，它應該寫在 NACL 中。

陷阱八：NAT Gateway 只按小時計費

NAT gateway 同時按小時和每 GB 處理資料量計費。資料處理費是悄無聲息的預算殺手。

陷阱九：透過 Gateway Endpoint 存取跨 Region 的 S3

Gateway endpoints 是 region 範圍的。us-west-2 的 VPC 擁有 S3 Gateway endpoint，但無法透過它連到 us-east-1 的 bucket；那個流量仍然走網際網路（或 NAT）。

陷阱十：Bastion Host 是 SSH 的答案

對 SOA-C02 而言，現代答案是 Session Manager。Bastion host 是考試認為次優的傳統模式。

陷阱十一：預設 Route Table Propagation 未啟用

Propagation 是每個 route table 針對 VPN BGP 路由的獨立設定。若它關閉，BGP 學到的路由不會出現，即使 tunnel 已連線，本地端路由也無法運作。

陷阱十二：單一 NAT Gateway 產生跨 AZ 資料傳輸費

AZ-a 中的單一 NAT gateway 服務來自 AZ-b 和 AZ-c 的流量，但跨 AZ 流量會產生資料傳輸費。最佳實踐是每個 AZ 一個 NAT gateway。

FAQ——VPC 設定與連線

Q1：Gateway VPC endpoint 在什麼時候優於 Interface VPC endpoint？

Gateway endpoints 只存在於 S3 和 DynamoDB，且免費。Interface endpoints 幾乎存在於所有其他 AWS 服務，收費，每個 AZ 小時費加每 GB 資料處理費。規則很簡單：對 S3 和 DynamoDB，一律使用 Gateway endpoint——沒有任何場景下 Interface endpoint 的變體是 SOA-C02 一般存取的正確答案。其他所有服務，Interface endpoint 是唯一選項，問題變成 Interface endpoint 的小時費加資料費，在你的流量量下是否比替代路徑（NAT gateway、網際網路 egress）更便宜。對多數 SOA-C02 問題而言，框架是「需要 private connectivity」，費用比較並不重要——Interface endpoint 是正確答案，因為工作負載完全不能走網際網路 egress。

Q2：為什麼 Interface endpoint 存在，private subnet 的 instance 仍無法連到 Secrets Manager？

三個高頻原因。第一，VPC 可能沒有同時啟用 enableDnsSupport 和 enableDnsHostnames——兩者缺一，secretsmanager.region.amazonaws.com 的 private DNS 名稱就無法解析到 endpoint 的 private IP，應用程式回退到 public IP，從 private subnet 只會 timeout。第二，endpoint ENI 上的 security group 可能沒有允許來自應用程式 SG 的 inbound 443——endpoint ENIs 需要自己的 SG，與應用程式的 SG 分開。第三，endpoint 可能沒有在呼叫 instance 所在的 AZ 中啟用——endpoints 是每 AZ 的 ENI，若某個 AZ 中沒有 endpoint ENI，該 AZ 的 instance 就無法透過 private DNS 使用 endpoint。在假設 endpoint 壞掉之前，先檢查這三點。

Q3：連接多個 VPC 時，如何在 VPC Peering 和 Transit Gateway 之間選擇？

對於剛好兩個需要完整 any-to-any 連線的 VPC，VPC peering 更便宜也更簡單——沒有每個 attachment 的小時費，peering 內的流量也沒有每 GB 處理費。對於三個或更多需要 any-to-any 連線的 VPC，Transit Gateway 勝出，因為 peering 的 non-transitive routing 迫使你建立全網狀，超過約 5 個 VPC 就難以管理（5 個 VPC 需要 10 條連線，10 個需要 45 條，20 個需要 190 條）。TGW 還能原生處理 VPN 和 Direct Connect attachments，讓你用多個 TGW route tables 隔離路由，並支援跨 region 的 TGW peering 建構全球 hub-and-spoke。SOA-C02 通則：超過 5 個 VPC 或需要 transitive routing → TGW；剛好兩個 VPC 且連線簡單 → peering。

Q4：完全 private VPC 的標準 Session Manager 設定是什麼？

五個元件。（1）EC2 instance 有 SSM agent 正在執行——在 Amazon Linux 2 / 2023、Ubuntu LTS、Windows Server 2016+ 上已預先安裝。（2）Instance 有 IAM instance profile，附加了 AmazonSSMManagedInstanceCore 受管政策。（3）VPC 有三個 Interface VPC endpoints：com.amazonaws.region.ssm、com.amazonaws.region.ssmmessages、com.amazonaws.region.ec2messages，各自在 instances 執行的 AZ 中啟用。（4）Endpoint security groups 允許來自 instance security groups 的 inbound 443。（5）啟動 session 的使用者對目標 instance 有 IAM 權限 ssm:StartSession。這五點都到位後，工程師執行 aws ssm start-session --target i-0abc123 就能透過 AWS private 網路取得互動式 shell，不需要 public IP、不需要 SSH key、不需要 22 port，並有完整稽核軌跡記錄到 CloudWatch Logs 或 S3。

Q5：為什麼 Site-to-Site VPN tunnel 顯示 UP，但本地端流量無法流到 VPC？

最常見原因：VPC route table 對 Virtual Private Gateway 未啟用 route propagation。BGP 學到的路由被廣告到 VGW，但只有在 propagation 開啟時才會出現在 VPC route table。第二個原因：本地端設備的 BGP 廣告 CIDR 有誤——確認廣告的 prefixes 符合 AWS 的預期。第三個原因：相關 subnets 的 NACLs 沒有允許來自本地端 CIDR 的 inbound，或沒有允許 return traffic 的 outbound ephemeral 範圍。第四個原因：目的地 instances 的 security groups 沒有允許來自本地端 CIDR 範圍的流量。第五個原因：本地端防火牆沒有允許 ESP（IP protocol 50）、UDP 500（IKE）和 UDP 4500（NAT-T）。依序逐層排查——route propagation 是 SOA-C02 最高頻的遺漏。

Q6：如何在 subnet 層級封鎖特定國家的 SSH？

NACLs 只支援基於 CIDR 的規則，不支援基於國家的規則。若要在 subnet 層級封鎖整個國家，你需要列出該國家所有分配到的 CIDR 範圍（數量龐大且不斷變動），並把它們打包成 NACL 的 deny 規則。大規模執行實際上不可行。考試正確答案是 AWS WAF geo-match rules，附加到工作負載的 CloudFront distribution 或 ALB——WAF 維護國家到 CIDR 的對應並自動更新。NACLs 適用於「封鎖這個特定的惡意 IP 範圍」或「無論 SG 如何都強制 subnet 層級封鎖」；WAF 適用於 L7 的國家、標頭、內容和速率限制過濾。WAF 在專屬的 SOA-C02 主題中說明。

Q7：NAT gateway 和 NAT instance 的差別是什麼？

NAT gateway 是受管的 AWS 服務：AWS 負責佈建、擴展、修補和操作。AZ 範圍，按小時和每 GB 處理資料量計費，最高 100 Gbps。NAT instance 是執行 NAT 軟體的普通 EC2 instance（通常是有 iptables masquerading 的社群 AMI）。你要管理修補、HA（意思是大小為 1 且帶 health checks 的 Auto Scaling group），還必須關閉 EC2 的 source/destination check 才能讓它轉送封包。NAT instance 在流量極低時比較便宜，因為你只付 EC2 instance 的費用，但在任何需要正式可用性和吞吐量的場景，NAT gateway 在操作簡便性上完勝。SOA-C02 在「最小化低流量開發環境的成本」以外的所有場景都偏好 NAT gateway。

Q8：VPC route table 中的最長前綴優先規則如何運作？

當封包離開 instance 時，VPC router 檢查 subnet 的 route table，選擇與目的地 IP 最長匹配前綴的路由。具體而言：若 route table 有 10.0.0.0/16 → local 和 10.0.5.0/24 → pcx-AB（peering），去往 10.0.5.10 的流量走 peering connection，因為 /24 比 /16 更精確。Gateway endpoints、peering 路由和 VPN 路由就是這樣選擇性覆蓋預設的 0.0.0.0/0 → IGW 或 NAT。對於 SOA-C02 中「流量走到了錯誤的地方」的問題，檢查 route table 是否有比你預期優先的更精確路由。

Q9：Security group rule 引用另一個 security group 什麼時候優於 CIDR 規則？

當來源集是「屬於另一個層的 instances」而非固定 IP 範圍時，security group 引用勝出。想像一個 ALB 後方的 Auto Scaling web server 群組——每次 instance 啟動或替換，IPs 都會改變，所以資料庫 security group 上基於 CIDR 的規則需要不斷更新。把資料庫 SG 規則寫成「允許來自 sg-web 的 5432」，規則就會在 web instance 汰換時持續有效，因為它用 SG 成員身份識別來源，而不是 IP。這是 SOA-C02 任何層間過濾的最佳實踐模式。在 security group 中使用 CIDR 規則的唯一原因，是來源在本地端（沒有 SG 可引用），或是在 peer VPC 中（SG 引用只在同 region peering 中有效，跨 region peering 不傳播 SG 引用）。

Q10：為什麼使用單一 NAT Gateway 時，團隊被收取跨 AZ 資料傳輸費？

因為每個 NAT gateway 都是 AZ 範圍的——它存在於剛好一個 AZ——其他 AZ 的 instance 流量必須跨越 AZ 邊界才能到達它。AWS 對跨 AZ 資料傳輸收取每 GB $0.01，加上 NAT gateway 的小時費和每 GB 處理費。單一 NAT gateway 服務三個 AZ，其中兩個 AZ 的流量會產生跨 AZ 費用。解法是每個 AZ 一個 NAT gateway，各 AZ 的 private subnet route table 指向同 AZ 的 NAT gateway。這個模式也提升可用性——一個 AZ 故障導致某個 NAT gateway 失效，不會影響其他兩個 AZ 的 egress。

Q11：VPC Peering Connections 最多可以有幾個？什麼時候切換到 Transit Gateway？

預設軟性配額是每個 VPC 125 個 active peering connections（可申請提升）。實際上，管理負擔遠在達到這個數字之前就讓人難以承受——8 個 VPC 的全網狀需要 28 個 peering connections，雙方各有路由項目，沒有一個集中的地方執行路由策略或隔離流量。多數運維團隊在 5 到 10 個 VPC 時切換到 Transit Gateway。TGW 也解鎖了 transitive routing、集中的 route table 策略、與 VPN 和 Direct Connect attachments 的整合，以及透過 AWS RAM 的跨帳號共享。SOA-C02 的觸發短語是「團隊在跨多個 VPC 管理路由時遇到困難」→ TGW。

延伸閱讀與相關操作模式

• What is Amazon VPC
• VPC Subnets
• Route Tables for your VPC
• Internet Gateways
• NAT Gateways
• Security Groups for your VPC
• Network ACLs
• AWS PrivateLink and VPC Endpoints
• Gateway VPC Endpoints
• Interface VPC Endpoints
• VPC Peering
• VPC Peering — Unsupported Configurations
• AWS Transit Gateway User Guide
• AWS Site-to-Site VPN User Guide
• AWS Systems Manager Session Manager
• Set up VPC Endpoints for Systems Manager
• Amazon VPC Quotas
• AWS SOA-C02 Exam Guide v2.3 (PDF)

VPC 基礎元件設定完成後，後續操作層包括：Route 53 DNS 和 CloudFront 負責 VPC 對外的公開邊緣、WAF、Shield 和網路保護服務在這裡設定的 L3/L4 防火牆上方加入 L7 和 DDoS 防禦、VPC 網路疑難排解的 Flow Logs、ELB access logs 和 Reachability Analyzer 工具組在事後找出這個架構中的問題，以及 EC2 Auto Scaling 和 ELB 高可用性，在本指南所設計的 subnets、security groups 和 route tables 中承載工作負載。

• Route 53 DNS、Routing Policies 與 CloudFront CDN — SOA-C02 學習筆記
• WAF、Shield 與網路保護服務 — SOA-C02 學習筆記
• 網路疑難排解：VPC Flow Logs、ELB Logs 與連線診斷 — SOA-C02 學習筆記
• EC2 Auto Scaling、ELB 與多 AZ 高可用性 — SOA-C02 學習筆記