Cloud Cost Governance Framework: Policies, Gates, Reviews
Optimization removes waste once. Governance is what stops it from coming back.
A cloud cost governance framework is the cost-management slice of cloud governance: the written policies about what spend is acceptable, the control points where those policies are checked, the people who approve exceptions, and the review cadence that keeps the whole thing current. Azure’s Well-Architected Framework puts the purpose well in its cost principles: proactive governance helps you avoid actions that lead to unnecessary expenditure beyond the budget, and realistic budgets with threshold notifications let you check spending against what was allocated.
General governance mechanics, such as SCPs, Azure Policy effects, and Google Cloud organization policies, are covered in cloud governance. This page is a template for the cost-specific layer.
1. Policies: write them as testable statements
A cost policy should be something a machine or a reviewer can check. Examples:
- Every resource carries
environment,team, andapplicationtags. See tagging best practices. - Non-production compute has an off-hours schedule or a recorded exception.
- Temporary environments carry an expiry date.
- Commitment purchases are made centrally, sized to the baseline that remains after scheduling and rightsizing.
- A change that raises a service’s monthly cost above an agreed threshold needs an owner’s approval.
2. Gates: check at the cheapest point
| Control point | What it catches | Example mechanism |
|---|---|---|
| Code review | Expensive infrastructure before it exists | Plan-time cost checks on Terraform or OpenTofu |
| Provisioning | Missing tags, disallowed types or regions | Provider policy (deny or audit) |
| Runtime | Idle, oversized, or orphaned resources | Recommendations with owners |
| Spend | Overruns and sudden changes | Budgets and anomaly alerts |
| Action | Risky fixes applied without review | Approval gates on destructive changes |
Early gates are cheaper to act on; late gates catch what early ones miss. A framework needs at least one at each end.
3. Accountability: name the approver for each exception
Every policy needs an exception path, or teams will route around it. Write down who can grant an exception, for how long, and where it is recorded. Exceptions without an expiry turn into permanent policy by accident.
4. Review cadence
- Weekly: new anomalies and budget threshold crossings, triaged by owning team.
- Monthly: largest open recommendations by estimated saving; exceptions due to expire; allocation coverage.
- Quarterly: commitment coverage and upcoming expiries; policy changes; budget reset against forecast.
Where ZopNight maps onto the framework
ZopNight provides controls at several of these points:
- Code review: IaC governance evaluates Terraform or OpenTofu plans on pull requests, with priced-plan guardrails such as a maximum monthly cost, a total budget cap, and a maximum cost delta; it emits the decision, your required check enforces it, and it never runs
apply. - Spend: budgets per cloud account, resource, resource group, or AI provider with threshold alerts, plus daily cost anomaly detection with root-cause analysis.
- Action: remediation workflows include an admin approval step for destructive operations, and mutating requests are recorded in the audit log.
See also cloud budget planning and auto-remediation.
Signs the framework is too heavy
If exceptions outnumber compliant resources, if engineers learn to avoid the review that triggers a gate, or if nobody can say who owns a policy, simplify. Remove policies that nobody checks, and keep the ones tied to a measurable outcome.