VPC 架構與網路安全基礎

Amazon VPC（Virtual Private Cloud）是所有 AWS 網路設計的根基。Amazon EC2 執行個體、Amazon RDS 資料庫、Amazon ECS 工作、具備 VPC 存取的 AWS Lambda 函數，以及 Amazon ElastiCache 叢集，全都運行在 VPC 之中。在 SAA-C03 考試中，VPC 相關概念大約佔每三道情境題就有一道——不只出現在安全性領域，也涵蓋韌性（Multi-AZ Subnet 配置）、效能（Transit Gateway、PrivateLink）和成本最佳化（Gateway Endpoint 對比 NAT Gateway）。如果備考 SAA-C03 只能深入研究一個網路主題，就選 Amazon VPC。

本指南是 ExamHub 所有 SAA-C03 主題的 VPC 標準參考資料。後續筆記提到「將資料庫放入私有 Subnet」、「使用 Interface Endpoint 私下存取 AWS 服務」或「將 VPC 連接至 AWS Transit Gateway」時，相關機制都在這裡定義。Task Statement 1.2（「設計安全的工作負載與應用程式」）要求你能流暢地將 CIDR 規劃、子網路劃分、路由、Security Group、NACL 及混合連線整合成生產級網路設計。本指南逐一說明每個基本元件，點出最常見的 SAA-C03 考試陷阱，並提供便於記憶的類比。

Amazon VPC 是什麼，為什麼對 SAA-C03 如此重要

Amazon VPC 是 AWS 服務，讓你在 AWS 區域（Region）內建立一個邏輯隔離的虛擬網路，包含你自己的私有 IP 位址範圍、Subnet、Route Table、Internet Gateway 和安全控管機制。VPC 本質上就是你自己的軟體定義資料中心網路，範圍限定在一個 AWS Region，橫跨該區域的所有可用區域（AZ）。每個 AWS 帳號在每個 AWS Region 都會自動建立一個預設 VPC，此外你最多可以在每個 Region 建立 5 個自訂 VPC（軟性上限，可申請提高）。

VPC 同時賦予你三種核心能力：隔離性（你的 VPC IP 空間與其他所有 AWS 客戶完全分開）、控制力（由你決定 CIDR、Subnet、路由和過濾規則），以及連線彈性（由你決定哪些流量可以通往網際網路、哪些流量走內部部署，哪些完全保持私有）。這樣的組合正是 Amazon VPC 成為 SAA-C03 Well-Architected 設計基礎層的原因。

Amazon VPC 為何是 SAA-C03 的根基主題

SAA-C03「設計安全架構」領域佔考試比重 30%，Task Statement 1.2（設計安全的工作負載與應用程式）明確測驗 VPC 設計模式——公有／私有 Subnet 分層、Security Group、NACL、VPC Endpoint、PrivateLink。VPC 也廣泛出現在領域 2（RDS 容錯移轉的 Multi-AZ Subnet 配置）、領域 3（Transit Gateway 的輻射型架構，兼顧效能與規模）以及領域 4（Gateway Endpoint 取代 NAT Gateway 的資料處理費用）。ExamHub 上幾乎每一個 SAA-C03 主題都會連結回本篇；深入學習 Amazon VPC，在四個領域都能獲得回報。

白話文解釋 Amazon VPC

抽象的網路概念，一旦對應到具體場景就清晰許多。以下提供三個不同的 Amazon VPC 類比，涵蓋 SAA-C03 考試所有主要構件。

類比一：有分區樓層的辦公大樓

想像一棟私人企業辦公大樓。大樓本身就是你的 Amazon VPC——一棟建築，位於一塊土地（一個 AWS Region），擁有統一的門牌號碼段（VPC CIDR，例如 10.0.0.0/16）。每一個樓層就是一個 Subnet，每個樓層刻意分配到大樓的某個消防分區（一個 AZ），這樣若 A 分區發生火警，B 分區的樓層仍可正常運作。面街樓層（公有 Subnet）有直接通往街道的大門——那道門就是 Internet Gateway（IGW）。後棟樓層（私有 Subnet）沒有面街出入口；需要外出的員工必須走後方卸貨碼頭——也就是 NAT Gateway——它讓員工出去辦事並帶回貨物，但外人無法從街上直接走進後棟。

Route Table 是每部電梯旁張貼的樓層導覽：「前往 3 樓請按 3；前往街道請按 L；前往隔壁姊妹大樓請按天橋按鈕。」Security Group 是駐守在每個辦公室門口的保全——他們對照個人許可名單核查每位訪客，並記得誰曾進入，所以這些人離開時不需要再次核驗（有狀態）。Network ACL（NACL） 是樓層電梯廳的門禁閘機——每個進出樓層的人都必須對照一本有編號的規則手冊逐條核驗，而且閘機沒有記憶，不知道誰剛進來（無狀態），所以回程流量需要獨立的明確規則。

VPC Endpoint 是從你的樓層直通 AWS 服務區的私有走廊，完全不需要走出大樓——你透過內部通道就能抵達 Amazon S3 或 Amazon DynamoDB。VPC Peering 是連接你的大樓與鄰棟夥伴大樓的空中走廊——快速、直達，但只連結那兩棟特定大樓。AWS Transit Gateway 則是市區的中央巴士總站——每棟大樓在城區只需連接到總站一次，班車就在各棟之間透過樞紐往來運行。

類比二：有住戶公約的封閉社區

想像一個大型封閉式住宅社區。入口的警衛亭大門就是 Internet Gateway——那道門是汽車從公共道路進入的唯一通道。社區內的各條小巷是各個 Subnet，每條小巷分配給一個緊急應變分區（一個 AZ）。面街小巷（公有 Subnet）的住宅可以直接叫外送，外送員可以直接騎車抵達；後棟小巷（私有 Subnet）沒有通往主幹道的直接車道，住戶需要叫**社區接駁車（NAT Gateway）**出去辦事。接駁車會把他們帶回來，但外送員不能自行騎到後棟小巷。

每戶大門上張貼的住戶規定是 Security Group——屋主寫明「水電工、電氣技師和奶奶可以進入」，規定跟著房子走，門口的保全記得誰進去了，讓他們出來時免受阻攔。各小巷入口的社區管委會公告是 NACL——從 1 號起依序評估，遇到第一條相符的規則就停止；任何進出小巷的人，雙向都必須有明確的許可，因為管委會公告不記得訪客。

VPC Flow Logs 是社區的 CCTV 系統——每輛進出小巷的車都會被記錄時間、方向、車牌號碼（來源／目的 IP），以及大門是讓它通過（ACCEPT）還是拒之門外（REJECT）。

類比三：有海關分區的國際貨運港

國際貨運港口完美呈現了 Amazon VPC 的運作方式。港口（VPC）座落在某個海岸（AWS Region），劃分為多個停泊碼頭（Subnet），各碼頭分屬不同作業分區（AZ），如此一來 A 分區的起重機故障，B 分區的碼頭仍可繼續運作。面向大海的港灣入口就是 Internet Gateway——貨輪從這裡進出。公有碼頭（公有 Subnet）直接臨海，貨輪可直接靠泊。私有碼頭（私有 Subnet）位於內陸倉庫，沒有海上通道；出港貨物需搭乘**接駁卡車（NAT Gateway）**運到海邊，再原路返回。

每個碼頭張貼的港區路線圖（Route Table）告訴堆高機每個目的地在哪裡。碼頭上逐貨物核查的海關人員是 Security Group——有狀態，記得每次查驗。港區分區之間的周界哨站是 NACL——有編號的規則，無狀態，沒有記憶。通往亞馬遜服務倉的私有鐵路支線是 Gateway Endpoint（不出海就能連線到 Amazon S3 或 Amazon DynamoDB），或者是 Interface Endpoint / PrivateLink（連至大多數其他 AWS 服務和第三方 SaaS 供應商的私有貨運電梯）。連接某一特定夥伴港口的海底電纜是 VPC Peering；在整個港區以單一接口連接每個港口的地區貨運中樞是 AWS Transit Gateway。在公共海域中加密的隧道是 AWS Site-to-Site VPN，而鋪設到你自家碼頭的專用實體海底光纜是 AWS Direct Connect。

VPC 基礎：CIDR 區塊、位址保留與 Region 範圍

在規劃 VPC 之前，你需要對 IPv4 CIDR 計算和 AWS 在每個 Subnet 中靜默保留的五個位址有扎實的掌握。

VPC CIDR 區塊大小

Amazon VPC 由一個主要 IPv4 CIDR 區塊定義，範圍介於 /16（65,536 個位址）至 /28（16 個位址）之間。正式生產環境最常見的選擇是 /16，因為它為未來的 Subnet 擴充和多 VPC 設計留有充裕空間。依照 RFC 1918，允許的私有位址範圍為：

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

若位址不足，AWS 也支援為 VPC 附加次要 CIDR 區塊（預設最多 5 個），並可透過 IPv6 /56 區塊建立雙協定堆疊。SAA-C03 考試除非題目明確說明 IPv6，否則一律假設使用 IPv4。

Subnet CIDR 大小與 AZ 綁定

每個 Subnet 都是 VPC CIDR 的子集，並綁定至唯一一個可用區域（AZ）。Subnet 大小範圍從 /28（16 個位址）至 /16（與 VPC 相同）。Subnet 為公有（其 Route Table 有通往 Internet Gateway 的預設路由）或私有（沒有此預設路由）。「公有／私有」標籤並非 Subnet 物件本身的屬性——完全由附加在其上的 Route Table 決定。

每個 Subnet 的五個保留位址

AWS 在每個 Subnet 中保留 5 個 IP 位址，無論大小為何。以 10.0.1.0/24 Subnet 為例：

因此，一個 /28 Subnet 共有 16 − 5 = 11 個可用 IP 位址。在為 Auto Scaling 群組、EKS Pod 或 ENI 密集型工作負載調整 Subnet 大小時，這個數字非常重要。

Subnet：公有與私有——Route Table、Internet Gateway 與 NAT Gateway

公有與私有的區別是 SAA-C03 中最常考的 Subnet 概念。確切理解「什麼讓 Subnet 成為公有」，就能解鎖大多數網路情境題。

什麼讓 Subnet 成為公有

當三個條件同時成立時，Subnet 才是公有的：

1. 其 Route Table 有一條預設路由（0.0.0.0/0）指向 Internet Gateway（IGW）。
2. 該 IGW 已附加至 VPC。
3. Subnet 中的資源擁有公有 IPv4 位址（透過 Subnet 的 MapPublicIpOnLaunch 設定自動指派，或手動附加 Elastic IP）。

三個條件缺少任何一個，該 Subnet 實際上就是私有的。

什麼讓 Subnet 成為私有

私有 Subnet 沒有通往 IGW 的預設路由。其中的資源只有私有 IP 位址，無法從公共網際網路直接存取。私有 Subnet 是你放置資料庫（Amazon RDS、Amazon ElastiCache）、置於 Load Balancer 後方的應用程式伺服器，以及內部微服務的地方——任何不應接受來自網際網路主動連線的服務都應放在這裡。

Internet Gateway（IGW）

Internet Gateway 是一個水平擴展、冗餘、高可用的 VPC 元件，負責兩項工作：作為 Route Table 中網際網路流量的目標，以及對擁有公有 IP 的 EC2 執行個體執行私有與公有 IPv4 位址之間的 1:1 NAT。每個 VPC 只能附加一個 IGW。IGW 本身不收費，但流經它的資料傳輸需付費。

NAT Gateway——私有 Subnet 的僅限出站網際網路連線

NAT（Network Address Translation）Gateway 是 AWS 受管服務，讓私有 Subnet 中的執行個體可主動發起對外連線（下載作業系統修補程式、呼叫第三方 API、存取沒有 VPC Endpoint 的 AWS 服務端點），同時不接受來自網際網路的主動連入連線。NAT Gateway 本身位於公有 Subnet 並使用 Elastic IP。私有 Subnet 的 Route Table 將 0.0.0.0/0 導向 NAT Gateway，由其代替原始請求方將封包轉送至 IGW。

SAA-C03 反覆測驗的 NAT Gateway 關鍵特性：

• AZ 範圍——每個 NAT Gateway 僅位於一個 AZ。要實現高可用性，需要每個 AZ 部署一個 NAT Gateway，各私有 Subnet 的 Route Table 指向同一個 AZ 內的 NAT Gateway。
• 最高 45 Gbps 頻寬，可自動擴展至此上限。
• 以每小時計費＋每 GB 處理費計算，因此 NAT Gateway 是成本最佳化的常見目標。
• 受管服務——無需修補，AZ 內部不需要額外 HA 設計。

NAT Instance（舊式做法）

NAT Instance 是一個執行 NAT 軟體的自管 EC2 執行個體。AWS 仍支援此做法，但被視為舊式技術——沒有自動 HA、沒有自動擴展，需要自行修補。在 SAA-C03 中，預設選擇 NAT Gateway，除非題目明確要求最低成本、極低流量，或需要在 NAT 主機上執行自訂軟體的特殊情境。

Route Table——流量如何找到離開 Subnet 的路徑

大多數網路錯誤配置都藏在 Route Table 裡。每個 Subnet 只有一個生效的 Route Table，而該表的內容決定 Subnet 是公有還是私有、能否抵達對等 VPC，以及能否抵達內部部署環境。

主要 Route Table 與自訂 Route Table

每個 VPC 都有一個自動建立的主要 Route Table。未明確關聯自訂 Route Table 的 Subnet 會繼承主要 Route Table。在生產環境中，建議模式是為每個 Subnet 明確關聯自訂 Route Table，避免錯誤配置的主要 Route Table 意外變更你的拓撲。

路由評估：最精確比對獲勝

當流量離開 Subnet 時，Amazon VPC 將目的地與 Route Table 中的每一條路由比對，並選擇**最精確（最長前綴）**的比對結果。10.0.2.0/24 的路由優先於 10.0.0.0/16，後者又優先於 0.0.0.0/0。VPC 自身 CIDR 的預設本地路由（local）永遠存在，且對 VPC 內部流量永遠優先。

SAA-C03 常考的 Route Table 條目

Security Group 與 Network ACL——最常考的關鍵區別

這個區別幾乎在每次 SAA-C03 考試中都會出現至少一道題。熟練掌握這個概念，你就能在領域 1 和領域 3 輕鬆拿分。

Security Group——有狀態、執行個體層級

Security Group（SG） 是附加在彈性網路介面（ENI）上的虛擬防火牆——也就是說，它作用在執行個體層級，而非 Subnet 層級。每個 ENI 最多可附加 5 個 Security Group，每個 Security Group 的輸入與輸出規則各最多 60 條（申請提高上限後，每個 SG 雙向合計最多 1,000 條規則）。

Security Group 的關鍵特性：

• 有狀態（Stateful）——若你允許一個輸入請求，回應流量會自動被允許輸出。回覆流量不需要另設匹配的輸出規則。
• 僅允許規則——你無法撰寫拒絕規則。你只需指定允許的內容；其他所有流量隱性拒絕。
• 規則可引用其他 Security Group——Security Group 規則可將另一個 Security Group 作為來源／目的地引用。這讓你可以說「允許來自 app-tier-sg 中執行個體的 TCP 3306 輸入」，而不需要寫死 IP 位址。
• 預設輸出——新建立的 Security Group 預設有一條「允許所有輸出」規則。新建立的 Security Group 預設沒有任何輸入規則。
• 作用在 ENI 層級——同一個 SG 可附加至多個 Subnet 和 AZ 中的執行個體。

Network ACL——無狀態、Subnet 層級

Network ACL（NACL） 是位於 Subnet 邊界的防火牆。進出 Subnet 的每個封包都會被 NACL 規則評估。

NACL 的關鍵特性：

• 無狀態（Stateless）——輸入與輸出流量獨立評估。若你允許輸入 TCP 443，還必須為臨時連接埠範圍（大多數 Linux 為 1024-65535，Windows 為 49152-65535）撰寫輸出規則，讓回應流量能夠離開。
• 有編號的規則，號碼最小者優先——規則從最小規則號碼到最大依序評估；第一個比對成功的規則即決定結果，AWS 不再繼續評估。慣例是以 100 為間隔設定規則號碼（100、200、300……），方便日後插入新規則。
• 允許規則與拒絕規則都支援——NACL 支援明確的拒絕，適合用來封鎖已知的惡意 IP 範圍。
• 每個 Subnet 只能有一個 NACL——一個 Subnet 只能關聯一個 NACL，但一個 NACL 可以涵蓋多個 Subnet。
• 預設 NACL——允許所有進出流量。自訂 NACL——預設拒絕所有流量，直到你新增規則。

並排比較——Security Group 與 NACL

縱深防禦——兩者並用

Security Group 與 NACL 並非二選一——AWS Well-Architected 設計兩者都用。Security Group 在執行個體層處理精細的、基於引用的規則（Web 層與應用程式層通訊，應用程式層與資料庫層通訊），NACL 則提供粗粒度的 Subnet 邊界防護（阻擋已知惡意 IP 範圍的流量，在 Subnet 邊緣拒絕所有 SMB/NetBIOS 流量）。

VPC Endpoint——私下存取 AWS 服務

VPC Endpoint 是一個虛擬裝置，讓 VPC 中的資源可以在不穿越公共網際網路的情況下存取 AWS 服務（以及透過 AWS PrivateLink 存取 SaaS 夥伴），也不需要 Internet Gateway、NAT Gateway 或 VPN。VPC Endpoint 有兩種截然不同的類型，SAA-C03 兩者都會考。

Gateway Endpoint——僅限 S3 與 DynamoDB，免費

Gateway Endpoint 是一個 Route Table 目標，讓你可以私下存取 Amazon S3 或 Amazon DynamoDB。建立 Endpoint 後，AWS 會將一條前綴清單路由新增至你選定的 Route Table，之後流往 S3 或 DynamoDB 的流量就會透過 Endpoint 傳輸，而非走 IGW/NAT 路徑。

Gateway Endpoint 的關鍵特性：

• 支援的服務：僅限 Amazon S3 與 Amazon DynamoDB。
• 不額外收費——Gateway Endpoint 免費，也不收取資料處理費。
• VPC 範圍——僅在 VPC 內部有效，不支援跨區域或跨帳號連線。
• 前綴清單路由——AWS 維護 S3/DynamoDB 的 IP 清單；你只需引用 pl-xxxx 前綴清單。
• 非常適合成本最佳化——若私有 Subnet 的主要對外流量是前往 S3，Gateway Endpoint 可大幅降低 NAT Gateway 的資料處理費用。

Interface Endpoint——AWS PrivateLink，適用大多數 AWS 服務與 SaaS

Interface Endpoint 是放置在你一個或多個 Subnet 中的 ENI，使用 Subnet 範圍內的私有 IP。前往 Endpoint 的流量透過 AWS PrivateLink 私下抵達目標服務。Interface Endpoint 支援大多數 AWS 服務（Amazon EC2 API、AWS KMS、AWS Systems Manager、Amazon SQS、Amazon SNS、AWS Secrets Manager、Amazon ECR 及 100 多項其他服務）以及透過 AWS PrivateLink 發布的第三方 SaaS 供應商（Datadog、Snowflake、MongoDB Atlas 等）。

Interface Endpoint 的關鍵特性：

• 以每 AZ 每小時計費＋每 GB 處理費計算。
• 每個 Endpoint 位於你選定的 Subnet 中——為了 HA，請選擇多個 AZ 中的 Subnet。
• 當「Enable Private DNS」開啟時，透過私有 DNS 解析至 PrivateLink ENI IP，讓你的應用程式程式碼無需變更 Endpoint URL。
• 由 Endpoint 政策（限制允許透過 Endpoint 執行哪些 API 操作的資源型 IAM 政策）和 Endpoint ENI 上的 Security Group 控管。

Gateway Endpoint 與 Interface Endpoint 的比較——SAA-C03 決策指引

AWS PrivateLink——不經公共網際網路的私有服務暴露

AWS PrivateLink 是驅動 Interface Endpoint 的底層技術。它讓服務提供者（另一個 AWS 帳號，或 SaaS 廠商）能將服務以 Endpoint 服務的形式（以 Network Load Balancer 為後端）對外發布，讓服務消費者透過自己 VPC 中的 Interface Endpoint 存取——雙方流量都不會觸及公共網際網路，也不需要在兩者之間建立 VPC Peering 或 Transit Gateway。

AWS PrivateLink 對 SAA-C03 的重要性

• 沒有 CIDR 重疊限制——與 VPC Peering 或 Transit Gateway 不同，即使提供者和消費者 VPC 的 IP 範圍重疊，PrivateLink 仍可運作，因為每個消費者只會看到自己 Subnet 中的 ENI IP。
• 單向——消費者主動連線至提供者；除非提供者也朝反方向設置 PrivateLink，否則沒有反向路徑。
• 一對多——一個服務提供者可以向跨多個 AWS 帳號的多個消費者 VPC 發布服務。
• SaaS 使用情境——AWS 客戶將內部微服務對外暴露給其他業務單位，SaaS 廠商則透過 PrivateLink 讓客戶資料不必經過網際網路。

SAA-C03 的典型 PrivateLink 情境

• 「某公司希望在不使用 VPC Peering 或公共網際網路的情況下，將內部應用程式暴露給夥伴 VPC」→ AWS PrivateLink Endpoint 服務。
• 「SaaS 廠商希望無需 CIDR 規劃協調，就能私下將 API 提供給客戶 VPC」→ AWS PrivateLink。
• 「私有 Subnet 中的工作負載需要在不經過 NAT Gateway 的情況下呼叫 AWS Secrets Manager」→ Interface Endpoint（底層就是 PrivateLink）。

VPC Peering——非遞移性的點對點連線

VPC Peering 是恰好兩個 VPC 之間的網路連線，允許流量使用私有 IPv4 或 IPv6 位址在兩者之間路由。Peering 可在相同 AWS Region、跨 AWS Region（區域間 Peering）以及跨 AWS 帳號運作。

VPC Peering 關鍵特性

• CIDR 區塊不得重疊。 Peering 不會在重疊的 IP 範圍之間路由；你必須事先規劃 CIDR。
• 非遞移性。 若 VPC A 與 VPC B 對等，VPC B 與 VPC C 對等，VPC A 無法透過 B 抵達 VPC C。你必須在 A 與 C 之間另外建立 Peering。
• 兩端都需要配置 Route Table——每個 VPC 都需要一條指向 pcx-xxxx 的對端 CIDR 路由。
• Security Group 只能在相同 Region 引用對端 SG（跨區域 Peering 需要以 CIDR 為基礎的規則）。
• 沒有單點故障，沒有頻寬瓶頸——Peering 直接使用 AWS 骨幹網路，自動擴展。
• 定價——不收每小時費用，只有流經 Peering 的跨 AZ 或跨區域資料傳輸費用。

何時使用 VPC Peering，何時使用 AWS Transit Gateway

AWS Transit Gateway——多 VPC 的輻射型中樞

AWS Transit Gateway（TGW） 是區域性、高可用的網路轉運中樞，可連接多個 VPC、VPN 連線、Direct Connect 閘道和 Transit Gateway 對等連接。相較於 N 個 VPC 的全網狀連接需要 N×(N−1)/2 個 Peering 連線，TGW 將設計簡化為只需 N 個附件掛接在單一中樞上。

Transit Gateway 關鍵特性

• 區域性——每個 Region 一個 TGW，可擴展至數千個 VPC 附件。
• 遞移路由——任何附件都可以路由至其他任何附件（視 Route Table 規則而定）。
• Route Table——Transit Gateway 有自己的 Route Table，獨立於 VPC Route Table。每個附件與一個 TGW Route Table 關聯，可向其他 Route Table 傳播路由。
• 跨 Region TGW Peering——連接兩個不同 Region 的 TGW，建構全球骨幹網路。
• Direct Connect 整合——透過一個 Direct Connect 閘道，讓內部部署網路連至所有附加的 VPC。
• 頻寬——每個附件最高 50 Gbps。
• 定價——每個附件每小時計費加上每 GB 資料處理費。Transit Gateway 功能強大，但費用明顯高於 Peering。

Transit Gateway 是正確答案的時機

• 5 個以上 VPC 需要互相連線。
• 混合網路，內部部署需要抵達多個 VPC。
• 多帳號落地區（Landing Zone），數十個工作負載帳號共用中央出口或共用服務 VPC。
• 需要遞移路由（VPC A ↔ VPC B ↔ VPC C 透過同一中樞連通）。

AWS Site-to-Site VPN——透過公共網際網路的加密隧道

AWS Site-to-Site VPN 在你的內部部署客戶閘道裝置與 AWS 端的虛擬私有閘道（Virtual Private Gateway，VGW）（附加至 VPC）或 Transit Gateway 之間建立兩條 IPsec 隧道（提供冗餘）。流量透過公共網際網路傳輸，但端對端加密。

Site-to-Site VPN 關鍵特性

• 每個 VPN 連線有兩條隧道，各自終止在不同的 AWS 可用端點以實現 HA。
• 每條隧道最高 1.25 Gbps（AWS 端的總體吞吐量通常限於此範圍）。
• BGP 或靜態路由——BGP 支援動態容錯移轉；靜態路由需要手動更新路由。
• 快速建立——幾分鐘內即可佈建，無需申請專線。
• 在網際網路上加密——流量已加密，但效能取決於網際網路路徑品質（延遲和抖動會有變化）。
• 費用——每小時費率較低，加上標準資料傳出定價。

AWS Client VPN 與 Site-to-Site VPN 的比較

這是兩個不同的 AWS 服務。AWS Site-to-Site VPN 連接整個內部部署網路（完整資料中心）至 AWS。AWS Client VPN 是以 OpenVPN 為基礎的受管服務，讓個別使用者裝置（筆記型電腦、手機）連線至 VPC，供遠端工作者使用。SAA-C03 中提到「分支辦公室連接 AWS」表示 Site-to-Site VPN；提到「開發人員從家中連線到私有 VPC」表示 Client VPN。

AWS Direct Connect——連接 AWS 的專用私有光纖

AWS Direct Connect（DX） 是你的內部部署資料中心（或共置機房）與 AWS Direct Connect 節點之間的實體專用網路連線。它完全繞過公共網際網路，提供穩定的低延遲和可預測的頻寬。

Direct Connect 關鍵特性

• 連接埠速率：1 Gbps、10 Gbps、100 Gbps（專用連線）；透過 Direct Connect 夥伴（託管連線）可提供低於 1 Gbps 的選項。
• 在 Direct Connect 節點進行實體交叉連接——佈建需時數週至數月（下訂、運送、安裝光纖）。
• 預設不加密——Direct Connect 是私有連線，但實體鏈路不在 Layer 2 加密。若需要加密，可在 Direct Connect 上疊加 AWS Site-to-Site VPN（有時稱為「DX + VPN」）。
• 虛擬介面（VIF）：私有 VIF 連接一個 VPC 的 VGW 或 Direct Connect 閘道；公有 VIF 私下連接 AWS 公共服務端點（S3、DynamoDB）；傳輸 VIF 連接至前端為 Transit Gateway 的 Direct Connect 閘道。
• Direct Connect Gateway 讓一條 Direct Connect 連線能抵達多個 Region 的多個 VPC。
• 韌性等級——AWS 提供「最高韌性」（4 條 DX 連線分散在 2 個節點）和「高韌性」（2 條 DX 連線分散在 2 個節點）參考架構。

VPN 與 Direct Connect 的比較——SAA-C03 決策指引

VPC Flow Logs——安全性與問題排查的可視化工具

VPC Flow Logs 擷取流向或來自 VPC 中網路介面的每個 IP 封包的詮釋資料（metadata）。你可以在 VPC 層級、Subnet 層級或個別 ENI 層級啟用 Flow Logs，並將記錄發布至 Amazon CloudWatch Logs、Amazon S3 或 Amazon Kinesis Data Firehose。

Flow Log 記錄包含的內容

每筆記錄（採預設格式）擷取：來源 IP、目的地 IP、來源連接埠、目的地連接埠、通訊協定、封包數、位元組數、開始／結束時間、動作（ACCEPT 或 REJECT）及評估結果。自訂格式讓你可以新增 VPC ID、Subnet ID、執行個體 ID、AWS Region 和 TCP 旗標等欄位。

Flow Logs 能做什麼，不能做什麼

Flow Logs 可以擷取：

• 被 Security Group 與 NACL 允許或封鎖的流量。
• 流向或來自彈性網路介面（包括 NAT Gateway 和 Load Balancer ENI）的封包。
• 被拒絕的流量——對診斷「為何 A 無法連至 B」非常有用。

Flow Logs 無法擷取：

• 流向或來自 Amazon 提供的 DNS（169.254.169.253 或 .2 解析器）的流量。
• 流向 Amazon EC2 執行個體詮釋資料服務（169.254.169.254）的流量。
• DHCP 流量。
• 鏡像流量（請改用 VPC Traffic Mirroring）。
• 封包的內容（Payload）——Flow Logs 僅為詮釋資料，不是封包擷取工具。

SAA-C03 的典型 Flow Logs 情境

• 「排查 EC2 執行個體為何無法連線至私有 Subnet 中的 RDS 資料庫」→ 啟用 VPC Flow Logs，並查看相關 NACL 或 Security Group 上的 REJECT 記錄。
• 「法規遵循要求保留一年份的 VPC 所有網路流量記錄」→ Flow Logs 發布至 S3，並設定生命週期轉存至 Glacier。
• 「即時網路監控與異常偵測」→ Flow Logs 透過 Kinesis Data Firehose 導入 OpenSearch，或讓 Amazon GuardDuty 自動消費以進行威脅偵測。

網路分段策略——分層 Subnet 架構

SAA-C03 的正式生產 Amazon VPC，通常採用每個可用區域三層的 Subnet 分層架構：

1. 公有 Subnet 層——放置面向網際網路的 Load Balancer（Application Load Balancer、Network Load Balancer）、NAT Gateway 和堡壘主機（Bastion Host）。Route Table 的 0.0.0.0/0 → IGW。
2. 私有應用程式 Subnet 層——放置 EC2 應用程式伺服器、ECS/EKS 工作節點、容器工作和具備 VPC 存取的 Lambda 函數。沒有直接的網際網路進站流量。Route Table 的 0.0.0.0/0 → NAT Gateway。
3. 私有資料 Subnet 層——放置 Amazon RDS、Amazon ElastiCache、Amazon OpenSearch。除非必要否則沒有對外網際網路連線。Security Group 僅接受來自應用程式層 Security Group 的流量。

在每個 AZ 都部署相同的三個層（通常 2-3 個 AZ 以實現 HA）。這樣每個 VPC 會有 6-9 個 Subnet，這是 SAA-C03 的標準佈局，也符合 AWS Well-Architected 參考架構。

Amazon VPC 的關鍵數字與必記事實

記住這份清單——它涵蓋了 SAA-C03 中大多數 VPC 數值與分類陷阱。

常見考試陷阱——Amazon VPC

幾乎每次 SAA-C03 考試都會遇到其中至少兩個。在閱讀選項前，先學會識別出題模式。

陷阱一：Security Group 有狀態，NACL 無狀態

暗示你需要為 Security Group 中的回應流量設定匹配輸出規則的選項是干擾項——SG 是有狀態的。反之，忘記 NACL 中臨時連接埠輸出規則的答案，在 NACL 精細調整的情境下會產生連線中斷。若題目呈現 NACL 規則且連線失敗，請懷疑遺漏了臨時連接埠（1024-65535）。

陷阱二：VPC Peering 是非遞移性的

三 VPC 情境：A ↔ B，B ↔ C，題目問 A 是否能透過 B 抵達 C。答案是不能，解決方案是 AWS Transit Gateway，而非另一條 Peering。

陷阱三：Gateway Endpoint 僅涵蓋 S3 與 DynamoDB

任何涉及「不透過 NAT Gateway 私下存取 AWS 服務 X」的情境，預設答案是 Interface Endpoint（PrivateLink）——除非 X 是 Amazon S3 或 Amazon DynamoDB，此時 Gateway Endpoint 免費且是正確答案。

陷阱四：NAT Gateway 高可用性需要每個 AZ 一個

部署單一 NAT Gateway 並將所有私有 Subnet 路由至它，會造成跨 AZ 的單點故障。正確的 HA 模式是每個 AZ 一個 NAT Gateway，各私有 Subnet 的 Route Table 指向同一個 AZ 的 NAT Gateway。

陷阱五：Direct Connect 預設不加密

Direct Connect 是私有連線（不走網際網路路由），但其 Layer 2 不加密。若合規需求強制要求加密，需在 Direct Connect 上疊加 Site-to-Site VPN。

陷阱六：Subnet 只屬於一個 AZ

Subnet 無法跨越多個 AZ。對於 Multi-AZ RDS、跨 AZ 的 Auto Scaling 及類似的韌性需求，你需要每個 AZ 建立一個 Subnet。描述「一個 Subnet 跨越多個 AZ」的選項是干擾項。

陷阱七：VPC 是區域性的，Subnet 是 AZ 範圍的

Amazon VPC 是區域性（Regional）構件——你不會為每個 AZ 建立一個 VPC。VPC 內的每個 Subnet 才是 AZ 範圍的。暗示「每個 AZ 一個 VPC」的答案是錯誤的。

VPC 作為根基主題——其他 SAA-C03 領域如何引用它

本主題是後續 SAA-C03 主題連結回來的基礎。以下說明各領域如何在本篇的 VPC 概念上進一步延伸：

• 領域 1——application-security-protection：AWS WAF 部署在公有 Subnet 中的 Application Load Balancer 前方。AWS Shield 保護面向公開的 ENI。Amazon GuardDuty 消費 VPC Flow Logs 進行威脅偵測。AWS Network Firewall 位於檢查 Subnet 中。
• 領域 1——data-encryption-key-management：私有 Subnet 中的工作負載透過 Interface Endpoint 私下存取 AWS KMS。
• 領域 2——high-availability-multi-az：Multi-AZ RDS、ElastiCache 和 Auto Scaling 群組需要本篇分層 Subnet 架構中每個 AZ 每一層都有一個 Subnet。
• 領域 2——disaster-recovery-strategies：跨區域 VPC Peering 或跨區域 Transit Gateway Peering 連接主要和 DR 區域。
• 領域 3——high-performing-network-architectures：深入探討 Transit Gateway、PrivateLink 效能、Direct Connect 虛擬介面及大規模 CIDR 規劃。
• 領域 3——data-transfer-solutions：AWS DataSync 和 AWS DMS 部署在私有 Subnet 中，透過 Gateway Endpoint 存取 S3。
• 領域 4——cost-optimized-network：使用 Gateway Endpoint 避免 NAT Gateway 費用、共用 NAT Gateway 模式、Transit Gateway 附件成本對比 Peering、Direct Connect 對比 VPN 的成本分析。

每一個後續主題都假設你已熟悉本篇的基本元件。有疑問時，回來這裡查閱。

FAQ——Amazon VPC 高頻問題

Q1：Security Group 與 NACL 有什麼差別？

Security Group 是有狀態（Stateful）的執行個體層級防火牆，附加在 ENI 上。它只支援允許規則，可將其他 Security Group 引用為來源，並自動允許回應流量。NACL 是無狀態（Stateless）的Subnet 層級防火牆，具有有編號的規則（從最小號碼起評估，第一個比對成功者獲勝），同時支援允許與拒絕，且輸入與輸出方向都需要明確的規則——包括回程路徑上的臨時連接埠範圍。Security Group 適用於精細的執行個體間規則，NACL 適用於粗粒度的 Subnet 邊界防護。兩者相輔相成，強健的 SAA-C03 設計兩者都會使用。

Q2：公有 Subnet 與私有 Subnet 有什麼差別？

公有 Subnet 的 Route Table 有一條將 0.0.0.0/0 導向 Internet Gateway 的條目，且其中的資源擁有公有 IPv4 位址。私有 Subnet 沒有這條預設路由——其中的資源只有私有 IP，無法從網際網路直接存取。私有 Subnet 通常將 0.0.0.0/0 路由至（位於公有 Subnet 的）NAT Gateway，讓出站呼叫仍可運作，但來自網際網路的主動連入連線是不可能的。這個區別完全取決於 Route Table 和 IGW——Subnet 物件本身並沒有「公有」旗標。

Q3：何時應使用 Gateway Endpoint，何時應使用 Interface Endpoint？

當你想私下存取 Amazon S3 或 Amazon DynamoDB 時，使用 Gateway Endpoint——這是 Gateway Endpoint 支援的唯二服務，且免費。對於所有其他 AWS 服務（AWS KMS、AWS Secrets Manager、AWS Systems Manager、Amazon SQS、Amazon SNS、Amazon ECR 等）以及透過 PrivateLink 發布的第三方 SaaS 服務，使用 Interface Endpoint（AWS PrivateLink）。Interface Endpoint 收取每 AZ 每小時費加上每 GB 處理費，但支援範圍廣得多。在成本最佳化方面，務必先確認 S3 Gateway Endpoint 是否可以取代 NAT Gateway 的資料處理費用。

Q4：何時應使用 VPC Peering，何時應使用 AWS Transit Gateway？

當 VPC 數量少（通常 2-4 個）、沒有遞移路由需求，且 CIDR 不重疊時，使用 VPC Peering。Peering 不收每小時費，並直接使用 AWS 骨幹網路，沒有頻寬上限。當 VPC 數量多（5 個以上）、採用輻射型或全網狀拓撲，或有遞移路由需求（VPC A 需透過中央中樞抵達 VPC C）時，使用 AWS Transit Gateway。Transit Gateway 也整合混合連線——一個 Direct Connect 閘道或 VPN 附件就能抵達所有輪輻 VPC。Transit Gateway 按每附件每小時和每 GB 處理費計費，在極小規模時比 Peering 昂貴，但在中大規模時管理便利許多。

Q5：何時應使用 Site-to-Site VPN，何時應使用 AWS Direct Connect？

當你需要在數分鐘至數小時內建立混合連線、頻寬需求低至中等（每條隧道最高約 1.25 Gbps），或需要一條透過公共網際網路的加密連線時，使用 AWS Site-to-Site VPN。當你需要穩定的低延遲、1-100 Gbps 的專用頻寬、持續的大量資料傳輸，或可被驗證的私有網路路徑——但可接受數週至數月的佈建時間——時，使用 AWS Direct Connect。許多實際架構兩者並用：Direct Connect 作為主要穩態路徑，VPN 作為備援；或在 Direct Connect 上疊加 VPN 以在專用光纖上增加加密。

Q6：VPC Flow Logs 如何協助問題排查與安全性？

VPC Flow Logs 擷取流經 VPC ENI 的每個 IP 封包的詮釋資料——來源／目的地 IP 和連接埠、通訊協定、位元組數、封包數，以及是否被 Security Group 與 NACL 組合評估後 ACCEPTed 或 REJECTed。這使得 Flow Logs 成為工作負載無法連線至 VPC 內另一個工作負載時的首選工具：在相關 ENI 上搜尋 REJECT 記錄，找出有問題的 NACL 或 Security Group 規則。Flow Logs 也會饋送至 Amazon GuardDuty 進行自動化威脅偵測。將 Flow Logs 發布至 Amazon CloudWatch Logs 以進行即時查詢，發布至 Amazon S3 進行長期封存，或發布至 Amazon Kinesis Data Firehose 進行即時串流管道處理。請記住：Flow Logs 是詮釋資料，不是封包擷取工具——若需要完整封包檢測，請使用 VPC Traffic Mirroring。

Q7：如何為 SAA-C03 設計一個 Multi-AZ、可正式生產的 Amazon VPC？

從 RFC 1918 範圍中選一個 /16 VPC CIDR 開始。在至少 2-3 個 AZ 中劃分三個層：每個 AZ 一個公有 Subnet，供面向網際網路的 Load Balancer 和 NAT Gateway 使用；每個 AZ 一個私有應用程式 Subnet，供 EC2/ECS/EKS 工作負載使用，預設路由指向同一 AZ 的 NAT Gateway；每個 AZ 一個私有資料 Subnet，供 RDS、ElastiCache 和 OpenSearch 使用。部署每個 AZ 一個 NAT Gateway 以避免跨 AZ 故障。新增 S3 與 DynamoDB 的 Gateway Endpoint 以降低 NAT 費用，並為私有工作負載頻繁呼叫的 AWS 服務新增 Interface Endpoint。若預期有多個 VPC，將 VPC 連接至 AWS Transit Gateway；混合連線則使用 AWS Direct Connect 加上傳輸 VIF。啟用 VPC Flow Logs 並發布至 S3 進行稽核。這就是 SAA-C03 的標準 Well-Architected VPC 設計。

延伸閱讀

• Amazon VPC 使用者指南
• Security Groups for Your VPC
• Network ACLs for Your VPC
• NAT Gateways
• VPC Endpoints and AWS PrivateLink
• VPC Peering Guide
• AWS Transit Gateway Guide
• AWS Site-to-Site VPN User Guide
• AWS Direct Connect User Guide
• VPC Flow Logs
• AWS SAA-C03 考試指南（PDF）