AWS免实名账号 AWS Transit Gateway 跨账号网络路由不通？TGW 路由表与 Attachment 排查
很多人第一次做 AWS 跨账号互通，最常见的反馈不是“创建失败”，而是“Attachment 明明是 Available，但两边 VPC 还是互 ping 不通”。
我处理过的这类问题里，真正卡住的点通常只有三类：Attachment 没接对、TGW 路由表没配对、VPC 回程路由缺失。如果再往下看，才是安全组、NACL、CIDR 重叠、账号权限、付款状态这些外围问题。
先说结论：跨账号 TGW 不通，别先怀疑网络，先查这 4 项
- Attachment 状态：是不是还在 PendingAcceptance / Pending / Failed。
- TGW 路由表关联：Attachment 有没有关联到正确的 TGW Route Table。
- 传播是否开启：源/目标 VPC 的路由有没有被传播进 TGW 路由表。
- VPC 子网路由：实例所在子网的路由表，是否已经把对端网段指向 TGW。
实际排查中，60% 以上的问题出在“Attachment 已建好，但关联错了路由表”或者“只配了单向路由，回程没配”。
一、跨账号场景最容易踩的 6 个坑
| 现象 | 高概率原因 | 你应该先查什么 |
|---|---|---|
| Attachment 已 Available，但不通 | TGW 路由表未关联 / 未传播 | 看 TGW Route Table 的 Association 和 Propagation |
| 单向能通，反向不通 | 回程路由缺失 | 对端 VPC 子网路由表是否指向 TGW |
| 跨账号创建 Attachment 失败 | 资源共享没接受 / IAM 权限不足 | RAM/Share 接收状态、IAM 权限、组织共享策略 |
| 能 ping 私网 IP，但应用端口不通 | 安全组/NACL/系统防火墙拦截 | 放通对应端口与回包规则 |
| 路由看起来都对，还是不通 | CIDR 重叠 | 检查两边 VPC 网段是否有交集 |
| 新账号资源创建异常 | 支付方式未验证 / 风控触发 | 账单卡是否通过验证、是否被限制创建资源 |
二、按实际排障顺序查，效率最高
1）先看 Attachment 有没有“真的接上”
跨账号 TGW 不是“创建完就能通”。如果 TGW 所在账号通过资源共享把 TGW 给到另一个账号，对方创建 VPC Attachment 后，先确认：
- Attachment 是否为 Available。
- 跨账号共享是否已被接收。
- 目标 VPC 与子网是否选对。
- Attachment 所在区域是否一致。
2）再查 TGW 路由表，不要只看 VPC 路由表
很多人习惯先看 VPC 路由表，但 TGW 场景里，中间转发点是 TGW Route Table。如果 Attachment 没有关联到正确的 TGW 路由表，或者没有开启传播，你会看到“路由像是配了，实际不转发”。
经验上，建议你把 TGW Route Table 分成两类看：
- 入口路由表：谁能进 TGW。
- 出口路由表：进来后要去哪里。
AWS免实名账号 如果你把多个 Attachment 混在同一个表里，后面排障会非常痛苦，尤其是跨账号、跨环境、跨业务线时。
3）VPC 子网路由表必须指向 TGW
这一步是最容易漏掉的。VPC 里创建了 Attachment，不代表实例就自动走 TGW。你还要把实例所在子网的路由表，指向对端 CIDR 到 TGW。
常见错误是：只改了主路由表，没改实例实际绑定的子网路由表。AWS 里子网绑定错路由表，比想象中常见得多。
4）最后再查安全组、NACL、系统层
如果路由都没问题，ping 还是不通，才查安全组和 NACL。很多人一开始就盯着安全组，其实会浪费大量时间。
AWS免实名账号 建议顺序：
- 先用
ping或telnet/ nc验证路由。 - 再查安全组入站和出站。
- 最后看 NACL 是否有显式拒绝。
三、跨账号为什么比同账号更容易出问题
同账号内配置 TGW，通常问题集中在路由层；跨账号时，问题会多一层：账号权限和共享关系。
- 资源共享未完成：对方账号没接受 TGW 共享，Attachment 无法正常创建。
- IAM 权限不足：创建 Attachment、查看路由表、修改路由需要对应权限。
- 组织策略限制：企业账号下有些操作被 SCP 或权限边界限制。
- 账号状态异常：账单未验证、付款失败、风控触发后，部分网络资源操作会受影响。
如果你是新开 AWS 账号，别忽略付款状态。AWS 不是“先充值再用”的模式，更多是绑定信用卡后按账单扣款。卡验证不过、账单地址不匹配、虚拟卡被拒、3DS 验证失败，都会让资源创建或后续变更卡住。
四、关于账号开通、实名认证、支付方式：这不是附加项，是真问题
不少人做 TGW 排障时，发现网络配置没问题，但账号层已经先出事了。实操里最常见的是以下几种：
- 信用卡验证失败：卡段不支持、余额不足、风控拒付、账单地址不一致。
- 账号触发审核：短时间内多账号注册、频繁切换 IP、同一设备反复登录。
- 企业信息不完整：公司名、地址、联系人、税务信息填写不一致。
- 第三方代充/买号风险：后续找回、付款争议、Root 权限不在自己手里。
如果你打算长期跑 TGW、VPN、Direct Connect 这类网络架构，不要用来路不明的成品账号。买号的最大问题不是“便宜”，而是后续一旦卡在付款、风控、实名补件，你没法控制 Root 和账单主体。
五、成本别只看 TGW，本质是“转发费 + 流量费 + 互联费”
很多人第一次上 TGW，会以为“比 VPC Peering 高一点点”，结果账单出来才发现，除了 Attachment 费用，还有数据处理、跨 AZ、跨区域、VPN 之类的额外项。
| 方案 | 适合场景 | 费用特点 | 排障难度 |
|---|---|---|---|
| VPC Peering | 2 个 VPC 直连 | 通常更便宜，但不支持传递路由 | 低 |
| TGW | 多 VPC、多账号、中心辐射 | 有附件和流量处理成本 | 中高 |
| VPN + TGW | 远程办公、混合云 | VPN 与 TGW 费用叠加 | 高 |
如果你的网络结构只有 2 个 VPC，且不会扩展到更多账号，Peering 往往更省钱；但只要你有多账号、多业务线、未来要扩展的计划，TGW 的维护效率会更好。只是要接受它的账单更细，排查路径也更长。
六、实战排查示例：为什么“同账号通、跨账号不通”
AWS免实名账号 一个很典型的现场是：A 账号里有中心网络 VPC，B 账号里是业务 VPC。两边 Attachment 都是 Available，但业务侧访问中心侧数据库失败。
我一般会这样查：
- 确认 B 账号的 Attachment 是否已经被正确关联到 TGW 的业务路由表。
- 确认中心路由表里是否有去往 B 账号网段的传播路由或静态路由。
- 确认 B 账号子网路由表是否把中心网段指向 TGW。
- 确认数据库安全组是否允许 B 账号网段的源地址。
- 确认两边 CIDR 没有重叠。
最后我碰到过一个案例，问题根本不是路由，而是业务账号用了一个刚注册的卡，账单验证没过，后续修改路由时控制台动作一直报错。也就是说，账号状态异常会伪装成网络问题，这类坑很容易误判。
七、FAQ：你最可能会问的几个问题
Q1：Attachment 是 Available，为什么还是不通？
A：大概率是 TGW 路由表没关联对，或者 VPC 子网路由没指向 TGW。先看两张路由表，再看安全组。
Q2：跨账号一定要先共享 TGW 吗？
A：是。没有资源共享接收，Attachment 创建和后续管理都会受影响。
Q3：AWS 账号可以像云厂商国内站那样充值吗？
A：通常不是充值制，而是绑卡后按账单扣款。要重点关注卡验证和账单扣款是否成功。
Q4：新账号适合直接上生产 TGW 吗？
A：不建议。先把支付方式、权限边界、共享流程、账单联系人跑通，再接生产网段。
Q5：TGW 比 Peering 贵多少？
A：要看流量规模和是否跨 AZ。只看附件费没有意义，真正拉开差距的是长期流量和后续扩展成本。
最后给一个实操建议
如果你现在正卡在“跨账号 TGW 不通”，不要同时改很多项。正确做法是按这个顺序停下来：
- 先确认账号没被付款/风控卡住。
- 再确认 Attachment 状态正常。
- 然后检查 TGW 路由表关联和传播。
- 最后查 VPC 子网路由、安全组、NACL。
只要按这个顺序排，绝大多数问题都能在 15 到 30 分钟内定位出来。真正难的，不是 TGW 本身，而是跨账号、跨权限、跨支付状态叠在一起后，表面看像网络，实际是多层问题同时存在。
