Open the AWS bill for most small and mid-sized businesses and the largest single line is often the same one: spend nobody can attribute to anything. Compute, storage and data transfer add up to a number, finance asks which team or product it belongs to, and the honest answer is a shrug followed by a few days of detective work in the console.

That shrug has a cause, and it is rarely carelessness. AWS does not know what your resources are for. It knows they exist, what they cost and which account they sit in. Everything else (who owns it, which client it serves, whether it is production or a forgotten experiment) only exists if somebody told AWS, and the mechanism for telling it is tagging.

Why untagged resources make accountability impossible

A tag is a key-value pair attached to a resource, such as Environment = production or Owner = payments-team. On its own it is just metadata. Once activated for billing, it becomes a way to slice cost data by something other than service or account.

Without it, a cost review turns into archaeology. Nobody can say whether that £600 a month of EBS storage belongs to a live system or to a project that finished in March. Nobody wants to delete it, because nobody can prove it is safe. So it stays, and the bill drifts upward. Tagging is not a reporting nicety; it is the precondition for almost every other cost saving, because you cannot right-size, switch off or commit to something you cannot identify.

A starter taxonomy that fits on one page

The most common mistake is designing a 20-tag scheme that nobody follows. Start with a small set that answers the questions finance and engineering actually ask:

Tag keyQuestion it answersExample values
OwnerWho do we ask about this?A team name or shared mailbox, not an individual
EnvironmentIs this safe to switch off?production, staging, development
CostCentreWhich budget does this belong to?A finance code or department
ApplicationWhat business service does it support?client-portal, reporting
Criticality (optional)How careful do we need to be?high, standard, low

Four or five keys is plenty. A few rules keep the scheme usable:

  • Fix the exact spelling. Tag keys and values are case-sensitive, so environment, Environment and Env are three different tags in the cost data. Pick one form and document it.
  • Use controlled values. Free-text values drift into prod, Prod, production and PRODUCTION within weeks.
  • Tag to a team, not a person. People move on; a tag naming someone who left last year is worse than no tag.
  • Make it boring and short. If tagging a resource takes more than a few seconds, it will not happen.

Tags do nothing for billing until you activate them

This catches many teams out. Applying tags to resources is only half the job: to use a tag in cost reporting, it has to be activated as a cost allocation tag in the Billing and Cost Management console. Only then does it appear as a dimension in Cost Explorer, AWS Budgets and the Cost and Usage Report. (Check AWS’s current documentation before publishing for how long activation takes to show up and whether historical spend can be backfilled; both have changed over time and should not be assumed.)

Once active, the payoff is immediate. A Cost Explorer view grouped by Application or CostCentre replaces a spreadsheet exercise with a filter, and a budget can be scoped to a single team’s tagged spend rather than the whole account.

Getting from “we should tag” to actually being tagged

A taxonomy on a wiki page changes nothing. Three mechanisms turn it into practice, in rough order of effort:

  1. Find and fix what exists. Tag Editor and the Resource Groups tooling can list resources missing a tag, so a first clean-up pass is a morning’s work, not a project. Start with the biggest cost lines (usually EC2, RDS and EBS), not every resource.
  2. Tag at creation through infrastructure as code. If your resources are built from Terraform or CloudFormation, set the standard tags once in the template or provider defaults and every new resource inherits them. This is by far the most reliable approach, because it removes the human step entirely.
  3. Enforce it. In a multi-account setup, AWS Organizations tag policies can standardise which keys and values are allowed, and service control policies can block creation of certain resources without required tags. AWS Config also offers managed rules that flag resources missing required tags. (Confirm current behaviour for each: which resource types tag policies and the “required tags” controls actually cover is not universal, and should be verified against AWS documentation at publish time.)

Enforcement sounds heavy, but a lightweight version works for most SMEs: IaC defaults for new resources, plus a monthly report of untagged spend so the gap stays visible.

What tagging will not fix

Be realistic about the limits, or the first report will disappoint:

  • Some costs cannot be tagged. Support plan charges, certain data transfer and some shared services do not carry tags the way an EC2 instance does. Plan for an “untagged and shared” bucket rather than chasing zero.
  • Shared resources need a decision. A database used by three applications can only carry one Application tag. Agree in advance whether you split the cost by a rule, assign it to a shared platform cost centre, or use AWS cost categories to group it.
  • Tags are only as good as their upkeep. A taxonomy nobody reviews decays. A quarterly check of the top untagged line items is usually enough.

Where to start this week

You do not need a programme. Agree four tag keys, activate them as cost allocation tags, fix tagging on your five largest cost lines, and set the standard tags in your infrastructure code so new resources arrive labelled. Then look at the bill again by Application and Environment; the first view usually turns up at least one resource nobody can account for.

That groundwork is the first thing a Yemberzal Cost Optimisation Audit establishes: working out what each cost line actually belongs to, so that savings recommendations are made against owners rather than guesses.