AWS API Gateway Pricing Calculator
Estimate monthly API Gateway request costs for HTTP APIs, REST APIs, and WebSocket APIs using a practical pricing model based on commonly used AWS public rate tiers in US East. This estimate excludes data transfer out, CloudWatch, Lambda, WAF, caching, private link, and taxes.
Tip: if your architecture uses custom domains, WAF, CloudFront, VPC links, or caching, your real monthly bill can be meaningfully higher than the request charge shown below.
Expert Guide: How to Use an AWS API Gateway Pricing Calculator the Right Way
A reliable AWS API Gateway pricing calculator helps you translate API traffic into a monthly operating estimate before launch, during growth planning, and while optimizing an existing workload. API Gateway pricing can look simple at first glance because the service is request based, but the actual bill depends on the API type you choose, the volume tier you reach, and whether you use features that add cost outside the gateway itself. That is why a calculator matters. It creates a repeatable way to compare API styles, model growth, and avoid underestimating the real run rate of a production platform.
The calculator above is designed to estimate the gateway charge for four common deployment paths: HTTP API, REST API Regional, REST API Edge Optimized, and WebSocket API. Each option serves a different technical purpose. HTTP APIs are often the lower cost choice for modern, lightweight request and response traffic. REST APIs support a richer feature set and are frequently used in mature environments with more advanced routing, integrations, and legacy patterns. WebSocket APIs are billed differently because they depend on message counts and connection minutes rather than basic request totals.
Why API Gateway cost planning matters
For low traffic workloads, API Gateway charges may look negligible. At scale, even small differences in per million request pricing can become important. If your application processes tens or hundreds of millions of requests per month, choosing the wrong API type can materially change your monthly spend. Good planning also improves margin forecasting. A SaaS team might know the cost per active customer only after request cost, compute cost, data transfer, and observability are all estimated together. This is especially valuable for products with usage based billing, internal chargeback, or budget controls.
There is also an architecture dimension. The least expensive gateway option is not always the best option for your workload. If a team needs advanced REST features, migration convenience, or a particular security and integration pattern, paying more per request may be justified. A good pricing calculator does not only answer, “What is cheapest?” It also answers, “What is the likely request cost if we choose the feature set we actually need?”
Core pricing logic used by this calculator
This page focuses on the API Gateway request layer. For HTTP APIs and REST APIs, pricing is calculated from monthly request volume and public volume tiers commonly associated with AWS US East pricing. For WebSocket APIs, the estimate includes message billing and connection minute billing. Message charges are important because WebSocket payloads are billed in 32 KB increments, so a 33 KB message counts as two billable messages, not one.
| API type | Primary billing unit | Public pricing model used here | Best fit |
|---|---|---|---|
| HTTP API | Requests | First 300 million at $1.00 per million, next 700 million at $0.90, above 1 billion at $0.80 | Cost efficient front doors for modern services, Lambda integrations, and lightweight microservice APIs |
| REST API, Regional | Requests | First 333 million at $3.50 per million, next 667 million at $2.80, above 1 billion at $2.38 | Feature rich APIs that need mature gateway capabilities and established REST patterns |
| REST API, Edge Optimized | Requests | Same request rate model shown above, estimate excludes data transfer and related edge services | Global client access patterns where edge distribution behavior matters |
| WebSocket API | Messages and connection minutes | $1.00 per million messages plus $0.25 per million connection minutes, with 32 KB message rounding | Real time dashboards, collaboration apps, live status streams, chat, and event push systems |
How to estimate accurately
If you want a realistic forecast, begin with monthly usage assumptions that are tied to application behavior rather than rough top line guesses. For request based APIs, estimate requests per user session, sessions per active user, expected retries, webhook calls, health checks, and partner traffic. For WebSocket APIs, estimate both the total number of messages and the aggregate connection minutes. Always model peak months, not just average months, because pricing tiers and operational load are driven by the upper range of demand.
- Start with monthly active users or monthly transactions.
- Convert each business event into API calls. Include reads, writes, polling, retries, webhooks, and health probes.
- Separate public requests from internal service to service traffic if both pass through the gateway.
- For WebSocket workloads, estimate average payload size because 32 KB rounding can change the billable message count.
- Add a growth buffer, usually 15 percent to 30 percent, for marketing campaigns, seasonality, or feature adoption.
Example: suppose a mobile application has 250,000 monthly active users. If the typical user triggers 120 API requests per month, the baseline is 30 million requests. If retries, background sync, and partner callbacks add 12 percent overhead, the adjusted estimate is 33.6 million requests. Running that number through a pricing calculator gives a much stronger planning figure than simply saying, “We have a quarter million users.”
Sample scenarios with real cost math
The following examples show why the calculator is useful. The figures below are derived from the pricing model used on this page and are intended as request charge examples, not full AWS bills.
| Scenario | Monthly usage | HTTP API estimate | REST API estimate | WebSocket estimate |
|---|---|---|---|---|
| Startup application | 10 million requests | $10.00 | $35.00 | Not applicable |
| Growing B2B platform | 100 million requests | $100.00 | $350.00 | Not applicable |
| Large scale API product | 500 million requests | $480.00 | $1,866.90 | Not applicable |
| Realtime app | 20 million messages, 10 million connection minutes, 4 KB average message | Not applicable | Not applicable | $22.50 |
| Larger realtime workload | 150 million messages, 80 million connection minutes, 40 KB average message | Not applicable | Not applicable | $320.00 |
Notice how HTTP APIs can be dramatically less expensive than REST APIs for the same request volume when your workload fits the HTTP API feature profile. Also notice how WebSocket message size matters. In the larger realtime example above, a 40 KB average message is billed as two 32 KB units per message, which doubles the message component relative to a payload under 32 KB.
What this calculator does not include
Many teams underestimate total API platform cost because they stop at the gateway request line item. In a production architecture, your bill can also include Lambda invocations, container runtime, EC2 instances, private network components, CloudWatch logs and metrics, WAF, custom domain certificates, and data transfer out. Data transfer is often the biggest missing variable in edge heavy systems, media oriented APIs, or globally distributed mobile applications.
- Compute and integration cost: Lambda, ECS, EKS, EC2, Step Functions, and downstream databases.
- Security and edge cost: AWS WAF, Shield options, custom domains, and CloudFront related charges.
- Observability cost: CloudWatch logs, metrics, traces, alarms, and third party monitoring tools.
- Network cost: data transfer out, inter AZ traffic, NAT usage, and private connectivity patterns.
- Developer productivity cost: feature complexity, migration effort, and operational overhead.
Because of those extras, the best use of an AWS API Gateway pricing calculator is as one layer inside a fuller cloud cost model. It gives you a grounded request estimate, then you add adjacent services on top of it. For organizations with financial controls, this is useful for budget requests, unit economics, and gross margin analysis.
When to choose HTTP API versus REST API
If your team is deciding between HTTP API and REST API, pricing is only one side of the decision. HTTP APIs are often attractive because they are simpler and lower cost for many modern API patterns. REST APIs can still be the better fit when advanced gateway features matter more than the raw request rate. A disciplined approach is to list your required features first, then run the pricing comparison second. If both API types meet the requirement, the cost advantage of HTTP APIs can be compelling at scale.
A practical test is to estimate 12 months of traffic growth under both options. If your traffic is expected to increase from 50 million to 500 million monthly requests over a year, the difference between the two API categories can become large enough to influence architecture reviews. In some organizations, that delta can justify migration work. In others, the richer feature set of REST APIs remains worth the premium. The right answer depends on product maturity, compliance needs, release velocity, and the value of operational simplicity.
How to model WebSocket APIs without undercounting
WebSocket pricing introduces two common mistakes. The first is ignoring connection minutes. A consumer app with many long lived sessions can accumulate a large pool of connected clients even if each client sends only a modest number of messages. The second mistake is forgetting message size rounding. Since billing uses 32 KB units, payload design becomes a cost factor. Compressing or restructuring payloads can improve efficiency without changing user experience.
For example, if your collaboration tool sends 5 million updates per day and the average update is 20 KB, monthly billable messages are essentially the same as raw messages because each update fits into one 32 KB block. If the average update drifts to 35 KB due to richer metadata, each event becomes two billable message units. That can double the message line item overnight. This is one of the simplest optimization opportunities for realtime applications.
Optimization tactics that actually reduce spend
- Reduce unnecessary client polling by moving to event driven refresh patterns where appropriate.
- Bundle related reads into fewer calls when that does not create oversized payloads or poor cache behavior.
- Use HTTP APIs when the feature set is sufficient for the workload.
- Review health checks, retries, partner callbacks, and bot traffic to remove low value request volume.
- For WebSocket systems, keep average message sizes below 32 KB when practical.
- Track cost per customer, cost per transaction, or cost per session so engineering can measure improvements.
Operational and governance references
Pricing decisions should sit alongside governance, security, and resilience practices. For broader guidance on cloud and API related risk controls, useful public resources include the NIST microservices and API security guidance, the NIST cloud computing program, and CISA API security resources. These resources are not pricing sheets, but they are highly relevant when you are choosing between API architectures and planning the operational controls that can influence long term platform cost.
Final takeaway
An AWS API Gateway pricing calculator is most valuable when you use it as a planning instrument, not just a one time quote tool. It helps compare API styles, estimate launch cost, model growth, and reveal where small architectural choices can create large monthly differences at scale. For request and response APIs, the biggest cost lever is often the API type itself. For realtime systems, the biggest levers are message count, payload size, and connection duration. Combine those estimates with data transfer, compute, logging, and security costs, and you will have a much more reliable forecast for production.