
Cargando...
Choose the right API Gateway flavor — REST for power, HTTP for speed, WebSocket for real-time
Three API types, three use cases — knowing the difference separates pass from fail
| Feature | API Gateway REST Feature-rich, enterprise-grade REST APIs | HTTP Faster, cheaper, simpler HTTP APIs | WebSocket Persistent, bidirectional real-time connections |
|---|---|---|---|
Primary Use Case If the scenario mentions 'real-time bidirectional', always pick WebSocket. If it mentions 'cheaper/faster Lambda proxy', pick HTTP API. | Full-featured REST APIs requiring advanced controls (auth, caching, request validation, WAF) | Low-latency, cost-optimized APIs for Lambda and HTTP backends | Real-time, persistent two-way communication (chat, gaming, live dashboards) |
Protocol WebSocket is the ONLY stateful option. REST and HTTP APIs are both stateless. | HTTP/HTTPS (stateless request/response) | HTTP/HTTPS (stateless request/response) | WebSocket (ws:// or wss://) — stateful persistent connection |
Relative Cost HTTP API is the cost-optimized choice. WebSocket has a unique dual-billing model (connection time + message count). | Most expensive — highest per-million-request pricing | Up to ~70% cheaper than REST API for equivalent workloads | Billed on connection minutes AND messages — different pricing model entirely |
Latency HTTP API wins on latency for request/response workloads. | Higher latency due to richer feature processing pipeline | Lower latency — streamlined, minimal processing overhead | Initial handshake latency; subsequent messages have very low latency over persistent connection |
Lambda Integration HTTP API supports payload format v2.0 by default (simpler, smaller). REST API defaults to v1.0. This is a common trap — Lambda function code may need updating when migrating. | Lambda Proxy Integration and Lambda Custom Integration (supports both) | Lambda Proxy Integration only (simplified payload format v1.0 and v2.0) | Lambda integration per route ($connect, $disconnect, $default, custom routes) |
Authorization / Auth HTTP API has NATIVE JWT/OIDC authorization — no Lambda Authorizer needed for JWT. REST API requires a Lambda Authorizer or Cognito User Pool Authorizer for JWT. WebSocket auth only happens at $connect. | IAM, Cognito User Pools, Lambda Authorizer (TOKEN and REQUEST types), Resource Policies | IAM, Cognito JWT Authorizer, Lambda Authorizer (REQUEST type only), OIDC/OAuth 2.0 JWT natively | IAM, Lambda Authorizer (on $connect route only), Cognito (via Lambda Authorizer) |
API Keys & Usage Plans CRITICAL: If the scenario requires API Keys or Usage Plans for throttling/monetization, you MUST use REST API. This is a frequent exam trap. | Fully supported — API Keys, Usage Plans, throttling per key | NOT supported — no API Keys or Usage Plans | NOT supported — no API Keys or Usage Plans |
Request/Response Validation Request validation (reducing unnecessary Lambda invocations) is a REST API-only feature. Common exam scenario. | Supported — validate request body, headers, query strings against JSON Schema | NOT supported natively | NOT supported natively |
Response Caching Caching is REST API exclusive. If a scenario mentions reducing backend calls via caching, REST API is the answer. | Supported — configurable TTL, cache per stage, cache invalidation | NOT supported | NOT applicable |
WAF (Web Application Firewall) Integration Both REST and HTTP APIs support WAF. WebSocket does not — important for security scenario questions. | Supported — attach AWS WAF WebACL to REST API stage | Supported — WAF can be attached to HTTP API | NOT supported natively with WAF |
VPC Link / Private Integration HTTP API VPC Link (v2) supports BOTH NLB and ALB. REST API VPC Link (v1) supports NLB only. This is tested. | VPC Link for NLB (Network Load Balancer) — VPC Link v1 | VPC Link for NLB and ALB (Application Load Balancer) — VPC Link v2 | VPC Link supported (v1) |
Custom Domain Names Edge-optimized custom domains are REST API only (uses CloudFront under the hood). | Supported — edge-optimized and regional | Supported — regional only | Supported — regional only |
Endpoint Types Private endpoints (accessible only within VPC via VPC Endpoint) are REST API only. Edge-optimized is also REST API only. | Edge-Optimized, Regional, Private | Regional only | Regional only |
Stages & Deployments HTTP API supports auto-deploy, making CI/CD simpler. REST API requires explicit deployment actions. | Explicit deployment to named stages required (dev, prod, etc.) | Auto-deploy option available; stage variables supported | Explicit deployment to named stages required |
Canary Deployments Canary/blue-green deployment at API Gateway level is REST API only. | Supported — canary release at stage level | NOT supported natively | NOT supported natively |
Mutual TLS (mTLS) mTLS is available for both REST and HTTP APIs but not WebSocket. | Supported | Supported | NOT supported |
CORS Configuration HTTP API has the easiest CORS setup. REST API CORS is a common pain point and exam topic. | Manual configuration required (set headers in method response or Lambda) | Built-in CORS configuration — simple console/API setup | NOT applicable (WebSocket uses different handshake) |
Data Transformation (Mapping Templates) VTL Mapping Templates are REST API exclusive. Used to transform payloads without Lambda. Heavily tested in DVA-C02. | Supported — Velocity Template Language (VTL) for request/response transformation | NOT supported | NOT supported |
Connection Management (WebSocket) In WebSocket APIs, the backend uses the @connections management API endpoint to send messages TO connected clients. The connectionId is passed to Lambda on $connect. | NOT applicable | NOT applicable | Manages connection IDs; backend calls @connections API to push messages to clients |
Routes (WebSocket-specific) $connect and $disconnect are special lifecycle routes. Authorization ONLY happens at $connect. After connection, no re-auth per message. | NOT applicable | NOT applicable | $connect (on connection), $disconnect (on close), $default (fallback), custom routes based on message content |
Supported Backend Integrations REST API supports direct AWS service integrations most broadly (e.g., DynamoDB, SQS, SNS directly without Lambda). | Lambda, HTTP endpoints, AWS services (direct), Mock, VPC Link | Lambda, HTTP endpoints, VPC Link, AWS services (limited) | Lambda, HTTP endpoints, AWS services (direct), Mock |
Throttling & Quotas Default account-level throttling limits apply across all API types. REST API allows per-method throttling overrides — HTTP API allows per-route throttling. | Account-level and per-stage/method throttling; default 10,000 RPS burst, 5,000 RPS steady state (account default, adjustable) | Account-level throttling applies; per-route throttling supported | Connection and message throttling applies at account and API level |
Monitoring & Logging X-Ray tracing is supported for REST and HTTP APIs. WebSocket has limited X-Ray support. REST API provides both execution logs AND access logs. | CloudWatch Metrics, CloudWatch Logs (execution + access), X-Ray tracing supported | CloudWatch Metrics, CloudWatch Logs (access logging), X-Ray tracing supported | CloudWatch Metrics, CloudWatch Logs (execution + access), X-Ray NOT supported natively |
OpenAPI / Swagger Support Both REST and HTTP APIs support OpenAPI for definition and import. REST API has broader OpenAPI extension support. | Full OpenAPI 2.0 and 3.0 import/export | OpenAPI 3.0 import/export supported | NOT applicable (different protocol model) |
Summary
Use REST API when you need the full feature set: caching, WAF, API Keys/Usage Plans, request validation, VTL mapping templates, canary deployments, or private/edge-optimized endpoints. Use HTTP API when you want lower cost and latency for Lambda or HTTP backends, native JWT/OIDC auth, or simpler CORS — and don't need REST API's advanced features. Use WebSocket API exclusively for real-time, persistent, bidirectional communication scenarios like chat applications, live notifications, collaborative tools, or streaming dashboards.
🎯 Decision Tree
Need real-time bidirectional messaging? → WebSocket API. Need API Keys/Usage Plans OR response caching OR VTL mapping templates OR request validation OR canary deployments OR private endpoint? → REST API. Need cheapest/fastest Lambda or HTTP integration with JWT auth? → HTTP API. Need VPC Link to ALB (not just NLB)? → HTTP API (VPC Link v2). Need edge-optimized or private endpoint? → REST API only.
API Keys and Usage Plans are EXCLUSIVE to REST API — if a scenario requires throttling per customer/API key or monetization via usage tiers, REST API is the ONLY answer. HTTP and WebSocket APIs do not support API Keys at all.
API Gateway integration timeout is 29 seconds for REST API and 30 seconds for HTTP API — if a Lambda function or backend takes longer, the client receives a 504 Gateway Timeout even if Lambda eventually succeeds. For long-running operations, use asynchronous patterns: invoke Lambda async, return 202 Accepted, and use SQS/SNS/EventBridge + polling or WebSocket for result delivery.
VTL Mapping Templates (data transformation without Lambda) are REST API ONLY — if a scenario asks how to transform a request/response payload between API Gateway and a backend WITHOUT using Lambda, the answer is always REST API with a Mapping Template using Velocity Template Language (VTL).
WebSocket API authorization ONLY occurs at the $connect route — once connected, subsequent messages are NOT re-authorized at the API Gateway level. If you need per-message authorization, implement it inside your Lambda function logic.
HTTP API natively supports JWT/OIDC authorization (Cognito, Auth0, Okta, etc.) WITHOUT a Lambda Authorizer — REST API requires a Lambda Authorizer or Cognito User Pool Authorizer to validate JWTs. On cost/simplicity questions, HTTP API wins for JWT-based auth.
HTTP API VPC Link (v2) supports both ALB and NLB as targets. REST API VPC Link (v1) supports NLB ONLY. If a scenario requires private integration to an Application Load Balancer, HTTP API is required.
Response caching (reducing calls to backend, improving latency, reducing cost) is REST API ONLY with configurable TTL up to 3600 seconds. Cache can be invalidated per-request with the Cache-Control: max-age=0 header (if cache invalidation is enabled on the stage).
In WebSocket APIs, to send a message FROM the server/backend TO a connected client, your Lambda function must call the API Gateway Management API (@connections endpoint) using the connectionId. This is the PostToConnection API call — not a standard Lambda return value.
The #1 exam trap: Assuming HTTP API is just a 'cheaper REST API' with the same features. HTTP API is missing critical features that REST API has: NO API Keys/Usage Plans, NO response caching, NO VTL Mapping Templates, NO request validation, NO canary deployments, NO edge-optimized endpoints, NO private endpoints. Exam questions will describe a scenario requiring one of these features and offer both HTTP API and REST API as options — always check for these REST-API-exclusive features before choosing HTTP API.
CertAI Tutor · DVA-C02 · 2026-02-22
Services
Comparisons
Guides & Patterns