AWS Application Load Balancer (ALB) Explained

What is AWS Application Load Balancer?

AWS Application Load Balancer is a managed load balancer that operates at Layer 7, which means it understands HTTP and HTTPS traffic and can make routing decisions based on application-level information.

Instead of forwarding traffic only by port and protocol, ALB can inspect the incoming request and decide which backend service should handle it. This is why it is so useful in modern cloud-native applications with multiple services behind a single front-end domain.

Why ALB matters in AWS networking

Many cloud applications are no longer single backends. They often consist of APIs, frontends, admin portals, authentication endpoints, and microservices. ALB helps keep all of that organised behind one web-facing entry point.

How AWS ALB works

ALB receives HTTP or HTTPS requests on listeners, evaluates listener rules, and forwards traffic to the correct target group. Those target groups can contain EC2 instances, containers, pods, or IP targets depending on your architecture.

Client
  |
  v
Application Load Balancer
  |
  v
Listener (HTTP / HTTPS)
  |
  v
Rule evaluation
  |
  v
Target Group
  |
  v
EC2 / ECS / EKS / IP targets

Step-by-step flow

1. A client sends an HTTP or HTTPS request.
2. The request reaches the ALB listener.
3. ALB evaluates configured listener rules.
4. The request is matched to a target group.
5. Traffic is sent to a healthy backend target.

Key features of AWS ALB

Listeners and rules in ALB

A listener checks for incoming connections on a configured port and protocol, such as HTTP 80 or HTTPS 443. Rules attached to that listener determine where traffic should go.

Why listener rules matter

• They allow a single ALB to handle multiple application paths.
• They support host-based routing for different domains or subdomains.
• They help keep architectures simpler by avoiding separate load balancers for every service.

HTTPS Listener :443
  |
  +--> if host = api.example.com      --> API Target Group
  |
  +--> if host = app.example.com      --> Frontend Target Group
  |
  +--> if path = /admin/*             --> Admin Target Group
  |
  +--> default action                 --> Default Target Group

Path-based routing

Path-based routing allows ALB to inspect the URL path and send traffic to different backend services depending on which part of the application the user is trying to access.

Example

example.com/api/*    --> API service
example.com/admin/*  --> Admin service
example.com/*        --> Frontend service

This is especially useful for microservices and applications where different components need separate scaling, deployments, or teams.

Host-based routing

Host-based routing allows ALB to send traffic to different backends based on the hostname in the request. This is common when multiple applications share one ALB.

Example

api.example.com   --> API target group
app.example.com   --> Frontend target group
auth.example.com  --> Authentication target group

Host-based routing can reduce infrastructure sprawl while keeping services logically separated.

ALB vs NLB

ALB and NLB are both important, but they are designed for different traffic patterns. Picking the right one depends on whether your routing needs are application-aware or network-level.

Real-world ALB architecture example

A common ALB-based architecture for a public web platform may look like this:

User
  |
  v
Route 53
  |
  v
CloudFront
  |
  v
Application Load Balancer
  |
  +--> /api/*        --> API Target Group
  |
  +--> /admin/*      --> Admin Target Group
  |
  +--> default       --> Frontend Target Group
  |
  v
EC2 / ECS / EKS workloads

In this design:

• Route 53 resolves the domain name.
• CloudFront may act as the CDN layer in front.
• ALB receives HTTP or HTTPS traffic.
• Listener rules send requests to the correct target group based on host or path.

Health checks in ALB

ALB uses health checks to determine which targets are available. If a target fails health checks, ALB stops sending traffic to it.

Why health checks matter

• They keep broken instances out of active traffic flow.
• They improve reliability across multiple targets.
• They reduce user-facing errors when some backends fail.

What to validate

• Correct health check path such as /health
• Expected HTTP response code
• Correct port and protocol
• Backend readiness to answer health checks

Terraform example for AWS ALB

Below is a simple example that creates an Application Load Balancer, target group, and HTTP listener.

resource "aws_lb" "alb" {
  name               = "example-alb"
  internal           = false
  load_balancer_type = "application"
  subnets            = ["subnet-aaa111", "subnet-bbb222"]
  security_groups    = ["sg-12345678"]
}

resource "aws_lb_target_group" "app" {
  name     = "example-alb-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = "vpc-12345678"

  health_check {
    path     = "/health"
    protocol = "HTTP"
    matcher  = "200"
  }
}

resource "aws_lb_listener" "http_80" {
  load_balancer_arn = aws_lb.alb.arn
  port              = 80
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app.arn
  }
}

What this Terraform does

• Creates a public Application Load Balancer.
• Creates an HTTP target group.
• Uses a health check path of /health.
• Creates an HTTP listener that forwards traffic to the target group.

Common ALB mistakes

Using ALB for non-HTTP workloads

ALB is designed for HTTP and HTTPS application traffic. Teams sometimes force it into use cases better suited to NLB.

Bad rule design

Overlapping path rules, missing defaults, or unclear priorities can make routing hard to troubleshoot.

Weak health check configuration

If the health endpoint is wrong or unstable, healthy targets may be removed from service unnecessarily.

Ignoring target group separation

Combining unrelated services into a confusing target group design can make operations and debugging harder.

Wrong load balancer choice

Some teams choose ALB for every workload without checking whether transport-layer performance or protocol requirements point to NLB instead.

ALB troubleshooting guide

Practical checklist

• Check listener ports and protocols.
• Review listener rules from highest to lowest priority.
• Confirm target groups are attached correctly.
• Validate health check path and backend response.
• Check that ALB is really the right load balancer for the workload.

ALB interview questions

Frequently asked questions

Related cloud networking resources