The cloud bill has a line for a virtual machine called test-new2. Another is called SQLserverFINAL. A storage account is named after an employee who left last year. Half the resources have a tag called Owner, some have owner, some have CreatedBy, and most have nothing. Finance wants to know what the marketing website costs. Nobody can say without an afternoon of guesswork.
Inconsistent naming and tagging looks like an untidiness problem. In practice it is the reason many businesses cannot answer basic questions about their cloud estate: what is this, who owns it, what does it support, and can it be switched off?
The problem in plain language
Cloud platforms let anyone with the right permissions create resources in minutes. Each person names them in their own way and adds, or skips, labels called tags. Over time the estate fills with resources whose purpose, environment and owner can only be guessed. Common symptoms include:
- names that do not show the application, environment or region;
- the same tag spelt several ways, so filters and reports miss resources;
- no tag for owner or cost centre on most resources;
- production and test resources indistinguishable at a glance;
- clean-up postponed because nobody is sure what is safe to delete.
What the buyer is actually trying to solve
People search for cloud naming conventions, tagging best practice, how to allocate cloud costs by department, or how to find out what a resource is for. Finance managers ask why the cloud bill cannot be split by business unit. IT managers ask how to tidy up without breaking anything. The underlying need is a standard that makes every resource identifiable and attributable, applied automatically so it does not depend on everyone remembering.
Evidence and system mechanism
Tags are the mechanism for knowing what belongs to what
The AWS whitepaper on best practices for tagging AWS resources explains that as usage grows across many resource types and applications, you need a mechanism to track which resources belong to which application, to support cost monitoring, incident management, patching, backup and access control. It notes that a structured name can only hold a limited amount of information, which is why tags carry the rest. A consistent tagging strategy makes it easier to filter, search, and monitor cost and usage.
Names are hard to fix later
Microsoft's Cloud Adoption Framework guidance on defining a naming convention points out that most Azure resource names cannot be changed after creation, so names should include only information that stays constant, with other details held in tags. It suggests components such as resource type, workload, environment, region and instance number, in a fixed order. Getting the standard in place early matters, because renaming usually means rebuilding.
Tags can be enforced and inherited
Microsoft's tutorial on managing tag governance with Azure Policy shows how to deny the creation of resource groups that lack a cost-centre tag, how resources can inherit tags from their resource group, and how remediation tasks correct existing non-compliant resources, since policies do not automatically fix what is already there. AWS and other platforms offer equivalent controls. The tooling exists to stop the problem growing.
Tags only help billing once they are activated
AWS documentation on activating user-defined cost allocation tags states that tags must be activated before they appear in billing reports, and that it can take up to 24 hours for new tag keys to appear for activation and up to another 24 hours to activate. A business can tag diligently and still see nothing in its cost reports if this step was missed, and inconsistent tag keys multiply the work.
Problem owner and why-now trigger
The IT manager or cloud administrator owns the standard and its enforcement. Application owners and budget holders supply the values that matter, such as owner and cost centre. Budget for the clean-up typically sits with the finance director or chief information officer.
Platform growth is the usual trigger. A handful of resources can be managed by memory; a few hundred across several subscriptions or accounts cannot. Other triggers include a cloud bill increase that finance cannot explain, a request to charge costs back to departments, a security incident where responders cannot tell what a compromised resource supports, and a migration that brings many new resources at once.
Economic consequence
- Unallocated spend. Costs cannot be assigned to products, departments or customers, weakening budget accountability, as described in when cloud spend has no business owner.
- Paying for forgotten resources. Unidentifiable resources keep running because deleting them feels risky.
- Slower incidents. Responders waste time working out what a resource does and whom to call.
- Weaker automation. Scheduled shutdowns, backups and patching that target tags miss resources tagged differently.
- Audit effort. Proving which resources hold personal or financial data takes manual investigation.
Root cause
- No written standard. Or one that exists in a document nobody uses.
- No enforcement. Resources can be created without required tags.
- Too many tags. Ambitious standards with a dozen mandatory tags are ignored.
- Uncontrolled values. Free-text tag values produce many spellings of the same department.
- Legacy estate left untouched. New rules apply only to new resources.
Practical intervention
- Agree a short naming convention. Resource type, workload, environment, region and instance number in a fixed order is a sensible start.
- Choose a small set of required tags. For example owner, cost centre, application, environment and data classification, with exact key spellings.
- Control the values. Publish allowed values for cost centre, environment and classification.
- Enforce at creation. Use platform policies to block or flag resources without required tags, and inherit tags from resource groups or accounts where possible.
- Remediate the existing estate. Report non-compliant resources, assign them to likely owners to confirm, and correct tags in batches. Unclaimed resources go through an agreed review, as covered in infrastructure resources without a clear business owner.
- Activate cost allocation. Turn on the tags in billing tools and build a monthly cost report by cost centre and application.
- Check monthly. Track the share of spend that is correctly tagged and follow up the gaps.
Trade-offs
Strict enforcement can block urgent work. Many businesses start by auditing and alerting, then switch to blocking once the standard is familiar.
An illustrative example
Illustrative: a Stellenbosch software company with about 60 staff had grown to several hundred cloud resources across two subscriptions. Finance could not split costs between its two products. The team agreed five required tags, applied a policy that added cost-centre and environment tags from resource groups, and spent two weeks confirming owners for untagged resources. Several unclaimed test environments were shut down after review, and monthly cost reports by product became possible.
Diagnostic questions
- What share of your cloud spend carries an owner and cost-centre tag?
- Can you tell production from test resources by name alone?
- Is there a written naming and tagging standard, and is it enforced?
- How many spellings of your key tags exist in the estate?
- Are your cost allocation tags activated in billing?
What good looks like
Every resource follows a short, documented naming convention and carries a small set of required tags with controlled values. New resources cannot be created without them. Existing resources are remediated and reviewed monthly. Costs can be reported by application and cost centre, and responders can identify any resource's purpose and owner in seconds. Rising costs then become explainable, a theme covered in cloud costs rising without explanation.
Where Mellorca fits
Mellorca's digital infrastructure work can design a naming and tagging standard, set up policies to enforce it and remediate the existing estate. Through managed digital operations, Mellorca can run the monthly compliance and cost reporting that keeps it in place.
Method note
Platform behaviours are drawn from current AWS and Microsoft documentation and differ between providers. The example is illustrative rather than a client case. The right tag set depends on how the business wants to report and govern its estate; fewer, well-enforced tags usually beat many optional ones.
Sources and further reading
- Best Practices for Tagging AWS Resources - Best Practices for Tagging AWS Resources (last verified 10 October 2026)
- Define your naming convention - Cloud Adoption Framework (last verified 10 October 2026)
- Tutorial: Manage tag governance with Azure Policy - Azure Policy (last verified 10 October 2026)
- Activating user-defined cost allocation tags - AWS Billing (last verified 10 October 2026)
Related Mellorca reading
- Why manual changes keep bypassing your infrastructure-as-code
- Why certificates expire when nobody clearly owns their renewal
- Why infrastructure changes get made without recording the business impact