云上VPC网络设计实战：子网划分、路由表、安全组与NAT网关
去年，一个客户上云，吭哧吭哧搭了两个月，终于把业务跑起来了。结果有一天，数据库连不上了。查了半天，发现是子网IP不够了——当初随手配了个/24，256个IP，以为绰绰有余。结果光Kubernetes节点就占了几十个，再加RDS、Redis、各种中间件，IP池爆了。
改CIDR？VPC建好了就不能改。只能重建VPC，把几十个服务全迁过去，折腾了一周。
他后来跟我说：“早知道当初多花半小时规划网络，就不用花一周来填坑。”
这是云上网络设计最常见的悲剧：一开始随手配，后面哭着改。
今天聊聊VPC网络设计。不是那种“VPC是什么”的入门课，而是帮你理清楚：子网怎么分、路由表怎么配、安全组怎么设、NAT网关要不要上，才能让后面少踩坑。
01 选CIDR：别随手敲一个/16
创建VPC的第一步，选CIDR（IP地址范围）。很多人随手敲个10.0.0.0/16或172.31.0.0/16，觉得够大就行。
但这里有几个坑：
坑一：和本地网络冲突
如果你公司内网用的是10.0.0.0/8，云上VPC也选10.0.0.0/16，以后想打通VPN或专线，IP段重叠，路由都配不了。选之前，先问问网络团队：“我们内网用什么段？”避开它。
坑二：网段太小不够扩展
/24只有256个IP，去掉网络号、网关、广播，剩253个。看着不少，但云上消耗IP的地方比你想象的多：每台EC2至少1个主IP，每个Load Balancer、NAT网关、RDS都有IP。Kubernetes一个节点就能占几十个IP（Pod IP不在VPC里，但节点本身在）。几百个IP可能一两年就用完了。但改CIDR几乎不可能。
坑三：网段太大浪费路由
/8有一千多万个IP，但路由表条目有限，大网段会导致路由条目稀疏，影响性能。而且IP浪费本身不是问题，问题是VPC内其他云服务（如VPN网关）的IP地址池可能冲突。
建议：选/16，预留足够扩展空间。 比如10.0.0.0/16（65536个IP），够大多数公司用好几年。内网冲突的话，用172.16.0.0/12或192.168.0.0/16。千万不要用/8。
02 子网划分：把不同类型的资源隔开
VPC建好后，下一步划分子网。原则很简单：把不同用途的资源放到不同子网。
至少分三层：
公网子网：放负载均衡、NAT网关、堡垒机。这些资源需要直接或间接暴露给公网。
应用子网：放应用服务器。不能直接访问公网，但能通过NAT出去下载补丁。
数据子网：放数据库、Redis、缓存。连公网都不能出，只允许应用子网访问。
每个可用区都要有这三层子网，做高可用。
一个典型的三层架构：流量从公网子网的LB进来，到应用子网的ECS，再到数据子网的RDS。每一层都隔离，攻击者拿到应用服务器，也碰不到数据库。
反常识观点：子网不是越多越好，够用就行。 有人把每个微服务单独一个子网，结果路由表爆炸，维护成本极高。按“公网、应用、数据”三层分，再按可用区分，足够了。
03 路由表：流量往哪走
每个子网都有一张路由表，告诉流量往哪走。
默认路由表只有一条：local，VPC内部互通。
你需要加的可能有这几条：
公网子网：加一条
0.0.0.0/0指向Internet Gateway，让LB能接收公网流量。应用子网：加一条
0.0.0.0/0指向NAT网关，让应用能下载补丁，但不能被公网主动访问。数据子网：没有默认路由，只能VPC内部访问。
专线或VPN子网：加一条指向VPN网关或专线网关的路由，打通本地数据中心。
路由表的设计原则：默认拒绝，按需放开。 不需要的默认路由别加，加一条就多一条风险。
04 安全组 vs 网络ACL：两个防火墙
很多人分不清安全组和网络ACL，老混着用。
安全组：实例级别的防火墙。有状态——你允许出站，回包自动放行。只支持“允许”规则，不支持“拒绝”。一个实例可以绑多个安全组。
网络ACL：子网级别的防火墙。无状态——进出规则都要写。支持“允许”和“拒绝”。一个子网只能绑一个ACL。
怎么用？
安全组是主力，大部分规则写在这里。
网络ACL做补充，比如要“明确拒绝某个IP”时用（安全组只能允许，不能拒绝）。
一个常见配置：应用子网的安全组只允许来自LB的流量；数据子网的安全组只允许来自应用子网的流量。
反常识观点：安全组规则越少越好。 规则多了不仅难维护，还可能因为规则顺序、冲突导致意外放行。能用3条就别用10条。
05 NAT网关：让私网实例上网
应用子网的实例没有公网IP，但有时需要上网：下载系统补丁、调用外部API。
NAT网关就是干这个的。它放在公网子网，私网子网的路由表配一条0.0.0.0/0指向它，流量就出去了。
NAT网关的坑：
贵：除了实例费，还要付流量费。如果私网实例下载量大，账单可能吓人。
单点：一个可用区一个NAT网关，挂了就切到另一个可用区的。高可用要自己设计（比如用NAT网关+路由表切换）。
替代方案：
如果只是偶尔下载补丁，用VPC endpoints代替NAT网关。比如S3、ECR、CloudWatch都有VPC endpoint，流量不走公网，更便宜、更安全。
如果对成本敏感，可以用自建NAT（EC2上配iptables），但需要自己维护高可用。
06 一个真实案例：VPC重建的教训
回到开头的客户。他们当初选CIDR时随便敲了个10.0.1.0/24，觉得256个IP肯定够。结果业务涨得快，Kubernetes集群节点从3个涨到20个，每个节点还有几个Pod的辅助IP，再加上RDS、Redis、ELB、NAT网关，IP池爆了。
我们帮他分析了两个方案：
方案一：重建VPC，新CIDR用
10.0.0.0/16，把服务迁过去。代价是停机窗口，需要协调业务方。方案二：不重建，用VPC二次分配CIDR（部分云支持添加辅助CIDR），老资源不动，新资源用新段。但老段IP还是不够，只能缓解，不能根治。
最后选了方案一，花了一周迁移。他后来说：“早知道规划一下CIDR，这一周就不用折腾了。”
写在最后
VPC网络设计，看起来是“创建时点几下”的小事，但一旦建好，后面想改，代价极大。CIDR选错了、子网分少了、路由表配乱了，后面每一层架构都要迁就它。
花半小时好好规划，后面省下的时间可能是几周甚至几个月。
那家客户后来重建VPC时，花了一天做规划：CIDR选10.0.0.0/16，按可用区和用途分了6个子网，路由表、安全组一次性配好。到现在两年了，从来没因为网络问题折腾过。
技术负责人跟我说：“以前觉得网络是运维的事，现在觉得，网络是整个架构的地基。地基没打好，上面盖多高都悬。”
你的云上地基，打好了吗？
