What do you see when I tell you to think of a viking?

Probably a very angry man with a big beard, an axe, and a horned helmet. The truth is, however, that their famous headgear is entirely a fabrication. It’s lucky that this myth is so widespread that the truth about it is just as prevalent nowadays to avoid spreading misinformation.

Sadly, cloud cost models aren’t so lucky.

Asking someone “what are the cloud cost models” is a recipe to get a muddled response of conflicting information, when the answer is in fact very simple. That’s why this post will cover:

• Why are cloud cost models so confusing?
• What are the cloud cost models for public providers like AWS?
• A quick and dirty method to model out future cloud costs
• What is a good benchmark for comparing your AWS spend?
• How to create a more predictable cost model for your company

Strap on your helmet and let’s charge in.

Why are cloud cost models so confusing?

First we need to address the elephant in the room - there’s a lot of confusion around the term “cloud cost models”. The main issue here is that many people are assuming that this means the same thing as pricing methods for enterprise hosting companies like Oracle.

It doesn’t, and let’s stick with Oracle as our example to demonstrate why.

With private companies like Oracle, there tends to be a degree of flexibility in their pricing methods. You might be able to negotiate a specific price book or contract (eg, paying a flat price in exchange for being billed usage at a low rate and overages getting billed separately), so there’s very little consistency.

Due to that lack of consistency, there’s theoretically infinite pricing methods for enterprise hosting companies.

However, there are a very limited number of set cloud cost models, as these deal with public providers such as Google GCP, Microsoft Azure, and AWS.

Cloud cost models aren’t a pricing plan agreed to between a hosting provider and each unique client. They’re set models from which you can see how you will be billed for your cloud usage from public providers that will not change the core of what you’re being billed for.

Now that that’s out of the way, let’s get right into the big question. What are the cloud cost models?

What are the cloud cost models for public providers like AWS?

There are four cloud cost models:

• Pay-as-you-go
• Reservation of server types
• Spot (or Preemptible) computing power
• Savings Plan(s)

Pay-as-you-go cloud cost model

A pay-as-you-go model will result in you getting billed for your usage as you use it. Think of it like a mobile phone pay-as-you-go contract - you pay for your exact usage and no more.

This is both a boon and a drawback.

Much like a phone contract, it’s relatively easy to control exactly what you’re spending if you have tight control over your usage. Yet, as we’ve previously explained, it can be a nightmare to try and keep track of your cloud computing costs.

If you don’t have an iron fist clenched around your spending, pay-as-you-go can quickly become inordinately expensive. You’re paying for what you use, so if you add more storage, networking, or generally use more cloud computing power, your costs are going to jump.

This is especially true because the pay-as-you-go model has you paying full price for everything. If you’re low usage, they can be great for avoiding a massive commitment, but otherwise they’re vastly more expensive than your other options.

Reservation cloud cost model

The reservation model is more akin to a standard phone contract. That is, you pay a fixed sum for a set amount of time, and get a specific usage “reservation” as a result. The sum can be paid upfront in whole, partially, or over time, but no matter the payment schedule the client is always contractually required to pay the full amount.

You’ll pay the same amount whether or not you actually use what you’ve requested so make sure that you’re not over-committing before entering into a reservation model. However, you can easily get some heavy discounts compared to a pay-as-you-go model if you can predict what your usage will be and require a more long-term solution or more consistent uptime (eg, a web server).

Spot (Preemptible) cloud cost model

Preemptible models are a little more volatile, and so they’re not suited to anything where you require a set amount of cloud computing power consistently.

These models are based entirely on the available capacity of the cloud provider on instances that may be reserved or scheduled for use by other clients. When the provider has extra virtual machines available for a specific period of time, a spot (or preemptible) instance becomes available for use. Just as quickly the capacity may disappear and the computing power may similarly retreat from your environment.

The inverse is also true though.

If your provider is swamped with requests, your usage will be the first on the chopping block. If they need their capacity back, any workloads you have that are using it will have to be terminated very quickly. As a result, clients must be very thoughtful of which workloads can be run on spot instances, and ensure non-spot instance backstops are always present for mission-critical workloads.

As a reward for the client’s flexibility with uptime, the preemptible model benefits from extremely heavy discounts - up to as much as 80% on AWS.

Savings Plan(s) cloud cost model

The Savings Plans model is specific to AWS, and consists of three models which offer discounts for different commitments. In this way they’re akin to the reservation model, but they’re not interchangeable.

A Savings Plan differs in that you can have multiple of them for different commitments - they’re more flexible than reservation models but tend to offer slightly lower discounts.

The three kinds of Savings Plan are the:

• Compute Savings Plans
• EC2 Instance Savings Plans
• SageMaker Savings Plans

As you might expect, each plan offers different discounts for different commitments. For more information, check out Amazon’s official documentation.

A note on all cloud cost models

A very quick note worth making is that the prices of all cloud cost models are not just applied to the servers you’re using, but also the services you use, data traffic to and from cloud services, and storage amount.

In other words, while the models themselves are very simple, what you’re paying for is just as complicated as the innumerable pricing plans offered by private cloud hosting services. The difference here is that you’re not having to negotiate over the specifics of each aspect.

A quick and dirty method to model out future cloud costs

As you might have gathered from the four cloud cost models, the best route to go down is pretty hazy at the best of times and, in the case of preemptible, can even be considered a downright bet.

Pay-as-you-go is flexible but expensive, while reservation requires you to know how much of each element you’re going to need in advance and comes with steep discounts. Preemptible is a wildcard.

So, to help you choose, and to help you calculate your costs once you commit to a model, let’s go over a quick and easy method for figuring out your future cloud costs.

This isn’t a fool-proof method, and we’d highly recommend checking out this detailed method from Michael Wittig at Cloudonaut if you want to spend a little more time and energy on getting a more accurate result.

First you’ll need to get an accurate estimate of the number of customers you have now, and the number of customers you will have at the end of the period you’re modeling for. Now, there are entire careers built around predicting and influencing customer growth, so we’ll keep things simple.

Start with your current infrastructure and work out how many customers you currently have. That’s the easy part.

Then forecast your customer changes over a period of time (if you don’t have a prediction but have a desired growth rate, use that to predict where you’ll be if you hit your numbers) and work out the difference between that and your current amount. Multiply your traffic and storage values by that difference.

Finally, evaluate the servers and services you have in use to see if they could handle your forecasted customer changes. If they can, then congratulations! You don’t have to worry about changing your cloud hosting plan at all, and can simply compare how much you’re paying at the moment to how much you would be paying on the other cloud cost models.

If your servers and services can’t handle the change in customers, you then need to figure out how much more needs to be added and factor that into your current cloud cost model (and the alternatives for comparison).

And there you have it - a relatively painless way to model your future cloud costs and to compare the viability of the different cloud cost models that you could be using going forwards.

Just remember that pricing isn’t everything when it comes to cloud computing, as consistency and uptime are pivotal factors which only you can really assess as to their importance.

What is a good benchmark for comparing your AWS spend?

You now know how to predict your cloud costs and to make the most of the cloud cost models on offer. So let’s change gear and ask why it’s important to know your AWS (cloud) spend, and how to know what it should be.

In other words, why should you care what your AWS spend is, and what’s a good benchmark to compare it against?

Well, beyond the obvious of knowing how much you’re spending on cloud solutions, your AWS spend is useful because of what it affects. Remember, your cloud computing requirements are more complex than simply hosting a website, so increasing or decreasing your spend will affect many things including your:

• Production environment(s)
• Research and development environments (including Quality Assurance)
• Sales engineering and demo environments
• Customer implementation environments

Each of these elements are vital in and of themselves, but perhaps even more importantly they tie into different benchmarks on your financial statement. In other words, your AWS spend has far-reaching effects on your finances beyond the pure cost of services.

Production environment AWS costs and customer implementation environments make up a core element of your Cost of Goods Sold (COGS), which is one of two central figures (the other being your revenue) for assessing the financial health of your company. For a SaaS company, your target should be to have your COGS never exceed 20% of your revenue in order to maintain a healthy profit margin, and knowing and controlling your AWS costs is a vital part of this.

Sales engineering and demo environments factor into Customer Acquisition Cost (CAC) but you can’t know what is reasonable to spend without talking to your sales team. They need to be aware of the costs of these environments in order to give you a benchmark of how much they’ll need in order to drive your CAC down to a reasonable level.

Finally, research and development environments are essentially a cost center, and your amount of spending will depend on your company’s goals.

If you’re focusing on high growth, high delivery, you’ll probably be prepared to spend a lot to increase what R&D can produce. If you’re more focused on sustainability and profitability, your costs should probably match your production or be less than it.

How to create a more predictable cost model for your company

You’ve learned a lot about cloud cost models over the course of this post, so let’s turn that knowledge into action. Here’s how you can create a more predictable cost model for your company going forwards.

Start by creating a budget and dividing it by financial category.

Next, make sure you’re tracking AWS resources by category. More specifically, you should be using your accounts or cost allocation tags.

Follow up by assigning team responsibilities for costs in each category and staying on budget. That way you can help to ensure that the rest of the company is working with and not against you in trying to keep your AWS costs to a manageable and profitable level.

Remember that if a team doesn’t stay on budget, it’s likely a result of not understanding why the budget was important versus their internal team goals. The people you assign responsibility to (likely team leaders) need to understand and agree with the budget you set out, so you should also take time to understand their team’s side of things and not just take the lower-cost path for nothing but the sake of saving money.

Once your teams are on board, put measures in place to keep everyone aware of what the current costs are in their own category. This will be nigh-on impossible without some kind of tool to help you, but luckily Aimably Pulse fills that gap perfectly by letting your team know what their expected AWS charges are every week on the dot.

To round out, make sure you’re tracking cost increases and that any such rises are escalated beyond the department that’s accountable for them when they’re left unattended. Someone should always be aware of an incoming spike, even if their only response is to clear the expense as a reasonable cost for the new services entailed.

Once again, we here at Aimably have your back here with Aimably Warn. This tool will (surprise surprise) warn a team when their AWS costs rise beyond a certain level, and allow you to send that warning to multiple people to cover the possibility of someone being unavailable.

In other words, it’s the perfect accompaniment to your ideal cloud cost model.

‍