It’s a common refrain in cloud teams:
“Let’s wait until we have clean, complete labels before we start serious cost monitoring.”
On the surface, this sounds responsible, like getting your house in order before analyzing the bills. But in reality, it’s a strategic and financial mistake.
Waiting for perfect labels delays visibility, allows waste to accumulate, and ignores the fact that you can (and should) start cost observability now, even with partial or messy data.
Let’s break down why.
The Myth of “Clean Tagging First, Optimization Later”
Native labels or tags like AWS tags, GCP labels, or Azure resource tags are undeniably valuable. They help allocate costs by team, environment, or project. They’re great for dashboards and chargeback models.
But they were never designed to be the only tool in your cost visibility strategy and waiting for perfect tag coverage introduces five major blind spots:
1. Not All Cloud Services Can Be Tagged
Even the most mature cloud platforms have services and resources that simply don’t support tagging or support it in limited or inconsistent ways.
Examples:
-
Azure: Many resource types don’t support tags at all, or support them but don’t emit them into cost reporting. Examples include internal managed service resources (like NSG security rules, diagnostics settings), networking components, and some third-party services.
Azure tagging support reference -
GCP: While major services like Compute Engine, BigQuery, and Cloud Run support labels, others like Cloud NAT, Pub/Sub subscriptions, and certain networking and IAM-related components don’t.
GCP label support by service
No matter how strict your tagging policy is, some services just won’t be taggable, leaving gaps in your cost view.
2. Shared Infrastructure Can’t Be Solved by Tags Alone
Some infrastructure spans teams and workload like VPCs, shared Kubernetes clusters, monitoring/logging pipelines, or centralized CI/CD systems. Even if tagged, they just tell you “shared,” not how to allocate cost.
These require:
- Custom cost allocation models (e.g., proportionally dividing based on VM hours, network traffic, or usage volume)
- Usage metering per team or namespace
- Policy decisions on fairness
Tags are insufficient here. You’ll need deeper analytics and cost attribution logic.
3. Legacy and Inherited Infrastructure is Often Untaggable
Many organizations inherit cloud environments that predate any structured tagging strategy.
Whether from previous teams, acquisitions, or early-stage experiments, these systems:
- Are often critical (can’t be shut down just to add a tag)
- Use inconsistent or obsolete naming conventions
- May be hard to modify safely
Expecting perfect tag coverage from legacy stacks is unrealistic. You need tools and processes that account for incomplete tagging, not wait until it’s fixed.
4. Tag Enforcement is an Ongoing Investment
Even with a defined tag schema, getting consistent tag adoption is hard. You need:
- Executive sponsorship from engineering leadership
- CI/CD and IaC automation to enforce tagging (e.g. Terraform modules, Azure Policies, GCP Org Policies)
- Tag compliance reporting and alerting
- Team education and cleanup plans
And enforcement is never “done.” People circumvent it. New services are added. Services change their tag behavior. It requires continuous policy execution and cultural alignment, not a one-off initiative.
5. Every Day You Wait = Money Lost
Even without full tag coverage, you can already answer questions like:
- Which services are driving most of my spend?
- Are there idle VMs or underutilized managed services?
- Is spend growing faster than expected in certain regions or SKUs?
- What percentage of my resources are untagged and how does that change month over month?
You don’t need a perfect map to see where the fire is.
Want to know what to do instead read Part 2 (coming Soon)