Finitizer and native cloud tools

Finitizer is not a replacement for Cost Explorer or Cloud Billing. Those remain the authoritative record of what you spent. Finitizer is what you put on top when the console has run out of things to tell you, or when nobody is opening the console in the first place.

This page covers both of those cases: what the native tools do not look at, and why the things they do find so often go unactioned.

Fourteen tools, one job

Between them, AWS and Google Cloud ship at least fourteen separate cost surfaces: Cost Explorer, the Cost and Usage Report, Budgets, Compute Optimizer, Cost Optimization Hub, Trusted Advisor, Cost Anomaly Detection and S3 Storage Lens on one side; Cloud Billing reports, Budgets, Recommender, FinOps Hub, BigQuery INFORMATION_SCHEMA and the BigQuery recommenders on the other.

Each has its own enablement step, its own permissions, its own lookback window, and its own idea of what a recommendation looks like. Three failures compound from that.

Nothing is in one place. Rightsizing lives in Compute Optimizer, commitment coverage in Cost Explorer, best-practice checks in Trusted Advisor, storage waste in S3 Storage Lens. Cost Optimization Hub consolidates some of these and not others, and nothing consolidates the Google Cloud side with the AWS side at all.

Each has to be switched on, separately. Compute Optimizer requires an opt-in. Organisation-wide visibility requires opting in from the management account. Longer lookback windows are a paid feature. And 426 of Trusted Advisor's 482 checks are gated behind a Business or Enterprise Support plan.

Almost nobody has access. These consoles sit behind billing permissions that most engineers do not have. The people who can see the recommendations are usually in finance or a central platform team; the people who can act on them are the engineers who own the workloads. No native tool has a mechanism for getting a finding from one to the other.

The result shows up in the industry data: the FinOps Foundation's State of FinOps 2026 survey found that 44% of organisations still report limited visibility into cloud spend despite having adopted cloud-native and third-party tools.

Finitizer's answer is deliberately unglamorous. One application, one login, every cloud and every service in the same place, with role-based access so the engineer who owns a workload sees their own findings without being granted billing permissions. Findings are delivered into Slack, Jira and pull requests rather than waiting in a console for somebody to visit.

A recommendation nobody sees is worth exactly zero, however good the algorithm that produced it.

Capability comparison

Ratings are Strong, Partial, Limited and None rather than ticks and crosses, because native capability varies by provider, by support plan, and by whether you have paid to switch a feature on. A tick would hide all three.

Coverage, service by service

Below, native coverage is judged on whether the provider ships a cost optimization capability for that service, not merely whether the service appears on the bill.

Data, analytics, streaming and ML

Native cost optimization is thinnest exactly where modern spend is growing fastest. Most of these services get commitment or reservation recommendations only, or nothing at all.

This gap is structural rather than accidental. Native rightsizing is built on CloudWatch utilisation metrics, which map cleanly onto instances and volumes. They do not map onto a Kinesis shard, a Bedrock batch job, or a stale S3 lifecycle rule.

The AI rows deserve a specific note. The State of FinOps 2026 survey named granular monitoring of AI spend, meaning tokens, inference requests and GPU utilisation, as the single most requested tooling capability of the year, and one the market has not yet delivered at scale. Neither cloud offers it natively. Google Cloud's idle VM recommender explicitly excludes instances with GPUs or TPUs, which means the most expensive machines in a modern estate are the ones it will never comment on.

BigQuery

Google Cloud gives BigQuery two cost recommenders and a set of SQL views. Both are useful. Neither is an analysis product.

Around 30 distinct BigQuery analyses run across 8 dedicated pages in the product. The native starting point is a SQL view and a blank editor.

Google Cloud infrastructure

The ratings above are generous, and it is worth being specific about why Recommender should be treated as an early-maturity tool. These are Google's own documented limits, not opinion: the idle VM lookback is configurable between 1 and 14 days and cannot be extended, so month-end and seasonal patterns are invisible by construction; it reads CPU and network only, not memory or disk; Google warns that its default thresholds classify a VM as idle when monitoring agents generate most of its traffic, and that those thresholds may change; and no recommendations at all are produced for instances with local SSDs, GPUs or TPUs, App Engine flexible resources, Dataflow, or GKE. Recommendations also surface per product and per project, so there is no estate-wide ranked list of what to do first.

Compute and database primitives

This is where native tooling is genuinely strong, and where Finitizer largely agrees with it.

If your estate is mostly EC2 and RDS, the native tools will find a large share of your waste, and that is worth saying plainly. The question is what proportion of your bill that actually describes, and for most organisations running data, analytics or AI workloads, it is a shrinking one.

Depth: the same finding, both ways

Coverage is only half the argument. Here is what the difference looks like on a single resource.

Compute Optimizer, on an EC2 instance:

Finding      Over-provisioned
Current      m5.2xlarge
Recommended  m5.xlarge
Basis        CPU and network utilisation, 14 days
Savings      $138.24 / month

That is a good recommendation. It is also the whole of it: no owner, no ticket, no evidence you can hand to the team that runs the workload, no memory metric unless you installed the CloudWatch agent, and a 14-day window that will miss a month-end batch job. Extending that window to 93 days is a paid feature.

Finitizer, on the same instance:

Resource   i-0f2a…c41d  (eu-west-1, account 4471…9082)
Condition  Over-provisioned instance
Evidence   CPU p95 11.4% over 90 days. Network p95 42 Mbps of 10 Gbps.
           Disk IOPS p95 340 of 6000. Month-end peak 2026-07-31 reached
           CPU 46%, still within m5.xlarge headroom.
Saving     $138.24 / month  (differential: m5.2xlarge to m5.xlarge, same
           region, after your Savings Plan coverage of 61%)
Action     Resize to m5.xlarge in the next maintenance window
Owner      platform-team  (tag: owner)
Terraform  aws_instance.api_worker_02, module infra/compute
Ships as   Pull request against infra-live, or Jira ticket PLAT-4471

Same instance, same saving, different object. One is a number in a console that somebody with billing permissions has to go and look at. The other is a piece of work that arrives in front of the person who owns the workload, with the proof attached and a route to done.

The gap is wider still where native has no opinion at all. There is no console that will tell you a provisioned Kinesis stream has had zero consumers for six weeks, that your Support plan tier costs more than the usage it is calculated on, or that 38% of your spend carries no owner tag.

Where to go next

• What Finitizer looks for is the anatomy of a finding, and how savings are estimated
• Connecting an account covers the read-only access model and what it can and cannot see
• From finding to fix is the loop from finding to ticket to measured saving