Hello there! Long time no see! Let's get back to our series about Amazon Verified Permissions!
The last few months haven't brought much news in AVP, other than the addition of tags (which should have been added a long time ago), but a few days before re:Inforce, we got a real game changer: a price change.
As we know, AVP has many advantages, but the biggest drawback has always been the price. For a new service, this made it very difficult for customers to adopt. I've conducted many workshops, talks, and a large implementation around AVP, but this pricing has always been a pain point for many people.
In this blog post, I want to share my perspective on the price change based on the use case I implemented with my team.
Recap on pricing
Until today, pricing looked like this: we paid for the number of authorization requests, and depending on how many requests we made, we had several tiers. The more requests you made, the less you paid per request (but this only made sense with a large number of requests).
We also have a cost for Policy management requests, but it's a small cost for managing policy stores.
Let's look at a 70 million requests scenario monthly (our current volume):
First 40 million requests: 40,000,000 × $0.00015 = $6,000
Next 30 million requests: 30,000,000 × $0.000075 = $2,250
Total: $6,000 + $2,250 = $8,250 monthly => $99,000 yearly
Such a price can cause a big headache. Often in smaller companies, this is the entire annual AWS budget, not just for one authorization service.
Cache?
When talking about AVP with different people, the discussion always went to: "Well, okay, but we can always cache authorization decisions so we don't have to pay so much for AVP." And it's true - this is especially efficient if you have M2M flows with lots of repetitive requests in a short period.
I presented our use case for AVP, handling authorization for 70 million API requests monthly. This consisted of traffic on API Gateway and monolithic apps - API calls only.
In my Re:Invent 2024 presentationI presented our use case for AVP, handling authorization for 50 million API requests monthly (currently it's 70 million so in this blogpost I will focus on this number). This consisted of traffic on API Gateway and monolithic apps - API calls only.
I also presented how we built the cache for AVP (API Gateway with its built-in cache mechanism, and how we built our own cache). You'll see that we cache up to 98% of requests when we have 70 million authorization requests per month (currently)!
To be more precise:
Total authz decisions: 70.7M
Direct AVP: calls1.4M
Cache hits: 69.3M
Unfortunately, AVP doesn't have a built-in cache option.
If you use AVP in a Lambda authorizer attached to API Gateway, you can use the authorizer cache mechanism - just remember to set the correct cache keys! If you use it in a monolithic application, you have to build the cache yourself and understand the whole mechanism well. You can use Redis (whether it's ElastiCache Redis or Valkey on AWS). The cache isn't free, but the cost isn't huge either.
Our current ElastiCache Setup:
- Multiple clusters (cache.t4g.micro, primary + replica = 2 nodes/cluster)
- Engine Redis OSS 7.x (reserved, 1-year)
- Current cost: $7.34/day
Which was about 220$ USD monthly for Elasticache clusters.
New pricing
Today a pricing change came out that changes everything. There are no more tiers for authorization requests, which means we have a flat rate of $5 per million requests (down from $150). That's a 97% price drop!
For our case with 70 million authorization requests, the calculation now looks like:
70 million requests: 70,000,000 × $0.000005 = $350 monthly → $4,200 yearly (compared to $99,000 in the old pricing).
Keep in mind that batch authorization request costs remain unchanged!
Will You Still Cache?
I'm getting lots of questions about whether I plan to get rid of the cache with such a dramatic price change.
"AVP is so cheap now, why bother with cache anymore?"
"Let's simplify and just use direct API calls"
The short answer is no.
This only applies to my specific use case - in other cases, the outcome might be totally different. Here's why we're keeping our cache:
First, we built the cache mechanism ourselves (for those who don't use API Gateway's built-in mechanism). It's already implemented, works well, and handles a huge number of requests. This means both a smaller AVP bill every month AND better performance because we get data faster from cache than by sending requests to AWS APIs. (We use 10-minute TTL and spent quite a lot of time developing it.)
Second, our cache hit ratio is insanely high (98%). This means without cache, we'd go from 1.4 million API calls to 70 million API calls. That's not just "a few more API calls" - it's 50x more calls. Even at the new cheap rate, 50x more of anything adds up fast.
Third, there are quota and performance considerations. Loading from cache is faster than direct API calls.
However, if we wanted to reduce cache costs, we could look at ElastiCache with Valkey (based on pricing, it would reduce costs by 20% just by changing the engine).
We could go even further and consider Serverless Valkey (my calculations showed about 80% cheaper per cluster per month).
Certainly, if we were starting from scratch today (in our use case), we would not be building a cache with the new pricing structure. We were one of the early adopters of AVP.
My opinion
- I think this is a great and needed change that will definitely boost AVP adoption among customers
- It solves one of AVP's major problems, but we still have others (developer experience, lack of aliasing, versioning, cross-region replication, and several others)
- I'm very optimistic that the AVP team is working hard on new features and improvements, so I can't wait for more news!
Go build now!
Top comments (0)