10 reasons why you should think about using an AWS Application Load Balancer

In this blog post, I would like to share 10 points that can be achieved with an AWS Application Load Balancer. These can not be achieved or are limited in a classic setup with an Elastic Load Balancer or NGINX Proxy.

What is an Application Load Balancer (ALB)

Unlike the classic load balancer or network load balancer, the ALB works on layer 7 of the OSI model. This allows it to inspect the traffic at the application level instead of IP and port. It makes it possible to define more complex rules and to address different services via subdomains and path-based routes.

I would like to dispel the myth that most people automatically associate with the term load balancer:

A load balancer does not necessarily need two or more instances to be beneficial! Even a setup with only one instance and one load balancer can save costs and bring additional benefits, depending on the application.

In 7 out of 10 points mentioned below an architecture where there is a single instance or service is connected can be applied to the application load balancer.

1. High Availability*
2. Automatic Failover*
3. SSL Termination
4. Monitoring
5. Access Logs
6. Dual Stack IPv6 Integration
7. HTTP/2 and websockets integration
8. Service Distribution*
9. Security (DDOS, WAF, AWS Shield)
10. API Control

* ) only applies to setups with at least two instances/services

1) High Availability

One of the most important tasks of a load balancer is the distribution of the traffic to different endpoints. High availability is achieved by ensuring that if there is more than one end point, the request is always routed to an accessible end point. To achieve the highest possible level of availability even in the event of a major outage, the end points are located in two or more Availability Zones.

2) Automatic Failover

Using metrics and watchdogs, the ALB can detect whether individual endpoints are no longer functioning properly and automatically select the fail over to another endpoint.

3) SSL Termination

One of the most interesting features of the ALB is the possibility of SSL termination. This brings some significant advantages which lead to a considerable cost saving especially in small environments and in large environments to a massive saving in maintenance effort.
Instead of creating their own certificates or buying expensive wildcard certificates, certificates can be obtained quickly, easily, and free of charge from the ACM. Because AWS has its own root CA, acceptance is very good. The creation and renewal of certificates can be done in a few steps and is immediately transferred to the load balancer. This eliminates the time-consuming rolling out, installation, and maintenance of new certificates for many endpoints.
Independent of this, own certificates can of course also be transferred to the ACM.

Related content:
AWS Certificate Manager

4) Health Monitoring

The ALB offers different metrics to display and evaluate latencies, HTTP codes, number of requests, etc. This allows you to analyze the load distribution over specific periods, peaks, and other problems This eliminates the need to analyze the log files to generate visual insights. The metrics are available almost in real-time.

Example: CloudWatch metrics of an Application Load Balancer

5) Access Logs

In addition to the metrics, the entire flow logs of the load balancer can be exported and evaluated in S3. This can be used in connection with machine learning models to identify and evaluate attacks, exploits, or unauthorized access. In a normal setup without a load balancer it would be necessary to activate logging for the specific ports and services in the instance and export them via an agent.

Example: Log files automatically exported to S3

6) Dual Stack IPv6 integration

Endpoints, applications, and services that previously only had IPv4 support are now outwardly accessible as dual stack IPv4 & IPv6. The ALB can receive requests as IPv4 and IPv6 in dual stack mode and connects internally to the endpoints based on IPv4. Since many applications still have only an experimental IPv6 implementation or older existing systems have to be integrated, this is a simple and effective way to make them now uniformly accessible via IPv6.

7) HTTP/2 and websockets integration

HTTP/2 brings some important advantages over the old HTTP 1.1 protocol. As with IPv6, some applications still do not support HTTP/2. Using HTTP/2 can lead to an enormous increase in speed depending on the application. With HTTP 1.1, a separate connection is established for querying each page element (CSS, JS, images) and the transmission is done in uncompressed format. Due to the maximum number of open connections or browser restrictions, long loading times and latencies can occur. With HTTP/2, multiple data is transmitted in parallel in one connection and the transmission is in binary format. In addition, the Application Load Balancer provides bi-directional communication channels between a client and a server over a long-running TCP connection using websockets.

8) Service Distribution

Behind an ALB different instances and services can be addressed based on rules like subdomains or paths. Thus it is possible to connect different services with a single ALB in a highly available way. It does not matter if the endpoint is an EC2 instance, an API gateway, REST API, or an on-premise instance. In this way, highly complex configurations can be realized with only one application load balancer. Time-consuming configuration and maintenance of DNS servers is not necessary, because the load balancer can take over the distribution of requests for different subdomains.

Example: routing by subdomain rules (source)

Example: routing by path rules (source)

9) Security

A major advantage is that the ALB is a proxy between the user and the instance and the instance is therefore not accessible from the Internet without protection. Possible exploits or open ports cannot be discovered via port scanning. The instance itself can also be located in a private subnet. An ALB is also less susceptible to DDOS attacks such as syn floods than the usual web servers. In case of attacks, the monitoring and logging of the ALB allows faster countermeasures to be taken.

In addition to the fine grained settings via Security Groups, the AWS specialised services like Web Application Firewall (WAF) and AWS Shield are also available to defend against large DDOS attacks.

Example: DDoS-resilient reference architecture (source)

Related content:
Web Application Firewall for Application Load Balancers
AWS Shield

10) API control

The ALB can be set up quickly and easily via the AWS GUI. In addition, it is possible to control and change all functions via API using the AWS SDKs. This provides many possibilities to configure the running load balancer. Adding subdomains, path based routes, or new endpoints can be implemented automatically and within a CD/CI.

Related content:
AWS SDK
Example: Node.js Class ELBv2

Costs

The costs of the application load balancer are determined on the basis of two cost factors:

• Application Load Balancer-hour (or partial hour)
• LCU-hour (or partial hour)

While hourly usage is easy to determine (usually 24 hours/day), LCU units are somewhat more complex and are calculated using the following criteria:

• New connections
• Active connections
• Processed bytes
• Rule evaluations

For an application load balancer in idle or low load, the costs are about 20 USD per month, depending on the region.

To understand and calculate the costs (especially LCU) I recommend the following calculator: Application Load Balancer Pricing

Conclusion

A Load Balancer is essential in productive environments with highly available architectures. Many services at AWS automatically provision a pre-configured Load Balancer without the need or possibility to configure it. For your own applications running on EC2 instances or different services that should be accessible via a central endpoint, the use of an ALB according to the above mentioned criteria would make sense. There is also no taboo to cascade several Load Balancers, one after another. This is often the case, for example, if a Load Balancer in a private subnet connects a highly available application and cannot be reached from outside. A higher-level ALB in a public subnet can connect the high availability application via the Load Balancer in the private subnet.
The ALB scales automatically and AWS ensures that the underlying resources are adjusted to the demand. Therefore you should never refer to the IP address of the ALB but always use the unique DNS name. IP of the ALB can change due to internal autoscaling or configuration changes.

These 10 use cases and examples for the use of an Application LoadBalancer are only a rough overview to show the versatile possibilities of a Load Balancer. For the effective and meaningful integration of an Application Load Balancer, the existing architecture must be identified and analyzed. Since the subsequent integration of a Load Balancer leads to instances and endpoints that were previously accessible from the outside now being operated in a private subnet or with restrictive firewall rules, the integration of an Application Load Balancer immediately increases security.