AWS VPC 入門（上）：單一 VPC 路由、防火牆與帳單

建置雲端基礎架構時，VPC（Virtual Private Cloud）常被當作理所當然的背景設定：拉幾張子網路、掛個 NAT Gateway、設定幾條安全群組規則，系統就能運作。直到遇上「封包連不到」或「月底帳單暴增」，才發現路由、防火牆與 DNS 的設定彼此牽動，很難從單一環節找出問題。

VPC 內繁雜的元件看似零散，本質上其實只在回答三個核心問題：

1. 位址：資源的 IP 是什麼、從哪段空間切分出來？（VPC CIDR、Subnet）
2. 路徑：封包該往哪裡送？（Route Table、Internet Gateway、NAT Gateway、VPC Endpoint）
3. 許可：封包是否允許通過？（Security Group、Network ACL）

橫跨這三個問題的，還有兩條隱形支線：名稱（DNS 解析決定封包走哪條路）與帳單（每條路徑的資料傳輸定價）。本文作為系列上篇，將徹底拆解單一 VPC 的運作邏輯，建立清晰的心智模型與故障排除體系。

 +----------------------------------------------------+
 |                   Single AWS VPC                   |
 |                                                    |
 | +------------------------------------------------+ |
 | | Address: CIDR & Subnets (AZ-a / AZ-b)          | |
 | +------------------------------------------------+ |
 |                         |                          |
 |                         v                          |
 | +------------------------------------------------+ |
 | | DNS: Route 53 Resolver (Base + 2)              | |
 | +------------------------------------------------+ |
 |                         |                          |
 |                         v                          |
 | +------------------------------------------------+ |
 | | Routing: Route Table (LPM) -> IGW / NAT / VPCE | |
 | +------------------------------------------------+ |
 |                         |                          |
 |                         v                          |
 | +------------------------------------------------+ |
 | | Permission: Security Groups & Network ACLs     | |
 | +------------------------------------------------+ |
 |                         |                          |
 |                         v                          |
 | +------------------------------------------------+ |
 | | Billing: Data Transfer & Gateway Costs         | |
 | +------------------------------------------------+ |
 |                                                    |
 +----------------------------------------------------+

一、位址規劃：VPC、CIDR、Subnet 與 AZ

VPC 與 Subnet 的層級邊界

VPC 是區域級（Region）的私有虛擬網路，建立時必須指定主要的 IPv4 CIDR 區段（例如 10.0.0.0/16）。Subnet 則是從 VPC CIDR 劃分出的子網段。每個 Subnet 只能存在於單一可用區（AZ）。

AZ 是彼此獨立供電、網路各自獨立的機房群，單一 AZ 故障不會波及其他 AZ。由於 Subnet 綁定單一 AZ，同一個 Subnet 內的資源也就與該 AZ 同生共死。

因此，跨 AZ 高可用在網路層的前提，是在每個目標 AZ 各建一組功能對應的 Subnet（Public、App、DB 各一），ALB、Auto Scaling Group 與 RDS Multi-AZ 才能把副本分散到不同 AZ。只切 Subnet 而不放備援資源，仍然不算高可用。

 VPC: 10.0.0.0/16 (Region-level)
 +-- AZ-a
 |   +-- Public Subnet:  10.0.0.0/24
 |   +-- App Subnet:     10.0.32.0/19
 |   +-- DB Subnet:      10.0.128.0/24
 +-- AZ-b
     +-- Public Subnet:  10.0.1.0/24
     +-- App Subnet:     10.0.64.0/19
     +-- DB Subnet:      10.0.129.0/24

AWS 規定單一 Subnet 的遮罩範圍介於 /28 至 /16 之間（詳見 Subnet CIDR blocks）。斜線後的數字代表前幾個位元固定為網段，剩下的位元才能分給主機：IPv4 位址共 32 位元，/24 留下 8 位元，即 2⁸ = 256 個位址；/28 只留 4 位元，即 2⁴ = 16 個。

值得注意的是，每個 Subnet 固定保留 5 個 IP：前 4 個與最後 1 個。以 10.0.0.0/24 為例，分別是 .0 網路位址、.1 VPC Router、.2 DNS、.3 保留供未來使用，以及 .255 廣播位址。扣掉這 5 個，/24 實際可用 256 − 5 = 251 個，/28 則只剩 16 − 5 = 11 個。

此外，VPC 內所有具備 IP 的實體（EC2、RDS、Lambda 網卡、Interface Endpoint 等），底層皆為 ENI（Elastic Network Interface）。IP 與安全群組皆綁定於 ENI 上，而非虛擬機器本體。

為什麼位址規劃必須一次到位

在雲端環境中，多數資源設定皆可事後調整，唯獨子網路位址極難變更：Subnet 建立後無法動態擴容，已運作的工作負載更無法無縫更換 IP。

前期規劃不當會帶來三大痛點：

• CIDR 重疊衝突：VPC Peering 明確禁止兩個 CIDR 重疊的 VPC 對接；與企業地端機房、VPN 或 Kubernetes Pod 網路互通時，重疊位址會讓路由無法分辨同一段位址該送往本地端還是遠端，封包就到不了目的地。
• 擴充彈性受限：雖然 VPC 支援事後新增 Secondary CIDR，但這屬於補救措施，無法擴大既有的擁擠 Subnet。
• IP 消耗速度超乎預期：EC2 單機僅占 1 個私有 IP，但 VPC 模式的 Lambda、ECS awsvpc、EKS Pod、Interface Endpoint 與 ALB 節點都會直接吃掉 Subnet IP（特別是 EKS 容器環境，詳見第七節）。

實務建議的初始設定原則為：VPC 至少給予 /16；放置容器等密集計算資源的 Private Subnet 切割 /19 或 /20；僅放置負載平衡器與 NAT 的 Public Subnet 則切 /24 即可。

IPv6 與 Public IPv4 成本考量

自 2024 年 2 月起，AWS 對所有 Public IPv4 位址全面計費（包含使用中的分配位址），us-east-1 費率為每小時 $0.005（單個 IP 每月約 $3.6），詳見 VPC 定價頁。這使過去「每台機器掛 Public IP」的架構產生實質營運成本。

引入 IPv6 是兼顧連線與成本的解法。VPC 可啟用 Dual-stack 模式分配全球可路由的 IPv6 位址。

針對 IPv6 的「只出不進」需求，改由 Egress-only Internet Gateway 負責：它只允許由內向外建立連線，本身不做 NAT。IPv6 位址數量充裕，每個實例都能分到全球唯一的位址，直接以自己的位址對外通訊，不必像 IPv4 那樣轉換。

二、路由機制：Route Table、IGW 與 NAT Gateway

Route Table 比對原則：最長前綴匹配

每個 Subnet 必須關聯一張 Route Table。表中必定存在一條由系統維護的 local 路由（例如 10.0.0.0/16 → local），確保 VPC 內所有 Subnet 彼此互通。

當封包目的地同時符合多條路由規則時，VPC Router 依循 Longest Prefix Match（最長前綴匹配） 原則轉發。「前綴」就是 CIDR 斜線後的數字，數字越大，涵蓋的範圍越小、越精確；路由器會挑範圍最精確的那條規則。

因此，10.0.0.0/16 → local 永遠優先於 0.0.0.0/0 → nat-xxx；針對特定服務的 Prefix List 路由也會優先於預設網際網路出口。

 Packet Destination: 10.0.32.15
 +-- Rule 1: 0.0.0.0/0       -> nat-0123456789abcdef0
     (Prefix /0)
 +-- Rule 2: 10.0.0.0/16     -> local
     (Prefix /16, Matches & Wins ✅)

 Packet Destination: 52.216.0.1 (AWS S3 IP in us-east-1)
 +-- Rule 1: 0.0.0.0/0       -> nat-0123456789abcdef0
     (Prefix /0)
 +-- Rule 2: pl-63a5400a     -> vpce-0123456789abcdef
     (Contains 52.216.0.0/15, Matches & Wins ✅)

Internet Gateway

Internet Gateway（IGW）是 VPC 與網際網路間的完全託管閘道，具備**水平擴充與高可用**特性，無頻寬瓶頸與單點故障問題。

IGW 扮演兩個角色：

1. 作為 Route Table 中網際網路流量的出口目標。
2. 在 EC2 的私有 IP 與其對應的 Public IPv4 間執行一對一網路位址轉換（1:1 NAT）。實例的作業系統內部永遠只看得到私有 IP，外部轉換全由 IGW 處理。

「Public Subnet」本質上是一條路由

Subnet 本身並無內建的「公有」屬性開關。決定一個 Subnet 是否為 Public 的唯一條件，是其關聯的 Route Table 是否包含導向 Internet Gateway 的預設路由（0.0.0.0/0 → igw-xxx）。

Subnet 設定中的「自動指派公有 IPv4」，僅決定新啟動的實例（Instance）是否獲配 Public IP；若具備 Public IP 但所屬路由表缺乏 IGW 條目，對外連線依然無法建立。

未手動關聯 Route Table 的 Subnet，會自動繼承 VPC 的 Main Route Table。若有人誤在 Main Route Table 加入 IGW 路由，後續所有未明確關聯的 Subnet 都會默默暴露為 Public。

標準安全作法是保持 Main Route Table 僅有預設 local 路由，其餘 Subnet 一律明確綁定自訂 Route Table。

NAT Gateway：Zonal vs Regional

Private Subnet 內的應用程式經常需要單向存取外網（如拉取套件或呼叫外部 API），同時禁止外部連線直接打入。NAT Gateway 透過多對一的 SNAT 機制實現此需求。

傳統 NAT Gateway 為 Zonal（可用區級） 架構，必須部署在特定 AZ 的 Public Subnet 並綁定 Elastic IP。這衍生經典的架構取捨：

2025 年 11 月，AWS 正式推出 Regional NAT Gateway，大幅緩解了這個架構痛點：

• VPC 級代管資源：由 AWS 於 VPC 基礎設施層代管出網路由，無須在使用者 VPC 內建立 Public Subnet 放置 NAT，所有 Private Subnet 直接指向統一的 Regional NAT ID。
• 緩解 SNAT 連線耗盡：TCP 連線由四元組（來源 IP、來源 Port、目的 IP、目的 Port）唯一定義，來源 Port 數量有限，因此 NAT 的每個 IP 對同一目的地僅能支撐約 55,000 條並行連線，高並行情境便會耗盡。Zonal NAT 最多可綁定 8 個 IP（預設 2 個，需申請提高配額），Regional NAT 則是每個 AZ 最多 32 個，出口並行上限因此再拉高 4 倍。

Regional NAT 的小時費率與 Zonal 相同（每個 AZ 每小時 $0.045），其價值在於消除 Public Subnet 的設定風險並簡化維運。需注意：新 AZ 擴充需約 60 分鐘暖機時間，且目前尚不支援 Private NAT 情境。

三、存取許可：Security Group 與 Network ACL

設計理念與機制對比

Security Group（安全群組）與 Network ACL（網路存取控制清單）共同構成 VPC 的防禦縱深，兩者在運作層級與狀態管理上有本質差異：

Stateless 的代價：Ephemeral Ports

由於 NACL 具備無狀態（Stateless）特性，若在 inbound 開放 TCP 443，當外部客戶端由隨機高位連接埠（如 52311）連入時，進站封包可順利通過；但伺服器回傳給 52311 的回應封包，若 outbound 未開放對應範圍，回應將在 Subnet 邊界被直接丟棄。

因此，使用自訂 NACL 時，outbound 必須顯式開放 Ephemeral Ports（臨時連接埠，實務常開 1024–65535）。

SG 參照 SG：解耦 IP 的多層架構

在多層式 Web 架構中，SG 規則的來源不應綁死 CIDR，而應直接填入來源端 SG ID。

 [sg-alb]  Inbound: 443 from 0.0.0.0/0
    |
    v (HTTP 8080)
 [sg-app]  Inbound: 8080 from sg-alb
    |
    v (PostgreSQL 5432)
 [sg-db]   Inbound: 5432 from sg-app

此寫法的優勢在於：無論 Auto Scaling 新增多少 App 實例，只要掛載 sg-app，便自動取得連線 DB 的權限；且外部流量完全無法繞過 ALB 直連後端服務。

何時需要介入自訂 NACL

絕大多數情境下，維持 NACL 預設全開、以 SG 作為主要防線即可。只有以下兩種情境值得額外設定 NACL：

1. 緊急封鎖特定來源：SG 只能設定 Allow，若要擋下特定惡意 IP 或 CIDR，可在 NACL 加一條編號較小的 Deny 規則，使其優先生效。不過 NACL 每個方向預設僅 20 條規則，封鎖名單一長就不敷使用；流量經由 ALB 或 CloudFront 進入時，AWS WAF 的 IP 封鎖清單通常是更合適的選擇。
2. 防禦縱深與分權管理：在 DB Subnet 邊界只放行 App Subnet 網段，即使有人誤將 sg-db 開放為 0.0.0.0/0，Subnet 層仍能擋下外部流量。部分合規稽核也要求這道與 SG 分開管理的第二防線。代價是必須同步維護雙向規則與 Ephemeral Ports。

四、不出網存取 AWS 服務：VPC Endpoint

當 Private Subnet 內的應用程式需要呼叫 S3、DynamoDB、SQS 或 ECR 等託管服務時，預設會經由 NAT Gateway 連向服務的公開端點。這段流量其實不會離開 AWS 網路：依 VPC FAQ，AWS 內部往公開服務端點的封包都留在 AWS 全球骨幹上。

真正的代價有二：每 GB 都要付 NAT 資料處理費，而且 Subnet 必須具備出網路徑才能使用這些服務。

VPC Endpoint 讓流量不經 NAT、直接抵達服務，同時解決這兩個問題。它分為兩種，運作原理截然不同：Gateway Endpoint 在路由表加一條路由，把往特定服務的流量攔截下來；Interface Endpoint 則在 Subnet 內放一張網卡，讓服務在 VPC 內擁有私有 IP，其底層技術稱為 PrivateLink。

S3 Gateway Endpoint 的攔截機制

S3 沒有 VPC 內部私有 IP。應用程式呼叫 S3 時，DNS 依然解析為公開 IP（例如 52.216.x.x）。

之所以能透明繞過 NAT，全靠路由表的最長前綴匹配（LPM）：AWS 在路由表中自動加入一條以 S3 Prefix List 為目的地的路由（ID 依區域而異，格式為 pl-xxxxxxxx），這份清單收錄該區域 S3 使用的多段 CIDR（例如 52.216.0.0/15）。

這些網段都比預設路由 0.0.0.0/0 更精確，出站封包因此直接被轉入 Gateway Endpoint，完全不需要修改 SDK 或 DNS。

Interface Endpoint 的接管機制：Private DNS

Interface Endpoint 靠 Private DNS 接管流量。啟用後，VPC 內的 DNS 會把 sqs.us-east-1.amazonaws.com 這類服務網址直接解析成該 Endpoint 的私有 IP，應用程式與 SDK 無須修改任何 Endpoint URL，流量就會自動改走 PrivateLink。前提是 VPC 的兩項 DNS 屬性都已開啟（見第五節）。

選型準則與成本試算

• S3 與 DynamoDB 務必直接啟用 Gateway Endpoint：完全免費且無設定負擔，應作為標準基礎設定。
• Interface Endpoint 需精算規模成本：若為單一服務啟用 3 個 AZ 的 Interface Endpoint，每月基本固定費用如下（詳見 PrivateLink 定價）：

$\$0.01 \times 730 \times 3 \approx \$21.9$

若同時開啟 10 個服務的 PrivateLink，每月光是固定費用就達 $219。只有在資料傳輸量極大（走 NAT 費用遠高於 $21.9）或資安要求「網路環境絕對零出口」時，才建議大量導入 Interface Endpoint。

五、VPC 內的 DNS 架構與陷阱

Route 53 Resolver（AmazonProvidedDNS）

每個 VPC 皆內建專屬 DNS 解析器（Route 53 Resolver），其 IPv4 位址固定為 VPC 主要 CIDR 的起始位址再加 2（例如 10.0.0.0/16 的 DNS 即為 10.0.0.2），亦可透過全域 Link-local 位址 169.254.169.253 存取。這也是 Subnet 保留 .2 位址的核心原因。

關鍵屬性設定與常見陷阱

VPC 具備兩項控制 DNS 行為的關鍵屬性：

另一個陷阱是自訂 DHCP Option Set：若把 DNS 伺服器改指向自建 DNS，實例就不再查詢 AmazonProvidedDNS，除非自建 DNS 轉發回 10.0.0.2，否則 Private Hosted Zone 與 Endpoint 的私有紀錄都查不到。

此外需注意：往 10.0.0.2 的 DNS 查詢流量不會被 SG 或 NACL 阻擋。

不過，存取 Link-local 位址服務（Route 53 Resolver DNS、IMDS、NTP 等）的流量有 1024 PPS（Packets Per Second） 的聚合配額上限，且無法調高；抵達配額時 Resolver 會直接拒絕流量，高並行短連線環境便可能出現 DNS 查詢逾時（i/o timeout），建議在節點層建置本機 DNS 快取（如 NodeLocal DNSCache）。

六、網路帳單：流量與成本結構拆解

以下為 us-east-1 的主要網路傳輸與閘道費率（基準日期 2026-09）：

實戰計費案例：S3 10 TB 存取的路徑對比

假設某 Private Subnet 內的批次運算叢集每月需自 S3 讀取 10 TB 資料，不同架構路徑的費用差異極大：

• 路徑 A（經由 NAT Gateway 出網）： $10{,}240\text{ GB} \times \$0.045\text{ (處理費)} + \$32.85\text{ (NAT 月租)} = \mathbf{\$493.65}$
• 路徑 B（誤開 3 AZ 的 S3 Interface Endpoint / PrivateLink）： $10{,}240\text{ GB} \times \$0.01\text{ (傳輸費)} + \$21.90\text{ (VPCE 月租)} = \mathbf{\$124.30}$
• 路徑 C（正確設定 S3 Gateway Endpoint）： $\mathbf{\$0.00}$

單一架構決策每月費用相差將近 500 美元。

七、進階專題：EKS 與 VPC CNI 的 IP 耗盡陷阱

VPC-Native CNI 的架構代價

AWS EKS 預設採用 AWS VPC CNI 外掛。其設計哲學為 VPC-Native：每個 Kubernetes Pod 皆直接獲配 VPC CIDR 內的真實私有 IP。

好處是 Pod 享有 VPC 內的一等公民地位，無須經由 Overlay 封裝，可直接套用 SG、Flow Logs 與 Direct Connect 路由；代價則是 Pod 的增長會急遽消耗 Subnet 的 IP 位址池。

在預設 Secondary IP 模式下，每個 EC2 機型能掛載的 ENI 數量與每張 ENI 能分配的 IPv4 數量存在硬體上限（例如 m5.large 最多掛 3 張 ENI、每張 10 個 IP；每張 ENI 有 1 個主 IP 保留給節點自身，Pod 實際可用 3 × 9 = 27 個，再加上 VPC CNI 與 kube-proxy 兩個不占用 IP 的系統元件，依 max pods 公式單節點上限為 29 個 Pod）。

更關鍵的是 Warm Pool 預熱機制：CNI 為了讓 Pod 啟動得快，會預先替節點多保留一些 IP，即使 Pod 還沒建立，這些 IP 也已經從 Subnet 預先扣走。

IP 耗盡症狀

當叢集節點擴充至一定數量，Subnet 容量見底時，將出現典型症狀：

• 新 Pod 永久卡在 ContainerCreating 狀態。
• 執行 kubectl describe pod 顯示 FailedCreatePodSandBox: no IP addresses available in network。
• 節點仍有充足 CPU 與記憶體，但無法排程任何新工作。

一個 /24 Subnet（僅 251 個可用 IP）在數十個節點加上 Warm Pool 預扣下，可能在數分鐘內消耗殆盡。

三大緩解機制與選型建議

實務上的選擇順序：

1. 新叢集若周邊相依都支援 IPv6，直接建立 IPv6 叢集最一勞永逸，但 IP 家族只能在建立叢集時決定，事後無法切換。
2. 仍需 IPv4 的叢集，先啟用 Prefix Delegation，並以 Subnet CIDR Reservation 預留連續區塊，避免空間破碎。
3. 只有在主 CIDR 已無空間、或企業可路由 IP 受限時，才動用 Secondary CIDR ＋ Custom Networking。

八、觀測與故障排除工具：Flow Logs 與 Reachability Analyzer

查修 VPC 網路問題時，AWS 提供兩大觀測工具，分別代表「實際流量」與「靜態路徑」：

• VPC Flow Logs（實際流量觀測）：捕捉 ENI、Subnet 或 VPC 層級的 IP 流量中繼資料（含來源/目的 IP、Port、Protocol、傳輸量與 ACCEPT/REJECT 狀態），但不包含封包酬載。若看到 REJECT 代表被 SG 或 NACL 阻擋；若目的端毫無紀錄，代表封包根本沒抵達，問題通常出在 DNS 解析或路由。
• Reachability Analyzer（靜態路徑模擬）：純設定分析工具。指定來源與目的端後，系統自動模擬走訪 Route Table、SG、NACL、IGW 等組態，分析封包是否可達並精確標註阻斷點。分析過程不發送實體網路封包，每次分析收費 $0.10。

九、實戰整合：三層式架構完整封包追蹤與故障排除

架構規格定義

設定雙可用區的 VPC（10.0.0.0/16）：

 +--------------------------------------------+
 | VPC: 10.0.0.0/16                           |
 |                                            |
 | [ Public Tier ]                            |
 | AZ-a: 10.0.0.0/24 | AZ-b: 10.0.1.0/24      |
 | Routes: local + 0.0.0.0/0 -> IGW           |
 | SG (sg-alb): Inbound 443 from 0.0.0.0/0    |
 |                                            |
 | [ App Tier ]                               |
 | AZ-a: 10.0.32.0/19 | AZ-b: 10.0.64.0/19    |
 | Routes: local + 0.0.0.0/0 -> Regional NAT  |
 |         + S3 Prefix -> Gateway Endpoint    |
 | SG (sg-app): Inbound 8080 from sg-alb      |
 |                                            |
 | [ DB Tier ]                                |
 | AZ-a: 10.0.128.0/24 | AZ-b: 10.0.129.0/24  |
 | Routes: local only                         |
 | SG (sg-db): Inbound 5432 from sg-app       |
 +--------------------------------------------+

封包逐跳（Hop-by-Hop）流程拆解

 User (Internet)
   | (1) DNS lookup -> ALB Public IP
   v
 [ IGW ] -> 1:1 NAT -> Public Subnet (sg-alb allows 443)
   |
   | (2) Local Route
   |     -> App Subnet (sg-app allows 8080 from sg-alb)
   v
 [ App Instance ]
   +-- (3) Local Route
   |     -> RDS Private IP (sg-db allows 5432 from sg-app)
   +-- (4) S3 Prefix List Route
   |     -> S3 Gateway Endpoint (Bypasses NAT, $0)
   +-- (5) Default Route (0.0.0.0/0)
         -> Regional NAT -> IGW -> External API

1. 第一跳（客戶端 → ALB）：使用者查詢 DNS 獲取 ALB 公開 IP，封包抵達 IGW 轉換為 ALB 節點私有 IP，進入 Public Subnet，sg-alb 放行 443 請求。
2. 第二跳（ALB → App）：ALB 節點以私有 IP 為來源連向 App 實例私有 IP，比對 VPC 內部 local 路由。sg-app 確認來源掛載 sg-alb，放行 8080。
3. 第三跳（App → RDS）：App 向內建 DNS（10.0.0.2）解析 RDS 網址取得 DB 私有 IP，走 local 路由抵達 DB Subnet，sg-db 放行 5432。若 App 與 RDS 分處不同 AZ，此段就會產生跨 AZ 傳輸費。
4. 第四跳（App → S3）：App 解析 S3 公有網址，Route Table 命中 S3 Prefix List 具體路由，封包直接注入 S3 Gateway Endpoint，不經 NAT、不計傳輸費。
5. 第五跳（App → 外部 API）：目的地為網際網路 IP，命中 0.0.0.0/0 路由轉發至 Regional NAT Gateway，SNAT 為公有出口 IP 後經 IGW 送出。

常見症狀診斷速查表

結語與下篇預告

掌握單一 VPC 的精髓，在於建立收斂的心智模型：由 CIDR 與 Subnet 劃定空間、Route Table 決定路徑、Security Group 與 NACL 執行過濾、DNS 導引方向，而每條路徑直接決定了帳單結構。

故障排除時依「名稱 → 路徑 → 許可」循序定位，搭配 Flow Logs 與 Reachability Analyzer，絕大多數單一網路拓撲的疑難雜症皆能迎刃而解。

然而，單一 VPC 僅是起點。跨入多帳號、多 VPC 互聯與地端混合雲後，VPC Peering、Transit Gateway、Direct Connect 與 Route 53 Resolver Endpoints 將陸續登場，這些留待下篇展開。