How to Quickly Estimate your AWS Costs (with FREE spreadsheet template)
In this article, I provide a quick and easy-to-use method to estimate AWS costs for your app. The article comes with a FREE spreadsheet template that will help you make the estimations with minimal effort.
The estimates you can do with the following are very rough estimates, different users will use your app differently, so do note that your actual expenses may vary accordingly.
Estimating the cost of using AWS is important to planning any application, as it helps you estimate how much you would have to charge users at a minimum later on.
The AWS price constants in the spreadsheet are based on one instance of AWS prices, and may vary as AWS changes their prices.
Fixed vs Variable costs
Fixed costs are expenditures that do not increase as the usage of your app increases. Examples of these include rent or purchase of physical storefront, warehouses, etc. Of course, it is important to note that fixed costs may actually scale somewhat with your number of users. For example, a warehouse for $1000/mo may have only enough capacity for an estimated 100,000users, and for another 100,000 users, you will need to purchase an additional warehouse. This could me modelled better as a step function, where from 0–100,000users, your fixed cost for warehousing is $1000, from 100,001–200,000 users, your cost is $2000, and so on.
However, for the purpose of this model using AWS, majority of your expenses will be variable, meaning they scale with the amount of usage. Thus, I leave one entry field for an estimated fixed cost, and the rest will be assumed to be variable costs.
The Spreadsheet
You can copy the cost estimator spreadsheet here.
The goal of the spreadsheet is to estimate AWS costs in a per month basis and scaled by an estimated number of users.
Note that each AWS Pricing Constant has VERY specific units (per million, per GB/mo, etc.). Take note of these units if you wish to modify the spreadsheet to better suit your application.
The example for this spreadsheet is an application to remind users to perform preventive maintenance for their properties / applicances. For example, an air conditioner in their apartment could be cleaned out every 2 months.
You will find that a lot of assumptions are made when making preliminary cost estimations and these should be clearly stated.
Legend
- Yellow Cells: You should change the number based on your own case
- Light-blue Cells: Resulting numbers you should pay attention to
- Grey Cells: Comments (could be removed)
The Transaction Table
This table describes the multiplicity of various user-related transactions.
In the example:
- 1 user is assumed to have 10* properties on average. (e.g. air conditioner, washing machine, dryer, etc.)
- On average, each property is assumed to have 1* appointment for maintenance per month.
- Each appointment would have 5* related notifications (e.g. start, delayed, etc.)
*It is good to slightly over-estimate these numbers
The second row estimates the total number of transactions by multiplying the number above it and to the left (see the equations for clarification)
This shows that on average, each user may receive 50 notifications in a month (this could be optimized later by grouping the notifications).
Note that the transaction table has NO assumption on using AWS yet, and it is solely based on the predicted usage of the application.
The Component Usage Table
This is a table to describe how much a user will use different modules in AWS. Like the transaction table, this varies for every app, and this will be majority of what you have to fill in.
Each row represents a component in AWS, while each column represents a related transaction.
In the column (b) for example, a single user is assumed to use the following components in creating, reading, updating, deleting (CRUD) a single property:
- API Gateway 5 times
- Lambda 5 times
- DynamoDB 10 times
- SES 0 times
In column (e), we have the price constants from the AWS Pricing Constants sheet.
Get Total AWS Component Costs
In column (f), we have the total estimated cost for using each AWS component (API Gateway, Lambda, DynamoDB, SES, etc.). This is acquired by multiplying each column with the estimated number of total transactions in the Transaction Table (see the equation in the sheet).
Get Insights
The pie chart below the Component Usage Table shows that the estimated usage of the AWS Simple Email Service (SES), would take up over 96% of the cost. That’s a large percentage and would thus need consideration on either optimizing the usage of SES, or finding alternatives to integrate into the solution.
Fixed Costs
Some of the fixed costs estimated in the sheet include domain name and hosting.
User-Scaled Estimates
The user-scaled estimates in Section D show a table and graph of how the total costs (fixed + variable) would cost on a monthly basis.
In the example, it is shown that the fixed costs are minimal if it was aimed for the app to achieve over 10,000 users in the long run.
Conclusion
Throughout this article, I have described a method to model user behaviour in an application, and how to create a table to calculate usage of AWS components.
With the tables generated, estimates of component costs and total cost are calculated and actionable insights could be acquired from these calculations.
Let me know in the comments if you’d love for me to create a user-based AWS cost estimator web application using the above concepts :)
