Anyone running highly available, scalable applications on Amazon Web Services (AWS) now has a few choices for load balancing:
- NGINX or NGINX Plus
- AWS Elastic Load Balancer (ELB), now called Classic Load Balancer
- The new Application Load Balancer, described by Amazon as an option for Elastic Load Balancing
The new option is described in a blog post and product documentation. In this post, we review the new features in Application Load Balancer, then compare its pricing and features to NGINX Open Source and NGINX Plus. We also describe the role of Classic Load Balancer with respect to these alternatives.
- The information about supported features in Application Load Balancer and NGINX Plus was accurate at the time of writing, but is subject to change.
- For a direct comparison of NGINX Plus and AWS Classic Load Balancer, as well as information on using them together, see our previous blog post.
New Features In Application Load Balancer
Application Load Balancer (ALB), like Classic Load Balancer, is tightly integrated into AWS. Amazon describes it as a Layer 7 load balancer – though it does lack many of the advanced features that cause people to choose a Layer 7 load balancer in the first place.
In contrast to Classic Load Balancer, ALB introduces several new features:
- Content‑based routing. Amazon claims content‑based routing for ALB. Currently ALB can only direct traffic based on pattern matches against the URL; rules cannot select targets based on other criteria. One implication of this is that each application (identified by a specific domain) needs a dedicated ALB load balancer.
- Support for container‑based applications. ALB improves on the existing support for containers hosted on Amazon’s EC2 Container Service.
- More metrics. With the (limited) content‑based routing in ALB, you can now collect metrics on a per‑microservice basis.
- WebSocket support. ALB supports persistent TCP connections between a client and server.
- HTTP/2 support. ALB supports HTTP/2, a superior alternative when delivering content secured by SSL/TLS.
ALB is a significant update for AWS users who have struggled with Classic Load Balancer’s limited feature set, and it goes some way towards addressing the requirements of sophisticated users who need to be able to secure, optimize, and control the traffic to their web applications. However, it does fall short of the capabilities of dedicated reverse proxies (such as NGINX) and load balancers (such as NGINX Plus).
A Better Approach to Control Traffic on AWS
Rather than using Amazon ALB, users can deploy NGINX Open Source or NGINX Plus on AWS to control and load balance traffic. They may wish to deploy Classic Load Balancer as a frontend to achieve high availability across multiple availability zones. The table compares features supported by ALB, NGINX, and NGINX Plus.
Note: The information in the following table about supported features was accurate at the time of writing, but is subject to change.
|Amazon ALB||NGINX Open Source||NGINX Plus|
|Load balancing||Round‑robin only, with cookie‑based session persistence||Multiple load balancing methods, including Round Robin, Least Connections, Hash||Adds Least Time method and more session persistence methods|
Caching in the load balancer not supported
|✅Strong support for static file caching and dynamic (application) caching||✅Static and dynamic caching plus advanced features|
|High availability and health checks||Active monitoring –
Determines server health by checking status code returned for asynchronous HTTP health checks
|Passive monitoring –Identifies failed servers by checking responses to client requests||Both active and passive – Active checks are richer and more configurable than ALB’s|
Each application needs its own ALB instance, as
|✅Each NGINX instance fully supports multiple distinct applications||✅Each NGINX Plus instance fully supports multiple distinct applications|
Only based on the request URL (path‑based routing)
|✅Based on request headers, cookies, or arguments, as well as the request URL|
|Containerized applications||Can load balance to Amazon IDs, ECS container instances, and Auto Scaling groups||Requires manual configuration or configuration templates||Automated configuration using DNS including
|✅Also TCP and UDP, with passive health checks||✅Also TCP and UDP, with active and passive health checks|
All environments (Dev, test, and production) must be on AWS
Any environment can be on any deployment platform
|SSL/TLS||– Single SSL/TLS certificate
– Single, hardwired SSL/TLS cipher
– Validation of SSL/TLS upstreams ❌
|– Multiple SSL/TLS certificates
– Full choice of SSL/TLS ciphers
– Validation of SSL/TLS upstreams ✅ (full validation)
|HTTP/2 and WebSocket||✅Single SSL/TLS certificate, HTTP/2 only||✅Multiple certificates and protocols||✅Multiple certificates and protocols|
|Advanced capabilities||❌||✅Origin serving, prioritization, rate limiting, and more|
|Logging and debugging||Amazon binary log format||Customizable log files and multiple debug interfaces||Fully customizable log files and multiple debug interfaces, fully supported by NGINX, Inc.|
|Monitoring tools||✅Integrated with Amazon CloudWatch||✅NGINX Amplify and other third‑party tools||✅NGINX Amplify and other third‑party tools; extended set of reported statistics|
|Official technical support||✅
At additional cost
Community support only
Included in price and direct from NGINX, Inc.
First 750 hours
30‑day trial subscription
Of course, you should evaluate your load‑balancing choice not by a feature checklist, but by assessing the capabilities you need to deliver your applications flawlessly, with high security, maximum availability, and full control.
Handling Traffic Spikes
Amazon’s Classic Load Balancer (formerly ELB) suffered from a poor response to traffic spikes. Load balancer instances were automatically sized for the current level of traffic, and it could take many minutes for ELB to respond and deploy additional capacity when spikes occurred. Users had to resort to a manual, forms‑based process to request additional resources in advance of traffic spikes (referred to as “pre‑warming”). It’s likely that ALB will require have similar limitations and require similar processes to scale.
NGINX and NGINX Plus are deployed within standard Amazon instances, and our sizing guide gives an indication of the potential peak performance of each instance type. Pricing for NGINX Plus is the same for all instance sizes, so it’s cost-effective to deploy excess capacity to handle spikes, and it’s quick to deploy more instances – no forms to complete – when more capacity is needed.
Detecting Failed Servers with Health Checks
Our initial testing of Amazon ALB indicates that it does not implement “passive” health checks. A server is only detected as having failed once an asynchronous test verifies that it is not returning the expected status code.
We discovered this by creating an ALB instance to load balance a cluster of instances. We configured a health check with the minimum 5‑second frequency and minimum threshold of 2 failed checks, and sent a steady stream of requests to the ALB. When we stopped one of the instances, for some requests ALB returned a
502 error for several seconds until the health check detected the instance was down. Passive health checks prevent these types of errors from being seen by end users.
ALB’s health checks can only determine the health of an instance by inspecting the HTTP status code (such as
Found). Such health checks are unreliable; for example, some web applications replace server‑generated errors with user‑friendly pages, and some errors are only reported in the body of a web page.
NGINX Plus’ health checks are more powerful, matching responses against the body of a response as well as the status code.
Finally, the biggest question you face if you deploy the new ALB service is cost. Load Balancing can be a significant part of your AWS bill, and the need to run one load balancer instance per application can make it prohibitively expensive.
ALB carries this limitation, and the pricing seems even more complex. Unless you know precisely how many new connections, how many concurrent connections, and how much data you will manage each month – which is very hard to predict – and you can run the LCU calculation the same way that Amazon does, you’ll be dreading your AWS bill each month.
NGINX Plus on AWS gives you complete predictability. For a fixed hourly cost plus AWS hosting charges, you get a significantly more powerful load‑balancing solution with full support.
NGINX Plus is a proven and superior solution for Layer 7 load balancing, with Layer 4 load‑balancing features as well. It works well in tandem with Amazon’s own ELB/Classic Load Balancer.
ALB is a limited, unproven, and – at deployment volumes – expensive solution. Prudence suggests waiting to hear from other users as to features, functionality, reliability, and expense before depending on any new solution.
We encourage the continuing and growing use of NGINX and NGINX Plus in the AWS environment, already a very popular solution. If you are not already an NGINX Plus user, you can try NGINX Plus for free today.