Policies
The guardrail engine — required tags, blocked resource types, cost and risk thresholds, and budget limits, enforced as advisory findings or hard blocks.
At a glance
| Route | /policies |
| Group | Govern |
| Page permission | policies |
What it is
The guardrail engine. Policies define what the estate is permitted to do — required tags, blocked resource types, cost and risk thresholds, budget limits — and are enforced either as advisory findings or as hard blocks.
This module also hosts the normalization rules that standardise cost dimensions across providers.
Who it is for
Platform engineering leads and FinOps practitioners who own cost standards, and compliance teams who need those standards evidenced.
How it works
Policies are evaluated at several points
Test before you activate
A test lab and a simulation endpoint let a policy be validated against real workspace data before activation — which prevents the common failure of switching on a blocking policy that halts every deployment.
Exceptions are governed, not achieved by disabling
An exceptions workflow allows a policy to be waived for a specific case with a recorded reason and requester — so exceptions are governed rather than achieved by turning the policy off.
Features
- Advisory and blocking enforcement modes
- Mandatory tag requirements on infrastructure resources
- Blocked resource types — for example prohibiting GPU instances in staging
- Cost and risk thresholds that flag or block changes above a limit
- Budget guardrails with separate soft and hard thresholds
- Budget recommendations derived from actual spend patterns
- Normalization rules standardising team, environment, feature, and tenant dimensions
- Policy simulation and a test lab for validation before activation
- Cloud enforcement scanning of live state, with a cloud action request path
- Policy posture and assurance views
- Exceptions request and approval workflow
- Evidence collection and export for audit
- Scope options controlling where each policy applies
- "Draft with Apex" — the agent drafts a policy and the standard endpoints create it
How to use it
Begin with normalization rules
Without consistent team and environment dimensions, tag and allocation policies cannot be evaluated meaningfully. This is genuinely the first step, not a preliminary.
Author the first policies in advisory mode only
Regardless of your confidence in them.
Use the test lab and simulation
To see what each policy would flag against real data before activating it.
Review advisory findings for a full cycle
And correct policies that produce false positives. This is the step teams skip and regret.
Promote proven policies to blocking, selectively
Typically starting with tag requirements, which are the least disruptive.
Blocking requires Pro or above.
Configure budget guardrails with soft below hard
So warnings precede blocks rather than arriving together.
Establish the exceptions workflow before blocking goes live
So teams have a governed route around a policy rather than an ungoverned one.
Run cloud enforcement scans periodically
To catch drift in live state, not just at change time.
Why it matters
Dashboards report; policies prevent. The difference in cost terms is substantial, because preventing a costly resource from being created is always cheaper than detecting and removing it after it has been running.
The advisory-to-blocking progression is what makes adoption survivable
An organisation can see what a policy would have done for a month before allowing it to stop anything. That is usually the difference between a governance programme that is adopted and one that is resented.
Connects to
- Enforced in PR Cost Review and during execution in Optimization and Autopilot
- Violations surface in Opportunity Queue
- Evidence supports Compliance
- Budget posture appears in Overview
- Tag policies have a dedicated module in Tag Governance
Govern
The controls — the rules the estate must obey, the gates changes must pass, the attribution that makes cost someone's responsibility, and the evidence trail.
Approvals
The central approval queue for every cost action — with savings, blast radius, rollback plan, and policy reason presented on every request.