SysPad › Lessons › networking lessons › Amazon API Gateway
How Amazon API Gateway works
Amazon API Gateway. Pick the API type: REST (full-featured - API keys, usage plans, response caching), HTTP (low-latency, ~60% cheaper), or WebSocket (persistent bidirectional messaging, billed per message). REST/HTTP are request/response.
An API Gateway is the bouncer and receptionist for your API. Clients never talk to your Lambdas or services directly, they go through the gateway, which handles auth, rate limiting, validation, and routing so your backend code can focus on business logic. The main decision: the feature-rich REST API or the leaner, cheaper HTTP API.
What you will learn
- Why put a gateway in front of your API instead of exposing backends directly?
- What cross-cutting work does the gateway take off your code?
- REST API vs HTTP API: what do you gain and give up?
- How do stages and throttling help you operate an API safely?
The managed front door
API Gateway sits between clients and your backend (Lambda, an HTTP service, or an AWS API) and manages the request lifecycle. Your backends stay private; the gateway is the public, controlled entry point.
The cross-cutting work it handles
The gateway centralises concerns every API needs: authentication/authorization(API keys, IAM, Cognito, custom authorizers), throttling and rate limiting, request validation and transformation, and response caching.
Without it, you’d reimplement these in every backend. With it, they’re configuration at the edge.
⚓ Public and partner APIs, mobile/web backends, and any Lambda you want to expose over HTTP.
REST API vs HTTP API
REST APIs are the feature-rich option: request/response transformation, API keys and usage plans, request validation, caching, WAF integration, and fine-grained control. HTTP APIs are a newer, leaner type, lower latency and significantly cheaper, with a streamlined feature set (JWT auth, simple proxy routes).
Stages, throttling, and protecting the backend
APIs deploy to stages (e.g. dev, prod), each with its own settings. Throttling caps the request rate, which protects your backend (and downstream databases) from spikes and abuse, the gateway sheds excess load instead of letting it overwhelm you.
Flashcards
- Why front your API with API Gateway instead of exposing Lambdas directly?
- It centralises auth, throttling, validation, caching, and routing at one controlled entry point, keeping backends private and code focused on logic.
- Name cross-cutting concerns API Gateway handles for you.
- Authentication/authorization, rate limiting/throttling, request validation and transformation, and response caching.
- When choose an HTTP API over a REST API?
- For simple, cost-sensitive Lambda/HTTP proxying, HTTP APIs are cheaper and lower-latency with a streamlined feature set.
- When do you specifically need a REST API?
- For advanced features: API keys/usage plans, request transformation, edge caching, WAF, and fine-grained control.
- What does gateway throttling protect, and how?
- Your backend and downstream stores, by capping request rate and shedding excess load before it reaches them.
Sources
- AWS, What is Amazon API Gateway
- AWS, Choosing between REST APIs and HTTP APIs
- AWS, Throttling and usage plans
- AWS, Stages and deployments
Open the SysPad canvas · Official Amazon API Gateway documentation