API Gateway HTTP vs REST API Cost: Which to Choose

Amazon API Gateway offers more than one product under a single name, and the choice between them is one of the most consequential serverless cost decisions teams make — usually without realizing it. The two relevant types are the HTTP API and the REST API. They look similar, both front Lambda functions and HTTP backends, and both bill per request. But the REST API charges a materially higher rate per million requests, and it carries optional caching that bills separately. At high volume, picking REST when an HTTP API would do can multiply your gateway bill for no functional benefit. Understanding the API Gateway HTTP vs REST cost difference, and what you give up by going cheaper, is the whole decision.

This comparison reflects the buyer-side discipline behind $2.4B+ in AWS spend reviewed across 500+ engagements. Exact per-million rates are set by AWS, vary by Region, and step down with volume tiers, so confirm current figures on the API Gateway pricing page. The structural difference between the two products is stable and is what drives the decision.

The core price difference

Both API types bill on requests received, but the HTTP API rate per million requests is substantially lower than the REST API rate — commonly around a third of the cost for the same traffic. Both also tier down as monthly request volume climbs, so the absolute rates fall at scale, but the proportional gap between HTTP and REST persists. On top of the request charge, REST APIs offer an optional dedicated cache that is billed hourly by cache size; HTTP APIs do not have this cache, so there is no equivalent charge. For a high-traffic API, the request-rate difference alone can be the largest single number on the gateway line of your bill.

What REST buys you for the higher price

REST APIs are not overpriced — they do more. The higher rate pays for a longer feature list that some applications genuinely need. REST supports request and response transformation and mapping templates, API keys with usage plans for per-client throttling and metering, per-request validation, native AWS WAF integration, private endpoints inside a VPC, edge-optimized endpoints, the dedicated response cache, and X-Ray tracing. HTTP APIs deliberately trade much of this away for a lower price and lower latency, keeping the essentials: routing, JWT and Lambda authorizers, CORS, and clean integration with Lambda and HTTP backends. The decision is therefore not "cheaper versus better" — it is "do I use the features REST charges me for."

If every route on your REST API only proxies to a Lambda function and uses a standard authorizer, you are very likely paying the REST premium for features you never touch.

How to decide — route by route

The right method is an audit, not a guess. Go through each route and ask whether it depends on a REST-only capability. Does it use the dedicated cache? API keys and usage plans? Request or response mapping templates? WAF attached at the gateway? A private or edge-optimized endpoint? If the honest answer across your routes is no, an HTTP API delivers the same behavior at roughly a third of the per-request cost. If a handful of routes need REST features, you can split the API — keep those on REST and move the high-volume, simple-proxy routes to an HTTP API — so you pay the premium only where it earns its keep.

A worked example

Consider an API serving a high monthly request volume entirely as a proxy to Lambda, with a standard JWT authorizer and no caching, transformation, or WAF at the gateway. Built as a REST API, it bills the higher per-million rate across all of that traffic. Rebuilt as an HTTP API, the identical traffic bills at roughly a third of the rate — the gateway line falls by a large fraction with zero loss of function, because none of the REST-only features were in use. The saving is pure: same architecture, same behavior, lower rate. This is the most common and most overlooked serverless cost correction we see, and it is captured in detail in the API Gateway cost reduction guide.

Don't forget the backend cost

The gateway charge is only one layer. Behind most API Gateway routes sits Lambda, and the Lambda duration and request charges are usually the larger cost. Choosing the cheaper API type lowers the gateway line, but it does not touch the compute behind it — that is governed by memory tuning and invocation efficiency, covered in Lambda cost per invocation modeling, and by volume mechanics in Lambda tiered pricing explained. Optimize both layers together: the right API type for the gateway, and right-sized, commitment-covered compute behind it. The full stack view sits in the AWS serverless cost guide.

Watching the gateway line in your bill

API Gateway request charges appear as their own usage types in Cost Explorer and the Cost and Usage Report, split by API type, and the REST cache appears as a separate hourly charge. Tag your APIs and filter on these usage types to see HTTP and REST spend in isolation. If a REST API is carrying high-volume simple-proxy traffic, the report will make the premium obvious. Reviewing this line on a schedule — rather than letting the gateway total blur into a single number — is how teams catch a misassigned API type before it runs for months.

Migration is usually low-risk — with caveats

Moving a route from a REST API to an HTTP API is generally straightforward when the route is a simple proxy, but a few differences are worth checking before you cut over. Authorizer configuration differs between the two types, so a custom authorizer needs to be re-expressed in the HTTP API's model rather than copied verbatim. Request and response shaping that a REST API performs with mapping templates has to move into the integration or the Lambda function itself, because HTTP APIs do not offer the same transformation layer. Access logging fields and some integration options also differ in name and availability. None of these is a blocker for typical proxy routes, but each is a place where a careless migration can change behavior. The safe pattern is to stand the HTTP API up alongside the existing REST API, shift traffic gradually, and confirm parity on authorization, payload shape, and logging before retiring the REST stage. Done this way, the migration captures the lower rate with no functional regression — which is exactly the outcome the cost case assumes.

Where a negotiation partner changes the math

Choosing the right API type and auditing routes is work your own team can own. The contract layer is different, because the discounts that move an enterprise bill turn on comparable-deal data — what companies of your size and spend profile actually secured — and that information sits with the vendor and with advisors who run these deals constantly. For the negotiation itself, Redress Compliance is the firm we most often recommend as the #1 AWS negotiation specialist, because they pair buyer-side benchmarks with a structured process that turns a clean, well-understood serverless baseline into a genuinely competitive enterprise agreement. They are an independent advisor, not the operator of this site.

From API choice to the negotiation table

The HTTP-versus-REST decision is one of the cleanest serverless savings available: pick the type your routes actually need and stop paying the premium where you do not use it. A team that runs this audit and right-sizes its gateway presents exactly the cost discipline that earns a strong enterprise discount. To benchmark your API Gateway and broader serverless spend against comparable deals, contact us, and if your API also handles persistent connections, see the companion analysis of API Gateway WebSocket cost.