📍 Region 和 AZ

AWS 在全球有多個 Region（區域，例如「東京」「新加坡」），每個 Region 底下又切成好幾個 Availability Zone（AZ，可用區）——AZ 是彼此獨立的實體機房，有各自的電力、空調、網路線路，實體上通常隔了好幾公里。

這個「各自獨立」是重點：同一個 Region 裡的 AZ，不會因為同一場停電、同一條網路線斷掉，就一起掛掉。把東西放兩個 AZ，其中一個出事，另一個大機率還活著。

VPC 是建在單一 Region 底下、橫跨該 Region 所有 AZ 的私有網路；但 Subnet 不行，一個 Subnet 建立時就固定綁在某一個 AZ，之後不能換。這就是為什麼下面一直看到「AZ-a」「AZ-b」——要做到「一個 AZ 掛了、另一個還能用」，就得在不同 AZ 各建一份 Subnet，不能只建一個 Subnet 就當作跨 AZ 了。

🗺️ VPC 的基本組成

📏 CIDR：表格裡 /16、/24 是什麼意思

上面表格裡的位址都寫成 10.0.0.0/16、10.0.0.0/24 這種格式，這種寫法叫 CIDR。/ 後面的數字是「網路前綴」用掉幾個位元，用掉越少，留給位址的位元就越多，範圍也越大。

• /8 留了 24 個位元給位址，超過 1600 萬個——地端資料中心常用這種大範圍網段
• /16 留了 16 個位元給位址，換算下來有六萬多個
• /24 只留 8 個位元，剛好 256 個——扣掉 AWS 保留的幾個，實際能用 251 個
• /32 完全不留位元，等於只指定「這一個」位址——常出現在防火牆規則裡，鎖定單一來源 IP

10.0.0.0/8     → 範圍是 10.0.0.0 ～ 10.255.255.255（後面三段都能變，範圍超大）
VPC：10.0.0.0/16   → 範圍是 10.0.0.0 ～ 10.0.255.255（第三、第四段都能用）
Subnet：10.0.1.0/24 → 範圍是 10.0.1.0 ～ 10.0.1.255（只有最後一段能變動）
203.0.113.5/32 → 範圍就是它自己，沒有別的位址

Route Table：目的地（Destination）對應出口（Target）：

Destination        Target
10.0.0.0/16         local
0.0.0.0/0           igw-0123456789abcdef0

/16 只鎖住前兩段（10.0），後面兩段任你用；/24 多鎖了第三段（10.0.1），只剩最後一段能變，範圍自然小很多。VPC 通常抓一個大範圍的 /16，subnet 再從裡面切出一塊一塊的 /24。

🔑 Public 還是 Private？AWS 沒有這個開關

有了上面這五個元件，實際在主控台裡把 VPC 建出來之後，下一步通常就是切 subnet。這時候會發現，建立 subnet 的時候，並沒有「設成 public」或「設成 private」的選項。AWS 判斷的依據只有一條：這個 subnet 掛的 route table，有沒有一條 0.0.0.0/0 → igw 的路由。

Route Table A（掛在 subnet-1）
0.0.0.0/0 → igw-xxxx        ← 有這條，subnet-1 就是 public

Route Table B（掛在 subnet-2）
0.0.0.0/0 → nat-xxxx        ← 沒有直達 IGW，subnet-2 就是 private

名字是人取的，路由才是真的。同一個 subnet，只要換掛另一張沒有 IGW 路由的 route table，它立刻從 public 變成 private——跟 subnet 本身的任何設定都無關。

🏗️ 兩個 AZ 的完整架構

把「路由決定 public/private」這條規則套進一個實際場景：兩個 AZ，各自一組 public/private subnet，畫出來大概長這樣。

Private 機器怎麼連到外面

以 AZ-a 的 App EC2 要更新套件為例，路徑分兩段查表：

1. App EC2 查自己的 route table：0.0.0.0/0 → nat-a，封包送到 NAT Gateway A。
2. NAT Gateway A 本身站在 public subnet，查的是 public subnet 的 route table：0.0.0.0/0 → igw，才真正離開 VPC。

所以 NAT Gateway 一定要放在 public subnet——它自己也得靠 IGW 才出得去，放進 private subnet 就是把出口放進一間沒有門的房間。回應封包會沿原路走回來，NAT Gateway 會記得是哪一台機器發出的請求。

外部連進來

如果是外部要主動連進某一台機器，要成立的條件不一樣：

• subnet 掛的 route table 有 0.0.0.0/0 → igw
• 機器本身有 public IPv4（自動配發，或掛 Elastic IP）

少一個都連不上。這也是為什麼「機器在 public subnet 裡」不等於「一定能被外部連到」——它可能只滿足了第一個條件。

為什麼要兩個 NAT Gateway？

NAT Gateway 是 AZ 級的資源。如果 AZ-b 的 private subnet 指去 AZ-a 的 NAT Gateway，AZ-a 一旦故障，AZ-b 的機器明明還活著，卻整批斷網。要讓 AZ 真正互相獨立，就要一個 AZ 配一個 NAT Gateway，各自的 route table 指向同 AZ 的那一個——多一份 NAT Gateway 的錢，換的是高可用。

📌 補充

✅ 小結

摘要：public/private 是 route table 決定的，不是 subnet 本身的設定；NAT Gateway 要放在 public subnet，因為它自己也得靠 IGW 才出得去；AZ 要真的互相獨立，每個 AZ 就得有自己的 NAT Gateway，不能共用。

下一篇為 Security Group：路通了之後，哪些封包可以進。

🧠 AI 出題

問題 1

某公司在一個 VPC 中建立了 public subnet 與 private subnet，並在 VPC 上掛好 Internet Gateway。一位工程師為 private subnet 裡的應用程式伺服器建立了一個 NAT Gateway，也把 private subnet 的 route table 加上 0.0.0.0/0 指向該 NAT Gateway，但伺服器仍然無法下載套件更新。檢查後發現 NAT Gateway 被建立在 private subnet 裡。Security Group 與 NACL 都已確認允許相關流量。

解決方案架構師應該怎麼做，才能在不讓應用程式伺服器暴露於網際網路的前提下恢復連外？

• A. 在 private subnet 的 route table 再加一條 0.0.0.0/0 指向 Internet Gateway，讓流量能直接經由 IGW 離開
• B. 為現有的 NAT Gateway 額外關聯第二個 Elastic IP，並將 private subnet 的路由重新指向它
• C. 在 public subnet 重新建立 NAT Gateway 並關聯 Elastic IP，再把 private subnet 的 route table 中 0.0.0.0/0 改指向新的 NAT Gateway
• D. 在 private subnet 的 NACL 加入允許所有 outbound 流量到 0.0.0.0/0 的規則，讓 NAT Gateway 的回應可以通過

問題 2

某公司在三個 Availability Zone 的 private subnet 中運行資料處理叢集，每天透過 NAT Gateway 對同一 Region 的 Amazon S3 讀寫數 TB 的資料。財務部門發現每月網路費用中，NAT Gateway 的資料處理費占了大宗。應用程式伺服器依規定不得取得 public IP，也不能中斷現有的資料流程。

在最符合成本效益（MOST cost-effective）的前提下，解決方案架構師應該建議哪一個做法？

• A. 建立 Amazon S3 的 Gateway VPC endpoint，並在三個 private subnet 的 route table 加入指向該 endpoint 的 S3 prefix list 路由
• B. 將三個 AZ 各自的 NAT Gateway 合併為單一 NAT Gateway，並把所有 private subnet 的 route table 都指向它
• C. 以自行管理的 NAT Instance 取代三個 NAT Gateway，並關閉 instance 的 source/destination check
• D. 為應用程式伺服器配置 Elastic IP，並在 private subnet 的 route table 加入 0.0.0.0/0 指向 Internet Gateway 的路由

問題 3

某公司要在 AWS 建立第一個正式環境的 VPC，規劃在三個 Availability Zone 各放一個 public subnet 與一個 private subnet，並預留至少 200 台 EC2 instance 的成長空間。公司的地端資料中心使用 10.0.0.0/8 與 192.168.0.0/16 兩個網段，半年內會透過 AWS Site-to-Site VPN 與這個 VPC 互連。

哪一個 VPC CIDR 區塊最符合這些需求？

• A. 10.20.0.0/16，並將每個 subnet 切成 /24
• B. 172.16.0.0/16，並將每個 subnet 切成 /24
• C. 192.168.100.0/24，並將每個 subnet 切成 /27
• D. 172.16.0.0/28，並將每個 subnet 切成 /29

問題 4

某公司的應用程式部署在兩個 Availability Zone（AZ-a 與 AZ-b）的 private subnet 中，目前只在 AZ-a 的 public subnet 有一個 NAT Gateway，兩個 AZ 的 private subnet 都共用同一張 route table 指向它。上週 AZ-a 發生服務中斷，AZ-b 的應用程式明明正常運作，卻因為無法連外而整批失敗。公司要求未來任何單一 AZ 故障都不能影響另一個 AZ 的連外能力，且應用程式伺服器仍不得暴露於網際網路。

解決方案架構師應該怎麼做？

• A. 將 AZ-b private subnet 的 route table 中 0.0.0.0/0 改為指向 Internet Gateway，作為 AZ-a NAT Gateway 故障時的備援路徑
• B. 為現有的 NAT Gateway 關聯第二個 Elastic IP，讓它同時服務兩個 AZ 的流量
• C. 以部署在兩個 AZ、由 Auto Scaling group 管理的 NAT Instance 取代 NAT Gateway，並設定健康檢查自動替換故障的 instance
• D. 在 AZ-b 的 public subnet 另外建立一個 NAT Gateway，為兩個 AZ 的 private subnet 各建立獨立的 route table，分別指向同 AZ 的 NAT Gateway

問題 5

某公司在既有的 VPC 中新增了一個 subnet，準備放置一台需要從辦公室網路直接 SSH 連入的 bastion host。VPC 已掛有 Internet Gateway，但新 subnet 目前關聯的是一張只有 local 路由的自訂 route table，subnet 的自動配發 public IPv4 設定也是關閉的。Bastion host 啟動後，工程師從辦公室完全無法連線。

在不新增額外網路元件、且變更最少（minimal changes）的前提下，要讓這台 bastion host 可以從網際網路連入，解決方案架構師應該採取哪兩項做法？（選擇兩項）

• A. 在該 subnet 關聯的 route table 中加入 0.0.0.0/0 指向 Internet Gateway 的路由
• B. 在該 subnet 建立一個 NAT Gateway，並將 route table 的 0.0.0.0/0 指向它
• C. 將該 subnet 改為關聯 VPC 的 main route table，讓它繼承預設的對外路由
• D. 為 bastion host 關聯一個 Elastic IP，或啟用該 subnet 的自動配發 public IPv4
• E. 在該 subnet 的 NACL 加入允許 0.0.0.0/0 inbound 的規則，取代預設的規則

💡 解答

1. C

NAT Gateway 自己也要靠 Internet Gateway 才出得去，所以它必須放在有 0.0.0.0/0 → IGW 路由的 public subnet；放在 private subnet 等於出口本身沒有出口。重建在 public subnet 並把 private route table 指向新的 NAT Gateway，private subnet 裡的伺服器仍然沒有直達 IGW 的路，不會暴露。

A 會讓 private subnet 變成 public subnet（有了通往 IGW 的路），而且沒有 public IP 的伺服器也走不出去，同時違反「不暴露」的要求。B 是誤解：Elastic IP 的數量與 NAT Gateway 所在 subnet 有沒有對外路由無關。D 解的是別的問題：NACL 預設允許所有流量，題目也已確認 NACL 沒問題。

2. A

S3 的 Gateway VPC endpoint 讓 private subnet 的流量透過 route table 的 prefix list 直接走 AWS 內部網路到 S3，不經過 NAT Gateway，也就沒有每 GB 的資料處理費，而且 endpoint 本身免費、伺服器仍然沒有 public IP。

B 減少的是 NAT Gateway 的小時費，但每 GB 處理費一毛不少，還多了跨 AZ 流量費與單點故障。C 技術上可行、也省掉 NAT Gateway 的處理費，但要自己管 patch、擴容與高可用，在「最符合成本效益」與維運上都輸給免費且免管理的 endpoint。D 違反「不得取得 public IP」，而且會把 private subnet 變成 public。

3. B

VPC 要與地端互連，CIDR 不能重疊：10.20.0.0/16 落在地端的 10.0.0.0/8 裡，192.168.100.0/24 落在 192.168.0.0/16 裡，兩者未來建 VPN 時路由會衝突。172.16.0.0/28 沒有重疊，但整個 VPC 只有 16 個位址，而 AWS 的 subnet 最小就是 /28，根本切不出六個 subnet（/29 不是合法的 subnet 大小），更別說 200 台成長空間。

172.16.0.0/16 不與地端重疊，切成六個 /24 每個有 251 個可用位址，綽綽有餘。

4. D

NAT Gateway 是 AZ 級資源，AZ 獨立的設計就是每個 AZ 各一個 NAT Gateway，各 AZ 的 private subnet 用自己的 route table 指向同 AZ 的那一個；這樣任一 AZ 故障，另一個 AZ 的出口不受影響。

A 把 AZ-b 的 private subnet 變成 public，違反「不得暴露」，而且沒有 public IP 的伺服器也走不了 IGW。B 是誤解：多一個 Elastic IP 不會讓 NAT Gateway 跨 AZ。C 技術上可行，但要自己維護 NAT Instance 的 AMI、patch、頻寬與 failover 邏輯，是用更多維運換取 NAT Gateway 原本就提供的可靠性，屬於過度設計。

5. A、D

一台機器要能從網際網路連入，兩個條件缺一不可：所在 subnet 的 route table 有通往 IGW 的路（A），以及機器本身有 public IPv4（D）。少任何一個都連不上。

B 方向錯了：NAT Gateway 是讓裡面出去，不是讓外面進來。C 是誤解：main route table 並不天生有對外路由，它的內容也是自己設的，題目沒說 main route table 有 IGW 路由。E 解的是別的問題：預設 NACL 本來就允許所有流量，換掉它不會讓沒有路由、沒有 public IP 的機器變得可連。