Most engineers think cutting the cloud bill means finding cheaper instances: right-size the EC2 fleet, buy a Reserved Instance, kill the dev cluster overnight. That still works, and you should do it. But as of July 2026 it's often polishing the brass while the ship takes on water elsewhere. The fastest-growing line item on most bills is no longer compute, it's AI. In the FinOps Foundation's State of FinOps 2026, 98% of teams now manage AI spend, up from 31% two years ago, and GPU cost overtook general cloud cost as the number-one concern.
So if you want to know how to reduce cloud costs today, FinOps is still the operating model that gets you there, but the target has moved. Give every resource an owner, make spend visible in near real time, then attack idle capacity, over-provisioning, on-demand pricing, and now runaway token bills, in that order.
FinOps isn't a tool you buy. It's a practice that pulls engineering, finance, and product into one loop so cost becomes a first-class metric, not a quarterly surprise. The checklist below is the exact sequence we run on a bloated AWS or GCP account; it usually finds 20–40% of savings in the first two weeks. On one 2026 engagement it took a client's AWS bill from $61,000 to $38,500 a month without shipping a single feature slower.
What is FinOps, exactly?
FinOps (Cloud Financial Operations) is a cultural and operational practice for managing variable cloud spend, where engineering, finance, and business teams share accountability for cost. It combines real-time visibility, resource ownership, and continuous optimization so teams make data-driven trade-offs between speed, cost, and quality.
The FinOps Foundation frames it in three phases that repeat forever: Inform (visibility and allocation), Optimize (rates and usage), and Operate (continuous governance). It's a loop, not a one-time cleanup, because usage and prices both drift. The 2026 wrinkle: scope has exploded. 90% of practitioners now manage SaaS spend and 64% manage software licensing, so the same discipline you apply to EC2 now covers your OpenAI invoice and your Datadog contract.
Why do cloud bills get out of control?
Cloud bills balloon for three predictable reasons: nobody owns the spend, resources outlive their purpose, and teams pay on-demand rates for steady workloads. Self-service provisioning makes it trivial to spin up a db.r6g.4xlarge for a test and forget it. Without tagging and alerts, that cost hides inside a five-figure line item.
The other silent killer is over-provisioning. Engineers size instances for peak-of-peak "just in case," so you pay 24/7 for capacity you touch two hours a day. In 2026 there's a fourth: an A100 or H100 left running after a training job, or a chat feature quietly calling a frontier model for a task a small model could do for a hundredth of the price. FinOps fixes the incentive by making every dollar traceable to a team.
The FinOps checklist: how do you cut the bill?
Cloud cost reduction with FinOps works best as an ordered checklist, cheapest and safest wins first. Each step below is independently measurable, so you always know which change moved the number. Run them roughly in this order.
1. Tag and allocate everything
You can't optimize what you can't attribute. Enforce a tagging policy (team, env, service, cost-center) and block untagged resources in CI. Then turn on Cost Allocation Tags so every dollar maps to an owner.
# Find untagged EC2 instances (the usual budget leak)
aws ec2 describe-instances \
--query "Reservations[].Instances[?!not_null(Tags[?Key=='team'].Value)].InstanceId" \
--output text2. Kill idle and orphaned resources
Idle resources are the fastest, safest cut you'll ever make. Sweep weekly for unattached EBS volumes, idle load balancers, old snapshots, and stopped instances still holding elastic IPs. On one account, deleting orphaned volumes and snapshots saved $4,200 a month.
# Unattached EBS volumes burning money
aws ec2 describe-volumes \
--filters Name=status,Values=available \
--query "Volumes[].[VolumeId,Size]" --output table3. Right-size over-provisioned compute
Right-sizing typically saves 30–50% on compute by itself. Pull 14 days of p95 CPU and memory from CloudWatch and move workloads down a tier. A fleet sitting at 8% average CPU does not need m5.2xlarge nodes.
4. Schedule non-production shutdowns
Dev, staging, and CI environments rarely need to run nights and weekends. Auto-stop them outside business hours and you cut their runtime by roughly 65% (from 168 hours a week to about 50). This one script paid for a recent engagement on its own.
5. Commit to Savings Plans or Reserved Instances
For steady baseline load, an AWS Savings Plan or Committed Use Discount saves real money versus on-demand. As of July 2026, EC2 Instance Savings Plans go up to 72% off and the more flexible Compute Savings Plans up to 66%. Commit only to the floor you're confident about, cover the peak with on-demand or spot, and review coverage monthly.
6. Move interruptible workloads to spot
Spot / preemptible instances run 60–90% cheaper than on-demand. Route stateless, fault-tolerant workloads (batch jobs, CI runners, queue-backed APIs) to spot, and keep databases and single-replica critical services on committed capacity.
7. Govern AI and GPU spend
This step didn't exist two years ago and now dominates. Track token consumption per feature and per API key, not just per account. Route to the smallest model that passes your eval, because most workloads never needed a frontier model; the FinOps Foundation calls model routing the single highest-impact AI optimization. Keep GPU nodes on autoscaling, reserve capacity for steady inference, and report cost per outcome (per query, per resolved ticket) rather than raw token counts.
8. Optimize storage and trim egress
Storage quietly compounds. Move cold data to archive tiers with lifecycle policies, delete incomplete multipart uploads, and drop 90-day log retention to 30 where compliance allows, which often shaves four figures a month. Egress is the bill nobody reads until it spikes: keep chatty services in the same region and AZ, put a CDN in front of static assets, and use VPC endpoints instead of NAT gateways.
9. Set budgets and anomaly alerts
Optimization rots without guardrails. Set per-team budgets and turn on anomaly detection so a runaway training job pages someone the same day, not at month-end. Alert on the rate of change, not just the total.
10. Make cost a weekly ritual (showback)
Attribute spend back to each team (showback) and share a short weekly report. When engineers see their own number, they self-correct. This is the "Operate" phase, and it's what keeps savings from creeping back.
Which FinOps tools should you use in 2026?
One thing changed structurally this year: FOCUS, the open billing schema, reached v1.4 (ratified June 2026) and now normalizes SaaS, PaaS, and token spend into the same columns as raw cloud, so multi-vendor reporting is finally sane. Start with visibility, then layer on optimization.
Tool | Purpose | Cost | Best for |
|---|---|---|---|
AWS Cost Explorer | Native visibility + forecasting | Free | AWS-only accounts |
Cloudability / Apptio | Multi-cloud FinOps platform | Paid | Enterprise showback |
Kubecost / OpenCost | Kubernetes cost allocation | Freemium / OSS | Container spend |
Infracost | Cost estimates in pull requests | Freemium | Shift-left in CI |
AWS Compute Optimizer | Right-sizing recommendations | Free | Instance tuning |
Vantage / Finout | FOCUS-native cost + LLM ingest | Paid | AI and multi-cloud spend |
Practical order: use native tools or OpenCost to see where money goes, add Infracost so cost shows up in code review (shift-left was the top-ranked desired capability in the 2026 survey), and add a paid FOCUS-native platform only once you're on multi-cloud plus AI.
What should you watch out for?
The biggest FinOps mistake is optimizing so aggressively that reliability suffers. Right-size too tight and you'll hit throttling and OOMKills; over-commit a Savings Plan and you're locked into capacity you no longer need. Roll changes out gradually, watch p95/p99 latency and error rates, and keep a Pod Disruption Budget on any spot workload.
Culture is the other failure mode: tools show the number, but only shared ownership keeps it down. For deeper dives, see our guides to Kubernetes cost optimization, what platform engineering is, observability with logs, metrics, and traces, and Terraform vs Pulumi for tagging spend as code. Our DevOps and cloud category links the full cluster.
Frequently Asked Questions
How much can FinOps realistically save on a cloud bill?
In our field experience, a neglected account typically yields 20–40% in the first month from idle cleanup and right-sizing alone, then another 20–30% from commitments and spot over the following quarter. Mature accounts still find 10–15% a year because usage and pricing constantly drift, with AI now the fattest new target.
Is FinOps only for large enterprises?
No. The practice scales down cleanly. A startup spending $5,000 a month can run the same checklist in an afternoon: tag resources, kill idle capacity, schedule non-prod shutdowns, cap which model the app may call, and set a budget alert. You don't need a dedicated team or a paid platform to start.
What's the difference between FinOps and cost cutting?
Cost cutting is a one-time event; FinOps is a continuous operating model. Cost cutting asks "what can we delete this quarter?" FinOps asks "how do we make cost a metric every team owns?" The goal isn't the lowest possible bill, it's the best value per dollar, so sometimes it means spending more to ship faster.
How is FinOps for AI different from regular cloud FinOps?
The mechanics are the same (visibility, then attribution, then optimization) but the units change. Instead of instance-hours you meter tokens and GPU-hours, and providers rarely tag spend for you, so you inject metadata through a proxy or gateway. The highest-leverage move stays routing each request to the cheapest model that still passes your evals.



