Customers using Amazon Web Services (AWS) often ask us whether to use NGINX Plus or Amazon Elastic Load Balancing (ELB) for application load balancing. Amazon has published a whitepaper that describes how to set up NGINX Plus on AWS. This post focuses on the factors to consider as you choose between NGINX Plus and ELB, as well as situations where it makes sense to use both.
Editor – In 2016 Amazon introduced a new native load balancing option, and as a result renamed ELB to Classic Load Balancer. This article retains the original name. For information about NGINX Plus and the new AWS load balancer, see Choosing the Right Load Balancer on Amazon: AWS Application Load Balancer vs. NGINX Plus.
Elastic Load Balancing (ELB) has been designed to provide a highly available infrastructure that is tightly integrated into AWS, but it does not have a large set of Layer 7 features like NGINX Plus. The feature overlap between NGINX Plus and ELB means it is not always obvious which is the right solution, but in general ELB is a good choice when you require simple load balancing but with high availability across multiple AWS zones and regions, and NGINX Plus is a good choice when you require more than very basic Layer 7 functionality. When used together, ELB and NGINX Plus can provide a very complete solution including a highly available active‑active cluster of NGINX Plus instances.
Here is a matrix showing a subset of the features available in NGINX Plus and ELB:
|Feature||NGINX Plus||ELB||NGINX Plus & ELB|
|Basic load balancing||✅||✅||✅|
|Simple HTTP health checks||✅||✅||✅|
|Advanced HTTP health checks||✅||❌||✅|
|TCP health checks||✅||✅||✅|
|UDP health checks||✅||❌||✅|
|SSL/TLS termination for HTTP and TCP||✅||✅||✅|
|Connection and rate limiting||✅||❌||✅|
|URL rewriting and redirecting||✅||❌||✅|
|Server Name Indication (SNI)||✅||❌||✅|
|Active-active NGINX Plus cluster||❌||❌||✅|
We will now discuss some of the feature differences between NGINX Plus and ELB and what is available when the two are combined.
Features in NGINX Plus
A common use case for NGINX Plus without ELB is when one NGINX Plus instance in a single availability zone is sufficient to meet the demand for your application. And if you have such NGINX Plus instances in multiple AWS regions, you can use Amazon Route 53 to distribute traffic across them.
NGINX Plus provides the following Layer 7 features, which are available with ELB in a more limited way or not at all.
NGINX Plus can route requests based on a number of values, including the URL, request headers, cookies, and so on. With ELB, all requests to a particular DNS name and port are sent to the same set of backend servers. With NGINX Plus, a number of backend server pools, or upstream groups, can be used. For example, any URL ending in .html, .jpg, .gif, or .png can be sent to one upstream group while all those ending in .php can be sent to another, or any request with a URL starting with /store can be sent to one upstream group while all those starting with /support can be sent to another.
URL Rewriting and Redirecting
NGINX Plus can rewrite the URL of an incoming request before forwarding the request to a backend server, which is useful if, for example, you need to change the location of a file but don’t want to change the URL advertised to clients. NGINX Plus can also redirect requests; one of the simplest cases is redirecting all HTTP requests to an HTTPS server.
Advanced Application Health Checks
You can configure NGINX Plus to check the health of the servers it is proxying. You can customize HTTP application health checks by specifying the URL to be requested and by inserting headers. You can also specify which response codes are valid and a string that must occur in the response body for the health check to succeed. With TCP/UDP health checks you can specify the string to be sent and the string that the server needs to return.
For both HTTP and TCP/UDP health checks, you can specify how often the checks run, how long NGINX Plus waits for a response, and how many consecutive times the health check must fail before NGINX Plus marks the node as down. You can also configure the slow‑start feature, so that after a node returns to health it does not immediately receive its full share of traffic; instead NGINX Plus gradually ramps up the amount of traffic to the node over the time period you specify.
ELB also provides HTTP and TCP health checks, but you cannot specify the HTTP response body or TCP response string, or set the number of consecutive failures before a node is marked as down. ELB does not handle UDP traffic at all.
WebSocket and HTTP/2 Support
Connection and Rate Limits
NGINX Plus allows you to configure multiple limits to control the traffic to and from your NGINX Plus instance. These include limiting the inbound connections, the connections to backend nodes, the rate of inbound requests, and the rate of data transmission from NGINX Plus to clients and from backend servers to NGINX Plus.
Multiple Load Balancing Algorithms
When configuring load balancing, NGINX Plus gives you a choice of algorithms to use: Round Robin, Least Connections, Least Time, IP Hash, and Hash. ELB uses Round Robin for TCP load balancing and Least Outstanding Request (similar to Least Connections) for HTTP and HTTPS traffic.
Features in ELB
If you do not need any of NGINX Plus’ Layer 7 functionality as described above, you can use ELB as a highly available load‑balancing solution across availability zones, and – with Route 53 – across regions. It can also provides the functionality described in the following paragraphs, which is not available in NGINX Plus.
ELB Auto Scaling provides the ability to scale up or down the number of backend nodes being load balanced in reaction to changes in overall load.
Built‑in Integration with Route 53 Health Checks
Route 53 can be enabled to automatically configure and manage health checks for ELB. If Route 53 is used with NGINX Plus, custom health checks can be configured.
Features in NGINX Plus and ELB Combined
You can use NGINX Plus and ELB together to take advantage of the superset of features of the two products, plus the additional functionality described in the following paragraphs.
Active‑Active High Availability
Using ELB to load balance across NGINX Plus instances makes them highly available by creating a set of active‑active instances.
Auto Scaling NGINX Plus
ELB Auto Scaling can also be used to scale up or down the number of NGINX Plus instances based on load.
Autoscaling Backend Instances
By putting ELB behind NGINX Plus, but in front of the backend servers, you can use ELB Auto Scaling to scale the number of backend server instances up or down, while still getting the benefits of NGINX Plus’ Layer 7 features.
NGINX Plus and ELB both support access logging, but the exact capabilities differ. NGINX Plus can log to a local disk or to syslog, and provides an extensive set of values you can configure to be logged. ELB logs directly to Amazon S3, and also allows you to configure the values to be logged, but the list of possible values is less comprehensive. Centralizing your logging to S3 for all of the applications you are running in AWS can be very convenient, and ELB does it by default. To centralize NGINX Plus logging to S3, configure NGINX Plus to log to a syslog server that is set up to log to S3.
As has been discussed, NGINX Plus and ELB can be used for application load balancing in a number of configurations, separately or together. The following diagram shows where each component can be used.
ELB is a good choice if your load balancing requirements are simple, and its high availability and Auto Scaling features are excellent. NGINX Plus is a good choice when your load balancing needs are more complex. When used together, you can utilize the advanced load‑balancing features of NGINX Plus as well as the active‑active high availability and Auto Scaling features of ELB.