The FinOps Treadmill
Here's the pattern that plays out in most engineering organizations:
Month 1: Cloud bill comes in 30% over forecast. Finance escalates. Engineering runs a cleanup sprint — rightsize overprovisioned instances, delete orphaned snapshots, enable storage lifecycle policies, purchase some Reserved Instances. Bill drops 25%.
Month 2: Bill is flat. Team feels good.
Month 3–4: New services deployed. Autoscaling groups don't have rightsizing policies. Engineers provision for peak, not average. Unused dev environments accumulate. Bill starts climbing again.
Month 6: Repeat from Month 1.
SquareOps called this the "FinOps treadmill" in their 2026 AWS cost optimization guide — a cycle of reactive cleanup, temporary improvement, and inevitable drift. The underlying problem: each optimization was a human action in response to a past event, not a system maintaining a desired state.
The FinOps Foundation's maturity model maps the journey to three phases: Inform (visibility — you can see what you're spending), Optimize (action — you're acting on spending inefficiencies), and Operate (continuous — optimization is embedded in how you work). Most teams have nailed Inform. Many have manual Optimize processes. Almost none have reached Operate at scale — and Operate is where the real leverage lives.
What "Autonomous" Actually Means
"Autonomous FinOps" is an overloaded term. Let's be precise with a spectrum:
Level 0 — Reactive alerts: You set budget thresholds. When spend exceeds them, you get an email. You decide what to do. AWS Budgets, GCP Budget Alerts, Azure Cost Alerts all operate here.
Level 1 — Recommendations: The platform analyzes your usage and tells you what to change. AWS Compute Optimizer, GCP Recommender, Azure Advisor. Acting on them is still manual.
Level 2 — Automated execution with approval gates: The platform identifies an opportunity and either acts after a configured delay (unless blocked) or queues it for human review. AWS Compute Optimizer automated rightsizing, Cast AI, Harness Cloud Cost Management.
Level 3 — Continuous autonomous optimization with guardrails: The platform continuously monitors, executes within defined policy bounds, and self-corrects when drift occurs — without human involvement in the execution loop. Humans define policy; systems execute. ProsperOps operates here for commitment management.
Level 4 — Agentic optimization: AI agents that can reason about tradeoffs, draft and propose policy changes, and execute complex multi-step optimization sequences. Microsoft Ignite 2025 announced this direction; production maturity is 2026.
Most organizations need a clear-eyed view of which level they're at and which level their tooling supports. Claiming "autonomous FinOps" when you're at Level 1 is marketing; building Level 3 without proper guardrails is dangerous.
The Cloud Provider Native Toolkit (And Its Limits)
AWS
AWS Compute Optimizer: Automated recommendations for EC2, ECS containers, Lambda, EBS volumes, and Auto Scaling groups. As of re:Invent 2025, includes Unused NAT Gateway recommendations and experimental automated rightsizing for certain instance types. Still primarily Level 1.
AWS Cost Efficiency Score (re:Invent 2025): A new composite metric combining commitments, rightsizing, idle resources, and migration opportunities. Useful for tracking drift; doesn't execute anything autonomously.
AWS Cost Anomaly Detection: ML-powered alerts for unexpected cost spikes. Level 0, but smarter — context-aware anomaly detection vs simple threshold alerts.
GCP
GCP VM Rightsizing Recommender: One of the most mature in the market — uses 8 days of CPU/memory metrics to generate rightsizing recommendations with confidence scores. Level 1.
GCP Autopilot (GKE): Handles node rightsizing for Kubernetes workloads automatically. This is Level 2+ for containerized workloads — one of the few cases where a major cloud provider has built autonomous rightsizing into the core product.
Azure
Azure Advisor: Recommendations across compute, storage, security, and reliability. Level 1.
The Native Toolkit Gap
The cloud providers are excellent at Inform (Level 0) and increasingly good at Optimize recommendations (Level 1). But there's a systematic gap at Level 2+: they generate recommendations, they don't autonomously execute them. This gap is where third-party autonomous FinOps platforms live.
Building Autonomous FinOps: The Guardrail Architecture
Autonomous execution without guardrails is just uncontrolled automation. Before enabling any system to take action on cloud infrastructure without human approval, you need a guardrail framework.
1. Change Budget
Define a maximum change rate per time window: "The system may not modify more than 20 instances per day" or "The system may not change total committed spend by more than $5,000/week without approval." This prevents a misconfiguration from cascading into large-scale infrastructure changes.
2. Scope Limits
Define exactly which resources are in-scope for autonomous action:
- Which AWS accounts / GCP projects / Azure subscriptions
- Which environments (prod vs non-prod; most teams start with non-prod only)
- Which resource types (EC2 rightsizing may be in-scope; database instance resizing may not)
- Which tags indicate opt-out (e.g.,
finops-autonomous: false)
Scope limits should be defined in code (policy-as-code), not configuration files — so they're version-controlled and reviewable.
3. Approval Gates
Not all actions require the same approval tier. A tiered model:
| Action type | Risk | Approval |
|---|---|---|
| Tag orphaned resource | Very low | Autonomous |
| Resize non-prod EC2 instance | Low | Autonomous (with notification) |
| Delete idle dev database | Medium | Async approval (24hr window) |
| Resize prod EC2 instance | Medium-high | Synchronous approval required |
| Purchase Reserved Instances | High | Synchronous approval + finance review |
| Delete production storage | Critical | Never autonomous |
The approval gate mechanism: for async approvals, the system sends a notification (Slack, email, ticketing system) with a specific action description, justification, estimated savings, and a "block this action" link. If no block signal is received within the window, the action executes.
4. Rollback Triggers
Autonomous actions should have automated rollback conditions. After any infrastructure change, monitor for:
- Error rate increase >X% within Y minutes
- Latency P95 increase >Z ms within Y minutes
- CPU/memory utilization spike indicating undersizing
If rollback conditions are met, automatically revert the change and page the on-call engineer.
5. Audit Trail
Every autonomous action must generate a structured log entry:
- Timestamp
- Resource ID and type
- Action taken
- Reasoning (what recommendation/signal triggered this)
- Before/after state
- Estimated cost impact
- Execution outcome
This log is your compliance artifact, your debugging surface when something breaks, and your evidence that autonomous optimization is actually working.
Drift Detection: The Missing Link
Most FinOps tooling optimizes for the current state. Fewer tools track drift — the delta between the last-optimized state and the current state.
Drift happens because:
- New resources are provisioned outside IaC (manual console deployments)
- Auto-scaling events create new resources that inherit default sizes, not optimized sizes
- Software updates change resource consumption profiles, making old rightsizing obsolete
- Engineers override optimized configurations for "temporary" reasons that become permanent
A drift detection system needs:
- A snapshot of optimized state per resource (stored after each optimization action)
- Continuous comparison of current state vs optimized state
- Alerts when drift exceeds a threshold
- Automatic re-evaluation when significant drift is detected
GCP Recommender's confidence scores and AWS Compute Optimizer's recommendation history provide partial drift signals, but neither explicitly tracks drift from a previously-optimized state. This is typically a custom implementation layer.
The Current Autonomous Platform Landscape
ProsperOps: Autonomous management of AWS and GCP commitment purchasing (Savings Plans, Reserved Instances, Committed Use Discounts). The platform watches your compute usage continuously and purchases/modifies/exchanges commitments within a policy you define. Level 3 autonomy for the commitment layer — one of the most mature implementations available.
Cast AI: Focuses on Kubernetes cost optimization with autonomous rightsizing and spot instance management. Particularly strong for EKS, GKE, and AKS workloads. Level 2–3 for container infrastructure.
Harness Cloud Cost Management: Broader cost intelligence platform with some autonomous optimization capabilities. Strong on visibility and recommendation quality; autonomous execution features are more approval-gate-centric than fully autonomous.
Spot by NetApp: Autonomous spot instance management and Kubernetes optimization. Strong for workloads that can tolerate spot interruptions; the automation layer handles spot selection, fallback to on-demand, and cluster optimization continuously.
Microsoft Azure's direction (Ignite 2025): Agentic AI for FinOps across the full Inform/Optimize/Operate lifecycle — migration agents, deployment optimization agents, and cost optimization agents. Still early; production maturity is 2026.
The Practical Roadmap to Operate-Phase FinOps
Getting from where most teams are (manual Optimize) to Operate-phase autonomous FinOps is a 6–12 month platform engineering investment.
Phase 1 (Month 0–2): Visibility foundation
- Implement tagging policy and enforcement (without accurate tags, you can't scope autonomous actions safely)
- Set up billing export to analytics (BigQuery, S3 + Athena) for custom analysis
- Baseline current utilization metrics across all resource types
- Identify top 3 optimization opportunities by spend impact
Phase 2 (Month 2–4): Automation infrastructure
- Build your guardrail framework (change budget, scope limits, approval gates, audit log)
- Implement drift detection for your highest-spend resource types
- Enable cloud provider native recommendations and build a pipeline that ingests recommendations into your ticketing system automatically
Phase 3 (Month 4–6): First autonomous actions (non-prod)
- Enable autonomous rightsizing for non-prod environments within your guardrail framework
- Automate orphaned resource cleanup (unattached EBS volumes, unused IPs, idle load balancers)
- Measure: track actions taken, savings realized, rollbacks triggered, false-positive rate
Phase 4 (Month 6–9): Expand to prod with approval gates
- Extend autonomous actions to prod with appropriate approval tiers
- Evaluate third-party platforms for commitment management (ProsperOps, Cast AI)
- Build executive-facing dashboard with Cost Efficiency Score equivalent for continuous tracking
Phase 5 (Month 9–12): Agentic layer
- Evaluate emerging agentic FinOps capabilities (Microsoft's 2026 roadmap, Harness, etc.)
- Define policy change proposals: should the system be able to propose policy updates when it detects consistent approval patterns?
- Formalize the human/system decision boundary for your organization
The Real Test of Autonomous FinOps
The test isn't "does it save money when you set it up?" It's "does it keep saving money 6 months after you stopped paying attention to it?" That's what Operate-phase maturity means.
Every autonomous system drifts toward the edge cases its designers didn't anticipate. A well-designed autonomous FinOps system handles that through continuous monitoring, rollback triggers, and escalation paths — not by requiring constant human supervision.
Build the guardrails first. The autonomy is only as valuable as the policy it operates within.