AWSDOP-C02
On this page
Beginner-friendly overview

API Gateway

API Gateway is a fully managed front door for your APIs. Clients call one HTTPS endpoint, and API Gateway handles the request β€” authenticating the caller, throttling traffic, and forwarding it to a backend such as a Lambda function, an HTTP service, or another AWS service. It removes the need to run and scale your own API servers.

Why a Managed Front Door

Without API Gateway you'd build and operate the plumbing every API needs: TLS termination, request throttling, authentication, request/response handling, logging, and versioning. API Gateway provides all of that as a managed service, so your backend can be a small Lambda function while the gateway absorbs the operational concerns in front of it.

Client β†’ API Gateway (the front door) β†’ backend integration Client web Β· mobile Β· service HTTPS API Gateway auth Β· throttle Β· cache stages Β· logging Β· TLS request/response handling integrate Backend Lambda Β· HTTP endpoint ALB/NLB (VPC Link) Step Functions Β· SQS

Three Kinds of API

API Gateway can build three different API types, and choosing between them is the first decision:

REST API β€” the original, full-featured type. It supports everything: caching, usage plans and API keys, request/response transformation, canary deployments, and all endpoint types. It's the most capable and the most expensive.

HTTP API β€” a newer, cheaper, faster, simpler type. Great for straightforward "receive a request, hand it to a Lambda" APIs with modern token-based auth. It trades away many REST features in exchange for lower cost and latency.

WebSocket API β€” for real-time, two-way communication such as chat apps, live dashboards, or notifications, where the server needs to push messages to connected clients rather than just answer requests.

Where the Front Door Lives β€” Endpoint Types

For a REST API you also choose where the endpoint is exposed:

Regional β€” the API is served directly in its own AWS Region. Clients connect straight to that Region.

Edge-optimized β€” the API still lives in one Region, but API Gateway puts a CloudFront distribution in front of it so clients connect to the nearest edge location. Good for a single-Region API with users spread around the world.

Private β€” the API is reachable only from inside a VPC, never the public internet. Used for internal-only APIs.

Stages and Deployments

You don't edit a live API directly. You make changes, then deploy them to a stage (like dev, test, or prod). A stage is a named, callable version of your API. This is why "I updated my API but nothing changed" almost always means "you forgot to deploy to the stage."

API Gateway is a receptionist. Clients only ever talk to the receptionist, who checks your credentials (auth), enforces the queue (throttling), remembers recent answers (caching), and walks the request to the right office (integration). The offices (your Lambda/HTTP backends) never face the public directly β€” and swapping which office answers is a stage change, not a rebuild of the lobby.