May 8, 2026 8 min read
API Gateway REST vs HTTP API: the 71 percent discount most teams missed
AWS HTTP API has been a 71 percent discount on REST API since 2020. Most teams who started before that are still on REST. The migration is one Terraform resource for new APIs and a measured cutover for existing ones. The math, the trade-offs, and the audit query.
AWS shipped HTTP API in December 2019 and made it generally available in 2020. The pricing was a 71 percent discount on REST API requests. Six years later, most teams who started building before 2020 are still on REST, paying $3.50 per million requests instead of $1.00, because nothing has ever forced the migration.
For an API doing 100M requests a month, that is $250 per stage per month. Multiply by however many stages and accounts the team runs and the number gets serious. We see seven-figure annual API Gateway lines on accounts that could be cut by a clean six figures with a Terraform refactor.
The pricing in one paragraph
REST API charges $3.50 per million requests for the first 333M per month, dropping to $2.80, $2.38, and finally $1.51 in the higher tiers. HTTP API charges $1.00 flat for the first 300M and $0.90 above. The catch on HTTP API is that requests are billed in 512 KB chunks, so a 600 KB payload bills as two requests. For typical JSON APIs (under 4 KB per request), the chunking is invisible.
WebSocket API is its own thing. $1.00 per million messages, plus $0.25 per million connection-minutes. The connection-minute dimension surprises teams: 50,000 concurrent clients held open 24/7 cost $540/month before any message flows.
What you give up moving REST to HTTP
Be honest with the team. HTTP API is slimmer, and the omissions are the reason it can be cheaper. The list of REST-only features:
- Usage plans and API keys. If you sell API access with per-key throttling and quotas, REST has it built in. HTTP does not. You can replicate this at the application layer or via WAF, but it is more code.
- Request and response transformations. REST lets you rewrite requests and responses in mapping templates. HTTP API does not. Most teams who use this feature could move the logic into Lambda for the same effect.
- Native AWS WAF integration on the gateway. You can still attach WAF in front of HTTP API via CloudFront, but the click-to-attach in the console is REST-only.
- Edge-optimized endpoints. HTTP API is regional only. For global APIs you put CloudFront in front regardless, so this is rarely a real loss.
- Private REST APIs via VPC endpoints. Different model on HTTP API. If you depend on this, the migration has more shape to it.
The audit query
Run this against every account in the org to inventory what you have:
aws apigateway get-rest-apis --query 'items[].[name,id,createdDate]' --output table
aws apigatewayv2 get-apis --query 'Items[].[Name,ApiId,ProtocolType]' --output table The first command lists REST APIs. The second lists HTTP and WebSocket APIs (apigatewayv2 covers both). Cross-reference REST API IDs against your Terraform and you will find the ones that have not moved. Sort by createdDate to find the oldest, which usually have the heaviest traffic and the biggest savings opportunity.
The migration shape, for new vs existing APIs
For a brand-new API, the migration is one Terraform resource choice:
# Old (REST API)
resource "aws_api_gateway_rest_api" "main" { ... }
# New (HTTP API)
resource "aws_apigatewayv2_api" "main" {
name = "main"
protocol_type = "HTTP"
cors_configuration {
allow_origins = ["https://app.example.com"]
allow_methods = ["GET", "POST", "OPTIONS"]
allow_headers = ["content-type", "authorization"]
}
} For an existing REST API in production, the migration is a cutover. The route definitions, integrations, authorizers, and CORS config all have HTTP API equivalents but the Terraform resource types are different. The pattern we recommend:
- Stand up the HTTP API in parallel, route the same integrations.
- Validate behavior with a small percentage of traffic via Route 53 weighted records or a CloudFront origin failover.
- Move authorizers (Lambda, JWT, IAM) one at a time, verify.
- Cut over the DNS record, leave REST API alive for one rollback window, then delete it.
For most teams this is a one-week project per API. The savings start the day of cutover and compound across stages.
The other surprises
Two more line items hide alongside the gateway request charge:
Access logs. API Gateway access logging to CloudWatch Logs is per-request and not bundled. At a few KB per access log entry and millions of requests, this can be bigger than the gateway itself. Either turn it off, sample, or ship to a cheaper logs destination.
Custom domain Route 53 queries. Each custom domain on the gateway resolves through Route 53. At hot APIs this adds Route 53 query charges that nobody attributes back. Small individually, real at scale.
The before-lunch change
Run the audit query, list every REST API older than 2020 (almost all of them), and pick the highest-traffic one. Plug its monthly request count into the API Gateway cost calculator to see the dollar value of moving it. That number is your business case for the cutover. Most teams find the migration pays for itself in a single month of savings.
Keep reading
More from the blog
May 8, 2026 · 8 min read
Lambda cost: the three knobs that matter (and the one that does not)
Lambda pricing has two components and three knobs that move the bill. Memory tuning, architecture, duration. Provisioned Concurrency is the fourth knob most teams should not touch. The math, the audit query, and the change you can ship before lunch.
May 8, 2026 · 8 min read
S3 Intelligent-Tiering vs Standard-IA: when each is the wrong choice
Both classes look like a free lunch at first glance. The math says otherwise on small objects, short-lived data, and predictable access patterns. The decision tree we run on every audit, with the dollar thresholds where each class breaks even.