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)
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