AWS API Gateway Pricing Explained

Where do I start on this one?
I’m thinking we’ll cover what API Gateway actually is, then the pricing will make sense.

Right, yes, let’s do that.

I’ll try and cover everything you need to know about API Gateway pricing, but if you want more detail, the pricing page on the AWS website is here: https://aws.amazon.com/api-gateway/pricing/

What is API Gateway?

API Gateway is a managed API service (it’s somewhat on the nose with the name).

It connects to a whole raft of other AWS services and will send traffic on to external endpoints too.

When I say a raft, I mean it. The list is as follows:

• EC2 (including ALBs & NLBs)
• Lambda
• Step Functions
• SQS
• DynamoDB
• Kinesis
• Eventbridge
• VPC links
• Or the other 96 services that support direct integration
• And anything that can work on ports 80, 443, and 1024 – 65535

The upshot of this massive list of supported integrations is that you can put API Gateway in front of any workload you can think of.

• Basic call and response? Lambda integration. Or a direct integration with DynamoDB.
• Kicking off complex processing? Step function integration.
• Already have something in EKS and need a web response? Pop a load balancer in front of the cluster, and have it connect there.

Aside from the list of integrations, API Gateway has another trick up its sleeve – it supports WebSockets, in addition to RESTful APIs. It breaks REST APIs into 2 further categories, which I’ll touch on shortly.

If you’re not familiar, a WebSocket connection is a long-lived connection to a remote resource, which allows for bi-directional communication. They’re used quite a bit for real-time chat applications, multiplayer games, and things like that.

Security for WebSockets is done through either IAM or custom Lambda authorizers, but if you need a web socket connection, odds are a custom authorizer is also needed anyway.

For REST APIs the offering is great too. API Gateway breaks it down into 2 options. HTTP APIs, which are simple call-and-response integrations to a backend, typically used with a Lambda integration, and REST APIs, which are the full-featured option, allowing manipulation of the request between the caller and the integration.

What about Security?

REST API security is available through IAM, AWS Cognito, VPC Endpoint policies, tag policies, or custom Lambda authorizers.

The HTTP API’s security is a little slimmer, as it’s a slimmed-down offering of the REST API. In my opinion, the best option (which isn’t available on the other two) is the plug-and-play JWT-based security, using an external JWT provider (like Firebase, which is pretty good, actually) or AWS Cognito. IAM and custom authorizers via Lambda are also supported.

As you’d expect, TLS connections are also fully supported across the board, using certificates hosted in AWS Certificate Manager. I’ve long been a fan of Certificate Manager, as managing TLS certificates is a job that should be firmly consigned to history.

That’s all a bit heavy, so let’s have some diagrams to show you some examples.

In this case we have a user requesting “something” from our service via an API Gateway REST API. The request goes from API Gateway to the external JWT authorizer, before being sent on to the lambda backend integration. The lambda processes the request and sends the response back to the gateway, which in turn sends it to the user.

Here we have a slightly different flow. The user is requesting data from an endpoint, and is authorized by a Lambda custom authorizer, using whatever logic is appropriate. API Gateway then integrates directly with DynamoDB to retrieve the relevant data, before returning it to the user.

Right, that’s the short version; now we can get to the meat of why you’re here.

AWS API Gateway Pricing

So, what does all this cost? To start with, not a lot.

Within the first 12 months of account opening, API Gateway has an attractive free tier (probably to encourage usage and get you hooking enough things up to it that moving away from it will be annoying, but I’m cynical).

In the first 12 months, you can use the following:

• 1 million HTTP API calls
• 1 million REST API calls
• 1 million WebSocket messages & 750,000 connection minutes

PER MONTH!

So you could quite easily make 30 million requests across the 3 types and pay precisely nothing. That’s mad.

Once your introductory 12 months are over, or if you go above these allowances, the prices are still incredibly low. HTTP APIs cost $1 per million requests, of up to 512 KB of data per request, for the first 300 million requests and $0.90 per million after that. The free tier doesn’t actually look so great now, does it?

REST APIs are a little more expensive – $3.50 per million for the first 350 million. $2.80 per million for the next 667 million. That’s a bit of an odd number, but it’s for a reason. The next pricing tier is the “next 19 billion”, that’s billion, with a b. For the “next 19 billion,” it’s $2.38 per million, and above 20 billion, it’s $1.51 per million. To be clear, this is per month. I honestly can’t think of an API busy enough to serve 20 billion requests a month outside of AWS, Google, Microsoft, and the like.

To demonstrate quite how cheap this is, 100 million requests in a month would cost a grand total of $100.

That’s a cost of $0.000001 per request. For a service that’s available 24/7, is fully managed (so is already highly available) and has precisely zero dollars of standing cost.

Standing Cost

Now, standing cost. Yes. OK, it does have some, really. Some of the time.

If you’re genuinely serving 100 million requests per month (for context, that’s slightly more than 38 requests per second), you’re going to want to think about caching. That’s an option, but it isn’t free.

You pay based on the size of the cache you provision, starting at $0.02 per hour for a 0.5 GB cache and up to $3.80 for a 237GB cache (another weird number, but OK).

So again, staggeringly cheap for something that you provision and forget – and almost certainly cheaper than the salaries of the team of engineers needed to create and manage this on-premises.

Websockets

Websockets are charged a little differently – as you might have gathered from the free tier being in connection minutes rather than per request.

As WebSockets are long-lived bi-directional connections, you pay based on how long you’re connected and how much data is transferred. $1 per million messages (32KB per message) up to the first billion and $0.80 per million after that. Connection minutes are charged at a flat rate of $0.25 per million.

No caching here, but it’s not really a request type that supports it.

What’s the Catch?

There isn’t one. Not really.

Yes, there are extra charges, but none of them are for API Gateway itself.

If your API calls a Lambda, you pay for the Lambda execution. If it’s connected to a VPC Private Link, you pay for the private link. If it’s web-facing and sends data “out” to users, you pay the EC2 data transfer rate. Any logs generated are sent to CloudWatch Logs, and you pay the ingest and storage rates for that. Logs are optional here, though I highly recommend you turn them on.

None of that is unreasonable, I don’t think, especially when you consider this is for a service that’s available 24/7, is fully managed and has a frankly ridiculous uptime.

What are the Alternatives?

You could do all of this on-premises, but that’s difficult, complicated, and quite expensive.

You could, however, use another AWS service – an Application Load Balancer (ALB).

ALBs can talk to a subset of the services that API Gateway can, but it’s primarily compute-focused (so EC2s, Lambdas, or other load balancers). This means that whilst you can’t use it to directly query DynamoDB or kick off a Step Function, you can use it as a way to host web-facing Lambdas for basic call-and-response setups. Essentially they’re a competitor for the HTTP API offering.

This is useful to know, as the pricing on ALBs scales differently – they have a higher standing cost but a much lower cost-per-request, as it’s entirely based on data transfer.

What this means in practice is if you have a high number of low data volume requests (1 million per day at 5KB or so), ALBs come out cheaper than API Gateway – even with WAF turned on.

Full disclosure, I didn’t do the maths on this myself. I used the data from this blog post.

The Takeaway?

Unless you have a very specific high-traffic, low-volume use case with well-defined usage patterns, API Gateway is the simplest, easiest, and fastest way to get going with an API offering.

Hopefully, this has given you enough insight into API Gateway pricing to get started on your own projects, and if you want help configuring anything or explaining all of this to your management team, why not reach out to us here at Logicata.