Making rate limiting in AWS less terrible

Full disclosure, it is still terrible. I don’t promise it wouldn’t be, just rather less terrible.

There are lots of bad ways to do this. I don’t think there are any best practices unfortunately. Each comes with its own set of drawbacks.

Realistically, you have an API. You always have an API, if you didn’t you probably wouldn’t be reading this article in the first place. Your API may be deployed behind APIGW using Lambda. Or maybe it’s an ALB handling your TLS Termination for your containerized compute. At some point, you are going to figure out that you need rate limiting. It’s not usually an if, but rather a when. And when that time comes, it’s not per-IP or per authenticated account, but per user rate limiting.

Too often the advice in AWS is “Throw a WAF at it”. And that’s not exactly wrong, but it’s not the nuanced answer you’re looking for either. What if you did do per-IP — would that really not work? What about somehow rate limiting on the JWT the user is already sending? I’ll get to all of that and more.

But first, why do you even care?

Rate limiting solves a real business problem. And usually more than one. And the reason you need to be clear about which problem you’re solving is that different motivations lead to different architectural choices, and most of the bad solutions out there come from not being specific about what you’re protecting and most importantly why.

Protecting expensive downstream resources. Your API calls a database, a third-party service, or triggers compute that costs real money per invocation. One user hammering an endpoint can run up your bill in minutes . Without rate limiting, your cost model is “whatever the most aggressive user decides to spend on your behalf.” In the world of today, usually there is some threat actor, just desiring to use your solution as a database  or as pure compute.

Maintaining your uptime SLA. This is the one people underestimate. Rate limiting isn’t just about cost or abuse, it’s a real and vital strategy for uptime . Blocking malicious traffic before it saturates your origin is what keeps your service viable for the users who actually matter.

Enforcing fair usage across tenants. In a multi-tenant system, you’ll have shared resources. And one tenant over consuming allocated capacity will degrade the experience for everyone else. Rate limiting is the mechanism that prevents that.

Protecting yourself from your own customers’ bugs. And not every spike is malicious. A customer could easily ship a mobile app with an infinite retry loop, or a misconfigured webhook fires on every event. Which then means, you’re suddenly absorbing ten thousand requests per second from a single client. Your SLA doesn’t care whether the outage was caused by an attacker or by one customer lambda-bombing themselves.

No matter where you go, rate limiting is not just a feature. Fundamentally, you will get to the point where it’s required infrastructure that protects your system from what the outside world can throw at it. And the hard part isn’t deciding you need it; but rather implementing it correctly without burying you with the mountain of cloud maintenance.

I don’t know if this has been written before. But enough people get rate limiting with API Gateway wrong that another post on the topic can’t hurt.

There are so many things wrong with AWS API Gateway (APIGW), such that this article could be dedicated to just that. But instead I’ve taken a different focus. But in order to that I still need to touch upon at least the relevant parts.

APIGW has two forms: REST (V1, Legacy) and HTTP (V2). V1 is called REST because it supports OpenAPI Spec v2.0 for model validations, has a notion of documentation, lets you automatically deploy a CloudFront distribution on top of your API, and does rate limiting using what they call Usage Plans .