Amazon API Gateway
API Gateway is AWS's managed front door for HTTP and WebSocket APIs. You define routes; AWS handles HTTPS termination, request validation, authentication, throttling, logging, and integration with the backend — Lambda, an HTTP service, or AWS service APIs directly. Pairing it with Lambda gives a fully managed HTTP service with no servers anywhere.
Use it whenever you expose an API and want managed auth, rate limiting, and routing without running NGINX or Kong yourself.
Three API Types
HTTP API is the recommended default for modern serverless APIs — cheaper (~70% less per million requests), faster, and simpler. REST API is the original, with extra features (usage-plan API keys, certain request validation, edge-optimized endpoints, directly attached WAF) at more cost and complexity.
WebSocket API handles stateful bidirectional connections (chat, live dashboards, games) that stay open and let the server push messages. Start every new API as an HTTP API unless you can name a REST-only feature you need.
Integrations
A route forwards to an integration: most often a Lambda function; an HTTP backend (public or in-VPC via VPC Link); an AWS service direct call (DynamoDB, SQS, Step Functions, S3) with no Lambda in the middle; or a mock for stubbing and CORS preflight.
A common pattern mixes HTTP API plus Lambda for compute-heavy routes with a few AWS-service-direct integrations for simple actions like putting a message on an SQS queue.
Authorization, Throttling, and Stages
Authorization is per route: none, IAM (SigV4 for service-to-service), Cognito or a JWT authorizer (validate tokens from Cognito, Auth0, Okta), or a Lambda authorizer for custom schemes. Throttling and authorization are independent — an open endpoint that throttles is still open.
Throttling defaults on at 10,000 rps (raisable) and can tighten per stage, route, or API key. API keys plus usage plans (REST only) meter individual clients. Stages are versioned deployment slots (dev, staging, prod), each with its own URL and settings.
API Gateway — public APIs needing managed auth, throttling, request validation, usage plans, or WebSocket support.
Application Load Balancer — internal microservice-to-microservice traffic or latency-critical APIs, where skipping the API Gateway hop is cheaper and a few ms faster.
- Defaulting to REST API when HTTP API is ~70% cheaper and lower-latency — pick REST only for a specific REST-only feature.
- Assuming throttling provides security — a misconfigured authorizer returning 200 leaves an endpoint open no matter the rate limit.
- Creating separate APIs per environment instead of using stages.
- Putting an internal microservice API behind API Gateway when a plain ALB is cheaper and simpler.
- Skipping request-shape validation at the gateway, letting malformed requests reach and crash backend code.
- Adding API Gateway caching (REST only) when CloudFront in front would be cheaper and more flexible.
- Start with HTTP API unless you need a specific REST-only feature.
- Use Cognito or a JWT authorizer for user-facing APIs; Lambda authorizers for custom logic.
- Set throttling at the route level for expensive operations.
- Use stages for environments, not separate APIs.
- Emit JSON access logs to CloudWatch and validate request shape at the gateway.
- Put CloudFront in front of public APIs needing DDoS protection or edge caching.
Knowledge Check
Which API Gateway type is the recommended starting point for a new serverless API?
- HTTP API — cheaper, faster, simpler than REST API
- REST API — the original, most featureful default for new APIs
- WebSocket API — the most modern type for request/response
- Classic API — the cheapest of the four gateway types
Why does throttling not substitute for authorization?
- They are independent — a rate-limited route with no real auth stays open to anyone within the limit
- Throttling encrypts requests in transit with TLS before they reach the route but does not authenticate them
- Throttling only applies to callers that have already passed an authorizer and been fully authenticated
- They are the same underlying setting under two different names
How should you manage dev, staging, and prod for one API?
- Use stages — versioned deployment slots, each with its own URL
- Create three separate APIs, one for each environment
- Use three separate AWS accounts and duplicate the API into each
- Change the integration target by hand before each environment deploy
For an internal microservice-to-microservice call that never leaves the VPC, what is often the better choice than API Gateway?
- An Application Load Balancer — cheaper and a little faster without the hop
- A WebSocket API for the internal service-to-service traffic
- A REST API with response caching enabled on the stage to keep internal calls fast
- Route 53 weighted routing spread evenly across the internal service endpoints
You got correct