一、VPC规划：私网的"地基"，错了就全错了
VPC（虚拟私有云）是你在云上的专属网络空间，相当于你自己的"内城"。VPC规划的第一步，不是画子网，而是想清楚你要几座城、城和城之间怎么隔开。
1.1 单VPC还是多VPC？
| 方案 | 适用场景 | 优缺点 |
|---|---|---|
| 单VPC + 多子网隔离 | 中小型企业，业务线不超过3条 | 管理简单，但隔离性依赖安全组，出了问题影响面大 |
| 多VPC互通 | 大型企业，多业务线/多环境/多部门 | 隔离性强，但需要配置对等连接，复杂度高 |
| 混合方案（推荐） | 大多数企业 | 核心业务用独立VPC，非核心业务共用VPC，通过云企业网互通 |
我的建议是：生产环境必须独立VPC，测试环境和开发环境可以共用一个VPC但用子网隔开。
某金融科技公司的做法是：核心交易系统一个VPC，风控系统一个VPC，办公系统一个VPC，三个VPC通过云企业网互通，但默认不通，需要显式授权才能通信。等保测评一次通过，零扣分。
1.2 CIDR块怎么选？
VPC创建时需要指定一个CIDR块（私有地址段），比如10.0.0.0/16。这个选错了，后面全是坑。
| CIDR块 | 可用IP数 | 适用规模 | 风险 |
|---|---|---|---|
| 10.0.0.0/16 | 65534 | 中大型企业 | 最常用，与大多数内网不冲突 |
| 172.16.0.0/12 | 1048574 | 超大型企业 | 够大但容易与Docker默认网段冲突 |
| 192.168.0.0/16 | 65534 | 小型企业 | 容易与家庭路由、办公网冲突，慎用 |
铁律：永远不要用192.168.x.x作为VPC CIDR，除非你确定不会和任何本地网络互通。 一旦地址冲突，排查起来能让你怀疑人生。
二、子网划分：把"内城"分成"功能区"
VPC是城，子网就是城里的"区"。生产区、测试区、数据区、管理区——每个区有自己的地址范围和访问规则。
2.1 子网划分的黄金法则
| 原则 | 说明 |
|---|---|
| 一个业务一个子网 | 不要把Web服务器和数据库塞在同一个子网里 |
| 按环境隔离 | 生产、预发、测试、开发，至少分4个子网 |
| 按功能隔离 | 前端区、后端区、数据区、运维区，各占一个子网 |
| 预留扩展空间 | 每个子网至少预留30%的IP余量，别把CIDR用满 |
2.2 实战划分方案（以中型企业为例）
| 子网名称 | CIDR | 用途 | 可用IP数 |
|---|---|---|---|
| prod-web | 10.0.1.0/24 | 生产环境Web服务器 | 251 |
| prod-app | 10.0.2.0/24 | 生产环境应用服务器 | 251 |
| prod-db | 10.0.3.0/24 | 生产环境数据库 | 251 |
| test-web | 10.0.10.0/24 | 测试环境Web服务器 | 251 |
| test-app | 10.0.11.0/24 | 测试环境应用服务器 | 251 |
| mgmt | 10.0.100.0/24 | 运维管理区（堡垒机、监控） | 251 |
关键：生产子网和测试子网的CIDR不能相邻。 很多人图省事把测试网放在10.0.10.0/24，生产放在10.0.1.0/24——中间差了好几个段，路由表写起来麻烦不说，万一配错规则，测试网直接能访问生产库。
2.3 可用区（AZ）与子网的关系
每个子网必须绑定一个可用区（AZ）。高可用架构要求：同一业务的子网必须跨至少两个AZ。
比如：prod-web子网绑定AZ-A，同时在AZ-B再建一个prod-web-2子网，负载均衡把流量分到两个AZ——一个AZ挂了，另一个自动接管。
三、路由表：私网的"交通规则"
子网建好了，默认情况下，同一个VPC内的所有子网是互通的。这意味着你的测试环境可以直接访问生产数据库——这是灾难的开始。
路由表就是用来控制"谁能跟谁说话"的。
3.1 默认路由表 vs 自定义路由表
| 类型 | 作用 | 适用场景 |
|---|---|---|
| 默认路由表 | VPC创建时自动生成，所有子网默认关联 | 不要改默认路由表，用它管"出公网"的流量 |
| 自定义路由表 | 手动创建，按需关联子网 | 用它管"内网隔离"——哪个子网能访问哪个子网 |
3.2 三张表打天下
| 路由表名称 | 关联子网 | 规则 |
|---|---|---|
| rt-public | 所有需要出公网的子网（如prod-web） | 默认路由指向NAT网关/弹性IP |
| rt-prod | prod-web、prod-app | 允许prod-web访问prod-app的3306端口，拒绝其他一切 |
| rt-isolate | test-web、test-app | 只允许test-web访问test-app，禁止访问任何prod开头的子网 |
核心思路：生产环境的路由表只允许必要的通信，其他全部拒绝。测试环境的路由表完全隔离生产。
某电商平台就是靠这套路由表策略，在一次内网渗透测试中，攻击者从测试环境拿到了一台主机的权限，但因为路由表隔离，无法访问生产数据库——攻击链在第一步就被掐断了。
3.3 路由表的优先级
当一个子网关联了多张路由表时，系统按自定义路由表优先于默认路由表的原则匹配。所以：
- 需要出公网的子网：关联rt-public + 默认路由表
- 需要严格隔离的子网：只关联rt-isolate，不关联默认路由表
四、安全组：主机级别的"门禁系统"
如果说路由表是"区与区之间的关卡"，那安全组就是"每台主机的门禁"。路由表管的是"能不能到这个区"，安全组管的是"能不能进这台机器"。
4.1 安全组的核心原则
| 原则 | 说明 | 反面教材 |
|---|---|---|
| 最小权限 | 只开放业务必需的端口 | 一台Web服务器开放了22、3389、80、443、3306、6379…… |
| 白名单机制 | 只允许特定IP/安全组访问 | 0.0.0.0/0开放22端口，等于把门敞开 |
| 分层设计 | Web层、应用层、数据层各有自己的安全组 | 所有主机用同一个安全组 |
| 默认拒绝 | 入站规则默认拒绝所有，只添加允许的 | 默认允许所有，再手动加拒绝——容易漏 |
4.2 四层安全组架构（生产环境推荐）
| 层级 | 安全组名称 | 入站规则 | 出站规则 |
|---|---|---|---|
| Web层 | sg-prod-web | 允许负载均衡的安全组访问80/443 | 允许访问应用层的8080端口 |
| 应用层 | sg-prod-app | 只允许Web层访问8080端口 | 允许访问数据层的3306端口 |
| 数据层 | sg-prod-db | 只允许应用层访问3306端口 | 不允许出站（或只允许到备份服务的端口） |
| 运维层 | sg-mgmt | 只允许堡垒机IP访问22端口 | 允许访问所有内网（用于运维） |
关键：数据层的安全组，入站规则只允许应用层的安全组访问，不允许任何其他来源。 即使攻击者拿到了Web层的权限，也碰不到数据库。
4.3 安全组 vs 网络ACL：别搞混了
| 维度 | 安全组 | 网络ACL |
|---|---|---|
| 作用范围 | 主机级别 | 子网级别 |
| 规则类型 | 允许（白名单） | 允许 + 拒绝（黑白名单） |
| 状态 | 有状态（回包自动放行） | 无状态（回包需单独配置） |
| 优先级 | 先判断 | 后判断 |
最佳实践：安全组做精细控制（白名单），网络ACL做粗粒度兜底（黑名单）。 比如安全组允许Web访问App，ACL拒绝测试网访问生产网——双保险。
五、实战 checklist：上线前逐条对照
| 检查项 | 状态 |
|---|---|
| VPC CIDR与本地网络不冲突 | ☐ |
| 生产环境独立VPC | ☐ |
| 每个业务至少一个独立子网 | ☐ |
| 生产/测试子网CIDR不相邻 | ☐ |
| 跨AZ部署高可用架构 | ☐ |
| 自定义路由表隔离生产与测试 | ☐ |
| 数据库安全组只允许应用层访问 | ☐ |
| 没有0.0.0.0/0开放22/3389 | ☐ |
| 运维只能通过堡垒机访问 | ☐ |
| 网络ACL配置了黑名单兜底 | ☐ |
| 弹性IP不用时已解绑 | ☐ |
| 僵尸子网已清理 | ☐ |
六、写在最后：私网规划不是一次性的，是持续性的
很多团队上线前认真规划了一周，上线后就再也没管过。三个月后，测试环境和子网合并了，安全组规则越加越多，路由表变成了一团乱麻——等到出事的时候，没人说得清内网到底长什么样。
私网规划是活的，它必须跟着业务一起成长。
每新增一条业务线，先画子网图；每开一个端口，先过安全组评审；每改一条路由，先想清楚影响面。
你写的代码跑在云上，云上的网络就是你的"地基"。地基打不好，楼盖得再高也是危楼。
私网不是运维的事，是每个开发工程师都该懂的事。因为你的代码，就跑在这张网上。
现在就打开控制台，对照上面的checklist，逐条检查你的私网。如果有一项没打勾——那就是你下一个事故的隐患。
