Deploy an API Gateway V2 HTTP API with Lambda Backend

Architecture Overview

This architecture pairs API Gateway V2 (HTTP API) with a Lambda function to create a serverless HTTP endpoint. API Gateway V2 is the newer, streamlined version of API Gateway, designed specifically for HTTP workloads. It offers lower latency, lower cost, and simpler configuration compared to the original REST API type, making it the recommended choice for most new serverless APIs.

The deployment creates a Lambda function with an IAM execution role, an HTTP API with a Lambda proxy integration, a default catch-all route, and an auto-deploying stage with throttling. The Lambda proxy integration means API Gateway automatically transforms HTTP requests into Lambda event payloads and Lambda responses back into HTTP responses, without manual mapping templates.

The auto-deploy stage eliminates the need for manual deployment steps. When you update the API configuration (routes, integrations, or stage settings), changes take effect automatically. Throttling protects your Lambda function from traffic spikes by limiting the burst and steady-state request rate at the stage level.

Lambda Function and IAM

The Lambda function is the compute backend that processes all incoming HTTP requests. It runs with an IAM execution role that grants it permission to write logs to CloudWatch. The execution role follows the principle of least privilege: it can assume the Lambda service role and write logs, but nothing else unless you add additional policy attachments.

API Gateway receives explicit permission to invoke the Lambda function through a resource-based policy. This permission scoping ensures that only your API Gateway can trigger the function, not arbitrary AWS services or accounts.

HTTP API and Integration

The API Gateway V2 HTTP API serves as the public-facing endpoint. The Lambda proxy integration connects the API to your function, handling the request/response transformation automatically. With proxy integration, the Lambda function receives the full HTTP request context (headers, query parameters, path, body) and returns a response object that API Gateway transforms into an HTTP response.

The default route acts as a catch-all, forwarding every request regardless of path or method to the Lambda function. This is useful when your function handles its own routing logic internally, or when you want a single function to handle all API traffic.

Stage and Throttling

The stage is configured with auto-deploy enabled, so changes to the API take effect without manual intervention. Throttling is configured at the stage level with burst and rate limits to protect downstream resources from traffic spikes. These limits apply to all routes in the stage and can be overridden per-route if specific endpoints need different thresholds.

Throttling returns a 429 (Too Many Requests) response when limits are exceeded, which is the standard HTTP mechanism for rate limiting. Clients can implement retry logic with exponential backoff to handle throttled requests gracefully.

Common Customizations

• Add route-specific paths: Replace the catch-all route with specific routes (like /users or /orders) that map to different Lambda functions or integrations for a more structured API.
• Enable CORS: Configure CORS settings on the HTTP API to allow browser-based applications to call your API from different origins.
• Add JWT authorization: Attach a JWT authorizer to routes to authenticate requests using tokens from an identity provider like Cognito or Auth0.
• Connect a custom domain: Add a custom domain name with an ACM certificate so your API is available at a branded URL instead of the generated API Gateway domain.