大多数 AWS 新用户在创建第一台 EC2 时会直接使用系统提供的默认 VPC，这在测试阶段没有问题，但在生产环境中默认 VPC 的网络结构过于开放，缺少必要的隔离设计。
理解 VPC 的核心组件和架构逻辑，是把 AWS 用好的基础——不仅是安全层面，也直接影响资源之间的连通性、网络性能和账单结构。
为什么每台 EC2 都在 VPC 里
VPC（Virtual Private Cloud）是在 AWS 云里划定的一块逻辑隔离网络空间，相当于在 AWS 的基础设施上为你的资源分配了一片私有的虚拟局域网。
所有 EC2 实例、RDS 数据库、Lambda 函数等资源都必须运行在某个 VPC 里，两个不同 VPC 里的资源默认完全隔离，即使在同一个 AWS 账号下也无法直接通信。
AWS 在每个区域自动创建一个默认 VPC，配置较为宽松——所有子网默认都是公有子网，新建的 EC2 会自动分配公网 IP。
这个设计方便快速上手，但对生产环境来说意味着每台实例都默认暴露在互联网，不符合最小暴露原则。
自定义 VPC 让你从地址段规划开始，完全控制网络结构。创建 VPC 时需要指定 CIDR 块，定义整个 VPC 的 IP 地址空间：
- 常用私有地址段：10.0.0.0/8（约 1600 万个 IP）、172.16.0.0/12（约 100 万个 IP）、192.168.0.0/16（约 65,000 个 IP）
- 实际部署中通常选 10.0.0.0/16，再从中划分子网，地址空间足够大且便于管理
- 规划时要避免和本地网络、其他 VPC 的地址段重叠，否则日后配置 VPC Peering 时会出现路由冲突
VPC 的核心组件
子网：公有子网与私有子网的本质区别
子网是对 VPC 地址空间的进一步划分，每个子网必须绑定一个可用区（AZ）。公有子网和私有子网的区别不在于名称，而在于路由表的配置：公有子网的路由表里有指向 Internet Gateway 的路由条目，私有子网没有。
两类子网的定位：
- 公有子网： 资源可以配置公网 IP，双向访问互联网；适合部署负载均衡器、堡垒机等需要对外暴露的组件
- 私有子网： 资源没有直接的公网访问路径，无法从互联网直接访问；适合部署应用服务器、数据库等不应对外暴露的资源
生产环境的子网规划建议每种类型在多个可用区各建一个，避免单 AZ 故障导致整个服务不可用。
路由表：流量怎么找到目的地
路由表（Route Table）定义了子网内流量的转发规则，每条规则包含目标地址（Destination）和下一跳（Target），AWS 按最精确匹配原则处理流量：
- 公有子网路由表： 本地流量（VPC CIDR）直接转发；其他流量（0.0.0.0/0）发往 Internet Gateway
- 私有子网路由表： 本地流量直接转发；需要出网的流量（0.0.0.0/0）发往 NAT Gateway
- 数据层子网路由表： 只保留本地路由，不配置出网规则，数据库不需要访问互联网
建议为每个子网创建独立的自定义路由表，而不是直接修改 VPC 的主路由表，避免误操作影响所有子网的路由行为。
Internet Gateway 与 NAT Gateway 的选择逻辑
两者都涉及互联网访问，但流量方向和适用场景完全不同：
| 特性 | Internet Gateway | NAT Gateway |
| 流量方向 | 双向（可被外部主动访问） | 单向（只能主动出网） |
| 部署位置 | 附加在 VPC 上 | 必须部署在公有子网内 |
| 费用 | 免费 | 按小时 + 按流量双重计费 |
| 适用场景 | 公有子网资源对外提供服务 | 私有子网资源需要访问外网 |
判断逻辑：需要被外部访问的资源放公有子网，通过 Internet Gateway 接入；只需要主动出网（如调用外部 API、下载系统更新）的内部资源放私有子网，通过 NAT Gateway 出网。
NAT Gateway 本身必须部署在公有子网，私有子网里的流量先到 NAT Gateway，再经 Internet Gateway 出网。
安全组 vs 网络 ACL：两层防护的差别
VPC 里有两层流量控制机制，分别作用在不同层级：
| 对比项 | 安全组 | 网络 ACL |
| 作用层级 | 实例级别 | 子网级别 |
| 状态特性 | 有状态（入站允许自动放行响应出站） | 无状态（入站出站规则各自独立） |
| 规则类型 | 只有允许规则，无法写拒绝规则 | 支持允许和拒绝规则 |
| 默认行为 | 默认拒绝所有入站，允许所有出站 | 默认允许所有流量 |
| 规则评估 | 所有规则同时生效 | 按规则编号从小到大顺序匹配 |
安全组是日常配置的主要工具，绝大多数场景用安全组就够了。
安全组的有状态特性意味着：只要入站规则放行了一个请求，AWS 自动允许该请求的响应流量出站，不需要单独写出站规则。
而网络 ACL 是无状态的，入站和出站规则必须分别配置——如果忘记配置出站规则，响应流量会被阻断，这是使用网络 ACL 时最常见的配置错误。
网络 ACL 适合在子网层面做额外隔离，例如明确拒绝某个已知恶意 IP 段访问整个子网。
正常业务场景下保持默认即可，不需要修改。关于安全组的详细配置方法和排查逻辑，可以参考 AWS 安全组怎么配置？
典型公私网分离架构设计
三层架构的设计逻辑
标准的公私网分离架构将资源分布在三个层次，每一层运行在不同的子网类型里，通过安全组规则严格控制层间访问关系。
第一层：公有子网（接入层） Application Load Balancer 部署在公有子网，配置公网 IP，接收来自互联网的 HTTP/HTTPS 请求，再将流量转发到后端应用服务器。负载均衡器是整个架构里唯一直接暴露在互联网的组件。
第二层：私有子网（应用层） EC2 应用服务器部署在私有子网，不配置公网 IP，无法从互联网直接访问。
服务器只接受来自负载均衡器的内网流量。如果需要调用外部 API 或下载系统更新，通过 NAT Gateway 出网，但外部无法主动发起到这些服务器的连接。
第三层：私有子网（数据层） RDS 数据库部署在独立的私有子网，只接受来自应用服务器的内网连接，不需要也不应该访问互联网。
这一层的子网路由表不配置 NAT Gateway 路由，彻底切断和互联网的连接。
这种设计的核心安全逻辑是最小暴露：每一层只和相邻层通信，攻击面随层级递减。即使负载均衡器被入侵，攻击者面对的是私有子网里的应用服务器，无法直接访问；即使应用服务器被入侵，数据库也只接受来自应用层安全组的连接，不开放任何其他来源的入站流量。
三层架构中安全组的配置方式
每一层的安全组规则应遵循最小权限原则，只开放业务必须的端口和来源：
- 负载均衡器安全组： 入站允许 80（HTTP）和 443（HTTPS）来自 0.0.0.0/0；出站允许到应用服务器安全组的应用端口（如 8080）
- 应用服务器安全组： 入站只允许来自负载均衡器安全组的流量，不开放任何公网入站；出站允许到数据库安全组的数据库端口（MySQL 3306 / PostgreSQL 5432），以及经 NAT Gateway 访问外网的 443
- 数据库安全组： 入站只允许来自应用服务器安全组的数据库端口；不需要配置特定出站规则
安全组之间通过引用 ID 而非 IP 段互相关联——入站规则的来源填写另一个安全组的 ID，当应用服务器因扩缩容导致 IP 变化时，数据库安全组规则不需要更新，维护成本更低。
多可用区部署与高可用
单可用区部署意味着该 AZ 出现故障时整个服务不可用。生产环境应至少覆盖两个可用区：
- 公有子网和私有子网各在两个可用区各建一个，共四个子网
- Application Load Balancer 自动跨可用区分发流量，某一 AZ 实例不健康时自动绕开
- EC2 Auto Scaling Group 在两个可用区的私有子网里维持实例数量
- RDS 开启 Multi-AZ 部署，主库故障时自动切换到备库，切换通常在分钟级内完成
- NAT Gateway 在每个可用区各部署一个，避免单个 NAT Gateway 故障导致所有私有子网断网
关于 AWS 账号的整体安全防护策略，可以结合 AWS 服务器安全防护教程 一起参考。
VPC Peering 与跨 VPC 访问
随着业务增长，很多团队会把不同业务线或不同环境（生产、测试、开发）放在独立的 VPC 里，跨 VPC 访问有几种方式，选择哪种取决于 VPC 数量和访问关系的复杂程度。
VPC Peering 是两个 VPC 之间建立私有连接的最直接方式，流量完全走 AWS 内部网络，不经过公网。
建立后双方都需要在路由表里添加对方 CIDR 的路由条目，安全组也要允许来自对方 CIDR 的流量。
VPC Peering 的核心限制是非传递性：A 和 B 有 Peering，B 和 C 有 Peering，A 不能通过 B 访问 C，需要单独建立 A 和 C 的 Peering。
VPC 数量增多后，管理成本随连接数量指数级上升。
VPC Endpoints 解决的是私有子网访问 AWS 自有服务的问题。
没有 Endpoint 时，私有子网访问 S3 需要通过 NAT Gateway 出网，产生额外流量费用。
配置 Gateway 类型的 VPC Endpoint 后，流量通过 AWS 内网直接路由到 S3，不经过 NAT Gateway，S3 和 DynamoDB 的 Gateway Endpoint 是免费的，是降低 NAT Gateway 流量费用的有效手段。
Transit Gateway 适合 VPC 数量较多的场景，充当所有 VPC 连接的集中式路由器。
所有 VPC 连接到同一个 Transit Gateway，路由统一管理，避免建立大量点对点 Peering。Transit Gateway 按附加连接数和数据处理量计费，VPC 数量少时成本高于直接 Peering，适合有明确多 VPC 管理需求的企业环境。
VPC 相关费用
VPC 本身以及子网、路由表、Internet Gateway 都是免费的，但以下组件会产生持续费用：
- NAT Gateway： 约 $0.045/小时（约 $32/月）+ 约 $0.045/GB 处理流量；私有子网频繁访问外部服务时，NAT Gateway 的流量费用可能超过服务器本身
- 跨可用区数据传输： 同一 VPC 内跨 AZ 的流量约 $0.01/GB；多 AZ 部署时应将负载均衡到后端、应用服务器到跨 AZ 数据库的流量纳入成本核算
- VPC Interface Endpoint： Gateway 类型（S3、DynamoDB）免费；Interface 类型按小时和流量双重计费，用量小时性价比不一定优于 NAT Gateway
- Transit Gateway： 按附加连接数（约 $0.05/小时/连接）和数据处理量计费，VPC 数量少时成本较高
NAT Gateway 是最容易被低估的 VPC 相关费用项。
如果私有子网里的应用每天有大量对 S3 或 DynamoDB 的调用，建议先配置 VPC Gateway Endpoint，将这部分流量移出 NAT Gateway，再评估剩余出网流量的体量，决定是否需要保留完整规格的 NAT Gateway。
关于 AWS 账单构成的完整逻辑，可以参考 亚马逊云服务器价格
常见 VPC 配置问题排查
EC2 无法访问互联网
排查顺序：
- 检查 EC2 所在子网的路由表，确认有 0.0.0.0/0 → Internet Gateway（公有子网）或 0.0.0.0/0 → NAT Gateway（私有子网）的路由条目
- 公有子网的 EC2 需要配置公网 IP 或 Elastic IP，没有公网 IP 的实例即使路由正确也无法对外通信
- 检查安全组出站规则是否允许目标端口的流量
- 如果在私有子网，确认 NAT Gateway 已部署在公有子网，状态为 Available，且私有子网路由表已指向该 NAT Gateway
EC2 实例之间无法内网通信
排查顺序：
- 确认两台实例在同一 VPC，不同 VPC 的实例默认完全隔离，无法通过内网 IP 通信
- 检查接收方实例的安全组入站规则，确认允许来自发起方 IP 或发起方安全组的对应端口流量
- 确认通信使用的是私有 IP，通过公网 IP 通信会绕道互联网，产生额外延迟和流量费用
- 如果跨 VPC，确认 VPC Peering 已建立，且双方路由表均已添加对方 CIDR 的路由条目
私有子网数据库无法从应用服务器连接
排查顺序：
- 确认数据库安全组入站规则允许来自应用服务器安全组的数据库端口（MySQL 3306 / PostgreSQL 5432）
- 确认连接使用数据库的私有 IP 或 RDS 内网 Endpoint，不能通过公网地址访问私有子网资源
- 确认两者在同一 VPC 或 VPC Peering 已正确配置，路由表已更新
- 检查数据库子网的网络 ACL 出站规则，无状态的 ACL 如果缺少出站规则会阻断响应流量，导致连接超时
关于 IAM 权限配置对资源访问的影响，可以结合 AWS IAM 权限管理教程 一起参考。
