Application Load Balancer

Leave a Comment / By /

Back to: AWS-Basics-Advanced

0

Mastering AWS Application Load Balancer (ALB) — From Basics to Advanced

Modern web applications need high availability, scalability, and secure traffic distribution. AWS Application Load Balancer (ALB) is a Layer 7 load balancer that allows you to smartly route HTTP/HTTPS traffic to multiple targets — including EC2 instances, containers, IPs, or Lambda functions.

In this blog, we will cover ALB basics, components, creation steps, routing rules, multiple domains, and SSL certificates, from beginner to advanced.

1. What is an ALB?

An ALB is a managed AWS service that distributes incoming web traffic across multiple resources, ensuring your application remains highly available, fault-tolerant, and scalable.

Why ALB?

  • Supports HTTP/HTTPS routing (Layer 7)

  • Enables host-based, path-based, and header-based routing

  • Works seamlessly with microservices and containers (ECS/EKS)

  • Supports SSL/TLS termination, WebSockets, and HTTP/2

  • Integrates with AWS WAF for application security

Real-life Example:
Imagine a web app with a blog, an API, and an image service:

  • /api/* → API servers

  • /images/* → Image servers

  • /blog/* → Blog servers

ALB routes traffic intelligently so each request reaches the correct service.

2. ALB Components You Must Know

Component Role
Load Balancer The ALB itself; receives requests and distributes them.
Listeners Define the port/protocol (HTTP/HTTPS) and forward requests to target groups.
Target Groups Logical collections of resources (EC2, IPs, Lambda) that receive traffic.
Listener Rules Define routing logic: host, path, or HTTP headers.
Targets Actual resources behind the load balancer.
Health Checks Periodically checks target availability.
Security Groups Controls inbound/outbound access.
Access Logs Optional logs for analytics and troubleshooting.

3. Advanced ALB Features

  1. Host-based routing: Route traffic based on domain names (api.example.com).

  2. Path-based routing: Route traffic based on URL paths (/images/*).

  3. Header & Query String routing: Forward traffic based on headers (X-User-Type) or query parameters.

  4. Sticky Sessions: Ensure client requests always go to the same target.

  5. SSL/TLS Termination: Offload HTTPS traffic at the ALB.

  6. WebSocket & HTTP/2 Support: For real-time apps and better performance.

  7. AWS WAF Integration: Protect your application from threats.

  8. ECS/EKS Integration: Supports dynamic container ports.

4. Step-by-Step ALB Creation

Step 1: Create Load Balancer

  1. Go to EC2 → Load Balancers → Create Load Balancer → Application Load Balancer

  2. Configure: Name, Scheme (internet-facing/internal), IP type, and listener (HTTP/HTTPS).

Step 2: Select VPC & Subnets

  • Choose a VPC and at least two subnets across AZs for high availability.

Step 3: Configure Security Groups

  • Allow HTTP/HTTPS traffic as required.

Step 4: Configure Target Groups

  • Create a target group for each service:

    • API-TG, Image-TG, Blog-TG

  • Define protocol, port, and health check path (/health).

Step 5: Register Targets

  • Add EC2 instances, IP addresses, or Lambda functions.

Step 6: Set Up Listener Rules

  • Default rule → Default target group

  • Host-based rules: api.example.com → API-TG

  • Path-based rules: /images/* → Image-TG

  • Header-based rules: X-User-Type=Premium → Premium-TG

5. Multiple Domains and SSL Certificates

ALB supports multiple HTTPS certificates using SNI. This lets a single ALB serve multiple domains securely.

Steps:

  1. Request/import SSL certificates in ACM for all domains (example.com, www.example.com, api.example.com).

  2. Add HTTPS listener (443) to ALB.

  3. Add additional certificates to the listener.

  4. Use host-based rules to route each domain to its target group.

Example Table:

Domain Target Group SSL Certificate
example.com Default-TG example.com cert
www.example.com WWW-TG www.example.com cert
api.example.com API-TG api.example.com cert

ALB uses SNI (Server Name Indication) to serve the correct certificate for each domain.

6. Header & Query String Routing

  • Forward requests based on HTTP headers (X-User-Type=Premium)

  • Forward requests based on query strings (/search?q=aws)

  • Set rule priority to ensure traffic flows correctly, with a default catch-all rule.

7. Monitoring & Logs

  • CloudWatch Metrics: RequestCount, HealthyHostCount, UnHealthyHostCount, HTTPCode_Target_2XX/4XX/5XX

  • Access Logs: Store in S3 for analysis

  • Health Checks: Ensure only healthy targets serve traffic

8. Best Practices

  1. Deploy ALB across multiple AZs

  2. Always use HTTPS with SSL termination

  3. Integrate AWS WAF for security

  4. Use host/path/header-based routing for microservices

  5. Enable sticky sessions only when necessary

  6. Use wildcard certificates for multiple subdomains

  7. Monitor with CloudWatch alarms for traffic and target health

9. Conclusion

The AWS ALB is a flexible, secure, and scalable Layer 7 load balancer:

  • Handles multiple domains and SSL certificates via SNI

  • Routes intelligently using host, path, or header rules

  • Integrates with ECS/EKS, CloudWatch, and WAF for production-grade applications

With ALB, you can host multiple services or domains on a single load balancer, achieving high availability, performance, and security for modern web applications.

Header & Query String Routing in AWS ALB

ALB supports routing rules that can inspect HTTP headers or query string parameters in incoming requests and forward them to specific target groups.

1️⃣ Prerequisites

  • An ALB with an HTTPS or HTTP listener (usually port 443 or 80).

  • One or more target groups (e.g., Premium-TG, Standard-TG).

  • AWS console or CLI access.

2️⃣ Step 1: Go to Listeners

  1. Open AWS Management Console → EC2 → Load Balancers

  2. Select your ALB → Listeners tab

  3. Click View/edit rules for the listener (HTTP/HTTPS)

3️⃣ Step 2: Add a New Rule

  1. Click Add Rule

  2. Click Insert Rule at the desired priority (rules are evaluated top to bottom)

4️⃣ Step 3: Configure Conditions

A. Header-Based Routing

  • Condition: HTTP header

  • Key: X-User-Type

  • Value: Premium

Example:

  • Requests with header X-User-Type: Premium → Forward to Premium-TG

  • All other requests → Forward to Standard-TG

B. Query String-Based Routing

  • Condition: Query string

  • Key: plan

  • Value: premium

Example:

  • Request https://example.com/dashboard?plan=premium → Premium-TG

  • Request https://example.com/dashboard?plan=standard → Standard-TG

5️⃣ Step 4: Set the Action

  • Action: Forward to target group

  • Choose the appropriate target group (e.g., Premium-TG or Standard-TG)

6️⃣ Step 5: Save Rule and Test

  1. Save the rule

  2. Test by sending requests with the specified header or query string:

# Header example
curl -H "X-User-Type: Premium" https://example.com/dashboard# Query string example
curl https://example.com/dashboard?plan=premium

  • Traffic should go to the Premium target group.

  • Requests not matching the condition go to the default target group.

7️⃣ Notes & Best Practices

  1. Rule Priority Matters:

    • ALB evaluates rules in priority order from top to bottom.

    • Default rule should be last to catch unmatched requests.

  2. Multiple Conditions:

    • You can combine host + path + header conditions for more complex routing.

  3. Header Sensitivity:

    • Header values are case-sensitive.

    • Ensure clients send headers exactly as configured.

  4. Query String Matching:

    • Supports exact match only (key=value).

    • Multiple query parameters can be specified using AND logic.

  5. Security:

    • Make sure headers used for routing cannot be spoofed by clients if used for sensitive routing.

    • Use ALB only for routing; authentication/authorization should be done at the application layer or via AWS WAF/IAM.

✅ Example Scenario

Request X-User-Type / Query Target Group
/dashboard with X-User-Type: Premium Header Premium-TG
/dashboard with plan=standard Query string Standard-TG
/dashboard without header/query None Default-TG

Session-Based Routing (Sticky Sessions) in AWS ALB

1️⃣ Prerequisites

  • An ALB already created with at least one HTTPS or HTTP listener.

  • One or more target groups with registered targets (EC2, IP, or Lambda).

  • AWS console or CLI access.

2️⃣ Step 1: Go to Target Groups

  1. Open AWS Management Console → EC2 → Target Groups

  2. Select the target group you want to enable sticky sessions for (e.g., WebApp-TG)

3️⃣ Step 2: Modify Target Group Attributes

  1. Click Actions → Edit attributes

  2. Find Stickiness

  3. Enable Stickiness (toggle ON)

  4. Choose Type: Application-based Cookie

    • ALB generates a cookie named AWSALB by default.

  5. Set Duration (TTL):

    • The amount of time the ALB should route requests from the same client to the same target (e.g., 300 seconds).

Notes:

  • TTL range: 1–604800 seconds (1 second to 7 days)

  • The ALB cookie is automatically inserted into client responses.

4️⃣ Step 3: Save Changes

  • Click Save changes

  • Sticky sessions are now enabled for this target group

5️⃣ Step 4: Test Sticky Sessions

  1. Send repeated requests from the same client:

curl -I https://your-alb-dns-name/

  1. Look at the Set-Cookie header in the response:

Set-Cookie: AWSALB=xyz123; Path=/; Expires=...

  1. Subsequent requests from the same client will be routed to the same target as long as the cookie is valid.

6️⃣ Important Notes

  1. Target Group Specific:

    • Sticky sessions are enabled per target group, not per ALB listener.

  2. Duration:

    • Set a TTL appropriate for your application.

    • Too short: session may not stick

    • Too long: uneven load distribution if targets scale down

  3. Cookies:

    • ALB-managed cookies (AWSALB) handle sticky routing automatically

    • Application-managed cookies: you can also use your own cookie by configuring “Application-based Cookie” with a custom name

  4. Use Case:

    • Useful for stateful web applications where a user session must remain on the same backend server.

    • Not recommended for stateless microservices; use shared session storage instead.

✅ Example Scenario

Client Request Sticky Session Enabled? Target Routed
First request Yes EC2-1
Second request Yes EC2-1
Third request Yes EC2-1

  • The AWSALB cookie ensures all requests from the same client go to EC2-1 during the TTL.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to Top