API Gateway

Amazon API Gateway Development

Expert guidance for building, managing, governing, and operating APIs with Amazon API Gateway. Covers REST APIs (v1), HTTP APIs (v2), and WebSocket APIs.

How to Use This Skill

When answering API Gateway questions:

1. Read the relevant reference file(s) before responding, do not rely solely on this summary
2. For tasks spanning multiple concerns (e.g., "private API with mTLS and custom domain"), read all relevant references
3. When the user needs IaC templates, consult references/sam-cloudformation.md or references/sam-service-integrations.md and provide complete, working SAM/CloudFormation YAML
4. Always mention relevant pitfalls and limits that affect the user's design

Quick Decision: Which API Type?

Choose the right API type first. This decision affects every downstream choice.

REST API is the full-featured API management platform for enterprises. It provides the governance, security, monetization, and operational controls that organizations need to build, publish, and manage APIs at scale, including usage plans with per-consumer throttling and quotas, API keys, request validation, WAF integration, resource policies, caching, canary deployments, and private endpoints.

HTTP API is the lightweight, low-cost proxy optimized for simpler API workloads. It offers ~70% lower cost and lower latency but trades away the API management features. Choose HTTP API when you need a fast, lightweight proxy to Lambda or HTTP backends and don't require the enterprise controls above.

Use REST API when: you are building APIs for external consumers, partners, or multi-tenant platforms; need to enforce per-consumer rate limits and quotas; require request validation, caching, or WAF at the API layer; need private endpoints, resource policies, or canary deployments; or are building an API product with monetization and governance requirements.

Use HTTP API when: you are building lightweight APIs or simple backend proxies; cost and latency are the primary concerns; you don't need per-consumer throttling, request validation, caching, or WAF at the API layer; and native JWT authorization with OIDC/OAuth 2.0 meets your auth needs. Accept the hard 30s timeout and lack of API management features. For WAF, edge caching, or edge compute, place a CloudFront distribution in front of the HTTP API.

Use WebSocket API when you need: persistent bidirectional connections for real-time use cases (chat, notifications, live dashboards).

Instructions

Step 1: Design the API

Before implementation, gather requirements systematically. Consult references/requirements-gathering.md for the full requirements workflow covering endpoints, auth, data models, performance, security, and deployment needs.

Key design decisions:

1. API type: Use the decision table above
2. Endpoint type: Edge-optimized (default for global clients; optimizes TCP connections via CloudFront POPs but does not cache at the edge), Regional (same-region clients, or global clients needing their own CloudFront distribution for edge caching, edge compute, granular WAF control, or geo-based routing), Private (VPC-only access, REST API only — the only way to make an API non-internet-facing; HTTP API v2 has no private mode)
3. Topology: Centralized (single domain, path-based routing) vs Distributed (subdomains per service)
4. Authentication: See references/authentication.md for the decision tree

Step 2: Implement the API

Consult these references based on what you're building:

• Architecture patterns: references/architecture-patterns.md: topology, multi-tenant SaaS, hybrid workloads, private APIs, multi-region, streaming
• WebSocket API: references/websocket.md: route selection, @connections management, session management, client resilience, SAM templates, limits, multi-region
• Service integrations: references/service-integrations.md: direct AWS service integrations (EventBridge, SQS, SNS, DynamoDB, Kinesis, Step Functions, S3), HTTP proxy, mock, VTL mapping templates, binary media types, Lambda sync/async invocation
• Custom domains and routing: references/custom-domains-routing.md: base path mappings, routing rules, header-based versioning
• Security: references/security.md: mTLS (API Gateway native + CloudFront viewer mTLS), TLS policies, resource policies, WAF, HttpOnly cookies, CRL checks
• SAM/CloudFormation: references/sam-cloudformation.md: IaC patterns, OpenAPI extensions, VTL reference, binary data
• SAM service integration templates: references/sam-service-integrations.md: EventBridge, SQS, DynamoDB CRUD, Kinesis, Step Functions (REST + WebSocket) templates

Step 3: Configure Performance and Scaling

• Throttling: Account-level default is 10,000 rps / 5,000 burst (adjustable; request increases via AWS Support). Configure stage-level and method-level throttling via usage plans. See references/performance-scaling.md
• Caching (REST only): Default TTL 300s, max 3600s. Only GET methods cached by default. Max cached response 1 MB
• Edge caching (all API types): For edge caching, place a self-managed CloudFront distribution in front of a Regional API. CloudFront reduces latency, backend load, AND cost (cached responses never reach API Gateway). Also enables edge compute (CloudFront Functions, Lambda@Edge) and granular cache behaviors per path. Use a Regional endpoint, not edge-optimized, when pairing with your own CloudFront distribution
• Scaling: API Gateway scales automatically but plan the entire stack (Lambda concurrency, DynamoDB capacity)

Step 4: Set Up Observability

Always configure access logging. For REST and WebSocket APIs, also enable execution logging (ERROR level for production, INFO only for debugging). HTTP API does not support execution logging; use access logs with enhanced observability variables instead.

Consult the observability references based on what you need:

• Logging setup, log formats, retention: references/observability-logging.md
• Metrics, alarms, metric filters, X-Ray tracing: references/observability-metrics-alarms.md
• Log analysis and insights, analytics pipeline, cross-account, control plane logs: references/observability-analytics.md

Step 5: Deploy

• Use Infrastructure as Code (SAM, CDK, CloudFormation, Terraform) for production
• Canary deployments (REST only): Route a percentage of traffic to test new versions
• Blue/green deployments: Use custom domain API mappings to switch between environments with zero downtime
• Routing rules (preferred for new domains): Declarative header/path-based routing on custom domains for versioning, A/B testing, gradual rollouts, and cell-based routing
• See references/deployment.md for detailed patterns

Step 6: Apply Governance

For organization-wide API standards, see references/governance.md covering:

• Preventative controls (SCPs, IAM policies)
• Proactive controls (CloudFormation Hooks, Guard rules)
• Detective controls (AWS Config rules, EventBridge)
• Specific enforcement examples for security, observability, and management

Response Format

When responding to API Gateway questions, structure your answer as:

1. Recommendation: Lead with the recommended approach and why
2. Code: Include SAM/CloudFormation YAML or code when the user needs implementation (always read the relevant reference file first)
3. Pitfalls: Warn about relevant gotchas from the pitfalls below or from references/pitfalls.md
4. Limits: Mention any service limits that constrain the design

Troubleshooting Quick Reference

When diagnosing API Gateway errors, consult references/troubleshooting.md for detailed resolution steps. Here are the most common issues:

Critical Pitfalls

1. REST API default timeout is 29 seconds (increasable up to 300s for Regional/Private endpoints via quota request). Lambda continues running but client gets 504. Request a timeout increase, or consider async patterns (SQS, EventBridge) for better user experience on long operations
2. HTTP API hard timeout is 30 seconds. Returns {"message":"Service Unavailable"} while Lambda continues
3. /ping and /sping are reserved paths. Do not use for API resources
4. Execution log events truncated at 1,024 bytes. Use access logs for complete data
5. 413 REQUEST_TOO_LARGE is the only gateway response that cannot be customized. Use DEFAULT_4XX as a catch-all to add CORS headers for all 4xx errors including 413
6. maxItems/minItems not validated in REST API request validation
7. Root-level security in OpenAPI is ignored. Must set per-operation
8. JWT authorizer public keys cached 2 hours. Account for this in key rotation
9. Management API rate limit: 10 rps / 40 burst. Heavy automation can hit this
10. Always redeploy REST API after configuration changes. Changes don't take effect until deployed
11. Edge-optimized endpoints do NOT cache at the edge — they only optimize TCP connections via CloudFront POPs. If you need edge caching, edge compute (CloudFront Functions, Lambda@Edge), or granular CloudFront control, use a Regional API with your own CloudFront distribution instead
12. "Internal-only / not internet-facing" requires a private REST API — HTTP API (v2) has NO private endpoint mode. An HTTP API with IAM (SigV4) auth is authenticated but its endpoint DNS is still publicly resolvable — authenticated ≠ off-the-internet. To keep traffic entirely on the AWS network, use a REST API (v1) with endpoint_type = PRIVATE, an execute-api interface VPC endpoint, and a resource policy that allows only the approved aws:SourceVpce (and denies otherwise). Decide this at design time from the requirement — retrofitting an API-type swap after build is costly. If a requirement mentions "internal", "private", "no public access", or "VPC-only", branch to private REST API immediately.
13. A private API cannot be smoke-tested from outside the VPC — its DNS only resolves through the interface VPC endpoint. Live end-to-end tests must run from an in-VPC runner (SSM/bastion host, in-VPC CI/CodeBuild) or over VPN/Direct Connect. Plan the test harness accordingly, or exercise the backend (e.g. the state machine/Lambda) directly for functional verification.

For additional pitfalls (header handling, URL encoding, caching charges, canary deployments, usage plans), see references/pitfalls.md.

IaC Framework Selection

Default: CDK TypeScript

Override syntax:

• "use SAM" → Generate SAM/CloudFormation YAML templates
• "use CloudFormation" → Generate CloudFormation YAML templates
• "use Terraform" → Generate Terraform HCL

When not specified, ALWAYS use CDK TypeScript.

Error Scenarios

MCP Server Unavailable

• Inform user: "AWS Serverless MCP not responding"
• Ask: "Proceed without MCP support?"
• DO NOT continue without user confirmation

Service Limits Quick Reference

See references/service-limits.md for the complete table. Most numeric quotas below are default values and adjustable; check with your AWS account team and the latest quotas page before using them for architectural decisions. Key limits: