Careeroza

ALB

AWS Application Load Balancer (ALB) is a fully managed, layer 7 load balancing service that routes incoming HTTP, HTTPS, and gRPC traffic across multiple targets—such as Amazon EC2 instances, Docker containers, microservices, and AWS Lambda functions.

Operating at the Application Layer (Layer 7 of the OSI model), an ALB makes intelligent routing decisions by inspecting the actual content of the incoming network request, including URL paths, HTTP headers, query strings, and cookie parameters.


Core Component Hierarchy

The operational lifecycle of an ALB relies on a structured hierarchy of three main components:

  • Listeners: A front-facing process that continuously monitors for connection requests from clients based on a configured protocol (HTTP or HTTPS) and port (typically 80 or 443).

  • Rules: Positioned directly inside a listener to dictate how incoming requests are processed. A rule consists of Conditions (what to look for in the request) and Actions (what to do when a match occurs).

  • Target Groups: A logical collection of backend resources that receive the forwarded traffic. Each target group tracks the health of its registered resources using independent health check configurations.


Advanced Content-Based Routing Patterns

Because an ALB can dissect Layer 7 payload headers, you can build complex routing architectures that decouple your frontend services from backend microservices:

  • Path-Based Routing: Routes traffic to completely different target groups based on the URI text path in the URL string. For example, you can configure a rule to send all requests hitting example.com/api/* to a fleet of high-performance Node.js container workers, while routing requests for example.com/static/* to a separate storage pool.

  • Host-Based Routing: Routes traffic based on the HTTP Host header domain name in the request. This allows a single ALB to manage multiple applications simultaneously. For instance, traffic reaching app.domain.com can be directed to Target Group A, while traffic reaching dashboard.domain.com is seamlessly pushed to Target Group B.

  • Advanced Query String and Header Matching: Rules can evaluate specific client-side conditions before letting traffic hit your servers. This allows you to inspect incoming cookies, look for custom HTTP headers (e.g., verifying a mobile app version string), or match explicit query parameters to route premium users to dedicated, isolated server pools.


Key Technical Capabilities

  • SSL/TLS Termination (HTTPS Offloading): To protect backend processing capacity, an ALB integrates natively with AWS Certificate Manager (ACM). You can install an SSL certificate directly onto the ALB. The load balancer decrypts incoming HTTPS traffic at the edge, validates the security handshake, and passes the requests to your backend servers via standard, unencrypted HTTP (port 80), removing the cryptographic compute burden from your application code.

  • Native Authentication Gates: ALB can act as a secure security perimeter before a single line of your application code executes. It integrates directly with Amazon Cognito User Pools and external Identity Providers (IdPs) supporting OpenID Connect (OIDC). When a user hits a protected endpoint, the ALB intercepts the request, redirects the user to a secure login page, validates their token headers, and only grants backend access upon successful authentication.

  • Sticky Sessions (Session Affinity): By default, an ALB routes every individual HTTP request independently using a round-robin or least-outstanding-requests algorithm. However, for legacy stateful applications that store user data locally in server memory, you can enable Sticky Sessions. The ALB drops a custom cookie into the client's web browser, ensuring that subsequent requests from that specific user are consistently pinned to the exact same backend EC2 instance for the duration of their active session.

  • HTTP/2 and gRPC Support: ALB natively supports modern, high-performance protocols. It optimizes connection multiplexing via HTTP/2 and handles strict binary serialized streaming patterns via gRPC, which is essential for low-latency communication between microservices.


Health Check Mechanics and Failover Execution


To ensure maximum availability, an ALB actively assesses the status of every single backend resource registered inside its target groups:

[ Incoming Client Request ] ───► [ ALB Node ] ───► (Evaluates Health Status) ───► [ Healthy Target EC2 ]
                                                      │ (Drops Traffic)
                                                      ▼
                                            [ Unhealthy Target EC2 ]

  • Dynamic Request Probing: You define an explicit HTTP verification path (such as /health or /api/status) along with expected return parameters (e.g., matching a standard HTTP 200 OK status response). At fixed intervals (e.g., every 30 seconds), the ALB pings each server interface.

  • Automated Traffic Dropping: If a backend application encounters a database crash or an out-of-memory error and fails a configured number of consecutive health checks, the ALB marks that specific node as Unhealthy.

  • Zero-Downtime Shifting: The ALB immediately stops routing subsequent user requests to that broken target. It silently shifts the entire traffic load across remaining healthy instances within milliseconds, preventing users from seeing connection errors while an Auto Scaling Group spins up a replacement server.