AWS VPC Intro

背景

VPC 是在 AWS 云中构建任何应用架构的基石。它为云资源提供了一个逻辑隔离的网络环境，使用户能够完全掌控虚拟网络的配置，包括 IP 地址范围、子网划分、路由策略和安全控制。

AWS VPC 核心架构与关键组件

CIDR 地址块

当您创建一个 VPC 时，首要任务是为其分配一个采用无类别域间路由（CIDR）表示法的 IP 地址范围（例如 10.0.0.0/16）。这个 CIDR 地址块定义了 VPC 内部可用的私有 IP 地址池。进行 IP 地址规划时，必须深思熟虑，确保所选范围不会与您可能需要连接的其他网络（如本地数据中心或其他 VPC）产生重叠。这是避免未来网络集成时出现地址冲突的关键一步。

子网（公有与私有）

子网是从 VPC 的 CIDR 地址块中划分出的一个更小的 IP 地址范围，它构成了 VPC 内部资源部署的基本单元。一个核心特性是，每个子网都必须完整地存在于某一个**单一的可用区（Availability Zone, AZ）**内。

根据其路由配置和网络可达性，子网通常被划分为两类：

• 公有子网：其关联的路由表中包含一条指向互联网网关 (IGW) 的路由。这使得子网内的资源（如果分配了公网 IP）能够直接与互联网进行双向通信。典型用例是部署需要面向公众提供服务的资源，如 Web 服务器或应用负载均衡器 (ALB)。
• 私有子网：其路由表中没有直接通往互联网的路由。子网内的资源无法被互联网直接访问，从而提供了更高的安全隔离性。典型用例是部署核心业务逻辑（如应用服务器）和敏感数据存储（如数据库服务器）。

为了实现架构的高可用性，最佳实践是在至少两个不同的可用区中创建对应的公有和私有子网，并将应用资源分布其中。

路由与网关

路由表

路由表包含一系列被称为“路由”的规则，用于决定从子网发出的网络流量应被导向何处。每个子网都必须关联一个路由表。例如，公有子网的路由表会将所有目标为互联网（0.0.0.0/0）的流量指向互联网网关，而私有子网的路由表则可能将此类流量指向 NAT 网关。

互联网网关 (IGW)

互联网网关 (IGW) 是一个水平扩展、高可用的 VPC 组件，它允许您的 VPC 与公共互联网之间进行通信。将一个 IGW 附加到 VPC，并在子网的路由表中创建指向它的路由，是构建公有子网、使其能够访问互联网的先决条件。

NAT 网关

NAT 网关是一项 AWS 托管的网络地址转换（NAT）服务，其核心功能是允许私有子网中的实例（如数据库或后台应用）能够发起出站连接到互联网（例如，下载软件包更新或调用外部 API），同时阻止来自互联网的未经请求的入站连接。这极大地增强了内部资源的安全性，因为它们无需暴露公网 IP。需要注意的是，NAT 网关是一项托管服务，会产生小时使用费用和每 GB 数据处理费用。

网络安全层

VPC 提供了两个主要的网络安全层，用于实现精细化的访问控制：安全组和网络访问控制列表 (NACLs)。

最佳实践总结：将安全组作为保护实例的第一道、也是最主要的防线。它提供精细化的、有状态的访问控制。而 NACLs 则可作为可选的、粗粒度的第二层防护，用于在子网级别执行更广泛的网络隔离策略。

VPC 端点

VPC 端点使得您的 VPC 能够私密地连接到受支持的 AWS 服务，而无需通过公共互联网。这意味着流量完全在 AWS 的内部网络中传输，从而显著提升了安全性，并可能降低数据传输成本。VPC 端点主要有两种类型：

网关端点

网关端点通过在您的路由表中添加一个目标来实现与服务的连接。它目前仅支持 Amazon S3 和 Amazon DynamoDB。其最大的优势在于不产生任何额外费用。通过配置网关端点，私有子网中的实例可以直接访问 S3，而无需经过 NAT 网关，从而节省了数据处理成本。

接口端点 (AWS PrivateLink)

接口端点通过在您的子网中创建一个弹性网络接口（ENI）来工作，它为目标服务提供一个私有 IP 入口。它支持更广泛的 AWS 服务以及通过 AWS PrivateLink 提供的第三方服务。与网关端点不同，接口端点会产生每小时使用费用和每 GB 数据处理费用。

将这些基础组件有机地组合起来，我们便可以构建出满足各种业务需求的复杂网络架构。下一章节将通过一个实例来展示如何实现这一点。

典型应用架构：构建安全高可用的三层网络

本章将通过一个真实的多层 Web 应用部署案例，具体展示如何综合运用上一章节介绍的 VPC 核心组件，来构建一个既安全又具备高可用性的网络环境。

架构设计详解

该架构的核心是构建一个跨越多个可用区（AZ）的 VPC，以确保应用具备弹性和灾难恢复能力。

• VPC 整体设计: VPC 的 CIDR 地址块经过精心规划，并横跨至少两个可用区进行部署。在每个可用区内，都创建了公有子网和私有子网。
• 公有子网层 (Web/Public Tier):
  • 部署内容: 该层部署了所有需要直接与互联网交互的组件。核心是应用负载均衡器 (Application Load Balancer, ALB)，它作为所有外部流量的统一入口，并将请求分发到后端的应用服务器。
  • 高可用性: 为了实现高可用性，每个可用区的公有子网中都部署了一个托管的 NAT 网关。这确保了即使一个 AZ 的 NAT 网关出现问题，另一 AZ 的私有子网实例仍能访问互联网。
  • 路由: 该层子网的路由表配置了一条默认路由（0.0.0.0/0），将所有出站流量指向互联网网关 (IGW)。
• 私有子网层 (Application/Database Tier):
  • 部署内容: 该层承载了应用的核心业务逻辑（如 EC2 应用服务器）和敏感数据（如数据库服务器）。这些资源不分配公网 IP 地址，从而最大程度地减少了攻击面。
  • 出站访问: 当应用服务器需要访问互联网以下载更新或调用外部 API 时，其出站流量会被路由到其所在可用区的 NAT 网关。
  • 路由: 该层子网的路由表将默认路由（0.0.0.0/0）指向NAT 网关。
• 安全策略实施 (纵深防御): 通过安全组实现了分层、精细化的访问控制，贯彻了“最小权限”原则：
  • ALB 安全组：仅允许来自互联网的 HTTP (80) 和 HTTPS (443) 流量。
  • 应用服务器安全组：仅允许来自 ALB 安全组的流量，拒绝其他所有入站连接。
  • 数据库服务器安全组：仅允许来自应用服务器安全组的特定数据库端口（如 3306）的流量。
• 成本与安全优化: 在该架构中，如果应用服务器需要频繁访问 Amazon S3（例如，读写静态文件），标准路径是通过 NAT 网关。这不仅会产生 NAT 网关的数据处理费用，还会将流量短暂暴露在公网路径上。通过为 S3 创建一个网关 VPC 端点，我们可以让应用服务器直接通过 AWS 内部网络访问 S3。这一简单配置带来了双重收益：
  1. 提升安全：流量不离开 AWS 网络，降低了数据暴露风险。
  2. 节省成本：绕过了 NAT 网关，从而完全消除了这部分流量产生的 NAT 网关数据处理费用。

该三层架构完美体现了最小权限和纵深防御等核心安全原则。然而，随着企业业务的扩展，单一 VPC 往往无法满足所有需求，此时，如何安全高效地连接多个 VPC 成为了新的挑战。

多VPC网络连接方案深度对比分析

随着企业云上业务的扩张和成熟，采用多个 VPC 进行环境隔离（如开发、测试、生产环境分离）或业务单元隔离已成为标准实践。这带来了新的挑战：如何让这些隔离的 VPC 之间在需要时进行安全、可控的通信。本章将深度对比分析解决这一问题的两种核心方案：VPC 对等连接和 AWS Transit Gateway。

VPC 对等连接 (VPC Peering)

VPC 对等连接 (VPC Peering) 是一种在两个 VPC 之间建立的点对点网络连接技术。建立对等连接后，两个 VPC 中的实例可以使用私有 IP 地址进行通信，仿佛它们处于同一个网络中。

• 优点:
  • 设置简单：创建和接受一个对等连接请求即可。
  • 高性能低延迟：流量在 AWS 的内部骨干网络上传输。
  • 成本效益高：没有小时使用费用。仅对跨可用区传输的数据收取少量的数据传输费（同区域跨 AZ 约为 $0.01/GB，每个方向单独计费）。在同一 AZ 内的数据传输通常是免费的。
• 局限性:
  • 不支持传递性路由 (Transitive Routing)：如果 VPC A 与 VPC B 对等，VPC B 与 VPC C 对等，那么 VPC A 不能通过 VPC B 自动与 VPC C 通信。必须在 A 和 C 之间建立一个独立的对等连接。
  • 管理复杂性：当需要互联的 VPC 数量增多时，对等连接会形成一个难以管理的“网状 (Mesh)”拓扑结构，连接数量会呈指数级增长。
• 适用场景: 最适用于少数（通常少于 10 个）VPC 之间，且网络拓扑简单的连接需求。

AWS Transit Gateway (TGW)

AWS Transit Gateway (TGW) 是一种托管的云路由器，它充当区域网络中心，采用中心辐射型 (Hub-and-Spoke) 架构来连接成千上万的 VPC 和本地网络。

• 优点:
  • 高度可扩展：单个 TGW 在一个区域内可以连接多达 5000 个 VPC，极大地简化了大规模网络管理。
  • 支持传递性路由：连接到 TGW 的任何 VPC 都可以与其他任何连接的 VPC 通信（受路由表控制），无需建立点对点连接。
  • 集中管理：TGW 提供了一个中心化的管理点，用于控制 VPC 间以及 VPC 与本地网络（通过 VPN 或 Direct Connect 连接）之间的路由。
• 权衡因素:
  • 成本较高：TGW 是一项托管服务，会产生每小时连接费用（即每个挂载到 TGW 的 VPC 或 VPN 连接）和每 GB 数据处理费用。例如，一个 VPC 挂载的小时费约为 $0.05，数据处理费约为$0.02/GB。
• 适用场景: 适用于大规模、复杂的企业级多 VPC 环境，特别是需要连接多个 AWS 账户、多个 VPC 以及本地数据中心的企业。

决策依据与对比总结

多个关键维度对这两种方案进行了全面对比：

在解决了网络层（Layer 3）的连接性问题后，现代化的微服务应用架构还需要考虑更高层次的通信需求。这便引出了 AWS 在应用网络层（Layer 7）的创新服务——VPC Lattice。

高级应用网络功能：AWS VPC Lattice 剖析

随着云原生和微服务架构的普及，应用间的通信变得日益复杂。为了应对这一挑战，AWS 的网络服务正在向应用层演进。本章将介绍 AWS VPC Lattice，这是一个专注于简化服务到服务（service-to-service）通信的高级应用网络服务。

VPC Lattice 的定位与价值

AWS VPC Lattice 是一个全托管的应用层网络服务，其核心目标是简化跨 VPC 和跨 AWS 账户的服务发现、连接、安全和监控。

它与我们之前讨论的 Transit Gateway 或 VPC Peering 有着本质的区别：

• VPC Lattice 工作在应用层 (Layer 7)：它处理的是服务间的 HTTP/HTTPS 请求和 gRPC 调用，而不是底层的 IP 流量。
• Transit Gateway / Peering 工作在网络层 (Layer 3)：它们负责在 VPC 之间路由 IP 数据包。

VPC Lattice 的核心价值在于，它将开发人员从复杂的底层网络配置（如 IP 路由、安全组规则、对等连接管理）中解放出来。开发人员只需将他们的服务（如运行在 ECS、EKS 或 Lambda 上的应用）注册到一个“服务网络”中，Lattice 就能自动处理服务发现和请求路由。它还提供了一个统一的平台来实施流量管理策略、健康检查、认证和授权（可与 IAM 集成）。简而言之，Transit Gateway 和 Peering 关心的是 IP 数据包能否从一个VPC到达另一个VPC；而 VPC Lattice 关心的是“订单服务”能否安全地调用“库存服务”，而无需关心底层的IP地址和路由。

适用场景分析

VPC Lattice 特别适用于以下场景：

• 跨 VPC 部署的微服务应用：当一个复杂应用的多个微服务分布在不同的 VPC 中时，Lattice 可以极大地简化它们之间的通信。
• 多账户间的服务共享：当一个团队的服务需要被另一个 AWS 账户中的应用安全地调用时，Lattice 提供了一种标准化的解决方案。
• 统一的服务间通信治理：希望以统一、声明式的方式管理所有服务间通信的流量规则、访问控制和可观测性。

需要明确的是，VPC Lattice 并非 VPC 基础组件的替代品，而是构建在其之上的一个高级抽象层。对于架构师而言，当您的系统演进到多 VPC、多账户的微服务级别，且面临日益复杂的跨服务通信管理挑战时，应积极评估引入 VPC Lattice 以简化架构和运维。

在设计了功能强大的网络架构后，确保其长期可持续性的关键在于成本控制。下一章节将深入探讨如何系统性地优化 VPC 相关的成本。

AWS VPC 成本优化策略

虽然 VPC 本身是免费创建和使用的，但其关联的众多组件和服务却可能成为 AWS 账单上显著的成本来源。本章旨在系统性地分析 VPC 环境中的主要成本构成，并提供一系列具体、可行的优化策略，帮助您在不牺牲性能和安全性的前提下，有效控制云网络支出。

识别VPC成本驱动因素

要优化成本，首先需要了解费用来自何处。以下是 VPC 环境中最主要的计费项：

• NAT 网关: 按小时和数据处理量 (GB) 双重计费。数据密集型应用的出站流量会使其成本迅速增加。
• Transit Gateway: 按小时连接数（每个 VPC 挂载）和数据处理量 (GB) 计费，是企业级网络的核心成本之一。
• 接口 VPC 端点: 按小时和数据处理量 (GB) 计费。
• 跨可用区 (AZ) 数据传输: EC2 实例之间、通过 VPC Peering 或 Transit Gateway 传输的流量，如果跨越了 AZ 边界，都会产生数据传输费用。
• 公网 IPv4 地址: 无论是弹性 IP (EIP) 还是实例自动分配的公网 IP，使用中的公网 IPv4 地址都会产生小时费用。
• 其他服务: 一些高级功能，如 IPAM (IP 地址管理器) 的高级版（按每个活动 IP 每小时 $0.00027 计费）和 流量镜像 (Traffic Mirroring) （按每个 ENI 每小时$0.015 计费），也都有其自身的计费模式。

成本优化

针对上述成本驱动因素，可以采取以下具体优化措施：

优化NAT网关成本

• 善用免费的网关端点：对于需要访问 Amazon S3 和 DynamoDB 的私有子网实例，务必配置网关 VPC 端点。这部分流量将通过 AWS 内部网络直达服务，完全绕过 NAT 网关，从而节省 100% 的相关数据处理费用。
• 评估接口端点效益：对于其他 AWS 服务，计算通过接口端点的成本（小时费 + 数据处理费）与通过 NAT 网关的成本（小时费 + 数据处理费）之间的差异。对于流量大且稳定的服务，使用接口端点通常更具成本效益和安全性。
• 同 AZ 部署：将通信密集型的应用组件部署在同一个可用区内，可以避免产生跨 AZ 数据传输成本，这部分流量也就无需通过 NAT 网关处理。

优化数据传输成本

• 优化架构布局：在设计应用架构时，优先将产生高流量的组件（如应用服务器与数据库）放置在同一个可用区，以消除跨 AZ 数据传输费用。
• 智能选择连接方案：对于仅有两个 VPC 且流量不大的场景，使用 VPC Peering 远比 Transit Gateway 更经济，因为它没有小时连接费用。

优化端点和网关成本

• 定期审查与清理：养成定期审查网络资源的习惯。及时删除不再使用的接口端点、NAT 网关和 Transit Gateway 连接。例如，一个闲置的 NAT 网关每月仍会产生约 32 美元的小时费用，即使没有处理任何数据。
• 按需启停：对于开发和测试环境，可以考虑在非工作时间通过自动化脚本关闭 NAT 网关，以节省小时费用。

优化IP地址成本

• 释放闲置 EIP：AWS 对未绑定到正在运行实例的弹性 IP (EIP) 会收取少量费用。定期检查并释放所有不再需要的 EIP。
• 减少公网 IP 使用：审查应用架构，确认哪些实例真正需要公网 IPv4 地址。尽可能通过内部负载均衡器、私有 IP 或堡垒机进行通信，减少公网 IP 的使用量。

成本优化是一个持续的过程，而构建一个遵循设计最佳实践的架构，是实现长期成本效益和技术卓越的根本途径。

VPC 设计与管理最佳实践

遵循一系列经过行业验证的 VPC 设计与管理最佳实践，是构建一个安全、可扩展、高可用且易于维护的云网络基础的保障。本章将总结这些核心原则，为您的云网络设计提供指导。

7.2 核心最佳实践

1. 精心规划IP地址空间：在创建 VPC 之前，务必仔细规划 CIDR 地址块。选择一个唯一的、与您的本地网络或其他云环境无重叠的 IP 范围。同时，为未来的业务增长预留充足的地址空间，避免日后因地址耗尽而进行复杂的网络迁移。
2. 利用多可用区实现高可用：始终将您的子网和关键资源（如 EC2 实例、RDS 数据库、NAT 网关）分布在至少两个不同的可用区（AZ）中。这是构建容错和高可用性应用架构的基石，能够有效抵御单个 AZ 级别的故障。
3. 贯彻公私分明的子网设计：严格分离面向公众的服务和内部核心服务。将 Web 服务器、负载均衡器等需要直接暴露给互联网的资源放置在公有子网中；而应用服务器、数据库、缓存等核心组件则应部署在私有子网中，从而最小化攻击面。
4. 优先使用安全组进行访问控制：将安全组作为实例级别访问控制的第一道防线。遵循“最小权限”原则，仅开放必要的端口和源 IP。由于安全组是有状态的，管理起来比 NACLs 更简单直观。仅在需要在子网级别实施无状态的、粗粒度的拒绝规则时，才使用 NACLs 作为补充。
5. 通过基础设施即代码（IaC）实现自动化：强烈建议使用 AWS CloudFormation 或 Terraform 等工具（例如，广受欢迎的 Terraform AWS VPC 模块）来定义和管理您的 VPC 配置。通过 IaC，您可以确保网络环境的一致性、可重复性和版本控制，显著减少人为错误，并简化部署和变更流程。
6. 启用VPC流日志进行监控与审计：为您的 VPC 或关键子网启用 VPC Flow Logs。它能够捕获进出网络接口的 IP 流量信息，并将日志发送到 CloudWatch Logs 或 S3。这对于网络故障排查、安全事件分析和满足合规性审计要求具有不可估量的价值。
7. 利用网络分析工具进行验证：善用 AWS 提供的网络分析工具，如 Reachability Analyzer 和 Network Access Analyzer。前者可以帮助您主动验证两个网络端点之间是否存在有效的网络路径；后者则能分析您的网络配置，识别潜在的、非预期的网络访问路径。
8. 通过隔离环境增强安全性：为不同的环境（如开发、测试、生产）或不同的业务单元使用独立的 VPC。这种隔离策略可以有效控制变更的“爆炸半径”，并增强整体安全性。然后通过 Transit Gateway 或 VPC Peering 进行受控的、按需的连接。
9. 定期审查和清理配置：云环境是动态变化的。应定期审计安全组规则（特别是开放给 0.0.0.0/0 的规则）、路由表、VPC 端点和弹性 IP。及时移除不再需要的资源和规则，不仅能降低成本，还能减少潜在的安全风险。

参考

AWS 官方文档