Networking & Content Delivery

Optimizing data transfer costs when using AWS Network Load Balancer

Following our previous post, Exploring Data Transfer Costs for AWS Network Load Balancers, this post explores architectural patterns to help optimize these expenses.

Understanding inter-zone data transfer costs

When network traffic flows across Amazon Web Services (AWS) Availability Zones (AZs), whether from clients to Network Load Balancers (NLBs) or from NLBs to targets, AWS applies an inter-zone data transfer charge of $0.01 per GB in each direction. This charge applies to both the load balancer and Amazon Elastic Compute Cloud (Amazon EC2) instances involved in the transfer. For example, when sending 1 GB of data from an EC2 client instance to an NLB in a different AZ, data transfer charges are incurred at both ends of the connection: the client and the NLB.

To better understand this pricing structure, consider the following scenario, shown in Figure 1:

  • Data transfer between AZs costs $0.02 per GB.
  • The traffic flows from a client in AZ A to an NLB in AZ B, the charge breaks down as:
    • $0.01 per GB at the sender’s end
    • $0.01 at the receiver’s end

Data transfer between an NLB and its target within the same AZ incurs no other charges.

Figure 1: Client is in a different AZ, NLB and target are in the same AZ

Figure 1: Client is in a different AZ, NLB and target are in the same AZ

  1. When data crosses between AZs, a transfer cost of $0.02 per GB is incurred.
  2. When traffic crosses AZ boundaries twice—once from client to NLB and once from NLB to target—the total data transfer cost amounts to $0.04 per GB in each direction. This occurs when the client is in AZ A, the NLB in AZ B, and the target back in AZ A, as shown in Figure 2.
Figure 2: Client and NLB are in different AZs, and the Target is not in the same AZ as the NLB

Figure 2: Client and NLB are in different AZs, and the Target is not in the same AZ as the NLB

  1. If the traffic flow remains within the same AZ, then there is no charge for data transfer, as shown in Figure 3:
Figure 3: The Client, NLB, and Target are all in the same AZ

Figure 3: The Client, NLB, and Target are all in the same AZ

Now that we have discussed these scenarios, let’s examine how traffic flows between AZs and explore the features that help optimize and reduce associated costs.

Client to NLB traffic

In the preceding examples, we discussed an internal NLB being accessed by an internal client within the same Amazon Virtual Private Cloud (Amazon VPC). However, the same principles apply to clients accessing the internal NLB through an AWS Transit Gateway or VPC peering connection.

By default, NLBs have an Availability Zone DNS affinity setting of 0 percent zonal affinity. This means that when clients make DNS queries using Amazon Route 53 resolver, they receive responses containing any healthy NLB IP addresses across all AZs where the NLB is present. Although this approach typically achieves better traffic distribution, it also means that clients may send traffic to any NLB AZ with equal probability, regardless of their own location. When clients send traffic to an NLB Elastic Network Interface (ENI) in a different AZ, data transfer charges apply.

To minimize inter-AZ data transfer costs, you can enable 100% zonal affinity, which keeps client-to-NLB traffic within the same AZ. However, if no healthy NLB IP addresses are available in the client’s AZ, then DNS queries may still route traffic to other zones.

Considerations

Enabling 100% zonal affinity can lead to uneven traffic distribution at the NLB level. This imbalance may extend to the target level when cross-zone load balancing is disabled. To address this situation:

How to turn on zonal affinity

To turn on AZ affinity using the AWS Management Console, follow these steps, also shown in Figure 4:

  • Open the Amazon EC2 console.
  • In the navigation pane, choose Load Balancers.
  • Choose the name of the NLB to open its details page.
  • On the Attributes tab, choose Edit.
  • Under Availability Zone routing configuration, Client routing policy (DNS record), choose Availability Zone affinity or Partial Availability Zone affinity.
  • Choose Save changes.
Figure 4: Setting AZ affinity for NLB

Figure 4: Setting AZ affinity for NLB

To turn on AZ affinity using the AWS Command Line Interface (AWS CLI):

NLB to target traffic

Cross-zone traffic between a NLB and its targets is controlled by cross-zone load balancing configurations at both the load balancer and target group levels. When cross-zone load balancing is enabled, each load balancer node can distribute incoming traffic across all registered targets in every enabled AZ. However, when a load balancer node routes traffic to a target in a different AZ, it results in inter-zone traffic that incurs charges.

By default, NLBs have cross-zone load balancing disabled at both the load balancer and target group levels. Although some users enable it to achieve more balanced traffic distribution across their targets, this decision results in inter-zone data transfer charges whenever traffic is sent to targets in different AZs.

Considerations

When cross-zone load balancing is disabled, traffic distribution among targets can become imbalanced. It’s recommended to maintain a proportional number of targets in each AZ. This configuration helps achieve consistent and efficient traffic distribution across your application infrastructure.

How to turn off cross-zone load balancing

To modify cross-zone load balancing for a load balancer using the console, follow these steps, also shown in Figure 5:

  • Open the Amazon EC2 console.
  • In the navigation pane, under Load Balancing, choose Load Balancers.
  • Choose the name of the load balancer to open its details page.
  • On the Attributes tab, choose Edit.
  • On the Edit load balancer attributes page, turn Cross-zone load balancing off.
  • Choose Save changes.
Figure 5: Disabling cross-zone load balancing for NLB

Figure 5: Disabling cross-zone load balancing for NLB

To modify cross-zone load balancing for your load balancer using the AWS CLI:

To modify cross-zone load balancing for a target group using the console, follow these steps, also shown in Figure 6:

  • Open the Amazon EC2 console.
  • On the navigation pane, under Load Balancing, choose Target Groups.
  • Choose the name of the target group to open its details page.
  • On the Attributes tab, choose Edit.
  • On the Edit target group attributes page, choose On for Cross-zone load balancing.
  • Choose Save changes.
Figure 6: Disabling cross-zone load balancing for NLB Target Group

Figure 6: Disabling cross-zone load balancing for NLB Target Group

To modify cross-zone load balancing for a target group using the AWS CLI:

Availability Zone Independence

Another noteworthy aspect of this approach is the ability to achieve Availability Zone Independence (AZI) by disabling cross-zone load balancing and enabling 100% zonal affinity, as shown in Figure 7.

This configuration not only helps mitigate data transfer costs but also serves as a best practice for building resilient architectures. Implementing AZI supports zonal evacuation strategies and can enhance availability in scenarios where a specific AZ experiences any issues. For more detailed information, refer to the Availability Zone Independence whitepaper.

Furthermore, by keeping traffic within the same AZ, you can reduce packet latency through your load balancer. You can monitor real-time inter-AZ latency using the Infrastructure Performance feature in AWS Network Manager.

Figure 7: AZI with NLB

Figure 7: AZI with NLB

Conclusion

Optimizing data transfer costs for NLBs necessitates a thoughtful approach to architecture and configuration. You can implement the strategies discussed in this article to significantly reduce your inter-zone data transfer costs while maintaining high availability and performance. These strategies include the following:

  • Enabling 100% zonal affinity for client-to-NLB traffic
  • Disabling cross-zone load balancing
  • Maintaining balanced distribution of clients and targets across AZs
  • Consider Availability Zone independence

Although these optimizations can lead to substantial cost savings, it’s crucial to monitor your application’s performance and adjust your strategy as needed. Remember that the most cost-effective solution should always be balanced against your specific requirements for availability, scalability, and performance. You can carefully consider your architecture and use these AWS features to create a more cost-efficient and resilient infrastructure that meets your business requirements. For more information on Network Load Balancer configuration and best practices, refer to the Network Load Balancer documentation.

About the authors

Luis Felipe Silveira da Silva

Luis Felipe Silveira da Silva

Luis Felipe is a Principal Solutions Architect. He is part of the Application Networking team and based in Dublin, Ireland. Leveraging AWS’s extensive load balancing and networking suite, he helps customers to design and enhance their workloads. Luis Felipe collaborates closely with clients and internal AWS teams to develop resilient architectures and promote the effective implementation of AWS networking solutions.

Lucas Rolim

Lucas Rolim

Lucas Rolim, a Senior Solutions Architect at Amazon Web Services (AWS), is based in Sydney, Australia, where he works in the Application Networking team. He is dedicated to helping customers make informed decisions while building on AWS. His expertise primarily focuses on Networking and Security.