Varcio FinOps Copilot

Optimization

The action-first savings pipeline — bundles opportunities into executable work, runs them through guardrails and approvals, and reports realised return on investment.

At a glance

Route/optimization
GroupOperate
Page permissionoverview

What it is

The action-first savings pipeline. Where Opportunity Queue is a triage surface, Optimization is an execution surface: it takes ranked opportunities, bundles them into executable work, runs them through guardrails and approvals, executes them, and reports realised return on investment.

Who it is for

Platform engineers, SREs, and FinOps practitioners who are accountable for actually reducing the bill rather than reporting on it.

How it works

Ranking and bundling

The optimization engine ranks opportunities by a composite of savings, confidence, and effort, and groups related ones into curated savings bundles that can be executed as a unit — a far more efficient pattern than acting on dozens of individual findings.

Execution policy

Each execution is governed by a policy you configure: which risk tiers may run automatically, which require approval, and which are blocked outright. Rollout safety controls stage execution rather than firing everything at once, and execution windows constrain when changes may occur.

Verification

After execution, savings verification compares subsequent actual spend against the prediction and records realised savings separately from identified savings.

CloudWatch-verified savings

The summary reports a CloudWatch-verified savings figure — the share of identified savings backed by measured utilisation evidence rather than heuristics alone.

This distinction matters when you are asked to defend a number.

Features

  • Ranked opportunity pipeline with identified, in-flight, and realised savings tracked as distinct states
  • Curated savings bundles, executable and resumable as a single unit
  • Configurable execution policy with risk tiers — low, high, critical — and per-tier automation decisions
  • Execution guardrails: approval-first mode, auto-run mode, dry run, and blocked states
  • Per-opportunity lifecycle view showing every state transition from detection to verified saving
  • Optimization playbooks — repeatable procedures for common waste classes
  • Automation diagnostics explaining exactly why a given action did or did not run automatically
  • CloudWatch-verified savings KPI separating measured evidence from inference
  • Reset capability to return an opportunity to the queue when circumstances change
  • Filters across cloud, decision state, outcome, and risk tier

How to use it

Open Execution policy first and decide your posture

Approval-first is the correct starting point for every new workspace. Auto-run should only be enabled per risk tier once trust is established.

Confirm your connections carry a verified execution role

Read-only credentials support analysis but cannot execute. The page reports this explicitly rather than failing at run time.

Review the ranked list, filtered to low risk and high confidence

For the first pass. Build a track record on the easy wins.

Open a candidate and read its assumptions and lifecycle

Where measured evidence is attached, check the utilisation series against your expectations.

Run in dry run mode first

This simulates the entire execution without calling the provider. There is no reason to skip it.

Execute

Either individually, or as a curated bundle where several related actions should move together.

Approve anything that lands in the approval queue

In this module, in Approvals, or from Slack or Teams.

Return after a full billing cycle

Read realised savings against identified savings. That delta is the number to report upward.

Consult automation diagnostics for anything that did not execute

And adjust the execution policy or guardrails accordingly.

Why it matters

This is the module that converts a cost tool into a cost outcome.

Identified savings are cheap to produce and every vendor quotes them. Realised, verified savings are what actually appear on an invoice. By carrying execution, safety, approval, and verification in one place, Optimization closes the gap between knowing about waste and having removed it — and produces defensible evidence that the removal worked.

A persistent identified-vs-realised gap is diagnostic

If identified savings keep growing while realised savings do not, you have an execution bottleneck, not a detection problem. Check approval queue depth in Approvals first.

Connects to

On this page