Tagging Enforcement and Attribution in a Fast-Growing Cloud Estate

Reject it as drafted. At a 41% gap, a 24-hour delete rule would destroy roughly two in five of everything created, and the failures would not fall where you expect:

• Tag propagation lag. EBS volumes, snapshots and load balancers created by a service role often carry tags seconds or minutes after the parent - a 24-hour window helps, but the nightly 02:00 pull means enforcement is running on stale data.
• Infrastructure-as-code reality. Terraform creates then mutates; a resource can be legitimately untagged mid-apply.
• Blast radius. Deleting a volume behind a running production instance is an outage, not a compliance action.

Propose graduated enforcement instead:

1. Prevent at source. Mandatory tag variables in the Terraform modules, AWS tag policies and SCPs, Azure Policy in deny mode for production scopes. Most untagged resources never exist.
2. Close the measurement gap first. Move ingestion to event-driven (CloudTrail/EventBridge, Azure Resource Graph change feed) so "untagged" means untagged, not "not yet pulled".
3. Quarantine, don't delete. Stop or isolate non-production resources, notify the owner found via the IaC repository, and delete only after a 7–14 day clock with backup evidence.

Enforce hard in production creation, softly in remediation.

Neither belongs in the register at the same granularity as a server.

Ephemeral compute: at 220 per week, roughly 11,400 instances a year, a CI per instance produces a register nobody can use and a discovery job that never catches up. Register the durable constructs - accounts, clusters, node pools, namespaces, landing zones - and treat ephemeral compute as a run-rate with a monthly summarised count and cost. Reconcile by sampling: pick 20 terminated instances a week and confirm each appears in billing data with an owner.

Kubernetes: there are only four node pools carrying the only tags, so tagging at the node is where attribution starts but cannot end. Split in two layers:

• Infrastructure layer: node pools and clusters tagged with CostCenter/Owner/Environment/Application and reconciled to the register as CIs.
• Workload layer: namespace labels mapped to applications, then split node pool cost across namespaces by requested and actual resource consumption, using a cost allocation tool or the cost-and-usage export.

Publish a documented allocation rule so Finance can defend the numbers, and flag genuinely shared costs (ingress, NAT, control plane) as an explicit platform charge rather than letting them fall into Unassigned. The register stores the mapping table; the pods stay out of it.

Work backwards from the number. USD 168,000 of USD 412,000 is 41% unassigned; under 5% means roughly USD 20,600, a reduction of about USD 147,000.

Metrics:

• Outcome: unassigned spend as a percentage of total, published weekly, target trajectory 41% → 25% → 12% → <5%.
• Leading indicator: percentage of newly created resources tagged within 24 hours, measured from the event stream. This predicts next quarter's outcome; the lagging number cannot be managed directly.
• Pareto view: top 20 unassigned resources by cost, refreshed weekly. Effort goes where the money is.

Controls:

1. Fix the showback method before chasing the last percent. Shared platform costs should be allocated by a published rule - proportional to tagged consumption - not left unassigned. Otherwise the metric cannot converge no matter how well engineering behaves.
2. Block production creation without tags; allow a grace period with auto-remediation in non-production.
3. Name an accountable owner per business unit who signs off their allocation monthly. Contested numbers need a person, not a dashboard.
4. Review the top 20 in a 30-minute weekly with engineering present. Attribution problems are usually three or four architectural patterns repeated, not thousands of individual mistakes.

Report the trend, not just the point: a falling unassigned percentage with a rising estate is the evidence that controls are working.