
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
What AWS Application Load Balancer uses
- AWS Application Load Balancerspreads requests across instances onAmazon EC2
- AWS Application Load Balancerroutes requests to tasks onAWS Fargate
- AWS Application Load Balancercan be the ingress forKubernetes
- AWS Application Load Balancercan invoke functions inAWS Lambda
- AWS Application Load Balancerruns inside subnets ofAmazon VPC
What uses AWS Application Load Balancer
- AWS Elastic Beanstalkputs web environments behindAWS Application Load Balancer
- Amazon EKSexposes Ingress traffic throughAWS Application Load Balancer
- Amazon CloudFrontforwards dynamic requests toAWS Application Load Balancer
- Amazon API Gatewaycan reach private services behindAWS Application Load Balancer
- Amazon Route 53can alias a domain toAWS Application Load Balancer
- gRPCcan be routed per call byAWS Application Load Balancer
- Amazon CloudWatchcollects request and target metrics fromAWS Application Load Balancer
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 →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
- 2009
Elastic Load Balancing launches with CloudWatch and Auto Scaling
- 2016
Application Load Balancer launches on 11 August; the original becomes “Classic”
- 2017
Host-based routing and IP targets; the Network Load Balancer covers layer 4
- 2018
OIDC and Cognito sign-in, redirects, fixed responses and Lambda targets
- 2020
gRPC and end-to-end HTTP/2 support
- 2023
Mutual TLS authentication for clients
- 2025
JWT validation, URL and host rewrites, and Target Optimizer concurrency limits
- AWS News Blog: New – AWS Application Load Balancer (2016)
- AWS What’s New: Monitoring, Auto Scaling and Elastic Load Balancing for Amazon EC2 (2009)
- Werner Vogels: Automating the management of Amazon EC2 (2009)
- Document history for Application Load Balancers
- AWS What’s New: Application Load Balancer launches Target Optimizer (2025)
- AWS News Blog: New Network Load Balancer (Sep 2017)
- Amazon ECS docs: Load balancer types, on Classic Load Balancers’ fixed port mapping (2018 copy) · archived copy, original
- ELB docs: What is Elastic Load Balancing? (Classic as the previous generation)
Sources16 · facts checked 5 October 2026
- ALB docs: What is an Application Load Balancer?
- ALB docs: Application Load Balancers (nodes per zone, HTTP/2, DNS name)
- ALB docs: Listeners (HTTP/2 and WebSockets)
- ALB docs: Condition types for listener rules
- ALB docs: Action types for listener rules
- ALB docs: Target groups (target types, gRPC)
- ALB docs: Lambda functions as targets
- ALB docs: Authenticate users using an Application Load Balancer
- ALB docs: Access logs
- ALB docs: Quotas
- Elastic Load Balancing pricing
- Amazon ECS docs: Use an Application Load Balancer for Amazon ECS
- Amazon EKS docs: Route HTTP traffic with Application Load Balancers
- AWS WAF docs: Resources you can protect
- NLB docs: Use an Application Load Balancer as a target of a Network Load Balancer
- Global Accelerator docs: How it works