A cost governance policy is the written rule set that states what teams may use and spend in the cloud without asking: in which regions, with which services and sizes, with which mandatory tags, above which amount only with approval, who buys commitments, who sees cost data and what an exception looks like. It is the source from which guardrails, budgets and reviews are derived. Without it, every platform setting enforces a rule nobody decided on, and every missing setting allows something nobody meant to allow. For the invoice, the policy decides which costs cannot arise at all, which arise only after a signature and which are merely reported.
How it works
The FinOps Foundation covers the subject in the Governance, Policy & Risk capability, part of the Manage the FinOps Practice domain, and distinguishes three forms of implementation: guidelines, guardrails and automation. How the capabilities fit together is covered in the four FinOps domains and their capabilities. A policy only takes effect once each of its areas has a mechanism that enforces it or reports a breach.
Areas and mechanisms
| Area | What the policy states | AWS | Azure | Google Cloud |
|---|---|---|---|---|
| Regions | allowed regions per environment | SCP with a condition on aws:RequestedRegion | built-in policy for allowed locations, deny effect | gcp.resourceLocations constraint, for example with in:eu-locations |
| Services and sizes | allowed services, instance families and SKUs | SCP denying services | built-in policies for allowed resource types and VM SKUs | gcp.restrictServiceUsage; custom constraint on resource.machineType |
| Mandatory tags | keys and values from the tagging policy | tag policies, SCP with aws:RequestTag, Config rule required-tags | Azure Policy with deny, modify or audit | custom constraint on resource.labels |
| Commitments | who may buy | savingsplans:CreateSavingsPlan action for named roles only | Owner or Reservation Purchaser; "Reserved Instances" policy under EA and MCA | compute.commitments.create, part of Compute Admin; spend-based only Billing Account Administrator |
| Cost data | who sees which costs | Billing console only after Activate IAM Access, then IAM actions | Cost Management roles per scope | Cloud Billing roles |
| Exceptions | requester, reason, end date | separate organizational unit with a different SCP | policy exemption with expiresOn | different policy on a folder or project |
Approval thresholds are missing from the table because no mechanism replaces a signature; how they are sized against the budget is covered in guardrails and approval thresholds. How the tag rules are maintained as code is covered in policy as code: enforcing tagging rules, and the roles for cost data in cost data access control: roles by provider.
Preventive, detective, proactive
AWS Control Tower assigns every control one of three behaviours. A preventive control disallows the action and is implemented with service control policies and related organization policies. A detective control reports a breach afterwards and relies on AWS Config rules. A proactive control checks a resource before it is provisioned, through CloudFormation hooks, and therefore only for resources CloudFormation provisions. Azure Policy draws the same line through its effects: deny rejects a request, audit logs it, and a standard evaluation cycle assesses existing resources every 24 hours. Google Cloud offers a dry-run mode for organization policies that logs violations without blocking them.
Preventive rules have two limits. They are not retroactive: Google states that new organization policies are usually not applied retroactively, and the modify effect in Azure Policy does not change existing resources but marks them non-compliant until a remediation task corrects them. Whatever existed before the rule is found only by a detective check. And SCPs do not affect users or roles in the management account of an AWS organization; Control Tower likewise lets administrators there do what controls would otherwise deny, so that the account stays usable. Workloads meant to follow the policy therefore belong in member accounts.
Exceptions and review
A policy without a route for justified deviations gets bypassed. Azure Policy models that route as an exemption: in the Waiver category when non-compliance is accepted for a while, or Mitigated when the policy's intent is met another way, with an optional expiresOn date and free-form metadata such as requester, approver and ticket reference. After the expiry date the exemption stops applying while the object remains as a record, and Microsoft recommends revisiting exemptions regularly. The pattern works for any provider: an exception names the resource, the reason, the owner and an end date, and it lives where the policy lives.
How often the policy itself is reviewed is the organisation's decision. The FinOps Foundation's framework links a regular review cadence with the walk maturity stage and, at run, expects rules that are checked automatically before merge or deployment. Reasons for an unscheduled review come from operations: a new region, a new provider, a substantially changed budget, an exception about to be extended for the third time.
What it means for your cost
Each area of the policy acts on the invoice differently. Regions, services and sizes limit which line items can arise at all. Mandatory tags decide what share of the cost can be assigned to an owner; it is measured as allocation coverage, as tag coverage and untagged cost explains. Access to cost data decides who notices a deviation in the first place.
The rule for buying commitments is the area where a mistake stays on the invoice longest. Google states for both resource-based and spend-based committed use discounts that a purchased commitment cannot be cancelled, and AWS states that a purchase of EC2 Reserved Instances cannot be cancelled once made. The circle of buyers is often wider than assumed: on Azure any Owner or Reservation Purchaser of an eligible subscription may buy reservations, which EA and MCA customers can restrict through the "Reserved Instances" policy; on Google Cloud, the Compute Admin role on a project is enough for resource-based commitments. Which exchange and return routes remain afterwards is covered in exchange, cancellation and expiry of commitments.
Exceptions without an end date become permanent cost. A region opened for one customer stays open long after that customer has left; with an end date, it comes back to the next review, with a name and a reason.
Where it goes wrong
- A policy that lives only in a document. Symptom: the policy forbids a region, yet the billing data shows cost there. Cause: no preventive or detective mechanism was ever set up for that area.
- The management account forgotten. Symptom: resources outside the allowed regions run in the central AWS account of all places. Cause: SCPs only affect member accounts.
- A new rule, the old estate. Symptom: after a region is blocked, cost in that region does not fall. Cause: preventive rules act on new requests; existing resources are found only by a detective check.
- An expired exception. Symptom: a resource suddenly shows as non-compliant again although nothing about it changed. Cause: the Azure exemption reached its expiry date; the object is still there but no longer applies.
- Purchase rights through a project role. Symptom: a commitment appears that nobody approved. Cause: Owners of an Azure subscription or Compute Admins of a Google Cloud project may buy, and the policy never restricted those roles.
- A rigid allow list. Symptom: teams request an exception for every new instance family. Cause: a list of allowed sizes holds only what existed when it was written, and nobody reviews it.
Sources
Read on 2026-10-16. FinOps Foundation Governance, Policy & Risk (CC BY 4.0); AWS control behavior in Control Tower, controls and the management account exception, service control policies, global condition keys, tag policies, Config rule required-tags, identity and access management for Savings Plans, buying EC2 Reserved Instances and managing access to the Billing console; Microsoft Azure Policy overview, modify effect, policy exemption structure, buy an Azure reservation and assign access to Cost Management data; Google Cloud Organization Policy Service, restrict resource locations, restrict service usage, Compute Engine custom constraints, purchase resource-based commitments, spend-based committed use discounts and Cloud Billing access control.