1. 企业云网络架构总览

企业把业务系统迁移到 AWS 时，网络并不是“把服务器连上网”这么简单。它决定了应用能否跨可用区容灾、能否就近服务全球用户、能否与本地数据中心安全互通，以及故障发生时爆炸半径有多大。理解 AWS 全球基础设施的层级结构，是设计一切企业云网络方案的前提。

一、AWS 全球基础设施的层级结构

AWS 的全球基础设施可以按“由大到小”的粒度理解为四层：全球网络骨干、区域（Region）、可用区（Availability Zone，AZ）、边缘站点（Edge Location）。它们不是简单的包含关系，而是各自承担不同的网络职责。

区域是物理上相互隔离的地理集群，例如 us-east-1（弗吉尼亚北部）、ap-southeast-1（新加坡）、cn-north-1（北京）。每个区域内部由多个可用区组成，AZ 之间通过低延迟、高带宽的私有光纤互联，物理距离通常在几十公里内，但供电、制冷、网络相互独立。这意味着：同一区域内跨 AZ 部署可以获得毫秒级延迟和故障隔离，而跨区域部署则用于满足数据驻留、灾难恢复和就近接入需求。

边缘网络由全球数百个边缘站点组成，是 CloudFront、Global Accelerator、Route 53 等服务的落地点。它不承载你的业务计算，而是把用户请求在离用户最近的位置接入 AWS 骨干网，从而降低首包延迟、减少公网抖动。企业面向公网的服务，几乎都会用到边缘网络这一层。

二、企业网络的核心需求

在动手设计之前，需要先把企业的真实诉求翻译成网络指标。常见需求可以归为五类：

• 可用性与容灾：单 AZ 故障时业务不中断，关键系统要求 RTO（恢复时间目标）与 RPO（恢复点目标）可量化，例如 RTO ≤ 15 分钟、RPO ≈ 0。
• 安全与隔离：生产、测试、办公网段必须隔离；对外只暴露必要端口；东西向流量也要可审计。
• 性能与延迟：面向用户的服务要求 P95 延迟可控，跨区域调用要评估骨干网延迟。
• 混合云互通：与本地 IDC 通过 VPN 或 Direct Connect 打通，网段不能冲突。
• 可观测与成本：流量走向可追踪，跨 AZ、跨区域流量费用可预估。

三、设计原则

基于上述需求，企业云网络设计通常遵循以下原则：

1. 先规划地址，再规划资源。VPC 网段一旦确定，后期修改成本极高。建议按“区域—环境—AZ”三段式规划，例如生产环境新加坡区域使用 10.10.0.0/16，其中 AZ-A 为 10.10.1.0/24、AZ-B 为 10.10.2.0/24、AZ-C 为 10.10.3.0/24。同时预留 10.20.0.0/16 给测试环境，避免与本地 IDC 的 192.168.0.0/16 冲突。

2. 默认多 AZ，关键系统跨区域。无状态服务至少部署在两个 AZ，数据库使用多 AZ 主备；对 RTO 要求极高的系统，再叠加跨区域只读副本或 Pilot Light。

3. 分层隔离，最小权限。用公有子网承载负载均衡与 NAT 网关，私有子网承载应用与数据库，数据库子网不设默认路由。安全组按“应用—数据库”逐层授权，而不是整段放行。

4. 就近接入，回源收敛。公网入口优先使用 CloudFront 或 Global Accelerator，把用户接入点前移到边缘，回源流量集中到区域入口，减少公网暴露面。

5. 用标签和流日志建立可观测性。为 VPC、子网、NAT 网关打上 Environment、CostCenter 标签，开启 VPC Flow Logs，才能在故障时快速定位是安全组拒绝、路由缺失还是 NAT 端口耗尽。

四、一个可参考的起步示例

假设某企业要在新加坡区域部署一套面向东南亚用户的电商系统，本地 IDC 网段为 192.168.0.0/16。可以这样起步：