如果你要在 AWS 上部署业务，VPC 网络规划最好先想清楚。子网怎么分、路由表怎么走、安全组放开什么端口，都会影响后面的扩容、安全和排障。
很多团队刚开始只想“先把 EC2 跑起来”。这当然没问题，但如果后面要接 RDS、负载均衡、堡垒机、VPN、跨账号访问，早期随手建的 VPC 很快会变成麻烦。更常见的问题是：公网实例太多，私网资源也能被误访问；路由表混在一起，谁能出网、谁不能出网说不清；安全组规则越加越多，最后没人敢删。
这篇 AWS VPC 网络规划教程按实际搭建顺序讲：先定网段，再分子网，再配路由表，最后收紧安全组。你可以把它当作上线前的检查清单，也可以用来复盘已有环境。
AWS VPC 网络规划先定什么？
VPC 可以理解成你在 AWS 里的私有网络。它不是单台服务器的配置，而是后面所有 EC2、RDS、负载均衡、NAT、VPN 的网络底座。
第一步要定的是 CIDR 网段。常见做法是使用私有地址段，比如 10.0.0.0/16、172.16.0.0/16 或 192.168.0.0/16 范围内的网段。具体选多大，要看你未来会不会多环境、多可用区、多业务线共用。如果只是测试环境，小一点也够用；如果是企业生产环境，建议给后续扩展留空间。
这里有一个容易踩的坑：VPC 网段不要和办公室、机房、其他云账号里的网段冲突。现在不冲突，以后做 VPN、专线、VPC Peering 或 Transit Gateway 时也可能冲突。网段一旦用久了，再改会很麻烦，通常要迁移资源。
比较稳的做法是先画一张简单表：生产、测试、开发分别用哪个大网段；每个区域用哪个网段；每个可用区切出哪些子网。表不需要复杂，但要能让团队一眼看懂。
子网怎么分：公网、私网和数据库网段要分开
子网是 VPC 里的更小网络单元，并且属于某一个可用区。AWS 里的高可用架构通常会跨多个可用区，所以子网也要按可用区成对规划。
一个常见结构是这样分：公网子网放负载均衡、NAT Gateway、堡垒机这类需要直接或间接连公网的资源；私网应用子网放业务 EC2、容器节点或应用服务；数据库子网放 RDS、缓存等不该暴露到公网的资源。
如果你是个人测试环境，可以先建一个公网子网和一个私网子网。但如果是生产环境，建议至少跨两个可用区准备同类子网。比如每个可用区都有一个公网子网、一个应用私网子网、一个数据库私网子网。这样后面做负载均衡、数据库多可用区部署时，网络结构不会重新返工。
在控制台操作时，可以进入 VPC 控制台，选择 Subnets，然后创建子网。你需要选择所属 VPC、可用区和 IPv4 CIDR。创建完成后，子网会显示为 available 状态。后面资源启动时，就可以选择对应子网。
子网命名也别省。像 prod-public-a、prod-app-private-a、prod-db-private-a 这种名字，比默认名称好排查得多。等环境多起来，清楚的命名会省下很多沟通成本。
路由表怎么配：先决定哪些资源能出公网
路由表决定流量往哪里走。很多 AWS VPC 网络问题，最后都能追到路由表：实例有公网 IP 但上不了网，私网实例不能拉镜像，数据库被错误放到可出公网的子网里。
公网子网通常会关联一张公网路由表。这张路由表里需要有一条到互联网网关的默认路由，比如 0.0.0.0/0 指向 Internet Gateway。这样放在公网子网里的资源，在满足公网 IP 和安全组规则的前提下，才能和公网通信。
私网子网不要直接连 Internet Gateway。应用私网子网如果需要访问公网下载补丁、拉取依赖或访问外部 API，常见做法是通过 NAT Gateway 出网。它的路由表可以设置 0.0.0.0/0 指向 NAT Gateway。这样外部无法主动访问私网实例，但私网实例可以主动访问外部服务。
数据库子网要更保守。如果数据库只给应用访问，就不要给它配置默认出公网路由。它的路由表只需要保留 VPC 内部路由，以及必要的内网访问路径。这样就算安全组误放开，也少了一层风险。
可以按下面步骤检查路由：
- 打开
VPC 控制台，进入Route tables。 - 找到公网子网关联的路由表，确认默认路由指向 Internet Gateway。
- 找到应用私网子网关联的路由表，确认默认路由按需要指向 NAT Gateway，或没有默认出公网路由。
- 找到数据库子网关联的路由表，确认它没有被误关联到公网路由表。
- 回到
Subnets，查看每个子网的 route table association，确认子网和路由表对应正确。
判断子网是不是公网子网，不是看名字，而是看它关联的路由表是否能通过 Internet Gateway 到公网。 这是排查时很重要的一点。
安全组怎么写：只放开真实需要的入口
安全组是实例、负载均衡、数据库等资源的虚拟防火墙。它是有状态的。简单说，你放开入站规则后，返回流量一般不需要再单独写一条出站规则。
安全组最怕两种写法。一种是为了省事，把 0.0.0.0/0 放到 SSH、RDP、数据库端口上。另一种是规则越写越多，却没有备注，也不知道哪条还在用。前者风险高，后者后期难维护。
更好的写法是按访问关系建安全组，而不是按端口随便堆规则。比如：负载均衡安全组允许公网访问 80 或 443；应用服务器安全组只允许来自负载均衡安全组的业务端口；数据库安全组只允许来自应用服务器安全组的数据库端口。这样规则能跟架构对应起来。
如果你要配置 Web 应用，可以按这个思路做：
- 给负载均衡创建安全组，只开放业务需要的 HTTP 或 HTTPS 端口，来源按实际访问范围设置。
- 给应用 EC2 创建安全组，入站来源选择负载均衡安全组，而不是直接写所有公网 IP。
- 给 RDS 创建安全组，入站来源选择应用服务器安全组，只开放数据库实际使用的端口。
- 管理端口不要长期对公网开放。需要远程维护时，优先使用固定办公出口 IP、堡垒机、Session Manager 或 VPN 等方式。
这里不要迷信“内网就安全”。私网资源也要写清楚访问边界。应用服务器能访问数据库，不代表所有私网实例都应该访问数据库。
公网子网和私网子网该怎么选？
如果资源需要被互联网直接访问，比如公网负载均衡、临时测试 Web 服务、NAT Gateway，通常放在公网子网。公网子网的核心特征是有到 Internet Gateway 的路由。
如果资源不需要被公网主动访问，比如应用服务器、队列消费者、内部 API、数据库、缓存，通常放在私网子网。它们可以通过内网和其他服务通信。是否能出公网，要看有没有 NAT Gateway 或其他出口路径。
企业生产环境里，建议把“入口”和“业务处理”分开。公网入口放负载均衡，后端应用放私网子网。这样公网只看到入口层，应用层和数据层都藏在内网里，安全边界更清楚。
如果你只是做开发测试，结构可以简化，但不要把数据库直接放到公网子网，也不要给数据库绑定公网可访问配置。即使只是测试，很多事故也是从“临时方便一下”开始的。
NAT Gateway 要不要用？
私网实例如果完全不需要访问公网，可以不用 NAT Gateway。比如数据库只接受应用访问，不下载外部依赖，也不主动访问公网服务，就不需要默认出公网路由。
如果私网应用要访问公网，NAT Gateway 是常见方案。它适合让私网资源主动出网，又不接受公网主动访问。比如拉取软件包、访问第三方 API、连接外部授权服务。
费用方面，NAT Gateway 会产生相关费用，具体以 AWS 官方最新价格为准。采购和预算评估时，别只看 EC2 或 RDS。公网出口、NAT、负载均衡、跨可用区流量等都可能影响账单。
如果你正在做 AWS 国际站账户注册、充值或预算规划，进化云可以协助处理账户注册、代充值、折扣申请和产品代购相关事项。涉及价格、折扣和到账时间，请以实际咨询和 AWS 官方最新规则为准。
一套基础 VPC 可以这样落地
下面是一套比较通用的 VPC 落地顺序，适合新项目从零开始搭环境。不同公司会有自己的命名和审批流程，但大方向差不多。
- 创建 VPC。进入
VPC 控制台，选择Your VPCs，创建一个新的 VPC，并设置 IPv4 CIDR。 - 创建子网。按可用区创建公网子网、应用私网子网和数据库私网子网。CIDR 不要重叠。
- 创建并挂载 Internet Gateway。把它附加到目标 VPC。
- 创建公网路由表。添加
0.0.0.0/0到 Internet Gateway，并关联公网子网。 - 按需要创建 NAT Gateway。把它放在公网子网里，再让应用私网子网的默认路由指向它。
- 创建数据库私网路由表。不要给数据库子网配置直接出公网的默认路由，除非业务确实需要，并且已经评估风险。
- 创建安全组。按负载均衡、应用、数据库分组，不要把所有规则写进一个安全组。
- 启动资源并测试。确认公网入口能访问应用，应用能访问数据库，数据库不能被公网访问。
测试不要只看“页面能不能打开”。还要检查几件事：应用服务器是否真的在私网子网；数据库是否没有公网入口；安全组来源是否用了具体 IP 或安全组引用；路由表有没有误关联。
常见错误怎么排查？
实例有公网 IP，但访问不了互联网，先看三件事：子网路由表是否有默认路由到 Internet Gateway；实例是否有公网 IPv4 地址或弹性 IP；安全组和网络 ACL 是否允许相关流量。缺一项都可能不通。
私网实例访问不了外网，先看它的路由表有没有默认路由到 NAT Gateway。再看 NAT Gateway 是否在公网子网里，公网子网是否能到 Internet Gateway。NAT 放错子网，是很常见的配置问题。
应用连不上数据库，别急着改数据库参数。先看数据库安全组是否允许应用安全组访问目标端口，再看应用和数据库是否在同一个 VPC 或已有正确的网络连接。还要确认数据库子网组和路由没有误配。
安全组规则太乱时，不建议一口气全删。先把现有规则导出或截图，按访问关系重新建新安全组，再逐步切换资源。确认业务稳定后，再清理旧规则。
上线前检查这几项就够用了
上线前，建议把 VPC 配置按“能不能被公网访问”和“能不能主动出公网”分开检查。这个方法比单纯看子网名字更靠谱。
- 公网入口是否只放在负载均衡、API 网关或明确需要公网访问的资源上。
- 应用服务器是否位于私网子网，并通过受控路径访问外部网络。
- 数据库、缓存等数据层资源是否没有公网入口。
- 路由表是否按子网类型分开，没有把数据库子网关联到公网路由表。
- 安全组是否使用最小开放原则，管理端口没有长期对所有公网开放。
- 命名和标签是否清楚，后续能按环境、业务和负责人查找资源。
VPC 规划不是一次性工作。 业务上线后，新增服务、跨区域部署、混合云连接都会影响网络设计。每次增加入口、出口或跨网段访问，都应该回到路由表和安全组检查一遍。
进化云能帮你处理哪些 AWS 账户相关问题？
很多采购者和技术负责人关心的不只是怎么配 VPC，还包括 AWS 国际站账户怎么开、没有国际信用卡怎么充值、预算怎么走审批、折扣能不能申请。
进化云的定位是 AWS 国际站代充与账户代理服务，可协助处理 AWS 账户注册、代充值、折扣申请及全系列产品代购支持。网络架构这类问题，也可以在采购前一起沟通，避免账户、预算和技术方案脱节。
涉及 AWS 产品价格、折扣、服务限制和区域差异，请以 AWS 官方最新说明和实际咨询结果为准。VPC、NAT Gateway、负载均衡、数据传输等费用都可能影响总成本，建议在部署前一起纳入预算。
FAQ
AWS VPC 子网一定要分公网和私网吗？
不一定，但生产环境建议分。公网子网放入口资源，私网子网放应用和数据层，边界更清楚，也更容易控制访问风险。
安全组和路由表有什么区别？
路由表决定流量往哪里走，安全组决定资源允许哪些流量进出。路由通了，不代表安全组也放行；安全组放行了，路由不通也访问不了。
数据库可以放在公网子网吗？
不建议。数据库通常应放在私网子网，并只允许应用安全组访问。是否需要公网访问，要按业务和安全要求单独评估。
AWS VPC 网络规划和充值账户有关吗？
技术上是两件事，但预算和采购会关联。比如 NAT、负载均衡、跨可用区流量都会影响费用。做 AWS VPC 网络规划时，建议同步评估账户充值和成本安排。
