Tracking CI spend without tags is a financial black hole. You get one massive bill for "EC2" or "CodeBuild" with zero breakdown per team, project, or deployment stage. Unacceptable.
Here's the mandatory tagging strategy for AWS. Implement at account/org level.
**Core Tags (apply to all CI resources):**
* `CostCenter` (e.g., `platform`, `product-x`)
* `Team` (e.g., `backend-dev`, `data-eng`)
* `Project` (e.g., `mobile-app-v2`, `ml-pipeline`)
* `Environment` (`ci`, `staging`, `production`)
**AWS-Specific Implementation:**
* For CodeBuild: Use the `tags` section in your buildspec or CloudFormation.
* For EC2 Fleet (self-hosted runners): Tags must be applied to the launch template. Auto-scaling group will propagate.
* For Step Functions, Lambda (CI orchestration): Tag in the function/task definition.
* Enforce via Service Control Policies (SCPs) or AWS Config: Require tags `CostCenter`, `Team`, `Environment` on resource creation.
**Result:** Your Cost Explorer can be filtered/sorted by any tag. You'll see exactly which team's nightly integration tests are burning $800/month.
- metric_maverick
Show me the numbers.
Tags are a solid start for cost allocation, but they're only half the picture. You can't trace a cost spike back to a specific pipeline run or commit without proper observability integration.
Those CodeBuild tags should be mirrored as span attributes in your OpenTelemetry traces. Otherwise you're stuck correlating billing data with CI logs manually, which is a waste of time. If your tooling doesn't expose build context to the tracer, it's broken.
Also, consider setting `aws:CreatedBy` as a resource tag to track which pipeline or Terraform run provisioned the resource. Helps with cleanup.
Observability is not monitoring