The activation trap: tagging the resource isn't enough
On AWS, a user-defined cost allocation tag has to be separately activated in the Billing and Cost Management console before it appears in Cost Explorer or a Cost and Usage Report. Tagging the resource itself doesn't do it. Activation used to be strictly forward-looking with no way back; AWS now lets an account request a backfill of up to twelve months, but only for the stretch where the resource was already, physically, tagged. A tag activated today still can't retroactively create history for a resource that was untagged last year.
That makes activating every tag key you plan to ever use a same-week task, not a someday task. The cost of waiting isn't a delay; it's a hole in the historical record that a backfill request can't fill unless the tag was already there. Other providers carry their own version of the same trap: Google Cloud's labels have no built-in mechanism for a project's labels to propagate down to the resources inside it, and Azure tags don't inherit from a resource group either, unless you deliberately attach the built-in "Inherit a tag from the resource group" policy. In both cases, a tag scoped one level up does nothing for the resource underneath it until something explicit copies it down.
Coverage → showback → chargeback: what each stage needs
The four bands above aren't arbitrary cutoffs; they map to what a number is safe to do. Below 50, the bill can't support any team-level statement at all. Between 50 and 80, it's solid enough to point a team at its rough number and prioritize from there, but not solid enough to put in front of anyone as final. Between 80 and 95, showback holds up. The number is close enough to trust for visibility and behavior change.
Chargeback needs the top band, and that's not caution for its own sake: any team billed off a number built on a meaningful share of unattributed or misattributed spend has a legitimate argument that the bill is wrong, and a chargeback program that loses that argument once loses the trust it needs to run at all. Reaching for chargeback before the coverage supports it turns a FinOps process into a dispute process.
Showback vs. chargeback, defined →
Enforcement that doesn't slow engineering down
The fix that holds is layered, not a single gate: tag defaults baked into infrastructure-as-code so a resource is born tagged instead of tagged later, a narrow IAM condition that blocks resource creation specifically when a required tag is missing, and a recurring drift sweep against the normalized cost view to catch whatever still slips through both of those.
What deliberately isn't on that list is blocking every deploy on a tag-lint failure. A hard gate on every commit turns tagging into an engineering-velocity argument instead of a FinOps one, and it's the kind of control that gets quietly bypassed the first time it blocks an incident fix. A weekly sweep that flags drift and files a ticket keeps the same discipline without ever being the reason a deploy didn't ship.
Track this as a checklist item →
Where CostMon fits, and where it can't help
CostMon reads whatever tags already exist across every connected provider into the same normalized daily view, so a dollar tagged checkout on AWS and a dollar tagged checkout on an AI provider's workspace land in the same row and can be summed together. Unattributed spend is a first-class number on the dashboard, not buried in an "Other" bucket that hides how large it really is.
CostMon does not create, enforce, or fix a single tag. It reads the provider's billing export exactly as tagged, or not, at the source. The schema, the Terraform defaults, and the IAM condition below are still yours to apply. And for AI API spend specifically, since there's no resource to tag in the first place, CostMon attributes it by connector, workspace, or API key instead: ordinary connector metadata doing the same job a tag would.
See how CostMon normalizes every connector →