Application Load Balancer

What ALB is

An Application Load Balancer sits in front of a group of backend targets — usually EC2 instances in an Auto Scaling group — and distributes incoming HTTP(S) requests across whichever targets are currently passing their health check. It operates at layer 7, so it can route on the actual content of a request: URL path, hostname, headers, not just raw TCP connections. It’s the standard way to make a fleet of otherwise-private app servers reachable from the internet without giving any single instance a public IP.

Design Beaver models an ALB as a node that lives inside a VPC — it can’t sit on bare canvas — and validates as you draw where it can route, what each connection needs, and where a single-AZ or plaintext setup will bite you.

When to use ALB (and when not to)

Reach for an ALB when EC2 instances or containers need to be reachable from the internet but shouldn’t carry public IPs themselves, when you need content-based routing on path, host, or header across multiple backend services from one entry point, or when you’re fronting an Auto Scaling group and want targets registered and deregistered automatically as it scales. Terminating TLS at the edge of a private, HTTP-only backend is a natural fit too.

Don’t reach for it for non-HTTP(S) traffic — raw TCP/UDP or extreme low-latency requirements are a Network Load Balancer’s job, not ALB’s. It’s also the wrong tool for a single throwaway or dev instance with no resilience requirement, where the setup and cost buy you nothing, or for a purely static site with no backend logic, where CloudFront in front of S3 directly is simpler and cheaper.

Variants: listener protocol and target type

An ALB’s real choice points aren’t instance sizes — they’re the listener protocol and the target type. HTTPS with an ACM certificate is the recommended listener for public production traffic, and the target type decides what the ALB actually routes to.

ALB pricing

You pay an hourly rate per load balancer plus Load Balancer Capacity Units — and the LCU model is the part that surprises people, because you’re billed only on whichever usage dimension peaked that hour, not the sum of all four.

How ALB connects to other services

An ALB is never a lone box — it’s the hinge between a public entry point and a private compute tier. Each edge has a direction and a requirement that makes it actually work, and Design Beaver models them so it knows what belongs on each connection.

• →EC2

  ALB forwards incoming requests to EC2 instances registered in a target group, using the protocol/port and routing algorithm (round robin or least-outstanding-requests) configured on that target group

• →ECS

  ALB forwards requests to an ECS service's tasks registered in a target group — the standard way to put a containerized web/API tier behind a load balancer, with the ECS service keeping the target group's registrations in sync as tasks start and stop

• ←Route 53

  Route 53 alias record (A/AAAA, ALIAS type) resolves a domain name to the ALB, so users hit a memorable custom domain instead of the ALB's own *.elb.amazonaws.com DNS name

• ←CloudFront

  CloudFront uses the ALB as a custom HTTP(S) origin, adding edge caching, HTTPS, and a CDN layer in front of a dynamic app server tier

What ALB can’t connect to

Some edges look reasonable on a canvas but don’t exist in AWS. Design Beaver flags them instead of letting you draw a diagram that can’t be built.

• ✕RDS

  ALB is a layer-7 HTTP(S) load balancer that routes requests to registered targets over HTTP(S) — it has no concept of a database wire protocol and never has an RDS instance as a backend target. The EC2 tier the ALB fronts is what connects to RDS, not the ALB itself.

• ✕App Runner

  AWS App Runner has its own built-in, fully managed load balancer and public HTTPS endpoint, and isn't a registrable ALB target — ALB targets are EC2 instances, IPs, or Lambda functions, not a managed App Runner service. Use ECS/Fargate behind the ALB for a container workload that needs your own load balancer.

Anti-patterns Design Beaver catches

These are the ALB mistakes that pass a diagram review but leave you exposed — the ones the validation engine flags as you draw.

Gotchas that bite in production

• Two AZs isn’t a suggestion, it’s a requirement. You must select at least two subnets in two different Availability Zones just to create an ALB. Single-AZ isn’t only a bad idea here — AWS enforces it (Outposts and Local Zones have narrower single-subnet exceptions, but that’s not the typical case).
• Each subnet needs free IPs to scale into. Every AZ subnet the ALB uses needs a CIDR of at least a /27 with 8 free IP addresses. The load balancer reserves these to scale out, and running low can push the ALB into a degraded state during scaling.
• Cross-zone load balancing is on by default. For an ALB it can’t be turned off at the load balancer level, only per target group. Traffic spreads evenly across targets in every enabled AZ, not just the zone a request landed in.
• Point Route 53 at an ALB with ALIAS, not a CNAME. An ALB is a supported ALIAS target (like CloudFront and S3 website endpoints); a plain EC2 instance isn’t. Use an ALIAS record so it works at the zone apex and Route 53 doesn’t bill the query.
• One ALB in front of one manual instance solves nothing. The resilience comes from the ALB, target group, and Auto Scaling group together — a single manually-registered target still leaves exactly one thing to fail over to.

Further reading

• Official AWS documentation
• Why we built a validation engine