Start your FinOps journey with Cost Segmentation
Tajana Belina
13 January 2022

The public cloud and shared mobility are service categories that provide an ephemeral ownership of a resource to users, providing them with the convenience of using the resource without an upfront capital investment.
Given the sheer convenience of storing data on the cloud, starting up a virtual computer or using ride hailing services for client visits, it is not surprising that the services in these two categories have seen a huge growth in the B2B context.
As per Gartner research, the public cloud will account for more than 45% of corporate IT spending by 2024. Another Gartner forecast predicts that the public cloud will grow to just below 400 billion USD by 2022. The cloud market has always been growing. Covid 19 and the resultant shift to work from home has accentuated this growth even further.
With an increasing number of use cases being successfully migrated to the cloud, the underlying technologies have proven to be resilient, flexible, and reliable.
The user driven nature of the cloud has enabled engineers, developers, and end users to provision cloud resources almost instantaneously by using API-driven provisioning, Infrastructure as Code (IaC) or with a few clicks by using the console.
On the one hand this trend provides opportunities for flexibility and scalability in terms of computing resources. On the other hand, companies now need an organized and disciplined approach to financial management and governance of cloud expenditure.
This need has resulted in the evolution of FinOps.
FinOps – a brief introduction
FinOps is a continuous journey with a focus on optimising cloud spend. It’s not just about cutting costs as is mistakenly believed. We have heard of the trifecta of cheap, fast, and good. It is often said that a product or service can fulfil any two of these standards; not all three.

FinOps as a practice attempts to get the best of these three otherwise mutually exclusive objectives. It does so by finding the right balance between reliability (the good), performance (the fast) and expense (the cheap).
The following two examples illustrate balancing these three objectives:
- Using magnetic storage devices in place of Solid-State Drives (SSD) when the storage is for backup or archival purposes.
- Using the right storage tier for object storage based on frequency of access and retrieval.
Some of the concrete outcomes of a robust FinOps practice include:
- continuous integration and coordination between Tech, Finance and Business
- right-sizing and downsizing over-provisioned resources
- terminating idle compute resources
- retiring unused software licenses
FinOps – Starting the Journey
FinOps begins with knowing our total cloud expenditure and the allocation of that expenditure over the cost-centres within our organisation.
Let’s refer to these cost-centres as segments. Cost segmentation is “the process of allocation of total cloud expenditure over the segments”. It’s actually synonymous with the term cost-allocation – a standard accounting practice.
An example in point is, cloud expenses incurred on compute resources such as compute instances, database or object storage, allocated to segments such as Production, Human Resources, or Marketing departments, on an actual usage basis.
FinOps – The significance of cost segments
First know thyself
As a first step we need to identify the segments and resources within our organisation. Examples of segments and resources are given below.
POSSIBLE SEGMENTS
Department
Project
Product
Application
Service
Anything else that can be defined as a segment
EXAMPLES OF RESOURCES
Compute instance
Database
Object Storage
Block volume
Load balancers
Backup Snapshots
Segments and resources are elements that collectively represent a taxonomy with interrelationships and a hierarchy. A simplified view is displayed below.

As we will see later in the blog, FinOps is a continuous and cyclical process. We can always make minor tweaks to the segments.
However, successful implementation of FinOps depends a lot on:
- creating a valid schema for identifying segments
- correctly identifying segments
- using a consistent approach
Using Tags to identify segments and label resources
A physical computer in an office usually has a label with the asset code, department, and other relevant information. Similarly, most cloud resources such as compute instances, databases, object storage objects, bloc volumes and snapshots have tags.
What is a Tag exactly?
A tag is a user-definable name-value pair that is used to document a characteristic or attribute of a cloud resource. A resource can have multiple tags for each attribute that we need to identify.
Tags provide the power to obtain information on compute resources at a granular level and have multiple other uses besides facilitating cost segmentation.
In the following table we have listed possible attributes for three cloud resources. Notice that the Department in this case is the segment for the resource.
TAG NAME
Resource ID
Department
Environment
Date Created
Resource ID
Department
Environment
Date Created
Resource ID
Department
Environment
Date Created
TAG VALUE
ocid1.instance.oc1.eu.frankfurt-.antfdslkkljafajs85jklfsdt4
DevOps
Staging
12/04/2020
ocid1.instance.oc1.eufrankfurt-.2bgg3gg3gshn384gh334
I.T. Services
Production
12/04/2020
ocid1.instance.oc1.eu-.kfurt-.1.564tjio5948huvuzg29h483
Department
Human Resources
1/05/2020
Not all resources and services can be tagged
One of the biggest challenges in cost segmentation is that due to their inherent nature, certain resources and services cannot be tagged. As a result, the expense on that resource (or service) cannot be apportioned over segments directly.
Examples of resources that cannot be tagged:
- data transfer costs
- network costs
- database backup snapshots for certain cloud providers
Examples of resources that cannot be tagged:
- support costs charged by cloud vendor
- sign up and fixed fees for various services
The expenses on such services have to be allocated to segments on a pro-rata basis that could be based on internally established and mutually agreed upon parameters.
The Multicloud reality
The fact is that all cloud providers, such as MS-Azure, Oracle, AWS and GCP provide the feature of tagging cloud resources, with possibly minor variations to what resources can and cannot be tagged. The reality however is that most organisations today use multiple cloud providers and multicloud environments are the order of the day.
Each cloud provider an organisation uses would have several accounts and users. This means the taxonomy we discussed earlier is much more complex than we had thought.

What we need is an application:
- through which we can view and manage our multicloud subscriptions, accounts, resources, cost centres, resource groups and assets
- that provides a unified view of all relevant artefacts and provides comprehensive support for implementing the three phases of FinOps
FinOps – taking a deeper look
Let’s take a quick look at these phases before we discuss the application.

Inform Phase
As we have discussed earlier on in the blog, the Inform phase is the first logical step in the FinOps lifecycle. It is a phase of discovery where we ascertain cloud costs, identify cost centres, and allocate the costs to cost centres. This phase gives visibility of costs to our teams and provides them with a clear As-Is picture.
Optimize Phase
During the Optimize Phase, teams act upon the information generated in the Inform Phase. The objective is to optimize operations by setting goals, downsizing and rightsizing configuration of cloud resources in an effort to find a balance between reliability, performance, and expense.
Operate Phase
The Operate Phase is a definition of processes that enable continuous integration between technology, operations, finance, and business with a view of improving and optimising productivity from the cloud.
Once we have carried out cost allocation, the next step is to promote accountability and fiscal responsibility within the cost centres by either showbacks or chargebacks.
Chargeback and Showback explained
A chargeback is quite simply a means of:
- Recovering the costs incurred on cloud computing resources allocated to a cost-centre via a Department, Project, Application etc.
- Recovering costs of services rendered by a service-oriented department e.g., I.T. to other departments e.g., Marketing, Administration etc.
A showback on the other hand is providing internal customers with the information related to the value of cloud computing resources or I.T. services consumed. Costs are allocated to different cost centres or internal customers but there is no recovery.
The practice of using showbacks could be an interim phase before a chargeback system is put into place. Alternatively, chargebacks can be put into practice immediately.

Chargebacks are not only applicable for internal clients, departments, or cost-centres within an organisation. Any organisation that provides I.T. services to other external clients – a Managed Service Provider for example – can make use of FinOps methodologies and obtain granular and accurate information about computing costs incurred by their clients.
One good example is the implementation of CloudVane at Dekod, a ticketing service rendered on a dedicated platform built using Oracle Cloud Infrastructure. This platform is used by a number of Dekod’s clients such as event organisers, football clubs and philharmonic orchestras for ticketing.
Dekod has used CloudVane to implement a system of cost allocation and chargebacks that provides timely and accurate information about the costs the clients incur when using Dekod’s infrastructure. This approach has reduced costs, improved visibility, and increased client satisfaction.
FinOps is all about creating teams that take ownership of the costs allocated to their cost centres. Chargebacks encourage internal customers to fully understand and be accountable for the value of the services they are consuming. The one important consideration is that the cost allocation and chargeback model should map to the needs of the organisation.
Simplifying Cost Centre Management with Organisational Hierarchy
The Organisational Hierarchy feature of CloudVane displays cost centres and cloud resources in that cost-centre in an organisational chart, clearly depicting the hierarchy.
Just click on a cost-centre, drill down and attach or remove a resource and carry out other tasks such as adding or deleting cost centres. With a few clicks, resources that haven’t been attached can be filtered out and associated with a cost centre of your choice.
Working with cost centres and resources becomes easy and intuitive.
CloudVane also provides a unified view of your cloud environment starting with your company and its cloud accounts at the top, drilling down to service categories, cost-centres, and individual resources.

If you are interested in knowing more about CloudVane, its capabilities and features, get in touch with us for a demo today.