3. VPC作为企业网络核心边界
在 AWS 上，VPC（Virtual Private Cloud）不是“把服务器放进云里”的容器，而是企业网络在云上的逻辑边界与地址自治域。它决定了企业能使用哪些私有地址、如何划分安全域、流量在哪些路径上被允许或拒绝，以及后续与本地数据中心、其他 VPC、互联网如何互联。因此，VPC 设计一旦落地，后续迁移、扩容和合规审计的成本几乎都由此决定。
一、VPC CIDR 规划：先定地址，再谈架构
VPC 创建时必须指定 IPv4 CIDR 块，允许范围是 /16 到 /28，且创建后不能修改或缩小，只能追加辅助 CIDR。这意味着地址规划必须前置。企业常见做法是：总部或云平台团队从 RFC 1918 私有地址中划出一段专供 AWS 使用的“云地址池”，例如 10.0.0.0/8 中预留 10.10.0.0/16 给生产、10.20.0.0/16 给测试、10.30.0.0/16 给共享服务。
规划时要同时考虑三件事：规模、互联、冲突。规模上，/16 可提供约 6.5 万个地址，适合作为大型生产 VPC；/20 约 4000 个地址，适合中小型业务。互联上，若未来要通过 Transit Gateway 或 VPC Peering 打通多个 VPC，各 VPC 的 CIDR 不能重叠，否则无法路由。冲突上，必须与本地数据中心、其他云、并购企业已有网段核对，避免出现 10.0.0.0/8 被本地占用、云上又重复使用的情况。
一个可参考的示例规划如下：生产 VPC 使用 10.10.0.0/16，测试 VPC 使用 10.20.0.0/16，共享服务 VPC 使用 10.30.0.0/16，本地数据中心使用 172.16.0.0/12。这样在后续建立混合连接时，路由表可以清晰地区分“云内东西向”和“云到本地南北向”流量。
二、子网分层：把安全域写进地址结构
子网是 VPC 内的可用区级划分，一个子网只能属于一个可用区。企业不应把所有资源塞进一个子网，而应按安全层级分层。典型分层包括：公有子网、应用私有子网、数据私有子网、管理子网。公有子网承载 ALB、NAT Gateway、跳板机等需要出入互联网的组件；应用私有子网承载 EC2、ECS、Lambda 等业务计算；数据私有子网承载 RDS、ElastiCache、OpenSearch 等数据服务；管理子网承载堡垒机、监控、日志采集等运维入口。
分层的关键不是命名，而是路由与安全组策略的差异化。例如，公有子网路由指向 Internet Gateway，应用私有子网路由指向 NAT Gateway 以支持出站软件更新，数据私有子网则完全不配置默认路由，只允许来自应用子网的安全组访问。这样即使应用层被攻破，数据层仍没有直接出网路径。
三、路由表：决定流量“往哪走”
路由表是 VPC 内流量的导航规则。每个子网必须关联一张路由表，路由表由“目标 CIDR + 下一跳”组成。企业 VPC 中通常至少维护三类路由表：公有路由表、私有路由表、隔离路由表。公有路由表包含指向 Internet Gateway 的 0.0.0.0/0；私有路由表包含指向 NAT Gateway 的 0.0.0.0/0；隔离路由表只保留 local 路由，用于数据层或合规隔离区。
路由表设计中最容易出错的是路由优先级与最长前缀匹配。AWS 会优先选择最具体的目标网段。例如，路由表中同时存在 0.0.0.0/0 → IGW 和 10.20.0.0/16 → TGW，那么访问 10.20.1.5 的流量会走 TGW，而不是 IGW。因此，在混合云场景中，必须把本地网段、其他 VPC 网段显式写入路由表，否则流量会默认走互联网，既不合规也不安全。
四、默认 VPC 对比：为什么生产环境不应直接使用
每个 AWS 区域在首次创建资源时会自动生成一个默认 VPC，CIDR 通常为 172.31.0.0/16，并在每个可用区创建一个默认子网。默认 VPC 的优点是开箱即用，适合快速实验；但对企业生产环境而言，它存在明显问题：地址段固定且容易与本地冲突、子网全部为公有子网、默认安全组允许同组内互通、缺乏分层与命名规范。因此，企业应禁用或忽略默认 VPC，按规划创建自定义 VPC，并通过 SCP 或 IAM 策略限制在默认 VPC 中创建生产资源。
| 对比项 | 默认 VPC | 企业自定义 VPC |
|---|---|---|
| CIDR | 172.31.0.0/16，固定 | 按地址池规划，如 10.10.0.0/16 |
| 子网属性 | 默认均为公有子网 | 按安全域分为公有、私有、数据、管理 |
| 路由表 | 单一主路由表，指向 IGW | 多张路由表，差异化下一跳 |
| 安全组 | 默认组允许同组互通 | 最小权限，按层授权 |
| 命名与标签 | 无统一规范 | 强制命名与标签策略 |
| 适用场景 | 实验、临时验证 | 生产、混合云、合规业务 |
五、企业 VPC 命名与标签策略
当企业拥有几十个 VPC 时，命名和标签就是可运维性的基础。命名建议采用“环境-业务-区域-序号”的结构，例如 prod-payment-apne1-01、test-order-apne1-01。子网命名可追加层级与可用区，例如 prod-payment-apne1-01-public-a、prod-payment-apne1-01-data-a。这样在控制台、CLI 和账单中都能快速定位资源归属。
标签策略应至少覆盖以下键：Environment（prod/test/dev）、BusinessUnit（payment/order/user）、Owner（团队邮箱或负责人）、CostCenter（成本中心）、DataClass（public/internal/confidential）。其中 Environment 和 DataClass 可用于自动化策略：例如，DataClass=confidential 的子网禁止关联 Internet Gateway 路由，Environment=prod 的 VPC 必须开启 Flow Logs。标签不是装饰，而是策略即代码的输入条件。
综上，VPC 作为企业网络核心边界，其设计质量取决于四件事：CIDR 是否可扩展且不冲突、子网是否按安全域分层、路由表是否精确控制流量路径、命名与标签是否可治理。默认 VPC 适合实验，但不应承载生产。把地址、分层、路由和标签四者统一规划，才能让 VPC 真正成为企业云上网络的稳定边界，而不是后续迁移和审计的负担。