Application Load Balancer: Everything You Need to know

Application Load Balancers intelligently provide scalability, performance, and availability. They also guarantee that your servers are not overworked and are prepared to handle traffic spikes.

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.

cryptoshitcompra.com/wp-content/uploads/2022/06/Application-Load-Balancer-Everything-You-Need-to-know.jpg» alt=»YouTube video» width=»480″ height=»360″ data-pin-nopin=»true»/>

Features of Application Load Balancers

Layer-7 Load Balancing

Based on request attributes, you can load balance HTTP/HTTPS and gRPC traffic to Amazon EC2 instances, ECS containers, AWS Lambda, 3rd party, or on-prem servers.

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

Application Load Balancer improves container support by distributing the load across multiple ports on a single Amazon EC2 instance (dynamic port mapping). In the ECS task definition, you can specify a dynamic port, which gives the container an unused port when scheduled on the EC2 instance. This port is used by the ECS scheduler to add the task to the load balancer.

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

You can use Application Load Balancer to offload your apps’ authentication mechanism. When users access cloud applications, the Application Load Balancer will authenticate them. End users can authenticate through social identity providers like Google, Facebook, and Amazon, as well as enterprise identity providers like Microsoft Active Directory via SAML or any OpenID Connect-compliant identity provider, thanks to Application Load Balancer’s seamless integration with Amazon Cognito.

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.

• Support for Path conditions: You can configure your listener with rules that forward requests based on the URL in the request. This allows you to break down your application into smaller services (microservices) and route requests to the appropriate service based on the URL’s content.
• Support for Host conditions: You can configure your listener with rules that forward requests based on the host field in the HTTP header. This allows you to route requests to many domains using a single load balancer.
• Routing is supported based on request information such as HTTP header conditions and methods, query parameters, and source IP addresses.
• You can send routing requests to numerous applications on a single EC2 server.
• An instance or IP address can be registered with numerous target groups on a separate port.
• You can redirect requests from one URL to another.
• Returning a custom HTTP response is possible.
• Support for registering targets for the load balancer by IP address, including targets outside the VPC.
• Lambda functions can be registered as targets.
• Before routing requests, the load balancer can authenticate users of your applications using their corporate or social identities.
• Containerized apps are supported. When scheduling a task, Amazon Elastic Container Service (Amazon ECS) can choose an unused port and use it to register the task with a target group. This allows you to get the most out of your clusters.
• As health checks are defined at the target group level and CloudWatch metrics are published at the target group level, support for monitoring the health of each service individually is available. When you add a target group to an Auto Scaling group, you may dynamically scale each service based on demand.
• Additional information is recorded in compressed format in access logs.

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.