Networking & Content Delivery

Exploring Data Transfer Costs for Classic and Application Load Balancers

In this post, we explore how Amazon Elastic Compute Cloud (Amazon EC2) data transfer costs apply to the communication between Classic Load Balancers (CLB), Application Load Balancer (ALB), clients, and targets in multiple scenarios, to help you optimize data transfer costs on AWS.

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 Application and Classic Load Balancers, let’s review the pay as you go cost model for each. For Application Load Balancers, you pay for each hour or partial hour that an Application Load Balancer is running, and the number of Load Balancer Capacity Units (LCU) used per hour. When using Classic Load Balancers, you pay for each hour or partial hour that a Classic Load Balancer is running and for each gigabyte (GB) of data transferred through your load balancer. 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, VPC, and Region boundaries, Amazon Elastic Compute Cloud (EC2) Data Transfer charges apply. In this post, we review all data transfer charges for Classic and Application Load Balancers.

Note that 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 AWS Region as US East (Northern Virginia) and the secondary Region is Europe (Frankfurt). Always refer to the individual service pricing pages for the most up-to-date pricing. All prices are in USD.

Prerequisites and assumptions

This post assumes that you are familiar with Application and Classic Load Balancers. The scenarios explored in this post aim to illustrate data transfer charges in a simplified 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 diagram below (Figure 1) provides a visual representation of the charges for various paths, intended for quick reference. Later in this post, we will 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.

Summary of Data Transfer charges for ALB

Figure 1: Summary of charges for Data Transfer using Application Load Balancers

Before we explore sample architectures, and how these charges are applied, let’s review how Application and Classic Load Balancers are deployed for high availability and resiliency across multiple Availability Zones in a Region.

Elastic Load Balancing and Availability Zones

Both Application and Classic Load Balancers are Regional resources that can be configured in one or more Availability Zones (AZ). For each AZ, when you deploy an Application or Classic Load balancer, you must select a subnet where the load balancer will have one or more nodes deployed, depending on various scaling factors.

In the scenarios we cover throughout this blog post, when we represent a load balancer in an AZ, we are referring to the specific node(s) that run in that AZ. The following diagram (Figure 2) highlights the deployment model for Application and Classic Load Balancers, 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.

Example of a load balancer in two public subnets, serving traffic to target instances in other subnets with cross zone enabled.

Figure 2: Application and Classic Load Balancers deployment model

Scenarios

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

Data transfer costs for internal Application and Classic Load Balancers

Scenario 1.1: Intra-VPC within the same AZ

In the following diagram (Figure 3), no data transfer charges apply for any traffic direction. This is because all traffic remains within the same AZ and VPC.

Client and target in the same AZ as the ELB node.

Figure 3: Scenario 1.1 – Client and target in the same Availability Zone as the ELB node. No data transfer charges apply for any traffic direction because all traffic remains within the same Availability Zone and VPC.

Scenario 1.2: Intra-VPC, across AZs

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

Client and ELB node in different AZ. Target and ELB node in the same AZ.

Figure 4: Scenario 1.2 – Client and ELB node in different Availability Zones. Target and ELB node in the same AZ. No data transfer charges apply for any traffic direction because all traffic remains within the same VPC.

Cross-VPC with VPC peering, within the same AZ and across AZs

Scenario 2.1: Cross VPC intra-AZ, using VPC peering

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

Client and ELB node in the same AZ but different VPC. Target and ELB node in different AZ and VPC.

Figure 5: Scenario 2.1 – Client and ELB node in the same Availability Zone but different VPC. Target and ELB node in different Availability Zones and VPCs. No data transfer charges apply for any traffic direction because all traffic remains within the same Availability Zone.

Scenario 2.2: Cross VPC cross AZ, using VPC peering

In the following diagram (Figure 6), the charge of $0.01 per GB applies for both incoming and outgoing traffic from the client to the load balancer and from the load balancer to the client. This is because the traffic is crossing AZs and crossing VPCs through a peering connection. From the load balancer to the target, there is no cost, as they are in the same AZ.

Client and ELB node in different AZ and VPC. Target and ELB node in the same AZ and VPC.

Figure 6: Scenario 2.2 – Client and ELB node in different Availability Zones and VPC. Target and ELB node in the same Availability Zone and VPC. Data transfer charges apply for traffic between Client and ELB because traffic crosses VPCs and Availability Zones.

Data transfer costs for internet-facing Application and Classic Load Balancers

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, 2.1 and 2.2.

Scenario 3.1: Client traffic from the internet

In the following diagram (Figure 7), data is transferred through the ELB out to the Internet. Pricing for this type of data transfer is tiered and varies by Region. For N. Virginia (US-EAST-1), the price range from $0.05 to $0.09. (These prices are current as when this blog post was published. For latest pricing information, visit the Amazon EC2 Pricing website.

Internet client. Target and ELB node in different AZ but same VPC.

Figure 7: Scenario 3.2 – Internet client. Target and ELB node in different Availability Zones but same VPC. Data transfer charges apply for Internet outbound traffic.

Scenario 3.2 – Client traffic within the same Region, through the Internet Gateway

In the following diagram (Figure 8), note that 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 extra change of $0.01/GB in each direction. Note that when using an IGW to connect to a public ELB in the same AWS Region, the source and destination subnet, AZ, and VPC do not change the Amazon EC2 data transfer charges.

Client in the same VPC connecting to ELB node via Public IP.

Figure 8: Scenario 3.2 – Client in the same VPC connecting to ELB node via Public IP.

If you must access a load balancer from a client within same VPC, then we recommend considering an internal load balancer, as it does not incur charges (we show this in scenarios 1.1, 1.2, and 2.1). Even if you must have an Internet-facing endpoint for the same workload, it may be more cost effective to have a separate internal load balancer for internal clients. For example, if you are transferring 2 GB per hour using the public IP you pay $0.04 (2 x $0.02), then the cost is greater than the hourly cost of the second load balancer, which is $0.0225 in the US East (N. Virginia) ‘us-east-1’ Region.

Scenario 3.3: Client traffic across Regions

In following diagram (Figure 9),  the ELB response leaves its AWS Region toward another AWS Region. This is typically charged at $0.02 per GB – but may vary according to the AWS Region. For example, you pay $0.01 for data sent between the US East (Ohio) and US East (Northern Virginia) Regions. See the full table in the section “Data Transfer OUT From Amazon EC2 To” of the Amazon EC2 pricing page for all prices.

Note that in this scenario, the client in AWS Region A might be a different customer and AWS account. In this case, the client’s account owner pays $0.02 for data out (Request) and the ELB’s account owner pays $0.02 for data out (Response).

Client from another AWS region. Target and ELB node in different AZ but same VPC.

Figure 9: Scenario 4.2 – Client from another AWS region. Target and ELB node in different AZ but same VPC.

Things to know

All the charges covered in this post are described in the Amazon EC2 Pricing Website and are current as when this blog post was published.

Scenarios 1.1 and 1.2:

Data transferred “in” to and “out” from Amazon Classic and Application Elastic Load Balancers using private IP addresses, between EC2 instances and the load balancer in the same AWS VPC is free.

Scenario 2.1

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

Scenarios 2.2 and 3.2

Data transferred “in” to and “out” from Amazon EC2, Amazon RDS, Amazon Redshift, Amazon DynamoDB Accelerator (DAX), and Amazon 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 3.1

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

Scenario 3.3

The Amazon EC2 pricing page details data transfer out from Amazon EC2 to various location, see section “Data Transfer OUT From Amazon EC2 To”

Conclusion

In this post, we explored how Amazon EC2 data transfer charges are calculated with load balancers, clients, and targets using multiple scenarios with ALB and CLB. We recommend you to visit the Cost Optimization Pillar – AWS Well-Architected Framework for other cost optimization opportunities and enable Cost and Usage Reports to get the detailed data transfer charges for your ELBs and make architecture decisions to optimize your costs. If you have questions about this post, then start a new thread on AWS re:Post, or contact AWS Support.

About the authors

Lucas Pellucci Barreto Rolim

Lucas Pellucci Barreto Rolim

Lucas Rolim is a Senior Solutions Architect with Amazon Web Services (AWS), working in the Application Networking team and based in Sydney, Australia. He is passionate about assisting customers in making informed decisions while building on AWS. His primary areas of expertise are Networking and Security.

Luis Felipe Silveira da Silva

Luis Felipe Silveira da Silva

Luis Felipe is a Principal Solutions Architect in the ELB Team. He works with a diverse range of load balancing and networking technologies, collaborating with customers and internal teams to design and optimize workloads, along with ensuring successful implementation and adoption of EC2 Networking services.