2.1.2. Amazon API Gateway for Serverless APIs
First Principle: Amazon API Gateway creates a secure, scalable, and unified entry point for developers to expose their application's logic as APIs, abstracting backend complexity.
API Gateway sits between your clients and your backend, handling authentication, throttling, request validation, and response transformation so your function code stays focused on business logic. It acts as the "front door" for applications, allowing applications to interact with backend services (like AWS Lambda functions or EC2 instances) via RESTful APIs.
You define resources (URL paths like /users, /orders) and methods (GET, POST, DELETE) that map to backend integrations — most commonly Lambda functions for serverless backends. API Gateway handles throttling (10,000 requests per second default), response caching (to reduce Lambda invocations), and request/response transformation.
Security is built in: you can require IAM signatures, Cognito tokens, or custom Lambda authorizers on any endpoint. Deployment stages (dev, staging, prod) let you manage different API configurations with stage variables that change behavior without code changes.
Each stage references a deployment — a point-in-time snapshot of the API's resources and methods — and has its own invoke URL and its own settings: throttling, caching, logging and stage variables. Resources and methods belong to the API, not to a stage — a stage only exposes the deployment snapshot it points to. A stage variable can appear in the Lambda integration ARN (...:function:my-fn:${stageVariables.alias}) so the dev and prod stages call different aliases, and with Lambda proxy integration the stage variables also arrive in the event as event['stageVariables'] — they are not Lambda environment variables.
Request validation (REST API) attaches a request validator and a model (JSON Schema) to a method, so a request with a missing header, query string or body field is rejected with a 400 before the backend is invoked. CORS: a browser app on another origin needs CORS enabled on the resource — API Gateway adds an OPTIONS preflight method and the Access-Control-Allow-* headers; with Lambda proxy integration the function must also return Access-Control-Allow-Origin in its own responses.
Two API types matter for the exam: REST API (full-featured — request validation, API keys, WAF integration, usage plans) and HTTP API (cheaper, faster, but fewer features). Know when the question requires REST API features vs. when HTTP API's lower cost is the right answer.
Scenario: You're building a new serverless backend for a mobile application. You need to expose a set of RESTful APIs that will be called by the mobile app, and these APIs will trigger Lambda functions for processing.
⚠️ Exam Trap: API Gateway has two types: REST API and HTTP API. HTTP APIs are cheaper and faster but have fewer features (no API keys, no request validation, no WAF integration). The exam tests when to use each.