Any IT team’s security infrastructure is built around load balancers. Load Balancers ensure your application can handle the incoming traffic. In this article, we will discuss the Application Load Balancer on AWS in more detail.
What is an Application Load Balancer?
Application Load Balancer, aka ALB, is an Elastic Load Balancer or ELB on AWS. It operates at the application layer (the seventh layer) of the Open Systems Interconnection (OSI) model. ALBs have three components – listeners, load balancer, and the target group. After receiving a request, the load balancer evaluates the listener rules in priority order (to choose which rule to execute). It then selects a target from the target group for the rule action. You can set up listener rules to send requests to different target groups depending on the content of the application traffic. The default routing algorithm for ALBs is Round-robin; however, you can choose the least outstanding requests routing technique. As your needs change, you can delete and add targets from your load balancer without interrupting your application’s general flow of requests. Elastic Load Balancing (ELB) allows you to scale your load balancer as your application’s traffic changes over time. All Elastic Load Balancers can automatically scale to the vast majority of workloads. You can also build health checks to monitor the status of your application on the registered targets so that the load balancer only sends requests to the healthy targets.
Features of Application Load Balancers
Layer-7 Load Balancing
Security Features
ALB supports desync safeguards based on the HTTP desync-guardian library. This capability protects customers’ applications against HTTP vulnerabilities caused by Desync without sacrificing availability or latency. Customers can also set their level of tolerance for questionable requests based on the architecture of their applications.
Outposts Support
AWS Outposts is a completely managed solution that extends AWS infrastructure, services, and tools to almost any data center, co-location space, or on-premises facility for a truly consistent hybrid experience. You can use Application Load Balancers with AWS Outposts. Customers can deploy ALBs on supported instance types, and the ALB will automatically scale up to the rack capacity to accommodate varying levels of application workloads without the need for manual intervention. You can also configure ALB to receive reminders/alerts to assist them in navigating their load balancing capacity requirements. Customers can use the same AWS Console, CLI, and APIs to provision and manage ALBs on Outposts that they use to provision and manage ALBs in AWS Regions.
HTTPS Termination
An Application Load Balancer(ALB) supports HTTPS termination between clients and the load balancer. This means that the connection between your client and ALB is HTTPS, but the connection between ALB and application servers(EC2, ECS, etc.) is HTTP. Since the connection between ALB and application servers() is inside your VPC, it is protected by external entities by default. ALBs can manage SSL certificates using AWS Certificate Manager for pre-defined security policies and AWS Identity and Access Management (IAM).
HTTP/2 and gRPC Support
HTTP/2 is a new HyperText Transfer Protocol (HTTP) form that allows many requests to be transmitted on the same connection using a single, multiplexed connection. It also provides SSL connections to clients and compresses header data before sending it out in binary format. gRPC traffic can be routed and load-balanced across microservices or between gRPC-enabled clients and services using the Application Load Balancer. This enables the smooth integration of gRPC traffic management into architectures without requiring changes to the underlying infrastructure on the clients’ or services’ end. gRPC is the protocol of choice for inter-service communications in microservices architectures, and it employs HTTP/2 for transmission. It has features like efficient binary serialization, support for a variety of languages, as well as the inherent benefits of HTTP/2, such as a smaller network footprint, compression, and bi-directional streaming, making it superior to legacy protocols like REST.
Sticky Sessions
Sticky sessions allow requests from the same client to be routed to the same target using cookies. We can set up sticky sessions easily by simply enabling sticky sessions and cookies in the ALB attributes. Application Load Balancer(ALB) supports both duration-based cookies and application-based cookies. Determining how long your load balancer should constantly send the user’s request to the same target is the key to managing sticky sessions. The Sticky sessions are enabled at the target group level. You can deploy a combination of duration-based stickiness, application-based stickiness, and no stickiness across different target groups.
Native IPv6 Support
Native Internet Protocol version 6 (IPv6) is supported by Application Load Balancers in a VPC. This enables clients to connect to the Application Load Balancer using IPv4 or IPv6.
Request Tracing
On all requests going into the load balancer, the Application Load Balancer injects a new custom identifier “X-Amzn-Trace-Id” HTTP header. Request tracing allows you to follow the progress of a request as it goes to numerous AWS services using its unique ID. You can utilize request tracing to find performance or bottle-neck issues in your application stack.
Redirects
The Application Load Balancer(ALB) can redirect an incoming request from one URL to another. For example, you can redirect HTTP requests to HTTPS requests, allowing you to fulfill your compliance goal of secure browsing while improving your site’s search ranking and SSL/TLS score. Redirects can also route users to a different website, e.g., an older version of an application to a newer version.
Fixed Response
The Application Load Balancer can manage which client requests your applications serve. Without passing the request to the application, you can respond to incoming requests with HTTP error response codes and custom error messages directly from the load balancer.
WebSockets Support
Application Load Balancers support WebSockets. WebSockets allow a server to send real-time messages to end users without requiring them to request (or poll) an update from the server. Over a long-running TCP connection, the WebSockets protocol allows bi-directional communication channels between a client and a server.
Server Name Indication (SNI)
SNI (Server Name Indication) is a TLS protocol extension in which a client specifies the hostname to connect to in the TLS handshake. The load balancer may present numerous certificates via a single secure listener, allowing it to support several secure websites with just one secure listener. With SNI, application load balancers use an intelligent certificate selection process to match the hostname in the request to the corresponding SSL certificate. If a client’s hostname matches multiple certificates, the load balancer chooses the optimal certificate based on several parameters, including the client’s capabilities.
IP addresses as Targets
By using the IP addresses of the application backends as targets, you can use ALBs to load balance any application hosted on AWS, on-premises, or even other cloud providers. This enables load balancing to any IP address and interface on an application backend. IP addresses can also be used as targets for load balancing applications hosted on-premises (through Direct Connect or VPN), peered VPCs, and EC2-Classic (using ClassicLink). You can migrate to the cloud, burst to the cloud, or failover to the cloud with the ability to load balance across on-premises resources and AWS.
Lambda functions as Targets
Users can access serverless apps from any HTTP client, including web browsers, thanks to Application Load Balancers’ support for executing Lambda functions to deliver HTTP(S) requests. You may use the support for content-based routing rules to direct requests to distinct Lambda functions by registering Lambda functions as load balancer targets. An Application Load Balancer can be used as a standard HTTP endpoint for apps that leverage servers and serverless computing. To develop applications, you can use Lambda functions to create a whole website or combine them with EC2 instances, containers, and on-premises servers.
Content-based Routing
Suppose your application is made up of numerous independent services. In that case, an Application Load Balancer can route a request to a service based on the content of the request, such as the Host field, Path URL, HTTP header, HTTP method, Query string, or Source IP address. Host-based Routing: Using The HTTP header’s Host field, ALB can route a client request to several domains from the same load balancer. Path-based Routing: The URL path of the HTTP header can be used to route a client request. HTTP header-based routing: Any standard or custom HTTP header value can be used to route a client request. HTTP method-based routing: Any standard or custom HTTP method can be used to redirect a client request. Query string parameter-based routing: A client request can be routed depending on the query string or parameters. Source IP address CIDR-based routing: A client request can be routed based on the source IP address CIDR from which it originates.
Containerized Application Support
ALB with Web Application Firewall
Using AWS WAF, you may now safeguard your web apps on your Application Load Balancers. AWS WAF protects your web applications from typical web exploits that can cause application downtime, compromise security, or consume excessive resources.
Slow Start Mode with Load-Balancing Algorithm
Application Load Balancer(ALB) supports a round-robin load-balancing algorithm. Additionally, the round-robin mechanism in Application Load Balancer includes a delayed start mode that allows you to add new targets without overloading them with requests. The slow start option will enable targets to warm up before taking their fair share of requests during a specified ramp-up period. The slow start is beneficial for apps that rely on cache and require a warm-up period before they can react to queries at their best.
User Authentication
Application Load Balancer can also verify enterprise users by connecting directly with your identity provider if you already have a bespoke IdP solution that is OpenID Connect-compatible.
Benefits of shifting from a Classic Load Balancer(CLB) to an Application Load Balancer(ALB)
Classic Load Balancers were the first type of Load Balancers from AWS. Although powerful, with the introduction of ALBs and NLBs, Classic Load Balancers are slowly getting outdated. Many features now supported by the newer versions of load balancers are not present in the Classic Load Balancer.
Final Words
Application Load Balancers are newer generation load balancers that are elastic, scalable, and come with many different features, especially for web application needs. You might need to use Classic Load Balancers if you have legacy applications hosted on the EC2 Classic Network, but for all the newer generation workloads, ALBs are going to be an obvious choice.
