Cloud Optimisation
The Multi-Cloud Blind Spot
Why provider-native cost tools are structurally single-cloud — and why the optimizations that fall between the seams are the ones most likely to stay uncaptured.
Cloud Optimisation
Why provider-native cost tools are structurally single-cloud — and why the optimizations that fall between the seams are the ones most likely to stay uncaptured.
Every cloud cost program of any scale runs into the same architectural reality eventually: the provider-native tools each see only their own platform. AWS-native tooling doesn't surface Azure inefficiencies. Azure-native tooling doesn't surface GCP inefficiencies. The recommendations each tool produces are anchored to its provider's own economics, framed in terms that fit that provider's strategy — Reserved Instances, Savings Plans, Committed Use Discounts, each with its own logic, its own discount surface, its own lock-in profile.
For enterprises with cross-provider estates — which is most of them at any meaningful scale — this means the cost picture is fragmented by design. The FinOps team assembles a composite view by stitching together three dashboards that don't share a schema, three recommendation queues that don't share a policy model, and three remediation paths that don't share a workflow. The composite is functional; it isn't unified. And the inefficiencies that fall between the seams — the ones that aren't visible to any single provider's tool — are the ones most likely to stay uncaptured.
The savings that single-cloud tooling can identify are real, but they're bounded by what's visible from inside one provider's perspective. The savings that single-cloud tooling can't identify are often the highest-leverage ones in the estate.
Cross-cloud workload placement is the obvious example: a workload running in one provider may be substantially cheaper to run in another, but neither provider's native tooling will tell you so. Commitment portfolio balancing is another — an enterprise over-committed on one provider and under-committed on another is leaving discount room on the table, and the optimization is invisible to any single-provider tool because it requires seeing both sides of the imbalance simultaneously. Redundant capacity across providers, duplicated data egress paths, multi-region architectures that don't actually require all the regions they span — these are the categories of waste that grow precisely because no single-cloud tool can see them.
The temptation, looking at this gap, is to assume one of the hyperscalers will eventually build the cross-cloud view. They won't, and the reason is structural rather than technical.
Each provider's cost tooling is built to optimize within that provider's economics. A genuinely neutral cross-cloud view would have to surface recommendations like "move this workload off our platform" — and no provider's product roadmap will prioritize building that. The cross-cloud view isn't a feature gap the hyperscalers will close; it's a conflict of interest baked into the business model. The customer's optimization frontier and the provider's growth surface point in opposite directions, and the tooling reflects whose interests built it.
Which means cross-cloud cost optimization, if it's going to happen, has to happen from a vendor whose economics aren't tied to any single provider's preservation. The platform's interests have to align with the customer's full estate, not any one slice of it.
The shift the category needs is a platform that operates across the full estate through a single lens — one workflow, one policy model, one Git pipeline, one set of recommendations grounded in the customer's complete infrastructure rather than any one provider's slice of it.
This is the layer JetScale operates in. AWS, Azure, and GCP are seen through the same instrumentation, governed by the same business policies, surfaced into the same PR workflow. Recommendations are produced based on what's viable for the customer's environment as a whole, not what's strategic for any one provider. Cross-cloud inefficiencies that fall between the seams of native tooling — workload placement, commitment imbalance, redundant capacity, egress optimization — become first-class objects in a single workflow rather than blind spots between three dashboards.
The operational consequence is significant. The FinOps team stops doing the manual reconciliation work of comparing three native dashboards against each other. The platform team stops maintaining three separate remediation paths with three different change-management conventions. The recommendations that surface are pre-filtered against the customer's actual policies and operating reality, regardless of which provider they touch. The composite view becomes a unified one.
The deeper implication is that cross-cloud cost optimization isn't a tooling question — it's a procurement-level one. Multi-cloud strategy is upstream of cost optimization: the decision to operate across providers is usually made for reasons of resilience, vendor leverage, regulatory geography, or workload-fit. Whatever drove the strategy, it implies an optimization layer that matches it. A multi-cloud strategy paired with single-cloud cost tooling is a strategy missing a load-bearing component.
The procurement framing also clarifies the build-vs-buy calculation in a useful way. Stitching together native tooling across providers is buildable in the short run, but the maintenance burden compounds quarter over quarter as each provider's APIs, pricing models, and recommendation schemas evolve independently. A unified platform absorbs that drift on the customer's behalf. The longer the estate operates across providers, the worse the math on the DIY approach gets.
In a multi-cloud world, single-cloud cost tools are a category that's aging out. The platforms that will define the next decade are the ones architected for the estate as it actually exists — distributed across providers, governed by one operating model, optimized through one workflow.