Tagging — the 20% that drives 80% of cost allocation
Source: Dev.to
Common FinOps Mistake: Over‑engineered Tagging
A Series B SaaS team spent three months designing a 47‑field tag taxonomy (e.g., Environment, Service, Owner, Business unit, Cost center, Data classification, Compliance zone, Criticality, Expiry, PII flag, Migration source, CI pipeline ID).
- They couldn’t enforce it.
- Their Terraform codebase contained ~80 modules, and half the resources were provisioned before the taxonomy existed.
- The rollout plan estimated six months; the team gave up after four.
Meanwhile, their cost‑allocation report still looked like:
Sum by service:
- EC2 = 34%
- RDS = 22%
- Datadog = 18%
- Others = 26%The 47‑field schema added zero business value.
The 80/20 Tagging Approach That Works
Only five tags are needed, enforced via Service Control Policies (SCP), CI gates, and IaC policies:
| Tag | Purpose |
|---|---|
team | Which team owns the resource (e.g., finance + on‑call = one owner) |
service | The product/feature the resource serves |
env | prod / staging / dev |
cost_center | Finance roll‑up identifier |
expiry | Auto‑delete date for non‑prod resources; blank for prod |
# Example IaC policy (pseudo‑code)
required_tags:
- team
- service
- env
- cost_center
- expiry
enforcement: block_if_missing
auto_flag: true- Mandatory: resource creation is blocked if any tag is missing.
- Auto‑flagged if a tag violates policy.
This five‑tag schema covers ≈95 % of the FinOps reporting needs you’ll ever have.
Rule of thumb: Build the additional 42 tags that vendors recommend only when you have a concrete question they answer. Never pre‑emptively create them.
Tag Strategy Maturity Curve
- Start simple – adopt the five‑tag schema above.
- Iterate – add extra tags only when a specific, justified need arises.
- Keep documentation short – if your tagging RFC exceeds three pages, rewrite it. Shorter docs are more shippable.
Tags: AWS FinOps CloudCost DevOps Tagging InfrastructureAsCode IndiaSaaS Engineering Founders