API Gateway — Concept
What it is
Amazon API Gateway = fully managed service to publish, secure, monitor, and version APIs — REST, HTTP, and WebSocket — in front of Lambda / HTTP backends / AWS services.
Why it exists
Building a production API needs auth, rate limiting, caching, deployment stages, monitoring, and integration with backends. API GW provides all of that without running infrastructure.
Three API types
| Type | Protocol | Best when |
|---|---|---|
| HTTP API | HTTP | Most workloads — cheaper, faster, fewer features |
| REST API | HTTP | Need advanced features: usage plans, API keys, request validation, request/response transformations, X-Ray, edge-optimized, private endpoints |
| WebSocket API | WSS | Real-time bidirectional apps (chat, gaming, dashboards) |
Endpoint types (REST API)
- Edge-optimized (default) — uses CloudFront under the hood.
- Regional — clients in same region; pair with your own CloudFront if needed.
- Private — only accessible from your VPC via interface endpoint (PrivateLink).
Integrations
- Lambda (proxy or non-proxy).
- HTTP backends (any public/private URL).
- AWS service integration (e.g. directly into DynamoDB, S3 — no Lambda needed).
- VPC Link → reach private VPC resources via NLB.
- Mock integrations for testing.
Auth & security
- IAM authorizers — caller signs with SigV4.
- Lambda authorizer — custom token validation (JWT, OAuth).
- Cognito User Pool authorizer — built-in JWT validation.
- API keys + Usage plans (REST only) — per-customer throttling.
- Resource policy — restrict by IP, VPC, account.
- WAF integration on REST + edge-optimized.
Performance & cost features
- Caching (REST only): cache responses per stage (0.5–237 GB), reduces backend load, TTL configurable.
- Throttling (per stage and per method): rate + burst limits.
- Stages (
dev,prod) with deployment versioning. - Canary deployments — % traffic to new version.
- Custom domain names + ACM certs (must be in us-east-1 for edge-optimized).
Monitoring
- CloudWatch metrics (4XX, 5XX, Latency, Count).
- CloudWatch Logs for execution + access logs.
- X-Ray tracing.
When to use vs alternatives
| Use ... | Instead of ... | When ... |
|---|---|---|
| HTTP API | REST API | Lower latency / cost, simple HTTP-only need |
| REST API | HTTP API | Need API keys, usage plans, request validation, X-Ray |
| WebSocket API | REST | Real-time bidirectional |
| AppSync | API Gateway | GraphQL APIs with managed real-time / offline |
| ALB | API Gateway | Internal HTTP load balancing, EC2-/container-bound apps |
Common exam scenarios
- "Expose Lambda over HTTPS with auth & throttling" → API Gateway + Cognito / Lambda authorizer.
- "Tiered customers: Free 100 req/s, Premium 1000 req/s" → REST API + API keys + Usage plans.
- "Cache product list responses to reduce backend cost" → REST API caching with TTL.
- "Private API only callable from inside VPC" → Private endpoint + interface VPC endpoint.
- "Need to call private NLB-backed service" → VPC Link (REST or HTTP API).
- "Real-time chat" → WebSocket API + Lambda + DynamoDB connection table.
- "Filter requests by IP range" → API Gateway resource policy or WAF.
Exam tip
Picking between API types:
- HTTP API (default modern choice) — most use cases, half the cost of REST.
- REST API — when you specifically need its richer features (API keys, request validation, X-Ray, caching).
- WebSocket API — bidirectional streams.