亚马逊云12个月免费号 AWS Transit Gateway 实战教程：简化多 VPC 网络互联的创建、路由配置与故障排查

当你的 AWS 环境从 2 个 VPC 增长到 5 个、10 个甚至更多时，最先失控的往往不是实例数量，而是网络路由。开发环境、生产环境、数据库网络、共享服务网络、VPN 网络同时存在后，用户常见的问题包括：VPC Peering 数量太多难维护、路由表反复改动容易出错、跨账号互联审批复杂、某些子网能通某些子网不通、明明 attachment 已创建却还是无法访问服务。搜索“AWS Transit Gateway 实战”的用户，真正想解决的是如何把多 VPC 互联做成可扩展、可排错、可持续维护的网络结构。下面直接进入配置实践。

先明确这篇教程要解决哪些实际问题

亚马逊云12个月免费号 在真实项目中，用户通常不是来了解 Transit Gateway 是什么，而是在以下决策点卡住：

• 已经有多个 VPC，继续使用 VPC Peering 是否会越来越乱。
• 生产、测试、共享服务网络是否应该共用一个 Transit Gateway 路由表。
• 创建了 VPC attachment 后，为什么 EC2 仍然 ping 不通或应用连接超时。
• 数据库所在 VPC 是否应该通过 Transit Gateway 暴露给所有业务 VPC。
• 跨账号接入时，Resource Share、Attachment、Route Table Association 到底先做哪一步。
• 如何避免因为 CIDR 冲突、路由传播错误、安全组遗漏导致上线失败。

如果你的目标是把多个 VPC、办公网络、VPN 或 Direct Connect 接到统一网络枢纽，并且希望后续新增网络时不再逐一建立 Peering，那么本文的步骤适合直接照着操作。

部署前准备：先把这些信息确认好，能少走很多弯路

账号与权限要求

建议使用具备以下权限的 IAM 角色或账号执行操作：

• ec2:CreateTransitGateway
• ec2:CreateTransitGatewayVpcAttachment
• ec2:CreateRoute
• ec2:AssociateTransitGatewayRouteTable
• ec2:EnableTransitGatewayRouteTablePropagation
• 亚马逊云12个月免费号 ram:CreateResourceShare（跨账号共享时）

如果是组织内多账号环境，建议网络团队统一在专用网络账号中创建 Transit Gateway，再通过 AWS RAM 共享给业务账号使用。

前置规划清单

在控制台点击创建前，先完成下面这张表中的信息确认：

建议的测试资源

为了快速验证网络连通性，建议每个 VPC 至少准备一台测试实例：

• 亚马逊云12个月免费号 Amazon Linux 2023 或 Ubuntu 22.04，用于 SSH 和 traceroute 测试
• Windows Server 2022，用于 RDP 和应用端口验证
• 若涉及数据库，准备 MySQL 或 Redis 测试端口

Linux 测试常用命令：

ping 10.1.1.10

traceroute 10.1.1.10

nc -zv 10.1.1.10 3306

亚马逊云12个月免费号 Windows 可使用 PowerShell：

Test-NetConnection 10.1.1.10 -Port 3389

操作实践一：创建 AWS Transit Gateway 并填写关键参数

步骤1：在控制台创建 Transit Gateway

进入 AWS 管理控制台，打开 VPC 服务。

左侧选择 Transit Gateways，点击 Create transit gateway。

亚马逊云12个月免费号 重点填写以下参数：

这里最容易出错的不是创建动作本身，而是把默认关联和默认传播保留为开启。这样短期看省事，长期会让测试网、生产网、数据库网意外互通，后期排查复杂度非常高。

步骤2：创建 Transit Gateway 路由表

创建完成后，不要急着接 VPC，先规划路由表。进入 Transit Gateway Route Tables，创建至少 2 张：

• tgw-rt-shared-services：共享服务路由表，如 AD、日志、监控、堡垒机
• tgw-rt-app-prod：生产应用路由表

如果环境隔离要求高，可以进一步拆分为 dev、test、prod 三张，数据库单独一张。

经验建议：不要一开始只建一张大路由表。后面只要出现“开发环境误通生产数据库”，基本都和早期偷懒有关。

亚马逊云12个月免费号 操作实践二：将多个 VPC 连接到 Transit Gateway

步骤3：创建 VPC attachment

进入 Transit Gateway Attachments，点击 Create transit gateway attachment。

Resource type 选择 VPC，然后依次设置：

这里有两个非常关键的注意事项：

• 不要随便选择业务子网作为 attachment 子网，建议专门划出 TGW attachment 子网，便于审计和路由控制。
• 如果你的应用分布在 ap-southeast-1a 和 ap-southeast-1b，而 attachment 只选了 1a 的子网，可能会引发跨 AZ 流量绕行或设计不符合预期。

步骤4：关联到正确的 Transit Gateway 路由表

Attachment 创建后，进入对应 attachment 页面，选择 Associate route table。

例如：

• 应用 VPC 关联到 tgw-rt-app-prod
• 共享服务 VPC 关联到 tgw-rt-shared-services

Association 决定这个 VPC “看”哪张 TGW 路由表。很多用户把 attachment 建好了，却忘了做 association，结果 TGW 状态显示 available，但流量没有进入预期路由域。

步骤5：启用路由传播或手工加静态路由

进入目标 Transit Gateway Route Table，选择 Propagations，启用来自相关 attachment 的路由传播。或者手工创建静态路由：

如果你对网络隔离要求高，优先使用静态路由；如果 VPC 数量多且变更频繁，可以结合 propagation，但要对传播范围做限制。

操作实践三：修改 VPC 路由表，否则 attachment 建好了也不会通

这是最常见漏项。Transit Gateway 不是创建完就自动生效，VPC 内部子网路由表也必须知道“去其他 VPC 的流量要发给 TGW”。

步骤6：在业务子网路由表中添加目标网段

进入 VPC Route Tables，找到应用服务器所在子网使用的路由表，点击 Edit routes。

添加类似规则：

如果你希望某个应用 VPC 只访问共享服务 VPC，不访问数据库 VPC，就只加对应网段，不要偷懒写大范围聚合路由。

步骤7：检查返回路径

双向通信失败时，80% 以上的问题不是入口不通，而是返回路由缺失。比如 app-vpc 可以到 db-vpc，但 db-vpc 的子网路由表里没有返回 app-vpc CIDR 到 TGW 的路由，结果表现为连接超时。

排查顺序建议固定为：

• 源实例所在子网路由表
• 目标实例所在子网路由表
• TGW 路由表 association
• TGW 路由表 route/propagation
• 安全组
• NACL
• 实例本机防火墙

跨账号和混合网络接入：适合企业多环境统一管理

步骤8：跨账号共享 Transit Gateway

如果生产 VPC、测试 VPC 在不同账号，建议使用 AWS RAM。

操作顺序如下：

• 在网络账号中打开 AWS RAM，创建 Resource Share。
• 选择资源类型为 Transit Gateway。
• 添加目标账号或 AWS Organization OU。
• 在被共享账号中接受共享。
• 由业务账号创建 attachment，或由网络账号统一代建。

跨账号常见错误是：RAM 已共享，但目标账号没有接受，或者 attachment 建好了却没有被网络账号批准。

步骤9：接入 VPN 或 Direct Connect

如果你的目标不仅是多 VPC 互联，还要把本地 IDC 或办公室网络接进来，可以在 TGW 上增加 VPN attachment 或 Direct Connect Gateway 关联。

这时要特别关注两个点：

• 本地网段不能与 AWS VPC CIDR 冲突。
• BGP 广告和 TGW 路由传播范围要可控，避免本地网段意外进入所有 VPC。

一个常见上线失败案例是：本地网络使用 10.0.0.0/8 大网段，而 AWS 多个 VPC 又都在 10.x.x.x，结果 BGP 路由优先级混乱，导致部分业务流量走错路径。

典型故障排查：为什么 attachment 显示正常，但业务仍然不通

故障场景1：EC2 可以 ping TGW 对端网段，但数据库端口连不上

优先检查数据库安全组是否放通来源 CIDR。很多用户只改了网络路由，没有在 3306、5432、6379 等端口上允许来源 VPC 网段。

故障场景2：Linux 能通，Windows RDP 不通

通常不是 TGW 问题，而是目标 Windows 主机防火墙未放行 3389，或安全组仅允许堡垒机来源 IP。

故障场景3：只有某个可用区的实例访问失败

重点检查该 AZ 对应子网是否使用了不同路由表，或者 attachment 创建时没有包含该可用区的子网。

故障场景4：跨账号 attachment 一直处于 pending acceptance

说明共享流程未闭环。去 TGW owner 账号中确认是否需要手动 accept attachment。

故障场景5：新增 VPC 后，旧业务突然异常

亚马逊云12个月免费号 大概率是 CIDR 冲突或路由传播导致更具体路由被覆盖。使用 Reachability Analyzer 可以快速验证路径断点。

按业务类型给出配置建议

如果你同时管理网站、API、Redis、MySQL、日志系统，推荐采用“共享服务中心 VPC + 应用 VPC + 数据库 VPC”的结构，所有流量经 TGW 汇聚，但路由表按访问方向分开，而不是全部互通。

配置优化：不仅要能通，还要稳定、可控、成本清晰

安全优化

• 关闭 TGW 默认 association 和 propagation。
• 数据库 VPC 单独路由表，不接受无关网络传播。
• 亚马逊云12个月免费号 安全组使用源安全组或明确 CIDR，不使用 0.0.0.0/0 放通内部端口。
• 跨账号 attachment 审批流程固定化，避免误接入。

性能优化

• 每个活跃可用区选择对应 attachment 子网，减少不必要跨 AZ 流量。
• 高并发业务优先检查实例 ENA、MTU、应用连接池和 DNS 解析延迟，不要把所有性能问题都归因于 TGW。
• 使用 Reachability Analyzer 和 VPC Flow Logs 定位路径问题。

成本优化

• VPC 数量较少时，对比 TGW 与 Peering 成本，不要盲目升级架构。
• 按环境拆分路由，不必要的互联就不要建立。
• 对跨可用区、跨区域流量做监控，避免因为架构绕行导致流量费用升高。

稳定性优化

• 路由命名和 attachment 命名统一规范，如 env-app-region。
• 所有网段规划写入 CMDB 或 Terraform 变量，避免人工新增冲突 CIDR。
• 上线前做最小验证：ICMP、TCP 端口、DNS、双向返回路径四项全部通过再切业务。

如果你打算进一步自动化，建议把 Transit Gateway、Route Table、Attachment、VPC Route 全部纳入 Terraform 或 CloudFormation 管理，避免控制台手工改动造成配置漂移。

最后给一个实战判断标准：当你发现新增一个 VPC 需要修改 3 个以上已有 VPC 的配置时，就应该尽快改成以 Transit Gateway 为中心的路由结构。这样后续扩容、隔离、排错都会轻松很多。