Estimating Your Cloud Costs
Estimating cloud costs isn’t always easy, especially if your goal is to be super exact. The desire to be super precise will probably cause you to spend more time estimating the costs of resources than the resources might cost themselves. Always remember that development time is expensive. Trying to estimate down to the dollar isn’t worth it.
That doesn’t mean we shouldn’t estimate these costs; cloud costs do matter, and recurring monthly charges matter a lot to businesses.
The first reality you need to accept is that costs will affect your system designs. Economic factors must play into your cloud design. What good is it if you have an amazing system design but the business can’t afford it? Usually, we are not deciding between a super expensive build and a cheap build. We are usually looking at a few options that are marginally different.
The first thing I like to think about is the factors that could affect our cost. How the factors affect a project differ, but they are often in these buckets:
- Compute costs
- Storage costs
- Blob
- Database
- Transfer costs
Compute Costs
Compute costs could be VMs, application services, or Azure functions (or AWS Lambdas). They tend to be priced based on hours something is running. Sometimes compute can be priced on a per request basis. If you are using a service priced per request, you will need to estimate how many requests will be run per day. Use that to figure out your monthly costs.
If pricing is based on hours, you also need to factor in how large a VM you need. The best way to figure this out is to start with a “standard” sized VM and see how your workload runs. In general, always choose some sort of PaaS (Platform as a Service) option that will make horizontally scaling your solution easier in the future.
Storage and Blob Costs
Storage costs often don’t matter. Storing a few static files in blob storage doesn’t matter much for most projects. But if you are hosting videos, which are large files, you could rack up quite a bill. If you are hosting thousands (or millions) of files, you might have some storage costs. Unless these get really out of hand, it will probably still be less than compute costs, but not in all cases.
Database
Storage can be a significant expense if you factor in databases to storage. Database costs can become expensive in a hurry. Database costs are almost a combination of storage and compute rolled up into one. With databases, you can also have large compute / query costs or large storage costs for very large databases.
Think about these three key questions when it comes to databases:
- How will the data be queried or updated, and how often?
- How much data is there?
- Do we need to replicate this data for availability?
Transfer Costs
Transfer costs can be tricky to price. If you don’t have a lot of requests, you probably don’t need to worry. If you are hosting videos, you might need to start doing some math.
This leads me to cloud provider calculators. These require that you can set the inputs correctly to get good answers. But instead of doing the math yourselves, these can be useful.
When figuring out costs, also remember you will need multiple environments. You will need a QA environment and a production environment, at a minimum. But you may need a UAT or a Staging environment too.
As some general guidance, you can probably keep costs down for a startup by choosing Azure Functions or AWS Lambda for your backend hosting. These options will provide the dynamic scaling you want while minimizing hosting costs. These options also have great scaling stories for handling load as your business scales.
If you are hosting a very intensive workload from Day 1, you should do some load/performance testing to get an idea of your actual needs. It is hard to predict where the system will be stressed without running some tests. But once you know you can handle the load, you can size your resources appropriately. As you do more of this, you will make better guesses based on less information.
Pricing cloud resources doesn’t have to be scary. Just realize you are creating an estimate. And estimates should always have ranges. When estimating resources, ask yourself, “What if I need to bump things up?” Provide a range that includes at least one bump up if you underestimated the first time.
