Tagging Strategy to Make Cost Allocation Defensible
A company with 40 accounts and 12 product teams discovers that 38% of its monthly cloud bill (about $190,000 of $500,000) cannot be attributed to a team. Investigation shows inconsistent tag keys (team, Team, owner-team), resources created by automation that skip tags, and shared services (networking, logging) with no clear owner. Finance wants per-team chargeback next quarter. Engineering wants to avoid a big-bang migration. The cloud governance lead proposes enforcing tags at creation time with a policy that denies untagged resource creation, effective immediately across all accounts.
1. Evaluate the immediate deny-untagged-resources policy. What are the risks, and what sequencing would you recommend instead?
Read the worked answer
An immediate deny policy across 40 accounts is high-risk: automation pipelines that create resources without tags will start failing, and teams will be blocked on work unrelated to the tagging effort. It also does not fix the existing 38% of untagged spend-deny policies only affect new resources.
Recommended sequencing:
- Standardize the schema first: pick canonical keys (e.g.,
team,cost-center,environment) and a controlled vocabulary. Normalize existing tags where possible. - Backfill and remediate: run a tagging report, backfill automation, and tag shared services with an explicit owner (e.g., a platform team cost center).
- Warn before enforce: deploy the policy in audit/warn mode for a defined window (e.g., 30–60 days), measure violations, and fix automation.
- Enforce new resources: switch to deny for new creation only after the warn period shows low violation rates.
- Handle shared costs: allocate networking/logging via a documented split (e.g., proportional to each team's direct spend) rather than leaving them unallocated.
This gets chargeback defensible next quarter without a big-bang outage.
2. Finance asks how to allocate the shared-services spend. Describe a defensible method and the trade-offs.
Read the worked answer
Shared services (networking, logging, security tooling) have no single consuming team, so allocation must be explicit and documented. Options:
- Equal split across the 12 teams: simple and transparent, but ignores that some teams consume far more network/log volume.
- Proportional to direct spend: each team pays shared costs in proportion to its own attributable spend. Easy to compute once direct tagging works, and generally seen as fair, but it can under-charge a team that is heavy on shared services while light on direct spend.
- Usage-based (meters): allocate by measured consumption (bytes logged, egress, requests). Most accurate but requires metering and adds engineering cost.
Recommendation: start with proportional-to-direct-spend because it is computable immediately after tagging is fixed and is easy to explain to Finance. Document the method, publish the formula, and revisit usage-based allocation for the largest shared line items (e.g., egress) once metering exists. The key defensibility requirement is a written, consistently applied formula-not the most precise one.