API Gateway
AWS LabsOfficialPublished by AWS Labs
- Skill
- Tool integration
- Cloud and DevOps
- Apache-2.0
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides comprehensive support for Amazon API Gateway, covering the full lifecycle of API development. It helps users choose between REST, HTTP, and WebSocket APIs based on specific requirements like cost, latency, and management features. The skill includes guidance on architecture patterns, security configurations (including mTLS and Lambda authorizers), performance tuning, and observability. It also provides troubleshooting steps for common errors and supports IaC implementation using SAM, CloudFormation, and CDK.
What it does
- Assists in selecting the appropriate API type (REST, HTTP, or WebSocket) based on enterprise needs.
- Provides architectural patterns for multi-tenant SaaS, private APIs, and cross-account deployments.
- Offers troubleshooting workflows for common 4xx and 5xx errors, including CORS and timeout issues.
- Guides the implementation of security controls like Lambda authorizers, JWT, and mTLS.
- Generates IaC templates for API Gateway resources using SAM, CloudFormation, or CDK.
- Configures performance settings such as throttling, usage plans, and caching strategies.
When to use it
- When designing or deploying APIs on AWS using API Gateway.
- When you need to troubleshoot API Gateway errors like 403, 502, 504, or CORS failures.
- When implementing security, authentication, or authorization for serverless APIs.
- When you need to optimize API performance, scaling, or observability.
- When you require Infrastructure as Code templates for API Gateway resources.
Advantages
- Reduces development time by providing clear decision trees for API types and auth methods.
- Minimizes configuration errors by highlighting common pitfalls and service limits.
- Ensures consistent deployment practices through standardized IaC patterns.
- Simplifies complex tasks like setting up mTLS or cross-account API routing.
- Provides a structured approach to observability and logging for production readiness.
Usage examples
- “I need to build a REST API that requires per-consumer throttling and request validation. Which API type should I use?”
- The agent will recommend the REST API (v1) and explain how to configure usage plans and request validation to meet your requirements.
- “My API is returning a 504 timeout error. How can I fix this?”
- The agent will guide you through checking backend latency, suggest optimizing the integration, or explain how to request a timeout increase for Regional/Private endpoints.
- “Generate a SAM template for a private API Gateway REST API.”
- The agent will provide a complete SAM/CloudFormation YAML template configured for a private endpoint, including necessary VPC link resources.
- “How do I set up mTLS for my API Gateway?”
- The agent will explain the requirements for Regional custom domains, S3 truststore configuration, and the necessary security policies.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/awslabs/api-gateway/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip api-gateway.zip -d .agents/skills
Documentation by AWS Labs
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:
Read the relevant reference file(s) before responding, do not rely solely on this summary
For tasks spanning multiple concerns (e.g., "private API with mTLS and custom domain"), read all relevant references
When the user needs IaC templates, consult
references/sam-cloudformation.mdorreferences/sam-service-integrations.mdand provide complete, working SAM/CloudFormation YAMLAlways 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.
| Factor | REST API (v1) | HTTP API (v2) | WebSocket API |
|---|---|---|---|
| Positioning | Full API management | Low-cost proxy | Real-time bidirectional |
| Cost | Higher | ~70% cheaper | Per-message pricing |
| Latency | Higher | Lower | Persistent connection |
| Max timeout | 50ms-29s (up to 300s Regional/Private) | 30s hard limit | 29s |
| Payload | 10 MB | 10 MB | 128 KB message / 32 KB frame |
| API Management | |||
| Usage plans/API keys | Yes | No | No |
| Request validation | Yes (JSON Schema draft 4) | No | No |
| Caching | Yes (0.5-237 GB) | No | No |
| Custom gateway responses | Yes | No | No |
| VTL mapping templates | Yes | No (parameter mapping only) | Yes |
| Security & Governance | |||
| WAF | Yes | No (use CloudFront + WAF) | No |
| Resource policies | Yes | No | No |
| Private endpoints | Yes | No | No |
| mTLS | Yes (Regional custom domain only) | Yes (Regional custom domain only) | Via CloudFront viewer mTLS |
| Auth | |||
| Lambda authorizer | Yes (TOKEN + REQUEST) | Yes (REQUEST only, simple + IAM policy format) | Yes (REQUEST on $connect only) |
| JWT authorizer | No (use Cognito authorizer) | Yes (native) | No |
| Cognito authorizer | Yes (native) | Use JWT authorizer | No |
| Operations | |||
| Canary deployments | Yes | No | No |
| Response streaming | Yes | No | No |
| X-Ray tracing | Yes | No | No |
| Execution logging | Yes | No | Yes |
| Custom domain sharing | Not with WebSocket | Not with WebSocket | Not with REST/HTTP |
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:
API type: Use the decision table above
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)
Topology: Centralized (single domain, path-based routing) vs Distributed (subdomains per service)
Authentication: See
references/authentication.mdfor 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, streamingWebSocket API:
references/websocket.md: route selection, @connections management, session management, client resilience, SAM templates, limits, multi-regionService 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 invocationCustom domains and routing:
references/custom-domains-routing.md: base path mappings, routing rules, header-based versioningSecurity:
references/security.md: mTLS (API Gateway native + CloudFront viewer mTLS), TLS policies, resource policies, WAF, HttpOnly cookies, CRL checksSAM/CloudFormation:
references/sam-cloudformation.md: IaC patterns, OpenAPI extensions, VTL reference, binary dataSAM 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.mdCaching (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.mdMetrics, alarms, metric filters, X-Ray tracing:
references/observability-metrics-alarms.mdLog 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.mdfor 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:
Recommendation: Lead with the recommended approach and why
Code: Include SAM/CloudFormation YAML or code when the user needs implementation (always read the relevant reference file first)
Pitfalls: Warn about relevant gotchas from the pitfalls below or from
references/pitfalls.mdLimits: 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:
| Error | Most Common Cause | Quick Fix |
|---|---|---|
| 400 Bad Request | Protocol mismatch (HTTP/HTTPS) with ALB | Match protocol to listener type |
| 401 Unauthorized | Wrong token type (ID vs access) or missing identity sources | Check token type matches scope config; verify all identity sources sent |
| 403 Missing Auth Token | Stage name in URL when using custom domain | Remove stage name from URL path |
| 403 from VPC | Private DNS on VPC endpoint intercepts ALL API calls | Use custom domain names for public APIs |
| 403 Access Denied | Resource policy + auth type mismatch or missing redeployment | Review policy, check auth type, redeploy API |
| 403 mTLS | Certificate issuer not in truststore or weak signature algorithm | Verify CA in truststore, use SHA-256+ |
| 429 Too Many Requests | Account/stage/method throttle limits exceeded | Implement jittered exponential backoff; request limit increase |
| 500 Internal Error | Missing Lambda invoke permission (especially with stage variables) | Add resource-based policy to Lambda function |
| 502 Bad Gateway | Lambda response not in required proxy format | Return {statusCode, headers, body} from Lambda |
| 504 Timeout | Backend exceeds 29s (REST, increasable) or 30s (HTTP, hard). HTTP API body says "Service Unavailable" but status is 504 | Optimize backend, request timeout increase (REST Regional/Private), or switch to async invocation |
| CORS errors | Missing CORS headers on Gateway Responses (4XX/5XX) | Add CORS headers to DEFAULT_4XX and DEFAULT_5XX gateway responses |
| SSL/PKIX errors | Incomplete certificate chain on backend | Provide full cert chain; use insecureSkipVerification only for testing |
Critical Pitfalls
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
HTTP API hard timeout is 30 seconds. Returns
{"message":"Service Unavailable"}while Lambda continues/pingand/spingare reserved paths. Do not use for API resourcesExecution log events truncated at 1,024 bytes. Use access logs for complete data
413
REQUEST_TOO_LARGEis the only gateway response that cannot be customized. Use DEFAULT_4XX as a catch-all to add CORS headers for all 4xx errors including 413maxItems/minItemsnot validated in REST API request validationRoot-level
securityin OpenAPI is ignored. Must set per-operationJWT authorizer public keys cached 2 hours. Account for this in key rotation
Management API rate limit: 10 rps / 40 burst. Heavy automation can hit this
Always redeploy REST API after configuration changes. Changes don't take effect until deployed
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
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:
| Resource | REST API | HTTP API | WebSocket |
|---|---|---|---|
| Payload size | 10 MB | 10 MB | 128 KB |
| Integration timeout | 50ms-29s (up to 300s Regional/Private) | 30s hard | 29s |
| APIs per region | 600 Regional/Private; 120 Edge-optimized | 600 | 600 |
| Stages per API | 10 | 10 | 10 |
| Routes/resources per API | 300 | 300 | 300 |
| Custom domains (public) | 120 | 120 | 120 |
| Account throttle | 10,000 rps / 5,000 burst | Same | Same (shared quota) |
| API keys per region | 10,000 | N/A | N/A |
| Usage plans per region | 300 | N/A | N/A |
| Cache sizes | 0.5 GB - 237 GB | N/A | N/A |
Files
- ATTRIBUTION.mdAdded by AutoGineer908 B
- LICENSELicence file added by AutoGineer9.9 KiB
- NOTICELicence file added by AutoGineer89 B
- SKILL.md19.3 KiB
- references/architecture-patterns.md19.0 KiB
- references/authentication.md9.4 KiB
- references/custom-domains-routing.md8.5 KiB
- references/deployment.md14.9 KiB
- references/governance.md9.8 KiB
- references/observability-analytics.md4.2 KiB
- references/observability-logging.md11.2 KiB
- references/observability-metrics-alarms.md5.5 KiB
- references/performance-scaling.md9.0 KiB
- references/pitfalls.md2.0 KiB
- references/requirements-gathering.md14.8 KiB
- references/sam-cloudformation.md7.8 KiB
- references/sam-service-integrations.md22.5 KiB
- references/security.md18.2 KiB
- references/service-integrations.md24.4 KiB
- references/service-limits.md11.5 KiB
- references/troubleshooting.md14.5 KiB
- references/websocket.md7.4 KiB
references/troubleshooting.md
Troubleshooting Guide
Table of Contents
General Approach
HTTP 400 Bad Request
HTTP 401 Unauthorized
HTTP 403 Forbidden
HTTP 413 Request Too Large
HTTP 429 Too Many Requests
HTTP 500 Internal Server Error
HTTP 502 Bad Gateway
HTTP 504 Gateway Timeout
SSL/TLS and Certificate Issues
CORS Errors
Lambda Integration Errors
VPC and Private API Issues
Mapping Template Errors
WebSocket Issues
SQS Integration Errors
Useful Debugging Commands
General Approach
Enable execution logging (REST/WebSocket only — HTTP API supports access logging only) AND access logging before troubleshooting
Use
x-amzn-requestidresponse header to trace specific requests in execution logsCheck enhanced observability variables in access logs to identify which phase failed (see
references/observability-logging.md)Use CloudWatch Logs Insights for pattern analysis across many requests
Request Phase Order
WAF -> Authenticate -> Authorizer -> Authorize -> Integration
Each phase exposes $context.{phase}.status, $context.{phase}.latency, $context.{phase}.error in access logs.
HTTP 400 Bad Request
Protocol Mismatch with ALB
Cause: Sending HTTP to TLS listener or HTTPS to non-TLS listener
Fix: Match protocol (HTTP/HTTPS) to ALB listener type
ALB Desync Mode
Cause: ALB desync mitigation set to "strictest" rejects non-RFC-compliant requests
Fix: Switch to "defensive" mode or ensure requests are RFC-compliant
Invalid Request Body
Cause: Request body fails JSON Schema validation (REST API request validator)
Fix: Check model definition; note
maxItems/minItemsare NOT validated
HTTP 401 Unauthorized
Lambda Authorizer
Missing token: Token source header not sent or wrong header name
Regex mismatch: Token fails the Token Validation regex pattern
Missing identity sources: Required headers/query strings not sent (REQUEST type)
Fix: Verify header name, regex pattern, and all identity sources
Cognito
Wrong token type: Use ID token when no scopes configured; access token when scopes configured
Expired token: Check token expiration
User pool mismatch: Verify user pool ID in authorizer config
HTTP 403 Forbidden
"Missing Authentication Token"
Cause: Stage name in URL when using custom domain (stage already mapped)
Fix: Remove stage name from URL path
Also occurs when: hitting nonexistent resource path, default endpoint disabled
Note: This 403 behavior is REST API specific. HTTP API returns 404 Not Found for nonexistent paths (Gateway response types)
From VPC (All APIs Fail)
Cause: Private DNS on
execute-apiVPC endpoint routes ALL API calls through the endpointFix: Use custom domain names for public APIs, or disable private DNS
Lambda Authorizer with {proxy+}
Cause: Authorizer returns IAM policy with path-specific resource ARN. When caching is enabled, that policy is reused for requests to different proxy paths, which are denied by the cached partial policy (Configure Lambda authorizer caching)
Fix: Return wildcard resource ARN (
*/*) in policy, or disable authorizer caching
Cross-Account IAM
Cause: Missing either IAM policy (caller account) OR resource policy (API account)
Fix: REST API: configure both. HTTP API: use
sts:AssumeRole(no resource policies)
Resource Policy
Common causes:
IP not in allow list or is in deny list
HTTP method/resource not covered by policy
Auth type mismatch (e.g., IAM auth expected but not provided)
API not redeployed after policy change
Wrong condition key (
aws:SourceVpcevsaws:SourceVpc)
mTLS 403
Certificate issuer not in truststore
Insecure signature algorithm (must be SHA-256+)
Self-signed certificates with insufficient key size (RSA-2048+ or ECDSA-256+ required)
WAF Filtered
waf-status: 403in access logsCheck WAF rules and web ACL configuration
HTTP 413 Request Too Large
Cause: Payload exceeds 10 MB limit (REST and HTTP API) (API Gateway quotas)
REQUEST_TOO_LARGE is the only gateway response that cannot be customized. Use
DEFAULT_4XXas a catch-all to add CORS headers for all 4xx errors including 413For larger payloads: Use S3 presigned URLs for direct client upload/download
HTTP 429 Too Many Requests
"429 Too Many Requests"
Cause: API rate or burst limits exceeded at account, stage, or method level
Fix: Implement retries with jittered exponential backoff; request limit increase
"Limit Exceeded"
Cause: API quota limits exceeded (daily/weekly/monthly)
Fix: Request quota extension via usage plan or AWS Support
HTTP 500 Internal Server Error
Lambda Stage Variable Permission
Cause: Missing Lambda invoke permission when function referenced via stage variable
Fix: Add resource-based policy:
aws lambda add-permission --function-name <fn> --statement-id apigateway --action lambda:InvokeFunction --principal apigateway.amazonaws.com --source-arn <api-arn>(Lambda permissions for API Gateway)
VPC Link Issues
VPC link in "Failed" state
Unhealthy NLB targets
Security group blocks (port 443 TCP)
NACLs blocking traffic
TLS certificate mismatch on backend
Fix: Check VPC link status, NLB target health, security groups, backend TLS chain
Lambda Authorizer Malformed Response
Cause: Lambda authorizer returns invalid JSON, missing
principalId, or policy exceeding ~8 KB. API Gateway returns 500 (not 401/403) — commonly mistaken for a backend issue (Authorizer output format)Fix: Check execution logs for authorizer errors; verify response includes
principalIdand validpolicyDocument
General Lambda Integration
Missing Lambda invoke permissions
Lambda throttled (concurrency limit)
Incorrect status code mapping (non-proxy integration)
Fix: Add permissions, implement backoff, configure correct mappings
HTTP 502 Bad Gateway
Lambda Proxy Integration
Cause: Lambda response not in required format
REST API / payload format 1.0 (response format):
{
"statusCode": 200,
"headers": { "Content-Type": "application/json" },
"body": "{\"key\": \"value\"}",
"isBase64Encoded": false
}statusCodemust be integer,bodymust be string,headersmust be objectHTTP API payload format 2.0 is more flexible (response format):
bodycan be string or object (auto-serialized to JSON), a bare string return is treated as 200 body, andcookiesarray is supported for Set-Cookie headersAlso check Lambda permissions and package file permissions
HTTP 504 Gateway Timeout
REST API
Default: 29 seconds integration timeout (increasable up to 300s for Regional/Private via quota request)
Lambda continues running but client receives 504
HTTP API
30 seconds hard limit (not increasable)
Returns HTTP 504 while Lambda continues (Troubleshoot 504 errors)
Diagnosis
Check
IntegrationLatencymetric for spikesUse CloudWatch Logs Insights to identify slow requests
Enable X-Ray tracing for detailed latency breakdown (REST API only). For HTTP API, enable X-Ray in Lambda functions and correlate via
$context.integration.requestId
Fixes
Optimize Lambda: increase memory, reduce cold starts, use provisioned concurrency
Check backend health and response times
For REST API Regional/Private: request timeout increase up to 300s via AWS Support
For better UX or operations exceeding max timeout: consider async patterns (SQS, EventBridge, Step Functions): acknowledge immediately, process in background
SSL/TLS and Certificate Issues
PKIX Path Building Failed
Cause: Incomplete certificate chain, unsupported CA, or self-signed cert on backend
Fix: Provide complete certificate chain on backend; use
insecureSkipVerification=truefor testing only
General SSLEngine Problem
Unsupported CA, expired certificate, invalid chain, unsupported cipher suite
Fix: Verify CA support, check expiry, ensure valid chain. RSA keys 2048-4096 bits and ECDSA keys are supported
VPC Link TLS
NLB TLS listener terminates TLS at NLB; TCP listener passes through
Fix: Use TCP listener for end-to-end TLS; TLS listener for NLB-terminated TLS
Wrong Certificate Returned
Cause: DNS record points to stage URL instead of API Gateway domain name target
Fix: Point DNS to correct API Gateway domain name
mTLS Certificate Conflicts
Multiple CAs with same subject in truststore
Fix: Clean up truststore, remove duplicate/conflicting CA certificates
CORS Errors
Missing CORS Headers on Error Responses
Cause: Gateway responses (4XX/5XX) bypass integration and don't include CORS headers
Fix: Add CORS headers to
DEFAULT_4XXandDEFAULT_5XXgateway responses
Proxy Integration Missing CORS
Cause: API Gateway doesn't add CORS headers in proxy integration
Fix: Lambda/backend must return
Access-Control-Allow-Originand other CORS headers
Private API Preflight Failure
Cause:
x-apigw-api-idheader triggers preflight requests that failFix: Use
Hostheader instead ofx-apigw-api-id
Lambda Integration Errors
"Invalid permissions on Lambda function"
Fix (console): Re-save Lambda integration to auto-add permissions
Fix (CLI):
aws lambda add-permission --function-name <fn> --statement-id apigateway --action lambda:InvokeFunction --principal apigateway.amazonaws.com --source-arn <method-arn>Fix (CloudFormation): Add
AWS::Lambda::Permissionresource
Lambda Authorizer Permission Error
Create IAM role with
lambda:InvokeFunctionand set as Lambda Invoke Role on the authorizer
Async Invocation
REST API: Set
X-Amz-Invocation-Type: 'Event'in Integration Request HTTP HeadersHTTP API: Not directly supported. Use proxy Lambda that invokes target Lambda asynchronously
VPC and Private API Issues
Connection Checklist
Resource policy allows VPC endpoint or VPC
VPC endpoint policy allows the API
Security groups allow TCP 443 inbound
DNS resolution works (check private DNS setting)
Invoke URL Formats (Without Private DNS)
Route 53 alias to VPC endpoint
VPC endpoint public DNS +
HostheaderVPC endpoint public DNS +
x-apigw-api-idheader
On-Premises DNS Resolution
Create Route 53 Resolver inbound endpoint in VPC
Configure on-prem DNS forwarder to forward
amazonaws.comqueries to Resolver
Mapping Template Errors
"Invalid mapping expression specified"
Cause:
{proxy+}path variable needs URL path parameter mappingFix: Define URL path parameter
proxymapped frommethod.request.path.proxy
"Illegal character in path"
Cause: Without mapping, API Gateway sends literal
{proxy+}(containing{)Fix: Same as above. Ensure Endpoint URL uses
{proxy}(without+)
WebSocket Issues
410 GoneException
Message sent before connection fully established
Connection terminated by client
Invalid connectionId format
Fix: Use
getConnectionbeforepostToConnection; do NOT post from $connect route Lambda
Connection Errors
Missing Lambda permissions, incorrect API URL, backend errors
WebSocket URL format:
wss://api-id.execute-api.region.amazonaws.com/stage
SQS Integration Errors
| Error | Cause | Fix |
|---|---|---|
| UnknownOperationException | Wrong Content-Type or Action name | Verify Content-Type and action |
| AccessDenied | IAM role missing SQS permissions | Add SQS permissions to role |
| KMS.AccessDeniedException | Missing KMS permissions for encrypted queue | Add KMS permissions |
| SignatureDoesNotMatch | Content-Type header mismatch | Align Content-Type between method and integration |
| InvalidAddress | Queue URL doesn't match region | Use correct regional queue URL |
Useful Debugging Commands
Systems Manager Automation
Use AWSSupport-TroubleshootAPIGatewayHttpErrors runbook to automatically analyze CloudWatch logs for 4xx/5xx errors.
CloudWatch Logs Insights for Specific Request
fields @timestamp, @message
| filter @message like "REQUEST_ID_HERE"
| sort @timestamp ascExecution Log Sequence (REST API Only)
Authorizer -> Usage Plan -> Method Request -> Endpoint Request -> Endpoint Response -> Method Response
Tracing with x-amzn-requestid
Every API Gateway response includes x-amzn-requestid header. Use this to search execution logs for the full request trace.
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs an MCP server, Needs an API key
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- AWS Labs
- Publisher
- AWS Labs (Official)
- Source
- awslabs/agent-plugins · plugins/aws-serverless/skills/api-gateway · commit fbefb37
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- NOTICE (added by AutoGineer from NOTICE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by AWS Labs or AWS Labs.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download api-gateway.zip