[解决方案] 探索 AWS 网络负载均衡器的数据传输成本

[解决方案] 探索 AWS 网络负载均衡器的数据传输成本   # 产品功能分析 ## 新功能/新产品概述本文探讨了 **Network Load Balancer (NLB)** 在数据传输成本方面的功能和应用，旨在帮助用户优化 AWS 上的数据传输费用。**NLB** 作为 AWS 弹性负载均衡服务的一部分，提供高可用性、自动扩展和安全支持，适用于处理高性能网络流量场景。核心目标是阐明数据传输收费规则，针对不同网络边界（如可用区、VPC 和区域）进行分析。该功能适用于需要精细成本管理的应用，例如 Web 服务或大规模网络架构，目标用户群包括企业架构师和 DevOps 工程师，在云计算市场中定位为提升负载均衡效率的实用工具。 ## 关键客户价值 - **成本优化**：通过理解数据传输收费，用户可以避免不必要的费用，例如在同一可用区内传输数据时无收费，提升了资源利用率，与传统负载均衡相比，**NLB** 的按用量付费模型允许更精确的预算控制。 - 在同一 AZ 和 VPC 内（如场景 1.1），无数据传输费用，实现零成本内部通信，适用于内部应用，提升整体业务效率。 - **差异化优势**：相比 **Application Load Balancer (ALB)** 和 **Classic Load Balancer (CLB)**，**NLB** 在跨可用区传输时收取 $0.01/GB（场景 1.2），但 ALB 和 CLB 在类似场景下可能无费用，这突显 **NLB** 在高性能网络中的权衡，提供更低延迟的优势，但需用户评估跨 AZ 成本。 - 在互联网流量场景（如场景 2.1），分层定价（如 N. Virginia 区域 $0.05-0.09/GB）帮助跨区域用户管理外部流量成本，体现出在全球部署中的灵活性。 - **场景适应性**：在不同使用场景中，这些价值显著降低运维复杂性，例如通过 VPC Peering 无费用传输（场景 1.3），使多 VPC 架构更具经济性，但跨区域流量（如场景 2.3，$0.02/GB）可能增加成本，需结合 AWS Well-Architected 框架优化。 ## 关键技术洞察 - **技术独特性**：**NLB** 基于 Elastic Network Interface (ENI) 和子网部署，实现高可用性跨可用区流量管理，工作原理涉及路由流量通过特定 IP 和 ENI，确保毫秒级响应。数据传输收费机制依赖于流量边界，例如跨 AZ 时收取 $0.01/GB，在同一 AZ 内免费，这体现了 AWS 的按需付费模型。 - 创新点在于结合 **VPC Peering** 和 **Internet Gateway (IGW)** 的集成，支持无额外收费的内部通信，提升性能和可用性，但跨区域传输（如 eu-central-1 到 us-east-1 的 $0.02/GB）可能导致延迟增加。 - **对性能和安全性的影响**：该功能增强了资源利用率，通过自动扩展处理突发流量，但跨边界收费可能增加管理复杂度，限制了大规模组网的成本可控性。技术挑战包括流量监控的精确性，AWS 通过 **CloudWatch** 指标提供动态调整，但冷启动或高并发场景下需关注潜在费用上升。 - 优势在于高性能网络支持，但局限性是定价依赖区域差异，可能在全球应用中要求额外规划。 ## 其他信息 - 文章强调参考最新 **Amazon EC2 定价页面** 以获取准确费用，并建议结合 AWS Well-Architected 框架的成本优化支柱进行架构审查，以最大化价值。作者包括 AWS 资深解决方案架构师，提供专业指导。   # 探索 AWS 网络负载均衡器 (Network Load Balancer) 的数据传输成本 **原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/exploring-data-transfer-costs-for-aws-network-load-balancers/](https://aws.amazon.com/blogs/networking-and-content-delivery/exploring-data-transfer-costs-for-aws-network-load-balancers/) **发布时间:** 2025-04-08 **厂商:** AWS **类型:** BLOG --- 在本帖中，我们探讨 [Amazon Elastic Compute Cloud (Amazon EC2)] 数据传输成本如何适用于 [Network Load Balancer (NLB)] 与客户端以及目标实例之间的通信，在多种场景中，以帮助您优化 Amazon Web Services (AWS) 上的数据传输成本。对于 Classic Load Balancer 和 Application Load Balancer，请查看我们的帖子，[探索 Classic 和 Application Load Balancers 的数据传输成本](https://aws.amazon.com/blogs/networking-and-content-delivery/exploring-data-transfer-costs-for-classic-and-application-load-balancers/)。 Elastic Load Balancing 提供四种类型的负载均衡器，所有类型都支持高可用性、自动 scaling 和强大的安全特性，用于您的应用程序：[Application Load Balancer (ALB)](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/)、[Network Load Balancer (NLB)](https://aws.amazon.com/elasticloadbalancing/network-load-balancer/)、[Gateway Load Balancer (GWLB)](https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/) 和 [Classic Load Balancer (CLB)](https://aws.amazon.com/elasticloadbalancing/classic-load-balancer/)。我们重点关注 NLB 时，可以审视其按量付费成本模型。对于 NLB，您需要为每个小时（或部分小时）运行的 NLB 付费，以及每小时使用的 Load Balancer Capacity Units (LCU) 数量。我们在 [Elastic Load Balancing 定价页面](https://aws.amazon.com/elasticloadbalancing/pricing/) 上提供了这些主题的详细信息。当流量在客户端和负载均衡器之间，或负载均衡器和目标实例之间，跨越 [Availability Zone (AZ)](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)、[Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc/) 和 AWS Region 边界时，Amazon EC2 数据传输费用会适用。在本帖中，我们审视 Network Load Balancers 的所有数据传输费用。 *本帖展示的是发布时的定价，并假设没有批量折扣或适用的税费和关税。为演示目的，我们将主要 Region 指定为 US East (Northern Virginia)，次要 Region 为 Europe (Frankfurt)。请始终参考 [Amazon EC2 定价页面](https://aws.amazon.com/ec2/pricing/on-demand/) 以获取最新定价。所有价格均以 USD 为单位。* ## 先决条件和假设本帖假设您熟悉 NLB。本帖中探讨的场景旨在简洁地展示数据传输费用。在设计使用负载均衡器的架构时，请遵守 [AWS Well-Architected 框架](https://aws.amazon.com/architecture/well-architected/?wa-lens-whitepapers.sort-by=item.additionalFields.sortDate&wa-lens-whitepapers.sort-order=desc&wa-guidance-whitepapers.sort-by=item.additionalFields.sortDate&wa-guidance-whitepapers.sort-order=desc)，成本优化仅是六大支柱之一。因此，我们建议您在考虑所有支柱时审视您的架构。 ## 费用摘要以下图表（图 1）提供了各种路径费用的视觉表示，用于快速参考。本帖后续将涵盖真实场景，这些场景的费用遵循图表中所示规则。所示值为 US East (N. Virginia) ‘us-east-1’ Region。 ![数据传输使用 NLB 的费用摘要](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2025/04/03/nlb_dt_summary_charges.png) 图 1 – 数据传输使用 Network Load Balancers 的费用摘要在我们探讨示例架构以及这些费用如何应用之前，我们可以审视 NLB 如何在多个 AZ 中部署以实现高可用性和弹性。 ## NLB 和 AZ NLB 可以配置在一个或多个 AZ 中。对于每个 AZ，当您部署 NLB 时，必须选择一个子网，其中负载均衡器有一个 IP，这也意味着它在该子网中有一个 Elastic Network Interface (ENI)。在本帖中，我们所涵盖的场景中，当我们表示一个 AZ 中的负载均衡器时，是指存在于该 AZ 中的 IP 和 ENI。以下图表（图 2）展示了 NLB 的部署模型，显示了一个面向互联网的负载均衡器部署在两个 AZ 中的两个公共子网中，为私有子网中的目标实例提供客户端流量，并启用跨区负载均衡。 ![图 2: NLB 的多 AZ 部署模型](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2025/04/03/nlb_azs.png) 图 2: NLB 的多 AZ 部署模型 ## 场景为便于您浏览本帖，我们将不同场景分组如下： - 数据传输成本对于 **内部** NLB - 场景 1.1: 同一 VPC 内，同一 AZ - 场景 1.2: 同一 VPC 内，跨 AZ - 场景 1.3: 跨 VPC 使用 VPC peering，同一 AZ 内 - 数据传输成本对于 **面向互联网** NLB - 场景 2.1: 来自互联网的客户端流量 - 场景 2.2: 同一 Region 的客户端流量 - 场景 2.3: 跨 Region 的客户端流量 ## 内部 NLB 的数据传输成本在这些场景中，我们关注负载均衡器内流量的费用。 ## 场景 1.1: 同一 VPC 内，同一 AZ 在以下图表（图 3）中，客户端、NLB 和 NLB 目标实例都位于同一 VPC 和 AZ 中。由于所有流量都保持在同一 AZ 和 VPC 内，因此任何方向的流量都不会产生数据传输费用。 ![图 3: 场景 1.1 – 客户端和目标实例与 NLB ENI 在同一 AZ](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2025/04/03/1.1-client-target-same-AZ.png) 图 3: 场景 1.1 – 客户端和目标实例与 NLB ENI 在同一 AZ ## 场景 1.2: 同一 VPC 内，跨 AZ 在以下图表（图 4）中，当流量跨 AZ 时，客户端和负载均衡器之间的传入和传出流量每 GB 收取 $0.01。从负载均衡器到目标实例，没有费用，因为它们位于同一 AZ。 ![图 4: 场景 1.2 – 客户端和 NLB ENI 在不同 AZ](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2025/04/03/1.2-client-eni-different-azs.png) 图 4: 场景 1.2 – 客户端和 NLB ENI 在不同 AZ 然而，如果目标实例位于与 NLB ENI 不同的 AZ（如图 5 所示，这可能发生在启用跨区的负载均衡器中），则负载均衡器和目标实例之间的传入和传出流量每 GB 也会收取 $0.01。这些场景在使用 ALB 和 CLB 时不会收费，如帖子 [探索 Classic 和 Application Load Balancers 的数据传输成本](https://aws.amazon.com/blogs/networking-and-content-delivery/exploring-data-transfer-costs-for-classic-and-application-load-balancers/) 中的场景 1.2 所述。 ![图 5: 场景 1.2 – 客户端和目标实例与 NLB ENI 在不同 AZ](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2025/04/03/1.2-client-eni-target-different-azs.png) 图 5: 场景 1.2 – 客户端和目标实例与 NLB ENI 在不同 AZ ## 场景 1.3: 跨 VPC 使用 VPC peering，同一 AZ 内在以下图表（图 6）中，任何流量方向都不会产生数据传输费用。这是因为尽管流量跨 VPC，但它保持在同一 AZ 内。 ![图 6: 场景 1.3 – 客户端和 NLB ENI 在同一 AZ 但不同 VPC。目标实例和 NLB ENI 在不同 AZ 和 VPC](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2025/04/03/1.3-client-eni-same-az-different-vpc.png) 图 6: 场景 1.3 – 客户端和 NLB ENI 在同一 AZ 但不同 VPC。目标实例和 NLB ENI 在不同 AZ 和 VPC ## 面向互联网 NLB 的数据传输成本在这些场景中，我们关注客户端和负载均衡器之间的流量费用。对于负载均衡器和目标实例之间的费用细节，请参考前面的场景 1.1、1.2 和 1.3。在这些示例中，NLB 和目标实例位于同一 AZ。 ## 场景 2.1: 来自互联网的客户端流量在以下图表（图 7）中，数据从客户端通过 NLB 传输到互联网。更具体地说，返回流量通过 NLB 回传到客户端。这种数据传输的定价是分层的，并根据 AWS Region 而变化。对于 N. Virginia (US-EAST-1)，价格范围从 $0.05 到 $0.09。这些价格是本帖发布时的当前价格。要获取最新定价信息，请访问 [Amazon EC2 定价页面](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer_within_the_same_AWS_Region)。 ![图 7: 场景 2.1 – 传输数据到互联网客户端](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2025/04/03/2.1-internet-client.png) 图 7: 场景 2.1 – 传输数据到互联网客户端 ## 场景 2.2: 同一 Region 的客户端流量在以下图表（图 8）中，即使客户端位于同一 VPC，它使用公共 IP 连接到公共负载均衡器，这会导致流量通过 Internet Gateway (IGW) 并返回，每方向收取额外的 $0.01/GB。当使用 IGW 连接到同一 Region 中的公共 NLB 时，源和目标子网、AZ 和 VPC 对 Amazon EC2 数据传输费用没有影响。以下图表假设 NLB ENI 和目标实例在同一 AZ，因此没有数据传输费用。 ![图 8: 场景 2.2 – 客户端在同一 VPC 中通过公共 IP 连接到 NLB ENI。目标实例和 NLB ENI 在同一 AZ 和同一 VPC](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2025/04/03/2.1-client-same-vpc-public-ip.png) 图 8: 场景 2.2 – 客户端在同一 VPC 中通过公共 IP 连接到 NLB ENI。目标实例和 NLB ENI 在同一 AZ 和同一 VPC ## 场景 2.3: 跨 Region 的客户端流量在以下图表（图 9）中，请求来自 eu-central-1 Region 的客户端，每 GB 收取 $0.02。NLB 响应从 us-east-1 Region 传向客户端，每 GB 收取 $0.02。这个费用可能会根据涉及的 Region 而变化。请查看 [Amazon EC2 定价页面](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer_within_the_same_AWS_Region) 中“Data Transfer OUT From Amazon EC2 To”部分的完整表格以获取所有价格。 ![图 9: 场景 2.3 – 来自另一个 AWS Region 的客户端。目标实例和 NLB ENI 在不同 AZ 但同一 VPC](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2025/04/03/2.3-client-different-aws-region.png) 图 9: 场景 2.3 – 来自另一个 AWS Region 的客户端。目标实例和 NLB ENI 在不同 AZ 但同一 VPC ## 注意事项本帖中涵盖的所有费用都描述在 [Amazon EC2 定价页面](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer_within_the_same_AWS_Region)，并是发布时的当前信息。请参考定价页面以获取最新版本。 #### 场景 1.1 在同一 AZ 中，Amazon EC2、Amazon RDS、Amazon Redshift、Amazon ElastiCache 实例以及 Elastic Network Interfaces 之间传输的数据是免费的。 #### 场景 1.2: 在同一 AWS Region 中，跨 AZ 传输数据“in” 到和“out” 从 Amazon EC2、Amazon RDS、Amazon Redshift、Amazon DynamoDB Accelerator (DAX) 和 Amazon ElastiCache 实例、Elastic Network Interfaces 或 VPC Peering 连接，每方向收取 $0.01/GB。 ### 场景 1.3 在同一 AZ 中，Amazon EC2、Amazon RDS、Amazon Redshift、Amazon ElastiCache 实例以及 Elastic Network Interfaces 之间传输的数据是免费的。 ### 场景 2.1 Amazon EC2 定价页面详细说明了从 Amazon EC2 到互联网的数据传输“out”，请参阅“Data Transfer OUT From Amazon EC2 To Internet”部分。 ### 场景 2.2 在同一 AWS Region 中，跨 AZ 传输数据“in” 到和“out” 从 Amazon EC2、Amazon RDS、Amazon Redshift、Amazon DynamoDB Accelerator (DAX) 和 Amazon ElastiCache 实例、Elastic Network Interfaces 或 VPC Peering 连接，每方向收取 $0.01/GB。 ### 场景 2.3 Amazon EC2 定价页面详细说明了从 Amazon EC2 到各种位置的数据传输“out”，请参阅“Data Transfer OUT From Amazon EC2 To”部分。 ## 结论在本帖中，我们探讨了使用多个 NLB 场景的负载均衡器、客户端和目标实例时，Amazon EC2 数据传输费用如何计算，以帮助您优化 AWS 上的数据传输成本。我们建议您访问 [成本优化支柱 – AWS Well-Architected 框架](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html) 以了解其他成本优化机会。您还可以设置 [Cost and Usage Reports](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html) 来获取 NLB 的详细数据传输费用，并做出架构决策来优化成本。如需审视您的架构，请联系您的 AWS Solutions Architect 或 Technical Account Manager。如果您对本帖有疑问，请在 [AWS re:Post](https://repost.aws/) 上启动新线程，或联系 [AWS Support](https://aws.amazon.com/contact-us/)。 ## 作者介绍 ![](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2023/08/21/lucas-rolim.png) ### Lucas Rolim Lucas Rolim 是 Amazon Web Services (AWS) 的高级解决方案架构师，位于澳大利亚悉尼，隶属于 Application Networking 团队。他致力于帮助客户在 AWS 上做出明智决策。他的专长主要集中在 Networking 和 Security。 ![Luis Felipe Silveira da Silva](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2025/02/12/silluis-2024.jpg) ### Luis Felipe Silveira da Silva Luis Felipe 是首席解决方案架构师。他隶属于 Application Networking 团队，位于爱尔兰都柏林。利用 AWS 的广泛负载均衡和网络套件，他帮助客户设计和增强其工作负载。Luis Felipe 与客户和内部 AWS 团队密切合作，开发弹性架构并推广 AWS 网络解决方案的有效实施。