API security: what an API gateway already covers and what the specialist tier adds

The gateway bill is a traffic bill, not an API bill

Amazon API Gateway publishes a pay-as-you-go model with no minimum fees and no upfront commitments. For HTTP APIs and REST APIs the charge is for the API calls received and the amount of data transferred out, and there are no data transfer out charges for Private APIs. A team running 200 APIs therefore does not pay 200 times anything; it pays for the calls those APIs serve.

The free tier gives one million REST API calls received and one million HTTP API calls received per month for up to 12 months, alongside one million messages and 750,000 connection minutes for WebSocket APIs, available to new AWS customers. After that, standard usage rates apply. The tier structure is published in bands rather than as a single rate: the REST API pricing page lists a first band up to 333 million calls, then bands to 667 million, to 19 billion and over 20 billion, and the HTTP API page splits at 300 million.

That shape matters for the comparison. A gateway bill is driven by request volume, so an estate with many low-traffic internal APIs can publish a large surface for very little money, while one high-traffic public API can dominate the invoice. The number of APIs, which is what a per-API security product meters, does not appear in the gateway's billing mechanics at all.

What the gateway page does not price, and what to ask for

The published pricing page is a metering document. It describes calls, data transfer, caching and WebSocket messages, and it states that caching is optional and charged hourly per stage at a rate that varies with cache size. It does not describe a per-API security charge, because there is no such line in the model.

That absence is the finding, not a gap to fill. A buyer comparing the gateway against a specialist API security product needs to establish what the gateway enforces at the edge and what it leaves to another layer, and the pricing page will not answer it. The question to put to the account team is specific: which of the protections on the shortlist are included in the call charge, which require another AWS service, and which are not offered.

The same applies to the specialist tier. No price for a per-API security product appears in these pages, so any figure in a business case is the buyer's own quote, not a published rate. Ask for the unit of metering, the treatment of dormant APIs, and whether the count is taken at contract signature or measured monthly, because a 200-API estate that grows through the term will be repriced under one model and not the other.

Where the two models diverge at 200 APIs

The gateway's cost is a function of traffic. A 200-API estate serving modest internal volume may sit inside or near the free tier allowances for its first year and cost very little after that, because the bands only bite at hundreds of millions of calls. The same estate under a per-API model carries a licence line from day one, whether or not those APIs receive traffic.

The divergence runs the other way for a small number of very high-traffic APIs. There, the per-million-call charge is the dominant number and a per-API licence looks cheap by comparison, because the specialist product is not metering the traffic that drives the gateway invoice. Neither model is wrong; they are counting different things, and the estate's shape decides which count is larger.

Caching is the one place the gateway page shows a cost that scales with configuration rather than traffic. It is charged hourly per stage and varies with the cache size selected, with no long-term commitment. A team that adds a cache to every stage of every API should price that separately, because it is the line most likely to surprise a forecast built only on call volume.

The shortlist, on the criteria the billing model moves

Three options are worth putting side by side for this estate: the gateway alone, the gateway plus a specialist API security product, and a specialist product fronting the estate. The first is priced by the published call bands. The second carries the call bands plus a licence whose price is not published in these pages. The third replaces the gateway's metering with a licence, which only makes sense if the gateway is not otherwise required.

The criteria that move are the API count, the traffic distribution and the term. A per-API product makes the count the number that matters, and a 200-API estate should ask how dormant or internal-only APIs are counted. A per-call gateway makes the traffic distribution the number that matters, and the estate should model its busiest APIs against the published bands before assuming the gateway is the cheaper route.

One published detail cuts across all three: AWS PrivateLink charges apply when using Private APIs in API Gateway. An estate that keeps most APIs private is therefore paying a networking line that has nothing to do with either the call charge or a per-API licence, and it belongs in the comparison.

The decision rule

Choose the gateway alone if the estate's APIs are mostly internal, its monthly call volume sits comfortably inside the published bands, and the protections the team needs are already covered by the services it runs. In that case the per-API licence is buying a count the business does not yet need to meter.

Add the specialist tier alongside the gateway if the estate has a published, externally reachable API surface and the team cannot answer, from the gateway's own documentation, which protections apply to each of those APIs. The licence then buys an inventory and a control set the call charge does not describe, and the 200-API count becomes the negotiating unit.

Wait if the estate is still inside its first 12 months of free tier allowances and has not yet measured its call volume against the published bands. The gateway bill is not yet a real number, and a per-API commitment signed before that measurement is a commitment to a count rather than to a cost.