July 16, 2026

Amazon API Gateway pricing explained: REST, HTTP, and WebSocket APIs

Amazon API Gateway bills on the requests you receive, with no minimum fee and no upfront commitment. The complication is that there are three distinct API types, REST, HTTP, and WebSocket, and each prices on a different dimension. Picking the wrong type is the most expensive API Gateway mistake you can make, because the per-request rate between REST and HTTP differs enough that the choice dominates any other tuning. The current rates are published on the Amazon API Gateway pricing page, and any specific number below is the us-east-1 first-tier rate as published at the time of writing. Confirm against the pricing page before you model a real workload, because region and tier change the number.

REST APIs: tiered per million requests

REST APIs are the original API Gateway product and the most feature-rich. Pricing is per million requests and tiers down as volume rises. In us-east-1, the first tier is $3.50 per million requests as published, and the rate drops through additional tiers as monthly volume grows. REST APIs support usage plans and API keys, request and response mapping transformations, request validation, native AWS WAF attachment, and edge-optimized endpoints with a CloudFront distribution baked in. They also support caching at the stage level, which is priced separately.

HTTP APIs: lower first-tier rate, fewer features

HTTP APIs are the newer, leaner product. Pricing is per million requests and is substantially lower than REST at the first tier. In us-east-1, the first tier is $1.00 per million requests as published, which is roughly 71 percent below the REST first-tier rate. The trade-off is feature set: HTTP APIs have no usage plans, no API keys, no mapping templates, no request validation, and no native WAF attachment on the gateway. WAF can still be attached in front of an HTTP API through CloudFront, which removes the gap for most use cases. For the deeper migration math, see API Gateway REST vs HTTP API: the 71 percent discount.

WebSocket APIs: messages plus connection-minutes

WebSocket APIs are bidirectional and price on two dimensions, which is where the surprise lives. The first dimension is messages, billed per million messages sent or received. The second is connection-minutes, billed per million connection-minutes, where a connection-minute is one client connected for one minute. In us-east-1, the message rate is $1.00 per million and the connection-minute rate is $0.25 per million as published. The connection-minute dimension is what catches teams: a large pool of idle clients held open around the clock accrues connection-minutes even when no messages flow, and that line can exceed the message line on a fanout workload.

The non-request costs

Beyond the request charge, three lines regularly show up on the API Gateway bill. The first is data transfer out to the internet, which is billed per GB on top of the request charge and applies to the response payload size. The second is caching, which is available on REST APIs only and is billed per hour by the cache capacity you provision. The cache runs whether or not it is hit, so the hourly charge is fixed by the capacity tier regardless of traffic. The third is CloudWatch Logs ingestion, which is billed per GB ingested into CloudWatch and is easy to overlook because it lands on the CloudWatch line rather than the API Gateway line. Access logging on a hot API, at a few KB per request, can quietly exceed the request charge itself.

The free tier

API Gateway offers a free tier of one million API calls per month for up to 12 months, available across REST, HTTP, and WebSocket APIs. The tier is per-account and per-region and expires 12 months after the first API call in each region, so it is not a permanent allowance. It is useful for proving out a new API but should not be modeled into a steady-state cost estimate.

REST vs HTTP: the feature trade-off

The decision between REST and HTTP almost always comes down to whether you need the features REST provides or whether you can move them elsewhere. If you depend on usage plans and API keys for per-key throttling and quotas, REST has it built in and HTTP does not. If you rely on mapping templates to transform requests and responses at the gateway, REST supports it and HTTP does not. If you need request validation or the click-to-attach WAF in the console, REST is the simpler path. For a straightforward JSON API with authorizers handled in Lambda or a JWT authorizer, HTTP API delivers the same behavior at a fraction of the per-request cost, and WAF can be layered through CloudFront when needed.

Cloud Horizons shows API Gateway spend by API, stage, and account across your AWS estate, so the REST vs HTTP choice shows up in real spend rather than only in a one-time estimate. See the features page for the full breakdown.