VPC 架構、CIDR 設計與子網規劃

VPC 架構在 ANS-C01 中與 SAA-C03 的側重點完全不同。助理架構師 (SAA) 考試會問：「資料庫應該放在哪個子網路？」。而 Advanced Networking Specialty (進階網路專家) 考試則會問：「你有 3 個區域中的 47 個帳號，最初的 VPC 大小設定為 /24，自動擴展示範組已開始出現 IP 用盡的情況，且最近收購的公司引入了一個使用 10.0.0.0/16 CIDR 的 VPC，與你的 VPC 重疊——請在 60 秒內設計出不中斷生產環境的連線性」。這是一個網路工程師的問題，涉及 CIDR 大小規則、每個子網路的 5 個保留 IP、IPv6 雙堆疊、將 RFC 6598 100.64.0.0/10 電信級 NAT 空間作為次要 CIDR、AWS IP 位址管理員 (IPAM) 池層次結構、BYOIP、透過 Resource Access Manager 進行 VPC 共用、VPC 對等互連的非傳遞性質，以及 ENI 的前綴委派，還有針對重疊位址空間的 PrivateLink / NAT / Transit Gateway 解決方案——而 ANS-C01 經常在單一情境題中測試所有這些移動零件。

本主題完全對應至領域 1 (網路設計，佔考試 30%) 的任務說明 1.6。官方 ANS-C01 考試指南逐字列出了知識要點：「不同的連線性模式與使用案例 (例如 VPC 對等互連、Transit Gateway、AWS PrivateLink)」、「VPC 共用的功能與優勢」以及「考慮到 IP 位址重疊的 IP 子網路與解決方案」。這些技能要求你為特定需求選擇正確的 VPC 間服務、管理 IP 重疊，並在多帳號設定中使用 VPC 共用。大約 65 題考試題目中有 8 到 12 題會觸及此領域，幾乎總是以情境題而非純粹的記憶題形式出現。

為什麼 CIDR 設計是 ANS-C01 領域 1 的基礎

CIDR 設計錯誤會產生複利效應。第一年選擇的 /24 VPC，到了第三年會變成多帳號、多區域生產環境的爆炸半徑，且補救成本隨工作負載遷移範圍線性增長。專家級考試之所以測試這一點，是因為實務中的網路工程師每天都會遇到這些後果——自動擴展子網路中的 IP 枯竭是 AWS 支援案例中的常客，而重疊 CIDR 的補救則是 AWS re:Invent 中最常被問到的架構審查問題。ANS-C01 期望你能在設計時防止問題，並在修補時解決問題。

考試獎勵的心智模型是將 IP 位址視為集中治理的有限組織資源。孤立設計單一 VPC 是錯誤的出發點。正確的出發點是在組織根目錄建立 AWS IPAM 池層次結構，由區域和營運池向每個帳號分配非重疊的 CIDR，並為 RFC 6598 100.64.0.0/10 預留空間作為自動擴展溢出的逃生閥。考試會以高分獎勵這種思維；而將 VPC CIDR 視為單一 VPC 決策的考生將在重疊 CIDR 的干擾項中失分。

白話文解釋 VPC 架構與 CIDR 設計

VPC CIDR 規劃結合了 IP 算術、AWS 保留位址、IPv6 雙堆疊機制、多帳號治理與衝突解決。三個類比可以幫助理解這些移動零件。

類比一 — 房地產開發總體規劃

VPC CIDR 是總體規劃城市中的一塊土地。CIDR 區塊是地塊邊界——一旦圍起來，擴張就需要測量和分區審核。子網路是地塊內的街區，其大小應符合你預期的建築 (工作負載)；過大的街區會浪費土地，過小的街區在公寓大樓 (自動擴展群組) 想要擴建時，會被迫進行昂貴的分區變更。每個子網路的 5 個保留 IP 是城市在街區開始時始終安裝的消防栓、郵箱、路燈、變壓器和雨水排水管——你不能停在它們的位置上。AWS IPAM 是城市規劃部門，負責從主網格中分發不重疊的地塊分配，拒絕重複地址並追蹤誰擁有什麼。次要 CIDR 是當原始地塊填滿時你補上的吞併地塊——連接到同一個地址，但在地圖上不連續。VPC 對等互連是兩個相鄰地塊之間的共用車道——對兩個鄰居有用，但不能延伸到第三個鄰居 (非傳遞路由)。VPC 共用則是綜合開發案，其中一個業主持有產權 (參與者帳號共用子網路)，但多個租戶在內部經營業務。重疊 CIDR 問題則是收購的財產使用了與你現有街區相同的門牌號碼——郵件 (封包) 在沒有中間轉寄人 (NAT 或 PrivateLink) 的情況下，無法區分該送到哪一間房子。

類比二 — 電話號碼編號計劃

將 CIDR 區塊想像成國家電話編號計劃中的區域碼。/16 是擁有 65,536 個電話號碼 (IP 位址) 的區域碼。/24 是擁有 256 個號碼的小鎮交換機。/28 是只有 16 個號碼的單一鄰里區塊，其中第一個 (網路位址)、第二個 (VPC 路由器)、第三個 (DNS 解析器)、第四個 (預留供未來使用) 和最後一個 (廣播) 被電話公司佔用——每個 /28 留給你 11 個可用號碼。IPv6 雙堆疊是向新編號方案的遷移，擁有實際上無限的號碼 (每個 VPC 為 /56，每個子網路為 /64)；舊電話 (舊式 IPv4) 和新電話 (IPv6) 透過雙堆疊 ENI 共存。AWS IPAM 是國家編號管理局，向電信商 (帳號) 分配區域碼且不重複，並回收未使用的範圍。BYOIP 是攜碼轉網選項，AWS 託管並通報 (透過 BGP 宣告) 你從自己的 ARIN/RIPE 分配中帶來的 IP 空間。重疊 CIDR 是兩家電信商都被分配了 555 區域碼——當客戶撥打 555-1234 時，網路不知道該撥通哪家電信商的客戶；解決方案是 NAT 等效方案，將一家電信商的 555 轉換為不同的前綴。

類比三 — 具備前台的公寓大樓

VPC 是一棟公寓大樓，CIDR 是大樓的地址範圍，而子網路則是樓層。VPC 路由器 (.1 保留位址) 是大樓的郵件收發室，知道每個包裹該去哪個樓層。AmazonProvidedDNS (.2 保留位址) 是前台管理員，回答「資料庫的內部 IP 是什麼？」。5 個保留 IP 是每層樓都被佔用的五個大樓服務室——你永遠租不到。VPC 對等互連是兩棟大樓之間的私有走廊——對這兩棟大樓的居民很方便，但第三棟大樓的居民不能把它當作捷徑 (非傳遞性)。Transit Gateway 是中央轉運中心，透過一個完善的轉運終端將城市中的每棟大樓連接到所有其他大樓——而且它可以在任何兩者之間路由 (具備傳遞性)。VPC 共用是一個組織擁有整棟大樓，而不同的部門租用特定的樓層並像經營獨立辦公室一樣運作。PrivateLink 是氣動管系統，將一間公寓直接連接到另一棟大樓的服務提供商，而完全不使用走廊——當兩棟大樓具有相同的地址編號 (重疊 CIDR) 且無法建立正常的走廊連接時，這非常完美。

VPC 基礎 — CIDR 大小、保留 IP 與子網路算術

VPC 是一個區域性的、邏輯隔離的虛擬網路，在建立時由一個 /16 到 /28 大小的主要 IPv4 CIDR 區塊定義。AWS 會拒絕超出此範圍的請求——/15 太大，/29 太小。

允許的 CIDR 範圍與 RFC 1918 預設值

AWS 允許任何 IPv4 範圍，但傳統上你會使用 RFC 1918 私有空間：10.0.0.0/8、172.16.0.0/12 或 192.168.0.0/16。在 VPC 中使用公有 IPv4 技術上可行 (你擁有一個公有範圍並想在內部使用) 但很少見；除非 AWS BYOIP 代表你進行宣告，否則在 VPC 內部使用的公有 IPv4 無法透過 VPC 的 IGW 在網際網路上路由。大多數 VPC 使用 10.x.x.x，因為 /8 提供了最大的規劃空間。

每個子網路 5 個保留 IP

無論大小，每個子網路都有 AWS 保留的 5 個 IP 位址：

• .0 — 網路位址 (子網路識別碼)。
• .1 — VPC 路由器 (每個 ENI 用於非本地流量的隱含預設閘道)。
• .2 — AmazonProvidedDNS (VPC 內部 DNS 解析器，也稱為 Route 53 Resolver 預設端點)。
• .3 — 保留供 AWS 未來使用。
• .255 (或子網路中的最後一個 IP) — 網路廣播 (AWS 實際上不進行廣播，但該位址已被預留)。

一個 /28 子網路有 16 個位址，其中 5 個被預留——剩下 11 個可用。一個 /24 有 256 個，剩下 251 個。一個 /22 有 1024 個，剩下 1019 個。ANS-C01 期望你能像直覺一樣在考試壓力下立即完成這項計算。

子網路大小的權衡

較大的子網路 (例如 /22) 提供了增長空間，但會浪費跨多個 AZ 和帳號的 IP 位址空間。較小的子網路 (例如 /27) 可以節省空間，但會讓你面臨自動擴展爆發期間 IP 枯竭的風險——當 EKS 上的 200 個 pod 透過前綴委派在只有 11 個可用 IP 的 /28 子網路中啟動時，你會立即遇到 ENI 分配失敗。

務實的平衡是每個子網路 /24 (251 個可用)，每個 AZ 有三個或四個子網路用於層級分離 (公有、私有、隔離、內部)。對於高密度的 EKS 或容器工作負載，每個子網路 /22 或 /21 是合適的，特別是當前綴委派 (prefix delegation) 為每個 ENI 分配 /28 的 IPv4 或 IPv6 區塊時。

IPv6 雙堆疊與僅限 IPv6 的子網路

AWS 中的 IPv6 是一個獨立的平行位址平面。VPC 可以是僅限 IPv4、雙堆疊 (dual-stack) (IPv4 + IPv6) 或僅限 IPv6 (這是較新的 AWS 選項)。在 ANS-C01 中，預計會出現探討雙堆疊與僅限 IPv6 部署之間的差異以及對出口影響的題目。

IPv6 CIDR 分配

AWS 從 Amazon 擁有的池 (或你的 BYOIPv6 池) 中為每個 VPC 分配一個 /56 IPv6 CIDR。每個子網路從該 /56 中劃分出一個 /64——這意味著單一子網路擁有 1,800 億億個 IPv6 位址，而單一 VPC 可以劃分出 256 個不同的 /64 子網路。

IPv6 沒有與 5 個保留 IP 慣例完全等效的限制——AWS 在每個 /64 中保留前四個位址和最後一個位址，但在擁有 2^64 個位址的情況下，這種計算無關緊要。

僅限出口網際網路閘道 (Egress-only Internet Gateway)

在 IPv6 中，每個位址都是全球唯一的且全球可路由的——沒有「私有 IPv6」。為了防止來自網際網路的入站流量，同時允許出站流量，AWS 提供了僅限出口網際網路閘道 (EIGW)。EIGW 是 IPv4 中 NAT 出站的 IPv6 等效方案：具備狀態，允許出站 + 回程流量，拒絕未經請求的入站流量。AWS 中的 IPv6 不使用 NAT，因為每個 IPv6 位址已經是公有的，不需要位址轉換。

僅限 IPv6 的子網路

僅限 IPv6 的子網路沒有 IPv4 CIDR。其中的工作負載沒有 IPv4 位址。要與僅限 IPv4 的 AWS 服務或 IPv4 網際網路通訊，你需要 DNS64 + NAT64——Route 53 Resolver 為僅限 IPv4 的目的地合成 AAAA 記錄，而 NAT 閘道在 NAT64 模式下會在傳輸時進行 IPv6 → IPv4 轉換。這是 AWS 推薦的現代 IPv6 部署模式。

次要 CIDR 區塊與 RFC 6598 100.64.0.0/10

當 VPC 的 IPv4 位址用盡時，你有三種選擇：以更大的 CIDR 重建 VPC (遷移成本高)、縮小現有子網路 (不可能——子網路無法調整大小)，或增加次要 CIDR。

增加次要 CIDR

VPC 預設情況下最多可以擁有 5 個 IPv4 CIDR 區塊 (可透過服務配額提高至 50 個)。透過 associate-vpc-cidr-block 增加次要區塊。新區塊可以來自同一個 RFC 1918 超網，也可以來自不重疊的範圍——一個常見的模式是使用原始的 10.0.0.0/16 作為主要，並增加 100.64.0.0/16 (RFC 6598 電信級 NAT 空間) 作為次要。

為什麼選擇 RFC 6598 100.64.0.0/10

RFC 6598 為共用位址空間劃分了 100.64.0.0/10——它在公用網際網路上不可路由，不會與任何 RFC 1918 範圍衝突，且在企業本地環境中很少使用。AWS 在 VPC 中專門支持它作為規範性的「10.x.x.x 用盡且需要更多」的範圍。使用案例：

• 透過前綴委派消耗 IP 速度快於 /16 所能負荷的 EKS pod。
• 在 VPC 模式下具備高並行性的 Lambda。
• 爆發到數千個執行個體的自動擴展群組 (Auto Scaling groups)。

次要 CIDR 的子網路運作方式與主要 CIDR 子網路相同——相同的路由規則、相同的安全群組、相同的出口路徑。

次要 CIDR 限制

存在一些限制：次要 CIDR 不能與主要重疊，不能與對等 VPC 重疊，且不能來自與 VPC 連接的任何 TGW 路由表中的現有路由重疊的範圍。禁止使用 CIDR 區塊 169.254.0.0/16 (連結本地)、224.0.0.0/4 (多點傳送) 和 240.0.0.0/4 (預留)。

AWS IPAM — 多帳號治理的 IP 位址管理員

Amazon VPC IP Address Manager (IPAM) 是 AWS 原生的控制平面，用於在整個組織內分配 IP 位址。在 ANS-C01 考試中，它是「我們在 3 個區域中有 50 個帳號，我們需要確保沒有兩個 VPC 共用同一個 CIDR」的規範答案。

池層次結構 (Pool hierarchy)

IPAM 將位址空間建模為池的層次結構：

• 組織範圍的頂層池 (例如 10.0.0.0/8) — 主分配池。
• 從頂層池劃分出的區域池 (例如 us-east-1 為 10.0.0.0/12，eu-west-1 為 10.16.0.0/12)。
• 從區域池劃分出的營運池 (例如生產環境為 10.0.0.0/16，開發環境為 10.1.0.0/16)。
• 從營運池提取的帳號範圍分配 — 當帳號建立 VPC 時，它向營運池請求一個 CIDR，IPAM 會分發一個不重疊的區塊。

分配規則與地區 (Locale)

每個池都可以有分配規則：最小和最大允許 CIDR 長度、要求的 CIDR 長度、允許從中分配的 CIDR。地區 (Locale) 將池綁定到特定的 AWS 區域——該區域的 VPC 必須向具備匹配地區的池發送請求。

合規性監控

IPAM 持續監控 VPC 並顯示合規性事件：「VPC X 使用的 CIDR 不屬於任何池」、「VPC Y 與 VPC Z 重疊 (儘管不在池中)」。這是受監管產業常見的「證明組織中沒有兩個 VPC 重疊」需求的審計故事。

透過 RAM 進行跨帳號共用

頂層池建立在集中式帳號 (通常是網路帳號) 中，並透過 AWS Resource Access Manager (RAM) 共用給所有成員帳號。成員帳號透過池 API 請求 CIDR；池會追蹤誰獲得了什麼。這是 AWS 安全參考架構 (SRA) 的 IP 治理模式，也是專家級考試的重點。

透過 AWS Resource Access Manager 進行 VPC 共用

VPC 共用讓一個 AWS 帳號 (擁有者) 與其他帳號 (參與者) 共用 VPC 的子網路，以便參與者可以直接在擁有者的子網路中啟動資源 (EC2、RDS、Lambda)。參與者不擁有 VPC，不控制路由，且無法建立新子網路——他們僅消耗共用子網路內的容量。

擁有者與參與者模型

擁有者帳號控制 VPC：CIDR、路由表、安全群組、NACL、IGW、NAT 閘道、VPC 對等互連連線、Transit Gateway 連接。參與者帳號控制其在共用子網路中啟動的資源：EC2 執行個體、RDS 叢集、Lambda 函式。參與者也可以在共用 VPC 內建立自己的安全群組。

為什麼使用 VPC 共用而非每個帳號一個 VPC

在共用功能出現之前，典型的模式是「每個帳號一個 VPC，透過對等互連或 TGW 連接」。這會浪費 IP 空間 (每個 VPC 都需要自己的 CIDR) 並使管理成本爆炸 (每個 VPC 都有自己的 NAT、自己的路由表、自己的出口路徑)。VPC 共用將 50 個 VPC 合併為一個由網路帳號擁有的共用大 VPC，50 個參與者帳號在其中啟動工作負載——節省了 NAT 成本，簡化了出口，並集中了 IP 規劃。

共用先決條件

VPC 共用要求啟用 AWS Organizations 且開啟所有功能。子網路透過 RAM 共用。擁有者可以隨時撤銷共用，這會立即阻止新的資源啟動，但不會終止現有的參與者資源——那些資源將保留直到參與者自行終止。

VPC 對等互連 — 同區域、跨區域與非傳遞路由

VPC 對等互連 (VPC peering) 在相同或不同區域和帳號的兩個 VPC 之間建立私有連線。對等互連是非傳遞性的 (non-transitive)：如果 VPC A 與 VPC B 對等，且 VPC B 與 VPC C 對等，A 無法透過 B 連線到 C。每個對等互連都是點對點的。

同區域 vs 跨區域

同區域對等互連在對等 VPC 之間沒有資料傳輸費用 (在區域內)。跨區域對等互連則收取跨區域傳輸費並增加延遲。兩者都在 AWS 網路邊緣加密流量，但使用者無法在 IPsec 層級進行設定。

對等互連路由表設定

對等互連不會自動填入路由表。兩側必須手動新增路由，透過對等互連連線 ID 指向對方的 CIDR。這是「我建立了對等互連但無法通訊」疑難排解案例的長年來源。

禁止 CIDR 重疊

兩個 CIDR 重疊的 VPC 無法建立對等互連——AWS 在建立時會拒絕該請求。解決方案是 PrivateLink、NAT 或 CIDR 重構。

對等互連擴展限制

單一 VPC 支援 125 個活動對等互連連線。超過此限制，Transit Gateway 就是答案。50 個 VPC 的全網格對等互連需要 50 × 49 / 2 = 1225 個連線——在管理上是不可行的。TGW 將其簡化為 50 個連接和一個路由表。

重疊 CIDR 問題 — NAT、PrivateLink 與 TGW 解決方案

兩個 CIDR 重疊的 VPC 無法對等互連，無法連接到同一個 TGW 路由表，也無法直接路由。進階網路專家考試會測試四種解決方案，按優先順序排列如下。

解決方案 1：PrivateLink

具備服務提供商模式的 AWS PrivateLink 可以完全繞過重疊問題。提供商 VPC 透過 NLB 發布服務，取用者 VPC 建立指向該服務的介面端點。端點 ENI 位於取用者 VPC 的 CIDR 中——無需對等互連，無共用位址空間——取用者不需要知道提供商的內部 IP。當需求是單向服務取用 (例如呼叫 API) 時，這是最簡潔的答案。

解決方案 2：基於 NAT 的重定向

每個 VPC 將對方的流量 NAT 到一個不重疊的範圍。VPC A 到 VPC B 的流量會被 NAT (例如透過 NAT 執行個體或設備)，使其看起來像是來自不重疊 CIDR 的流量。雙向 NAT 可行，但引入了狀態性並破壞了端對端 IP 可見性——診斷和安全遙測變得更加困難。

解決方案 3：具備路由表技巧的 Transit Gateway

TGW 路由表可以使用路由表關聯與傳播，將重疊 VPC 之間的流量引導至執行位址轉換的中間檢查或 NAT VPC。這比直接對等互連更靈活，但需要仔細的路由表設計。

解決方案 4：重構 CIDR

暴力選項：為其中一個重疊的 VPC 重新分配 IP。成本高 (工作負載遷移成本) 但能永久消除問題。使用 AWS IPAM 分配一個新的非重疊範圍並進行遷移。

BYOIP — 攜帶自己的 IP 位址

攜帶自己的 IP (BYOIP) 讓你通報自己擁有的公有 IP 範圍 (來自 ARIN、RIPE、APNIC 等)，以便 AWS 代表你託管並宣告這些位址。當情境提到「我們擁有想要保留的公有 IP 區塊」、「法規或品牌需要我們的特定 IP 範圍」或「我們正在從本地遷移且不想更改 DNS 映射的 IP」時，BYOIP 就是答案。

BYOIP 要求

你必須擁有該 IP 範圍並獲得區域註冊機構的授權。你向 ARIN/RIPE 提供 Route Origin Authorization (ROA)，允許 AWS 進行宣告。最小 CIDR：IPv4 為 /24，IPv6 為 /48。較小的區塊無法在全球 BGP 網格上進行宣告。

BYOIP 使用案例

• 來自 BYOIP 池的彈性 IP — 分配給 NAT 閘道、NLB 或 EC2 執行個體，替換 AWS 分配的 EIP。
• 來自 BYOIP 的 VPC 主要 CIDR — 你在 VPC 內部擁有的 IP 空間；結合來自 BYOIP 池的 EIP，指向你 IP 範圍的本地 DNS 在雲端切換期間能繼續工作，無需 DNS 遷移。
• Direct Connect 上的 MACsec 使用你擁有的 IP 進行對等互連——請參閱 Direct Connect 主題。

BYOIP 與 MACsec

100Gbps 的 Direct Connect MACsec 要求 BGP 對等互連位址使用 BYOIP。這是 ANS-C01 考試中的專家級整合問題——請參閱 Direct Connect 主題以獲取完整模式。

多帳號 VPC 模式 — 星狀拓撲 vs 全網格

兩種規範性的多帳號 VPC 拓撲是星狀拓撲 (具備 TGW 的 hub-and-spoke) 和全網格 (具備對等互連的 full-mesh)。進階網路專家考試期望你能根據 VPC 數量、通訊模式和維運複雜性在兩者之間做出選擇。

具備 TGW 的星狀拓撲 (Hub-and-spoke)

每個 VPC 都連接到中央 TGW。TGW 路由表對分支進行分段——生產分支僅能看到其他生產分支，開發僅能看到開發，共用服務能看到所有人。每個分支一個連接，集中控制路由，透過 TGW Network Manager 進行集中日誌記錄。可擴展至數千個 VPC。

全網格對等互連 (Full-mesh peering)

每一對 VPC 都建立對等互連。最適合 VPC 數量較少 (5 個或更少) 且 VPC 間通訊頻繁的情況。超過 10 個 VPC，網格在管理上會變得不可行——管理介面隨數量呈平方增長 (n × n-1 / 2 個連線)。

決策準則

• <5 個 VPC：對等互連即可，無 TGW 成本。
• 5–10 個具備選擇性通訊的 VPC：如果流量模式稀疏，對等互連仍然合理。
• >10 個 VPC 或任何組織規模的架構：TGW 是唯一答案。

進階網路專家考試通常會給出 20 個以上 VPC 的情境並預期選擇 TGW。如果選項中包含 50 個 VPC 的對等互連，那就是干擾項。

彈性 IP、次要 ENI 與前綴委派

彈性 IP 分配與限制

彈性 IP (EIP) 是靜態的 IPv4 公定位址，可以在資源間重新映射。預設限制：每個區域 5 個 EIP (可提高)。EIP 在未關聯到執行中個體時會按小時收費——這是規範性的「EIP 空閒收費」陷阱。

次要 ENI 與別名 IP

一個 EC2 執行個體可以附加多個次要 ENI。每個 ENI 從子網路獲得一個主要私有 IP，並可以擁有多個次要私有 IP。次要 ENI 用於：單一執行個體上的多租戶路由、基於 IP 的授權軟體，以及高可用性 ENI 故障轉移模式。

ENI 的前綴委派 (Prefix delegation)

前綴委派為 ENI 分配 /28 IPv4 前綴或 /80 IPv6 前綴，而非單個 IP。這是高密度 EKS 工作負載的現代 AWS 模式——每個 ENI 獲得 16 個 IPv4 位址或 2^48 個 IPv6 位址，無需進行 16 次次要 IP 分配。對於 Nitro 執行個體上的大規模 EKS pod，前綴委派是強制性的。

常見陷阱複習 — VPC 架構與 CIDR 設計在 ANS-C01

陷阱 1：允許使用 /29 和 /30 子網路

錯誤。子網路最小為 /28。AWS 在 API 調用時會拒絕任何更窄的範圍。

陷阱 2：每個子網路有 3 個保留 IP

錯誤。每個子網路始終有 5 個 保留 IP (網路、.1 路由器、.2 DNS、.3 未來使用、最後一個廣播)。

陷阱 3：當兩端都授權時，VPC 對等互連具備傳遞性

錯誤。對等互連絕不具備傳遞性。即使接受了所有對等互連，A → B → C 也不通。

陷阱 4：啟用傳播時會自動填入對等互連路由

錯誤。對等互連路由始終是靜態的。路由傳播僅適用於 VGW 和 TGW。

陷阱 5：IPv6 出站需要 NAT 閘道

錯誤。IPv6 使用僅限出口網際網路閘道，而非 NAT 閘道。NAT64 (另一個功能) 進行 IPv6 → IPv4 轉換。

陷阱 6：兩個具有重疊 10.0.0.0/16 的 VPC 可以直接使用 TGW

錯誤。TGW 路由表無法直接處理重疊——你需要 NAT、PrivateLink 或重構。

陷阱 7：一個 VPC 支援無限數量的次要 CIDR

錯誤。預設為每個 VPC 5 個 CIDR 區塊 (可提高至 50 個)。

陷阱 8：BYOIP 允許宣告任何大小的區塊

錯誤。最小值為 IPv4 為 /24，IPv6 為 /48——任何更小的區塊都無法在全球 BGP 上宣告。

陷阱 9：VPC 共用需要 Direct Connect 或對等互連

錯誤。VPC 共用透過 RAM 實現且需要 AWS Organizations——不需要設定網路層。

陷阱 10：100.64.0.0/10 像 1.1.1.0/24 一樣是公可路由的

錯誤。100.64.0.0/10 是 RFC 6598 電信級 NAT 空間——在公用網際網路上不可路由，可安全用作次要 CIDR。

陷阱 11：IPAM 在沒有 AWS Organizations 的情況下也能運作

部分正確。IPAM 可以在單個帳號中運作，但跨帳號治理使用案例 (規範性的考試情境) 要求 AWS Organizations + RAM 共用。

陷阱 12：子網路在建立後可以調整大小

錯誤。子網路 CIDR 是不可變的。要調整大小，必須建立新子網路、遷移工作負載，然後刪除舊子網路。

FAQ — VPC 架構與 CIDR 設計在 ANS-C01

Q1：可以託管 14 個 EC2 執行個體的最小子網路為何？

/28 有 16 個位址，其中 5 個被 AWS 預留——剩下 11 個可用。這不足以容納 14 個執行個體。下一個大小是 /27，有 32 個位址，其中 27 個可用——綽綽有餘。ANS-C01 經常包含差一錯誤 (off-by-one) 的問題，考生必須記住 5 個保留規則 (而非教科書子網路算術中的 2 個保留)，並選擇正確的子網路大小。背熟表格：/28 = 11, /27 = 27, /26 = 59, /25 = 123, /24 = 251。

Q2：何時應增加次要 CIDR 與重構 VPC？

在以下情況增加次要 CIDR：(a) 現有 VPC 已在生產中且遷移成本高，(b) IP 枯竭出現在特定的自動擴展子網路中，且你可以在次要區塊中建立新的較大子網路，(c) 原始 CIDR 規劃合理，但單一增長模式突破了它。在以下情況進行重構：(a) 原始 CIDR 規劃不當 (例如整個生產 VPC 只有 /24) 且枯竭會反覆發生，(b) 次要 CIDR 選項無法提供足夠的空間 (你已經增加了 5 個次要區塊)，或 (c) 你需要與新的、受 IPAM 管理的企業計劃保持一致。ANS-C01 通常將使用 100.64.0.0/16 的次要 CIDR 作為答案；而當考試提到「長期」或「戰略性」CIDR 治理時，答案則是重構。

Q3：為什麼同時需要網際網路閘道和 NAT 閘道？

IGW 是 VPC 與公用網際網路的連線——它允許公有 IP 位址 (EIP 和自動分配的公有 IP) 發送和接收流量。在公有子網路中的資源直接路由到 IGW。在私有子網路中的資源沒有公有 IP，無法直接使用 IGW，且需要 NAT 閘道 (位於公有子網路) 將其私有 IP 屏蔽為 NAT GW 的 EIP，以便進行僅限出站的流量。NAT GW 是具備狀態的——允許對出站發起連線的回程流量；拒絕未經請求的入站流量。ANS-C01 敏銳地區分了「公有子網路」(路由到 IGW) 與「私有子網路」(路由到 NAT GW 進行出站)——選錯一個就是常見的干擾項。

Q4：多帳號設定中 VPC 共用與 VPC 對等互連有何不同？

VPC 共用是由一個帳號擁有的單一 VPC，透過 RAM 將子網路共用給多個參與者帳號——參與者直接在共用子網路中啟動資源並消耗共用 CIDR 的容量。VPC 對等互連是兩個獨立的 VPC (每個帳號一個)，透過對等互連鏈路連接，每個帳號完全擁有自己的 CIDR、路由表和資源。共用節省了 IP 空間 (一個 VPC 而非 N 個) 和維運成本 (一組 NAT GW、一個路由表)。對等互連保留了帳號隔離 (每個帳號完全擁有自己的 VPC)，但會使 IP 消耗和維運介面倍增。對於單一環境中的 50 個以上帳號，VPC 共用是現代最佳實務；對等互連則是遺留做法。ANS-C01 青睞 VPC 共用作為「減少擴張」和「集中化網路」情境的答案。

Q5：應避免的最大 CIDR 設計錯誤為何？

為主要 VPC CIDR 選擇 /24 (256 個位址)。每個子網路 5 個保留 IP，外加三個或四個 AZ 子網路，外加增長空間，外加 EKS pod 密度，會在幾個月內消耗完一個 /24。一旦生產工作負載進入，重構為 /16 就需要昂貴的遷移。網路工程師專家的答案：每個 VPC 至少從 /16 (65,536 個位址) 開始——即使 99% 的空間都沒用到——因為 IP 成本為零，且未來的靈活性巨大。AWS IPAM 讓你從 /8 主池分配 /16 而不會浪費，因為未分配的空間仍保留在池中。

Q6：可以跨區域和跨帳號建立 VPC 對等互連嗎？

可以——跨區域對等互連和跨帳號對等互連都受到支持。跨區域對等互連收取跨區域資料傳輸費，但無需經過網際網路即可實現直接的 VPC 到 VPC 流量。跨帳號對等互連要求請求者帳號發送請求，且接受者帳號接受請求——兩端都必須手動新增路由。單一對等互連可以同時支持這兩者 (跨區域 + 跨帳號)。當涉及兩個以上 VPC 或需要傳遞語義時，ANS-C01 青睞 TGW 對等互連而非 VPC 對等互連；VPC 對等互連適用於兩 VPC 的點對點案例。

Q7：VPC 對等互連全網格拓撲的實際限制為何？

硬性限制是每個 VPC 125 個活動對等互連。實際限制 (管理上的可維護性) 要低得多——全網格中 5 到 10 個 VPC 就會變得難以維護，因為 n × (n-1) / 2 個連線會快速增長。10 個 VPC 就是 45 個對等互連；20 個是 190 個；30 個是 435 個。對於任何現代企業中的 10 個以上 VPC，遷移到 TGW 是強制性的。ANS-C01 會給出 20 個以上 VPC 的情境並預期選擇 TGW；在該規模下的全網格對等互連永遠是錯誤答案。

Q8：為什麼 AWS 保留每個子網路 5 個 IP 而非教科書上的 2 個？

5 個中的 2 個 (網路、廣播) 是標準的子網路慣例。另外 3 個是 AWS 特有的：

• .1 — VPC 隱含路由器 (每個 ENI 的預設閘道)。
• .2 — AmazonProvidedDNS 解析器 (VPC 內部 DNS)。
• .3 — 保留供 AWS 未來使用 (目前未分配給已知服務)。

這些是無法重新分配的 AWS 基礎架構位址。該預留是全局性的 (所有子網路，不論大小)。ANS-C01 期望你將其納入每次子網路大小計算中。

Q9：如何為具有高 pod 密度的 EKS 叢集規劃 VPC 大小？

EKS pod 會消耗 IP 位址。預設情況下，每個 pod 從節點的 ENI 獲得一個主要 IP；使用前綴委派 (Nitro 執行個體)，每個附加的次要 ENI 獲得一個 /28 前綴 (16 個 IP)。一個擁有 4 個 ENI 且每個都委派了 /28 的節點具有 64 個 pod IP。對於 1000 個 pod 的叢集，你需要大約 16 個節點的 IP 容量。每個節點的 IP 需求：計算執行個體 ENI 限制 × 16 (前綴委派) ≈ 每個節點 60–600 個 pod IP，具體視執行個體大小而定。加上每個節點本身為 kubelet 消耗每個 ENI 一個 IP。子網路大小準則：4 個節點 × 100 個 pod = 至少 400 個 IP；進位到 /23 (512 個位址，507 個可用)。對於組織規模的 EKS，每個叢集子網路分配 /20 或 /19。ANS-C01 情境通常涉及 EKS 密度——使用 100.64.0.0/16 的次要 CIDR 是規範答案。

Q10：何時使用 BYOIP 優於使用 AWS 分配的 IP？

當符合以下情況時，BYOIP 是合理的：(a) 你已經擁有了由 ARIN/RIPE 分配的、客戶、合作夥伴或監管機構已知的公有 IP 區塊，(b) 你正在從本地遷移，且 DNS 映射的 IP 在切換期間不能更改，(c) 監管或合約條款要求使用特定的 IP 範圍。AWS 分配的 IP 對於不需要固定 IP 的綠地工作負載 (greenfield workloads) 來說很好——它們更簡單，無需設定 ROA，且 AWS 處理 BGP 宣告。ANS-C01 通常以「我們正在從數據中心 Y 遷移工作負載 X，且現有客戶將 DNS 指向我們的 IP 區塊」來建立 BYOIP 情境——答案是 BYOIP 加上從 BYOIP 池分配的 EIP，附加到相同的工作負載角色 (NAT GW, ELB, EC2)。對於綠地項目，BYOIP 是錯誤答案。

延伸閱讀與相關維運模式

• Configure your VPC — 使用者指南
• VPC and subnet sizing
• Amazon VPC IP 位址管理員是什麼
• VPC Peering
• 與其他帳號共用你的 VPC
• 攜帶自己的 IP 位址 (BYOIP)
• 構建可擴展且安全的多 VPC AWS 網路基礎設施 (白皮書)
• AWS ANS-C01 Exam Guide

一旦 VPC 架構就緒，ANS-C01 上的自然次要維運層級為：Transit Gateway 路由與連接，用於大規模的星狀拓撲；PrivateLink、VPC 端點與端點政策，用於私有服務取用 (特別是跨重疊 CIDR)；VPC 路由 — 最長前綴匹配、傳播與黑洞路由，用於路由決策；以及網路效能 — ENA、EFA、置放群組與巨量框架，用於調整你所構建的 VPC 內部的輸送量。

• Transit Gateway 路由與連接 — ANS-C01 備考筆記
• PrivateLink, VPC 端點與端點政策 — ANS-C01 備考筆記
• VPC 路由 — 最長前綴匹配、傳播與黑洞路由 — ANS-C01 備考筆記
• 網路效能 — ENA, EFA, 置放群組與巨量框架 — ANS-C01 備考筆記