Saving Money By Replacing API Gateway With Application Load Balancer's Lambda Integration

Replacing API Gateway with Application Load Balancer could save you thousands of dollars on your bill every month. API Gateway is a great product, and offers a generous free tier. For personal projects and small sites that need one or more serverless APIs, it may be all you ever need. But, if your site is larger and gets a lot of traffic to your APIs, API Gateway might be the least cost-effective serverless service you use. Application Load Balancer provides an alternative for sites that have enough traffic to make the hourly pricing worthwhile, but have too much traffic to be cost-effective with API Gateway. I recently converted some APIs from using API Gateway to using Application Load Balancer, and this article explains why. When I get some actual billing data, I’ll update the article to give you an idea of actual realized cost savings, but for now I’ve included the estimated savings based on current bills (APIGW) and the AWS cost calculator (for ALB costs).

Why API Gateway is Expensive For a Lot of Usecases

For me, the main problem with API Gateway is the $3.50 per million request pricing. That may not seem like a lot for many small sites, but when compared to other serverless technology, it’s actually quite expensive. Here’s a breakdown of the costs for the three services involved: Lambda, DynamoDB, and API Gateway, with a comparison of the estimated costs if you replaced API Gateway with the recently-announced Application Load Balancer integration with Lambda:

Save money by replacing your API Gateway with Application Load Balancer

In this example, I have an API that’s averages 450 requests per second. That’s 38,880,000 requests per day, which equates to $136 per day, or over $4,000 a month for API Gateway. The API uses Lambda, most calls take 100-200ms, with 256MB of memory allocated. The Lambda functions call DynamoDB where I average around 3,100 provisioned RCU and 1,215 provisioned WCU.

Total costs for those 1.2 billion API calls each month?

  • Lambda: around $1,000
  • DynamoDB: around $1,000
  • API Gateway: $4,163

API Gateway is a great service, but for what I need frankly I’m just not getting enough out of it to justify it costing 4x the cost of my compute and database service - that’s extremely disproportionate.

What About Tiered Pricing?

A little over a month ago, AWS announced API Gateway tiered pricing. Would that help? Not enough. In the example scenario described above, I’m generating about 1.2 billion requests to API Gateway each month. But remember, at that scale, you want to be global; the API I’m talking about is deployed in three regions. If you divide my 1.2 billion requests evenly across three regions (in reality, the split typically ends up more like 40%, 35%, 25%) you’d be around 389 million requests per region. Since the tiered pricing is per region, that means you’d only have about 56 million requests priced at the second tier. So, your bill would be $3,500 at the first tier (333 million req * 3 regions / 1,000,000 * 3.50), and $586 at the second tier (the remaining 167 million requests at $2.80 per million. So, while I appreciate the efforts the API Gateway team made in offering a tiered pricing scheme, it still leaves the API Gateway part of my bill disproportionately high when using it as simply a Lambda invoker.

How Would Application Load Balancer Save Money?

When AWS announced at re:Invent 2018 that Application Load Balancer now supports calling your Lambda functions, I jumped for joy because of the potential for savings. I run this API in three regions (thank you DynamoDB global tables!), so I’d need an ALB in each region. ALB’s are priced out by the hour, and depending on the region you’re looking at around $15-$20 per month for the hourly cost. Then there’s this extremely complex set of metrics that equate to “LCUs” (load balancer cost units), and takes into account the number of new connections each second, active connections, bytes processed by the ALB, and the number of routing rules it needs to evaluate. All said, my best guess calculations are that I’ll average around 20 LCU’s aggregate across my three regions, at a whopping cost of another $115. So, all said, I expect to pay around $166 per month for ALB, whereas I’m paying $4,163 per month for the exact same service from API Gateway. (If my calculations turn out to be wrong on LCUs, I’ll update this article.)

How to Choose Between Application Load Balancer and API Gateway

API Gateway has a lot of features that ALB does not have. If you need those features, then the cost may be worth it for you. To find out more about those features, see my article on the technical differences between API Gateway and ALB.

On the other hand, if you’re reading this article it’s likely you’re a serverless fan. And if you’re a serverless fan, you’re probably using API Gateway in a very “vanilla” way - likely with its proxy integration that makes it a straight pass-through for requests. If that’s the situation you’re in (and you’re not using features I describe in that article like custom authorizers), then the decision-making process becomes primarily about costs.

Here’s what you need to consider: Application Load Balancer will cost you - at minimum - around $15 per month because it’s billed hourly. If you run your API in multiple regions, multiply that $15 (or up to around $20 for some regions) by the number of regions you have. $15 (ALB’s cost) worth of API Gateway calls will net you around 4.3 million API calls in the month (well, 5.3 million if you count the free tier). So, if your API is small enough to fit under that number of calls, stick with API Gateway - it’s simpler to use. But, 5.3 million API calls is only around two requests per second. So, if your API is used very much at all - or even if you have DNS health checks enabled - you could easily end up paying more for API Gateway than you would for Application Load Balancer.

So, how do you decide? Well, if you need the features of API Gateway, then you have to pay for them. But if you have a high-volume API and can get by without those features, look into ALB (more on how to do that below). Dougal Ballantyne, the Head of Product for Amazon API Gateway made basically the same observation when asked his opinion on when to choose one over the other.

Websites Powered by Lambda

We generally seem to focus on APIs when talking about serverless Lambda-powered HTTPS endpoints. I think that’s just because that’s what most of us have started with. But the next big thing that you’re surely going to see happening is entire websites and website frameworks being built to run as Lambda functions. When you get into that level of traffic, it’s going to definitely be more intuitive and cost-effective (for all but the smallest sites) to use Application Load Balancer with Lambda; API Gateway just isn’t made for that kind of usecase.


API Gateway is a great product, and I’ve relied heavily on it for nearly four years. But it was really built and its pricing modeled after a much different usecase - of being a real API gateway to possibly legacy services that need things like request and response mapping, offloading of authn and authz, rate limiting, et cetera. Now that we’re talking about using it as a simple pass-through to invoke a Lambda function over HTTPS, we’ve just brought a Mack truck to a bicycle race - we don’t need those features. Application Load Balancer’s new integration with Lambda may be exactly what you need to take your serverless APIs and websites to the next level.

But how do you set up an ALB in front of your Lambda? And what code changes will your Lambda need? I’ve answered those questions for you in the next two articles in this series:

  1. How to Set Up Application Load Balancer With Lambda

  2. API Gateway vs Application Load Balancer—Technical Details

If this article helped you learn about ALB and Lambda, helped you make a business decision, or helped you do something fun and exciting, please let me know. Leave a comment below!

Stay Informed

Subscribe to the Serving of Serverless newsletter or follow me on Twitter. I’ll keep you current with the serverless world, new training resources, and I will never sell or share your contact information.