Since that time DevOps and now FinOps teams everywhere pursue this Sisyphean task daily. A task made impossible because it's tightly coupled with the software development lifecycle but disconnected from the business lifecycle. It's this mismatch that has caused a very unnatural dependency and source of friction to emerge between two very different but now joined at the hip worlds: engineering and finance.
Tagging tools, policies, and even new abstractions like AWS's cost categories haven't solved the problem either because they all have their roots in the engineering lifecycle or are unable to move at a pace the business requires.
This makes tags one of the leakiest abstractions in all of the cloud. Tags force business and product teams to get lost in the technical details over what and how to tag or embark on multi-year tagging initiatives that seek to organize a constantly moving target.
Lastly, what about all the things that can't be tagged? Like transactions, DB queries, or the activities of your customers using your systems? Tags at best are meant to add meaning to systems, but break down when trying to assign meaning to actions or points in time.
What Does The Business Want?
The business needs are simple: ensuring the actions of engineering are connected with positive business outcomes. Achieving this, however, is anything but simple.
Go explain your architecture choices or Kubernetes to your finance team and tell me if that gets them off your back about your cloud bill. Understanding how much you spent on EC2 does not solve your problem.
The business needs to organize things by feature, product, or transaction, and then change that structure on a whim. They want to understand what their cost of goods sold (COGS) are and what their costs are per customer. They want to understand R&D spend versus production, they want to know which engineering teams are high performing and which are not. They want to know how to price new features and when to end-of-life underperforming products.
Tagging plays its part in adding meaning to systems, but it isn't flexible or capable enough of keeping up with the speed your business requires.
A few more real-world examples:
What is the combined cost of a set of Kubernetes Labels and AWS tags for a specific feature?
What is my cost per customer and which customers are costing me the most?
How can I segment my costs by region or customer type?
We just acquired a company. How can I merge two completely independent AWS environments?
How can I experiment with different approaches to organizing my assets?
Engineering has organized the infrastructure by team or system, but not by feature or product, how can I maintain two opposing organization structures?
What about costs outside of AWS?
A Better Way To Organize Cloud Spend
The path forward is to use a system that can fly above the noise and not be held back by tagging's limitations – one that takes the best ideas from engineering, like Infrastructure as Code patterns, but is independent from the development process and can move as fast as the business and cloud operations teams require.
CloudZero's Dimensions use a code artifact and domain specific language (DSL) called CostFormation to define how to organize your spend and enable cloud teams everywhere to break the tagging barrier. No matter how well or how little your teams have tagged, CloudZero Dimensions enables you to organize your spend in minutes, not days or years.
For example, let's say I wanted to do something simple, like break regions out into groups according to the two letter code.
To achieve even this simple example, I would need to tag every single resource in my environment with a country code and keep that up to date. With CostFormation, it's easy. I just split out the country code from the region associated with every resource. Notice I built this Dimension without using tags at all?
Now what about something more complex and this time I wanted to include the Name tag in addition to other metadata as sources. Let's say I wanted to map my spend into 3 "Features" — one for research (isolated to one account), and the other for the two features of my product.
In this example, we pull data from existing tags, but notice how messy they are and how we can easily combine multiple values, even pulling in resources from inside Kubernetes and other cloud providers like Snowflake into individual features I can now track from within CloudZero.
CostFormation offers the flexibility to pull together, despite the inconsistencies. The best part?
I didn't have to change a thing in my environment.
The process of organizing my cloud environment can now be totally decoupled from how it's currently tagged and even use data from other sources to avoid tags altogether if I need to.
Get Started Now
Interested in seeing your cloud cost transformed into new Dimensions?
to kick off your free trial of CloudZero. You’ll get months worth of visibility, in a matter of hours, keeping your dev teams focused on what matters.
STAY IN THE LOOP
Join thousands of engineers who already receive the best AWS and cloud cost intelligence content.