Our AWS tagging policy has been in place for four months. An SCP blocks resource creation unless owner, environment, and cost-centre tags are present, and a Lambda removes or handles untagged resources overnight. Tag coverage is above 95%.
However, when I reviewed the 20 largest billing line items, 11 were attributed to just three CI roles, representing about $14,000 per month. The tags are technically accurate because the pipelines created the resources, but they are not useful for chargeback. The aws:createdBy value produces the same roles, sometimes with a build number appended.
The pipeline knows which repository, commit, team, and person triggered a deployment, but that information is not connected to the resulting resources. These are mostly single-tenant resources with a clear owning team; shared services such as NAT gateways are a separate allocation problem. At the moment, the only fallback is comparing build logs with a spreadsheet. What approaches have worked for assigning these costs to real owners without pretending that a CI role is responsible?
5 Answers
Treat createdBy as provenance, not FinOps ownership. The useful chain is resource → application or repository → owning team → cost centre. A weekly export that joins resource tags with pipeline or deployment records can produce the chargeback report you need, even if the cloud resource itself only carries stable identifiers. Be careful with commit SHAs as tags at scale; they can create a lot of churn and noise without adding much long-term value.
If the resources belong to separate teams, give each team its own CI role or workload account and make that boundary part of the allocation model. An account-level report is often cleaner than trying to identify a human from every resource. For short-lived build environments, use a dedicated account or project with a mandatory TTL and delete them on a schedule; otherwise stale test resources can make the CI category look much larger than it should.
Adding more detail to the create event can help when tags are insufficient. Configure the CI tooling to identify the repository, deployment system, or application in its user agent, then use audit logs to trace resource creation back to the originating pipeline. That gives you an audit trail for older resources and a way to validate the ownership mapping, while stable resource tags handle normal reporting.
Define the allowed ownership values centrally and make the pipeline supply an application or team value rather than simply tagging owner=CI. The tag policy can reject unknown values, while a separate ownership table maps those values to managers and cost centres. Also check whether all of the supposedly CI-owned resources are still needed—unused test environments are often a significant part of the bill. Shared infrastructure should be marked as shared and allocated by a documented usage or traffic rule instead of being assigned to a fake individual owner.
Fix the attribution in the pipeline rather than relying on the principal name. Have the job apply a stable application or team identifier, repository, and perhaps deployment metadata when it creates the resource. Keep a small ownership mapping from application or repository to the accountable team and manager, so finance can resolve CI-created spend to a real owner. I would avoid using a person's name directly in tags.
That was my concern too. A deployment or application ID is probably a better durable key, while the detailed commit information can stay in the build and deployment system.