The AWS Pricing Calculator
An ultra-low-cost product. How to save every penny?
Did you ever ask yourself how the AWS Pricing Calculator works? To be honest, until a few weeks ago, I haven't thought about this either.
What I can say upfront — it's not what you think!
But let's start at the beginning.
What is the AWS Pricing Calculator?
The AWS description is an excellent summary:
AWS Pricing Calculator is a free web-based planning tool that you can use to create estimates for your AWS use cases. You can use it to model your solutions before building them, explore the AWS service price points, and review the calculations behind your estimates. You can use it to help you plan how you spend, find cost-saving opportunities, and make informed decisions when using Amazon Web Services.
AWS Pricing Calculator is useful for those who have never used AWS. It’s also useful for those who want to reorganize or expand their AWS usage. You don’t need experience with the cloud or AWS to use AWS Pricing Calculator.
Only with the last sentence, I slightly disagree. You can use it without experience, but you must understand what you plan or want to estimate. But never mind for now.
How could it work?
The Pricing Calculator is a JavaScript-based application. The typical stack to run these on AWS includes Amazon CloudFront, Amazon S3, Amazon API Gateway, AWS Lambda and some databases like Amazon DynamoDB. At least when you want to do some computing and store (dynamic) data.
Can you imagine somebody building a solution like this with only one POST API call and without a database and AWS Lambda? Initially confused, I quickly understood why they made it like this.
How is it working?
We must dive deeper into the architecture and application to understand this. To keep it simple, we assume that the only service we can calculate is Amazon EC2.
First, we need to know what attributes an EC2 Instance has and how they impact the price. The following graphic shows many of them with a few possible values.
Nearly all of these can be combined, for example, Tenancy->Shared with Pricing Model->On-Demand or Tenancy->Shared with Pricing Model->Reserved, and every combination has its individual price.
This leads us to an incredible number of 172.534 combinations, only for the region eu-central-1.
So, how do you provide access to this complex data without an API?
When we open the EC2 Service via the Configure button in the AWS Pricing Calculator and look into the Network tab of the Chrome Developer Console, we can find some hints hidden behind many disorganised files.
Additionally, we see how long it takes to load and how much data is transferred — over 2.5s, 42 requests and 765kB, which is damn slow and a lot of data for one single new page.
In the header of the files, we can see that they are all delivered via Amazon CloudFront from Amazon S3 without any exceptions. This is one of the critical facts of the solution because the data doesn't change often and is requested by many users worldwide. It should have a high cache-hit rate to reduce costs and increase speed.
We know how the data is delivered, but what do we get?
These are the key files from the response, which contain all the Amazon EC2 Service-related information.
For now, we skip the EBS and data transfer file and look at the "primary-selector-aggregations.json" file. It is the heart of the solution and contains 690 main categories with the attributes described above but no instance-related data.
The on-page selected operating system filters the file, and the result is used to build numerous URLs. These are the "index.json" files from our example call and contain the instance-related data.
After downloading the files, we finally have some instance-related data and prices. The download is done in parallel, so we don't lose too much time. JavaScript now uses this data to show the interface and calculate whatever you select. But keep in mind whenever you change the region or OS, the game starts again!
As we see in the example below, it's detailed but can't be used for further processing (scripts or similar) without cleaning.
You may ask yourself what happens with your calculation, and where is the single POST API call? Stay tuned for further technical insights at the AWS Community Day DACH 2022 and a follow-up blog post.
Why is it working like this?
That's quite easy. It's built for cost-efficiency by making trade-offs in performance and user experience. From this perspective, it's a great design.
How this is achieved can we summarise in four points:
- Every connection is routed over Amazon CloudFront.
- Everything is stored in Amazon S3.
- All computing is offloaded to the users.
- No updates. New files are cheaper.
A sneak preview upfront: I did an example calculation showing a price difference of over 2800% between the actual implementation and the previously described serverless stack.
We can assume that this free service is used frequently, so keeping the costs low is comprehensible.
In my opinion, if there were a good publicly available API, many would utilise this in tools, leading to even higher requests and costs.
Eager to know more?
If you are interested in more details — I will talk about this on 19/10 at the AWS Community Day DACH 2022 in Dresden!
After the event, you will find the slides shared here.
