This chapter covers Amazon API Gateway integration patterns, a critical topic for the SAA-C03 exam, particularly under Domain 3 (High Performance) and Objective 3.7 (Choosing a compute and API integration strategy). Understanding how API Gateway integrates with various AWS services and on-premises backends is essential for designing scalable, secure, and performant APIs. Approximately 5-10% of exam questions touch on API Gateway, often in scenarios involving RESTful APIs, WebSocket APIs, or HTTP APIs with Lambda, DynamoDB, or private integrations.
Jump to a section
Imagine a large corporate office building with a smart lobby concierge desk. The building has multiple internal departments (backend services like Lambda, EC2, or on-premises servers) that handle different types of requests. External clients (mobile apps, web applications, third-party services) want to interact with these departments but cannot just walk in—they must go through the concierge. The concierge (API Gateway) sits at the main entrance, receives all incoming requests, and performs several critical functions. First, the concierge authenticates visitors by checking IDs (API keys, IAM roles, Cognito tokens) and decides who is allowed entry. Then, they inspect the request details (method, path, headers) and route the visitor to the correct department based on a predefined map (API resources and methods). The concierge may also transform the request—for example, they might take a visitor's verbal request and write it down on a form that the department expects (request mapping templates). They enforce rate limits: only 10 visitors per minute per client (throttling). They cache frequently requested information (response caching) so that if another visitor asks the same question, the concierge can answer immediately without bothering the department. They also log every interaction in a visitor log (CloudWatch) and can send alerts if something unusual happens. The concierge can even manage multiple versions of the same department (canary deployments) by sending a small percentage of visitors to a new version. The building has a single public address (API endpoint), and all internal departments are hidden behind the concierge—this provides security and abstraction. If a department changes its location (backend migration), the concierge updates its map, and visitors never notice.
What is API Gateway and Why It Exists
Amazon API Gateway is a fully managed service that makes it easy for 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 your backend services. 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, monitoring, and API version management.
The primary reasons for using API Gateway include: - Decoupling frontend from backend: Clients interact with a single API endpoint, while backend services can be changed, scaled, or replaced without affecting clients. - Security: API Gateway can authenticate requests using AWS IAM, Lambda authorizers, or Amazon Cognito. It also supports SSL/TLS termination and AWS WAF integration. - Throttling and rate limiting: Protects backend services from being overwhelmed by too many requests. - Caching: Improves performance and reduces latency by caching responses. - Monitoring and logging: Integrated with Amazon CloudWatch for metrics, logs, and alarms. - API versioning: Supports multiple versions of an API simultaneously. - Canary deployments: Allows you to gradually roll out new versions of an API.
How API Gateway Works Internally
API Gateway sits between the client and the backend. When a client sends a request to an API Gateway endpoint, the following steps occur:
1. Request arrives at API Gateway endpoint: The client sends an HTTP(S) request to the API Gateway's public endpoint (e.g., https://api-id.execute-api.region.amazonaws.com/stage/resource).
2. TLS termination: API Gateway terminates the SSL/TLS connection, decrypting the request.
3. Authorization: API Gateway checks if the request is authorized. This can be done via IAM authorization (using SigV4), a Lambda authorizer (custom logic), or Amazon Cognito user pools.
4. Request validation: If configured, API Gateway validates the request body, headers, and query parameters against a model (JSON Schema).
5. Throttling check: API Gateway checks if the client has exceeded the throttling limits (e.g., 10,000 requests per second per account). If exceeded, it returns 429 Too Many Requests.
6. Cache lookup: If caching is enabled and the request is a GET method with a cache key, API Gateway checks the cache for a valid response. If found, it returns the cached response without invoking the backend.
7. Request transformation: API Gateway can transform the incoming request using mapping templates (Velocity Template Language) to adapt it to the backend's expected format.
8. Integration request: API Gateway sends the request to the configured integration endpoint. The integration type determines how the request is forwarded:
- AWS Lambda: API Gateway invokes the Lambda function synchronously.
- HTTP: API Gateway forwards the request to an HTTP/HTTPS endpoint.
- AWS Service: API Gateway calls an AWS service (e.g., DynamoDB, Step Functions) using the AWS SDK.
- Mock: API Gateway returns a mock response without calling any backend.
- VPC Link: API Gateway sends requests to resources inside a VPC via a Network Load Balancer.
9. Backend processing: The backend processes the request and returns a response.
10. Integration response: API Gateway receives the response and can transform it using mapping templates.
11. Response caching: If caching is enabled and the response is cacheable, API Gateway stores the response in the cache.
12. Response returned to client: API Gateway sends the final response to the client.
Key Components, Values, Defaults, and Timers
API types: REST API, HTTP API, WebSocket API. REST APIs offer full feature set (including caching, usage plans, API keys). HTTP APIs are cheaper and simpler, with lower latency (no data transformation, no usage plans). WebSocket APIs maintain persistent connections for real-time communication.
Endpoints: Edge-optimized (default, uses CloudFront edge locations), Regional (serves from a single region), Private (accessible only within a VPC via interface VPC endpoints).
Throttling limits: By default, each API Gateway account has a limit of 10,000 requests per second (RPS) across all APIs, with a burst limit of 5,000 requests. These can be increased via a support ticket. For HTTP APIs, the limit is 10,000 RPS per account, burst 5,000. For WebSocket APIs, the limit is 1,000 new connections per second.
Caching: Cache capacity ranges from 0.5 GB to 237 GB. Default TTL is 300 seconds (can be set from 0 to 3600 seconds). Caching is only available for REST APIs.
Timeouts: Integration timeout for REST APIs is 29 seconds maximum (default 29 seconds). For HTTP APIs, the timeout is 30 seconds. For WebSocket APIs, the maximum connection duration is 2 hours.
Payload size: Maximum payload size is 10 MB for REST APIs and HTTP APIs. For WebSocket APIs, the maximum message size is 128 KB.
Mapping templates: Use Velocity Template Language (VTL) to transform requests and responses. Common use cases: converting JSON to XML, adding headers, or extracting path parameters.
Stage variables: Key-value pairs that act like environment variables. They can be used in mapping templates, integration endpoints, and Lambda function aliases.
Canary deployments: You can create a canary release for a stage, sending a percentage of traffic to a different deployment.
Configuration and Verification Commands
API Gateway is primarily configured via the AWS Management Console, AWS CLI, or SDKs. Below are some common CLI commands:
# Create a REST API
export REST_API_ID=$(aws apigateway create-rest-api --name 'MyAPI' --description 'My REST API' --query 'id' --output text)
# Get the root resource ID
export ROOT_RESOURCE_ID=$(aws apigateway get-resources --rest-api-id $REST_API_ID --query 'items[0].id' --output text)
# Create a resource (e.g., /items)
export RESOURCE_ID=$(aws apigateway create-resource --rest-api-id $REST_API_ID --parent-id $ROOT_RESOURCE_ID --path-part 'items' --query 'id' --output text)
# Create a GET method
export LAMBDA_ARN='arn:aws:lambda:us-east-1:123456789012:function:my-function'
aws apigateway put-method --rest-api-id $REST_API_ID --resource-id $RESOURCE_ID --http-method GET --authorization-type NONE
# Set up Lambda integration
aws apigateway put-integration --rest-api-id $REST_API_ID --resource-id $RESOURCE_ID --http-method GET --type AWS_PROXY --integration-http-method POST --uri arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/$LAMBDA_ARN/invocations
# Deploy the API to a stage
aws apigateway create-deployment --rest-api-id $REST_API_ID --stage-name prod
# Test the API
curl https://$REST_API_ID.execute-api.us-east-1.amazonaws.com/prod/itemsHow API Gateway Interacts with Related Technologies
AWS Lambda: The most common integration. API Gateway invokes Lambda functions synchronously. With AWS_PROXY integration, the entire request is passed to Lambda, and the Lambda function returns a properly formatted response. With AWS integration (non-proxy), you can use mapping templates to transform the request/response.
DynamoDB: API Gateway can directly integrate with DynamoDB using the AWS integration type. This allows clients to perform CRUD operations on DynamoDB tables without a Lambda function. The integration uses IAM roles to access DynamoDB.
Amazon Cognito: API Gateway can use Cognito user pools as an authorizer. The client first authenticates with Cognito and obtains a JWT token. The token is then passed in the Authorization header, and API Gateway validates it before forwarding the request to the backend.
AWS WAF: API Gateway can be associated with a Web ACL to protect against common web exploits like SQL injection and cross-site scripting.
VPC Link: For integrating with resources inside a VPC (e.g., an ALB or NLB), you create a VPC Link. API Gateway uses the VPC Link to send requests to the NLB, which then routes to the backend instances.
CloudWatch: API Gateway automatically publishes metrics (e.g., count, latency, 4XX errors, 5XX errors) to CloudWatch. You can also enable detailed logging to CloudWatch Logs.
AWS X-Ray: API Gateway can send trace data to AWS X-Ray for end-to-end tracing of requests.
Route 53: You can point a custom domain name to an API Gateway endpoint using Route 53 alias records.
Client sends HTTPS request
The client makes an HTTPS request to the API Gateway endpoint URL. For REST APIs, the URL format is `https://api-id.execute-api.region.amazonaws.com/stage/resource`. The request includes HTTP method (GET, POST, PUT, DELETE, etc.), headers, query parameters, and optionally a body. API Gateway terminates the TLS connection, decrypting the request. It then parses the HTTP method and path to determine which API resource and method are being called.
Authorization check
API Gateway checks the configured authorization type. If using IAM authorization, it verifies the request's SigV4 signature. If using a Lambda authorizer, API Gateway invokes the Lambda function with the request context; the Lambda function returns an IAM policy that allows or denies the request. If using Cognito, API Gateway validates the JWT token in the Authorization header. If authorization fails, API Gateway returns a 401 Unauthorized or 403 Forbidden response.
Throttling and usage plan check
API Gateway checks if the request exceeds the account-level throttling limits (10,000 RPS, burst 5,000) or the per-client usage plan limits (e.g., 1000 requests per day). If a limit is exceeded, API Gateway returns a 429 Too Many Requests response. Throttling is applied per account, per region, per API, and per stage. Burst limits allow short spikes, but sustained traffic above the steady-state limit will be throttled.
Cache lookup (if enabled)
For GET methods with caching enabled, API Gateway checks the cache for a response matching the cache key (typically the request parameters and headers). If a valid cached response exists and its TTL has not expired, API Gateway returns the cached response immediately, bypassing the backend integration. This reduces latency and backend load. Cache TTL defaults to 300 seconds but can be configured from 0 to 3600 seconds.
Integration request and transformation
API Gateway constructs the integration request based on the integration type. For AWS_PROXY integration, the entire request is passed as-is to the backend (usually Lambda). For AWS or HTTP integrations, API Gateway can apply mapping templates to transform the request (e.g., convert JSON to XML, add headers, or change the method). The integration request is then sent to the backend. For VPC Link integrations, the request is forwarded through the VPC Link to an NLB inside the VPC.
Backend processing and response
The backend service (e.g., Lambda function, HTTP server, DynamoDB) processes the request and returns a response. For Lambda proxy integration, the Lambda function must return a response in the format expected by API Gateway: a JSON object with `statusCode`, `headers`, and `body`. For non-proxy integrations, the backend returns a raw response, and API Gateway can transform it using mapping templates. The response is then sent back to API Gateway.
Integration response transformation
API Gateway receives the backend response. For non-proxy integrations, it can apply mapping templates to transform the response (e.g., convert XML to JSON, remove headers, or set HTTP status codes based on backend output). It can also override the response status code and headers. For proxy integrations, the response is passed through without transformation.
Cache update and client response
If caching is enabled and the response is cacheable (e.g., GET method with 200 status code), API Gateway stores the response in the cache with the configured TTL. Finally, API Gateway sends the response to the client, including any headers set during the integration response. The client receives the HTTP response with the status code, headers, and body.
Enterprise Scenario 1: E-Commerce Platform with Lambda Backend
A large e-commerce company uses API Gateway to expose a RESTful API for its mobile and web applications. The backend consists of hundreds of Lambda functions handling product catalog, user authentication, shopping cart, and order processing. The company uses API Gateway's Lambda proxy integration to pass the entire request context to Lambda, simplifying development. They implement a Lambda authorizer that checks JWT tokens from Amazon Cognito. To handle traffic spikes during Black Friday, they set usage plans for third-party developers, limiting them to 1000 requests per hour. API Gateway's caching is enabled for the product catalog GET endpoint, reducing latency from 200ms to 5ms. They use canary deployments to gradually roll out new API versions, sending 10% of traffic to the new deployment for 24 hours before shifting 100%. Monitoring via CloudWatch alarms on 4XX and 5XX errors triggers auto-scaling adjustments and incident alerts.
Enterprise Scenario 2: Financial Services with Private API
A bank needs to expose internal APIs to its mobile banking app and partner systems. Security is paramount, so they use API Gateway's private endpoint, accessible only via VPC endpoints. The API Gateway is deployed as a private REST API, and a VPC Link connects to an internal Network Load Balancer that routes to on-premises servers via AWS Direct Connect. The integration uses HTTP (non-proxy) with mapping templates to transform JSON requests into legacy XML format expected by the mainframe. IAM authorization is used for internal services, while Cognito authenticates mobile users. Throttling is set to 1000 RPS per stage to protect the mainframe. They enable AWS WAF to block SQL injection attempts. Detailed logging to CloudWatch Logs is enabled for audit compliance. A common misconfiguration is forgetting to attach the correct resource policy to the VPC endpoint, causing timeouts.
Enterprise Scenario 3: IoT Device Management with WebSocket API
A smart home company uses API Gateway WebSocket APIs to manage millions of IoT devices. Devices establish a WebSocket connection and send telemetry data. API Gateway routes messages to Lambda functions for processing, and can send commands back to devices via the connection ID stored in DynamoDB. The WebSocket API uses a Lambda authorizer to authenticate devices using device certificates. The maximum connection duration is 2 hours, so devices must reconnect periodically. The company uses CloudWatch metrics to monitor connection count and message throughput. A common scaling issue is hitting the default connection rate limit (1000 new connections per second), which they increase via a support ticket. They also use API Gateway's $connect and $disconnect routes to manage device state in DynamoDB.
What SAA-C03 Tests on API Gateway
The SAA-C03 exam tests your ability to choose the right API Gateway integration pattern for a given scenario. The key objective codes are: 3.7 (Choosing a compute and API integration strategy), 2.1 (Designing secure access to AWS resources), and 3.1 (Selecting appropriate compute resources). You must understand the differences between REST, HTTP, and WebSocket APIs, and when to use proxy vs. non-proxy integrations. The exam also covers caching, throttling, authentication, and VPC Link integration.
Common Wrong Answers and Why Candidates Choose Them
Choosing HTTP API when REST API is needed: Candidates often select HTTP API because it's cheaper and simpler, but the scenario requires features only available in REST APIs, such as caching, usage plans, or API keys. The exam will explicitly mention these requirements.
Selecting a public endpoint when private is required: If the scenario mentions that the backend is in a VPC and must not be accessible from the internet, the correct answer is a private API endpoint with a VPC endpoint. Candidates may incorrectly choose edge-optimized or regional endpoints.
Using AWS integration (non-proxy) when Lambda proxy is simpler: The exam might present a scenario where the backend is a Lambda function. Many candidates choose AWS integration because they think it's more flexible, but proxy integration is simpler and passes the entire request to Lambda. The exam expects you to choose proxy unless there's a specific need for mapping templates.
Configuring throttling at the method level instead of stage or account level: The exam may ask how to limit a specific client's request rate. The correct answer is to create a usage plan with an API key, not just method-level throttling.
Specific Numbers, Values, and Terms Appearing on the Exam
Maximum integration timeout: 29 seconds for REST APIs, 30 seconds for HTTP APIs.
Default cache TTL: 300 seconds.
Throttling defaults: 10,000 RPS per account, burst 5,000.
Payload size limit: 10 MB.
WebSocket connection duration: 2 hours.
API types: REST, HTTP, WebSocket.
Endpoint types: Edge-optimized, Regional, Private.
Integration types: AWS_PROXY, AWS, HTTP_PROXY, HTTP, MOCK, VPC_LINK.
Authorizer types: IAM, Lambda, Cognito.
Edge Cases and Exceptions
API Gateway does not support custom domain names for private endpoints in all regions.
Caching is only available for REST APIs, not HTTP or WebSocket APIs.
Mapping templates are not supported with proxy integrations (AWS_PROXY, HTTP_PROXY).
WebSocket APIs do not support Lambda authorizers for the $connect route if using IAM authorization.
For private APIs, the resource policy must allow traffic from the VPC endpoint.
How to Eliminate Wrong Answers
If the scenario mentions caching, eliminate HTTP API (no caching).
If the scenario requires API keys or usage plans, eliminate HTTP API.
If the backend is in a VPC and must not be internet-facing, choose Private API + VPC Link.
If the scenario involves real-time two-way communication, choose WebSocket API.
If the backend is Lambda and no request transformation is needed, choose Lambda proxy integration.
API Gateway supports three API types: REST, HTTP, and WebSocket. REST APIs have the most features; HTTP APIs are cheaper and faster; WebSocket APIs enable real-time communication.
Lambda proxy integration is the simplest way to connect API Gateway to Lambda; use non-proxy when you need request/response transformation.
Caching is only available for REST APIs, with a default TTL of 300 seconds. Cache capacity ranges from 0.5 GB to 237 GB.
API Gateway throttles at 10,000 requests per second per account (burst 5,000). Use usage plans with API keys to throttle individual clients.
Private API endpoints require a VPC endpoint (interface endpoint) and are not internet-accessible.
Maximum integration timeout is 29 seconds for REST APIs and 30 seconds for HTTP APIs.
WebSocket APIs have a maximum connection duration of 2 hours and a maximum message size of 128 KB.
API Gateway can authorise requests using IAM, Lambda authorizers, or Amazon Cognito.
These come up on the exam all the time. Here's how to tell them apart.
REST API
Supports caching, usage plans, API keys, and mapping templates.
Maximum integration timeout is 29 seconds.
Higher latency due to additional features.
More expensive per request.
Supports edge-optimized, regional, and private endpoints.
HTTP API
No caching, usage plans, API keys, or mapping templates.
Maximum integration timeout is 30 seconds.
Lower latency (simpler processing).
Cheaper per request (about 70% lower cost).
Supports regional and private endpoints (no edge-optimized).
Lambda Proxy Integration
Entire request is passed to Lambda as-is.
Lambda must return a properly formatted response (statusCode, headers, body).
Simplest to configure; no mapping templates needed.
Less control over request/response transformation.
Recommended for most Lambda use cases.
Lambda Non-Proxy Integration
Request can be transformed using mapping templates before reaching Lambda.
Lambda can return a simple response; API Gateway transforms it.
More complex to configure; requires VTL templates.
More control over request/response transformation.
Useful when you need to adapt legacy backends or convert formats.
Mistake
API Gateway can directly invoke Lambda functions asynchronously.
Correct
API Gateway only invokes Lambda functions synchronously. For asynchronous invocations, you need to use Lambda's asynchronous invocation or integrate with services like SQS or EventBridge.
Mistake
HTTP APIs support the same features as REST APIs.
Correct
HTTP APIs are simpler and cheaper but lack features like caching, usage plans, API keys, and mapping templates. REST APIs offer full feature set.
Mistake
API Gateway automatically retries failed requests.
Correct
API Gateway does not retry failed requests. Retry logic must be implemented on the client side or using a service like Step Functions.
Mistake
Private API endpoints can be accessed from the internet if the VPC has an Internet Gateway.
Correct
Private API endpoints are only accessible from within the VPC via VPC endpoints (interface endpoints). They are not internet-facing even if the VPC has an Internet Gateway.
Mistake
API Gateway supports HTTP/2 for client connections.
Correct
API Gateway supports HTTP/1.1 and HTTP/2 for REST and HTTP APIs. However, HTTP/2 is only supported for edge-optimized endpoints (via CloudFront). Regional endpoints use HTTP/1.1.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
REST APIs offer a full set of features including caching, usage plans, API keys, mapping templates, and canary deployments. HTTP APIs are simpler and cheaper, with lower latency, but lack these advanced features. For scenarios requiring caching or API keys, choose REST API. For simple, cost-effective APIs, choose HTTP API.
Use Lambda proxy integration when you want the entire request passed to Lambda and you control the Lambda function to return a properly formatted response. It is simpler and recommended for most use cases. Use non-proxy integration when you need to transform the request or response (e.g., convert XML to JSON) using mapping templates, or when you are integrating with an existing Lambda function that expects a specific input format.
API Gateway caching stores responses from GET requests to reduce latency and backend load. You enable caching for a stage and set a TTL (default 300 seconds, max 3600). The cache key is based on the request parameters and headers. API Gateway checks the cache before invoking the backend; if a valid cached response exists, it returns it directly. Caching is only available for REST APIs.
Yes, you can use a VPC Link to connect API Gateway to resources inside a VPC, which can be on-premises via AWS Direct Connect or VPN. Create a Network Load Balancer in the VPC pointing to your on-premises servers, then create a VPC Link and configure the API Gateway integration to use the VPC Link.
By default, each API Gateway account has a limit of 10,000 requests per second (RPS) across all APIs in a region, with a burst limit of 5,000 RPS. For HTTP APIs, the limits are the same. For WebSocket APIs, the limit is 1,000 new connections per second. You can request increases via a support ticket.
You can secure API Gateway using IAM authorization (SigV4), Lambda authorizers (custom logic), or Amazon Cognito (JWT tokens). Additionally, you can enable AWS WAF to protect against common attacks, use SSL/TLS certificates, and restrict access via resource policies (for private APIs).
A VPC Link is a resource that allows API Gateway to send requests to resources inside a VPC. It is used when your backend is an internal ALB, NLB, or EC2 instances that are not publicly accessible. You create a VPC Link and configure the API integration to use it. VPC Links are available for REST APIs and HTTP APIs.
You've just covered API Gateway Integration Patterns — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?