Choosing the Right Load Balancer on Amazon: AWS Application Load Balancer vs. NGINX Plus
Anyone running highly-available, scalable applications on Amazon Web Services (AWS) now can 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 Balancer.
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 NGINX open source 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. That blog post includes a matrix comparing the features of NGINX Plus, ELB, and the combination of NGINX Plus and ELB used 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.
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.
Application Load Balancer is a significant update for Amazon ELB users who have struggled with its limited feature set, and it goes some way towards addressing the needs 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 F/OSS 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 Application Load Balancer | NGINX open source | NGINX Plus | |
| Support for multiple applications | No: Lack of support for host header routing and multiple SSL certificates means each application requires its own ALB instance | Yes: Fully supports multiple distinct applications on each NGINX instance | Yes: Fully supports multiple distinct applications on each NGINX instance |
| Support for load balancing | Provides round robin (only) and cookie session persistence | Provides multiple load balancing methods (round robin, least_conns, hash). | Even more load balancing methods (least_time); multiple session persistence methods |
| Support for high-availability using Health Checks | Active monitoring: performs asynchronous HTTP health checks and verifies status code to determine server health | Passive monitoring: checks all responses from upstreams and identifies failed servers | Passive monitoring and active Monitoring; NGINX Plus health checks are richer and more configurable than ALB’s |
| Support for containerized applications | Can load balance to AmazonIDs, Amazon Autoscaling Groups and Amazon Container Instances | Requires manual configuration | Automated configuration using DNS and DNS SRV. Works with leading registry services |
| Supports HTTP/2 and WebSockets | Yes (single SSL certificate only HTTP/2) | Yes, multiple certificates | Yes, multiple certificates |
| SSL security levels | Single SSL certificate; single hardwired SSL cipher policy; no upstream SSL validation | 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 |
| Support for other protocols | No: HTTP and HTTPS only | Yes; TCP and UDP supported, with passive health checks | Yes; TCP and UDP supported with passive and active health checks |
| Portability | 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 |
| Monitoring | Integrated with Amazon CloudWatch | NGINX Amplify and 3rd party products | NGINX Amplify, 3rd party products, Amazon Cloudwatch, with many more metrics |
| Logging and debugging | Amazon binary log format | customizable log files; multiple debug interfaces | Fully customizable log files; multiple debug interfaces; full support from NGINX |
| Advanced capabilities | None | Caching, Origin Serving, Prioritization, Rate Limiting and more | Caching, Origin Serving, Prioritization, Rate Limiting and more |
| Technical support | Yes, additional cost | Community support only | Yes, included in price and direct from NGINX |
| Free tier | 750 hours | Open source, no charge | 31 days free tier |
| Support for content-based routing | Only path-based routing — routing based on the request URL | Routing based on the request URL as well as the request headers, cookies or arguments | Routing based on the request URL as well as the request headers, cookies or arguments |
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 if a traffic spike came, it could take many minutes for ELB to respond and deploy additional capacity. Users had to resort to a manual forms-based process to request additional resources (“pre-warming”) in advance of traffic spikes. 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. NGINX’ pricing does not scale with the instance size, 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 to a cluster of instances. We configured a health check with the minimum 5-second frequency and minimum unhealthy threshold of 2, and sent a steady stream of requests to the ALB. When we stopped one of the instances, ALB returned a 502 error for some of the requests for a number of seconds until the health check detected the instance was down.
ALB’s health checks can only determine the health of an instance by inspecting the HTTP status code (e.g. 200-OK or 404-NotFound). 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.
Pricing
Finally, the biggest question you will face if you deploy the new ALB service will be the cost. ELB can be a significant part of your Amazon bill, and the need to run one ELB instance per application can make it cost prohibitive.
ALB carries the same limitation, and the pricing looks 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 very few people know – and you can run the LCU calculation the same way that Amazon will, 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.
Conclusion
NGINX Plus is a proven and superior solution for Layer 7 load balancing, with needed 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.
The post Choosing the Right Load Balancer on Amazon: AWS Application Load Balancer vs. NGINX Plus appeared first on NGINX.
Source: Choosing the Right Load Balancer on Amazon: AWS Application Load Balancer vs. NGINX Plus
Leave a Reply