Cloud pricing models made easy
In theory, you need to run your own private cloud to enjoy the ultimate in customizability. In practice, mainstream public clouds are likely to have more than enough customization options to satisfy even the most demanding of customers. There are literally millions of combinations of options and that’s even before you get to the different pricing models including dynamic pricing. Staying on top of all this can be a real nightmare, but it doesn’t have to be.
1. Tagging and SKUs can clear the chaos
While you may have many questions you would like your billing reports to answer, most of them revolve around two key issues.
-
-
- What is the unit cost of X?
- Who should pay for this?
-
The way to figure out the answer to either or both questions is to link back any asset used to a deployment item, which should have an owner. In principle, you could just link each SKU directly to a deployment item, but in practice, most companies are going to want a much greater level of detail. This means that you’re usually aiming to link an SKU with a component of a deployment item. Generally, this will be achieved by tagging.
For the sake of completeness, if you’re working in the multicloud, you’ll want to create a tagging system that works across all providers. This means you will need to standardize your syntax based on what is available at the provider with the most restrictive options.
2. Check SKUs first and instances second (if at all)
The problem with using instance reports to try to work out the costs of a deployment item is that it’s usually much easier to see what was being used than to see why it was being used. As a result, it can be difficult, or even impossible, to be sure that you are linking any instance with the right deployment item.
In many cases, the real value of instance reports is as a “hygiene” check to ensure that instances are being used responsibly. For example, if you see that instances are regularly being spun up late on a Friday and left running until Monday, then you may want to check if this is a legitimate out-of-hours task or if people are just forgetting to shut them down before they leave for the weekend.
3. Reformat billing reports so that they reflect the architecture of your system
Another advantage of working via SKUs rather than instance types is that it should make it possible for you to reformat the billing reports so that they reflect the architecture of your system. This can go a long way to getting financial and management staff on the same page as technical staff.
Just as financial staff do not necessarily understand the details of technology, so technical staff may struggle with billing reports. Presenting the financial costs in a way that clearly links them with the underlying infrastructure can make billing data much more understandable for both sets of staff.
As a bonus, this approach can also make it much easier to see where billing does not tally with your expectations and/or where there is room for economies to be made.
4. Focus on usage first and payment terms second
Cloud costs reflect both the economy of your usage and the economy of your payment terms. If your cloud costs are higher than you’d expect, you usually want to start by checking what you can do at your end and only move on to looking at payment terms once you are confident that you have done everything you can to make your applications work as efficiently as possible.
In this context, remember that a lot of cloud cost optimization ultimately boils down to creating applications that minimize if not eliminate the movement of data, especially between different sectors (whatever name they are given in any specific cloud platform).
There are two reasons for taking this approach. The first is that you might already have the most economical deal. If that’s the case, then you’ll be wasting time and hence wasting money trying to look for a better one since the problem lies with you rather than your cloud platform. Secondly, by making your applications as efficient as they can be, you put yourself in a much better position to work out what the best deal for you actually is.
5. Remember there’s more to the cloud than headline price
Having just explained how to understand cloud pricing models, it’s worth closing with a reminder that price is only one fact to consider in cloud deployments. There are many others, particularly security, reliability, and flexibility.
It’s also worth remembering that cloud pricing models change frequently and that when they do, you need to think carefully about the advantages of updating your usage and/or payment terms to take advantage of them versus the effort required to do so. What this often means in practice is that it makes more sense to fine-tune your usage with an existing provider than to keep switching between providers in search of a better deal.