4. 集中式网络账号设计
在 AWS 多账号体系中，网络并不是每个业务账号各自为政的“孤岛”，而是由少数几个职责明确的网络账号统一承载连通性、边界与地址规划。集中式网络账号设计的核心，是把“谁负责连通、谁负责出口、谁负责共享服务、谁负责地址分配”这四件事拆开，分别落到网络枢纽账号、出口账号、共享服务账号和 IPAM 归属上。这样做的直接收益是：业务账号只关心自己的 VPC 与子网，跨账号、跨 VPC、跨本地数据中心的复杂路由由网络账号集中收敛，安全策略和审计点也更容易统一。
三类网络账号的职责边界
网络枢纽账号（Network Hub Account）通常承载 Transit Gateway（TGW）及其路由表、VPC 关联、VPN/Direct Connect 连接。它是整个组织东西向和南北向流量的“交换中心”。出口账号（Egress Account）则专门承载出站流量路径，典型做法是在出口账号中部署 NAT Gateway 或集中式防火墙，业务账号的默认路由指向 TGW，再由 TGW 路由到出口账号的 VPC。共享服务账号（Shared Services Account）用于放置被多个业务账号共同访问的服务，例如 Active Directory、DNS Resolver、CI/CD 工具链、镜像仓库或集中式日志采集端点。
需要强调的是，这三类账号并不一定物理分离。中小规模组织可以把出口能力合并进网络枢纽账号，但一旦出现“出站流量需要独立计费、独立审计、独立限流”的需求，就应把出口账号独立出来。判断标准不是账号数量，而是职责是否可独立变更、独立授权、独立审计。
归属原则：VPC 的创建者通常是“使用该 VPC 的业务方”，但 TGW、路由表、IPAM 池、NAT 出口、共享 DNS 解析器这些“跨账号公共资源”的归属，应统一放在网络账号或共享服务账号中，避免业务账号各自创建导致路由冲突和地址重叠。
VPC、子网、路由与 IPAM 的归属划分
集中式设计中最容易出问题的是 IP 地址规划。建议由网络账号统一管理 IPAM，先创建顶层 Pool（例如 10.0.0.0/8），再按环境或区域划分二级 Pool，例如生产 10.10.0.0/16、非生产 10.20.0.0/16、共享服务 10.30.0.0/16。每个业务账号在申请 VPC 时，从对应 Pool 中分配一个 /16 或 /20 的 CIDR，而不是自行决定。这样做的价值在于：未来做 TGW 路由汇总、防火墙规则、跨账号对等连接时，不会因为地址重叠而返工。
子网划分则遵循“按用途分层”的原则。以生产 VPC 10.10.0.0/16 为例，可以划分为：公有子网 10.10.0.0/20（仅放 ALB/NAT 等边界组件）、应用私有子网 10.10.16.0/20、数据私有子网 10.10.32.0/20、TGW 附着子网 10.10.48.0/28。其中 TGW 附着子网只需极小网段，但必须与 TGW 所在账号的 VPC 关联。路由方面，业务 VPC 的路由表由业务账号维护，但指向 TGW 的路由、指向出口账号的路由，应由网络账号通过 RAM 共享 TGW 后统一编排，避免每个业务账号各自写默认路由导致黑洞。
路由编排的关键细节
集中式网络账号设计中最容易踩坑的是路由表关联与传播。TGW 默认不会自动让所有 VPC 互通，需要显式创建 TGW 路由表并做关联（Association）和传播（Propagation）。推荐做法是：为生产、非生产、共享服务分别建立独立的 TGW 路由表，生产 VPC 只关联生产路由表，非生产 VPC 只关联非生产路由表，共享服务路由表则被两者共同传播。这样生产与非生产之间天然隔离，而两者都能访问共享服务。
出口路径的编排需要特别注意非对称路由。业务 VPC 的默认路由指向 TGW，TGW 路由表中 0.0.0.0/0 指向出口账号的 VPC 附着。出口账号 VPC 内，NAT Gateway 所在的公有子网路由表将 0.0.0.0/0 指向 Internet Gateway。返回流量则沿原路径回程。如果出口账号同时存在多个 NAT Gateway 或防火墙端点，必须确保 TGW 路由表与出口 VPC 子网路由表使用同一可用区的附着，否则会出现跨 AZ 流量和额外费用。
实践建议：在正式投产前，用 aws ec2 describe-route-tables 和 TGW 路由表查询命令核对每条路由的下一跳。重点检查三类路由：业务 VPC 到 TGW 的默认路由、TGW 到出口 VPC 的默认路由、出口 VPC 到 IGW 的默认路由。任何一条缺失或指向错误，都会导致出站流量黑洞。
IPAM 与账号归属的落地方式
IPAM 的归属应放在网络账号，并通过 AWS RAM 将 IPAM Pool 共享给组织内的业务账号。业务账号在创建 VPC 时，选择“从 IPAM 分配 CIDR”，而不是手动输入。这样网络账号可以集中查看所有已分配网段、剩余容量和重叠情况。一个常见的教学示例是：网络账号创建 IPAM 后，先划分 10.0.0.0/8 顶层 Pool，再按区域创建 10.10.0.0/16（生产）、10.20.0.0/16（非生产）、10.30.0.0/16（共享服务）三个二级 Pool。业务账号 A 从生产 Pool 分配 10.10.0.0/16，业务账号 B 从非生产 Pool 分配 10.20.0.0/16。共享服务账号则从共享服务 Pool 分配 10.30.0.0/16，用于部署 AD 和 DNS Resolver。
需要提醒的是，IPAM 的分配一旦落地，后续修改 CIDR 的成本极高。因此在规划阶段就要预留足够的增长空间，例如每个业务账号至少预留一个 /16，而不是只按当前子网数量分配。对于未来可能合并的账号，也要在 Pool 层面预留连续网段，避免后期做路由汇总时出现断裂。
集中式网络账号的验收清单
| 检查项 | 归属账号 | 判断标准 |
|---|---|---|
| IPAM 顶层 Pool 与二级 Pool | 网络账号 | 所有业务 VPC CIDR 均从 IPAM 分配，无手动输入 |
| Transit Gateway 及路由表 | 网络账号 | 生产/非生产/共享服务路由表分离，关联与传播正确 |
| NAT Gateway 与出站路由 | 出口账号 | 业务 VPC 默认路由经 TGW 指向出口 VPC，回程对称 |
| 共享 DNS / AD / 日志端点 | 共享服务账号 | 业务 VPC 可通过 TGW 访问共享服务，且不暴露公网 |
| VPC 子网分层与 TGW 附着子网 | 业务账号 | 应用、数据、TGW 附着子网分离，附着子网不小于 /28 |
集中式网络账号设计不是一次性任务，而是随着组织规模演进的持续治理过程。初期可以只设网络枢纽账号和共享服务账号，出口能力合并进网络枢纽；当出站流量需要独立审计或独立计费时，再拆分出口账号。关键是保持“公共资源归网络账号、业务资源归业务账号、地址分配归 IPAM”这条主线不变，这样无论账号数量如何增长，路由和地址都不会失控。