Cargando...
Cargando...
Build, deploy, and manage secure, scalable APIs at any scale — without managing infrastructure.
Amazon API Gateway is a fully managed service that enables developers to create, publish, maintain, monitor, and secure REST, HTTP, and WebSocket APIs at any scale. It acts as the 'front door' for applications to access data, business logic, or functionality from backend services such as AWS Lambda, Amazon EC2, or any publicly reachable HTTP endpoint. API Gateway handles all the tasks involved in accepting and processing API calls, including traffic management, authorization, access control, monitoring, and API version management.
Expose backend services (Lambda, EC2, HTTP endpoints, AWS services) as secure, scalable, and manageable APIs without provisioning or managing servers.
Use When
Avoid When
REST API
Full-featured API type with caching, request/response transformation, models, validators, usage plans, and API keys. Higher cost but maximum features.
HTTP API
Lower latency, lower cost (up to 70% cheaper than REST API). Supports Lambda, HTTP backends, JWT authorizers. Does NOT support caching, request/response transformation, or API keys natively.
WebSocket API
Persistent two-way connections. Supports $connect, $disconnect, $default routes. Maintains connection state via DynamoDB integration pattern.
Lambda Authorizer (Custom Authorizer)
TOKEN type (JWT/OAuth) or REQUEST type (headers, query params). Returns IAM policy. Result can be cached.
Cognito User Pool Authorizer
REST APIs only natively. HTTP APIs support Cognito via JWT authorizer.
JWT Authorizer
HTTP APIs only. Validates JWT tokens from any OIDC-compliant identity provider including Cognito.
IAM Authorization
Uses SigV4 signing. Supports resource policies for cross-account access.
API Caching
REST APIs only. Not available for HTTP APIs or WebSocket APIs.
Request/Response Transformation (Mapping Templates)
REST APIs only. Uses Apache Velocity Template Language (VTL). Transforms payloads between client and backend.
Usage Plans & API Keys
REST APIs only natively. API keys are for metering/identification, NOT authentication.
Canary Deployments
REST APIs support canary release deployments. Route a percentage of traffic to a new stage configuration.
AWS WAF Integration
Attach WAF Web ACLs to REST API stages for protection against common web exploits.
AWS X-Ray Tracing
Enable active tracing on REST API stages. Traces requests end-to-end through API Gateway to Lambda. Does NOT automatically trace within application code — SDK instrumentation required.
CloudWatch Metrics & Logging
Access logs and execution logs available. Metrics include 4XXError, 5XXError, Count, Latency, IntegrationLatency, CacheHitCount, CacheMissCount.
Private APIs (VPC Endpoint)
REST APIs can be made private using VPC Interface Endpoints. Accessible only from within VPC or connected networks.
Edge-Optimized Endpoint
Uses CloudFront edge locations. Best for geographically distributed clients. ACM certificate must be in us-east-1.
Regional Endpoint
Deployed in a specific region. Best for clients in the same region. Can add your own CloudFront for more control.
Mock Integration
REST APIs can return mock responses without hitting a backend. Useful for development, testing, and CORS preflight responses.
AWS Service Integration (Direct)
REST APIs can directly integrate with AWS services (DynamoDB, SQS, SNS, S3, Kinesis) without Lambda using mapping templates.
Mutual TLS (mTLS)
Supported for REST and HTTP APIs with custom domain names. Requires a truststore in S3.
Resource Policies
REST APIs support resource-based policies for cross-account access and IP-based restrictions.
VPC Link
Connect API Gateway to private resources in a VPC. REST APIs use NLB-backed VPC Links; HTTP APIs support both NLB and ALB (or any private resource via Cloud Map).
Serverless REST API
high freqThe most common pattern. API Gateway receives HTTP requests and invokes Lambda functions as the backend. Lambda proxy integration passes the entire request context to Lambda. Non-proxy integration allows VTL mapping templates for request/response transformation. Use Lambda authorizers for custom authentication logic.
Edge-Optimized API with Custom CDN Control
high freqUse a Regional API Gateway endpoint behind a custom CloudFront distribution for full control over CloudFront behaviors, caching, geo-restriction, and WAF. Edge-optimized APIs automatically use CloudFront but you lose individual CloudFront configuration control. ACM certificate for edge-optimized must be in us-east-1.
API Monitoring and Alerting
high freqEnable CloudWatch metrics and access logging on API stages. Create alarms on 5XXError rate, Latency, and 4XXError metrics. Use CloudWatch Logs Insights to analyze access logs. Note: CloudWatch provides metrics/logs but NOT distributed tracing — that requires X-Ray.
Serverless Application Model Deployment
high freqAWS SAM simplifies API Gateway + Lambda deployment using YAML templates. SAM transforms AWS::Serverless::Api and AWS::Serverless::Function resources into CloudFormation. Supports inline Swagger/OpenAPI definitions, CORS configuration, and stage variables. The preferred IaC approach for serverless APIs.
Custom Domain with TLS
high freqUse ACM to provision free SSL/TLS certificates for custom domain names on API Gateway. Edge-optimized endpoints REQUIRE the certificate to be in us-east-1. Regional endpoints use certificates from the same region. ACM auto-renews certificates — no manual renewal needed.
Infrastructure as Code API Deployment
high freqDefine API Gateway resources (AWS::ApiGateway::RestApi, AWS::ApiGatewayV2::Api) in CloudFormation templates. Use Swagger/OpenAPI body property for full API definition. Stage deployments require explicit DependsOn or deployment resources to avoid race conditions.
Direct AWS Service Integration (No Lambda)
high freqREST API Gateway can directly integrate with DynamoDB using AWS service integration type and VTL mapping templates. Eliminates Lambda cold starts and reduces cost for simple CRUD operations. Common pattern: POST /items → PutItem, GET /items/{id} → GetItem. Requires IAM role with DynamoDB permissions.
Asynchronous API with Queue Decoupling
high freqAPI Gateway directly sends messages to SQS queue, immediately returning 200 to the client. Backend processing happens asynchronously via Lambda or EC2 consumers. Solves the 29-second timeout limitation for long-running operations. Classic pattern for order processing, job submission, and event ingestion.
JWT/OAuth2 Authentication
high freqREST APIs use Cognito User Pool Authorizer natively. HTTP APIs use JWT authorizer pointing to Cognito User Pool endpoint. Cognito validates tokens and API Gateway grants/denies access. No Lambda code needed for auth. Combine with Cognito Identity Pools for AWS service access post-authentication.
Distributed Tracing
high freqEnable X-Ray active tracing on API Gateway stage. API Gateway creates a trace segment and passes the trace header to Lambda. Lambda must also have X-Ray tracing enabled. Application code within Lambda must use the X-Ray SDK to create subsegments for downstream calls. API Gateway + Lambda X-Ray alone does NOT trace calls to databases, external APIs, or other services without SDK instrumentation.
Real-Time Data Ingestion API
high freqAPI Gateway directly integrates with Kinesis PutRecord/PutRecords API using AWS service integration. Clients POST events to API Gateway which forwards to Kinesis without Lambda. High-throughput event ingestion pattern for analytics, IoT, and clickstream data.
The 29-second integration timeout is HARD and CANNOT be increased. If your backend (Lambda or HTTP) takes longer than 29 seconds, API Gateway returns HTTP 504. The solution is to make the operation asynchronous: return immediately and use SQS, SNS, or EventBridge to process in the background. Lambda's own 15-minute timeout is irrelevant if API Gateway times out first.
X-Ray tracing on API Gateway only traces the API Gateway → Lambda segment. It does NOT automatically trace calls from Lambda to DynamoDB, RDS, external HTTP services, or other AWS services. To get full end-to-end tracing, you MUST instrument application code with the AWS X-Ray SDK (aws-xray-sdk). This is the #1 tracing misconception on DVA-C02 and DOP-C02.
API keys are NOT a security/authentication mechanism. They are for identification and metering (usage plans). For actual authentication use: IAM auth (SigV4), Lambda authorizer (custom logic), Cognito User Pool authorizer, or JWT authorizer (HTTP APIs). Exam questions often present API keys as a security solution — this is always wrong.
Know the three API types and their feature differences: REST API (full features: caching, VTL mapping, usage plans, API keys, Cognito authorizer natively, request validation, WAF) vs HTTP API (cheaper, lower latency, JWT authorizer, no caching, no VTL) vs WebSocket API (persistent bidirectional, $connect/$disconnect/$default routes). If a question asks about caching or request transformation, the answer is REST API.
For edge-optimized custom domain names, the ACM certificate MUST be in us-east-1 (N. Virginia), regardless of where your API is deployed. For regional custom domain names, the certificate must be in the SAME region as the API. This is a classic trap question combining API Gateway with ACM.
X-Ray on API Gateway + Lambda only traces infrastructure segments. Tracing calls within Lambda code (to DynamoDB, external APIs, etc.) REQUIRES X-Ray SDK instrumentation in application code. No SDK = no subsegments for downstream calls.
The 29-second integration timeout is a HARD limit. Any scenario with long-running synchronous operations through API Gateway requires an asynchronous architecture: API GW → SQS/SNS → Lambda (async processing) + polling or callbacks.
REST API vs HTTP API: Only REST API supports caching, VTL mapping templates, usage plans/API keys, WAF, and Cognito User Pool authorizer natively. HTTP API is cheaper but lacks these features. Match the question requirement to the correct API type.
Stage variables in API Gateway act like environment variables for stages. They can parameterize Lambda function ARNs, HTTP endpoints, and mapping templates. This enables a single API definition to point to different backends per stage (dev/test/prod) without redeployment of the API definition.
Lambda proxy integration vs Lambda non-proxy integration: Proxy passes the ENTIRE request (headers, body, query params, path params, context) as a structured event object to Lambda, and Lambda must return a specific response format. Non-proxy uses VTL mapping templates to transform request/response — more control but more complexity. Most modern serverless apps use proxy integration.
Throttling hierarchy matters: Account-level default (10,000 RPS) → Stage-level throttling → Method-level throttling → Usage plan throttling per API key. More specific throttling overrides broader throttling. When a client is throttled, they receive HTTP 429 Too Many Requests.
Private API endpoints use VPC Interface Endpoints (PrivateLink). You can restrict access using API Gateway resource policies AND/OR VPC endpoint policies. For a private API to be accessible, the VPC endpoint must have 'Enable Private DNS' configured OR you must use the VPC endpoint DNS name directly.
CloudTrail logs API MANAGEMENT calls (creating/deleting APIs, deploying stages) via the AWS management plane. CloudWatch logs APPLICATION-level API invocations (access logs, execution logs). X-Ray traces request flows. These are three distinct observability layers — exam questions test whether you know which tool to use for which purpose.
CORS must be enabled on API Gateway when a browser-based client from a different origin calls the API. For Lambda proxy integration, the Lambda function must return the appropriate CORS headers (Access-Control-Allow-Origin, etc.) in its response. For non-proxy integration, configure CORS headers in the method response. API Gateway has a built-in CORS configuration helper for HTTP APIs.
WebSocket APIs maintain persistent connections and use routes based on a 'route selection expression' (e.g., $request.body.action). The @connections API allows the backend to push messages to connected clients using the connection ID. Store connection IDs in DynamoDB to enable server-initiated messaging — the classic WebSocket + DynamoDB + Lambda pattern.
Canary releases on REST APIs allow you to send a percentage of traffic to a new deployment while keeping the rest on the current deployment. This enables safe rollouts. The canary stage variables can be different from the production stage variables, allowing testing of new Lambda versions or configurations.
Common Mistake
Enabling X-Ray tracing on API Gateway and Lambda gives you complete end-to-end distributed tracing of your entire application, including all downstream calls to databases and external services.
Correct
X-Ray tracing on API Gateway traces only the API Gateway → Lambda invocation segment. Lambda's X-Ray integration traces the Lambda execution environment. However, calls from within your Lambda code to DynamoDB, RDS, external HTTP APIs, or other services are NOT automatically traced. You MUST use the AWS X-Ray SDK in your application code to create subsegments for any downstream calls you want to trace.
This is the #1 tracing misconception tested on DVA-C02 and DOP-C02. The trap is thinking that enabling X-Ray at the infrastructure level (API Gateway + Lambda console toggle) is sufficient. Remember: X-Ray = Infrastructure tracing (automatic) + SDK instrumentation (manual, required for full trace). CloudTrail does NOT provide application-level tracing at all.
Common Mistake
API keys provide authentication and security for API Gateway endpoints, protecting them from unauthorized access.
Correct
API keys are an identification and metering mechanism, NOT an authentication or security mechanism. Anyone who obtains an API key can use it. For real security, use IAM authorization (SigV4 signatures), Lambda authorizers (custom token/request validation), Cognito User Pool authorizers, or JWT authorizers. API keys are used WITH usage plans to track and throttle consumption per client/application.
Exam questions frequently present API keys as a security solution. The correct answer will always involve IAM, Lambda authorizers, or Cognito for authentication. API keys answer 'who is calling?' for billing/metering, not 'are they allowed to call?'
Common Mistake
HTTP APIs and REST APIs have the same feature set — HTTP APIs are just a newer, cheaper version of REST APIs.
Correct
HTTP APIs are fundamentally different and deliberately limited. HTTP APIs do NOT support: response/request caching, VTL mapping templates, request/response transformation, usage plans, API keys, per-method throttling, Cognito User Pool authorizer (uses JWT authorizer instead), AWS service proxy integrations, or WAF at the API level. HTTP APIs are best for simple Lambda/HTTP proxy use cases where you need low cost and low latency. REST APIs are required for any advanced features.
Exam scenarios will describe a requirement that only REST API supports (e.g., 'cache API responses' or 'transform the request payload before sending to Lambda') — the correct answer is REST API, not HTTP API. Knowing this feature matrix is critical for SAA-C03 and DVA-C02.
Common Mistake
API Gateway can handle requests that take up to Lambda's maximum timeout of 15 minutes, since Lambda is the backend.
Correct
API Gateway has its own hard integration timeout of 29 seconds, completely independent of Lambda's timeout setting. Even if Lambda is configured for 15 minutes, API Gateway will return HTTP 504 Gateway Timeout after 29 seconds. This is a hard limit that CANNOT be increased. For long-running operations, use asynchronous patterns: API Gateway → SQS/SNS → Lambda, or return a job ID immediately and poll for results.
This is one of the most common architecture failure points in serverless designs. The 29-second limit is a hard constraint that forces architectural decisions. On exams, if a scenario mentions operations taking more than 29 seconds through an API, the answer involves asynchronous decoupling.
Common Mistake
Caching in API Gateway works the same way for REST APIs and HTTP APIs.
Correct
Caching is ONLY available for REST APIs. HTTP APIs have no built-in caching capability. If you need caching with HTTP APIs, you must place CloudFront in front of the HTTP API and configure CloudFront caching behaviors. The exam may present a scenario asking how to add caching to an HTTP API — the answer is CloudFront, not API Gateway cache settings.
The REST API vs HTTP API feature distinction is heavily tested. Caching is a key differentiator. Remember: REST API = Rich features including cache. HTTP API = Lean, cheap, no cache.
Common Mistake
CloudTrail can be used to trace and debug application-level API call flows and identify which Lambda function caused an error in a request.
Correct
CloudTrail records management-plane API calls (creating/modifying/deleting API Gateway resources, IAM changes, etc.) and data-plane events for auditing purposes. It does NOT provide request-level application tracing, latency measurements, or debugging of business logic. For application-level tracing, use X-Ray. For request/response logging and latency metrics, use CloudWatch access logs and execution logs.
CloudTrail vs CloudWatch vs X-Ray is a classic three-way confusion tested across multiple exams. Mnemonic: CloudTrail = WHO did WHAT to AWS resources (audit trail). CloudWatch = WHAT is happening with metrics and logs (operations). X-Ray = HOW requests flow through your application (distributed tracing).
REST = Rich, Edge, Secure, Transformable (has caching, edge-optimized, WAF, VTL mapping). HTTP = Humble, Tiny, Cheap, Proxy-only (no cache, no VTL, lower cost).
29-second timeout rule: 'APIs die at 29 — go async to stay alive.' Any operation over 29 seconds needs SQS/SNS decoupling.
API Key ≠ Security: 'Keys open doors but don't check IDs.' Use IAM/Cognito/Lambda Authorizer to actually verify identity.
ACM Certificate Region Rule: 'Edge goes East (us-east-1), Regional stays local.' Edge-optimized = cert in us-east-1, Regional = cert in same region.
X-Ray tracing layers: 'Infrastructure tracing is FREE (toggle on), Application tracing costs CODE (SDK required).' Toggle on API GW + Lambda = infra only. SDK in code = full trace.
Throttling returns 429, Timeout returns 504, Auth failure returns 403, Bad request returns 400. Remember: 4xx = client problem, 5xx = server/integration problem.
CertAI Tutor · SAA-C03, DVA-C02, DOP-C02, AIF-C01, SAP-C02, DEA-C01, CLF-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns