Summary
Give us 30 minutes. Transform your cloud costs.
We will show you how to identify your savings opportunities and implement a simple FinOps governance model.
How to choose a naming convention that survives until next year?
The temptation when starting out is to want to plan for everything. You open a Google Sheet, list fifteen possible keys, imagine subcategories for every special case—and three weeks later, no one follows the convention because it has become unreadable. A naming convention that is too ambitious is a stillborn naming convention.
In our experience, what works is the opposite: start small and accept that the convention will evolve. Five to seven keys, no more, at the start. This naming convention must remain identical across all cloud environments to ensure consistent cost allocation. Each key must answer a specific business question: who pays, who is responsible, what is it for. If a key doesn’t help answer a question that a CFO or CTO might ask one day, it has no place in the initial convention. It can be added later if the need is confirmed.
A point too often overlooked: case and format matter. Environment, environment, and ENV are not the same key for a cost allocation engine; they create three different lines in your reports, and no one notices until the audit. Decide on a strict naming convention (lowercase, kebab-case, it doesn’t matter which as long as it’s unique) and document it in a place people actually check—not a Confluence wiki buried under forty other pages, but a README in the infrastructure repo, or better yet, a schema enforced directly in the provisioning tool.
And above all: a convention without an owner has no future. Someone must be responsible for evolving it, deciding on disputed cases (“does ‘team’ refer to the product team or the technical team?”), and communicating it to newcomers. Without this role, the convention falls apart after six months, replaced by local variants that each team invents on its own.
Which tags are truly mandatory, and which are just for convenience?
There is a fundamental difference between “what would be nice to know” and “what we can’t allocate a cost without.” The two are often confused, and the result is a list of twenty mandatory tags that no one ever fully applies because filling out twenty fields to deploy an instance isn’t tagging—it’s paperwork.
Our position is clear: three to five mandatory tags, not one more. Below this threshold, you don’t have enough information to allocate costs reliably. Above it, you create friction, and in a cloud environment, friction systematically leads to workarounds—resources deployed without tags “because there wasn’t enough time,” or scripts that bypass the CI to go faster.
Concretely, in most organizations, the mandatory cloud tags are: cost-center or owner (depending on your organization, one of the two, rarely both), environment (prod, staging, dev, with no ambiguity possible), project or application, and if your structure justifies it, team. That’s it. The rest—expiry-date, data-classification, backup-policy—undeniably has value, but these are level-two tags. They enrich a healthy foundation; they don’t replace it.
What we observe with our clients is that the temptation to add tags “because we might need them one day” is almost irresistible for the most rigorous technical teams, precisely because they are capable of implementing them. But technical rigor is not the issue. The question is: will this tag be filled out correctly by the person in a hurry deploying a resource at 6:00 PM on a Friday? If the answer is no, the tag is decorative, and a decorative tag pollutes your reports more than it enriches them.
Policy as code, or how to stop relying on goodwill
We’ve all known the “documentation and goodwill” phase. A Slack message announcing the new tagging convention, a link to the wiki, and the sincere but naive hope that everyone will comply. It works for two weeks. Then a new developer arrives, never reads the wiki (let’s be honest, who really does?), and deploys fifty resources without a single tag.
Goodwill doesn’t scale. Code does.
This is where policy as code comes in—the idea that instead of politely asking people to tag their resources, we technically prevent the creation of a non-compliant resource. Terraform with Sentinel policies or OPA (Open Policy Agent), AWS with Service Control Policies or native Tag Policies via AWS Organizations, Azure with Azure Policy—the tools exist, and they are mature. There is no longer any technical excuse not to use them. These mechanisms allow for the automation of cloud tagging governance and sustainably improve the quality of data used by FinOps tools.
The principle is simple, almost brutal: if a resource does not carry the mandatory tags at the time of its creation, it is not created. Period. No catch-up after the fact, no “just this once” exceptions. Some might find this rigid; we find it healthy. Because the only alternative to upstream control is downstream cleanup, and downstream cleanup is systematically more expensive, in both time and frustration, than the initial constraint.
That said—and this is a point we want to emphasize because we see it done poorly too often—the aggressiveness of policy as code must be scaled according to the organization’s maturity. Hard blocking from day one in a team just discovering the concept is the best way to generate general resistance and systematic workarounds (via parallel AWS accounts, for example, which is worse than the initial problem).
We prefer a progressive approach: first, a “warning” mode that notifies without blocking for four to six weeks, giving teams time to adapt and edge cases to surface. Only then, the blocking mode. Rigor without education generates workarounds; education without rigor never changes anything. You need both, in that order.
The controls that make the difference between a tag and wishful thinking
A tag applied at the time of deployment is good news. A tag that remains correct six months later is another story. Cloud resources live, change owners, and change purposes—a test environment becomes, without anyone formally deciding it, a production dependency. And the tag itself doesn’t move on its own.
That’s why policy as code, as solid as it may be, is not enough. You need recurring controls, not just a check at creation. Two levels seem indispensable to us.
The first is an automated and regular compliance check—daily or weekly depending on your resource volume—that scans the entire fleet and identifies everything that has drifted: missing tags, values that don’t match any authorized values (an environment tagged “prod” instead of “production,” for example, the kind of micro-inconsistency that silently breaks your reports), or orphaned resources whose owner left the company eight months ago. AWS Config, Azure Policy Compliance, or third-party FinOps governance tools do this job very well; the key is that the result must be visible, not buried in a PDF report that no one opens. The goal is not only to verify the presence of tags but also their consistency to ensure reliable cloud cost allocation.
The second level, more qualitative, is a periodic review—ideally quarterly—with the teams, not just automated. Because a tag can be technically present and correct on paper while having become false in practice: the project has changed names, the team has been reorganized, or the cost-center no longer exists in the finance system. No automatic scanner detects this kind of semantic drift. Only a conversation reveals it.
We insist on this point because we see many organizations investing heavily in automated control while completely neglecting the human dimension—as if a 98% compliance dashboard guaranteed reliable allocation. It doesn’t. 98% technical compliance can easily hide 30% semantically obsolete tags.
The correction backlog: where to start without spending a quarter on it
And then there is the existing environment. The real subject, the one people avoid because it’s scary: somewhere, you have hundreds or even thousands of untagged or poorly tagged resources accumulated over the years. The temptation when faced with this project is either to ignore it (“we’ll start clean from now on”) or to try to fix everything at once in a dedicated sprint that inevitably drags on for three months and demotivates everyone.
Neither approach works. Ignoring the existing environment means condemning yourself to correctly allocating 20% of your bill while the remaining 80% continues to distort all your calculations. Trying to fix everything at once underestimates the real scope of the project and burns through the teams’ patience in a few weeks.
What works is prioritization by financial impact, not by alphabetical order or seniority. Pull the list of non-compliant resources, sort it by descending monthly cost, and tackle the top 20%. In almost all cases we’ve observed, this 20% represents 70% to 80% of the total unallocated cost—Pareto’s Law applies almost perfectly to cloud infrastructure, because a few massive resources (databases, compute clusters, large storage) always weigh disproportionately more than the long tail of small forgotten instances.
Concretely, this means a dedicated backlog, separate from the product backlog, with a fixed and recurring time budget—two days per sprint, for example, no more, but consistently rather than a one-off heroic effort. Regularity beats intensity on this subject, as on many others in cloud governance. And we set a realistic goal: aim for 90% compliance on high-financial-impact resources in one quarter, not 100% compliance on the entire fleet in one month. The remaining 10%, often legacy resources whose purpose no one really knows anymore, deserve a more radical question than tagging: why do they still exist?
Good to know
A poorly thought-out naming convention, or mandatory tags that are only mandatory on paper, and your entire cost allocation becomes fictional.
At Leonys, we help you build a tagging policy that lasts over time, not just on the paper from the first meeting. Receive our sample naming convention and our list of recommended tags—the starting point many teams wish they had before, rather than after, their first failed audit.
We could stop there, with this list of well-organized best practices. But the real question, the one rarely asked, is: what does it say about your organization that a simple label on a cloud resource is so difficult to enforce?
Cloud tagging is never a technical problem. It is a governance problem, disguised as a technical problem because it is more comfortable to treat it as such.
FAQ
For reliable cloud cost allocation, three to five tags are generally sufficient: the project or application, the environment (production, development, test), and a financial owner (owner or cost center). Depending on the organization, a team tag can also be added.
An effective tagging strategy relies on a simple naming convention, a few mandatory tags, automation via policy as code, and regular checks to maintain data quality over time.
Policy as code involves automatically applying cloud governance rules. A resource that does not comply with mandatory tags can be flagged or blocked upon deployment using tools like Terraform, AWS Tag Policies, or Azure Policy.
Inconsistencies appear when conventions are not maintained over time, when teams use different values, or when resources change owners without tag updates. Automated checks and regular reviews help limit this drift.
The best indicator is the resource compliance rate and, above all, the share of spending that is correctly tagged. A mature organization aims to cover more than 95% of its cloud costs with reliable and consistent tags.
