在云架构设计中，网络拓扑结构决定了工作负载的隔离边界、连通路径和性能表现。很多团队在初期只关注计算和存储选型，等到业务上线后才被迫重构网络，代价高昂。本文不打算罗列概念，而是直接给出规划路径：先明确边界，再逐层设计，最后验证取舍。所有结论基于 AWS 官方文档，并会指出适用条件和不确定性。
网络拓扑规划的第一步：明确隔离与连通边界
任何云网络规划都始于一个问题：哪些资源需要互相访问，哪些必须隔离？AWS EC2 文档指出，EC2 实例是云中的虚拟服务器，你可以配置安全性和网络。但网络拓扑的起点不是实例，而是 VPC（虚拟私有云）。VPC 提供了逻辑隔离的网络环境，你可以在其中定义 IP 地址范围、子网、路由表和网关。
规划前，先列出所有工作负载的通信需求：
- 哪些组件需要公网访问？
- 哪些组件只能内网访问？
- 哪些环境（如开发、测试、生产）必须隔离？
- 是否需要与本地数据中心互通？
这些答案决定了 VPC 的数量和子网划分。常见做法是：每个环境一个 VPC，或者使用一个 VPC 内的多个子网来分隔环境。前者隔离性更强，但成本更高；后者更经济，但需要严格的安全组和网络 ACL 控制。AWS Well-Architected 安全性支柱强调，安全设计应基于最佳实践，网络隔离是基础。
规划 VPC 与子网：CIDR 和可用区设计
VPC 的 IP 地址范围（CIDR）一旦确定，就不能轻易更改，因此要预留足够空间。建议使用 RFC 1918 私有地址段，如 10.0.0.0/16，并避免与其他 VPC 或本地网络冲突。子网通常按层划分：公有子网（放置负载均衡器、NAT 网关）和私有子网（放置应用、数据库）。
关键决策：子网应跨多个可用区（AZ）以提高可用性。AWS EC2 文档提到，你可以根据需求扩展或缩减容量，但网络设计要提前考虑高可用。每个子网必须关联一个路由表，路由表决定了流量去向。例如，公有子网的路由表通常包含指向 Internet 网关的默认路由，而私有子网则通过 NAT 网关访问外网。
常见误区：将数据库放在公有子网，或所有实例堆在单个可用区。这会导致安全风险或单点故障。正确的做法是至少使用两个可用区，并将不同层放在不同子网。
安全组与网络 ACL：两层防护的取舍
安全组是实例级别的虚拟防火墙，网络 ACL 是子网级别的防火墙。AWS 官方文档指出，安全组是有状态的，而网络 ACL 是无状态的，这意味着你需要显式配置回程流量。规划时，通常以安全组为主，网络 ACL 作为额外防线。
操作步骤：
- 为每个应用层创建安全组，只开放必要的端口和来源。
- 最小权限原则：仅允许特定安全组之间的通信，避免使用 0.0.0.0/0。
- 在子网级别设置网络 ACL，用于阻断已知恶意 IP 或限制管理端口。
失败条件：安全组规则过于宽松，或网络 ACL 规则顺序错误导致流量中断。安全组是状态化的，允许返回流量，但网络 ACL 需要同时配置入站和出站规则。一个常见错误是只配置了入站规则，忘记配置出站规则，导致请求失败。
连接外部网络：Internet 网关、NAT 与混合云
如果工作负载需要对外提供服务，需要 Internet 网关（IGW）和弹性 IP。如果私有子网中的实例需要访问外网（如拉取更新），则需要 NAT 网关。NAT 网关是托管服务，但会产生费用，需要权衡成本。AWS 成本优化支柱强调，成本优化的目标是充分利用资源，实现最低价格点。因此，对于非生产环境，可以考虑使用 NAT 实例替代，但需要自行管理。
混合云场景：如果需要与本地数据中心互通，可以使用 AWS Direct Connect 或 VPN。Direct Connect 提供稳定低延迟的专用连接，但成本较高；VPN 基于公网，成本低但延迟和可靠性较差。规划时，要根据业务对延迟和数据量的要求选择。
跨 VPC 通信与网络服务：VPC Peering 与 Transit Gateway
当多个 VPC 需要通信时，可以使用 VPC Peering 或 Transit Gateway。VPC Peering 是一对一的连接，配置简单，但不支持传递路由。如果 VPC 数量多，建议使用 Transit Gateway，它作为中心枢纽，简化网络管理。但 Transit Gateway 有附加成本，需要评估。
另外，AWS 提供了托管网络服务，如 Elastic Load Balancing、API Gateway 等，它们可以简化网络拓扑。例如，使用 Application Load Balancer 将流量分发到多个实例，避免暴露实例本身。ZuCDN 上有一篇关于 APIGW 与 Knative 实现弹性扩容的文章，可参考其架构思路。
成本与性能的平衡：规划中的取舍
网络拓扑直接影响成本。NAT 网关、Transit Gateway 等都有小时计费和数据传输费用。设计时，应考虑：
- 是否所有子网都需要 NAT？能否合并？
- 是否可以使用 VPC Endpoint 避免公网数据传输费用？
- 跨可用区数据传输会产生费用，尽量将通信密集的组件放在同一可用区，但要注意可用性。
性能方面，EC2 实例的网络性能取决于实例类型，文档中提到不同实例类型提供不同的网络能力。如果对网络吞吐有要求，应选择支持增强联网的实例，并配置适当的队列深度。
常见误区与检查清单
最后，总结几个常见误区：
- 子网划分过细或过粗，导致 IP 浪费或路由复杂。
- 忽略路由表传播，导致网络不通。
- 安全组规则顺序错误或语法错误。
- 忘记配置 DHCP 选项集，导致 DNS 解析失败。
规划完成后，建议使用 AWS 提供的工具（如 Reachability Analyzer）验证路径。同时，参考 Well-Architected 框架的六大支柱，持续审查架构。
参考资料
延伸阅读