Skip to main content
Before we begin implementation, it’s important to understand why we enforce cost and tagging policies using YAML-based policy-as-code instead of relying on spreadsheets or cloud provider dashboards. This section explains the trade-offs and benefits so you can design a governance model that scales with your teams and delivery pipelines.

​
Three common approaches

​
Option 1 — Spreadsheets

  • A person or small team manually tracks owners, cost centers, and expected resource tags in a spreadsheet.
  • Pros: Low friction to start; easy to edit for a very small project.
  • Cons: Becomes stale quickly. Spreadsheets are not synchronized with live infrastructure and offer no enforcement. They are error-prone and difficult to maintain as teams and deployments grow.

​
Option 2 — Cloud provider cost dashboards

  • Cloud consoles and native cost dashboards (AWS Cost Explorer, Azure Cost Management, GCP Billing) provide visibility and reporting.
  • Pros: Great for analysis, reporting, and chargeback after the fact.
  • Cons: Retrospective by nature — they surface problems (tag drift, unexpected spend) after resources are created and billed. They don’t prevent violations, only report them.

​
Option 3 — Policy as Code (YAML-based tagging rules)

  • Tagging and cost rules are encoded as declarative files (YAML) stored in version control.
  • Pros:
    • Rules are reviewed, audited, and evolved like application code.
    • Automation (CI checks, admission controllers, remediation bots) can read and enforce rules at creation time.
    • Prevents non-compliant resources from being provisioned or automatically remediates them.
    • Improves auditability and reduces configuration drift.
  • This is the recommended approach for teams that want enforceable, scalable cost governance.

​
Comparison at a glance

​
How policy-as-code works (high level)

  • Store tagging rules as YAML files in Git. Treat them like any other code: review, test, and release.
  • Integrate rule checks into CI/CD so that pull requests introducing infra or config changes are validated against the rules.
  • Enforce runtime using agents:
    • Admission controllers can block non-compliant Kubernetes resources.
    • Provisioning pipelines can fail PRs or jobs if tags are missing or incorrect.
    • Remediation bots can add missing tags or notify owners automatically.
Example YAML (illustrative) — a simple tagging rule that requires cost-center and owner tags:

​
Key benefits of policy-as-code

  • Enforceable: Prevent violations during provisioning instead of detecting them later.
  • Versionable: Policy changes are tracked in Git, enabling reviews, auditing, and rollbacks.
  • Automated: Integrates with CI/CD, admission controllers, and remediation tools for immediate action.
  • Scalable: Works across namespaces, teams, and multiple pipelines without manual coordination.
For a very small team, a spreadsheet can be a practical short-term starting point. However, once you operate across multiple teams, namespaces, or have frequent deployments, YAML-based policy-as-code becomes the maintainable, scalable choice. Automating enforcement reduces drift and saves time in the long run.

​
Practical next steps

  1. Start by defining a minimal set of required tags (e.g., cost-center, owner, environment) as YAML policies in a repository.
  2. Add CI checks that validate proposed infra/config changes against the policies.
  3. Roll out runtime enforcement (admission controllers or similar agents) gradually — begin with audit mode and move to deny/remediate.
  4. Monitor and iterate: use dashboards for visibility while enforcement prevents future drift.
Next, we’ll move on to implementing YAML-based tagging rules and integrating them into your CI/CD and control plane.

Watch Video