阿里云认证账号 阿里云虚拟私有云VPC规划

别急着点‘创建VPC’——先让脑子跑一遍网络拓扑

很多同学打开阿里云控制台，手指悬在‘创建VPC’按钮上，深吸一口气，输入‘192.168.0.0/16’，点击确认，然后……世界安静了。三天后，开发问：‘测试环境连不上数据库？’运维吼：‘安全组没开3306！’DBA默默重启了RDS实例——而没人想起，当初那个VPC，连子网都建在同一个可用区里。

VPC不是云上画个圈就完事的魔法结界，它是你整个云架构的骨架。骨架歪了，肌肉（ECS）、神经（SLB）、血液（数据流）全跟着抽搐。所以，规划VPC，本质是在写一份《未来三年云上生存说明书》。

第一步：地域和可用区——别把鸡蛋装进隔壁省的篮子

选地域，不是看离你家近不近，而是看你的用户在哪、合规要求在哪、上下游服务在哪。杭州地域支持金融云专区，北京地域有政务云通道，新加坡地域出海延迟低——但请注意：VPC不能跨地域迁移。今天选了上海，明天想挪到深圳？抱歉，得重建+数据迁移+DNS切流+业务停机，不是点两下鼠标的事。

阿里云认证账号 可用区（AZ）才是真·生死线。同一地域下，AZ之间物理隔离、电力独立、网络低延（通常<2ms）。一个VPC可以跨多个AZ，但子网（vSwitch）必须绑定单个AZ。所以，高可用架构的底线是：至少两个AZ，每个AZ部署一套核心子网（如web、app、db），再配好跨AZ的SLB和RDS多可用区实例。别信‘我只用一个AZ，省钱又省心’——去年某公司因单AZ电力故障宕机47分钟，CEO在复盘会上说：‘省下的那三千块，够买半瓶速效救心丸了。’

第二步：网段设计——172.16.0.0/12不是免死金牌

官方推荐10.0.0.0/8、172.16.0.0/12、192.168.0.0/16，但现实很骨感：

• 192.168.0.0/16：家用路由器最爱，也是企业内网高频撞车区。当你需要通过VPN或高速通道对接本地IDC时，大概率发现：‘咦？两边都是192.168.10.0/24，IP打架了。’
• 10.0.0.0/8：空间巨大，但部分老旧设备或中间件（比如某些版本的Kubernetes CNI插件）对超大网段兼容性存疑，且易与内部测试网冲突。
• 172.16.0.0/12：表面看最稳妥，但注意——它包含172.16.0.0/16到172.31.0.0/16共16个/16网段。如果你规划粗放，全用172.16.0.0/16，等于把16个‘小区’全塞进一个门牌号，后续扩容只能撕开重划，痛苦指数拉满。

实战建议：按业务域+环境分层切网段。例如：
• 生产VPC：172.20.0.0/16（预留172.21~29给未来VPC）
• 预发VPC：172.30.0.0/16
• 研发VPC：172.31.0.0/16
每个VPC内，再按子网角色划分：web层用/24（如172.20.10.0/24），app层用/24（172.20.20.0/24），db层用/25（172.20.30.0/25，留一半给灾备）。别怕‘浪费’，IPv4地址在云上不收钱，规划混乱导致的排障时间才真烧钱。

第三步：子网（vSwitch）——不是越多越好，是‘刚够用’最好

一个vSwitch=一个AZ里的二层广播域。关键原则：
• 用途隔离：web、app、db、管理、容器节点绝不混在一个子网；
• 规模可控：单个子网建议≤256台ECS（/24），超大集群用多个子网+相同路由策略；
• 弹性预留：哪怕当前只用10台机器，也别建/28（仅14个可用IP），/24起步，避免后期扩容时‘改子网CIDR’——这操作要停机。

特别提醒：NAT网关、SLB、ALB等云产品，会自动在所选子网分配ENI（弹性网卡）。如果你给NAT网关选了/27子网（仅26个可用IP），它可能抢光IP，导致新ECS无法分配内网地址。血泪教训：给承载云服务的子网，额外多留32个IP。

第四步：路由表——别让流量迷路，更别让它乱窜

默认路由表只有一条：本地路由（目标网段=VPC CIDR，下一跳=local）。所有新增路由，务必遵循‘最小权限’：

• 去公网：加一条0.0.0.0/0 → NAT网关（私网出网）或Internet网关（ECS绑EIP直连）。记住：NAT网关需部署在专用子网（建议/27），且该子网路由表要明确指向NAT网关，其他子网才能借道上网。
• 去IDC：加一条IDC网段 → VPN网关或高速通道。别忘了在IDC侧也配反向路由！
• 去其他VPC：加一条对方VPC CIDR → 对等连接（Peering）或云企业网（CEN）。重点来了：对等连接是单向的！A→B通了，B→A不一定通，双方路由表都要加。

终极检查法：挑一台ECS，用ip route get X.X.X.X看实际走哪条路由。比背文档管用十倍。

第五步：安全组——不是防火墙，是ECS的贴身保镖

安全组是‘入方向白名单+出方向全通’（默认），但很多人误以为它能替代ACL。错！安全组作用于ECS实例粒度，ACL作用于子网粒度，两者叠加生效。典型误区：

• ‘我开了安全组80端口，为啥还是打不开？’→ 检查ECS系统防火墙（iptables/ufw）是否拦截；
• ‘我把所有ECS都放一个安全组，方便管理’→ 一旦某台机器被黑，攻击者可横向移动到同组所有机器；
• ‘我用了最小化端口，但监控平台连不上’→ 忘了Zabbix/ Prometheus采集端口、云监控Agent上报端口也要放行。

黄金法则：按角色建安全组（如‘Web-HTTP-HTTPS’、‘DB-MySQL’），按最小端口+最小源IP授权（如只允应用子网访问DB端口），定期用云安全中心扫描冗余规则。

最后送你一张‘避坑清单’

• 别用169.254.x.x网段——这是阿里云元数据服务保留地址，冲突必跪；
• VPC删除前，务必清空所有关联资源（ECS、SLB、RDS、NAT网关…），否则删一半卡住；
• 跨VPC通信，优先选云企业网（CEN），对等连接（Peering）适合临时测试，不支持传递路由；
• 开启VPC流日志前，先评估存储成本——每GB约¥0.12，高频业务慎开；
• 所有规划文档，存Git，打Tag，写清楚‘谁、何时、为何修改了172.20.50.0/24子网掩码’——下次救火时，你会感谢当年那个较真的自己。

VPC规划没有标准答案，只有适配你业务节奏的最优解。它不酷炫，不性感，但当凌晨三点告警炸响时，一个清爽的VPC结构，就是你咖啡续命后，第一个能笑着敲出ping命令的理由。