Any business website depends on optimal performance and availability 24 hours a day, 7 days a week. Ensuring high performance to handle any kind of traffic — and especially spiky and high-volume traffic — can be a challenge if you aren’t using the right approach for managing requests.
Amazon Web Services recently expanded its load balancing options with a new service designed for latency-sensitive applications and extreme performance: Network Load Balancer. So what is a Network Load Balancer? In this post, we’ll explore the features and costs of this new service and help you navigate all of AWS’s load balancing options so that you know how to choose the best service for your applications.
What is a Network Load Balancer?
Until now, when you anticipated extremely spiky workloads or even instantaneous fail-over between regions, you would ask AWS to provision a load balancer in preparation for the surge in traffic. This meant the load balancer was “pre-warmed” for you by AWS, which is a wonderful example of AWS customer obsession. However, this process is dependent on several variables: you are responsible for creating the support ticket, knowing the dates for the traffic surge, the expected rate request per second, the size of a typical request. Finally, the process relies on AWS support to manage the pre-warming process for you.
The Network Load Balancer reduces some of these dependencies. Network Load Balancer has been designed to handle sudden and volatile traffic patterns, making it ideal for load balancing TCP traffic. It is capable of handling millions of requests per second while maintaining low latencies and doesn’t have to be “pre-warmed” before traffic arrives.
With Network Load Balancer, we have a simple load balancing service specifically designed to handle unpredictable burst TCP traffic. It makes a single static IP address available per Availability Zone, and it operates at the connection level (Layer 4) to route inbound connections to AWS targets. The target can be EC2 instances, containers, or an IP address. Network Load Balancer is tightly integrated with other AWS managed services such as Auto Scaling, ECS (Amazon EC2 Container Service), and CloudFormation. It also supports static and elastic IP addresses and load balancing to multiple ports on the same instance.
Best use cases for Network Load Balancer:
- When you need to seamlessly support spiky or high-volume inbound TCP requests.
- When you need to support a static or elastic IP address.
- If you are using container services and/or want to support more than one port on an EC2 instance. NLB is especially well suited to ECS (The Amazon EC2 Container Service).
Choosing the Right Load Balancer
There are three options for Elastic Load Balancing in AWS: Classic Load Balancer, Application Load Balancer, and Network Load Balancer. How do you know which one is the right fit for your applications?
Application Load Balancer is arguably the most protocol-oriented load balancing service. Because the service enforces the latest SSL/TLS ciphers and protocols, it is ideal for negotiating HTTP requests. Application Load Balancer also operates at the request level (layer 7), but provides more advanced routing capabilities than the Classic and Network Load Balancers.
Additionally, its support for host-based and path-based routing, X-Forwarded-For headers, server name indication (SNI), and sticky sessions makes the Application Load Balancer ideal for balancing loads to microservices and container-based applications.
Here is another reason why it’s a great choice for containers: Application Load Balancer enables load balancing across multiple ports on a single Amazon EC2 instance. This is really powerful when you are using ECS as you can specify a dynamic port in the ECS task definition. This creates an unused port on the container when an EC2 instance is scheduled. The ECS scheduler automatically adds the task to the load balancer using this port, which is one less thing for you to worry about. The Network Load Balancer also supports multiple ports on the same instance, so you might consider using Network Load Balancer over Application Load Balancer if you need to support a static or dynamic IP address.
Best use cases for Application Load Balancer: Containerized applications, microservices, and anytime you need to support a static elastic IP address.
Classic Load Balancer is still a great solution if you just need simple load balancing with multiple protocols. Classic Load Balancer supports many of the same Layer 4 and Layer 7 features as Application Load Balancer: sticky sessions, IPv6 support, monitoring, logging, and SSL termination. Both the Classic and Application Load Balancers support offloading SSL decryption from application instances, management of SSL certificates, and encryption to back-end instances with optional public key authentication.
One plus with Classic Load Balancer is that it permits flexible cipher support, allowing you to control the ciphers and protocols the load balancer presents to clients. This makes Classic Load Balancer a good choice if you have to use or limit use to a specific cipher.
Best use cases for Classic Load Balancer: Simple load balancing or flexible cipher support.
So, should I consider upgrading from Classic Load Balancer to the new Network Load Balancer? The answer should probably be yes if you:
- Want to support spiky and unpredictable TCP traffic without pre-warming.
- Need to support an IP address or an IP target outside of the VPC.
- Want to support and monitor multiple services running on ports on an EC2 instance.
Does Network Load Balancer cost more?
Costs vary per region so always check the AWS pricing page before using or changing a load balancer. Currently, all three load balancers attract a charge for each hour or partial hour the load balancer is running. Both Application and Network Load Balancers incur an additional charge for the number of Load Balancer Capacity Units (LCUs) used per hour. This cost is currently calculated based on the number of new connections, active connections, bandwidth, and rule evaluations made in an equation explained on the AWS load balancer pricing page. Classic Load Balancer has a simple charge for each GB of data transferred through the load balancer.
While each load balancing use case will be unique, here are the simple rules of thumb that I use when considering which load balancer to choose:
- If you need to support a static or elastic IP address: Use Network Load Balancer
- if you need control over your SSL cipher: Use Classic Load Balancer
- If using container services and/or ECS: Use Application Load Balancer or Network Load Balancer
- If you need to support SSL offloading: Use Application Load Balancer or Classic Load Balancer
