3、网络规划：VPC设计、子网划分、安全组规则、NAT网关配置

网络规划这件事，说白了就是给数据库搭一个「安全屋」。我见过太多项目，数据库性能没问题，结果网络层面出了幺蛾子——要么被攻击，要么连不上，要么带宽打满。嗯，今天咱们就把这块彻底聊透。

3.1 VPC设计：你的数据库专属领地

VPC（虚拟私有云）就像你在云上圈的一块地。我个人习惯，每个环境（开发、测试、生产）都建独立的VPC。为什么？因为隔离性最好，万一测试环境搞炸了，不会波及生产。

举个例子，我去年帮一家金融客户做架构，他们一开始把所有系统塞进同一个VPC。结果有一次运维误操作，把生产库的安全组规则删了，整个支付系统挂了20分钟。后来我强制要求：生产VPC、测试VPC、开发VPC，物理隔离。从此再没出过类似问题。

3.2 子网划分：公有与私有的艺术

子网划分，我建议遵循「三层架构」：

• 公有子网：放负载均衡、堡垒机、NAT网关。这些需要对外暴露。
• 私有子网：放数据库。绝对不分配公网IP。
• 管理子网：放运维工具、监控系统。只允许内部访问。

你想想看，数据库直接暴露在公网上，等于把家门钥匙挂门口。我曾经遇到一个客户，图省事给RDS绑了公网IP，结果三天后被扫到，数据库被勒索病毒加密。嗯，这个教训够深刻。

具体到IP段规划，我一般这样分：

子网类型	CIDR段	用途
公有子网-A	10.0.1.0/24	负载均衡、NAT网关
公有子网-B	10.0.2.0/24	堡垒机、跳板机
私有子网-A	10.0.10.0/24	主数据库（RDS/自建）
私有子网-B	10.0.11.0/24	从数据库/只读副本
管理子网	10.0.20.0/24	监控、备份、运维工具

3.3 安全组规则：最小权限原则

安全组是数据库的第一道防线。我见过最离谱的配置：安全组规则里写0.0.0.0/0，端口全开。这跟没穿衣服上街有什么区别？

我的做法是：

• 数据库端口：只允许应用服务器的私有IP段访问。比如MySQL的3306端口，只放行10.0.10.0/24。
• 管理端口：只允许堡垒机的IP访问SSH（22端口）。
• 禁止公网访问：数据库所在子网的安全组，入方向拒绝所有0.0.0.0/0。

举个例子，一个典型的安全组规则长这样：

# 数据库安全组规则示例
入方向：
  - 协议: TCP
    端口: 3306
    源: 10.0.10.0/24 (应用服务器子网)
    描述: 允许应用访问MySQL

  - 协议: TCP
    端口: 22
    源: 10.0.2.0/24 (堡垒机子网)
    描述: 允许运维管理

出方向：
  - 协议: ALL
    端口: ALL
    目的: 0.0.0.0/0
    描述: 允许数据库访问外部（如备份到OSS）

3.4 NAT网关配置：让私有子网访问外网

数据库放在私有子网里，怎么访问外网？比如下载补丁、同步时间、备份到对象存储。这时候就需要NAT网关。

NAT网关的作用很简单：给私有子网里的机器提供「单向」的公网访问能力。外网不能主动连进来，但里面可以出去。

我建议这样配置：

• NAT网关放在公有子网：它需要公网IP，所以必须放在公有子网。
• 路由表指向NAT：私有子网的路由表里，添加一条默认路由（0.0.0.0/0），下一跳指向NAT网关。
• 高可用：如果预算允许，部署两个NAT网关在不同可用区，避免单点故障。

你想想看，如果NAT网关挂了，私有子网里的数据库就彻底断网了。虽然不影响数据库本身运行，但备份、监控、日志上传都会停摆。所以高可用很重要。

3.5 整体架构图

下面这张图，是我做数据库网络规划时常用的架构。你可以参考一下：

这张图里，数据库稳稳地待在私有子网，所有对外访问都通过NAT网关。管理子网负责监控和运维，安全组像门卫一样严格检查每个请求。嗯，这就是我心目中的「安全屋」。

---

公众号:蓝海资料掘金营，微信deep3321