Application Load Balancer (ALB)

An ALB can inspect and route traffic based on the content of the HTTP request. This enables sophisticated routing rules that go beyond simple IP and port.

• Host-based routing: Direct traffic based on the Host header (e.g., api.example.com vs. www.example.com).
• Path-based routing: Route requests to different backend services based on the URL path (e.g., /images/* to a storage service, /api/* to an application server).
• Header-based routing: Make decisions using custom HTTP headers, such as X-API-Version or User-Agent.
• Query string parameter routing: Route based on key-value pairs in the URL query string.

This allows a single load balancer to front a microservices architecture, directing requests to the appropriate service based on the request context.

Also known as sticky sessions, this feature ensures requests from a specific user are consistently sent to the same backend target. ALBs offer more flexible persistence mechanisms than lower-level balancers.

• Application-controlled cookies: The ALB generates and manages its own cookie to track the session.
• Duration-based cookies: The cookie expires after a specified time.
• Application cookies: The ALB uses an existing cookie set by the backend application, providing application-defined stickiness.

This is critical for stateful applications where user session data is stored locally on a server, such as shopping carts or multi-step forms.

An ALB can handle the computationally expensive process of decrypting incoming HTTPS traffic and optionally re-encrypting it to the backend. This centralizes certificate management and offloads work from application servers.

• Centralized SSL Certificates: Manage and renew TLS/SSL certificates at the load balancer level.
• Support for SNI: Allows hosting multiple secure applications (with different domain names) on a single load balancer using Server Name Indication.
• Security Policy Enforcement: Define supported TLS versions and cipher suites centrally.
• Client Certificate Authentication: The ALB can validate client certificates before forwarding requests.

This simplifies compliance, reduces backend server load, and provides a single point for cryptographic policy enforcement.

ALBs continuously monitor the health of registered backend targets (e.g., servers, containers) using configurable probes. Unhealthy targets are automatically taken out of rotation.

• Protocol Flexibility: Health checks can use HTTP, HTTPS, TCP, or gRPC protocols.
• Granular Configuration: Define the check interval, timeout, healthy/unhealthy threshold counts, and the specific path/port to probe.
• Application-Aware: An HTTP health check can verify a specific endpoint (e.g., /health) returns a 2xx or 3xx status code, ensuring the application logic is functioning.

This feature is fundamental for high availability, ensuring traffic is only directed to targets capable of handling requests.

Modern ALBs natively support advanced application protocols essential for real-time, interactive applications.

• WebSocket Protocol: Enables full-duplex, persistent communication channels between a client and server (e.g., for chat apps, live dashboards). The ALB efficiently proxies WebSocket connections without terminating them.
• HTTP/2: Supports multiplexing multiple requests over a single TCP connection, reducing latency and improving page load times. ALBs can accept HTTP/2 from clients and communicate with backends using HTTP/1.1 or HTTP/2.
• gRPC Support: Some ALBs can route gRPC traffic, which uses HTTP/2 as its transport, enabling efficient microservice communication.

This native support allows developers to build modern applications without complex workarounds for protocol handling.

ALBs provide features that facilitate safe, controlled application updates and sophisticated traffic shaping.

• Weighted Routing: Distribute traffic across multiple backend target groups based on assigned weights (e.g., 90% to current version, 10% to new version), enabling canary deployments.
• Redirects & Fixed Responses: The ALB can return HTTP redirects (e.g., from HTTP to HTTPS) or static HTTP responses (like a maintenance page) without hitting a backend.
• Request Tracing: Insert unique identifiers (like X-Amzn-Trace-Id) into requests for end-to-end tracing across distributed services.
• Integration with Auto Scaling: Seamlessly works with cloud auto-scaling groups to register and deregister instances dynamically based on load.

These capabilities make the ALB a critical component for implementing continuous deployment strategies and managing application lifecycle.

Layer 7 load balancing is the foundational principle of an Application Load Balancer (ALB). It operates at the application layer of the OSI model, enabling routing decisions based on the actual content of HTTP/HTTPS messages.

• Key differentiator: Unlike Layer 4 load balancers that only see IPs and ports, Layer 7 can inspect URL paths, HTTP headers (like Host or X-Forwarded-For), SSL session IDs, and cookies.
• Primary use case: This allows for advanced routing, such as sending requests for /api/* to a pool of API servers and requests for /images/* to a static content server, all from a single entry point.

Session persistence, commonly called sticky sessions, is a method where an ALB directs all requests from a specific user session to the same backend server.

• Mechanism: The ALB uses a cookie (either generated by the ALB itself or based on an existing application cookie) to identify the client. Subsequent requests containing this cookie are routed to the originally assigned server.
• Critical for state: This is essential for applications where user session data is stored locally on a server's memory (stateful applications), preventing errors or data loss that would occur if requests were distributed randomly.
• ALB Implementation: AWS ALB, for example, supports application-controlled cookies (duration set by the app) and load balancer-generated cookies with configurable durations.

A health check is a periodic, automated test performed by the ALB to verify the operational status and readiness of its registered backend targets (e.g., EC2 instances, containers, IP addresses).

• Purpose: To dynamically route traffic only to healthy targets, ensuring high availability and removing the need for manual intervention during failures.
• Configuration: Administrators define the protocol (HTTP, HTTPS, TCP), port, request path (e.g., /health), success codes (e.g., 200), and check interval. A target is marked unhealthy after consecutive failed checks and stops receiving traffic until it passes consecutive checks.
• Proactive failure handling: This is a core component of creating a self-healing system, allowing the ALB to seamlessly handle instance crashes, application errors, or network issues.

Content-based routing is the flagship feature of an ALB, allowing it to make intelligent forwarding decisions by examining the content of incoming HTTP/HTTPS requests.

• Routing Rules: Rules are evaluated in order and consist of a condition and a target group action.
• Common Conditions:
  • Path-based: Path is /api/* or Path matches /users/[0-9]+.
  • Host-based: Host is app.example.com (enabling virtual hosting).
  • Header-based: Header X-API-Versionisv2``.
  • Query string-based: Query actionisdelete``.
  • HTTP method-based: Http request method is POST.
• Example Flow: A request to https://shop.example.com/checkout can be routed to a checkout-service target group, while a request to https://shop.example.com/images/logo.png is routed to a static-assets target group.

SSL/TLS termination is the process where the ALB decrypts incoming HTTPS traffic, performs load balancing logic on the plaintext HTTP request, and can then optionally re-encrypt the traffic (or send it unencrypted) to the backend targets.

• Performance Benefit: Offloading the computationally expensive cryptographic decryption/encryption from backend servers to the specialized ALB hardware improves backend server performance and capacity.
• Certificate Management: SSL certificates are installed and managed centrally on the ALB, simplifying renewal and security policy enforcement (e.g., enforcing TLS 1.2+).
• Backend Security: Traffic from the ALB to backend instances can travel over the internal network (unencrypted for speed) or be re-encrypted using a separate certificate for end-to-end encryption, depending on security requirements.

Connection draining (also called deregistration delay) is a process that allows an ALB to gracefully remove a backend target from service without disrupting existing user connections.

• Scenario: When a target is being taken down for deployment, scaling in, or maintenance, the ALB stops sending new requests to it but allows in-flight requests to complete.
• Configurable timeout: Administrators set a drain duration (e.g., 300 seconds). The ALB waits for existing sessions to finish within this period before fully terminating the connection to the target.
• Importance for Zero-Downtime Deployments: This feature is critical for implementing blue-green and canary deployments, as it ensures users do not experience errors or interrupted transactions during backend updates.