Your untagged spend keeps growing despite a monthly cleanup sweep — why does labelling at creation beat retroactive cleanup?

## Why the remainder is not a backlog you can drain The intuition behind a cleanup sweep is that untagged spend is a queue: resources accumulate without labels, you periodically go and label them, the queue shortens. That model is wrong in three separate ways, and each one is enough on its own. **The charge record is already written.** A usage record is stamped with the labels present at the moment it was metered. When you attach an owner label in a sweep, you have attributed the resource from that moment forward. Every hour it ran before the sweep stays in the unattributed remainder, permanently, in a period that is closed. So even a perfect sweep leaves the historical remainder untouched — you can only ever fix the future, which is precisely what labelling at creation does, only sooner and for everything. **The estate churns.** A sweep sees what exists when it runs. A batch job that ran for nine hours last Tuesday and deleted its resources afterwards was never visible to any sweep, and it still generated charges. A data pipeline that creates and tears down capacity for every run can put a substantial share of spend through resources with a lifetime shorter than the interval between sweeps. This is the part teams consistently underestimate: the untagged share is not dominated by the long-lived machine everyone forgot, it is dominated by everything that came and went. **Cleanup is the harder problem.** At creation, the owner is known — someone is actively asking for the resource, from a pipeline, a request, or a console session. In a sweep, the resource is already anonymous, and identifying its owner means archaeology: who called the management API that created it, what else shares its private address range, which deployment names it. That work is slow, it is guesswork, and it produces labels that are frequently wrong, which is worse than a visible gap because it looks like coverage. ## Preventive against detective, in the right direction | | At creation | Retroactive sweep | |---|---|---| | Control type | Preventive: the resource is not created unlabelled | Detective: it tells you the label is missing, afterwards | | Spend attributed | From the first metered unit | From the sweep onward only | | Covers short-lived resources | Yes | No — they are gone before the sweep | | Owner known | Yes, the requester is present | No, has to be reconstructed | | Effort | One-time, at a single choke point | Recurring, and grows with the estate | The direction matters and it is easy to state backwards: a sweep never prevented anything. It is a measurement of a gap that already cost you money. The mechanism that actually stops unlabelled resources being created is a preventive control set above the account, and that rule itself is a platform-governance subject rather than a cost-reporting one — what belongs here is the consequence: without it, the label is optional, and an optional key is exactly as complete as the busiest team's discipline on its busiest week. ## Why the share grows rather than shrinks The untagged share is the ratio of unattributed spend to total spend, and both sides move: 1. **New resources arrive continuously**, from more teams and more automations over time, while sweep capacity is one team's periodic effort. Arrival rate outruns sweep rate long before the estate feels large. 2. **Each unlabelled resource keeps accruing** until it is found, so the gap is an integral over time, not a count. A resource missed by two sweeps costs twice as much unattributed spend as one missed by one. 3. **The easy cases get labelled first.** What survives several sweeps is the set nobody can identify, which is also the set that grows old and is never turned off. 4. **Convention drift adds to the same bucket.** A key spelled differently, or a value pointing at a dissolved team, produces spend that is technically labelled and practically unattributable. ## Measuring it honestly Track the untagged share **by spend, not by resource count**. Counting resources flatters you: hundreds of tiny labelled objects hide one large unlabelled data store. Report the number as a trend alongside a named owner for the biggest unattributed buckets, and treat a rising trend as the signal that creation-time labelling has a hole — a new automation, a new team, a path into the estate that bypasses whatever normally applies the labels. The realistic target is not zero. There will always be charges with no resource behind them and shared costs no label can carry. The target is that the remainder is small, explained, and not growing — and that is a property you buy at creation time, because it is the only moment when the owner is standing there.