为什么上云前要先理解 VPC

在 AWS 中，VPC（Amazon Virtual Private Cloud）是多数云资源运行的网络边界。EC2 实例、RDS 数据库、负载均衡器、NAT 网关、私有子网中的应用服务，通常都需要放在某个 VPC 内，并通过子网、路由表、安全组和网络 ACL 等组件控制访问路径。

对云服务采购者来说，VPC 配置会影响后续资源能否正常访问、是否便于扩展，以及网络费用是否可控。对开发者和企业技术负责人来说，VPC 是应用架构的基础。如果一开始把公网实例、数据库、跳板机、出口访问混在同一个子网中，后期排查访问问题、做安全收敛或迁移到多可用区架构都会更困难。

本文从实际配置角度说明 AWS VPC 的常见组成：如何规划 CIDR，如何划分公有子网和私有子网，安全组怎么写，NAT 网关解决什么问题，以及公网访问要满足哪些条件。内容以基础架构说明为主，不涉及特定业务的性能承诺或费用测算。

VPC 的核心组件关系

配置 VPC 前，建议先把几个关键对象的关系理清。

VPC 是一个逻辑隔离网络，需要指定 IPv4 CIDR 范围，例如使用 RFC 1918 私有地址段。VPC 内可以创建多个子网，子网必须位于某个可用区。子网本身不等于“公有”或“私有”，真正决定它能否直接访问互联网的是路由表与网关配置。

Internet Gateway（互联网网关，简称 IGW）挂载到 VPC 后，可以为具有公网地址的资源提供互联网出入口。公有子网通常会把默认路由指向 IGW。NAT Gateway（NAT 网关）一般部署在公有子网中，为私有子网内的实例提供主动访问互联网的能力，例如拉取软件包、访问第三方 API 或连接 AWS 公共服务端点。私有子网的默认路由通常指向 NAT 网关，而不是 IGW。

安全组是实例级别或弹性网络接口级别的虚拟防火墙，控制入站和出站流量。网络 ACL 是子网级别的无状态访问控制。日常配置中，安全组使用频率更高，也更贴近应用端口管理；网络 ACL 更适合做子网层面的补充限制。

理解这些关系后，可以用一句话概括：VPC 提供网络范围，子网承载资源，路由表决定流量走向，网关连接外部网络，安全组控制能否访问。

第一步：规划 VPC CIDR 与可用区

创建 VPC 时要先选择 CIDR 范围。常见做法是使用私有地址段，如 10.0.0.0/16、172.16.0.0/16 或 192.168.0.0/16 的子范围。实际选择时需要考虑三个问题。

第一，是否会与公司办公网、IDC、其他云上 VPC 或未来的 VPN/专线网络冲突。如果后续要通过 Site-to-Site VPN、Direct Connect 或 VPC Peering 互联，地址段重叠会带来很高的改造成本。

第二，是否预留足够地址空间。子网、负载均衡器、容器节点、数据库、多可用区部署都会消耗 IP 地址。AWS 每个子网会保留部分 IP 地址供平台使用，因此不要把子网划得过小。

第三，是否按环境隔离。生产、测试、开发环境可以使用不同 VPC，也可以在同一账号内通过不同 VPC 分开。对于企业团队，生产环境通常建议与测试环境保持网络边界清晰，减少误操作和权限混用。

可用区方面，建议从一开始就按至少两个可用区设计子网结构。例如每个可用区准备一个公有子网和一个私有子网。这样在后续部署应用负载均衡、Auto Scaling、RDS 多可用区或容器集群时，不需要重新大规模调整网络。

第二步：划分公有子网与私有子网

AWS 中“公有子网”和“私有子网”不是创建子网时的固定类型，而是由路由和资源配置共同形成的结果。

公有子网通常具备三个条件：所在 VPC 已挂载 Internet Gateway；子网关联的路由表中有一条指向 IGW 的默认路由；子网内资源拥有公网 IPv4 地址或可被公网入口服务转发访问。常见放置对象包括面向公网的 Application Load Balancer、NAT 网关、堡垒机或需要直接被互联网访问的少量实例。

私有子网通常不把默认路由指向 IGW，也不给普通业务实例分配公网 IP。应用服务器、后台服务、数据库、缓存、内部队列等资源更适合放在私有子网中。私有子网内实例如需访问互联网，可通过 NAT 网关出站；如只访问 AWS 服务，也可以考虑 VPC Endpoint，以减少流量绕行公网路径的需求。

一个清晰的基础结构可以是：两个可用区，每个可用区一个公有子网和一个私有子网；公有子网放置负载均衡器和 NAT 网关；私有子网放置应用实例和数据库。公网用户访问负载均衡器，负载均衡器再把流量转发到私有子网中的应用目标组。应用需要更新系统包或访问外部接口时，通过 NAT 网关主动出站。

这种结构的优点是边界清楚：公网入口集中在负载均衡器或少数受控资源上，业务实例不必暴露公网地址，数据库也不直接暴露在互联网中。

第三步：配置 Internet Gateway 与路由表

创建 VPC 后，如果需要公网访问，需创建并挂载 Internet Gateway。挂载后还要修改对应子网的路由表，单独挂载 IGW 并不会自动让所有实例能访问公网。

公有子网的典型路由表包含本地路由和默认路由。本地路由指向 VPC 内部 CIDR，用于 VPC 内资源互通；默认路由 0.0.0.0/0 指向 Internet Gateway，用于访问互联网。如果启用 IPv6，还需要按实际需求配置 ::/0 指向 IGW，并注意 IPv6 地址通常具有公网可路由属性，安全组控制更要谨慎。

私有子网的路由表不应把默认路由指向 IGW。如果私有资源需要主动访问互联网，默认路由可以指向 NAT 网关。如果不需要出站互联网，则可以只保留本地路由和必要的 VPC Endpoint 路由。

在排查公网访问问题时，路由表是必查项。常见错误包括：实例有公网 IP 但子网路由表没有指向 IGW；IGW 已创建但未挂载到 VPC；子网关联了错误的路由表；私有子网误关联了公有路由表，导致不该暴露的资源具备公网路径。

第四步：安全组如何配置更稳妥

安全组是 VPC 配置中最常用的访问控制工具。它是有状态的：如果允许入站请求，则响应流量会自动允许返回；如果允许出站请求，对应返回流量也会被允许。配置安全组时，应遵循最小权限原则。

对于面向公网的负载均衡器，入站规则通常只开放业务需要的端口，例如 HTTP 或 HTTPS，来源为互联网或指定来源范围。生产环境中，如果有明确的访问来源，应尽量使用固定网段限制，而不是无差别开放。负载均衡器到后端实例的访问，可以让后端安全组只允许来自负载均衡器安全组的流量，而不是允许整个公网访问。

对于应用服务器，SSH 或 RDP 管理端口不建议直接对全网开放。更稳妥的方式包括使用堡垒机、AWS Systems Manager Session Manager，或仅允许公司出口 IP、VPN 网段访问。数据库安全组应只允许应用服务器安全组访问相应数据库端口，不应向公网开放。

安全组还支持用安全组作为来源或目标，这一点很实用。例如应用实例安全组允许来自 ALB 安全组的 443 或应用端口流量；数据库安全组允许来自应用实例安全组的数据库端口流量。这样即使实例 IP 变化，也不需要频繁修改规则。

出站规则也不应完全忽略。默认安全组通常允许所有出站流量，但企业环境中可以根据合规要求收紧，例如只允许访问必要端口、代理服务、NAT 网关路径或内部服务网段。需要注意的是，过度收紧出站规则可能影响系统更新、容器镜像拉取、监控代理上报等操作，变更前应先梳理依赖。

第五步：NAT 网关的作用与部署方式

NAT 网关主要解决一个问题：私有子网内的资源不暴露公网地址，但仍可主动访问互联网。典型场景包括 EC2 实例安装依赖包、应用调用外部 API、容器节点拉取镜像、系统补丁更新等。

NAT 网关需要部署在公有子网中，并分配弹性公网 IP。私有子网的路由表将 0.0.0.0/0 指向 NAT 网关后，私有实例即可通过 NAT 网关出站访问公网。外部互联网不能通过 NAT 网关主动连接私有实例，这与给实例绑定公网 IP 是不同的。

从可用性角度看，如果业务跨多个可用区运行，通常会在每个可用区的公有子网中部署 NAT 网关，并让同可用区的私有子网路由到本可用区的 NAT 网关。这样可以减少跨可用区依赖，也更符合多可用区架构思路。是否采用这种方式，需要结合预算、可用性要求和流量路径判断。

如果私有实例主要访问的是 AWS 服务，例如 S3、DynamoDB、Systems Manager、CloudWatch Logs 等，可以评估使用 VPC Endpoint。Endpoint 能让 VPC 内资源通过 AWS 内部网络路径访问相应服务，在安全边界和路由控制上更清晰。不同服务支持的 Endpoint 类型不同，配置前应查看 AWS 官方文档。

第六步：公网访问需要同时满足哪些条件

很多 VPC 问题看似是“端口不通”，实际上是多个条件中缺了一个。以 EC2 实例直接公网访问为例，至少要满足以下条件。

实例位于关联公有路由表的子网中，该路由表有默认路由指向 Internet Gateway；VPC 已正确挂载 IGW；实例有公网 IPv4 地址或弹性公网 IP；安全组入站规则允许访问端口和来源；实例操作系统防火墙允许该端口；应用进程监听正确地址和端口；网络 ACL 没有阻断对应入站和出站流量。

如果是通过公网负载均衡器访问私有实例，则条件会有所不同。负载均衡器需要位于公有子网并具有正确安全组；监听器和目标组配置正确；目标实例位于私有子网也可以，但其安全组必须允许来自负载均衡器安全组的流量；健康检查路径、端口和协议要与应用实际状态一致。

如果是私有实例访问公网，需要检查私有子网路由表是否指向 NAT 网关，NAT 网关是否在公有子网，NAT 网关所在公有子网是否有通向 IGW 的默认路由，安全组和网络 ACL 是否允许出站，目标域名解析是否正常。

因此，公网访问排查建议按链路走：DNS、目标地址、公网 IP、路由表、网关、安全组、网络 ACL、实例系统防火墙、应用监听。不要只盯着一个安全组规则。

一个常见 Web 架构的 VPC 配置示例

以下是一个便于理解的通用 Web 架构，不对应任何特定客户案例。

VPC 使用一个不与企业内网冲突的私有 CIDR。选择两个可用区，各创建一个公有子网和一个私有子网。创建 Internet Gateway 并挂载到 VPC。公有子网关联公有路由表，默认路由指向 IGW。私有子网关联私有路由表，默认路由指向 NAT 网关，或在不需要公网出站时不配置默认公网路由。

在公有子网中创建面向互联网的 Application Load Balancer。ALB 安全组允许公网访问 HTTPS 端口，是否开放 HTTP 视业务跳转策略决定。应用 EC2 实例部署在私有子网中，不绑定公网 IP。应用实例安全组只允许来自 ALB 安全组的应用端口流量，同时允许必要的管理入口，例如来自堡垒机或 Systems Manager 的访问。

数据库部署在私有子网中，使用单独安全组，只允许应用实例安全组访问数据库端口。数据库不绑定公网访问能力。应用实例如需访问外部服务，通过 NAT 网关出站。日志、监控和补丁更新根据实际服务选择公网出口或 VPC Endpoint。

这种架构适合多数需要对外提供 Web 服务、但不希望后端资源直接暴露公网的场景。实际落地时，还需要结合备份、监控、证书、域名解析、访问审计和权限管理一起设计。

采购与账户侧需要提前确认的事项

对于使用 AWS 国际站的团队，VPC 本身不单独代表完整成本，实际账单通常来自 EC2、NAT 网关、负载均衡器、数据传输、弹性公网 IP、RDS、存储和其他服务。采购或开通资源前，建议先明确业务所在区域、是否需要多可用区、是否需要固定公网 IP、私有子网是否需要出站互联网，以及是否会产生较多跨区域或跨可用区流量。

如果团队没有国际信用卡，或需要通过代理方式完成 AWS 国际站账户注册、充值、代购等流程，可以在网络方案确定后再处理账户和额度问题。这样有助于避免先开通资源、后发现区域选择或网络结构不符合业务要求。涉及账户、充值和产品购买的操作，应以 AWS 控制台、账单页面和官方文档为准，保留必要的内部审批与使用记录。

技术负责人也应将 VPC 规划与账号治理结合起来。例如生产环境和测试环境是否分账号管理，IAM 权限是否按角色分配，CloudTrail 是否开启，预算提醒是否配置，网络变更是否需要审批。VPC 配置不是一次性动作，后续新增子网、开放端口、创建公网资源，都应纳入变更管理。

常见错误与检查清单

配置 VPC 时，常见错误包括：把数据库放在公有子网并开放公网访问；应用实例绑定公网 IP 后又开放管理端口到 0.0.0.0/0；私有子网需要更新系统却没有 NAT 网关或 Endpoint；多可用区应用却只有单个可用区的网络出口；安全组规则以 IP 大范围开放，后期无人维护；路由表命名混乱，无法判断哪些子网是公有、哪些是私有。

上线前可以按以下清单自查：VPC CIDR 是否与现有网络冲突；子网是否覆盖所需可用区；公有子网是否只放置确需公网路径的资源；私有子网的默认路由是否符合预期；安全组是否按来源安全组或可信网段限制；数据库、缓存等状态服务是否禁止公网入口；NAT 网关、Endpoint 和 DNS 解析是否满足出站需求；CloudWatch、VPC Flow Logs 或其他日志是否能支持后续排查。

如果对某条规则是否应该开放没有把握，建议先从最小权限开始，通过测试和日志确认依赖，再逐步放行。相反，先大范围开放再回收，往往会给后续安全治理带来更高成本。

小结

AWS VPC 配置的关键不在于创建多少网络对象，而在于把入口、出口和内部访问边界设计清楚。公有子网负责承载必要的公网入口和出口组件，私有子网承载应用与数据资源；Internet Gateway 解决公网直连路径，NAT 网关解决私有资源主动出站；安全组围绕应用链路设置最小权限；路由表决定流量真正走向。

对于云服务采购者、开发者和企业技术负责人，建议在购买或部署资源前先完成 VPC 草图：区域、可用区、CIDR、子网、路由、访问入口、出站方式和安全组边界都应写清楚。这样不仅能减少上线时的网络故障，也便于后续进行账号管理、成本核对和安全审计。