Amazon API Gateway Pricing: The $125/Month Charge You Miss

Amazon API Gateway's rate card looks simple: $3.50 per million requests for REST APIs, $1.00 per million for HTTP APIs. Then a real bill shows up with a provisioned cache, a VPC Link, and a Developer Portal on it, none of which appear if you only read the top of the pricing page. Two things trip up almost every team pricing this service: a set of charges that bill whether or not a single request ever arrives, and one specific billing question AWS's own documentation doesn't fully answer.

API Gateway added two new billable features in November 2025 (Developer Portals and REST API response streaming), and new AWS accounts got a different free-tier structure starting in July 2025. If your last cost estimate predates that, it's missing real line items.

This breaks down every confirmed billable dimension across REST, HTTP, and WebSocket APIs, plus the one place where the documentation itself runs out of answers. If you'd rather plug in your own numbers as you go, the API Gateway pricing calculator is linked throughout.

The Three API Types and What Each One Actually Costs

API Gateway offers three API types, and picking one sets both your feature list and your bill. Requests are priced on a tiered scale that gets cheaper as volume grows (WebSocket is the exception, since it doesn't bill per request at all). The price gap between types tracks a feature gap, not an arbitrary markup, so the right starting question is what you actually need, not just which type is cheapest.

REST APIs

REST APIs bill per request received, plus data transferred out, on a tiered schedule:

Data transfer out runs $0.09/GB at the first tier. AWS's own worked example puts these together at real scale: 15 billion requests a month at 4 KB responses comes to $36,353.10 in request charges plus $5,149.84 in data transfer, for $41,502.94/month total. That's useful context for what "high volume" looks like on AWS's own numbers, even if your workload is nowhere near it.

REST is also the only type that supports AWS WAF, Usage Plans and API keys, per-stage caching, request/response transformation, and Edge-optimized (CloudFront-fronted) endpoints. If you need any of those, the higher per-request price is the cost of the feature set, not a penalty for choosing REST.

HTTP APIs

HTTP APIs bill on a simpler, cheaper tiered schedule (confirmed for us-east-1):

AWS states HTTP APIs run "at least 71% lower cost" than REST APIs at equivalent volume in us-east-1. A published case study makes that concrete: a workload doing roughly 534 million requests a year cost $1,870.26/year on REST and $534.36/year on HTTP, because that particular application didn't need API keys, Usage Plans, or Cognito integration. If your workload doesn't lean on REST-only features, that's the size of the gap you're leaving on the table.

WebSocket APIs

WebSocket has no per-request charge at all. Instead, it meters two dimensions independently:

• Messages, in 32 KB increments (a 33 KB message bills as two messages). AWS's own example uses $1.00 per million messages.
• Connection-minutes, rounded to the nearest minute. AWS's own example uses $0.25 per million connection-minutes.

Control frames (ping/pong) are never metered. And a message that fails authentication or authorization never counts as billable either, more on that in the next section.

Response streaming's new 10 MB billing unit (November 2025)

REST APIs gained response streaming in November 2025, and it introduced a new billing mechanic worth knowing before you estimate a large-response workload. Streamed responses bill in 10 MB increments, rounded up, with a minimum of one billable request even for a response under 10 MB. A 65 MB streamed response bills as 7 requests (ceil(65/10) = 7) at the standard REST tier rate for that account's volume. If you're adding streaming for large payloads, build this rounding into your estimate rather than assuming one response equals one request.

What Actually Gets Billed, and What Doesn't

Before the rate card gets more granular, it's worth answering the question that trips up nearly everyone at some point: does a request that never reaches your backend still cost you?

Here's the one fact AWS confirms directly: a WebSocket message that fails authentication or authorization never counts as a billable message. It's excluded before metering ever happens, per the API Gateway FAQ.

For REST and HTTP APIs, that same clarity doesn't exist. The publicly available pricing documentation doesn't spell out whether a request rejected for an invalid API key, a denied Lambda authorizer, or an exhausted Usage Plan quota gets billed as a request. Treat that as genuinely unresolved rather than assuming either answer. If a worst-case budget depends on the outcome, verify it directly against your own account's billing data or through AWS Support before you rely on it.

What is documented and configurable is Usage Plans, and it's the more useful thing to plan around anyway. Usage Plans give you three real controls: rate (steady-state requests per second), burst (concurrent requests allowed before a 429), and quota (a target ceiling on total requests per API key, per day, week, or month). An API key that exceeds its quota is normally rejected before it can generate further backend charges, whether that's Lambda invocations or data transfer.

But these are targets, not guarantees. AWS's own CloudFormation reference for AWS::ApiGateway::UsagePlan states it directly: "In some cases clients can exceed the targets that you set. Don't rely on usage plans to control costs." Rate and burst limits are enforced with a token bucket that can admit short spikes above the configured rate, and API Gateway's own developer guide says throttling in general "is applied on a best-effort basis and should be thought of as a target rather than a guaranteed request ceiling." Treat a quota as a strong deterrent against runaway usage, not a hard spend cap.

There's also a blunter, account-wide backstop: the account-level throttle quota defaults to 10,000 requests per second with 5,000 burst capacity (lower in a specific set of newer, smaller Regions), shared across every API in that account and Region. It's a shared safety net for concurrency, not a cost control. A misbehaving API can throttle unrelated APIs in the same account unless Usage Plans isolate them first.

The bottom line for budgeting: don't plan around an assumption that Usage Plans cap your spend, and don't assume rejected requests are free across the board either. AWS's own guidance is to pair Usage Plans with AWS Budgets for cost alerts and AWS WAF for request-level control in front of the API, or to enforce limits in your own application code if a quota being exceeded would be expensive. Usage Plans reduce risk; they don't eliminate it.

The Charges That Bill Whether or Not Anyone Calls Your API

Rejected requests are the exception. The bigger cost story is the set of charges that bill continuously whether or not any request arrives. Four show up on your bill regardless of traffic: a provisioned cache, the load balancer behind an always-on VPC Link, a Route 53 hosted zone, and a Developer Portal. None care how busy your API is. Provision one and forget it, and the meter keeps running.

REST API caching (hourly, traffic-independent)

Caching is available for REST APIs only, and it bills by the hour based on provisioned size, regardless of how much traffic hits the API. The confirmed rate point is a 1.6 GB cache at $0.038/hour, which works out to roughly $27.36/month if you leave it running continuously in US East, US West, or EU Ireland. Caching isn't eligible for the free tier, and a cache hit still counts as a billable API call. That last part matters: caching reduces backend compute cost, not the API Gateway request charge itself. Weigh avoided backend cost against the fixed hourly charge before you provision, not after.

Seven other cache sizes exist (from 0.5 GB up to 237 GB), but only the 1.6 GB rate is independently confirmed here. Rather than guess at the rest, the API Gateway pricing calculator covers all eight provisioned sizes if you need an exact number for a different tier.

VPC Links: the load balancer bills, not the link

Private integrations run through a VPC Link, and here's the detail that trips up cost estimates: API Gateway doesn't charge a separate fee for the VPC Link itself. AWS's own whitepaper on private API integrations says it directly: pay for the NLB when the target is an NLB, or pay per-ALB-hour plus per-LCU-hour when the target is an ALB. What gets called "VPC Link pricing" in most write-ups is really just the underlying load balancer's own rate, relabeled.

VPC Links V1 are legacy and target an NLB only, billed at standard NLB hourly plus NLCU rates. VPC Links V2 are the current path: REST APIs can target an ALB or an NLB, and HTTP APIs can also target an AWS Cloud Map service. Whichever load balancer sits behind the link keeps billing on its own schedule for as long as it exists, ALB at $0.0225/hour plus $0.008 per LCU-hour, or NLB at its own hourly plus NLCU rate (both us-east-1). AWS doesn't publish NLB or ALB rates on the API Gateway pricing page itself, since they're not an API Gateway charge, so check the Elastic Load Balancing pricing page directly. Which load balancer type costs less depends entirely on your request rate, connection pattern, and average payload size, so there's no blanket ALB-vs-NLB answer here; run your own numbers through ELB's pricing calculator.

There's a real, AWS-documented lifecycle wrinkle worth planning around, separate from any of that billing. If no traffic crosses a VPC Link V2 for 60 days, it becomes INACTIVE and API Gateway deletes its network interfaces. That's not a quiet degrade: AWS's own developer guide is explicit that API requests depending on the link fail during that window. When traffic resumes, API Gateway reprovisions the network interfaces, which takes a few minutes before the link works again. None of this touches the ALB or NLB behind the link, since it was never billed through the link in the first place. That load balancer keeps running and billing the entire time, whether the link in front of it is active, idle, or has just had its interfaces reclaimed. If your traffic is seasonal or bursty rather than steady, test that failure-and-reprovision path before you rely on it in production.

Private APIs sidestep the VPC Link question entirely by using AWS PrivateLink instead, and they trade the data-transfer-out charge for PrivateLink's own hourly and per-GB fees. AWS's own worked example: 5 million calls a month, one Availability Zone, a full month, comes to $17.50 in request charges, $7.20 in VPC endpoint hours, and $0.16 in data processing, for $24.86/month total.

Custom domain names (Regional vs. Edge-optimized)

There's no separate API Gateway fee for a custom domain itself; the cost comes from what surrounds it. ACM certificates for API Gateway custom domains are issued at no cost. A new Route 53 hosted zone runs $0.50/month for the first 25 zones, though an alias record pointed directly at API Gateway doesn't add a Route 53 query charge on top. Edge-optimized domains route through CloudFront, which adds its own cost. Check Route 53 pricing or CloudFront's pricing page if you're comparing endpoint types on cost.

API Gateway Portals

Portals, launched in November 2025, introduced a billing model that older cost estimates don't account for. Each Portal costs $125/month, prorated hourly, and that price includes the first 10 PortalProducts (each supporting up to 40 endpoints). Additional PortalProducts run $12.50/month each. AWS's own worked example: two Portals, one with 10 PortalProducts and one with 25, for a full month, comes to $437.50/month combined, independent of how much traffic the Portal itself sees.

If you're standing up a Developer Portal for external API consumers, treat that $125/month as a fixed cost the moment it's provisioned, not something that scales with adoption.

Run your own cache size, VPC Link target, and Portal configuration through the API Gateway pricing calculator once you know which of these apply to your setup.

The Adjacent AWS Bills Riding Along With API Gateway

Traffic-independent charges are one kind of surprise. The other kind comes from services that ride along with API Gateway but bill on their own meter entirely, so your API Gateway bill can look reasonable while the total cost of running that API is not.

CloudWatch Vended Logs and detailed metrics

API Gateway has two log types, execution logs and access logs, both disabled by default. Once enabled, REST API execution logs are delivered through CloudWatch's Vended Logs pricing, the same tiered mechanism Lambda logs use: $0.50/GB for the first 10 TB ingested per month, dropping through $0.25/GB, $0.10/GB, and down to $0.05/GB as volume climbs through the 30 TB and 50 TB bands (confirmed for us-east-1). AWS recommends against enabling "Data tracing" in production, since it can log full request and response payloads, which is both a data-exposure risk and a driver of ingestion volume.

Detailed (per-resource, per-method) metrics are a classic hidden cost because they scale with your API's surface area, not its traffic. Each metric runs $0.30/month in the first 10,000-metric tier. AWS's own example, 2 resources times 4 methods times 1 stage times 5 metrics, comes to 40 metrics and $12/month, a charge that accrues even on a low-traffic API the moment detailed metrics are turned on. Check your metric count against the CloudWatch pricing calculator if you're auditing a chatty microservice layout, and see our CloudWatch pricing breakdown for the rest of that service's billing dimensions.

AWS WAF (REST APIs only)

WAF protects REST APIs only; it has no attachment path for HTTP or WebSocket APIs. Its own pricing stacks four ways: $5.00/month per Web ACL, $1.00/month per rule or rule group, and $0.60 per million requests processed. AWS's own worked example, 10 million requests a month, 19 custom rules, no managed rule group, totals $30.00/month. Model your own Web ACL against the AWS WAF pricing calculator before you commit to a rule set.

This matters directly if you're migrating from REST to HTTP for the request-charge savings covered earlier: HTTP APIs have no WAF attachment path, so that protection has to move somewhere else, or you accept the gap. That's a governance decision, not just a pricing one.

Lambda and X-Ray behind the gateway

Lambda behind API Gateway is a fully separate bill: standard per-request pricing plus per-GB-second compute charges, referenced here at $0.0000166667/GB-second (US East N. Virginia, first tier). A low-request-count but long-duration or high-memory function can dominate total spend even when API Gateway's own charge is trivial, our Lambda provisioned concurrency cost guide covers that trade-off in more depth. X-Ray, if enabled, bills $0.000005 per trace beyond the first 100,000 traces recorded per month, which is generous enough that most low-to-mid-traffic APIs won't hit it.

Free Tier, and What Changed for New Accounts in July 2025

Free tier covers a prototype. Here's exactly what's included, and what changed recently enough that older estimates may have missed it.

The classic allowance, available for up to 12 months after AWS sign-up, gives you 1,000,000 REST API calls, 1,000,000 HTTP API calls, 1,000,000 WebSocket messages, and 750,000 WebSocket connection-minutes per month. Exceeding any of these just triggers standard pay-as-you-go rates for the overage, no penalty. REST API caching is explicitly excluded from this allowance even during the 12-month window.

Starting July 15, 2025, new AWS customers also receive up to $200 in AWS Free Tier credits, usable across eligible services including API Gateway. At sign-up, you choose between a free plan (available for 6 months) or a paid plan, and any remaining credit balance rolls onto your bill if you upgrade. AWS describes both the $200 credit and the classic per-service allowance on the same pricing page without fully explaining how the two combine for an account created after that date. If your free-tier math needs to be precise for a new account, check your own account's Billing console rather than assuming a specific interaction.

One more thing worth flagging if you're planning a multi-account setup: whether the free tier is evaluated per account or aggregated across an AWS Organization's linked accounts isn't addressed anywhere in the documentation. Don't assume either way.

In practice, a genuinely low-traffic prototype runs within the free tier without issue. The moment caching, a second API type, or real production traffic enters the picture, expect a bill.

What This Costs at 10M, 100M, and 500M Requests a Month

Free tier answers the "is this free to start" question. The one most readers actually have is what happens once traffic is real. Running REST and HTTP API's own published tiers out to three volume levels gives a clear answer, in request charges only, before anything from the sections above gets added on:

The REST figure at 500M comes from applying the tiers in sequence: 333M requests at $3.50/million plus the remaining 167M at $2.80/million. HTTP at the same volume is 300M at $1.00/million plus 200M at $0.90/million. These are illustrative calculations built from AWS's own published rates, not AWS-published totals, and they don't include data transfer, caching, VPC Links, CloudWatch, WAF, or backend compute, all of which are real costs on top of this. The gap between the two columns widens with volume, and it lands close to AWS's own "at least 71% lower" claim by the 500M mark, which is a useful sanity check on the arithmetic.

For a sense of what genuinely high volume looks like, AWS's own published example runs 15 billion requests a month at 4 KB responses to $41,502.94/month total, request charges and data transfer combined (covered in full in the REST API section above).

Once request volume becomes the dominant driver of your bill and the workload doesn't need REST-only features, WAF, Usage Plans/API keys, caching, or Edge-optimized endpoints, migrating to HTTP APIs is the single biggest lever available. The next section covers that trade-off, along with other ways to bring this number down. To run your own traffic through the math, the API Gateway pricing calculator handles it directly.

Cutting Your Bill Without Cutting Features

Now that the scale question has a number attached, here's what to actually do about it. None of these require re-architecting your API from scratch, and none of them depend on a commitment discount: API Gateway isn't covered by any of AWS's four Savings Plans types, so tiered volume pricing, architecture choices, and adjacent-service tuning are the entire toolkit.

Migrate REST to HTTP where the feature list allows it. You lose WAF attachment, Usage Plans/API keys, per-stage caching, and Edge-optimized endpoints, but for a workload that doesn't need those, AWS's own published case study showed a real-world drop from $1,870.26/year to $534.36/year for the same traffic. That's a genuine, source-backed lever, conditional entirely on whether your workload needs the features you'd be giving up.

Treat caching as a backend-cost lever, not a request-cost lever. Since cached responses still bill as API Gateway requests, caching only pays for itself when the backend compute cost you avoid (Lambda invocations, database queries) exceeds the fixed hourly cache charge for the period. Size the cache to the workload, not the other way around.

Enable payload compression for REST APIs. The minimumCompressionSize setting (0 to 10 MB) triggers automatic response compression. AWS's own Compute Blog test measured a 1 MB JSON response shrinking to 220 KB, a 78% reduction, with latency improving from 660 ms to 550 ms in that test. Since data transfer out bills per GB, this directly reduces that line item. Very small payloads may not benefit, and compression adds CPU overhead worth load-testing against your specific payload profile before rolling it out broadly.

Turn down log verbosity. Set execution logging to Errors-only instead of Errors-and-info, and avoid Data tracing in production. Since logs bill per GB ingested under CloudWatch's tiered Vended Logs pricing, cutting verbosity is a direct, immediate reduction in that charge.

Pair Usage Plans with a real cost alert, not just a quota. A quota is a target that clients can exceed, per AWS's own guidance, so it deters runaway usage rather than capping it. Set up AWS Budgets alerts on the API's cost allocation tags, and add AWS WAF or application-level rate limiting in front of any API where a quota breach would be genuinely expensive.

If you're weighing API Gateway against alternatives for a specific route: Lambda Function URLs carry no separate endpoint charge at all, you pay standard Lambda pricing only. ALB bills on an hourly charge plus LCU rates that depend heavily on average payload size, not just request count. There's no AWS-published crossover table between the three, so run your own payload size and traffic pattern through the relevant calculators rather than trusting a rule of thumb.

How AWS API Gateway Pricing Compares to GCP, Azure, and Kong

If you're evaluating API Gateway as one option among several, it's worth knowing where the comparison is and isn't useful. AWS's model is what this entire article has covered in detail: per-million-request tiers that decrease as volume grows, priced independently by API type.

GCP, Azure, and Kong each publish their own pricing pages with different structural models, subscription tiers or platform capacity rather than AWS's pure pay-per-request approach in many cases. This article is AWS-specific by design and doesn't carry independently sourced dollar figures for any of those vendors, so it won't manufacture a side-by-side rate table. If you're comparing vendors, go to each one's own pricing page for exact current numbers rather than trusting a summarized comparison, since these pricing models don't map cleanly onto each other.

What is worth knowing directionally: a subscription or capacity-based model changes how a workload's cost curve looks as it scales, compared to AWS's pure per-request tiers. If your traffic is genuinely bursty or unpredictable and you'd strongly prefer a flat monthly cost over a usage-based one, that's the concrete signal worth comparing on, not a blanket "which vendor is cheaper."

Catching Cost Regressions Before They Reach Production

A short set of levers gets you most of the way to a lower bill today. The harder problem is making sure the same charges don't creep back in after the next deploy.

Every traffic-independent charge covered above, an oversized cache, an always-on VPC Link, a Portal left enabled in a dev stack, detailed CloudWatch metrics turned on and forgotten, is a configuration choice made once in Terraform or CloudFormation and then billed forever until someone notices. Usage Plans and account-level throttle quotas are real AWS-native spend controls, but they only work if someone remembers to configure them per API. A code-review step that checks for a Usage Plan on every REST API before merge closes that gap before it ships.

That's the gap CloudBurn is built to close. It scans Terraform and CloudFormation for exactly this kind of cost anti-pattern, an API Gateway cache resource with no matching traffic justification, a REST API with no Usage Plan attached, a Portal or detailed-metrics configuration with no corresponding cost review, directly in CI, before it merges. The same rule set also runs against a live AWS account, so it can find what's already running: caches left provisioned after a feature was deprioritized, VPC Links and their target load balancers nobody tore down, Portals nobody sunset. See our shift-left FinOps approach for the reasoning behind catching these in code review rather than on next month's bill.

If you've read this far because a bill already surprised you, the fix isn't just fixing this one API. It's catching the next oversized cache or forgotten VPC Link before it ships.

Frequently Asked Questions

Key Takeaways

The per-request rate (REST at $3.50/million, HTTP at $1.00/million on tier one) is the smallest part of most real API Gateway bills. Caching, VPC Links, custom domains, and Portals bill whether or not traffic shows up, and CloudWatch, WAF, and Lambda ride on their own separate meters. Only one billing-edge-case question has a confirmed AWS answer (WebSocket authentication failures don't bill); for REST and HTTP, budget around Usage Plans and quotas rather than an assumption about rejected requests. REST-to-HTTP migration is the single biggest lever when your workload doesn't need WAF, Usage Plans, caching, or Edge-optimized endpoints. API Gateway added two new billing dimensions in November 2025, Portals and response streaming, so any estimate written before that date is missing real line items.

A manual AWS cost estimation workflow is a one-time snapshot. Run your own traffic, cache size, and API type through the API Gateway pricing calculator to get a number specific to your setup, including all eight cache sizes and Developer Portal costs. It doesn't price VPC Links, WAF, CloudWatch, or Lambda, since those bill on their own separate meters, so pair it with the ELB pricing page for VPC Link targets, the AWS WAF pricing calculator for REST API protection, and our CloudWatch pricing breakdown for Vended Logs and detailed metrics.