This chapter covers the three API Gateway endpoint types—REST, HTTP, and WebSocket—and their distinct use cases, performance characteristics, and pricing models. Understanding the differences is critical for the SAA-C03 exam, where you must choose the right API type for scenarios involving latency, payload transformation, real-time messaging, or cost optimization. Approximately 5-8% of exam questions touch API Gateway, typically in conjunction with Lambda, DynamoDB, or Step Functions.
Jump to a section
Imagine a busy restaurant with three distinct dining areas: a standard dining room (REST API), a fast-casual counter (HTTP API), and a private event space (WebSocket API). The maitre d' (API Gateway) stands at the entrance, directing each guest to the correct area based on their reservation type. For the standard dining room, the maitre d' performs full service: checks IDs, takes coat, escorts to table, and later returns with the bill (request/response with payload transformation, validation, and throttling). For the fast-casual counter, the maitre d' simply points the guest to the order kiosk with minimal interaction (lower latency, no transformations). For the private event, the maitre d' establishes a dedicated phone line (WebSocket connection) that stays open throughout the event, allowing guests to send messages back and forth instantly without hanging up. The maitre d' also enforces capacity limits: if the dining room is full, guests are turned away (429 Too Many Requests). For the private event, the maitre d' monitors the line quality and can disconnect unruly guests (idle timeout). Each area has its own menu (API) and pricing (cost model). The maitre d' ensures that guests are routed correctly, security is maintained (API keys, IAM, Lambda authorizers), and the restaurant operates smoothly under load.
What is API Gateway?
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, 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, monitoring, and API version management.
REST API (Regional, Edge-Optimized, Private)
REST APIs are the original API Gateway offering, providing full-featured API management with support for request/response transformation, validation, throttling, caching, and multiple integration types. They are ideal for APIs that require fine-grained control over the request/response lifecycle. REST APIs support three endpoint types: - Edge-optimized: Designed for geographically distributed clients. Requests are routed to the nearest CloudFront Point of Presence (POP), which then forwards to the API Gateway regional endpoint. This reduces latency for global clients but adds a small overhead for CloudFront processing. Default for REST APIs. - Regional: Designed for clients within the same AWS Region. All requests go directly to the API Gateway regional endpoint, avoiding CloudFront overhead. Lower latency than edge-optimized when clients are close to the region. - Private: Only accessible from within a VPC via a VPC endpoint (interface endpoint of AWS PrivateLink). Traffic never traverses the public internet. Used for internal microservices.
REST APIs support payload transformation using Velocity Template Language (VTL) mapping templates. They also support API keys, usage plans, and throttling at the method or API level. REST APIs have a maximum integration timeout of 29 seconds for Lambda and HTTP integrations, and 30 seconds for AWS service integrations.
HTTP API (Lower Latency, Simpler)
HTTP APIs were introduced in late 2019 as a simpler, cheaper, and faster alternative to REST APIs. They are designed for low-latency, cost-sensitive workloads that do not require the advanced features of REST APIs. HTTP APIs lack:
Payload transformation (no VTL mapping templates)
API keys and usage plans (use API keys only for JWT or OIDC authorizers)
Edge-optimized endpoints (only regional and private)
Request validation (must be done at the backend)
Custom domain names with mutual TLS (only REST supports mTLS)
HTTP APIs do support JWT authorizers, Lambda authorizers, and IAM authorization. They also support automatic deployment of CORS configuration without custom Lambda responses. The maximum integration timeout for HTTP APIs is 30 seconds for all integrations. HTTP APIs are roughly 60% cheaper than REST APIs at scale and have lower latency due to the absence of VTL processing.
WebSocket API (Real-Time Two-Way Communication)
WebSocket APIs maintain persistent connections between clients and the backend, enabling real-time, full-duplex communication. They are ideal for applications like chat apps, live dashboards, or multiplayer games. WebSocket APIs use a 'route selection expression' to determine which backend integration to invoke based on the message content. Key components:
- Connection ID: Each client is assigned a unique connection ID upon connection. The connection ID is stored in a DynamoDB table (recommended) or in memory for managing active connections.
- Route Selection Expression: A JSON expression (e.g., $request.body.action) that evaluates the incoming message to determine the route key. The route key is matched against defined routes (e.g., sendMessage, joinRoom).
- Routes: Define the behavior for different message types. The $connect route is invoked when a client connects; $disconnect when a client disconnects; $default if no route matches.
- Callback URL: A URL (https://api-id.execute-api.region.amazonaws.com/Stage/@connections/connectionId) used to send messages to connected clients. This is done via the PostToConnection API call.
WebSocket APIs have an idle timeout of 10 minutes (configurable from 1 to 60 minutes). After the timeout, the connection is closed. The maximum message size is 128 KB. For larger payloads, use chunked transfer encoding or compress the data.
Performance and Scaling
All API Gateway types scale automatically to handle traffic bursts. REST and HTTP APIs can handle tens of thousands of requests per second (RPS) per region. For higher throughput, request a service quota increase. API Gateway throttles requests at the account level (default 10,000 RPS across all APIs) and per-API level (default 1,000 RPS). These can be increased by contacting AWS Support.
Security
IAM Authorization: Use IAM policies to grant access to API Gateway APIs. Supports signature version 4 (SigV4) signing.
Lambda Authorizer: A custom Lambda function that validates the token (JWT, OAuth, custom) and returns an IAM policy.
JWT Authorizer: Built-in support for validating JWT tokens (HTTP APIs only).
Cognito User Pools: Use Amazon Cognito as an identity provider.
API Keys: For REST APIs only, used with usage plans to throttle and meter access.
WAF: AWS WAF can be associated with API Gateway to protect against common web exploits.
Monitoring
API Gateway integrates with Amazon CloudWatch to provide metrics like Count, 4XXError, 5XXError, Latency, IntegrationLatency, and CacheHitCount. It also supports CloudWatch Logs for detailed request/response logging. X-Ray tracing is available for REST and HTTP APIs to trace requests through the entire microservice stack.
Cost Model
REST API: Charged per million API calls ($3.50/M for regional, $4.25/M for edge-optimized) plus data transfer and cache usage.
HTTP API: Charged per million API calls ($1.00/M) plus data transfer. No cache charges.
WebSocket API: Charged per million messages ($1.00/M) plus connection minutes ($0.25 per million minutes).
Integration Types
Lambda: Invoke a Lambda function synchronously.
HTTP: Proxy to any HTTP endpoint (public or private via VPC link).
AWS Service: Integrate with other AWS services (e.g., DynamoDB, SQS, Step Functions).
Mock: Return a static response without calling a backend.
VPC Link: Connect to resources inside a VPC via Network Load Balancer (for REST/HTTP) or PrivateLink (for REST).
Caching
REST APIs support caching at the stage level (from 0.5 GB to 237 GB). Cache reduces latency and throttling for repeated requests. HTTP APIs do not support caching. WebSocket APIs do not have a built-in cache.
Versioning and Stages
API Gateway supports versioning through stages (e.g., dev, test, prod). Each stage has its own configuration, including throttling, caching, logging, and domain name. You can deploy multiple stages from the same API definition. Stage variables can be used to configure backend endpoints dynamically.
Transformation (Mapping Templates)
REST APIs can transform request/response payloads using VTL mapping templates. For example, you can transform a JSON request to XML before forwarding to a SOAP backend. HTTP APIs do not support this. This is a key differentiator for the exam: if the question mentions payload transformation, the answer must involve REST API.
Throttling and Quotas
Account-level: 10,000 RPS across all APIs (default). Can be increased.
Per-API: 1,000 RPS (default). Can be increased.
Per-method: Can set a custom throttling rate in the stage settings.
Usage plans: For REST APIs, define rate and burst limits per API key.
Burst: API Gateway allows short bursts up to the maximum rate (e.g., 5,000 RPS burst for a 1,000 RPS rate).
Configure API Gateway endpoint type
When creating an API, you choose the endpoint type: edge-optimized (uses CloudFront POPs globally), regional (direct access within a region), or private (VPC only). For REST APIs, the default is edge-optimized. For HTTP APIs, only regional and private are available. The choice affects latency, cost, and accessibility. Edge-optimized is best for global user base; regional is best for low latency within the same region; private is for internal VPC-only access. The exam frequently tests this distinction in scenario-based questions.
Define routes and integrations
For REST/HTTP APIs, define resources (e.g., /users) and methods (GET, POST). For each method, specify the integration type: Lambda, HTTP, AWS service, mock, or VPC link. For WebSocket APIs, define routes with a route selection expression (e.g., $request.body.action). Each route maps to an integration. The $connect route is invoked on new connection; $disconnect on close; $default for unmatched messages. The exam tests that you know which integration types are available for each API type.
Set authorization and authentication
Choose an authorization method: IAM, Lambda authorizer, Cognito, or JWT (HTTP only). For REST APIs, you can also use API keys with usage plans. For WebSocket APIs, authorization is typically done in the $connect route using a Lambda authorizer. The exam often presents a scenario where you need to choose between IAM and Cognito for authentication, or between Lambda authorizer and JWT authorizer. Remember that JWT is only available for HTTP APIs.
Configure throttling and caching
Set throttling limits at the stage or method level to prevent backend overload. REST APIs support caching; HTTP and WebSocket do not. For REST APIs, you can also create usage plans with API keys to enforce rate limits per client. The exam tests the default throttling limits (10,000 RPS account-level, 1,000 per API) and that caching is only for REST APIs. If a question asks for low latency for repeated requests, consider enabling caching.
Enable logging and monitoring
Enable CloudWatch Logs for detailed request/response logging. Enable CloudWatch metrics for monitoring. Use X-Ray for tracing (REST and HTTP only). The exam may ask about troubleshooting errors (e.g., 4XX vs 5XX). 4XX errors indicate client-side issues (e.g., invalid API key, exceeded quota). 5XX errors indicate server-side issues (e.g., Lambda timeout, integration failure). Knowing the difference helps eliminate wrong answers.
Deploy the API to a stage
After configuration, deploy the API to a stage (e.g., prod). Each deployment updates the stage with the current API definition. You can also enable canary deployments for gradual traffic shifting. The exam tests that each deployment is immutable; you can roll back by redeploying an older version. Stages have their own URL: https://api-id.execute-api.region.amazonaws.com/stage. Custom domain names can be mapped to stages.
Enterprise Scenario 1: Global E-Commerce Platform
A large e-commerce company serves customers worldwide. They use an edge-optimized REST API to expose product catalog, pricing, and inventory endpoints. The API integrates with Lambda functions that query DynamoDB and Elasticsearch. Edge-optimized endpoints reduce latency for customers in Europe, Asia, and North America by routing through CloudFront POPs. The API uses API keys with usage plans to differentiate between mobile app, web, and third-party partners. Caching is enabled for the product catalog endpoint to reduce database load and improve response times. Throttling is set to 500 RPS per API key to prevent abuse. Common issues: misconfiguring the cache TTL (default 300 seconds) leading to stale data; forgetting to invalidate cache after inventory updates. The exam might test that edge-optimized endpoints are best for global clients but add CloudFront overhead.
Enterprise Scenario 2: Real-Time Chat Application
A startup builds a real-time chat application using WebSocket API. Clients connect via WebSocket and send messages with an action field (e.g., 'sendMessage', 'joinRoom'). The $connect route invokes a Lambda authorizer that validates the JWT token and returns a policy allowing the connection. The $disconnect route cleans up the connection ID from a DynamoDB table. The 'sendMessage' route invokes a Lambda that broadcasts the message to all other connected clients using the PostToConnection API. The company sets an idle timeout of 30 minutes to avoid stale connections. They use CloudWatch metrics to monitor connection count and message throughput. Common misconfiguration: not handling the $disconnect route properly, leading to orphaned connection IDs in DynamoDB. The exam tests that WebSocket APIs are for real-time, bidirectional communication and that you must manage connection IDs yourself.
Enterprise Scenario 3: Internal Microservices
A financial services company uses private REST APIs for internal microservices. The APIs are only accessible from within the VPC via VPC endpoints (PrivateLink). This ensures that traffic never traverses the public internet, meeting compliance requirements. Each microservice has its own API with IAM authorization. The company uses VPC links to connect to internal HTTP endpoints hosted on EC2 behind a Network Load Balancer. They set throttling at the stage level to 1000 RPS per API. Common pitfall: forgetting to attach a VPC endpoint policy that allows access from specific IAM roles. The exam tests that private APIs require an interface VPC endpoint and that they cannot be accessed from outside the VPC.
The SAA-C03 exam tests your ability to select the correct API Gateway type based on requirements. Key objective codes: Domain 3: High-Performance Architectures, Objective 3.7: Choose the appropriate API Gateway type and features. Expect 2-3 questions directly or indirectly involving API Gateway.
Most Common Wrong Answers: 1. Choosing REST API when HTTP API is sufficient (e.g., scenario with low latency and cost savings, no transformation). Candidates see 'API Gateway' and default to REST, forgetting HTTP is cheaper and faster. 2. Choosing WebSocket for a simple request-response API. Candidates confuse persistent connection with real-time requirement. WebSocket is only for bidirectional, real-time communication. 3. Selecting edge-optimized for a single-region client base. Candidates think edge-optimized is always best, but regional is lower latency when clients are in the same region. 4. Assuming HTTP API supports payload transformation. This is a key differentiator: only REST has VTL mapping templates.
Specific Numbers and Terms: - Default throttle: 10,000 RPS account-level, 1,000 per API. - Maximum integration timeout: 29 seconds for REST (Lambda/HTTP), 30 seconds for HTTP and WebSocket. - WebSocket idle timeout: 10 minutes (configurable 1-60). - WebSocket max message size: 128 KB. - Cache sizes: 0.5 GB to 237 GB (REST only). - Pricing: HTTP ~60% cheaper than REST.
Edge Cases: - If a question mentions 'mutual TLS' (mTLS), only REST supports it. - If a question mentions 'request validation', only REST has built-in validation (HTTP does not). - If a question mentions 'API keys' or 'usage plans', only REST supports them. - For private APIs, you need an interface VPC endpoint (PrivateLink).
Eliminating Wrong Answers: - If the scenario requires low latency and cost optimization, lean toward HTTP API unless transformation or caching is needed. - If the scenario requires real-time bidirectional communication, choose WebSocket. - If the scenario involves a global user base, consider edge-optimized; if regional, use regional. - If the scenario mentions 'transform XML to JSON' or 'map payload', it must be REST API.
REST API supports VTL mapping templates, API keys, usage plans, caching, and edge-optimized endpoints; HTTP API does not.
HTTP API is cheaper (~60% less) and has lower latency than REST API, but lacks advanced features.
WebSocket API is for real-time, bidirectional communication; uses connection IDs and route selection expressions.
Edge-optimized endpoints route through CloudFront POPs; regional endpoints are direct; private endpoints are VPC-only.
Default throttling: 10,000 RPS account-level, 1,000 per API. Burst up to 5,000 RPS per API.
Maximum integration timeout: 29 seconds for REST (Lambda/HTTP), 30 seconds for HTTP and WebSocket.
WebSocket idle timeout defaults to 10 minutes; max message size 128 KB.
Only REST API supports mutual TLS (mTLS) and request validation.
For global clients, use edge-optimized REST; for regional clients, use regional REST or HTTP.
If a question mentions 'payload transformation', the answer must involve REST API.
These come up on the exam all the time. Here's how to tell them apart.
REST API
Supports payload transformation via VTL mapping templates
Supports API keys and usage plans for throttling and metering
Supports edge-optimized, regional, and private endpoints
Supports request validation and model schemas
Higher cost per million calls ($3.50 regional, $4.25 edge-optimized)
HTTP API
No payload transformation; backend must handle it
No API keys or usage plans; uses JWT, Lambda authorizers, or IAM
Only regional and private endpoints (no edge-optimized)
No built-in request validation; must be done at backend
Lower cost per million calls ($1.00)
REST/HTTP API
Request-response model; client sends request, server responds
Stateless; each request is independent
Supports caching (REST only)
Maximum integration timeout 29-30 seconds
Lower cost for low-frequency, short-duration interactions
WebSocket API
Persistent, full-duplex connection; server can push messages
Stateful; connection ID is maintained across messages
No built-in caching
Idle timeout configurable (1-60 min, default 10)
Higher cost for long-lived connections; charged per connection minute and message
Mistake
HTTP API supports payload transformation using mapping templates.
Correct
Only REST API supports VTL mapping templates. HTTP API does not have any built-in payload transformation. If transformation is needed, you must use REST API or handle it in the backend.
Mistake
WebSocket API can be used for standard request-response APIs.
Correct
WebSocket API is designed for persistent, bidirectional, real-time communication. For standard request-response (e.g., RESTful CRUD), use REST or HTTP API. WebSocket adds unnecessary complexity and cost.
Mistake
Edge-optimized endpoints are always the best choice for low latency.
Correct
Edge-optimized endpoints add CloudFront POP overhead. For clients in the same region as the API, regional endpoints provide lower latency because they bypass CloudFront.
Mistake
HTTP API supports API keys and usage plans.
Correct
API keys and usage plans are only available for REST APIs. HTTP API uses JWT, Lambda authorizers, or IAM for authentication, but not API keys.
Mistake
All API Gateway types support caching.
Correct
Only REST API supports caching. HTTP and WebSocket APIs do not have a built-in cache. If caching is required, use REST API or implement caching at the application level.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use REST API when you need payload transformation (VTL mapping templates), API keys with usage plans, caching, request validation, or edge-optimized endpoints. Use HTTP API when you need lower cost and latency, and you don't need those advanced features. The exam will present scenarios with specific requirements; match them to the capabilities.
Yes, WebSocket API is designed for real-time, bidirectional communication like chat apps. You define routes (e.g., sendMessage) and use a route selection expression. The backend (often Lambda) can send messages to connected clients using the PostToConnection API. The exam may test that you need to manage connection IDs, typically in DynamoDB.
Edge-optimized endpoints route requests through CloudFront POPs for lower latency for global clients. Regional endpoints serve requests directly from the API Gateway regional endpoint, which is lower latency for clients in the same region. Edge-optimized adds a small overhead due to CloudFront processing. The exam tests this in scenarios with user location.
No, API keys and usage plans are only available for REST APIs. HTTP API supports JWT authorizers, Lambda authorizers, and IAM authorization. If a question mentions API keys, you must choose REST API.
The default idle timeout is 10 minutes. You can configure it between 1 and 60 minutes. After the timeout, the connection is closed. The exam may test that you can adjust this based on application needs.
No, only REST API supports caching. HTTP API does not have a built-in cache. If the scenario requires caching, you must use REST API or implement caching at the application level (e.g., using ElastiCache).
Use a private REST or HTTP API with an interface VPC endpoint (PrivateLink). The API is only accessible from within the VPC. You can also attach a VPC endpoint policy to control access. The exam tests that private APIs require a VPC endpoint and cannot be accessed from the internet.
You've just covered API Gateway: REST vs HTTP vs WebSocket — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?