云上子网为什么要先减 5
公有云的虚拟子网并非所有地址都能分配给实例：AWS 与 Azure 每个子网固定保留 5 个地址，用于网络地址、网关、DNS 以及广播等用途。规划时如果按传统算法计算容量，实际可用数会比预期少 5 个，小尺寸子网尤其容易踩坑——一个 /29 在云上只剩 3 个地址可用，连起 4 台实例都不够。
基本信息
| AWS 保留 | 每子网 5 个：网络地址、VPC 路由器、DNS、预留、广播 |
|---|---|
| Azure 保留 | 每子网 5 个：网络地址、默认网关、两个 DNS、广播 |
| GCP 保留 | 每子网 4 个：网络地址、默认网关、倒数第二个、广播 |
| 估算公式 | 云上可用地址数约为 2^n 减 5 |
| 影响最大 | 小尺寸子网，/29 在云上只剩 3 个可用 |
| 规划原则 | 跨云项目以各厂商官方文档为准，不套用同一公式 |
AWS /24 子网占用示意
AWS /24 子网占用示意
10.0.1.0 网络地址（保留）
10.0.1.1 VPC 路由器（保留）
10.0.1.2 DNS（保留）
10.0.1.3 预留（未来使用）
10.0.1.255 广播（保留）
可用：10.0.1.4 - 10.0.1.254，共 251 个常见子网的实际可用量
| 子网 | 传统可用数 | 云上可用数 |
|---|---|---|
| /29 | 6 | 3 |
| /28 | 14 | 11 |
| /27 | 30 | 27 |
| /26 | 62 | 59 |
| /24 | 254 | 251 |
典型使用场景
- 规划云端子网尺寸时先扣除保留地址，避免上线后地址不足
- 跨云迁移项目分别按各厂商规则计算容量，不能沿用同一公式
- 容器与负载均衡占用的地址也要计入，云上按实例数估算往往偏乐观
- 设计高可用部署时每个可用区至少一个子网，容量需按区独立计算
- 核对账单与配额时确认子网地址是否真的用尽，有时是保留地址占位造成的错觉
规划建议
- 优先选择 /24 或更大的子网，云上额外保留的 5 个地址占比更低，规划弹性更好
- 预留至少一个额外子网作为扩容位，避免实例增长时只能重建子网
- 把子网地址规划与路由表设计同步进行，云上路由表与子网是独立配置项
- 在部署脚本中记录每个子网的可用地址区间，自动化分配时直接引用
- 跨云环境为不同厂商建立各自的容量计算表，避免混用导致容量误判
不同厂商保留规则不同，除 AWS 与 Azure 各保留 5 个外，GCP 保留 4 个；跨云项目务必以各厂商官方文档为准，不要套用同一公式。