Optimization Policies
Tune how CostLens detects waste and decide what happens to each finding — per part of your estate, with safe defaults and guardrails. Set thresholds, choose an action (recommend, queue for approval, or auto-fix), scope to specific resources, and let multiple policies coexist with clear precedence.
CostLens ships sensible waste-detection defaults out of the box. Optimization Policies are the layer on top that let you tune those defaults and decide what happens to each finding — for your whole organisation, a specific cloud account, a group of accounts, or a branch of your cloud hierarchy.
A good way to think about it: "For dev/test, be aggressive and clean things up automatically overnight. For production, only recommend, and never touch anything tagged keep." A policy is how you express exactly that.
Where to find it
Open Auto-Fix in the sidebar and choose the Configure tab. Viewing is open to everyone; creating and editing policies requires an Admin or FinOps role. See Policy Lifecycle for how policies handle future findings over time.
Safe by default
With no policies, every check runs on CostLens's built-in safe defaults — exactly the behaviour you have today. A policy only ever changes the settings you explicitly configure.
Core concepts
A policy is made of a few simple building blocks.
Waste types (capabilities)
Rather than tuning dozens of individual checks, CostLens groups them into waste types — for example Idle compute, Unattached storage, or Orphaned snapshots. Tune one knob and it applies across AWS, Azure and GCP automatically.
| Waste type | What it covers |
|---|---|
| Idle compute | VMs / Kubernetes node pools running at very low CPU |
| Rightsize compute | Used but consistently under-utilised compute |
| Idle database | Managed databases with sustained low CPU |
| Unattached storage | Disks / volumes not attached to anything |
| Orphaned snapshots | Snapshots whose source disk was deleted |
| Stopped instances | Instances stopped long enough to be waste |
| Unused public IPs | Public / elastic IPs not associated with anything |
| Idle load balancers | Load balancers with no backends or traffic |
| Idle gateways | Idle NAT gateways / VPC endpoints |
Action tiers
For each waste type you choose a single action — how far CostLens should go:
| Action | What happens |
|---|---|
| Off | Suppress the finding entirely — it isn't even surfaced for this scope |
| Recommend | Surface a recommendation (the safe default) |
| Approval | Automatically create a fix, but hold it for an admin to approve |
| Auto-fix | Apply the fix automatically — only for reversible checks, within guardrails |
Irreversible actions can never auto-apply
Actions that delete or release a resource (deleting a disk or snapshot, releasing an IP, terminating an instance) can never be set to Auto-fix, no matter how you configure a policy. The strongest setting they will accept is Approval. This is enforced by CostLens, not left to configuration.
Thresholds
Most waste types have thresholds — the detection numbers, such as the idle-CPU ceiling or the observation window. You can tighten or loosen them, and every value is clamped to a safe range so a policy can't set something nonsensical.
Thresholds resolve account-wide — CostLens analyses each account once, so a policy can't set a different threshold for individual resources. You can, however, scope the action, severity and guardrails to specific resources (see Scope to resources).
Scope
Every policy is bound to one scope, from broadest to most specific:
- Organisation — applies to every account
- Cloud hierarchy node — an AWS Organisation OU, Azure management group, or GCP folder (deeper = more specific)
- Account group — a label you've defined, such as Production
- Account — a single connected account
Guardrails
Guardrails bound what auto-fix is allowed to touch:
| Guardrail | Purpose |
|---|---|
| Max $/fix | A fix above this dollar amount is queued for approval instead of auto-applied |
| Max fixes/day | A daily cap on how many auto-fixes can run |
| Maintenance window | Only auto-fix inside a chosen time window (UTC) |
| Exclude tags / resource IDs | Resources you list are never surfaced or fixed |
| Protect production | Production resources are never auto-fixed (still recommended) |
| Dependency check | Skip auto-fix if the resource still has live dependents |
| Force severity | Pin a finding's severity rather than deriving it from savings |
Creating a policy
Click Create policy. Everything is captured in one step:
- Name and description — e.g. "Dev/Test aggressive cleanup".
- Scope — organisation, account, account group, or cloud-hierarchy node.
- Priority — a tie-breaker when two policies apply at the same scope (higher wins).
- Detection rules — for each waste type, pick an action and, if you like, expand Thresholds to tune the numbers.
Anything you leave on Recommend at default thresholds keeps CostLens's built-in behaviour and stores no rule — so your policy stays focused on only what you actually changed. When you save, CostLens creates the policy and applies the rules you configured, then opens it for any further tuning.
Start from a template
Not sure where to begin? Use a Default policy (below) to pre-fill sensible rules, then adjust.
Default policies
CostLens provides vetted starting profiles so you don't have to tune every knob from a blank grid. Each one expands (What it sets) to show its exact rules before you commit.
| Template | Posture |
|---|---|
| Conservative | Recommend-only with wide margins — flags only clearly-idle resources. No auto-fix. |
| Balanced | The CostLens defaults at standard thresholds. A safe everyday baseline. |
| Aggressive | Tighter thresholds and auto-fix queued for approval on reversible compute checks. |
| Dev / Test | Aggressive idle detection for non-prod, auto-fixing idle compute inside a nightly window. |
Create from template makes a new organisation-wide policy pre-filled with those rules. Inside an existing policy, Start from a template applies the rules onto it. Either way the result is fully editable — a template is a starting point, not a permanent link.
Scope to resources
Inside a policy's rule editor, each waste type has an optional Scope to resources section. Use it to apply that rule only to resources matching a cloud, environment, region, or tags — for example, auto-fix idle compute only where environment=dev.
Auto-detected from your accounts
The Cloud, Environment, Region and Tag fields suggest real values discovered from your connected accounts' resources, so you can pick from what you actually run instead of guessing. Use the Add detected tag picker to drop a real key=value straight into the filter. You can still type a value freely.
Leave these blank to apply the rule everywhere. When set, the scope affects the action, severity and guardrails for matching resources — detection thresholds still resolve account-wide.
Auto-detected values come from CostLens's resource inventory, which populates after an account's first sync. A brand-new account may show plain text fields until its resources have been scanned.
Managing policies
The Optimization Policies page lists every policy with its scope, number of customised rules, priority, status and last-modified date.
| Action | How |
|---|---|
| Edit rules | Click a policy row to open its editor |
| Enable / disable | Toggle the status chip — a disabled policy contributes nothing, without being deleted |
| Edit details | Change name, description or priority (scope is fixed after creation) |
| Clone | Duplicate a policy and its rules; the copy starts disabled so it can't change anything until you review it |
| Export / Import | Download a policy (or all of them) as JSON, and re-create from that file — handy for sharing or moving between organisations |
| Delete | Remove a policy and its rules |
How overlapping policies combine (precedence)
Multiple policies can apply to the same account at once. CostLens merges them per-setting — it never just picks one and ignores the rest. The resolution order is:
- Scope specificity — organisation → cloud hierarchy → account group → account
- Priority — higher wins among policies at the same specificity
- Recency — the most recently updated policy wins the final tie
The most specific policy wins each individual setting it defines, and inherits everything it doesn't specify from broader policies.
Example: an organisation-wide policy sets Idle compute → Recommend. A Production account-group policy sets only guardrails. Production accounts get Recommend (from the org policy) and the group's guardrails — merged, not replaced.
See the order
On the policies list, click Show precedence to see your enabled policies in resolution order, with the one that wins ties highlighted.
Preview the impact
At the top of the page, the Policy impact tiles are a live simulation of how your saved policies re-classify the recommendations you have open right now — no cloud calls, just your findings re-scored:
- Recommend — surfaced as normal
- Suppressed (off) — hidden by an Off rule, with the monthly savings you're choosing not to see
- Queued for approval — auto-fix rules awaiting sign-off
- Auto-fix — will be applied automatically
- Open recs — total findings in scope
A large Suppressed figure with significant hidden savings usually means an Off rule is broader than you intended — open the policy and check its scope.
Version history & rollback
Every rule change, template apply, clone, import and rollback is snapshotted under Version history inside a policy, with who made the change and when. You can roll back to any earlier version to restore that policy's rules exactly. A rollback is non-destructive — it's saved as a new version on top, so nothing is lost and you can always move forward again.
Who can do what
| Role | Access |
|---|---|
| Admin | Full — create, edit, clone, import, delete, enable/disable |
| FinOps | Full — same as Admin for policies (a cost-governance role) |
| Operator / Viewer | Read-only — can view policies and precedence, but not change them |
Related
See also Auto-Fix, How CostLens Detects Waste, and Recommendations.