Application Load Balancer (ALB) in AWS - Deep Dive

Overview - Application Load Balancer (ALB)

What is it?

An Application Load Balancer (ALB) is a service that automatically distributes incoming internet traffic across multiple servers or resources. It works at the application level, meaning it can understand and route requests based on details like the website address or content type. This helps websites and apps stay fast and available even when many people use them at once. ALB is part of Amazon Web Services and helps manage web traffic efficiently.

Why it matters

Without an ALB, a website or app might send all user requests to just one server, which can get overwhelmed and slow down or crash. ALB solves this by spreading the work evenly, so users get quick responses and the service stays reliable. This is crucial for businesses that want happy customers and no downtime. It also allows for smarter routing, like sending users to different servers based on what they ask for, improving user experience.

Where it fits

Before learning about ALB, you should understand basic networking concepts like servers, IP addresses, and how the internet sends requests. After ALB, you can learn about other load balancers like Network Load Balancer (NLB) and Gateway Load Balancer (GLB), and dive into auto-scaling and security features that work with ALB.

Mental Model

Core Idea

An Application Load Balancer acts like a smart traffic officer that directs user requests to the best available server based on the content of the request, ensuring smooth and efficient service.

Think of it like...

Imagine a busy restaurant with many waiters. The host (ALB) listens to each customer's order and sends them to the waiter best suited to handle that order, so no waiter gets overwhelmed and every customer is served quickly.

┌─────────────────────────────┐
│       Incoming Requests      │
└─────────────┬───────────────┘
              │
      ┌───────▼────────┐
      │ Application     │
      │ Load Balancer   │
      └───────┬────────┘
              │ Routes based on
              │ content (URL, headers)
  ┌───────────┴─────────────┐
  │                         │
┌─▼─────┐               ┌───▼─────┐
│Server1│               │Server2  │
└───────┘               └─────────┘

Build-Up - 8 Steps

1

Foundation

What is a Load Balancer?

Concept: Introduces the basic idea of distributing traffic across servers.

A load balancer is like a traffic manager for internet requests. When many people visit a website, their requests need to be shared among several servers so no single server gets too busy. This helps keep the website fast and available.

Result

You understand that load balancers help websites handle many users by sharing the work.

Knowing that load balancers prevent overload helps you see why they are essential for reliable web services.

2

Foundation

Difference Between ALB and Other Load Balancers

Concept: Explains that ALB works at the application level, unlike others that work at lower levels.

Some load balancers only look at basic network info like IP addresses (Network Load Balancer). ALB looks deeper into the request, like the website address or content type, to decide where to send it. This allows smarter routing.

Result

You can tell why ALB is better for web apps that need to route based on content.

Understanding ALB’s application-level routing shows how it improves user experience by sending requests to the right place.

3

Intermediate

How ALB Routes Traffic Using Rules

🤔Before reading on: do you think ALB sends all requests to servers equally, or can it choose based on request details? Commit to your answer.

Concept: ALB uses rules to decide where to send each request based on things like URL paths or headers.

ALB lets you create rules that check parts of the request. For example, if the URL contains '/images', ALB can send that request to servers optimized for images. If it contains '/api', it sends to servers handling APIs. This makes the system more efficient.

Result

Requests are routed to the best server for their type, improving speed and resource use.

Knowing ALB’s rule-based routing helps you design systems that handle different types of traffic smartly.

4

Intermediate

Health Checks Keep Traffic Flowing Smoothly

🤔Before reading on: do you think ALB sends traffic to servers even if they are down? Commit to your answer.

Concept: ALB regularly checks if servers are healthy and only sends traffic to those that respond correctly.

ALB sends simple requests to each server to see if it’s working. If a server doesn’t respond or fails the check, ALB stops sending it traffic until it recovers. This prevents users from getting errors.

Result

Traffic only goes to healthy servers, keeping the service reliable.

Understanding health checks shows how ALB maintains uptime and user satisfaction automatically.

5

Intermediate

Security Features with ALB

Concept: ALB integrates with security tools to protect applications.

ALB can work with AWS Web Application Firewall (WAF) to block bad traffic like attacks or bots. It also supports HTTPS to encrypt data between users and servers, keeping information safe.

Result

Your application is protected from common threats and user data stays private.

Knowing ALB’s security features helps you build safer web applications without extra complexity.

6

Advanced

Scaling and High Availability with ALB

🤔Before reading on: do you think ALB itself can handle more traffic automatically, or does it need manual setup? Commit to your answer.

Concept: ALB automatically scales to handle more traffic and works across multiple zones for reliability.

ALB can grow or shrink its capacity based on how many users are visiting. It also spreads traffic across servers in different data centers (availability zones), so if one zone fails, others keep working.

Result

Your app stays fast and available even during traffic spikes or failures.

Understanding ALB’s automatic scaling and multi-zone support reveals how it supports resilient, large-scale applications.

7

Expert

Advanced Routing: Host-Based and Path-Based Rules

🤔Before reading on: can ALB route traffic differently based on both the website name and the URL path at the same time? Commit to your answer.

Concept: ALB supports complex routing rules that combine hostnames and URL paths for precise traffic control.

You can configure ALB to send requests for 'app.example.com/api' to one set of servers and 'app.example.com/images' to another. It can also route 'blog.example.com' traffic separately. This allows hosting multiple apps behind one ALB.

Result

You can efficiently manage multiple applications or services with one ALB.

Knowing how to combine host and path rules unlocks powerful, cost-effective architectures for complex web systems.

8

Expert

Sticky Sessions and Their Tradeoffs

🤔Before reading on: do you think sticky sessions always improve user experience? Commit to your answer.

Concept: ALB can keep a user’s requests going to the same server, but this has pros and cons.

Sticky sessions help when a user’s data is stored temporarily on one server, like a shopping cart. ALB uses cookies to remember the server. However, this can cause uneven load and reduce fault tolerance if that server fails.

Result

You can decide when to use sticky sessions based on your app’s needs.

Understanding sticky sessions’ benefits and risks helps you balance user experience with system reliability.

Under the Hood

ALB operates at the application layer (Layer 7) of the network, inspecting HTTP and HTTPS requests. It parses headers, URLs, and methods to apply routing rules. It maintains persistent connections with backend servers and performs health checks by sending periodic requests. ALB uses a distributed architecture across multiple availability zones to ensure scalability and fault tolerance. It integrates with AWS security services to filter traffic and encrypt data.

Why designed this way?

ALB was designed to handle modern web applications that need intelligent routing based on request content, unlike older load balancers that only distribute traffic blindly. The rise of microservices and containerized apps required routing by URL paths and hostnames. AWS chose a Layer 7 design to enable this flexibility, while also ensuring high availability and security integration. Alternatives like Network Load Balancer focus on speed and lower-level routing but lack this application awareness.

┌───────────────────────────────┐
│        Client Requests         │
└───────────────┬───────────────┘
                │
        ┌───────▼────────┐
        │ Application     │
        │ Load Balancer   │
        ├────────┬───────┤
        │        │       │
  ┌─────▼───┐ ┌──▼────┐ ┌▼──────┐
  │Rule Eval│ │Health │ │Security│
  │Engine   │ │Checks │ │Filters │
  └─────┬───┘ └──┬────┘ └──┬─────┘
        │        │        │
  ┌─────▼────────▼────────▼─────┐
  │    Backend Servers / Targets │
  └──────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does ALB handle TCP traffic like a Network Load Balancer? Commit to yes or no.

Common Belief: ALB can load balance any kind of network traffic, including TCP and UDP.

Reality: ALB only handles HTTP and HTTPS (Layer 7) traffic. For TCP or UDP, AWS uses Network Load Balancer.

Why it matters: Using ALB for unsupported traffic causes failures and wasted resources, leading to downtime.

Quick: Does ALB automatically encrypt traffic between itself and backend servers? Commit to yes or no.

Common Belief: ALB encrypts all traffic end-to-end by default.

Reality: ALB encrypts traffic between clients and itself, but encryption between ALB and backend servers must be configured separately.

Why it matters: Assuming full encryption can expose sensitive data inside the network if backend encryption is missing.

Quick: Does enabling sticky sessions always improve performance? Commit to yes or no.

Common Belief: Sticky sessions always make user experience better by keeping users on the same server.

Reality: Sticky sessions can cause uneven load and reduce fault tolerance if a server fails.

Why it matters: Misusing sticky sessions can lead to server overload and downtime.

Quick: Can ALB route traffic based on the content of encrypted HTTPS requests without extra setup? Commit to yes or no.

Common Belief: ALB can inspect and route HTTPS traffic without decrypting it.

Reality: ALB must terminate SSL/TLS (decrypt) to inspect HTTPS content for routing rules.

Why it matters: Not understanding this leads to misconfigured SSL certificates and routing failures.

Expert Zone

1

ALB’s rule evaluation order matters; rules are checked top to bottom, so rule placement affects routing behavior.

2

ALB supports HTTP/2 and WebSocket protocols, enabling modern web app features, but backend servers must also support them.

3

Cross-zone load balancing can be enabled or disabled, affecting how traffic is distributed across availability zones and impacting cost and performance.

When NOT to use

ALB is not suitable for non-HTTP protocols like TCP or UDP; use Network Load Balancer instead. For ultra-low latency or static IP requirements, NLB is better. If you need to route at the network layer without inspecting content, ALB is overkill and adds latency.

Production Patterns

In production, ALB is often paired with auto-scaling groups to dynamically add or remove servers based on load. It is used with AWS WAF for security and integrated with Route 53 for DNS-based routing. Multi-tenant SaaS apps use ALB’s host-based routing to serve multiple customers from one load balancer.

Connections

Content Delivery Network (CDN)

Builds-on

Understanding ALB’s routing helps grasp how CDNs cache and deliver content closer to users, improving speed beyond load balancing.

Traffic Signal Control Systems

Same pattern

Both ALB and traffic signals direct flows efficiently to avoid congestion, showing how managing demand improves system performance.

Operating System Process Scheduling

Similar mechanism

Like ALB routes requests to servers, OS schedulers assign CPU time to processes, balancing load and responsiveness.

Common Pitfalls

#1 Sending traffic to unhealthy backend servers.

Wrong approach:

Configuring ALB without health checks or ignoring health check failures.

Correct approach:

Enable and configure health checks so ALB routes only to healthy servers.

Root cause:

Not understanding that ALB needs health checks to avoid sending traffic to down servers.

#2 Misconfiguring SSL termination causing routing failures.

Wrong approach:

Not uploading SSL certificates to ALB but expecting HTTPS routing rules to work.

Correct approach:

Upload and configure SSL certificates on ALB to terminate HTTPS and enable routing rules.

Root cause:

Lack of knowledge that ALB must decrypt HTTPS to inspect requests.

#3 Overusing sticky sessions causing uneven load.

Wrong approach:

Enabling sticky sessions for all traffic without considering server capacity.

Correct approach:

Use sticky sessions only when necessary and monitor load distribution.

Root cause:

Assuming sticky sessions always improve user experience without tradeoffs.

Key Takeaways

Application Load Balancer (ALB) smartly distributes web traffic by inspecting request content, improving speed and reliability.

ALB routes requests based on rules using URL paths and hostnames, enabling flexible and efficient traffic management.

Health checks ensure ALB sends traffic only to healthy servers, maintaining uptime and user satisfaction.

ALB integrates security features like encryption and firewall rules to protect applications from threats.

Understanding ALB’s advanced routing and scaling capabilities helps build resilient, scalable, and secure web applications.