前言：當雲端基礎設施不再是「黑盒子」

在雲端開發的旅程中，AWS VPC (Virtual Private Cloud) 往往是每位IT人員最先接觸、卻也最容易感到困惑的領域。你是否曾經遇到過這樣的狀況：明明設定了子網路 (Subnet)，路由表 (Route Table) 看起來也沒問題，但實例 (Instance) 卻死活連不上網？或者在設定安全規則時，總是在安全性群組 (Security Group) 與網路存取控制清單 (NACL) 之間糾結？

如果你要是一個雲端專家，理解 VPC 的底層機制，是為了建立一個安全、可靠且具備擴展能力的架構基礎。當我們撥開雲端網路的迷霧，將這些看似複雜的設定轉化為清晰的邏輯，VPC 將不再是一個充滿未知的「黑盒子」，而是你手中最強大的架構工具。

重點一：Subnet 裡消失的 IP 地址 — 關於預留位址的真相

在規劃 VPC 的子網路時，開發者通常會根據 CIDR 區塊（例如 /24 或 /28）來計算可用的 IP 地址數量。然而，一個最容易被忽略的細節是：子網路中的 IP 並非全數可用。

在任何一個 AWS 子網路中，AWS 都會自動保留 前 4 個 和 最後 1 個 IP 位址。以 10.0.0.0/24 為例，以下位址是無法分配給實例使用的：

• 10.0.0.0：網路地址 (Network address)。
• 10.0.0.1：由 AWS 保留，用於 VPC 路由器 (VPC Router)。
• 10.0.0.2：由 AWS 保留，用於對應到 Amazon DNS 的映射位址。
• 10.0.0.3：由 AWS 保留供未來使用。
• 10.0.0.255：網路廣播地址 (Network broadcast address)，雖然 VPC 不支援廣播，但仍保留此位址。

「架構師筆記」：這對規劃小規模子網路（如 /28）有著決定性的影響。一個 /28 的子網路理論上擁有 16 個 IP 位址（2^4=16），但在扣除這 5 個保留位址後，實際僅剩 11 個 可供使用。如果你在設計之初忽略了這 31.25% 的損耗，隨著業務擴展，很快就會面臨 IP 位址枯竭的窘境，迫使你必須重新設計整個網路架構。

重點二：防火牆的兩面性 — Security Group 與 NACL 的「狀態」之爭

AWS 提供了兩層網路安全防護：安全性群組 (Security Group) 與網路存取控制清單 (NACL)，它們最核心的差異在於「狀態性」。

• Security Group 是「有狀態的」(Stateful)：這意味著如果你允許了流入 (Inbound) 的流量，對應的回程流出流量會被系統自動允許。這簡化了管理，因為系統會記住連線狀態，你不需要額外考慮回程路徑。
• NACL 是「無狀態的」(Stateless)：這是許多初學者連線失敗的主因。

「無狀態的任何去/回流量都必須由規則明確允許。」

當你使用 NACL 時，即便你允許了 Port 80 的流入流量，如果沒有在流出 (Outbound) 規則中明確允許回應流量（通常是回到暫時連接端口 Ephemeral Ports），連線依然會被阻斷。

「架構師筆記」：Security Group 作用於 實例層級 (Instance level)，而 NACL 作用於 子網路層級 (Subnet level)。在實務設計中，我們通常利用 Security Group 處理大部分的較小的細緻度存取控制，而將 NACL 作為子網路整體的最後一道防線，用於較大的細緻度地阻斷特定惡意 IP 區段。

重點三：VPC Peering 的社交距離 — 拒絕「傳遞性」的對等連接

當企業規模擴大，需要在不同 VPC 之間建立連線時，VPC Peering (對等連接) 是常見的選擇。但必須記住：VPC Peering 不具備傳遞性 (Transitivity)。

假設你有三個 VPC：A、B、C。如果你建立了 A 與 B 的對等連接，以及 B 與 C 的對等連接，這並不代表 A 能夠透過 B 訪問 C。若 A 需要與 C 通訊，你必須手動建立 A 與 C 之間的對等連接。

此外，AWS 路由選擇遵循 最長前綴匹配 (Longest Prefix Match, LPM) 演算法。這意味著當路由表中存在多個匹配目標時，系統會優先選擇最精確（子網路遮罩最長）的路由。例如，若目的地是 10.0.0.77/32，系統會優先選擇針對該特定 IP 的路由，而非較大範圍的 10.0.0.0/16。

「架構師筆記」：建立對等連接還有一個硬性前提：CIDR 區塊不能重疊 (Overlap)。一旦兩個 VPC 的 IP 範圍發生重疊，它們將無法建立連線。在多帳號架構中，手動更新路由表並維持全局 IP 規劃的唯一性雖然繁瑣，卻是確保網路互通性的必要代價。

重點四：邊緣路由的禁區 — 消失的 Edge-to-Edge Routing

在進階架構設計中，常有一種誤解：認為可以透過一個「中心化 VPC」來當作所有流量的統一出口。然而，AWS 的路由設計嚴格遵循 "No Edge-to-Edge Routing" 原則。

這意味著，流量不能「跨過」一個邊緣設備再去存取另一個邊緣設備。以下是常見的無效配置場景：

• 集中式 NAT Gateway 失敗：VPC B 透過對等連接與 VPC A 相連，但 VPC B 無法 借道 VPC A 中的 NAT Gateway 來存取網際網路。
• 邊緣存取限制：VPC B 無法透過 VPC A 來存取 A 的 Internet Gateway (IGW)、VPN 連線 或 Direct Connect (DX)。
• 端點連線限制：VPC B 無法透過對等連接存取 VPC A 中的 S3 或 DynamoDB VPC Endpoint。

「架構師筆記」：這是新手最容易掉入的陷阱。許多人試圖構建 Hub-and-Spoke 架構，卻發現「Spoke VPC」無法使用「Hub VPC」的出口資源。如果你需要實現真正的集中化出入口管理（如 Centralized NAT），必須捨棄 VPC Peering，改為採用 Transit Gateway。

重點五：安全存取的進化 — 從堡壘機 (Bastion) 到 SSM 的典範轉移

如何安全地管理私有子網路 (Private Subnet) 中的實例，是架構設計的核心議題。

傳統做法是建立一台 堡壘機 (Bastion Host) 作為跳板。然而，這也帶來了額外的安全挑戰：你需要管理 SSH 密鑰、維護跳板機的作業系統補丁，並被迫將 SSH 端口 (Port 22) 暴露在公網中，增加了被暴力破解的風險。

現代化的最佳實踐是採用 AWS Systems Manager (SSM) Session Manager。

「這是一種更好的安全模型。」

透過在實例中安裝 SSM Agent，管理員可以直接透過 IAM 權限進行連線，而 無需開啟任何入站端口（包括 Port 22）。

「架構師筆記」：這種典範轉移 (Paradigm Shift) 極大地縮小了受攻擊面。它將原本依賴於網路層（防火牆規則）的安全性，轉化為依賴於身分識別層（IAM Policy）。這不僅提升了安全性，還能自動記錄所有指令操作日誌，滿足企業的稽核需求。

結語：構建更穩健的雲端思維

理解 VPC 的核心組件——從 CIDR 規劃、保留位址 的細節，到 無狀態性 的陷阱與 路由選擇邏輯——是掌握 AWS 的關鍵。這些規則雖然看似隱形且瑣碎，卻共同構建了雲端網路的流通與隔離邊界。

隨著 基礎設施即代碼 (IaC) 的普及，許多底層限制可能被自動化工具遮蔽。但在系統出錯或面臨大規模架構擴展時，深入理解這些「硬性」網路限制，正是區分雲端專家與一般IT的分水嶺。

最後留下一個啟發性的問題供大家討論：在自動化(包含AI)工具盛行的時代，深入理解這些「手動」的網路限制，對於一位架構師的價值究竟在哪裡？ 是為了在系統崩潰時能迅速定位問題，還是為了在設計之初就能避開代價昂貴的結構性錯誤？