Cloud service providers like AWS, Azure, and Google were created to provide compute resources to save enterprises money on their infrastructure. But cloud services pricing is complicated and difficult to understand, which can often drive up bills and prevent the promised cost savings. Here are just five ways that cloud providers obscure pricing on your monthly bill.

Terminology varies

For the purpose of this article, I’ll focus on the three biggest cloud service providers: AWS, Azure, and Google. Between these three cloud providers alone, different terms are used for just about every component of services offered.

For example, when you think of a virtual machine (VM), that’s what AWS calls an “instance,” Azure calls a “virtual machine,” and Google calls a “virtual machine instance.” If you have a scale group of these different machines, or instances, in Amazon and Google they’re called “auto-scaling” groups, whereas in Azure they’re called “scale sets.”

There’s also different terminology for their pricing models. AWS offers on-demand instances, Azure calls it “pay as you go,” and Google has “on-demand” resources that are frequently discounted through “sustained use.” You’ve also got “reserved instances” in AWS, “reserved VM instances” in Azure, and “committed use” in Google. And you have “spot instances” in AWS, which are the same as “low-priority VMs” in Azure, and “preemptible instances” in Google.

It’s hard to see what you’re spending

If you aren’t familiar with AWS, Azure, or Google Cloud’s consoles or dashboards, it can be hard to find what you’re looking for. To find specific features, you really need to dig in, but even just trying to figure out the basics of how much you’re currently spending and predicting how much you will be spending – all can be very hard to understand.

You can go with the option of building your own dashboard by pulling in from their APIs, but that takes a lot of upfront effort, or you can purchase an external tool to manage overall cost and spending.

They change the pricing frequently

Cloud services pricing has changed quite often. So far, they have been trending downward, so things have been getting cheaper over time due to factors like competition and increased utilisation of data centres in their space. However, don’t jump to conclude that price changes will never go up.

Frequent price changes make it hard to map out usage and costs over time. Amazon has already made changes to their price more than 60 times since they’ve been around, making it hard for users to plan a long-term approach. For some of these instances, if you have them deployed for a long time, the prices of instances don’t display in a way that is easy to track. So, you may not even realise that there’s been a price change if you’ve been running the same instances on a consistent basis.

Multitude of variables

Operating systems, compute, network, memory, and disk space are all different factors that go into the pricing and sizing of these instances. Each of these virtual machine instances also have different categories: general purpose, compute optimised, memory optimised, disk optimised and other various types.

Then, within each of these different instance types, there are different families. In AWS, the cheapest and smallest instances are in the “t2” family, in Azure they’re called the “A” family. On top of that, there are different generations within each of those families, so in AWS there’s t2, t3, m2, m3, m4, and within each of those processor families, different sizes (small, medium, large, and extra-large). So, there are lots of different options available – and lots of confusion, too. 

It’s based on what you provision – not what you use

Cloud services pricing can charge on a per-hour, per-minute, or per-second basis. If you’re used to the on-prem model where you just deploy things and leave them running 24/7, then you may not be used to this kind of pricing model. But when you move to the cloud’s on-demand pricing models, everything is based on the amount of time you use it.

When you’re charged per hour, it might seem like 6 cents per hour is not that much. But after running instances for 730 hours in a month, it turns out to be a lot of money. This leads to another sub-point: the bill you get at the end of the month doesn’t typically come until 5 days after the month ends, and it’s not until that point that you get to see what you’ve used.

As you’re using instances (or VMs) during the time you need them, you don’t really think about turning them off or even losing servers. I’ve had customers who have servers in different regions, or on different accounts that don’t get checked regularly, and they didn’t even realise they’ve been running all this time, charging up bill after bill.

What can you do about it?

Ultimately, cloud service offerings are there to help enterprises save money on their infrastructures. And they are great options if – and I emphasise, if – you know how to use them. To optimise your cloud environment and save money on costs, here are a few suggestions:

• Get a single view of your billing. You can write your own scripts (but that’s not the best answer) or use an external tool
• Understand how each of the services you use is billed. Download the bill, look through it, and work with your team to understand how you’re being billed
• Make sure you’re not running anything you shouldn’t be. Shut things down when you don’t need them, like dev and test instance on nights and weekends (my company, ParkMyCloud, focuses on this type of optimisation along with rightsising)
• Review regularly to plan out usage and schedules as much as you can in advance
• Put governance measures in place so that users can only access certain features, regions, and limits within the environment

Cloud services pricing is tricky, complicated, and hard to understand. Don’t let this confusion affect your monthly cloud bill.

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.