5. The FinOps tool market has 20+ platforms and most organisations pick the wrong one first

The situation

Gartner lists 25+ vendors. The FinOps Foundation landscape has 40+. Tools cost 3-5% of the cloud bill at the high end (Deloitte). No single tool covers all five layers of the reference architecture. The right question is not which tool is best, but which tools at which layer.

The temptation is to buy a platform that promises complete coverage. In practice, every platform excels at one or two layers and provides basic coverage for the rest. An organisation that buys Apptio Cloudability for Layer 5 governance and expects it to replace CAST AI at Layer 4 will be disappointed. An organisation that deploys CAST AI for Kubernetes optimisation and expects it to produce CFO-ready governance packs will also be disappointed. The tool market is layered because the problem is layered.

The complication

Most tools claim to be complete when they excel in one or two layers. 89% say lack of visibility impacts their role (CloudZero). But visibility requires connected systems, not a single dashboard. A FinOps Lead who can see that compute spend increased 20% this month but cannot trace it to the specific team, product, and pull request that caused it has visibility without understanding. Understanding requires data flowing through all five layers.

Tools mapped to five layers

Layer 1: Infrastructure and zombie detection

Note: FOCUS in these tables refers to the FinOps Open Cost and Usage Specification, an open standard maintained by the FinOps Foundation under the Linux Foundation. FOCUS defines a common schema for billing data across all cloud providers, SaaS, and on-premises. Version 1.4 was ratified in December 2025. When a tool is 'FOCUS-native' or 'FOCUS-compliant', it can ingest and export billing data in this standardised format, eliminating manual normalisation. 57% of FinOps practitioners plan to adopt FOCUS in the next 12 months (State of FinOps 2025).

How to evaluate Layer 1 tools

The decision at Layer 1 is binary: use native tools for single-cloud, add CloudBolt or equivalent for multi-cloud. Do not buy a third-party tool for Layer 1 if you run a single cloud provider. AWS Trusted Advisor, Azure Advisor, and GCP Recommender are free, integrated, and improving quarterly. They are not perfect: Trusted Advisor checks are broad but shallow, Azure Advisor recommendations sometimes conflict with security best practices, and GCP Recommender coverage varies by service. But for Layer 1 zombie detection, they are sufficient.

CloudBolt is the exception because it solves a problem that native tools cannot: unified zombie detection across providers with automated remediation. If you run AWS and Azure (common in financial services), you need a single view of idle resources across both. Native tools give you two separate views with different definitions of 'idle.' CloudBolt normalises these into a consistent framework. The JIRA/ServiceNow integration means detected zombies become tickets, not dashboard entries.

Layer 2: Network and data architecture

Network cost tools are the least mature category in the FinOps market. Most organisations rely on native cloud tools because third-party coverage is thin. The opportunity is significant: NAT gateway and data transfer costs are the most commonly underestimated category, and architectural changes at this layer often deliver permanent savings rather than one-time reductions.

Layer 3: Workload orchestration

Workload orchestration tools operate in real-time and target specific infrastructure patterns. The selection depends entirely on what you run: VDI means Nerdio, Kubernetes means Karpenter or Spot by NetApp, non-production environments mean ParkMyCloud or equivalent scheduling.

Layer 4: Optimisation and rightsizing

This layer is where measurable savings happen fastest. CAST AI reports average savings of 50-70% on Kubernetes workloads through automated rightsizing and spot instance orchestration. Infracost operates at the opposite end: preventive rather than detective, catching over-provisioning before it reaches production.

Layer 5: Governance and platforms

Governance platforms compete on three dimensions: allocation accuracy, executive reporting quality, and integration depth with engineering workflows. The market is consolidating. IBM acquired Apptio in 2023 and Kubecost in 2024. Broadcom owns CloudHealth through its VMware acquisition. The implication for buyers: platform stability and roadmap commitment now depend on the acquirer's strategic priorities, not the original vendor's.

How to evaluate Layer 5 platforms

The enterprise platform decision is the highest-stakes tool purchase in FinOps because switching costs are extreme. Migrating from Apptio to CloudHealth (or vice versa) requires rebuilding allocation models, retraining users, and re-establishing executive trust in the numbers. Plan for a 3-5 year commitment when choosing a Layer 5 platform.

Four criteria matter. First, allocation accuracy: can the platform correctly attribute shared costs (Kubernetes clusters, data lakes, shared services) to consuming teams? Test this with your actual data during the proof-of-concept, not with the vendor's demo data. Second, executive reporting: show the CFO and CTO the reports during evaluation. If they cannot understand the output without explanation, the tool will not drive the conversations it needs to drive. Third, FOCUS compliance: a FOCUS-native platform reduces data engineering effort and enables future tool portability. Fourth, engineering integration: does the platform connect to JIRA, ServiceNow, or Slack? If recommendations stay in the platform, they stay unactioned.

Pricing models vary. Apptio and CloudHealth typically charge 1-3% of managed cloud spend. Vantage and Finout charge per-resource. CoreStack and Cloudaware charge per-asset. For a $50M cloud estate, 1-3% means $500K-$1.5M per year. Ensure first-year savings exceed the platform cost by at least 3x, or the business case collapses.

Visibility-to-action bridge

Six vendors have built the integrations that close the gap between dashboards and engineering action. This is the most operationally critical capability in the market. A recommendation in a dashboard is a recommendation that dies. A recommendation in a JIRA ticket gets a sprint allocation. A recommendation that auto-creates a ticket with the affected resource, estimated savings, and remediation steps gets actioned.

Tool selection by maturity

The selection framework below matches tool investment to organisational maturity. Buying an enterprise platform at Crawl stage is the most expensive mistake in FinOps tooling. The implementation cost alone will exceed first-year savings. Start with native tools, which are free. Add third-party tools only when you can state the gap in one sentence.

Decision framework: when to buy versus build

Financial services organisations frequently debate whether to buy a FinOps platform or build custom tooling. The answer depends on three variables: cloud spend, engineering capacity, and regulatory requirements.

Buy when: your cloud spend exceeds $10M, your engineering team does not have capacity to build and maintain custom cost tooling, and your requirements are covered by an existing platform's feature set. The platform vendor handles updates, integrations, and new cloud service support. The total cost of ownership for a platform (licence + implementation + maintenance) is typically lower than custom development above $10M spend because the vendor amortises development costs across hundreds of customers.

Build when: your cloud spend is below $5M (native tools are sufficient), your regulatory requirements are unique enough that no platform covers them (Gap 2 from Section 9), or your engineering team wants cost tooling integrated directly into internal platforms. Lloyds built FinOps Hub 2.0 on GCP rather than buying a platform. This works because Lloyds is GCP-primary, has engineering capacity, and wanted AI-powered recommendations through Gemini integration that no platform provided at the time.

Hybrid when: your cloud spend is $5-20M and growing. Start with native tools and one lightweight platform (Vantage or Finout have free tiers). Add enterprise platforms when spend growth or governance requirements justify the investment. Most financial services organisations end up in the hybrid model because no single platform covers all five layers of the reference architecture, and the regulatory overlay (Gap 2) requires custom logic regardless of which platform you buy.

The build trap to avoid: custom FinOps dashboards built by a single engineer who leaves the company. Custom tooling requires maintenance, documentation, and knowledge transfer. If your FinOps tooling is a collection of Python scripts on one engineer's laptop, you have a person dependency, not a platform. Custom tooling is only viable if it is treated as an internal product with a backlog, a maintainer, and documentation.