AWS API Gateway vs ALB: Choosing the Right Entry Point

What and Why

API Gateway and Application Load Balancer (ALB) both terminate HTTPS and route traffic, but they live at different layers of the stack. API Gateway is a fully managed API front door with built-in throttling, request validation, schema transformation, and tight Lambda integration. ALB is a layer-7 load balancer with path and host routing, target groups, and deep integration with ECS, EKS, and EC2.

The right answer depends on whether you are exposing an API product to external consumers or balancing internal HTTP traffic across containers. Many teams pick wrong because they treat the two as interchangeable, and end up paying for features they do not need or rebuilding features they could have gotten for free.

Mental Model

Picture two halves of the same job. API Gateway is the policy layer: who can call this endpoint, how often, with what payload, and what shape should the response be. ALB is the traffic layer: take a connection, route it to a healthy target, and return the response as quickly as possible.

API Gateway charges per request and per data out, with a higher per-request price but no idle cost. ALB charges per hour plus LCUs (Load Balancer Capacity Units), so it has an idle floor but scales cheaply at high throughput. The crossover point is roughly a few hundred requests per second of steady traffic.

Hands-on Example

Consider a SaaS product with a public API for partners, an internal admin dashboard, and a microservices backend. A common pattern uses both services.

 Partners                Browsers              Internal apps
     |                       |                       |
     v                       v                       v
+------------+        +-------------+        +-------------+
|  API GW    |        |  CloudFront |        |  Internal   |
| (REST API) |        |  + Cognito  |        |    ALB      |
+-----+------+        +------+------+        +------+------+
      |                      |                      |
      |                      v                      |
      |               +-------------+               |
      +-------------> |  Public ALB | <-------------+
                      +------+------+
                             |
                     +-------v--------+
                     |  ECS / EKS     |
                     |  microservices |
                     +----------------+

Partners hit API Gateway because they need API keys, per-key rate limits, and a usage plan. Browsers hit CloudFront for caching and TLS, then an ALB for routing. Internal apps skip the public path entirely and use a private ALB.

A path-based ALB rule routes /api/orders/* to the orders target group and /api/users/* to the users target group. API Gateway can do the same but billing it for every internal call would be wasteful.

Common Pitfalls

A frequent pitfall is using API Gateway as a generic reverse proxy in front of ECS services. You pay the per-request fee on every internal hop and inherit a 29-second integration timeout that breaks long-running requests. ALB is the better fit for that role.

The opposite mistake is exposing Lambda functions through an ALB to save money, then discovering you need throttling, API keys, request validation, or WAF integration tuned per route. Rebuilding those in application code is more expensive than the API Gateway bill would have been.

Cold start surprises also bite. API Gateway adds a small but real overhead, usually 10 to 30 ms, on top of Lambda init. If your SLO is single-digit milliseconds at p99, an ALB plus container is more predictable.

Finally, watch out for the WebSocket gap. API Gateway has native WebSocket support; ALB supports WebSockets too but you must size target groups for long-lived connections.

Production Tips

Front API Gateway with WAF and enable AWS Shield Advanced for high-value public APIs. The WAF rules can also live on the ALB; pick one place to own them.

Use private API Gateway endpoints for VPC-only APIs when you want the gateway features without exposing the URL publicly. For ALB, prefer internal schemes and PrivateLink endpoints to reduce blast radius.

Cache aggressively at the edge. CloudFront in front of either service often pays for itself by absorbing GET traffic and shielding origins from spikes.

Tag the listener rules and stages. When the bill jumps, knowing which team owns each route is the difference between a quick fix and a long meeting.

Instrument both layers. API Gateway emits per-method latency and 4xx/5xx counts. ALB emits target response time and connection metrics. Pipe both to CloudWatch and alarm on real user impact, not raw counts.

Wrap-up

API Gateway is the right entry point when you sell or manage an API product, need fine-grained authorization, or want first-class Lambda integration without operating a load balancer. ALB is the right entry point when you route high-volume HTTP traffic to containers or instances and want predictable cost at scale.

In practice many architectures use both: API Gateway for the policy edge and ALB for internal routing. Start by listing the features you actually need, map them to the cheaper service that provides them, and revisit the choice as traffic patterns evolve.