Generated banner for API Gateway
Generated logo for API Gateway

API Gateway

AWS LabsOfficialPublished by AWS Labs

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • No issues found

From the author

Build, manage, and operate APIs with Amazon API Gateway (REST, HTTP, and WebSocket). Triggers on phrases like: API Gateway, REST API, HTTP API, WebSocket API, custom domain, Lambda authorizer, usage plan, throttling, CORS, VPC link, private API. Also covers troubleshooting API Gateway errors (4xx, 5xx, timeout, CORS failures) and IaC templates containing API Gateway resources. For general REST API design unrelated to AWS, do not trigger.
— the description by AWS Labs

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

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/awslabs/api-gateway/download
  2. Unzip 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:

  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.

FactorREST API (v1)HTTP API (v2)WebSocket API
PositioningFull API managementLow-cost proxyReal-time bidirectional
CostHigher~70% cheaperPer-message pricing
LatencyHigherLowerPersistent connection
Max timeout50ms-29s (up to 300s Regional/Private)30s hard limit29s
Payload10 MB10 MB128 KB message / 32 KB frame
API Management
Usage plans/API keysYesNoNo
Request validationYes (JSON Schema draft 4)NoNo
CachingYes (0.5-237 GB)NoNo
Custom gateway responsesYesNoNo
VTL mapping templatesYesNo (parameter mapping only)Yes
Security & Governance
WAFYesNo (use CloudFront + WAF)No
Resource policiesYesNoNo
Private endpointsYesNoNo
mTLSYes (Regional custom domain only)Yes (Regional custom domain only)Via CloudFront viewer mTLS
Auth
Lambda authorizerYes (TOKEN + REQUEST)Yes (REQUEST only, simple + IAM policy format)Yes (REQUEST on $connect only)
JWT authorizerNo (use Cognito authorizer)Yes (native)No
Cognito authorizerYes (native)Use JWT authorizerNo
Operations
Canary deploymentsYesNoNo
Response streamingYesNoNo
X-Ray tracingYesNoNo
Execution loggingYesNoYes
Custom domain sharingNot with WebSocketNot with WebSocketNot 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:

  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

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:

ErrorMost Common CauseQuick Fix
400 Bad RequestProtocol mismatch (HTTP/HTTPS) with ALBMatch protocol to listener type
401 UnauthorizedWrong token type (ID vs access) or missing identity sourcesCheck token type matches scope config; verify all identity sources sent
403 Missing Auth TokenStage name in URL when using custom domainRemove stage name from URL path
403 from VPCPrivate DNS on VPC endpoint intercepts ALL API callsUse custom domain names for public APIs
403 Access DeniedResource policy + auth type mismatch or missing redeploymentReview policy, check auth type, redeploy API
403 mTLSCertificate issuer not in truststore or weak signature algorithmVerify CA in truststore, use SHA-256+
429 Too Many RequestsAccount/stage/method throttle limits exceededImplement jittered exponential backoff; request limit increase
500 Internal ErrorMissing Lambda invoke permission (especially with stage variables)Add resource-based policy to Lambda function
502 Bad GatewayLambda response not in required proxy formatReturn {statusCode, headers, body} from Lambda
504 TimeoutBackend exceeds 29s (REST, increasable) or 30s (HTTP, hard). HTTP API body says "Service Unavailable" but status is 504Optimize backend, request timeout increase (REST Regional/Private), or switch to async invocation
CORS errorsMissing CORS headers on Gateway Responses (4XX/5XX)Add CORS headers to DEFAULT_4XX and DEFAULT_5XX gateway responses
SSL/PKIX errorsIncomplete certificate chain on backendProvide full cert chain; use insecureSkipVerification only for testing

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

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:

ResourceREST APIHTTP APIWebSocket
Payload size10 MB10 MB128 KB
Integration timeout50ms-29s (up to 300s Regional/Private)30s hard29s
APIs per region600 Regional/Private; 120 Edge-optimized600600
Stages per API101010
Routes/resources per API300300300
Custom domains (public)120120120
Account throttle10,000 rps / 5,000 burstSameSame (shared quota)
API keys per region10,000N/AN/A
Usage plans per region300N/AN/A
Cache sizes0.5 GB - 237 GBN/AN/A

Files

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

  1. Enable execution logging (REST/WebSocket only — HTTP API supports access logging only) AND access logging before troubleshooting

  2. Use x-amzn-requestid response header to trace specific requests in execution logs

  3. Check enhanced observability variables in access logs to identify which phase failed (see references/observability-logging.md)

  4. 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/minItems are 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-api VPC endpoint routes ALL API calls through the endpoint

  • Fix: 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:

  1. IP not in allow list or is in deny list

  2. HTTP method/resource not covered by policy

  3. Auth type mismatch (e.g., IAM auth expected but not provided)

  4. API not redeployed after policy change

  5. Wrong condition key (aws:SourceVpce vs aws: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: 403 in access logs

  • Check 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_4XX as a catch-all to add CORS headers for all 4xx errors including 413

  • For 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 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 principalId and valid policyDocument

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
}
  • statusCode must be integer, body must be string, headers must be object

  • HTTP API payload format 2.0 is more flexible (response format): body can be string or object (auto-serialized to JSON), a bare string return is treated as 200 body, and cookies array is supported for Set-Cookie headers

  • Also 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
Diagnosis
  1. Check IntegrationLatency metric for spikes

  2. Use CloudWatch Logs Insights to identify slow requests

  3. 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=true for 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

  • 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_4XX and DEFAULT_5XX gateway responses

Proxy Integration Missing CORS
  • Cause: API Gateway doesn't add CORS headers in proxy integration

  • Fix: Lambda/backend must return Access-Control-Allow-Origin and other CORS headers

Private API Preflight Failure
  • Cause: x-apigw-api-id header triggers preflight requests that fail

  • Fix: Use Host header instead of x-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::Permission resource

Lambda Authorizer Permission Error
  • Create IAM role with lambda:InvokeFunction and set as Lambda Invoke Role on the authorizer

Async Invocation
  • REST API: Set X-Amz-Invocation-Type: 'Event' in Integration Request HTTP Headers

  • HTTP API: Not directly supported. Use proxy Lambda that invokes target Lambda asynchronously


VPC and Private API Issues

Connection Checklist
  1. Resource policy allows VPC endpoint or VPC

  2. VPC endpoint policy allows the API

  3. Security groups allow TCP 443 inbound

  4. DNS resolution works (check private DNS setting)

Invoke URL Formats (Without Private DNS)
  • Route 53 alias to VPC endpoint

  • VPC endpoint public DNS + Host header

  • VPC endpoint public DNS + x-apigw-api-id header

On-Premises DNS Resolution
  • Create Route 53 Resolver inbound endpoint in VPC

  • Configure on-prem DNS forwarder to forward amazonaws.com queries to Resolver


Mapping Template Errors

"Invalid mapping expression specified"
  • Cause: {proxy+} path variable needs URL path parameter mapping

  • Fix: Define URL path parameter proxy mapped from method.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 getConnection before postToConnection; 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

ErrorCauseFix
UnknownOperationExceptionWrong Content-Type or Action nameVerify Content-Type and action
AccessDeniedIAM role missing SQS permissionsAdd SQS permissions to role
KMS.AccessDeniedExceptionMissing KMS permissions for encrypted queueAdd KMS permissions
SignatureDoesNotMatchContent-Type header mismatchAlign Content-Type between method and integration
InvalidAddressQueue URL doesn't match regionUse 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 asc
Execution 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.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download api-gateway.zip