AWS API Gateway vs ALB: Which One Should Front Your API?

API Gateway and ALB both receive HTTP requests and route them to backends. That surface-level similarity leads teams to treat them as interchangeable — and then discover, usually through a surprise bill or a missing feature, that they’re very different services with different cost models, feature sets, and appropriate use cases.

Here’s what actually determines the right choice.

What each service does

API Gateway is a managed API management layer. It handles authentication, authorization, request transformation, rate limiting, caching, and request/response mapping — all without your application code touching them. It comes in two flavors:

• HTTP API — Lightweight. Lower cost. JWT/Cognito auth, Lambda and HTTP backends. Missing some REST API features.
• REST API — Full-featured. Request transformation, response mapping, API keys, usage plans, caching. Higher cost.
• WebSocket API — For persistent bidirectional connections.

ALB (Application Load Balancer) is a Layer 7 load balancer. It routes HTTP/HTTPS traffic to targets (EC2, ECS, Lambda, IP addresses) based on path, host, header, and query string rules. It’s primarily a routing and load balancing layer, not an API management layer.

Cost comparison

This is usually where the decision becomes concrete.

API Gateway HTTP API: $1.00 per million requests (first 300 million/month), then $0.90. No fixed cost.

API Gateway REST API: $3.50 per million requests (first 333 million), then tiered pricing. Plus caching costs ($0.02–$0.38/hour depending on cache size) if enabled.

ALB: $0.008 per LCU-hour (Load Balancer Capacity Units). At typical API traffic patterns, 1 million requests/month on an ALB costs roughly $0.04–$0.25 depending on payload size and connection patterns, plus the ALB fixed cost of ~$16/month.

The crossover point: At low request volumes (under ~10 million requests/month), API Gateway HTTP API is often cheaper because there’s no fixed cost. At higher volumes, ALB’s per-request cost is substantially lower, and the $16/month fixed cost is negligible.

At 100 million requests/month, ALB is already 4x cheaper than API Gateway HTTP API and 16x cheaper than REST API.

Feature comparison

When to use API Gateway

Lambda-backed APIs with auth requirements. API Gateway’s native integration with Lambda (including proxy integration) and built-in JWT/Cognito authentication makes it the natural choice for serverless APIs that need authentication without an auth layer in application code.

Public APIs with third-party developer access. REST API’s API keys, usage plans, and developer portal features are designed for this. You can issue API keys, set per-key rate limits, track usage by key, and throttle abusers — none of which ALB provides natively.

Request/response transformation. If your backend returns a shape that your API consumers shouldn’t see directly (legacy response format, additional fields to strip, request header injection), REST API’s mapping templates handle this without additional Lambda.

Low-to-moderate traffic serverless APIs. Under ~10 million requests/month with Lambda backends, HTTP API is often the right default: no fixed cost, native Lambda integration, low latency relative to REST API (which adds ~10ms overhead from the mapping layer).

When to use ALB

Container-backed services (ECS, EKS). ALB is the standard frontend for ECS services and Kubernetes Ingress on EKS. It integrates directly with ECS service discovery and EKS target groups. Routing traffic from API Gateway to ECS adds a network hop and latency without meaningful benefit.

High-throughput APIs. When you’re processing hundreds of millions of requests per month, ALB’s cost advantage is substantial. The application handles auth, rate limiting, and other cross-cutting concerns in middleware.

Multiple backend types under one domain. ALB’s path-based and host-based routing lets you route /api/v1/users to one ECS service, /api/v1/orders to another, and /api/v2/* to a third — all under one ALB and one domain. API Gateway’s routing model is less flexible for this pattern.

gRPC services. ALB supports HTTP/2 and gRPC natively. API Gateway does not.

WebSocket with high concurrency. ALB WebSocket support is more straightforward for high-concurrency cases than API Gateway WebSocket API, which has connection limits and session management complexity.

When to use both

A common pattern: ALB in front of services, API Gateway for public-facing developer API.

Public developers → API Gateway REST API → VPC Link → internal ALB → ECS/EKS services

API Gateway handles: API keys, usage plans, developer documentation, throttling by key. ALB handles: internal routing to individual services, health checks, container orchestration integration. The VPC link keeps internal traffic private.

This pattern is appropriate when you have:

• An internal microservices architecture (ALB routing)
• External developers who need API keys and rate limiting (REST API)
• You don’t want the external API to talk directly to your service mesh

Private APIs

Both services support private API access within a VPC.

API Gateway private endpoints: Uses VPC endpoints (interface endpoints via PrivateLink). Adds ~$7/month per AZ for the endpoint plus data processing charges. Traffic stays within AWS backbone.

ALB with internal scheme: An internal ALB has no internet-facing endpoint — it’s only accessible within the VPC or via VPN/Direct Connect. No PrivateLink cost. Simpler and cheaper for purely internal service-to-service traffic.

For internal service mesh traffic, an internal ALB is almost always simpler and cheaper than an API Gateway private endpoint.

WebSocket APIs

API Gateway WebSocket API is purpose-built for WebSocket connections. It manages connection state, routes messages by action, and integrates with Lambda for connection/disconnection/message handling. The model is opinionated: you define route expressions, and API Gateway calls the appropriate Lambda for each.

ALB WebSocket support passes WebSocket connections through to the backend. The backend manages connection state, message routing, and session handling. More control, more implementation responsibility.

For simple use cases with Lambda backends, API Gateway WebSocket is faster to implement. For high-concurrency WebSocket applications or cases where the backend already manages state (Redis, DynamoDB Streams), ALB passthrough is more flexible.

Authentication

API Gateway handles JWT validation natively (HTTP API) or via Lambda authorizers (either type). The JWT authorizer validates tokens, extracts claims, and passes them to the backend — your Lambda doesn’t need to validate the token.

ALB can authenticate via Cognito or OIDC using the authenticate-cognito and authenticate-oidc actions on listener rules. This offloads auth from the application entirely — ALB validates the token, adds X-Amzn-Oidc-* headers with user claims, and forwards the authenticated request to the backend.

Both approaches are legitimate. ALB’s auth integration is less commonly known but handles Cognito and OIDC without application code changes and without Lambda authorizer overhead.

The decision in practice

Start with API Gateway HTTP API if:

• Your backend is Lambda
• Traffic is under 10-20 million requests/month
• You need JWT/Cognito auth without writing auth code
• You want zero fixed costs

Start with ALB if:

• Your backend is ECS, EKS, or EC2
• Traffic is high or expected to grow significantly
• You need host-based routing across multiple services
• You need gRPC

Use REST API if:

• You’re building a public API with third-party developer access
• You need request/response transformation
• You need per-consumer usage plans and rate limits

Getting this right

The API entry layer is one of those infrastructure decisions that’s hard to migrate later — changing the frontend service usually requires DNS changes, auth reconfiguration, and application changes simultaneously. If you’re designing a new API layer or evaluating whether your current setup fits your growth trajectory, I’m available to help.

Nick Allevato is an AWS Certified Solutions Architect Professional with 20 years of infrastructure experience. He runs Cold Smoke Consulting, an independent AWS consulting practice.