Choosing the Right Load Balancer on Amazon: What NGINX Offers

DZone 's Guide to

Choosing the Right Load Balancer on Amazon: What NGINX Offers

Here is a thorough comparison of AWS's Load Balancer and NGINX Plus.

· Cloud Zone ·
Free Resource

Anyone running highly available, scalable applications on Amazon Web Services (AWS) can now choose between load balancing with NGINX or NGINX Plus; AWS Elastic Load Balancer, now called Classic Load Balancer; and 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 will review the new features in Amazon Load Balancer, then compare its pricing and features to open source NGINX and NGINX Plus. We will also describe the role of Classic Load Balancer with respect to these alternatives.

Note: See our previous blog post for a direct comparison of NGINX Plus and AWS Classic Load Balancer, as well as information on using them together.

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.

Image title

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) will need 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 SSL/TLS-secured content.

ALB is a significant update for AWS users who have struggled with ELB’s limited feature set, and it goes some way toward 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 open source NGINX or NGINX Plus on AWS to control and load balance traffic. They may wish to deploy Amazon Classic Load Balancer as a front-end to achieve high availability across multiple availability zones.

Amazon ALB

NGINX open source


Load balancing

Only provides round-robin load balancing and cookie-based session persistence

Provides multiple load-balancing methods (Round Robin, Least Connections, Hash)

Adds more load balancing methods (Least Time) and more session persistence methods


No; no support for caching in the load balancer

Yes; strong support for static file caching and dynamic (application) caching

Yes; static and dynamic caching plus advanced caching features

High availability and health checks 

Active monitoring; performs asynchronous HTTP health checks and verifies status code to determine server health

Passive monitoring; checks all responses from upstream servers and identifies failed servers

Passive monitoring and active monitoring; health checks are richer and more configurable than ALB’s

Multiple applications 

No; needs one ALB instance per application, as host header routing and multiple SSL certificates are not supported

Yes; fully supports multiple distinct applications on each NGINX instance

Yes; fully supports multiple distinct applications on each NGINX instance

Content-based routing 

Only path-based routing – routing based on the request URL

Routing based on the request URL as well as request headers, cookies or argument

Routing based on the request URL as well as request headers, cookies or arguments

Containerized applications 

Can load balance to Amazon IDs, ECS container instances and autoscaling groups

Requires manual configuration or the use of configuration templates

Automated configuration using DNS including SRV records; works with leading registry services

Additional protocols 


Yes; TCP and UDP supported, with passive health checks

Yes; TCP and UDP supported with passive and active health checks


Dev, test and production environments can only be provisioned on AWS

Dev, test and production environments can be provisioned on any deployment platform

Dev, test and production environments can be provisioned on any deployment platform

SSL security 

Single SSL certificate; single hardwired SSL cipher policy; no validation of SSL upstreams

Multiple SSL certificates; full choice of SSL ciphers; full validation of SSL upstreams

Multiple SSL certificates; full choice of SSL ciphers; full validation of SSL upstreams

Amazon ALB
NGINX open source NGINX Plus

HTTP/2 and WebSockets 

Yes; single SSL certificate; HTTP/2 only

Yes; multiple certificates and protocols

Yes; multiple certificates and protocols

Advanced capabilities 


Origin serving, prioritization, rate limiting and more

Origin serving, prioritization, rate limiting and more

Logging and debugging 

Amazon binary log format

Customizable log files; multiple debug interfaces

Fully customizable log files; multiple debug interfaces; full support from NGINX

Monitoring tools 

Integrated with Amazon CloudWatch

NGINX Amplify and your choice of monitoring tools

NGINX Amplify and your choice of monitoring tools, with additional metrics on backend server performance

Technical support Yes, additional cost Community support only Yes, included in price and direct from NGINX, Inc.

Yes, additional cost 

Community support only

Yes, included in price and direct from NGINX, Inc.

Free tier 

750 hours

Open source (always free)

30 days free tier

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 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 its is not returning the expected status code.

We discovered this by creating an ALB instance that load–balanced a cluster of instances. We configured a health check with the minimum five-second frequency and a minimum threshold of two failed checks, then 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 (e.g. 200 OK or 404 Not 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. ELB can be a significant part of your Amazon bill, and the need to run one ELB instance per application can make it prohibitively expensive.

ALB carries the same 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 Amazon bill each month.

NGINX Plus on AWS gives you complete predictability. For $0.25/hour 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.

nginx ,load balancer ,aws ,amazon web services ,elastic load balancer

Published at DZone with permission of Owen Garrett . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}