A Comprehensive Guide to AWS Application Load Balancer

AWS Application Load Balancer (ALB) sits at the front of your application and spreads incoming traffic across your backend resources. If you’ve been running a single server and hitting capacity issues, or if you just want better reliability, ALB is worth knowing.

How ALB Improves Performance

Scaling resources dynamically

ALB integrates with Auto Scaling groups, so as traffic increases, new instances come online automatically. The balancer tracks which targets can handle requests and routes accordingly. No single instance gets hammered while others sit idle.

Health checks and CloudWatch

ALB runs health checks on your targets at intervals you define. If a target stops responding correctly, ALB marks it unhealthy and stops sending traffic there until it recovers.

CloudWatch metrics give you visibility into request counts, latency, and error rates. You can set up alarms to notify you when something looks wrong.

Target groups for routing

Target groups let you group targets by whatever criteria makes sense — by instance type, by region, by application. You then attach routing rules to determine which target group handles which requests.

Security with ALB

SSL/TLS offloading

You can terminate SSL/TLS at the load balancer instead of on each instance. This offloads the encryption overhead from your application servers and simplifies certificate management through AWS Certificate Manager.

Security groups and NACLs

Security groups control traffic at the instance level. Network ACLs work at the subnet level. Both work together with ALB to enforce network boundaries.

AWS WAF integration

ALB integrates with AWS WAF, which lets you filter out common attacks like SQL injection and cross-site scripting. WAF rules can allow, block, or count requests matching specific patterns.

ALB Pricing

AWS charges ALB based on hourly usage plus traffic volume (LCUs). If you have predictable traffic patterns, reserved instances can reduce costs significantly.

ConnectionIdle Timeout

You can configure how long connections stay open during low traffic. Setting this appropriately prevents resources from sitting idle unnecessarily.

Migrating from Classic ELB to ALB

If you’re still on the older Classic Load Balancer, ALB gives you better routing flexibility, better metrics, and lower costs for most use cases.

What to consider before migrating

ALB operates differently than Classic ELB. Some things work differently:

• ALB uses target groups and routing rules instead of a single backend
• Health check behavior is more configurable
• Some CLB features (like sticky sessions with the jsessionid cookie) work differently

Migration steps

1. Create target groups for your existing backend instances
2. Set up ALB with the same listeners your CLB uses
3. Test with a small percentage of traffic using weighted routing
4. Shift traffic over gradually, watching for errors
5. Update your DNS once you’re confident
6. Keep the CLB running until you’ve verified everything works

CloudFormation templates need updating if you use them. Replace CLB resources with ALB resources and target groups.

Advanced Routing

Path-based routing

This is where ALB gets interesting for microservices. You can route requests to different target groups based on URL path.

Say you have /catalog, /orders, and /payments as separate services. Instead of running a separate load balancer for each, ALB can route based on path:

/catalog/* → catalog-tg
/orders/* → orders-tg
/payments/* → payments-tg

Here’s how you’d set it up with the AWS CLI:

# Create target groups
aws elbv2 create-target-group \
    --name catalog-tg \
    --protocol HTTP \
    --port 80 \
    --vpc-id vpc-xxxxxxxx

aws elbv2 create-target-group \
    --name orders-tg \
    --protocol HTTP \
    --port 80 \
    --vpc-id vpc-xxxxxxxx

# Register targets
aws elbv2 register-targets \
    --target-group-arn arn:aws:elasticloadbalancing:region:123456789012:targetgroup/catalog-tg/xxx \
    --targets Id=i-xxxxxxx

aws elbv2 register-targets \
    --target-group-arn arn:aws:elasticloadbalancing:region:123456789012:targetgroup/orders-tg/xxx \
    --targets Id=i-xxxxxxx

# Create the ALB
aws elbv2 create-load-balancer \
    --name my-alb \
    --scheme internet-facing \
    --type application \
    --subnets subnet-xxxxxxx subnet-xxxxxxx

# Create listener rules
aws elbv2 create-rule \
    --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-alb/xxx/xxxxxxx \
    --priority 10 \
    --conditions Field=path-pattern,Values='/catalog/*' \
    --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/catalog-tg/xxx

aws elbv2 create-rule \
    --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-alb/xxx/xxxxxxx \
    --priority 20 \
    --conditions Field=path-pattern,Values='/orders/*' \
    --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/orders-tg/xxx

This approach means your microservices can each autoscale independently, and you only pay for one ALB instead of one per service.

Host-based routing

Host-based routing lets you route based on the domain name in the request. If you’re hosting multiple brands or domains behind a single ALB, this keeps things simple.

For example, brand1.example.com and brand2.example.com can route to different target groups, while sharing the same ALB and SSL certificate (with Subject Alternative Names or multiple certificates).

Query parameter routing

ALB can also route based on query strings. This is less common but useful when you need to send some requests to a canary deployment while others go to production.

What ALB Doesn’t Do

ALB handles traffic distribution, health checking, and routing. It doesn’t cache content (that’s CloudFront), and it doesn’t protect against all attack types — just the ones WAF can inspect. For DDoS protection at the network layer, you want AWS Shield.

More Context

If you want to dig deeper into load balancing options, here’s how they stack up:

NLB handles things like game servers or financial trading systems where you need raw TCP performance without HTTP semantics.