大家好，今天我們來聊一個在 AWS 云計算世界里既基礎又關鍵的話題：VPC 路由表。

很多剛接觸 AWS 的朋友，在配置網絡時可能會遇到這樣的困惑：為什么我的 EC2 實例無法訪問互聯網？為什么某些子網的網絡策略和其他子網不一樣？這些問題的答案，往往就藏在 VPC 的路由表（Route Table）中。特別是當我們看到“Explicit subnet associations”（顯式子網關聯）和“Subnets without explicit associations”（未顯式關聯的子網）這兩個選項時，可能會感到一絲迷茫。

別擔心，本文將通過通俗易懂的語言和具體示例，為大家徹底講清楚它們的區別，以及這如何影響我們的云上應用訪問互聯網。

什么是路由表？網絡世界的交通指揮官

在深入探討之前，我們先快速回顧一下路由表的作用。

我們可以把 VPC 路由表想象成一個網絡十字路口的交通指揮官。它包含一系列名為“路由”（Routes）的規則，這些規則告訴從子網（Subnet）發出的網絡流量應該去往何方。例如，一條規則可能會說：“所有去往互聯網（目標地址 0.0.0.0/0）的流量，都請走向互聯網網關（Internet Gateway）。”

每個 VPC 在創建時都會自動生成一個主路由表（Main Route Table）。這個主路由表是我們 VPC 的默認指揮官。

顯式子網關聯 (Explicit Subnet Associations): 精準的“指定委派”

“顯式子網關聯”非常直觀，它意味著我們手動、明確地將一個或多個子網與一個特定的路由表綁定。

打個比方：
想象一下我們管理一個大型物流車隊。對于運送貴重物品的卡車（重要應用所在的子網），我們會為它們指定一位經驗最豐富的調度員（一個定制的路由表），并明確告訴它們：“你們必須聽從這位調度員的指揮。” 這種一對一的指定關系，就是顯式關聯。

實際應用場景：
這是 AWS 網絡配置的最佳實踐。通常，我們會創建至少兩類路由表：

1. 公共路由表 (Public Route Table): 包含一條指向互聯網網關的路由（0.0.0.0/0 -> igw-xxxx）。
2. 私有路由表 (Private Route Table): 不包含指向互聯網網關的路由，或者指向一個 NAT 網關（0.0.0.0/0 -> nat-xxxx）。

然后，我們將需要直接對外提供服務的子網（如 Web 服務器所在的子網）顯式關聯到公共路由表。將需要訪問互聯網但又不想被外界直接訪問的子網（如數據庫、應用后端所在的子網）顯式關聯到私有路由表。

這種做法讓網絡架構清晰、可控，且安全性更高。

未顯式關聯的子網 (Subnets without explicit associations): “默認的管轄”

這個概念是理解主路由表（Main Route Table）的關鍵。它指的是那些沒有被我們手動關聯到任何路由表的子網。

AWS 的規則是： 如果一個子網沒有被顯式關聯到任何路由表，那么它將自動、隱式地被主路由表接管。

繼續用物流車隊的比喻：
對于那些沒有被指派特定調度員的普通貨運卡車（未顯式關聯的子網），它們會自動遵循公司總部發布的默認行車路線圖（主路由表）。

核心區別與對互聯網訪問的影響

現在，我們來回答最關鍵的問題：這兩者的區別是什么？會影響訪問互聯網嗎？

特性	顯式子網關聯 (Explicit)	隱式關聯 (Implicit, via Main)
控制方式	手動、精確。我們為子網指定了路由表。	自動、默認。子網沒有指定，就用主路由表。
架構清晰度	高。網絡流量走向一目了然，便于管理和排障。	較低。容易因疏忽導致子網使用了不期望的路由規則。
安全性	更高。遵循“最小權限”原則，按需分配網絡路徑。	有風險。如果主路由表過于開放，新建的子網可能暴露不必要的風險。

那么，它如何影響互聯網訪問？

影響互聯網訪問的不是“關聯方式”，而是“關聯的那個路由表里的規則”。

• 場景A： 我們將一個子網顯式關聯到一個包含互聯網網關路由的“公共路由表”。那么這個子網里的實例（需有公網IP）就能訪問互聯網。
• 場景B： 一個子網沒有被顯式關聯，它自動使用主路由表。如果這個主路由表恰好也配置了指向互聯網網關的路由，那么這個子網同樣可以訪問互聯網。
• 場景C： 一個子網沒有被顯式關聯，它自動使用主路由表。但這個主路由表的規則里沒有通往互聯網的路由。那么這個子網就無法訪問互聯網。

實用建議與最佳實踐

1. 永遠使用顯式關聯：為了架構的清晰和安全，請為每一個子網都顯式關聯一個路由表。不要依賴主路由表的隱式行為。
2. 改造主路由表：一個安全的實踐是，將默認的主路由表配置成最嚴格的“私有模式”（即不包含任何通往互聯網的路由）。這樣，任何新建的、被遺忘的子網默認都是隔離的，從而避免了意外的風險暴露。然后，按需創建新的“公共路由表”或“私有NAT路由表”，并將子網顯式關聯過去。
3. 排障指南：當我們的 EC2 實例網絡不通時，排查流程應該是：
   • 第一步：確認實例所在的子網。
   • 第二步：查看該子網關聯的路由表（是顯式關聯，還是使用了主路由表？）。
   • 第三步：檢查該路由表中的路由規則是否符合我們的預期。

結論

總而言之，“顯式子網關聯”是我們主動的設計，而“未顯式關聯的子網”則是一種默認回退機制，它們會自動歸屬于主路由表的管轄。雖然關聯方式本身不直接決定網絡通斷，但它決定了子網最終會使用哪一套“交通規則”。

掌握了這兩者的區別，我們就掌握了精細化控制 VPC 流量的核心技巧。希望這篇文章能幫助大家構建一個更加安全、健壯和可預測的 AWS 網絡環境！