Exploring Data Transfer Costs for AWS Network Load Balancers

In this post, we explore how HAQM Elastic Compute Cloud (HAQM EC2) data transfer costs apply to the communication between Network Load Balancer (NLB), clients, and targets in multiple scenarios, to help you optimize data transfer costs on HAQM Web Services (AWS). For Classic and Application load balancers, visit our post, Exploring Data Transfer Costs for Classic and Application Load Balancers.

Elastic Load Balancing offers four types of load balancers, all featuring high availability, automatic scaling, and robust security support for your applications: Application Load Balancer (ALB), Network Load Balancer (NLB), Gateway Load Balancer (GWLB), and Classic Load Balancer (CLB).

As we focus on NLBs, we can review the pay-as-you-go cost model for it. For NLBs, you pay for each hour or partial hour that an NLB is running, and the number of Load Balancer Capacity Units (LCU) used per hour. We provide details on these topics on the Elastic Load Balancing pricing page.

When traffic between clients and Load Balancers, or between Load Balancers and their targets, crosses Availability Zone (AZ), HAQM Virtual Private Cloud (HAQM VPC), and AWS Region boundaries, HAQM EC2 Data Transfer charges apply. In this post, we review all data transfer charges for Network Load Balancers.

This post illustrates pricing at the time of publication and assumes no volume discounts or applicable taxes and duties. For demonstration purposes, we list the primary Region as US East (Northern Virginia) and the secondary Region as Europe (Frankfurt). Always refer to the HAQM EC2 pricing page for the most up-to-date pricing. All prices are in USD.

Prerequisites and assumptions

This post assumes that you are familiar with NLBs. The scenarios explored in this post aim to show data transfer charges in a streamlined manner. When designing architectures using load balancers in accordance with the AWS Well-Architected framework, Cost Optimization is only one of the six pillars. Therefore, we recommend reviewing your architecture with all of the pillars in mind.

Summary of charges

The following diagram (Figure 1) provides a visual representation of the charges for various paths, intended for quick reference. Later in this post, we cover real scenarios with charges that follow the same rules as depicted in the image. The values presented are for the US East (N. Virginia) ‘us-east-1’ Region.

Figure 1 – Summary of charges for Data Transfer using Network Load Balancers

Before we explore sample architectures, and how these charges are applied, we can review how NLBs are deployed for high availability and resiliency across multiple AZs in a Region.

NLBs and AZs

NLBs can be configured in one or more AZs. For each AZ, when you deploy an NLB, you must choose a subnet where the load balancer has one IP, which also means it has an Elastic Network Interface (ENI) in that subnet.

In the scenarios we cover throughout this post, when we represent a load balancer in an AZ, we are referring to the IP and ENI existent in that AZ. The following diagram (Figure 2) shows the deployment model for NLBs, showing an internet-facing load balancer deployed across two AZs, in two public subnets, serving client traffic to target instances in private subnets, with cross-zone load balancing enabled.

Figure 2: NLBs deployment model with multiple AZs

Scenarios

To make it easier for you to navigate this post, we grouped the different scenarios as follows:

• Data transfer costs for internal NLBs
  • Scenario 1.1: Intra-VPC, within the same AZ
  • Scenario 1.2: Intra-VPC, across AZs
  • Scenario 1.3: Cross-VPC with VPC peering, within the same AZ,
• Data transfer costs for internet-facing NLBs
  • Scenario 2.1: Client traffic from the internet
  • Scenario 2.2: Intra-Region client traffic
  • Scenario 2.3: Cross-Region client traffic

Data transfer costs for internal NLBs.

In these scenarios, we focus on what you pay for traffic within the load balancer.

Scenario 1.1: Intra-VPC, within the same AZ

In the following diagram (Figure 3), the client, the NLB, and the NLB targets are all situated within the same VPC and AZ. As all traffic remains within the same AZ and VPC, no data transfer fees apply for traffic in any direction.

Figure 3: Scenario 1.1 – Client and target in the same AZ as the NLB ENI

Scenario 1.2: Intra-VPC, across AZs

In the following diagram (Figure 4), when traffic crosses AZs, a charge of $0.01 per GB applies for both incoming and outgoing traffic between the client and the load balancer. From the load balancer to the target, there is no cost, because they are in the same AZ.

Figure 4: Scenario 1.2 – Client and NLB ENI in different AZs

However, if the target is located in a different AZ than the NLB ENI (Figure 5), which can occur in cross-zone enabled load balancers, then a charge of $0.01 per GB would also apply to both incoming and outgoing traffic between the load balancer and the target.

Those same scenarios aren’t charged when using ALBs and CLBs, as covered in scenario 1.2 in the post, Exploring Data Transfer Costs for Classic and Application Load Balancers.

Figure 5: Scenario 1.2 – Both client and target in different AZs than the NLB ENI

Scenario 1.3: Cross-VPC with VPC peering, within the same AZ

In the following diagram (Figure 6), no data transfer charges apply for any traffic direction. This is because, even though the traffic crosses VPCs, it remains within the same AZ.

Figure 6: Scenario 1.3 – Client and NLB ENI in the same AZ but different VPC. Target and NLB
ENI in different AZs and VPCs

Data transfer costs for internet-facing NLBs

In these scenarios, we focus on what you pay for traffic between the client and the load balancer. For details of the charges between the load balancer and the targets, refer to the scenarios described in the previous scenarios 1.1, 1.2, and 1.3. For these examples, the NLB and the targets will be in the same AZ.

Scenario 2.1: Client traffic from the internet

In the following diagram (Figure 7), data is transferred from the client through the NLB and out to the internet. More specifically, return traffic travels back to the client through the NLB. Pricing for this type of data transfer is tiered and varies by AWS Region. For N. Virginia (US-EAST-1), the price ranges from $0.05 to $0.09. These prices are current as of the publishing of this post. For the latest pricing information, visit the HAQM EC2 pricing page.

Figure 7: Scenario 2.1 – Data transferred to an internet client

Scenario 2.2: Intra-Region client traffic

In the following diagram (Figure 8), even though the client is in the same VPC, it connects to a public load balancer using its Public IP. This causes the traffic to go through the Internet Gateway (IGW) and back, incurring an extra change of $0.01/GB in each direction. When using an IGW to connect to a public NLB in the same Region, the source and destination subnet, AZ, and VPC have no impact on the HAQM EC2 data transfer charges. The following diagram assumes NLB ENI and Target in the same AZ, thus no data transfer charge.

Figure 8: Scenario 2.2 – Client in the same VPC connecting to NLB ENI through Public IP. Target
and NLB ENI in same AZs and same VPC.

Scenario 2.3: Cross-Region client traffic

In following diagram (Figure 9), the request originates from a client in the eu-central-1 Region and is charged at $0.02 per GB. The NLB response leaves the us-east-1 Region toward the client and is charged at $0.02 per GB. This charge may vary according to the Regions involved. See the full table in the section Data Transfer OUT From HAQM EC2 To of the HAQM EC2 pricing page for all prices.

Figure 9: Scenario 2.3 – Client from another AWS region. Target and NLB ENI in different AZ but same VPC.

Things to know

All the charges covered in this post are described in the HAQM EC2 pricing page and are current as of the publishing of this post. Please refer to pricing page for most up-to-date version of this information.

Scenarios 1.1

Data transferred between HAQM EC2, HAQM RDS, HAQM Redshift, HAQM ElastiCache instances, and Elastic Network Interfaces in the same Availability Zone is free.

Scenario 1.2:

Data transferred “in” to and “out” from HAQM EC2, HAQM RDS, HAQM Redshift, HAQM DynamoDB Accelerator (DAX), and HAQM ElastiCache instances, Elastic Network Interfaces or VPC Peering connections across Availability Zones in the same AWS Region is charged at $0.01/GB in each direction.

Scenario 1.3

Data transferred between HAQM EC2, HAQM RDS, HAQM Redshift, HAQM ElastiCache instances, and Elastic Network Interfaces in the same Availability Zone is free.

Scenario 2.1

The HAQM EC2 pricing page details data transfer out from HAQM EC2 to the internet, see the section Data Transfer OUT From HAQM EC2 To Internet.

Scenario 2.2

Data transferred “in” to and “out” from HAQM EC2, HAQM RDS, HAQM Redshift, HAQM DynamoDB Accelerator (DAX), and HAQM ElastiCache instances, Elastic Network Interfaces or VPC Peering connections across Availability Zones in the same AWS Region is charged at $0.01/GB in each direction.

Scenario 2.3

The HAQM EC2 pricing page details data transfer out from HAQM EC2 to various locations, see the section “Data Transfer OUT From HAQM EC2 To”.

Conclusion

In this post, we explored how HAQM EC2 data transfer charges are calculated with load balancers, clients, and targets using multiple scenarios with NLB to help you optimize data transfer costs on HAQM Web Services (AWS). We recommend you visit the Cost Optimization Pillar – AWS Well-Architected Framework for other cost optimization opportunities. You can also set up Cost and Usage Reports to get the detailed data transfer charges for your NLBs and make architecture decisions to optimize your costs. For a review of your architecture, contact your AWS Solutions Architect or Technical Account Manager. If you have questions about this post, then start a new thread on AWS re:Post, or contact AWS Support.

About the authors