ALB vs API Gateway is one of the most misunderstood decisions in AWS architecture interviews. Most engineers default to API Gateway without considering cost implications or their actual API management needs. That incomplete answer will hurt your credibility.
This guide cuts through the confusion. By the end, you’ll know exactly which service solves your API hosting problem, why, and how to explain the decision confidently in any interview.
Quick Answer: ALB vs API Gateway at a Glance
| Factor | ALB | API Gateway |
|---|---|---|
| Pricing model | Hourly + per LCU | Per 1 million requests |
| Built-in authentication | None (use middleware) | Cognito, Lambda authorizers, IAM |
| Throttling / Rate limits | No native support | Built-in with usage plans |
| WebSocket support | Yes, native | Yes, separate API type |
| Private API endpoints | N/A (operates in VPC) | Yes, with execution role restrictions |
| Best for | Internal microservices, high throughput | External APIs, API governance |
What is an Application Load Balancer?
The Application Load Balancer (ALB) operates at Layer 7 and routes HTTP and HTTPS traffic based on request content. You define rules for hostnames, URL paths, HTTP headers, and query parameters, then ALB forwards matching requests to target groups without needing custom code.
ALBs integrate directly with container orchestration platforms (ECS, EKS) and EC2 Auto Scaling Groups. Targets can be EC2 instances, ECS tasks, Lambda functions, or IP addresses. Pricing is hourly plus per-LCU (Load Balancer Capacity Unit), making it cost-effective for steady-state traffic.
What is API Gateway?
Amazon API Gateway is a fully managed service for building and publishing REST, HTTP, and WebSocket APIs. You define an API using AWS-native tooling, configure request/response models, set up authentication and authorization, and API Gateway enforces those contracts at the edge before requests reach your backend.
API Gateway charges per million requests. It provides built-in authentication through Cognito or Lambda authorizers, request throttling, usage plans for API tiers, and AWS WAF integration for protection. The service is designed to expose APIs to external customers and enforce strict governance.
ALB vs API Gateway: 5 Differences That Actually Matter in Interviews
1. Pricing at Scale
For most organizations, pricing is the deciding factor. ALBs charge around $16/month plus $2.43 per million LCUs. A typical application serving 1 billion requests monthly consumes roughly 150 LCUs, costing approximately $366/month in LCU charges plus the base fee.
API Gateway charges $3.50 per million requests. At 1 billion requests, that’s $3,500/month. For high-throughput APIs, the cost difference becomes staggering. I’ve seen teams save 70% on ingress costs by migrating from API Gateway to ALB once traffic exceeded a certain threshold.
Interview tip: Mention the break-even point without being asked. It shows you understand production cost dynamics. The inflection typically occurs around 10-15 million requests monthly, but always calculate based on your actual traffic patterns.
2. Authentication and Authorization
API Gateway excels at enforcing authentication without custom code. Cognito integration provides user pool management. Lambda authorizers allow arbitrary authorization logic. IAM roles integrate seamlessly for AWS service-to-service APIs. You configure authentication at the API layer, ensuring every request is validated.
ALBs have no native authentication. If you need to protect endpoints, you implement authentication through middleware in your application, Lambda function logic, or a sidecar container. For internal APIs where you control the client, this trade-off is acceptable. For external APIs, the burden shifts to your backend.
This doesn’t make ALB inadequate. It means authentication responsibility moves from the edge to your application layer. For teams with mature middleware practices or stateless authentication tokens (JWT), ALB is perfectly viable. For teams needing centralized API governance, API Gateway handles this responsibility elegantly.
3. Request Throttling and Usage Plans
API Gateway provides request throttling at the API level with configurable rate limits per API key or stage. Usage plans allow you to tier your API: free tier with 100 requests/second, professional tier with 1,000 requests/second. Customers can request specific tiers and you monitor overage charges.
ALBs have no built-in throttling. If you need request limits, implement them in your application using libraries like Token Bucket or Rate Limit middlewares. This adds complexity but gives you fine-grained control. For internal microservices where traffic is managed through deployment practices rather than API limits, ALB suffices.
If you’re monetizing APIs or need strict fair-use enforcement, API Gateway’s usage plans save months of development time building custom throttling. If you’re routing internal traffic, that operational overhead doesn’t justify API Gateway’s cost.
4. WebSocket and Advanced Protocol Support
Both ALB and API Gateway support WebSockets natively. ALB handles WebSocket connections through native support at Layer 7. API Gateway offers a separate WebSocket API type with full bidirectional communication and message routing through Lambda or HTTP endpoints.
For real-time applications like chat, notifications, or live dashboards, both work. API Gateway’s WebSocket APIs provide slightly better developer experience with built-in routing and connection management. ALB’s WebSocket support is more straightforward because ALBs are fundamentally simpler.
The choice here rarely drives the ALB vs API Gateway decision. Use WebSocket support as a tiebreaker if you’ve already decided based on other factors. ALB is sufficient for most real-time use cases behind a microservices architecture.
5. Private Endpoints and Security Boundaries
ALBs operate within VPCs by default, automatically providing network isolation. Clients access ALBs through private IP addresses or ENIs. This makes ALBs naturally suitable for internal APIs with no internet exposure.
API Gateway can be configured as private APIs accessible only from specific VPCs using VPC endpoints. This adds cost and complexity but provides security similar to ALB. Public API Gateway endpoints are exposed to the internet immediately, making them suitable only for genuinely public APIs.
For internal service-to-service communication, ALB’s default security posture is simpler. For external customer-facing APIs, both can be secured appropriately, but API Gateway’s default public nature forces intentional security configuration while ALB’s default private nature requires intentional exposure.
When to Choose ALB vs API Gateway
Choose ALB when:
- APIs serve high request volumes (over 10-15 million requests monthly)
- Workloads run in containers (ECS, EKS) or EC2 Auto Scaling Groups
- You control client behavior through deployment practices rather than API limits
- Cost efficiency matters more than operational simplicity
- You already have application-level authentication middleware
Choose API Gateway when:
- APIs serve low to moderate request volumes (under 10 million requests monthly)
- You need built-in authentication without custom development
- Usage plans and API monetization are requirements
- Request throttling and quota enforcement must be API-level concerns
- External customers need API contracts, not internal service-to-service communication
Example Interview Answer
Here’s how to answer “Which is the best service to host APIs: ALB or API Gateway?”
Watch a real Senior AWS DevOps Engineer address this exact architectural decision:
“ALB and API Gateway solve similar problems at different scales. ALB operates at Layer 7, routes based on HTTP content, and costs hourly plus per-capacity. API Gateway charges per request and includes built-in authentication, throttling, and usage plans.
I choose ALB for internal microservices architectures where I control client behavior. The cost economics are better at scale, and integration with ECS and EKS is seamless. I choose API Gateway for external APIs where I need authentication, rate limiting, and API governance without building custom solutions.
In my previous role, we used API Gateway for our customer-facing REST API, handling authentication with Cognito and throttling per API key. Behind API Gateway, we routed to ALBs managing internal service-to-service communication. This separation gave us security at the boundary and cost efficiency internally.”
Common Mistakes to Avoid
Defaulting to API Gateway because it’s more powerful. Power and simplicity serve different problems. ALB’s simplicity is an asset when you don’t need API Gateway’s features, and its cost advantage is real.
Overlooking API Gateway cost until traffic scales. Start with API Gateway if you need built-in features. Monitor costs monthly. When the inflection point hits (usually 10-15 million requests monthly), revisit the choice. Migration is possible but requires effort.
Assuming ALB can’t handle APIs. ALB is absolutely sufficient for APIs. You’re just shifting responsibility for authentication and throttling from the edge to your application.
Ignoring your team’s existing middleware patterns. If your team already has authentication and rate-limiting middleware, ALB works perfectly. If you’re starting from scratch, API Gateway’s built-in features save development time.
Key Takeaway
The ALB vs API Gateway decision comes down to cost versus built-in governance. ALB wins on pricing for high-throughput workloads and simplicity for internal communication. API Gateway wins on built-in authentication, throttling, and API governance for external APIs. Choose based on request volume, authentication requirements, and whether you control client behavior through deployment practices or API contracts.
