Amazon API Gateway Design Patterns - Choosing Between REST API and HTTP API

Clear criteria for choosing between HTTP API and REST API, authentication patterns with Cognito and Lambda authorizers, and practical throttling design techniques.

About 8 min readLast updated: 2026-10-29

Criteria for Choosing Between REST API and HTTP API

API Gateway offers two types: REST API and HTTP API. HTTP API, released in preview in December 2019 and made generally available in March 2020, covers the core features of REST API while being up to 71% cheaper with lower latency. If your primary use case is proxying to Lambda functions or HTTP endpoints, HTTP API is the right choice. Cases where you should choose REST API include: publishing APIs to third parties with API keys and usage plans, request/response transformation (mapping templates), WAF integration, edge-optimized endpoints, and request validation features. For new projects, the recommended approach is to default to HTTP API and only consider REST API when you need features that HTTP API doesn't offer.

Authentication and Authorization Patterns

API Gateway supports multiple authentication methods, but the types of authorizers available differ between REST API and HTTP API (as of August 2026). The Cognito user pool authorizer (COGNITO_USER_POOLS) is specific to REST API: API Gateway automatically validates the JWT tokens issued by Cognito. Since you don't need to implement token validation logic yourself, it is easy to adopt in configurations that use Cognito. HTTP API does not offer this authorizer; instead, you use a JWT authorizer. A JWT authorizer validates JWTs in line with the OpenID Connect (OIDC) and OAuth 2.0 frameworks, using a specified issuer and audience. Because a Cognito user pool can be specified as the issuer, Cognito-based authentication is still achievable with HTTP API, but note that the type of authorizer you configure is different. The JWT authorizer verifies the signature with the public keys retrieved from the issuer's jwks_uri (only RSA-based algorithms are supported) and evaluates claims such as iss, aud, and exp. If you configure authorization scopes per route, you can also control access based on the scopes contained in the token. Lambda authorizers let you implement custom authentication logic in a Lambda function. Use them when you need flexible authorization logic such as custom token formats, integration with external IdPs, or IP address-based controls. Lambda authorizer results can be cached, and setting a TTL reduces duplicate authentication Lambda invocations. IAM authentication uses AWS SigV4 signatures to authenticate requests and is suited for internal communication between AWS services.

Throttling and Usage Plans

API Gateway throttling is implemented using the token bucket algorithm. The default account-level limit is 10,000 requests per second per Region, with a burst of 5,000 requests. Finer-grained limits can be set at the stage and method levels to prevent specific endpoints from overloading the backend. Usage plans are a REST API-specific feature that lets you set daily and monthly request limits and throttling rates per API key. When exposing APIs to external partners, you can apply different rate limits per partner. Clients that receive a 429 Too Many Requests response should implement retries with exponential backoff.

API Gateway Pricing

HTTP API costs approximately USD 1.00 per million requests, roughly 71% cheaper than REST API at USD 3.50 (as of August 2026). WebSocket API costs approximately USD 1.00 per million messages plus connection time charges (approximately USD 0.25 per million minutes). Enabling REST API caching incurs hourly charges based on the cache memory size (approximately USD 0.02 per hour for 0.5 GB). Properly setting Lambda authorizer cache TTL to reduce the number of authentication Lambda invocations is also effective for cost optimization. The legacy 12-month free tier (accounts created before July 15, 2025) included 1 million requests per month each for HTTP API and REST API. The credit-based free plan with up to USD 200 in credits applies to new accounts created on or after that date (see the official AWS site for the latest terms).

Integration Types and Backend Connectivity

API Gateway can bridge requests to a variety of backends. Proxy integration, which passes requests as they are to a Lambda function, is easy to use and the most common. There are also integrations that forward requests to existing HTTP services and mechanisms that connect to private services inside a VPC. If you use integrations that call some AWS services directly without going through a backend, you can skip Lambda for simple processing and keep cost and latency down. By designing what to place behind the API you expose and how to connect it, you can keep the configuration simple while providing the functions you need. Choose the appropriate integration type according to your requirements.

Request and Response Processing

API Gateway has features that process requests and responses. By validating whether the input format is correct and rejecting invalid requests before they reach the backend, you can prevent wasted processing and load. You can also convert the structure of requests and responses into a form that is easy for both the client and the backend to handle. In this way, you can adjust the shape of the API you expose externally without changing the backend specification. By performing validation and transformation at the entry point, you can protect the backend implementation while offering users a consistent API that is easy to use.

Real-Time Communication with WebSocket

A typical API is basically a one-way exchange that responds to requests from the client. On the other hand, if you want to push data from the server to the client at any time and need two-way real-time communication, you can build an API that supports WebSocket. It suits uses such as chat, notifications, and live update displays. You define processing for each event, such as establishing or closing a connection and receiving a message, and the server side can proactively send messages to connected clients. By using the request-response type and the real-time type according to the use case, you can meet the communication requirements of a wide range of applications.

Monitoring, Caching, and Operations

When operating an API, monitor the number of requests, the error rate, and latency so that you can detect anomalies. If you record access logs, you can trace what kinds of calls took place and use that to investigate problems. For endpoints that frequently return the same results, you can use the feature that caches responses to lower the backend load and latency. With stages, you can separate development and production, and you can also run canary releases that try a new version on part of the traffic. By combining monitoring, caching, and staged releases, you can provide an API that you can operate stably.

Summary

API Gateway is a service that centrally manages authentication, throttling, and monitoring at the API layer as the entry point for serverless architectures. By defaulting to HTTP API and choosing REST API only when enterprise features are needed, you can optimize both cost and latency.

References (Official AWS Resources)

The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.

If this page and the official documentation disagree, treat the official documentation as authoritative.

Amazon EFS and Lambda / ECS Integration Patterns - Using Shared File Systems in ServerlessEFS is mounted on Lambda functions and ECS tasks to make use of a shared file system. This article introduces access point design and performance optimization.Why Lambda's 15-Minute Limit Is 15 Minutes - The Rationale Hidden in Serverless Design ConstraintsThis article explains the current values of the various serverless limits, such as Lambda's maximum execution time of 15 minutes, memory limit of 10 GB, and payload of 6 MB, and how they affect architecture design. It does so from the perspectives of multi-tenant operation and the lifecycle of the execution environment.Understanding Lambda Cold Starts and Choosing Among Three Optimization StrategiesThis article explains the mechanism behind Lambda cold starts from the Firecracker MicroVM lifecycle perspective, and compares optimization techniques across three axes: SnapStart, Provisioned Concurrency, and function design in terms of cost and constraints.Getting Started with Serverless Development Using AWS Lambda - Function Design and Event Source IntegrationThis article covers Lambda function design, event source mapping, cold start mitigation, and Powertools usage.Behind Lambda's 1,000 Concurrent Executions - How the Firecracker Warm Pool and the Worker Manager WorkThis article explains how Lambda manages microVMs within the default limit of 1,000 concurrent executions, the reuse strategy through the warm pool, the placement decisions of the worker manager, and the internal optimizations that lower the cold start rate.Building Serverless APIs - Scalable API Infrastructure with Amazon API GatewayLearn how to build serverless APIs using Amazon API Gateway and Lambda.Designing State Machines - Workflow Orchestration with Step FunctionsLearn state machine design techniques with AWS Step Functions, including visual workflows, error handling, and workflow orchestration through Lambda integration.Designing Workflow Orchestration with AWS Step Functions - Choosing Between Standard and ExpressThis article clarifies the criteria for selecting between Standard workflows and Express workflows and introduces declarative error handling with Retry/Catch and large-scale parallel processing with distributed map.