VPC 子网这样划才不踩坑：新手常犯的 5 个错误

很多新手第一次创建 VPC，第一反应是先建一个 10.0.0.0/16 的大网段，把所有云服务器和数据库都塞进去。刚开始确实省事，可用了一段时间就会发现：想隔离生产和测试环境时拆不动，扩容时 IP 不够用，数据库离公网太近，出了故障也不知道先查哪一层。本文结合实际操作，把新手最常犯的 5 个错误讲清楚，每个都给出能直接照着做的做法。

错误一：只留一个大网段，后期想隔离时拆不动

一个子网里同时跑生产、测试和数据库，等于把不同安全等级的资源放在同一个广播域里。测试环境的一次误操作可能影响生产，数据库也没有独立的访问控制边界。等业务跑起来再拆，涉及改 IP、改安全组、改应用配置，停机窗口和风险都很大。

做法是一开始就按“环境 + 用途”拆分子网。例如在 10.0.0.0/16 这个 VPC 下这样规划：生产子网 10.0.1.0/24，测试子网 10.0.2.0/24，数据库子网 10.0.3.0/24。每个子网各有 256 个地址，职责清晰，以后给数据库子网单独收紧策略，也不会影响应用子网。规划时把网段写进一张表里，注明每个子网的用途、负责人和预计规模，再动手创建。

错误二：子网 CIDR 划得太小，扩容时 IP 不够用

子网一旦创建，CIDR 就不好随意改大。/28 的子网一共只有 16 个地址，扣掉网络地址、广播地址和云平台预留的地址，可用地址只有 11 个。放几台云服务器、几个负载均衡节点和预留地址后，很快就满了，新增实例会直接报 IP 不足。

估算方法是“当前实例数 × 2 再留余量”。例如现在有 20 台实例，短期要扩到 40 台，就按 80 个地址以上来规划，/24 的 256 个地址比较稳妥；如果还要留给容器节点、函数计算弹性 IP 预留，宁可再放大一档。记住：子网划大一点的成本很低，划小了再迁移的成本很高。

错误三：把数据库放进能直接访问公网的子网

数据库不需要、也不应该直接访问公网。给数据库子网绑定弹性 IP 或者配了指向公网的 NAT，一旦数据库口令泄露或出现漏洞，攻击者就多了一条直达路径。正确的做法是让数据库子网保持“私有”：不绑弹性 IP，不配出方向的 NAT，只允许应用子网的安全组访问数据库端口。

例如 MySQL 只放通应用子网的安全组访问 3306 端口，其他来源一律拒绝。应用服务器需要访问外网下载依赖时，走应用子网自己的 NAT，而不是让数据库子网也跟着出公网。定期检查一次：数据库实例有没有弹性 IP，数据库子网的路由表里有没有指向 NAT 网关或互联网网关的默认路由，有就立即清理。

错误四：路由表配错导致跨子网不通

两个子网都在同一个 VPC 里，理论上默认就能互通。如果跨子网 ping 不通，很多人第一反应是重启实例，其实问题大多出在路由表、网络 ACL 或安全组这三层中的一层。

排查要分层做。先看路由表：确认目的子网的路由指向本地 VPC，而不是被一条错误的自定义路由带走了。再看网络 ACL：子网级 ACL 是无状态的，出方向放通了，入方向也要放通回包。然后看安全组：实例级安全组要放通对端子网的来源。定位时用命令辅助判断：

ping 10.0.2.10
traceroute 10.0.2.10

ping 不通但 traceroute 在某一跳停住，往往是中间那层的 ACL 或路由问题；连第一跳都没有，多半是本机路由或安全组出方向被拦住了。一次只改一处，改完再测，这样才能确定是哪一层的问题。

错误五：安全组图省事放通 0.0.0.0/0

新建安全组时把入方向写成 0.0.0.0/0 确实能立刻连通，但等于把端口暴露给全网扫描。22 端口一旦放通全网，暴力破解的尝试很快就会出现；数据库端口和管理后台端口更不能这样放。

按最小权限原则，只放通业务真正需要的端口和来源。例如 Web 服务只放通 80 和 443 端口，来源可以放宽；SSH 的 22 端口只放通自己的办公出口 IP 或跳板机所在的安全组；数据库端口只放通应用子网的安全组。没有把握时先收紧，再根据业务报错逐步放开，而不是先放开再收。

小结

子网划分不是一次性填几个数字，而是一份网络拓扑设计：先按环境和用途拆网段，按“当前实例数 × 2 再留余量”定大小，数据库子网坚持私有，路由、安全组和网络 ACL 分层排查，安全组坚持最小权限。把这 5 点做对，后面扩容、隔离和排障都会轻松很多。