Understand AWS API Gateway Pricing
Learn about three different types of Amazon (AWS) API Gateway APIs and their pricing, how you're billed for each, and how to optimize costs.
Learn about three different types of Amazon (AWS) API Gateway APIs and their pricing, how you're billed for each, and how to optimize costs.
So you have an idea for your next project, and you know you want to use serverless, but how do you send requests to it? While you can directly call a lambda using a URL, building an entire API that way goes against a lot of best practices. That's where Amazon's API Gateway comes in.
In this article, you'll see what the three versions of Amazon API Gateway are, get some context on how you're billed for each of them, and see a few strategies for how to optimize their costs.
In a traditional three-tiered application, you would have a web server as a client's first point of contact. That server would then provide API paths that the client could request data from. But in a serverless world, this setup doesn't work.
In serverless, you only run compute in response to an event, so you can't have a lambda sitting there waiting for a request to come in. That's the job of API Gateway. It becomes the entry point that your web application calls into. It then maps those requests out to lambdas, or other services, and returns the result.
To understand how you're charged for an API Gateway, you first need to understand the different types of API Gateways available. There are three of them: REST, HTTP, and Websocket.
REST API is the original type supported by API Gateway. It's a feature-rich solution to create a serverless REST API. On the downside, it costs more than the HTTP option, has a higher latency, and can't send events to clients proactively.
HTTP API is a fairly new offering. It has fewer features than the REST API offering, but it has lower latency and is substantially cheaper. It was created by AWS to be faster and more cost-effective. This should be your go-to solution unless you need some of the features provided by REST APIs. While there are too many feature differences to write out here, you can see a full side-by-side comparison of features in the Amazon API Gateway Developer Guide. The most notable features missing from HTTP APIs are caching and API Keys.
While both of the previous offerings are solutions to the same problem, the WebSocket API solves the problem of how to send data to clients proactively. It does this by maintaining a connection with the clients so it can send data as needed.
Both REST and HTTP APIs charge based on the number of requests received. Since WebSocket APIs need to maintain a list of client connections, you're charged for both the amount of time that connections are left open, and the number of messages sent back and forth.
API Gateway takes a pay-as-you-go approach, much like other serverless services offered by AWS. This means you don't have to pay for idle resources, and the amount you pay is directly tied to how much it's used, instead of how much time you want it to be available.
There are a few issues that may come up in paying for an API Gateway. At the top of the list are cascading costs and unpredictability.
Cascading costs happen when your API Gateway calls another service that you also have to pay for. The most common service to be called is AWS Lambda. When this happens, you have to pay for the request in API Gateway, the Lambda execution costs, and the cost of any other services that the lambda calls into.
While pay-as-you-go billing means you're not paying for unused resources, it's also less predictable than paying for a server up-front for a whole month. You'll have to have good billing observability set up to counteract this.
While pay-as-you-go billing means you're not paying for unused resources, it's also less predictable than paying for a server up-front for a whole month
If you just recently set up your AWS account, you can take advantage of a generous free tier. You get one million REST or HTTP API requests per month for your first year.
Now that you've decided to use an API Gateway and seen how pricing works, let's take a look at how to optimize costs.
Before you start spending time optimizing costs, it's a good idea to enable cost allocation tags for all of your projects. If you tag all of your resources with their project name, then you'll be able to generate a report at the end of the month that shows exactly how much you spend on each resource for a specific project. For more details, see A Complete Introductory Guide to AWS Cost Allocation Tags.
If you'd like to get some more context into where your AWS costs are going, Cloudthread has a product that gives each of your development teams insights into their cost-efficiency.
If you're creating a standard API and don't need the advanced features of a REST API, then you can get a discount of about 70% by using an HTTP API. This works on a case-by-case basis. If your API needs to be private or needs to transform request bodies, then you don't have a choice.
This is my favorite way to save costs, since it removes the double-billing aspect of calling lambdas. You can set up different paths to directly call other AWS resources, then use a VTL template to translate the result into the correct response structure. While VTL templates can be difficult to work with, this does remove lambda cold start times and runtime costs.
If you need to use lambdas for some business logic, and that logic is consistent, you can enable caching and save on the cost of calling that lambda every time. This works well when you have a lot of people making the same request, and a long-running lambda that generates the response. As an added bonus, your users will get faster response times too.
To determine if you'll save money by using a cache, track your lambda expenses for a month using tags
To determine if you'll save money by using a cache, track your lambda expenses for a month using tags. Right now, a 0.5 GB cache costs $14.40 per month (see the Pricing Page for current prices). So, if your lambda costs substantially more than that, you may be able to save money by enabling the cache.
When you generate API Keys, you can add a usage plan to keep them from running up your bill. You can set request rate limits and quotas with a usage plan. If you have customers who call into your API directly, enforcing this limit can keep them from spamming you with requests that you have to pay for.
You've seen what role Amazon API Gateway plays in a serverless application, got some information on how to choose between the three different types of APIs available, and learned a few tips on how to track and reduce costs. You should now be able to use this information to build your next serverless API at an optimized cost.
