第4章：AWS网络与VPC设计——VPC、子网、路由表、NAT网关、安全组与网络ACL的实战配置
说到AWS的VPC，我脑子里第一个蹦出来的词就是「虚拟数据中心」。说白了，VPC就是你在AWS云上圈出来的一块私有网络空间。你可以在里面跑EC2、RDS、Lambda这些资源，完全由你说了算。
我记得刚入行那会儿，有个同事把数据库直接丢在公有子网里，结果被扫了端口。嗯，从那以后，我对VPC设计就特别较真。今天咱们就把VPC、子网、路由表、NAT网关、安全组和网络ACL这几个核心组件，一个一个掰开揉碎了讲清楚。
4.1 VPC与子网：你的网络地基
VPC是AWS网络架构的基石。你创建VPC时，需要指定一个CIDR块，比如10.0.0.0/16。这个范围决定了你的VPC能容纳多少IP地址。
重要原则：VPC的CIDR块一旦创建就不能修改。所以规划时一定要留足余量。我个人习惯用/16的掩码，这样有65536个IP，足够大多数场景使用。
子网是VPC的下一级划分。每个子网必须关联一个可用区（AZ）。这意味着你可以通过子网实现跨AZ的高可用部署。
子网分两种：
- 公有子网：关联了互联网网关（IGW），路由表中有一条指向IGW的默认路由（0.0.0.0/0）。
- 私有子网：没有直接通往互联网的路由。通常通过NAT网关或VPC端点访问外部服务。
我在项目中遇到过一个问题：有人把子网CIDR设成了10.0.0.0/24，结果只够256个IP，业务一扩容就炸了。你想想看，一个生产环境的VPC，子网至少得给/20才稳妥。
4.2 路由表：流量怎么走，你说了算
路由表决定了网络流量的走向。每个子网必须关联一张路由表。你可以把路由表想象成一张「交通地图」——数据包到了子网，路由表告诉它下一步该往哪走。
路由表的核心规则：
- 本地路由：VPC创建时自动生成，目标为VPC的CIDR块，下一跳为local。这条路由不能删除。
- 自定义路由：你手动添加的路由，比如指向IGW、NAT网关、VPC对等连接、VPN网关等。
我的经验：路由表遵循最长前缀匹配原则。比如目标IP是10.0.1.5，同时有两条路由：10.0.0.0/16和10.0.1.0/24，那么会匹配更精确的10.0.1.0/24。这个细节在排错时特别有用。
举个例子，一个典型的公有子网路由表长这样：
目的地 下一跳
10.0.0.0/16 local
0.0.0.0/0 igw-xxxxxxxx而私有子网的路由表，通常会把0.0.0.0/0指向NAT网关：
目的地 下一跳
10.0.0.0/16 local
0.0.0.0/0 nat-xxxxxxxx4.3 NAT网关：私有子网的「出海口」
私有子网里的EC2实例没有公网IP，但它们有时候需要访问互联网——比如下载补丁、拉取Docker镜像。这时候就需要NAT网关。
NAT网关部署在公有子网中，它有一个弹性IP。私有子网的路由表把0.0.0.0/0指向NAT网关，流量就通过NAT网关转发出去。注意，NAT网关只支持出站流量，外部无法主动访问私有子网里的资源。
避坑指南：我曾经踩过一个坑——NAT网关是单AZ的。如果它所在的AZ挂了，所有依赖它的私有子网都无法访问互联网。解决方案是：在每个AZ都部署一个NAT网关，并让对应AZ的私有子网路由指向本AZ的NAT网关。这样实现了AZ级别的容灾。
NAT网关的带宽上限是45 Gbps，但价格不便宜。如果预算有限，可以考虑NAT实例（EC2自建），但维护成本更高。我个人建议生产环境用NAT网关，省心。
4.4 安全组：实例级别的防火墙
安全组是AWS最常用的网络安全控制手段。它工作在实例级别，说白了就是给EC2、RDS这些资源配一个「门禁」。
安全组的特点：
- 有状态：允许入站流量后，出站响应自动放行，不需要额外规则。
- 只支持允许规则：你不能写一条「拒绝」规则。所有流量默认拒绝，只有明确允许的才放行。
- 可以引用其他安全组：比如允许来自某个安全组的所有流量，这在多层架构中非常实用。
举个例子，一个Web服务器的安全组规则：
入站规则：
类型: HTTP (80) 来源: 0.0.0.0/0
类型: HTTPS (443) 来源: 0.0.0.0/0
类型: SSH (22) 来源: 你的办公IP/32
出站规则：
类型: 所有流量 目标: 0.0.0.0/0我的习惯：安全组规则尽量细化。比如SSH只允许特定IP，而不是整个VPC。另外，我经常用安全组引用——让应用层的安全组只允许来自负载均衡器安全组的流量，这样更安全。
4.5 网络ACL：子网级别的访问控制
网络ACL（NACL）是子网级别的防火墙。它和安全组最大的区别是：NACL是无状态的，而且同时支持允许和拒绝规则。
NACL的规则按编号从小到大依次评估。一旦匹配到某条规则，就立即执行，不再继续匹配。所以规则编号要留出间隔，方便后续插入新规则。
一个典型的NACL配置：
| 规则编号 | 类型 | 协议 | 端口范围 | 来源/目标 | 允许/拒绝 |
|---|---|---|---|---|---|
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | 允许 |
| 110 | HTTPS | TCP | 443 | 0.0.0.0/0 | 允许 |
| 120 | SSH | TCP | 22 | 10.0.0.0/8 | 允许 |
| * | 所有流量 | 所有 | 所有 | 0.0.0.0/0 | 拒绝 |
注意：NACL的无状态特性意味着你需要同时配置入站和出站规则。比如允许入站HTTP流量，出站也要允许临时端口（1024-65535）的响应流量。这个细节经常被忽略，导致服务不通。
4.6 实战配置：搭建一个三层架构VPC
好了，理论讲完了，咱们来点实际的。假设我们要搭建一个经典的三层架构：Web层、应用层、数据库层。
步骤是这样的：
- 创建VPC：CIDR为
10.0.0.0/16。 - 创建子网：
- 公有子网A：
10.0.1.0/24，AZ-a - 公有子网B：
10.0.2.0/24，AZ-b - 私有子网A（应用层）：
10.0.3.0/24，AZ-a - 私有子网B（应用层）：
10.0.4.0/24，AZ-b - 私有子网C（数据库层）：
10.0.5.0/24，AZ-a - 私有子网D（数据库层）：
10.0.6.0/24，AZ-b
- 公有子网A：
- 创建互联网网关：关联到VPC。
- 创建NAT网关：部署在公有子网A，分配弹性IP。
- 配置路由表：
- 公有子网路由表：0.0.0.0/0 → IGW
- 私有子网路由表：0.0.0.0/0 → NAT网关
- 配置安全组：
- Web安全组：允许80/443来自0.0.0.0/0，允许SSH来自办公IP
- 应用安全组：允许来自Web安全组的流量
- 数据库安全组：允许来自应用安全组的3306端口
- 配置网络ACL：作为额外防线，限制子网间的非必要流量。
关键点：数据库层绝对不要放在公有子网里。我曾经见过有人图方便把RDS放在公有子网，结果被扫了数据库端口。安全组和NACL虽然能挡住一部分，但最佳实践是物理隔离——私有子网+安全组+NACL三层防护。
4.7 排错与最佳实践
VPC排错是AWS认证考试的常客，也是日常运维的必修课。我总结了几条经验：
- 流量不通？先看路由表：检查子网关联的路由表是否有正确的默认路由。
- 再看安全组：安全组是否有允许入站/出站的规则。
- 最后看NACL：NACL的无状态特性经常导致问题，特别是临时端口没放行。
- VPC Flow Logs是你的好帮手：开启Flow Logs，可以查看所有被允许或拒绝的流量，排错神器。
我的建议：在VPC设计阶段就开启Flow Logs，不要等到出问题再开。另外，用标签（Tag）给VPC、子网、路由表打上清晰的标记，比如Environment: Production、Tier: Web。这在资源多的时候能救命。
最后说一句：VPC设计没有银弹。每个业务场景都不一样，但核心原则是相通的——最小权限、分层隔离、高可用。你把这些原则吃透了，VPC这块基本就稳了。