Amazon API Gateway
A fully managed front door for your APIs — routing, throttling, authentication, and request/response transformation, without running your own API layer.
Want a visual for this topic?
Generate a diagram tailored to Amazon API Gateway — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain what API Gateway handles so your backend doesn't have to
- •Distinguish REST APIs from HTTP APIs in API Gateway and when to use each
- •Explain how API Gateway integrates with Lambda for a fully serverless API
- •Configure throttling and an API key/usage plan for rate limiting
What is it?
Amazon API Gateway is a fully managed service for creating, publishing, and securing APIs at any scale — it sits in front of your backend (Lambda functions, EC2/ECS services, or any HTTP endpoint) and handles routing, authentication, request/response transformation, throttling, and monitoring, so your backend code doesn't need to implement any of that itself.
Why it exists
Every API needs a set of common concerns handled — routing requests to the right backend logic, validating and transforming payloads, authenticating callers, protecting against abuse via rate limiting, and logging/monitoring traffic. Building and maintaining all of this yourself in every backend service is repetitive and error-prone. API Gateway exists to handle this entire 'API front door' layer as a managed service, letting your backend focus purely on business logic.
Problem it solves
It solves the cross-cutting-concerns problem (auth, throttling, logging implemented once at the gateway instead of duplicated in every backend service), the serverless-API problem (Lambda functions have no built-in HTTP listener; API Gateway is what turns a Lambda function into an actual callable HTTP API), and the API-versioning/staging problem (built-in support for multiple deployment stages like dev/staging/prod without duplicating infrastructure).
Intuition
Think of API Gateway as a hotel's front desk: guests (API callers) don't wander directly into the kitchen or laundry room (your backend services) — they go through the front desk, which checks their reservation (authentication), directs them to the right room (routing), makes sure no single guest monopolizes services (throttling), and keeps a log of who came and went (monitoring) — all without the kitchen staff needing to handle any of that themselves.
Analogy
A restaurant's host stand: the host doesn't cook, but manages the flow of every customer — checking reservations, seating them at the right table, managing the pace so the kitchen isn't overwhelmed, all so the kitchen (your actual backend logic) can focus purely on cooking.
Technical explanation
API Gateway offers two main API types: REST APIs (the original, feature-rich option with request/response transformation via mapping templates, API keys and usage plans, and AWS WAF integration) and HTTP APIs (a newer, simpler, lower-latency and lower-cost option covering the majority of common use cases — JWT authorizers, simpler routing — but without REST APIs' full transformation and usage-plan feature set). Integration types determine how a route connects to its backend: Lambda Proxy integration (the most common, passes the full request to Lambda and expects a specific response format back, minimal configuration), HTTP integration (proxies to any HTTP backend, including an ALB for containerized/EC2 backends), and Mock integration (returns a static response with no backend at all, useful for testing).
Architecture
A fully serverless API architecture places API Gateway in front of many individual Lambda functions, one per route/resource (e.g. GET /orders → orders-list Lambda, POST /orders → create-order Lambda), with a Lambda or JWT authorizer validating a Cognito or third-party-issued token before any request reaches backend logic, and usage plans with API keys issued to different partner integrations for differentiated rate limits.
Workflow
- Define your API's routes (resources and methods). 2) Choose REST API for full feature needs (usage plans, request/response transformation) or HTTP API for simpler, cheaper, lower-latency needs. 3) Configure the backend integration per route — typically Lambda Proxy for serverless backends. 4) Add an authorizer (Cognito User Pools, a custom Lambda authorizer, or JWT for third-party identity providers) to protect routes needing authentication. 5) Configure throttling limits and, if needed, usage plans with API keys for partner-specific rate limits. 6) Deploy to a stage (dev/staging/prod) and optionally attach a custom domain.
Example
A mobile app's backend uses an HTTP API (chosen for lower cost and latency over REST API, since the team doesn't need REST API's more advanced features) with routes like GET /profile and POST /orders each proxying to a dedicated Lambda function, protected by a JWT authorizer validating tokens issued by Amazon Cognito after user sign-in — the mobile app never talks to Lambda directly, only ever to API Gateway's stable public endpoint.
Real-world usage
API Gateway is the standard entry point for serverless architectures across AWS customers, extensively documented in AWS's own serverless reference architectures pairing it with Lambda and DynamoDB; API Gateway's usage plans and API keys are commonly used by companies offering a public or partner API product to differentiate rate limits and track usage per customer/integration.
Trade-offs
REST APIs offer more features (usage plans, request validation, richer transformation) at higher cost and latency; HTTP APIs are simpler, cheaper, and faster but cover a narrower feature set — the practical guidance is to default to HTTP APIs unless you specifically need a REST-API-only feature. Lambda Proxy integration is the simplest to set up and most common choice, but gives up some of REST API's fine-grained request/response transformation control that a non-proxy integration would allow, in exchange for far less configuration overhead.
Visual explanation
Picture a client sending a request to API Gateway's endpoint (e.g. api.example.com/orders). API Gateway matches the path and method against configured routes, applies any configured authorizer (checking a JWT or calling a Lambda authorizer function), applies throttling limits, optionally transforms the request, and forwards it to the configured backend integration (a specific Lambda function, an HTTP endpoint, or another AWS service) — then does the reverse transformation on the response before returning it to the client.
Advantages
- —
Handles cross-cutting API concerns (auth, throttling, logging, transformation) once, centrally, instead of duplicated per backend service
- —
Turns Lambda functions into real callable HTTP APIs, essential for serverless architectures
- —
Built-in support for multiple deployment stages and canary/blue-green style deployments
- —
HTTP APIs offer significantly lower latency and cost than REST APIs for the majority of common use cases
Disadvantages
- —
REST API's request/response transformation via Velocity Template Language mapping templates has a real learning curve and can become hard to debug
- —
Adds a network hop and a small amount of latency compared to a client calling a backend directly
- —
HTTP APIs lack some REST API features (usage plans/API keys, request validation, more granular WAF integration) that some use cases genuinely need
- —
Cold starts on the Lambda backend (if used) still apply — API Gateway itself doesn't have cold starts, but a Lambda integration behind it can
Common mistakes
- —
Defaulting to REST APIs out of habit or unfamiliarity with HTTP APIs, paying more and accepting higher latency for features that aren't actually being used
- —
Not setting throttling limits, leaving the API vulnerable to being overwhelmed by either legitimate traffic spikes or abuse
- —
Forgetting that a Lambda Proxy integration expects a very specific JSON response shape ({statusCode, headers, body}) from the Lambda function — a function returning a plain object instead causes confusing integration errors
- —
Not versioning or staging APIs properly, making breaking changes directly against production traffic instead of testing in a separate stage first
- —
Using a Lambda authorizer that itself makes a slow external call on every single request without caching its result, adding significant latency to every API call
In the AWS Console
- 1
AWS Console → API Gateway → Create API → HTTP API (or REST API)
Choose the API type, then add routes by specifying a method and path (e.g. GET /orders) and selecting the backend integration.
Start with HTTP API by default; only choose REST API if you have a specific, confirmed need for usage plans, API keys, or advanced request transformation.
- 2
API Gateway → [your API] → Authorization → Create and attach authorizer
Choose JWT (for Cognito or third-party OIDC tokens) or Lambda (for custom auth logic), and attach it to the routes needing protection.
Leave public/unauthenticated routes (like a health check endpoint) without an authorizer attached — not every route needs one.
- 3
API Gateway → [your API] → Deploy → Stages
Create separate stages (e.g. dev, staging, prod) each with their own deployment and configuration, and note each stage's own invoke URL.
Deploying to a stage doesn't automatically affect other stages — this is what lets you test changes safely before promoting to production.
- 4
API Gateway → [your API] → Throttling (REST API: Usage Plans; HTTP API: route-level throttling settings)
Set a rate limit (steady-state requests per second) and burst limit to protect the backend from being overwhelmed.
Throttling limits apply per API/stage (or per API key for usage plans) — set them based on what your actual backend can safely handle, not an arbitrary default.
🎤 Interview questions
What problem does API Gateway solve for a serverless architecture using Lambda? (Listen for: Lambda has no built-in HTTP listener; API Gateway is what exposes Lambda functions as callable HTTP endpoints, plus handles auth/throttling/routing centrally.)
When would you choose HTTP APIs over REST APIs in API Gateway? (Listen for: HTTP APIs are cheaper and lower-latency for the majority of common use cases; REST APIs are needed only for specific features like usage plans/API keys or advanced request transformation.)
How does a Lambda Proxy integration differ from a non-proxy integration? (Listen for: Proxy passes the full request through with minimal transformation and expects a specific JSON response shape; non-proxy gives more fine-grained control over request/response transformation but requires more configuration.)
How would you rate-limit different partners differently on the same API? (Listen for: REST API usage plans with distinct API keys per partner, each with its own throttle/quota limits.)
Why might attaching a slow, uncached Lambda authorizer to every route be a problem? (Listen for: adds real latency to every single API call since the authorizer runs before the actual backend logic; caching the authorization result mitigates this for repeated calls with the same token.)