API gateway, proxy or load balancer?
Three things you put in front of services — and they are often layered, not either/or.
A load balancer spreads traffic across healthy targets for availability and scale. A reverse proxy is a general-purpose intermediary you fully control — routing, TLS, caching, rewriting. An API gateway is a managed product for publishing and governing APIs — auth, API keys, throttling, transformation, OpenAPI. They are commonly layered (gateway in front of a load balancer in front of services), not a single choice. The deciding factor is how much API-product governance you need.
Answer the questions — the helper scores both the options against the sourced table below and shows its reasoning. A heuristic, not an oracle: the verdict above stays the authority.
| Criterion | API gateway | Reverse proxy | Load balancer |
|---|---|---|---|
| Primary purpose | Publish and govern APIs | A general-purpose request intermediary | Spread traffic across healthy targets |
| OSI layer | L7 — HTTP / REST / WebSocket | L7 | L7 (ALB) or L4 (NLB) |
| Auth & API keys | Built in — IAM, Cognito, Lambda authorizers, API keys | Manual configuration | ALB: OIDC/Cognito. NLB: none |
| Rate limiting | Built in — throttling, usage plans, quotas | Manual (e.g. limit_req) | Not provided |
| Transformation | Yes — mapping templates and parameter mapping | Manual header / URI rewriting | None |
| API-product management | OpenAPI import/export, SDK generation, stages | None | None |
| Who operates it | Fully managed by AWS | You operate the server / process | Fully managed by AWS |
| Typical placement | Edge entry point for APIs | Any hop you control | In front of a fleet, often behind a gateway |
Reach for an API gateway when
- You publish APIs and need API keys, usage plans and quotas.
- You need managed auth and request transformation without running code.
- You manage APIs as products via OpenAPI, stages and SDKs.
Reach for a reverse proxy when
- You need full control of routing, rewriting, caching or static content.
- You want a portable, vendor-neutral intermediary — on-prem, multi-cloud, or a sidecar.
- Your needs sit between a plain load balancer and a gateway, and you will operate it.
Reach for a load balancer when
- The goal is spreading traffic across healthy targets for availability.
- You need L4 throughput and static IPs (NLB) or L7 path routing (ALB).
- You want a managed, health-checked entry point without API-product features.
- Amazon API Gateway — welcome / overview — https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html
- API Gateway request throttling — https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
- API Gateway data transformations — https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-data-transformations.html
- Application Load Balancer — introduction — https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html
- Network Load Balancer — introduction — https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html
- ALB — authenticate users — https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html
- nginx — beginner's guide (reverse proxy) — https://nginx.org/en/docs/beginners_guide.html