API Gateway

The plain-language idea

API Gateway sits between a client and a backend, doing the job a hand-rolled router-plus-reverse-proxy would otherwise do: it takes an incoming HTTP request, decides which backend it maps to, and forwards it — while handling the cross-cutting concerns that shouldn't have to live inside every individual backend function.

Two product lines exist within API Gateway, and the choice between them is a real tradeoff, not "old vs. new done right":

• REST API — the original, full-featured option: request/response transformation (reshaping a request or a backend's response with mapping templates), request validation, API keys tied to usage plans, and several authorization models.
• HTTP API — a newer, deliberately leaner option: lower latency, lower cost, and native support for OIDC/JWT authorizers, in exchange for giving up some of REST API's transformation and usage-plan features.

Whichever type is used, the core jobs are the same: routing (map a path and method to a specific backend integration), throttling (rate-limit requests before they ever reach the backend), authorization (decide whether this caller is allowed to hit this route at all), and usage plans (tie an API key to a specific quota/rate tier — a free tier versus a paid tier, for example).

See it in a real thing: a request that gets throttled before Lambda ever runs

A client sends POST /orders to API Gateway — not directly to Lambda.

BackNext

A client sends POST /orders. API Gateway checks the caller's API key against its usage plan's rate limit. Under the limit: the request passes through a Lambda proxy integration, which invokes the order-creation Lambda function with the full raw request, and API Gateway reshapes whatever the function returns into the HTTP response sent back to the client. Over the limit: API Gateway returns a 429 immediately — the Lambda function is never invoked at all.

What people usually miss

Watch out

• An API key is a usage-plan identifier, not authentication. It tells API Gateway which quota and rate limit to apply to a caller — it's not equivalent to an IAM credential or a JWT, and a leaked API key doesn't grant access to AWS resources the way a leaked IAM credential would. It does let someone else consume against your quota and your bill.
• HTTP API isn't "REST API but modernized" — it's a genuine feature tradeoff. It intentionally leaves out request/response transformation and usage plans/API keys in exchange for lower latency and lower cost; picking one over the other is a real decision based on what a given API actually needs, not a default upgrade path.
• A Lambda proxy integration expects a specific response shape back — status code, headers, body — and getting that shape wrong produces a generic API Gateway error, not an obviously broken Lambda log. This is a common early debugging trap: the function itself might be running fine and returning a value, just not in the structure API Gateway requires to turn it into a proper HTTP response.
• Throttling protects the backend, not just the account's bill. A burst that isn't throttled at the gateway can exhaust a downstream Lambda function's concurrency limit for everyone hitting it, turning one caller's spike into an outage for every other caller.

Why this matters in interviews

"What's actually different about putting API Gateway in front of a Lambda function versus giving a client a way to call it directly?" tests whether a candidate can name concrete value beyond "it makes Lambda reachable over HTTP" — throttling that protects concurrency, authorization before the function ever runs, and usage plans that meter callers, all of which a bare, unprotected endpoint doesn't get for free.