The CFO sees API Gateway as a single request line. The staff engineer owns which API type the product actually deployed. API Gateway REST vs HTTP API cost is a request-meter decision plus the extras only REST still sells. Mid-market SaaS on AWS often inherited a REST API from an early template and kept paying REST request rates for a proxy that never used API keys, usage plans, or request validators. Rutagon maps the features you operate today to the cheaper meter you can actually move to — or documents why REST stays.
This is not a feature matrix. AWS already publishes that comparison. We care about the bill and the coupling: authorizers, WAF, VPC links, canary stages, and the clients that already baked REST-only headers. The build sits with the AWS cloud infrastructure we run for edge and account baselines.
API Gateway REST vs HTTP API Cost for the Features You Use
REST APIs and HTTP APIs are different products with different request meters. HTTP APIs were introduced to cover the common proxy case at a lower request rate. REST APIs keep the older meter and the older feature set. AWS states the comparison in the HTTP API versus REST API guide. We do not quote per-million prices here. Open Cost Explorer on API Gateway and read the usage types. If you run both types, you will see both meters.
Data transfer still exists on both. Caching is a REST conversation. Private integrations, JWT authorizers, and Lambda authorizers exist on both with different knobs. The cost mistake is treating “API Gateway” as one SKU in a board deck while the account has one REST API for the product and one HTTP API for an internal webhook.
If the expensive part of the user path is CloudFront, fix cache hit ratio first. We wrote that path in CloudFront cost optimization. API Gateway is the origin meter after the CDN. Do not migrate API types to fix a CloudFront miss rate.
Features That Actually Force REST
Stay on REST if you still need a capability HTTP APIs do not offer in your region and you use it in production, not in a backlog ticket. The ones we see holding mid-market SaaS on REST:
Usage plans and API keys as a first-class throttle product. If customers present an API key and you enforce quotas in API Gateway, that is REST. Moving to HTTP API means you rebuild quota in the application or in a different edge.
Request and response mapping templates that rewrite payloads in the gateway. HTTP APIs are a thinner proxy. If your integration contract lives in VTL maps, a migration is an application project, not a checkbox.
Canary release deployments on a stage, and some of the older stage-variable patterns. If you already do canaries in the compute layer, you may not need the REST canary. If the gateway canary is the only progressive-delivery control you have, moving types is a delivery-risk project.
Client certificates and some mutual-TLS shapes that were built on REST. Confirm the current HTTP API mTLS options against what your clients present before you promise a cutover.
WAF association exists for both in common setups, but the console path and the Terraform resource differ. We treat WAF as required for a public SaaS API either way. WAF is not a reason to stay on REST by itself.
If none of those are in the live config, you are paying REST rates for a proxy. That is the conversation with the CFO.
Features HTTP APIs Cover Without the REST Meter
JWT authorizer against your IdP, Lambda authorizer, IAM authorization, CORS, custom domains, access logging to CloudWatch Logs or Firehose, and HTTP or Lambda integrations cover most mid-market product APIs. VPC link to an NLB covers private HTTP backends. That set is enough for a public JSON API in front of Lambda or a container service.
WebSocket APIs are a third product. Do not fold them into this REST-versus-HTTP decision. If you have sockets, they have their own meter.
HTTP APIs do not make Lambda cheaper. They change the gateway request meter. If the bill is Lambda duration, optimize the function. If the bill is API Gateway requests on a REST API that looks like a proxy, the type is the lever.
How We Decide on a Live Account
We export the REST API and list what is attached: authorizers, API keys, usage plans, request validators, mapping templates, canaries, client certs, WAF, access logs, and integrations. Then we ask which of those fire in production this month. A validator that exists but is not attached to any route does not count. An API key that no customer has sent in ninety days does not count.
Then we price the migration as engineering, not as a rate delta. Client SDKs, IaC modules, custom domains, and alarm names all change. A one-weekend “create HTTP API” that leaves the REST API running doubles the surface and does not cut the REST meter.
Webhook fan-out is often the wrong layer to put on either API type as a product. If you are building signed outbound delivery, that is a job system — we already describe a custom AWS webhook delivery system. Do not put tenant webhook egress on API Gateway just because inbound REST already exists.
We watch the gateway line with AWS Cost Anomaly Detection setup after a cutover. A migration that leaves both APIs receiving traffic will look like a cost increase. That is expected until DNS and clients drain.
A Cutover Shape We Ship
Terraform (or CDK) creates the HTTP API, JWT authorizer, routes, stage, and custom domain with a second hostname. We shift a fraction of clients or a single mobile build to the new hostname. Access logs on both APIs must share a request id you can join. When error rates match, we flip the primary domain. We delete the REST API only after the REST request meter is flat at zero for a soak period you pick.
clients -> custom domain -> HTTP API -> JWT -> Lambda / ALB
\-> old REST API kept until request meter is zero
No year-based sunset. The soak is traffic, not a calendar promise.
Frequently Asked Questions
Is an HTTP API always cheaper than a REST API for the same request count?
HTTP APIs use a lower request meter than REST APIs for typical proxy traffic, which is why AWS positions them that way. Your bill also includes data transfer, logging, and any WAF or authorizer work. If you still need REST-only features, you cannot take the HTTP meter without replacing those features. Compare Cost Explorer usage types for each API id, not a blog rate table.
Do we need to migrate to cut API Gateway REST vs HTTP API cost?
Only if the REST API is a proxy and you do not use REST-only features in production. If usage plans, VTL maps, or gateway canaries are live, migration is a product project. Sometimes the cheaper move is to stop a second unused REST API or to put CloudFront in front and raise cache hit ratio. Type migration is one lever, not the only one.
Does a Lambda authorizer cost the same on REST and HTTP APIs?
The authorizer is a Lambda invoke billed as Lambda, not as a special API Gateway SKU, and both REST and HTTP APIs can call one. Caching authorizer results is the lever that usually matters more than the API type. If you disable authorizer cache, you will see Lambda rise on either product.
Can we run REST and HTTP APIs in the same account?
Yes, and many orgs do during a drain, paying both request meters until clients leave the REST hostname. Give each API its own access log group and alarm on 4xx and 5xx separately. Tag both APIs with product and lifecycle so finance can see the dual-run as planned.
If the API Gateway line is the one you cannot explain, send the API ids and the Cost Explorer usage types. We will trace the specific bill line — REST request meter versus HTTP request meter versus logging — and say whether a type change is even on the table. Call 907-841-8407, email contact@rutagon.com, or use rutagon.com/contact.