Private 子网的 EC2 没有公网 IP，但它可能需要下载软件包、访问外部 API。怎么让这些实例安全地访问公网，同时不暴露入站端口？最主流的方案是 TGW + NAT Gateway。
流量路径
Private EC2 访问公网的完整路径：
1
Private EC2（10.1.0.10）→ TGW → NAT Gateway（10.0.0.10）→ IGW → Internet
逐段拆解：
- EC2 发起出站请求，源 IP 为私有地址
10.1.0.10 - 子网路由表将
0.0.0.0/0指向 TGW，流量进入 Transit Gateway - TGW 根据路由表将流量转发到 Network VPC 的 NAT Gateway 所在子网
- NAT Gateway 做 SNAT，将源 IP 转换为自己的公网 IP
- 流量通过 IGW 到达公网
- 回包到达 NAT Gateway，NAT 还原目标 IP 为
10.1.0.10，经 TGW 原路返回
为什么不能省略 NAT
这是最常见的误解。TGW 是三层路由器，不做 SNAT。如果让 Private EC2 → TGW → IGW：
1
2
3
4
5
Private EC2（10.1.0.10）→ TGW → IGW → Internet
↓
回包目标：10.1.0.10
↓
IGW 无法路由到私有 IP ❌
IGW 只处理目标为公网 IP 或 VPC 网段的流量。回包的目标地址是私有 IP 10.1.0.10，IGW 不知道这个 IP 属于哪个 VPC，也没有路由可以转发——因为源 VPC（Prod）不在 IGW 所在的 VPC（Network）内。NAT Gateway 的 SNAT 转换是不可或缺的一环。
高可用设计
NAT Gateway 部署在单个可用区。如果只部署一个 NAT Gateway，另一个 AZ 的 Private 子网路由指向跨 AZ 的 NAT，会带来两个问题：
- 单点故障：NAT Gateway 不可用后，跨 AZ 的 Private 子网完全失去出站能力
- 跨 AZ 流量费：跨可用区的流量有额外费用（$0.01/GB）
最佳实践是每个 AZ 各部署一个 NAT Gateway，Private 子网的路由表指向本 AZ 的 NAT：
1
2
AZ-a Private 子网路由：0.0.0.0/0 → nat-a（同 AZ）
AZ-b Private 子网路由：0.0.0.0/0 → nat-b（同 AZ）
替代方案对比
| 方案 | 优势 | 劣势 |
|---|---|---|
| NAT Gateway | 托管服务，高可用，无需运维 | 每个 AZ 一个，费用固定 |
| NAT Instance | 费用低（可选用 t4g.nano） | 自建 EC2，需自行管理高可用 |
| VPC Endpoints（仅限 AWS 服务） | 不经过公网，延迟低 | 只覆盖 S3、DynamoDB、SSM 等 AWS 服务 |
| 前置 IGW（Public 子网） | 零额外费用 | 实例暴露公网 IP，不安全 |
NAT Instance 可以节省费用，但需要自己处理故障切换、带宽扩缩等问题。生产环境中建议使用托管的 NAT Gateway。
出站流量审计
出站流量集中经过 Network VPC 的 NAT Gateway 后，安全团队的审计点也收敛到了一处：
- 在 NAT Gateway 所在子网启用 VPC Flow Logs，记录所有出站连接的源 IP、目标 IP、端口、协议
- 将 Flow Logs 投递到审计账号的 S3 桶或 CloudWatch Logs，设置监控告警
- 检测到异常出站（如连接已知恶意 IP 或非业务端口）时通过 SNS 通知
特殊场景：单 VPC 内怎么做？
如果只有单个 VPC（无 TGW），Private 子网的出站路径更简单：
1
Private EC2 → 路由表（0.0.0.0/0 → nat-xxx）→ NAT Gateway（同 VPC Public 子网）→ IGW → Internet
同 VPC 内不需要 TGW，Private 子网的路由直接指向 NAT Gateway 即可。NAT Gateway 和 IGW 都在同一个 VPC 内，路由链路更短，费用也更低。
小结
Private EC2 访问公网的核心要点：TGW 是三层路由器，不做地址转换，所以 NAT Gateway 必不可少。多 AZ 部署保证高可用，VPC Flow Logs 补齐审计能力。如果架构允许，单 VPC 内方案更简单经济。