为什么需要一份可执行的VPC规划手册？
在一个真实迁移项目中，客户将原有/16的本地网络直接搬到了阿里云VPC，结果半年后容器化扩容时发现可用IP不足，不得不重建VPC并重新割接所有资源。这类事故的根源是：大多数团队只关注功能可用性，忽略了IP容量、路由收敛和故障域隔离的长远影响。
本文假设你同时面对AWS和阿里云两种环境（或需要迁移/混合使用），给出适用于两个平台但需注意差异点的规划方法。所有步骤都包含风险提示和可逆操作建议。
一、VPC IP地址范围设计：从预算开始反推
1.1 核心决策：选多大CIDR？
适用环境：新规划VPC，或已有VPC需要扩容（注意AWS无法修改VPC主CIDR，阿里云可以附加辅助CIDR但有限制）。
- 最小化原则：尽量使用/16及以下（例如/16），但预留未来扩展空间。
- 避免冲突：必须与本地网络、其他VPC、对等连接网络的CIDR完全不重叠。建议从RFC 1918地址池中选取一个从未用过的网段，例如/8中划分。
- 多VPC场景：使用独立的大段，例如总部用/16，开发用/16，生产用/16，且各段互不重叠。
风险警示：用/24或更小网段创建VPC，后续几乎一定会因不够用而重建。某创业公司将生产VPC设为/28，一年后因微服务数暴涨被迫手工迁移1000+个实例。
验证方法：创建VPC后立即用网络评估工具（如AWS IPAM或阿里云网络规划工具）扫描冲突，而非等到业务上线。
1.2 阿里云 vs AWS的差异
| 特性 | AWS | 阿里云 |
|---|---|---|
| 主CIDR修改 | 不可修改，只能删除重建 | 可附加辅助CIDR（上限5个） |
| IPv6支持 | 可附加/56 IPv6 CIDR | 需额外开通IPv6网关 |
| 专线网段限制 | 无特殊限制 | 需在云企业网中规划，避免路由黑洞 |
二、子网划分：AZ、可用区与故障域
2.1 子网大小与数量
每个子网建议至少/24（251个可用地址），避免未来因微服务拆分而频繁新建子网。对于容器集群（如K8s），每个Node可能需要消耗多个IP，因此建议使用/20甚至/16子网。
子网数量规划：
- 每个可用区至少创建一个公有子网（挂载互联网网关）和一个私有子网（无公网直连）。
- 如果使用NAT网关（共享出口），私有子网需要在路由表中指向NAT网关。阿里云建议每个可用区独立NAT网关以提升容灾。
- 预留10%的地址空间用于未知需求（例如未来新增可用区或隔离网络）。
2.2 子网划分示例
假设使用/16 VPC，目标3个可用区（us-east-1a, 1b, 1c）：
可用区A: 公有 /24, 私有 /20
可用区B: 公有 /24, 私有 /20
可用区C: 公有 /24, 私有 /20
预留: /24 (用于未来NAT网关或端点)这样每个私有子网有4096个地址，足以应对单可用区100+实例的容器集群。
三、路由与安全控制：ACL vs 安全组
3.1 路由表设计规则
原则：每个子网一张自定义路由表，不给VPC默认路由表添加额外路由（避免误影响其他子网）。
- 公有子网路由：0.0/0 -> Internet Gateway (AWS) 或 NAT网关（阿里云使用公网NAT网关）。
- 私有子网路由：0.0/0 -> NAT Gateway（出口用）或直接内网互联。
- T形路由：若需通过VPN或专线去本地，所有流量指向专线网关/虚拟网关。
风险点：不要为私有子网同时配置指向IGW和NAT的路由，会导致路由冲突。AWS会以最长前缀匹配，但阿里云可能产生非对称流。
3.2 ACL与安全组使用场景
安全组（有状态）：适合实例级别细粒度控制，限制特定端口和源IP。
网络ACL（无状态）：适合子网级别边界防护，限制已知恶意IP段或强制禁止非核心协议。
最佳实践：
- 子网ACL只做粗颗粒度黑名单（例如拒绝来自特定国家的IP或非业务端口）。
- 安全组做白名单：最小权限，仅允许业务依赖的端口（如HTTP 443, 数据库3306仅限特定安全组）。
- 两者规则数量不要接近平台上限（AWS VPC ACL 20条/每个ACL，阿里云100条）。
四、混合云与多VPC互联
4.1 专线/VPN接入
若需连接本地数据中心：
- SLA要求高的场景用专线，带宽保障且延迟稳定；补丁场景用IPsec VPN。
- 阿里云使用云企业网（CEN）或VPN网关；AWS使用Transit Gateway (TGW)或Direct Connect。
- 关键参数：BGP AS号、路由过滤、MTU设置。阿里云默认MTU 1500，如需巨帧需额外配置。
回滚方案：先建立测试隧道，确认路由不冲突再切换生产。若发现冲突，立即禁用BGP并删除路由。
4.2 多VPC互通策略
推荐使用中心化网络架构：
- 创建共享服务VPC（部署NAT、防火墙、监控），其他VPC通过Transit Gateway或云企业网连接。
- 避免VPC直接对等连接（Peering）过多导致的“网状网络”难以维护。
- AWS TGW默认最多关联5000个VPC；阿里云CEN单地域默认支持30个VPC，可申请提升。
五、验证、监控与持续优化
5.1 上线前的检查清单
- 每个子网的可用IP数是否大于预期实例数 + 预留20%？
- 所有私有子网是否有正确的NAT路由？
- 安全组是否默认拒绝所有入站，只放行必要端口？
- 是否关闭了VPC的DNS解析（若需自定义DNS）？AWS默认启用，阿里云需手动开启。
5.2 持续监控工具
- VPC Flow Logs (AWS) 或流日志（阿里云）：记录流量并分析异常访问。
- IP地址使用率告警：当子网利用率超过80%时自动告警，提前规划新子网。
- 路由表变更审计：使用AWS Config或阿里云配置审计跟踪路由变化。
总结：可执行的最佳实践清单
- VPC CIDR：/16起步，预留扩展位，不与任何已存网络冲突。
- 子网：每个可用区至少2个子网（公有+私有），大小/24或/20，预留10%地址。
- 路由：每子网独立路由表，公有子网指向IGW，私有子网指向NAT或专线。
- 安全：ACL做粗粒度的黑名单，安全组做精细的白名单，遵循最小权限。
- 互联：使用中心化网关（TGW/CEN），避免对等连接风暴。
- 验证：使用平台内置工具扫描冲突，建立变更审批流程。
- 回滚：所有操作尽量通过基础设施即代码（Terraform）管理，方便快速重建。
无论你选择AWS还是阿里云，以上框架均适用。唯一需要调整的是各自控制台入口和API差异，但底层原则完全一致：容量预留、故障隔离、路由清晰、安全分层。
延伸阅读