多 VPC 集中出口是什么
集中出口把出公网这件事从「每个 VPC 各自买 NAT 与 EIP」改成「统一走一个出口 VPC」：业务 VPC 的流量经转发路由器或云企业网汇聚到出口 VPC，再由那里的 NAT 网关与 EIP 统一出网。好处是出口地址数量可控、白名单好维护、安全防护与流量审计集中在一处；代价是出口 VPC 成了关键路径，可用性与容量都要按全量流量设计，而且跨 VPC 转发本身也会产生费用。
基本信息
| 架构 | 业务 VPC → 转发路由器/云企业网 → 出口 VPC（NAT + EIP） |
|---|---|
| 收益 | 出口统一管控，EIP、防护与审计集中 |
| 前提 | 跨 VPC 路由打通，且往返路径对称 |
| 风险 | 出口 VPC 成为关键路径，需高可用与容量余量 |
| 成本变化 | 跨 VPC 转发与流量处理可能产生额外费用 |
| 验证方式 | 在业务 VPC 实例内实测公网出口 IP |
典型使用场景
- 多个业务 VPC 都需要出公网，希望统一出口地址便于对端白名单
- 合规要求出网流量统一审计与拦截
- 成本治理：减少零散 EIP 与独立 NAT 网关数量
- 多环境统一出口策略，避免各环境规则漂移
- 为自建代理、日志采集提供集中接入点
集中出口的收益与代价
| 维度 | 集中出口 | 每 VPC 独立出口 |
|---|---|---|
| 出口地址 | 数量少、易维护 | 分散，白名单维护成本高 |
| 安全审计 | 集中，策略统一 | 各环境自行配置，容易漂移 |
| 故障影响 | 出口 VPC 故障影响全部业务 | 影响范围局限单个 VPC |
| 路由复杂度 | 需要打通跨 VPC 且路径对称 | 各 VPC 独立，简单 |
| 费用结构 | 增加跨 VPC 转发费用 | 各 VPC 独立计费 |
在业务 VPC 实例内验证出口
在业务 VPC 实例内验证出口
curl -s https://ifconfig.me; echo # 预期观察到出口 VPC 的 EIP
traceroute -n -T -p 443 1.1.1.1 # 观察路径是否先到出口 VPC
ip route get 1.1.1.1 # 默认路由是否指向转发路由器
mtr -rwzc 30 1.1.1.1 # 汇聚路径的稳定性
# 若出口 IP 不是预期值，优先检查业务 VPC 的路由优先级跨 VPC 转发与流量处理可能产生额外费用，方案评审时一并评估成本：集中出口省下的是 EIP 与运维成本，增加的可能是转发流量费，两者要放在一起算。
回程路径对称是这类架构的隐形门槛：请求经出口 VPC 出去，回包若从别的路径回来，会被丢在中间设备上。上线前用 traceroute 双向确认路径，并注意 NAT 会话表在有状态设备上的位置。