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

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.

The third type: WebSocket APIs

REST and HTTP APIs share one shape: the client asks, the gateway answers, the exchange ends. Chat, live dashboards and multiplayer games need the other direction too, which is what the third type is for. A WebSocket API holds a persistent, bidirectional connection. The client connects once; afterward either side can send messages without a new request.

Built-in routes $connect and $disconnect fire when a client opens or closes the connection (great for tracking who’s online). Incoming messages are dispatched by a route selection expression, a field in the message picks a custom route (e.g. action: "sendMessage") to a backend handler.

Pushing to a specific client

Each open connection has a connectionId. To send data to a client, the backend calls the @connections management API with that id. Store the ids (e.g. in DynamoDB) and you can push to one user, a room, or broadcast to all.

So pick a WebSocket API when you need low-latency, server-initiated, two-way messaging. If clients only ever poll or you just need occasional updates, a regular HTTP API (or even periodic polling) is simpler and cheaper.

⚓ Chat, live notifications, collaborative editing, live sports/markets, multiplayer state.

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.
What can a WebSocket API do that a REST or HTTP API fundamentally can’t?
Keep a persistent two-way connection so the server can push messages to clients anytime, not just respond to requests.
What are $connect and $disconnect for?
They fire when a client opens or closes the connection, ideal for tracking presence and cleaning up connection state.
How are incoming WebSocket messages routed to handlers?
By a route selection expression: a field in the message (e.g. an action) selects a custom route to a backend integration.
How does the backend send a message to one connected client?
Call the @connections management API with that client’s connectionId (which you store, e.g. in DynamoDB).
What extra responsibility does a WebSocket API add?
Managing connection state, storing connectionIds, mapping them to users/rooms, and cleaning up on disconnect.

Sources

Open the SysPad canvas · Official Amazon API Gateway documentation

Other networking lessons