AWS帳號代開 AWS Transit Gateway 跨帳號網路路由不通？TGW 路由表與 Attachment 排查
先看懂：TGW 不是一條線，而是一套轉發規則
AWS Transit Gateway 簡單看像一個中繼站，但真正在跑流量時，決定路能不能走通的，不只是 Attachment 是否建立成功，還包括 TGW 路由表、Attachment 的關聯與傳播、VPC 子網路由表、以及跨帳號共享是否完整。很多人第一次做跨帳號網路互通，常會遇到一個很典型的現象：Attachment 顯示正常，VPC 也已經掛上 TGW，可是兩邊主機就是打不通。問題通常不在連線本身，而在路由沒有被正確放進去。
要排查這類問題，先不要急著看安全組或 NACL。先把整個路由鏈條想清楚：來源 VPC 的封包先離開子網路由表，進到 TGW Attachment，再由 TGW 路由表決定要送到哪一個 Attachment，最後回程還要再走一次相同邏輯。只要其中任一段缺了一條路，雙向通訊就會失敗。
TGW 的核心概念：Association 與 Propagation
TGW 排查最容易混淆的地方，就是 Attachment 與路由表之間的兩種關係：Association 和 Propagation。這兩個名詞很像，但作用完全不同。
AWS帳號代開 Association 是「這個 Attachment 進哪一張表」
Association 決定某個 Attachment 的入站流量，會先查哪一張 TGW 路由表。你可以把它想成門牌號碼。封包從某個 VPC 進入 TGW 後，TGW 要先知道自己應該依哪一張表來判斷下一跳。如果 Attachment 沒有正確關聯到預期的路由表，流量就會被送到錯的規則集，結果不是走錯地方，就是直接找不到路。
Propagation 是「把哪些路由學到這張表」
Propagation 則是把 Attachment 對應的可達網段，自動寫進 TGW 路由表。這一點非常重要。很多人以為 Attachment 掛上去，TGW 就會自動知道對方網段，其實不一定。你必須確認該 Attachment 是否有開啟路由傳播，且傳播到正確的 TGW 路由表。沒有傳播，對端網段可能根本不存在於表中，TGW 當然無法轉送。
簡單說，Association 決定「從哪裡看表」，Propagation 決定「表裡有沒有資料」。排查 TGW 不通時，這兩個一定要分開看。
跨帳號場景最常見的問題點
跨帳號使用 TGW，通常會先經過 RAM 分享。這一步如果沒處理好，後面做再多都沒用。常見流程是：網路帳號建立 TGW，透過 AWS RAM 將 TGW 分享給應用帳號，應用帳號接受共享後建立 VPC Attachment，最後由網路帳號統一管理 TGW 路由表。這個架構很常見，但也最容易因為權限分工太細，導致一邊設定了，另一邊沒跟上。
最常見的幾個坑如下。
- 共享已建立，但對方帳號沒有接受邀請，Attachment 建不完全。
- Attachment 已建立，但沒有關聯到正確的 TGW 路由表。
- AWS帳號代開 路由傳播沒有開啟，TGW 表裡看不到對端 CIDR。
- VPC 子網的路由表沒有指向 TGW，來源封包根本出不去。
- 回程路由缺失，單向通、雙向不通。
- 兩個 VPC 的 CIDR 重疊，TGW 無法正確判斷路徑。
其中最麻煩的是回程路由問題。很多人測試時只看來源端能不能 ping 到對端，忘了回程是否也存在。網路不是單向箭頭，而是來回兩條路都要通。
排查第一步：先確認 Attachment 狀態
當跨帳號網路不通時，第一件事不是看流量，而是看 Attachment 狀態是否真的健康。Attachment 至少要確認幾件事：
- 狀態是否為可用。
- 是否已經接受共享資源。
- 對應的子網是否選對，尤其是每個可用區是否都有正確配置。
- VPC 與 TGW 是否位於相容的區域。
有些人以為 Attachment 建立完成就沒問題，但其實 VPC Attachment 依賴你在每個可用區選定子網。這些子網會承擔與 TGW 之間的流量，如果選錯子網、子網路由表沒改、或者安全策略阻擋，表面上看起來是 TGW 的問題，實際上根本沒把流量送出去。
排查第二步：檢查 TGW 路由表有沒有對的路
TGW 路由表是整個問題的核心。你要先看來源網段與目的網段是否都出現在表中，再看每條路由對應到哪個 Attachment。這裡常見的誤區是只看「有沒有路由」，卻不看「路由指向哪裡」。有路由不代表正確，有時候它可能指向另一個 Attachment，導致流量被送到錯誤的 VPC。
建議用這個邏輯檢查：
- 來源 VPC 的 CIDR 是否有出現在 TGW 路由表中。
- 目的 VPC 的 CIDR 是否有出現在 TGW 路由表中。
- 來源 Attachment 是否關聯到預期的 TGW 路由表。
- 目的 Attachment 是否也在同一張表，或至少存在可達的靜態路由。
如果你有多張 TGW 路由表，例如一張給生產環境、一張給測試環境、一張給共用服務，那就更要注意 Association 與 Propagation 不能亂掛。很常見的問題是，Attachment 已經傳播到某張表，但 Association 卻掛到另一張表，結果封包進來查的是 A 表，路由卻只在 B 表，當然找不到出口。
排查第三步：不要忘了 VPC 子網路由表
很多人把所有注意力放在 TGW，卻忽略 VPC 自己的路由表。封包要先從子網出去，才能到 TGW。若子網路由表沒有把對端 CIDR 指向 TGW Attachment，流量根本走不到 TGW，更不用說跨帳號了。
例如，帳號 A 的應用子網要連帳號 B 的資料庫子網，你需要在帳號 A 的 VPC 路由表中加入對帳號 B CIDR 的路由，目標指向 TGW。帳號 B 也要做同樣的回程設定，把帳號 A 的 CIDR 指向 TGW。這是最基本的雙向設計。如果只做單邊，測試很可能會出現半通半不通的狀況。
此外，別忘了路由表是綁在子網上的，不是綁在整個 VPC 上。很多故障其實只是某個子網沒套到正確的 route table，其他子網正常，讓人誤以為是 TGW 在抽風。
AWS帳號代開 排查第四步：確認沒有 CIDR 衝突
跨帳號網路設計裡，CIDR 重疊是致命問題。假設兩個 VPC 都用了 10.0.0.0/16，TGW 就無法透過路由表清楚區分目的地。即使 Attachment 正常，路由規則也會變得不可靠，結果不是轉錯方向，就是根本無法建立有效連通。
在設計階段就要先把網段規劃好，最好一開始就避免重疊。如果已經上線才發現重疊，通常不是改一張路由表就能解決，往往要重新規劃網段，甚至遷移資源。這也是為什麼 TGW 雖然好用，但前期地址規劃一定要做細。
排查第五步：安全組、NACL 與服務本身也可能擋住流量
當路由看起來都正確，還是打不通時，就要往下看安全層。TGW 只負責把流量送到正確的網路，不負責放行應用層的連線。安全組、NACL、主機防火牆、甚至服務本身的監聽埠設定，都可能讓你看到「路由通了，但應用不通」。
AWS帳號代開 例如，兩台主機能互相 ping 通，不代表 TCP 443 一定能連。也可能是安全組只允許了來源子網的另一個 CIDR，或者資料庫根本沒在預期埠號上聽。排查時要分清楚：網路層是否可達，應用層是否可用，是兩件不同的事。
一個實際的排查順序，照著做通常最快
如果你正在處理跨帳號 TGW 不通，建議按下面順序檢查，效率最高。
- 確認兩邊 VPC CIDR 沒有重疊。
- 確認 TGW 已透過 RAM 分享，且對方帳號已接受。
- 確認 VPC Attachment 狀態正常，並且已選對子網。
- 確認 Attachment 已關聯到正確的 TGW 路由表。
- 確認需要的路由傳播已開啟，路由表中看得到對端網段。
- 確認來源 VPC 子網路由表有指向 TGW 的路由。
- 確認回程 VPC 子網路由表也有指回 TGW 的路由。
- 確認安全組、NACL、主機防火牆沒有擋住目標流量。
這個順序的好處是先查最可能出錯、影響最大、且最容易漏掉的地方。很多時候一開始就去抓封包，反而浪費時間。路由沒通時，封包分析看到的通常只會是到不了下一跳，根本不會有太多資訊。
幾個最容易誤判的現象
在 TGW 跨帳號排查中，有些現象很容易讓人誤判問題來源。
第一種是 Attachment 看似正常，但路由表空空如也。這通常是傳播沒開，或傳播到錯的路由表。第二種是兩邊都能看到彼此 CIDR，但實際連不上，這時要看是不是子網路由沒配，或者安全組沒放行。第三種是某些子網能通、某些不能通，這通常是子網 route table 套用不一致。第四種是新建環境可以通，舊環境不通，往往是因為不同環境用了不同的 TGW 路由表策略，或者某些 Attachment 只做了部分關聯。
還有一種很常見：管理員以為「共享了 TGW 就等於共享了所有能力」，但實際上共享只是第一步。建立 Attachment、配置路由、控制傳播、設計隔離，這些都還要逐一完成。TGW 的強大正在於它能被精細管理，而不是一鍵全通。
設計上怎麼避免以後一直排查
與其每次出問題才救火，不如一開始就把 TGW 架構設計清楚。最實用的做法，是把 TGW 路由表當成一種分流工具，而不是一張大雜燴表。你可以依照環境、業務、共享服務來切分，例如生產、測試、審計、共用基礎設施各自一張表，讓每個 Attachment 只看到自己該看到的路徑。
這樣做的好處有三個。第一，風險更低，不容易把不該互通的環境打通。第二，問題更好查，路由來源清楚。第三，變更更安全，新增一個 Attachment 時，不需要擔心它自動吃到不該有的傳播。
另外，最好把路由規則與責任分工寫清楚。哪個帳號負責 TGW，哪個帳號負責 VPC，哪個團隊能改路由，哪個團隊只能申請共享，都要先定義。不然跨帳號環境一旦出事，很容易每個人都說自己這邊沒改，最後花大量時間在來回確認。
結語：TGW 不通，多半是規則沒對齊
AWS Transit Gateway 的問題，表面上看是網路不通，實際上大多是規則沒有對齊。Attachment 只是通道，Association 決定查哪張表，Propagation 決定表裡有沒有路由，VPC 子網路由表決定流量能不能送進 TGW，回程路由決定能不能回得來。只要這幾層有一層錯，跨帳號連通就會出現空窗。
排查 TGW 不要怕麻煩，最重要的是建立固定順序。先看共享與 Attachment，再看 TGW 路由表，再看 VPC 路由表，最後才看安全層。只要方法對，TGW 其實很好查，也很容易穩定運作。真正難的不是修一次，而是把架構設計成下一次不容易再出錯。
