Our AWS tag policy has been enforced for four months: resource creation requires owner, environment, and cost-centre tags, while an overnight Lambda removes or handles anything untagged. Tag coverage is above 95%, but the 20 largest cost line items still trace back to just three CI roles, representing about $14,000 per month. The tags are technically accurate because the pipeline created the resources, but they are not useful for chargeback because the actual team or person behind each deployment is missing. The aws:createdBy information produces the same roles, sometimes with a build number. These are mostly single-tenant resources with a clear owner; the missing link is between the pipeline, repository, deployment, and responsible team. Shared infrastructure such as NAT gateways is a separate allocation problem. What is a practical way to connect CI-created resources and their costs to the real owners without relying on manual spreadsheets and git blame?
5 Answers
Treat the CI principal as a creator, not the FinOps owner. Have the pipeline apply stable metadata such as application, repository, owning team, environment, and cost centre at creation time. Keep a small ownership mapping from application or repository to the responsible team, then join that data with billing exports and deployment records. That gives finance a real owner while preserving the useful fact that CI created the resource.
Make the cost-centre tag represent who should pay, rather than which principal made the API call. Each team can use its own CI role, or the pipeline can provide an application or team identifier that is validated against an approved ownership table. Unknown values should fail the deployment so new spending cannot silently end up under a generic CI owner.
Before building a perfect attribution system, check whether the expensive resources are still needed. In one case, much of the apparent CI ownership was abandoned test environments that nobody cleaned up. Add TTLs, scheduled reviews, and an owner notification or deletion workflow so the report drives savings as well as assigning names.
For resources created by short-lived test or build jobs, a separate account with a default cost allocation and an enforced time-to-live can be cleaner than trying to attribute every resource individually. Bill that account to the owning team and automatically delete anything that outlives its expected lifetime. It also exposes abandoned environments, which are often a sizeable part of CI-related spend.
Keep the deployment correlation as a separate data source instead of expecting tags to contain the whole history. Record which pipeline, repository, application, and team created each resource, then periodically join that inventory to the cost and usage report. CloudTrail details such as the user agent can help identify the originating build system, but the durable ownership mapping should come from the pipeline or application catalogue.
I would avoid putting a commit SHA on every resource. At scale it creates a lot of tag and monitoring churn for little reporting value. A stable repository, application, or deployment identifier is usually enough, with the commit retained in build and audit logs.