This chapter covers Amazon API Gateway, a fully managed service for creating, deploying, and managing APIs at scale. API Gateway is a core component of serverless architectures and is heavily tested on the DVA-C02 exam, appearing in approximately 15-20% of questions, either directly or integrated with Lambda, DynamoDB, and other services. You will learn how to design RESTful and WebSocket APIs, configure authentication, throttling, caching, and monitoring, and understand the differences between API types (REST, HTTP, WebSocket) and their use cases.
Jump to a section
Imagine a large office building with many departments (microservices). The building has a reception desk at the main entrance (API Gateway). Visitors (clients) arrive and the receptionist checks their identity (authentication), looks up which department they need (routing), and may even fill out a standardized form for them (request transformation). The receptionist can also limit how many visitors enter per minute (throttling), keep a log of all visits (logging), and even redirect visitors to a different entrance if the main one is under renovation (canary deployments). If a visitor asks for the same information multiple times, the receptionist can provide a cached copy without bothering the department (caching). The receptionist does not handle the actual work of the departments but manages the flow of requests and responses, enforcing policies consistently. This is exactly how API Gateway works: it sits between clients and backend services, handling cross-cutting concerns so that backend developers can focus on business logic.
What is Amazon API Gateway?
Amazon API Gateway is a fully managed service that enables developers to create, publish, maintain, monitor, and secure APIs at any scale. It acts as a front door for applications to access data, business logic, or functionality from backend services such as AWS Lambda, Amazon EC2, or any publicly accessible HTTP endpoint. API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, authorization and access control, throttling, monitoring, and API version management.
Why API Gateway Exists
In a microservices or serverless architecture, backend services are often distributed and may be invoked via different protocols or endpoints. Without a unified entry point, clients would need to know the details of each service, leading to tight coupling and increased complexity. API Gateway solves this by providing a single, consistent interface. It also offloads cross-cutting concerns such as authentication, rate limiting, request validation, and response transformation, allowing backend developers to focus on business logic. Additionally, API Gateway integrates seamlessly with AWS services like AWS WAF for web application firewall, AWS X-Ray for tracing, and CloudWatch for monitoring.
How API Gateway Works Internally
When a client sends a request to an API Gateway endpoint, the following steps occur: 1. Endpoint Resolution: The client resolves the API Gateway endpoint URL via DNS. The endpoint is specific to the API and stage (e.g., https://api-id.execute-api.region.amazonaws.com/prod). 2. TLS Termination: API Gateway terminates the TLS connection, decrypting the request. It supports both TLS 1.2 and TLS 1.3. 3. Request Processing: The request passes through the configured pipeline: first, any authorizer (Lambda or Cognito) is invoked to validate credentials. Then, request validation checks the payload against a model. If validation fails, a 400 Bad Request is returned immediately. 4. Integration Request: API Gateway constructs an integration request based on the integration type (Lambda, HTTP, AWS service, Mock, VPC Link). It applies any request mapping templates (Velocity Template Language) to transform the client request into the format expected by the backend. 5. Backend Invocation: The request is sent to the backend. For Lambda, the function is invoked synchronously (or asynchronously if using AWS_PROXY). For HTTP, a request is made to the specified URL. 6. Integration Response: The backend's response is returned to API Gateway. Response mapping templates transform the backend response into the desired client response format. 7. Response Delivery: API Gateway sends the final HTTP response to the client, including any configured headers, status codes, and body. Caching can occur at this stage: if caching is enabled and the request matches a cached entry, steps 3-6 are skipped.
Key Components, Values, Defaults, and Timers
API Types: REST API (full-featured, supports API keys, usage plans, caching), HTTP API (lower latency, cheaper, simpler, supports OIDC/OAuth2), WebSocket API (bidirectional communication).
Endpoint Types: Edge-optimized (default, uses CloudFront globally), Regional (for clients in the same region), Private (only accessible within a VPC via interface VPC endpoint).
Throttling: By default, each API has a steady-state request rate of 10,000 requests per second (rps) and a burst capacity of 5,000 concurrent requests across all stages. These can be increased via Service Quotas. Per-client throttling can be enforced using usage plans and API keys.
Caching: Cache capacity from 0.5 GB to 237 GB. TTL defaults to 300 seconds (5 minutes), configurable from 0 to 3600 seconds. Cache is encrypted by default.
Timeout: Integration timeout defaults to 29 seconds for REST APIs, 30 seconds for HTTP APIs, and 10 seconds for WebSocket APIs. Maximum is 29 seconds for REST (cannot be increased).
Payload Size: Maximum payload size is 10 MB for REST and HTTP APIs. Requests larger than that are rejected with a 413 Request Entity Too Large error.
Logging and Tracing: CloudWatch logging can be enabled at INFO or ERROR level. X-Ray tracing can be enabled for end-to-end tracing.
Configuration and Verification Commands
To create a REST API using the AWS CLI:
aws apigateway create-rest-api --name 'MyAPI' --description 'My first API' --region us-east-1To create a resource:
aws apigateway create-resource --rest-api-id <api-id> --parent-id <root-resource-id> --path-part 'items'To deploy an API:
aws apigateway create-deployment --rest-api-id <api-id> --stage-name 'prod'To view throttling settings:
aws apigateway get-stage --rest-api-id <api-id> --stage-name 'prod'For HTTP APIs, use apigatewayv2 commands:
aws apigatewayv2 create-api --name 'MyHTTPAPI' --protocol-type HTTPInteraction with Related Technologies
Lambda: API Gateway can trigger Lambda functions via proxy integration (event passed as JSON) or custom integration (mapping templates transform the request). The Lambda function must return a specific response format for proxy integration (statusCode, headers, body).
DynamoDB: API Gateway can directly integrate with DynamoDB using AWS service integration, allowing actions like PutItem, GetItem, etc., without a Lambda function. This is useful for simple CRUD operations but less flexible.
Cognito: API Gateway can use Cognito User Pools as an authorizer to validate JWT tokens. This is a common pattern for mobile and web applications.
AWS WAF: Can be associated with API Gateway stages to protect against common web exploits like SQL injection or cross-site scripting.
CloudFront: Edge-optimized endpoints use CloudFront to reduce latency for global clients. You can also put CloudFront in front of a regional endpoint for custom domain names and WAF.
Define API structure
In the AWS Management Console or via CLI, create a new API (REST, HTTP, or WebSocket). Define resources (URL paths) and methods (GET, POST, PUT, DELETE, etc.). Each method can have its own integration (Lambda, HTTP, etc.), authorization, and request validation. For REST APIs, you can also define models (JSON Schema) for request/response validation.
Configure authorization
Choose an authorization method: IAM, Cognito User Pools, Lambda authorizer (custom JWT or token validation), or OpenID Connect (for HTTP APIs). For IAM, you attach a resource policy to the API. For Cognito, you specify the User Pool ARN and required scopes. For Lambda authorizer, you provide a Lambda function ARN that validates the token and returns an IAM policy. The authorizer is invoked on every request (unless caching is enabled).
Set up integrations
For each method, define the integration type: AWS_PROXY (Lambda proxy), AWS (non-proxy Lambda or AWS service), HTTP_PROXY, HTTP, MOCK, or VPC_LINK. In proxy mode, the entire request is passed to the backend, and the backend must return the response in the correct format. In non-proxy mode, you can use mapping templates to transform request and response. For HTTP integrations, you specify the endpoint URL. For VPC_LINK, you use a Network Load Balancer to access private resources.
Enable throttling and caching
Configure throttling at the stage level: set the rate (requests per second) and burst (concurrent requests) limits. You can also set per-method throttling. Enable caching to reduce latency and backend load: choose cache size (0.5 GB to 237 GB) and TTL (default 300 seconds). Cache is keyed by request parameters; you can configure which headers/query strings are used for cache keys. Caching is available only for REST APIs.
Deploy and monitor
Deploy the API to a stage (e.g., 'dev', 'prod'). Each deployment creates a snapshot of the API configuration. You can enable CloudWatch logging (full request/response logging or error-only) and X-Ray tracing. Monitor metrics like 4XX/5XX error counts, latency, and integration latency. Set up alarms for unusual activity. Use usage plans to enforce throttling per API key for different client tiers.
Scenario 1: Serverless E-commerce Backend
A large e-commerce company uses API Gateway to expose RESTful APIs for product catalog, shopping cart, and order management. Each API resource integrates with a dedicated Lambda function that reads/writes to DynamoDB. API Gateway handles authentication via Cognito User Pools (users log in with email/password) and applies rate limiting: 1000 requests per second for the catalog (read-heavy) and 100 requests per second for orders (write-sensitive). Caching is enabled for the catalog endpoint with a TTL of 60 seconds to reduce DynamoDB read costs. The company uses edge-optimized endpoints to serve global customers with low latency. They also enable CloudWatch logging at ERROR level to capture 5XX errors and set up alarms for any spike in 4XX errors (e.g., due to invalid authentication). Misconfiguration often occurs when developers forget to set proper CORS headers, causing browser-based applications to fail. They resolved this by enabling CORS in API Gateway for the required origins and methods.
Scenario 2: Real-time Chat Application
A startup builds a real-time chat application using WebSocket API Gateway. Clients connect via wss:// URL and send messages that are broadcast to other connected clients via Lambda functions. API Gateway manages the WebSocket connections, using a $connect route for authentication (Lambda authorizer validates JWT), a $disconnect route for cleanup, and custom routes (e.g., sendMessage) for message handling. The backend uses DynamoDB to store connection IDs and chat history. The startup configures a 10-second idle timeout (default for WebSocket) and enables CloudWatch logs to debug connection issues. They also use API Gateway's built-in callback URLs to send messages to specific clients. Common pitfalls include not handling the $disconnect route properly (leaving stale connection IDs) and exceeding the maximum payload size of 128 KB for WebSocket frames.
Scenario 3: Microservices with HTTP APIs
A financial services company migrates from a monolithic application to microservices. They use HTTP APIs (lower cost, lower latency) to expose internal services like account balance, transaction history, and fraud detection. Each microservice runs on Amazon ECS behind an Application Load Balancer. API Gateway integrates with these HTTP endpoints using VPC Link to keep traffic within the VPC. They use IAM authorization with a resource policy to restrict access to specific source IP ranges (corporate VPN). They also enable request validation to ensure that required headers (e.g., X-Client-ID) are present. Throttling is set at 5000 rps with a burst of 2000 per service. They learned the hard way that HTTP APIs do not support usage plans or API keys, so they had to implement custom authentication logic.
DVA-C02 Exam Focus on API Gateway
The DVA-C02 exam tests API Gateway in the context of developing and deploying serverless applications. Key objectives include: 1.2 (Design APIs), 2.3 (Deploy and manage APIs), 3.1 (Secure APIs), and 4.1 (Monitor and troubleshoot). Expect scenario-based questions where you must choose the correct API type, integration method, or security mechanism.
Common Wrong Answers and Why
Choosing REST API when HTTP API is sufficient: Many candidates assume REST API is always better because it has more features. However, if the scenario does not require usage plans, API keys, or caching, HTTP API is cheaper and faster. The exam often tests this trade-off.
Selecting edge-optimized endpoint for internal VPC traffic: Edge-optimized endpoints route traffic through CloudFront, which adds latency and cost for clients within the same region. For internal clients, Regional endpoint is better. Private endpoint is for VPC-only access.
Using Lambda authorizer when Cognito User Pools would work: Lambda authorizers are more flexible but more complex and costly. If the scenario already uses Cognito for user management, using Cognito User Pool authorizer is simpler and cheaper.
Enabling caching for WebSocket APIs: WebSocket APIs do not support caching. Only REST APIs support caching.
Key Numbers and Terms
REST API: max integration timeout 29 seconds.
HTTP API: max timeout 30 seconds.
WebSocket API: idle timeout 10 seconds.
Default throttling: 10,000 rps, 5,000 burst.
Payload size limit: 10 MB.
Cache TTL default: 300 seconds.
API key: used with usage plans, only for REST APIs.
Mapping templates: Velocity Template Language (VTL).
Proxy integration: Lambda must return {statusCode, headers, body}.
VPC Link: requires Network Load Balancer.
Edge Cases and Exceptions
Lambda custom authorizer caching: By default, the authorizer result is cached for 300 seconds. If you need to invalidate the cache, you can set a TTL of 0 or use a different policy.
Request validation fails with 400: If validation fails, the request is rejected before reaching the backend. This is a cost-saving measure.
Multipart/form-data: API Gateway does not natively support multipart/form-data. You must use a proxy integration and handle it in the backend.
Binary support: REST APIs support binary content types (e.g., images) by configuring binary media types.
How to Eliminate Wrong Answers
If the question mentions 'lowest latency' or 'cheapest', lean toward HTTP API.
If it mentions 'API keys', 'usage plans', or 'caching', it must be REST API.
If it mentions 'real-time bidirectional', it's WebSocket API.
For authorization, if the scenario involves Cognito, use Cognito authorizer; if custom token validation, use Lambda authorizer.
For integration, if the backend is Lambda, prefer proxy integration for simplicity; if you need to transform request/response, use non-proxy with mapping templates.
API Gateway supports three API types: REST, HTTP, and WebSocket — each with distinct features and use cases.
Default throttling limits are 10,000 rps steady-state and 5,000 burst; can be increased via Service Quotas.
Maximum payload size is 10 MB; larger requests receive a 413 error.
REST API timeout max is 29 seconds; HTTP API timeout max is 30 seconds.
Caching is only available for REST APIs; default TTL is 300 seconds.
VPC Link requires a Network Load Balancer to access private resources.
For Lambda proxy integration, the function must return a JSON object with statusCode, headers, and body.
These come up on the exam all the time. Here's how to tell them apart.
REST API
Supports API keys and usage plans for client throttling.
Supports caching (0.5 GB to 237 GB).
Supports AWS WAF integration.
Maximum integration timeout: 29 seconds.
Supports custom domain names with mutual TLS.
HTTP API
Lower latency and lower cost.
No support for API keys or usage plans.
No caching; built-in throttling only at account level.
Maximum integration timeout: 30 seconds.
Supports OIDC and OAuth2 authorization.
Mistake
API Gateway can only integrate with Lambda.
Correct
API Gateway can integrate with any HTTP endpoint, AWS service (e.g., DynamoDB, Step Functions), or private VPC resources via VPC Link. Lambda is just one option.
Mistake
Edge-optimized endpoints are always faster than regional endpoints.
Correct
Edge-optimized endpoints use CloudFront, which adds a hop. For clients in the same region, regional endpoints have lower latency. Edge-optimized is best for global clients.
Mistake
HTTP APIs support the same features as REST APIs.
Correct
HTTP APIs are simpler and cheaper but lack usage plans, API keys, caching, and some security features (e.g., IAM authorization via resource policies). They support OIDC and OAuth2.
Mistake
API Gateway automatically validates all requests.
Correct
Request validation must be explicitly configured using models (JSON Schema). If enabled, it validates the request body, headers, and query strings before sending to the backend.
Mistake
You can increase the integration timeout beyond 29 seconds for REST APIs.
Correct
The maximum integration timeout for REST APIs is 29 seconds. For longer-running operations, consider using asynchronous patterns (e.g., Lambda with Step Functions).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Edge-optimized endpoints route requests through CloudFront edge locations, reducing latency for global clients. They are best for geographically distributed users. Regional endpoints serve clients in the same AWS region, offering lower latency for local traffic and lower cost. Private endpoints are accessible only within a VPC via interface VPC endpoints. On the exam, choose edge-optimized for global audiences, regional for same-region clients, and private for internal VPC communication.
Use Cognito User Pools when you already use Cognito for authentication (e.g., mobile/ web apps). It is simpler and cheaper. Use Lambda authorizer when you need custom token validation (e.g., custom JWT, OAuth tokens from third-party providers) or when you need to modify the IAM policy based on request context (e.g., user ID). Lambda authorizer adds latency and cost per invocation.
Yes, but with limitations. API Gateway supports binary content types (e.g., images, PDFs) when you configure binary media types. However, the maximum payload size is 10 MB. For larger files, consider using presigned S3 URLs: the client uploads directly to S3, and API Gateway can provide the presigned URL via a Lambda function.
CORS can be enabled in the API Gateway console by selecting a resource and method, then enabling CORS. This adds the necessary headers (Access-Control-Allow-Origin, etc.) to responses. You must also configure the OPTIONS method to handle preflight requests. For Lambda proxy integration, your Lambda function must return the CORS headers in the response.
A usage plan specifies throttling and quota limits for API keys. You create a usage plan, associate it with an API stage, and then generate API keys for clients. Each key is assigned to the plan, enforcing per-client rate limits (requests per second) and daily/monthly quotas. Usage plans are only supported for REST APIs, not HTTP APIs.
API Gateway caches responses from your backend based on the cache key (default: all request parameters). You can specify which parameters (headers, query strings, stage variables) form the cache key. The TTL defaults to 300 seconds and can be set from 0 to 3600 seconds. Caching reduces latency and backend load but is only available for REST APIs. Cache is encrypted at rest.
In proxy integration (AWS_PROXY, HTTP_PROXY), the entire request is passed to the backend, and the backend must return the response in the correct format (for Lambda: {statusCode, headers, body}). In non-proxy integration, you can use mapping templates (VTL) to transform the request and response, giving you more control over the format. Proxy is simpler; non-proxy is more flexible but requires more configuration.
You've just covered API Gateway Development — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?