8.7 VPC、子网、安全组

一句话

VPC 是你的逻辑数据中心：CIDR 一旦定下几乎改不了，子网决定 “能放下多少机器/IP”，安全组决定 “谁能进”，NACL 只做子网级粗筛；三者叠加才是真正的暴露面，而暴露面由最小的那一层决定。

先定 CIDR：这一步错了，后面全是补丁

决策	建议	代价
地址段	从 `10.0.0.0/8` 里切，一个环境一块（如 prod `/16`、staging `/16`）	一旦与办公网/其他 VPC 重叠，对等连接直接不可用
预留增长	至少留 4 倍余量（`/16` 有 65k 地址，够撑很久）	太小要重建 VPC = 迁移全部资源
跨环境隔离	prod / staging / dev 用不同网段	共网段会导致 “测试连到生产”
混合云	与 IDC 网段规划一起做	后期改 IDC 网段成本更高

现实中最贵的错误：VPC 用了 192.168.0.0/16，与公司办公网撞车，导致 VPN/专线永远连不通，只能全量重建。

子网：按 AZ 切，按用途分

类型	放什么	路由	说明
公有子网	负载均衡、NAT 网关、跳板机	`0.0.0.0/0 → IGW`	直接有公网路径
私有子网	应用、数据库、缓存	`0.0.0.0/0 → NAT GW`（或不通）	只能出、不能进
隔离子网	数据库（严格场景）	无默认路由	只允许同 VPC 内访问

两条容量纪律：

每个可用区至少一个子网，否则跨 AZ 高可用无从谈起（见 5.3 地域与可用区）。
单子网可用 IP 数 = 2^(32−掩码) − 保留地址（AWS 每个子网保留 5 个）。/28 只有 11 个可用 IP，跑几个 Pod 就耗尽——K8s 节点池的子网至少 /24。

安全组 vs NACL：一个有状态，一个无状态

维度	安全组（SG）	网络 ACL
作用对象	实例/ENI	子网
状态	有状态（回包自动放行）	无状态（回包要显式放行）
规则	只支持允许	允许 + 拒绝
评估	全部规则合并	按序号，命中即停
典型用途	精细的最小暴露	子网级粗筛（如整体封禁某段）

用安全组做精细控制，用 NACL 做兜底，反过来会很痛苦：NACL 无状态，一旦忘记放行高位端口回包，就会出现 “单向通” 的诡异现象。

分层放行：引用安全组，而不是 CIDR

Internet → LB(443) → app(8080, 仅来自 LB 的 SG) → db(5432, 仅来自 app 的 SG)

写法	好处	坏处
`sg-app` 允许来自 `sg-lb` 的 8080	机器扩容自动生效，不写死 IP	需要标签/命名规范
`sg-app` 允许来自 `10.0.1.0/24` 的 8080	直观	子网一变就失效，且范围过大
`sg-db` 允许 `0.0.0.0/0:5432`	“先跑通”	数据库直接暴露公网，最常见的入侵入口

入口层的四层/七层选型（LB 放在哪、是否终结 TLS）见 8.9 四层与七层负载均衡。

连通性排查顺序

现象	查什么	命令/位置
同 VPC 不同子网不通	路由表是否有本地路由、NACL 是否拦截	子网关联的路由表 / NACL 规则
出公网不通	私有子网是否有 NAT 路由、NAT GW 是否在可用 AZ	路由表 `0.0.0.0/0` 指向
入站不通	安全组入站规则、目标端口是否监听	`ss -lntp`、SG inbound
跨 VPC 不通	对等连接是否建立、两边路由是否回指、CIDR 是否重叠	Peering 状态 + 双向路由
偶发超时	安全组规则数量过多（部分实现按包匹配）、连接跟踪表满	SG 数量、conntrack（见 8.8 NAT 与端口映射）

反模式

反模式	后果
VPC CIDR 与办公网/IDC 重叠	专线、VPN、对等连接全部不可用，只能重建
所有资源放公有子网	每台机器都需要公网 IP，暴露面放大且成本更高
数据库安全组开 `0.0.0.0/0`	被扫描后直接爆破，最常见的数据泄露路径
用 NACL 做精细规则	无状态导致回包被拦，排障成本极高
子网用 `/28`	IP 耗尽，扩容时才发现
网状 VPC 对等（N² 连接）	连接数爆炸、路由难维护；应改 hub-spoke 或中转网关
安全组按 CIDR 写死应用地址	扩容/换网段即失效，最终没人敢改

三条铁律

🔑 CIDR 先规划再创建；重叠的 VPC 无法 “改一下”，只能重建。

🔑 私有子网 + NAT 出网是默认形态；给业务机器公网 IP 是例外，不是常态。

🔑 安全组引用安全组，把 “谁能访问我” 表达成服务关系，而不是 IP 段。

自检

Q1 新 VPC 与办公网都是 192.168.0.0/16，会有什么后果？

▸ 答案：私有地址冲突：同一条 VPN/专线上，两个相同网段的路由无法区分，对等连接也无法建立（云厂商直接拒绝重叠 CIDR 的 peering）。后果是 “办公网访问不了云上资源”，且无法通过改路由解决，只能重建 VPC 或重建办公网。这就是 “CIDR 必须先规划” 的原因——它几乎是唯一不可逆的网络决策。

Q2 为什么说 “安全组有状态、NACL 无状态” 会直接影响排障？

▸ 答案：安全组会自动放行已建立连接的回包，所以只需配 “入站 443” 就能双向通；NACL 不记状态，回程的高位端口必须显式放行，否则出现 “SYN 到了、回包被丢” 的单向不通。排障时如果只看 NACL 的入站规则，会漏掉出站临时端口——这是 “NACL 配了却不通” 的典型原因。

Q3 私有子网的机器要访问公网（拉镜像、调外部 API），需要什么？

▸ 答案：需要 NAT 网关 + 路由：私有子网路由表 0.0.0.0/0 指向 NAT GW，NAT GW 放在公有子网并绑定 EIP。两个坑：① NAT GW 是按可用区的，跨 AZ 部署的私有子网要各自有 NAT（否则单 AZ 故障就断网）；② NAT 只允许出向，外部无法主动连入——需要入向就加 LB，不要给机器绑公网 IP。

Q4 安全组规则写成 “允许 10.0.0.0/8 访问 3306”，有什么问题？

▸ 答案：范围过大，等于整个内网（含所有环境、所有租户）都能连数据库；一旦某台测试机被攻陷，数据库就在射程内。正确写法是 “允许来自 sg-app 的 3306”，把范围收窄到 “服务关系” 而不是 “网段”。这也是零信任的起点：默认拒绝，按身份（SG/标签）放行。

Q5 两个 VPC 要互通，选择对等连接还是中转网关？

▸ 答案：少量且稳定（2–3 个）用对等连接，简单、低延迟、无额外费用；规模上去（>5 个 VPC 或需要与 IDC 互联）用 hub-spoke + 中转网关，否则 N² 的对等连接会让路由与安全策略无法维护。判断依据是 “连接数增长时，配置量是线性还是平方”，以及 “是否需要对流量做集中审计”。

下游：13.3 网络隔离与最小暴露面