Cloud Parts

AWS Application Load Balancer

AWS’s managed layer-7 load balancer: routes HTTP requests by host, path or header to EC2, containers, IPs or Lambda.

What it is
Load balancers
Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary
Facts checked
5 October 2026

What it is

An Application Load Balancer (ALB) is one of the Elastic Load Balancing types. It lives in your VPC, with a node in each Availability Zone you enable. A listener accepts connections on a port, say HTTPS on 443, and terminates TLS. Its rules are checked in priority order: each matches on host name, path, HTTP header, method, query string or source IP, then forwards to a target group, redirects, or returns a fixed response. A target group holds the actual backends (instances by ID, IP addresses, or a single Lambda function) and runs its own health checks.

Because it understands HTTP, one ALB can front many services: /api/* to one container service, admin.example.com to another. It supports HTTP/2, gRPC and WebSockets, can sign users in through any OpenID Connect provider before a request reaches your app, and scales its own capacity with traffic. You pay about $0.0225 an hour (roughly $16 a month in US East) plus Load Balancer Capacity Units, measured by whichever is highest of new connections, active connections, bytes processed and rule evaluations.

Why teams pick it

  • Content-based routing lets one load balancer and one certificate serve many services
  • Integrates with Auto Scaling groups and ECS, which register and deregister targets for you
  • Built-in OIDC or Cognito sign-in, AWS WAF attachment and access logs
  • Can invoke Lambda functions directly, so small HTTP endpoints don’t need API Gateway

Watch out for

  • Regional only: multi-region failover needs Route 53 or Global Accelerator on top
  • Clients reach it by DNS name, not by addresses you choose; for static IPs to allow-list, put Global Accelerator or a Network Load Balancer in front
  • Default quotas of 100 rules and 1,000 targets per load balancer, and at most 5 condition values per rule
  • The hourly charge runs whether or not there’s traffic, which adds up across many small environments

Alternatives

What all load balancers have in common →

How it fits with other technologies

Send /api/* to a new target group with the AWS CLI · bash

aws elbv2 create-target-group --name orders-api \
  --protocol HTTP --port 8080 --vpc-id vpc-0a1b2c3d \
  --target-type ip --health-check-path /healthz

aws elbv2 register-targets --target-group-arn "$TG_ARN" \
  --targets Id=10.0.1.15 Id=10.0.2.27

aws elbv2 create-rule --listener-arn "$LISTENER_ARN" --priority 10 \
  --conditions Field=path-pattern,Values='/api/*' \
  --actions Type=forward,TargetGroupArn="$TG_ARN"

See it in a real stack

Web app on Kubernetes →
Live model
What you’re watchingRequests are spread across the pods. Each pod asks Redis first; hits come straight back, misses go on to PostgreSQL. Every 12 seconds one pod is taken down and the load balancer routes around it while Kubernetes replaces it.
Where it came from2009–2025

AWS launched Elastic Load Balancing in May 2009, together with CloudWatch and Auto Scaling, so EC2 customers could spread traffic over instances the way Amazon already did internally. That original balancer could speak HTTP, but it sent every request to the same pool of instances on a fixed port. As teams split apps into microservices and packed several containers onto each instance with Amazon ECS, one pool per load balancer meant one load balancer per service.

On 11 August 2016 AWS added a second type, the Application Load Balancer, and renamed the original the Classic Load Balancer. The ALB reads each HTTP request and picks a target group by its URL path, so /api and /mobile could go to different services that “can run and be scaled independently”, as Jeff Barr put it in the launch post. It also brought WebSockets and HTTP/2, and an hourly price 10% below Classic.

Over the next years the ALB grew into a small HTTP router: host-based routing in 2017, sign-in through OpenID Connect and redirects in 2018, Lambda functions as targets the same year, and gRPC in 2020. Classic Load Balancers still run, but the ALB became AWS’s main HTTP load balancer.

Why it’s built this way

Route by request content, not just by port
Microservices need different paths to reach different fleets. Matching rules on the path (and later host, header, method, query and source IP) lets one load balancer and one certificate front many services.
Target groups of ports, not lists of instances
ECS runs several containers per instance, each on its own port. Registering instance-and-port pairs, each with its own health check, let the scheduler add and remove containers without a load balancer per service.
Bill by capacity units, not just hours and bytes
Workloads stress a load balancer differently: a WebSocket app holds many idle connections, a download site moves bytes. An LCU charges for whichever dimension you use most.
Lambda functions as targets
Added in 2018 so an HTTP app could run serverless behind the same load balancer, and the same path rules, as its container services.

Timeline

  1. 2009

    Elastic Load Balancing launches with CloudWatch and Auto Scaling

  2. 2016

    Application Load Balancer launches on 11 August; the original becomes “Classic”

  3. 2017

    Host-based routing and IP targets; the Network Load Balancer covers layer 4

  4. 2018

    OIDC and Cognito sign-in, redirects, fixed responses and Lambda targets

  5. 2020

    gRPC and end-to-end HTTP/2 support

  6. 2023

    Mutual TLS authentication for clients

  7. 2025

    JWT validation, URL and host rewrites, and Target Optimizer concurrency limits

Sources16 · facts checked 5 October 2026

Improve this page on GitHub