# Multi-Cloud Cost Optimization: AWS, Azure, GCP, OCI & Kubernetes

URL: https://enjooy.blog/articles/varcio-multi-cloud-cost-optimization-aws-azure-gcp-oci-kubernetes-detectors
Published: 2026-11-15 · Updated: 2026-11-15
Author: Lana Steiner (Cloud Services & DevOps Editor)
Category: Cloud
Keywords: multi-cloud cost optimization, AWS cost optimization, Azure cost management, Google Cloud cost optimization, OCI cost optimization, Kubernetes cost management, FOCUS FinOps standard, cloud egress costs

> Multi-cloud cost optimization guide: AWS, Azure, GCP, OCI and Kubernetes pricing levers, commitments, egress, spot, FOCUS and Varcio's 316 detectors.

Key takeaways
Multi-cloud cost control in short
Multi-cloud cost problems are rarely about one expensive service. They come from four billing models, commitments that cannot move between clouds, egress charges that punish data gravity, and Kubernetes clusters that hide spend behind shared nodes. Normalize the data first (the FOCUS standard helps), size commitments to each cloud's stable floor, put interruptible work on spot, and allocate containers by requests and usage. Varcio covers the five surfaces with 316 active detectors: AWS 102, Azure 73, GCP 59, OCI 38, Kubernetes 21 and 23 cross-cloud.

## Four invoices, one question

Picture a platform lead on the last day of the quarter. The AWS bill is a Cost and Usage Report with hundreds of columns. Azure sends a differently shaped export with its own idea of a "meter". Google bills by project with credits netted in. A small OCI footprint arrives as a CSV. And a Kubernetes cluster sits across all of it, spending money nobody has named. The CFO asks one question: what does our infrastructure cost, and is it going up for a good reason?

Answering it is the multi-cloud cost problem in miniature. The hard part is rarely one expensive service. It is that each cloud names, meters and discounts things differently, so a view built for one provider cannot see the idle environment duplicated in another, and the cheapest decision on one cloud (a long commitment) may be the wrong one when the workload moves.

This guide walks through why teams end up multi-cloud, what the adoption data does and does not say, the cost levers on each provider (pricing models, commitment discounts, egress, spot and rightsizing), how the FOCUS standard normalizes billing data, how to allocate Kubernetes cost honestly, and how the 316 detectors in [Varcio](/articles/what-is-varcio-ai-cloud-cost-optimization-finops-platform) map to all of it. All pricing mentioned is as of November 2026 and linked to the provider's page; list prices change and vary by region, so treat the numbers as orders of magnitude and check the pricing pages before you decide.

## Why teams run more than one cloud

Few organizations choose multi-cloud from a blank sheet. The usual reasons are:

- **Acquisition and inheritance.** A merged company brings its own cloud. Moving is a multi-year project, so both stay.
- **Best-of-breed services.** A data platform on one cloud, enterprise identity or productivity integration on another, GPU capacity wherever it can be found.
- **Commercial leverage.** A credible second option changes a renewal negotiation, even if you never move.
- **Resilience and regulation.** Concentration risk and data-residency rules push some workloads to a second provider or region.
- **Database placement.** Some teams run Oracle-database-heavy workloads on OCI while the rest of the estate lives elsewhere.

### What the adoption data says

Be careful with headline numbers, because definitions vary. According to figures reported from [Flexera's 2026 State of the Cloud survey](https://www.flexera.com/blog/finops/the-new-era-of-cloud-what-2026-data-tells-us-about-spend-scale-and-strategy/) of 753 cloud decision-makers, 73% of organizations run hybrid estates (up three percentage points), multi-cloud adoption rose by two points, and only 14% operate exclusively multi-cloud without a private cloud. A Flexera blog chart caption cites 33% using multiple public and multiple private clouds. A separate vendor blog claims 89% of organizations use services from multiple providers and attributes it to the same report. I could not reconcile that figure with Flexera's own materials, so treat it with caution: the answer depends on whether "uses" means a production workload, a SaaS product on another cloud or a single experimental account.

On waste, the same report estimates [29% of cloud spend is wasted](https://www.flexera.com/blog/finops/flexera-2026-state-of-the-cloud-report-the-convergence-of-cloud-and-value/), up from about 27% (most sources; one differs on the baseline), the first rise after five years of decline. This is a respondent self-estimate for IaaS and PaaS, not an invoice audit. Flexera links the rise partly to AI workloads and newer services that are harder to rightsize. The FinOps Foundation's [State of FinOps 2026 survey](https://www.prnewswire.com/news-releases/state-of-finops-survey-ai-value-and-skills-top-priorities-as-finops-matures-across-technology-value-98-manage-ai-90-saas-64-licensing-48-data-center-302691410.html) (February 2026) adds that 98% of respondents now manage AI spend and 90% manage SaaS, and that FinOps scope has widened beyond public cloud. For multi-cloud teams, that means the bill you are trying to reconcile is growing in surface area as well as size.

### The honest trade-off

Multi-cloud adds cost as well as removing risk. You lose volume-discount concentration, you pay egress when data crosses clouds, you duplicate tooling and skills, and every commitment pool shrinks. A simple rule: run more than one cloud for a reason you can write down, and then make the cost of that reason visible. The rest of this guide is about making it visible.

## How cloud pricing works: the four levers

Across all providers, compute and database cost is shaped by four levers, in rough order of impact:

1. **Right-size and remove.** Pay for what you need, and delete what nobody uses. No commitment risk.
2. **Commit.** Trade flexibility for a discount on the usage you are confident will persist.
3. **Go interruptible.** Run fault-tolerant work on spare capacity (spot, preemptible) at steep discounts.
4. **Move less data.** Egress, cross-zone and NAT charges can silently exceed the compute they serve.

The order matters: commit after you have right-sized, or you lock in the waste.

## Commitment discounts, provider by provider

Every major provider offers a discount for committing to usage, and none of them transfer across clouds. Headline percentages are ceilings measured on favorable examples. Your rate depends on instance family, region, term and payment option.

| Provider     | Instrument                            | Headline discount (provider's wording)                         | Notes                                                                         |
| ------------ | ------------------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| AWS          | Compute Savings Plans                 | Up to 66% off On-Demand                                        | Flexible across instance family, region and some services                     |
| AWS          | EC2 Instance Savings Plans            | Up to 72% off On-Demand                                        | Tied to an instance family in a chosen region                                 |
| Azure        | Reservations                          | Up to 72% vs pay-as-you-go (VMs)                               | Footnote range 36 to 72%; you choose family, size and region                  |
| Azure        | Savings plan for compute              | Up to 65% on a specific example                                | Footnote range 11 to 65%; commits to an hourly amount                         |
| Google Cloud | Resource-based CUDs                   | Up to 55%, up to 70% for memory-optimized                      | Per Google's committed use discount docs                                      |
| Google Cloud | Flexible (spend-based) CUDs           | Roughly 28% (1-year) and 46% (3-year) per third-party analysis | Confirm on Google's pricing page; sources differ on memory-optimized coverage |
| OCI          | Universal Credits (annual commitment) | Negotiated, not published                                      | Consultancy estimates range from about 20% to 60%; verify against a quote     |

Sources: [AWS Savings Plans pricing](https://aws.amazon.com/savingsplans/pricing/) and [plan types](https://docs.aws.amazon.com/savingsplans/latest/userguide/plan-types.html); [Azure reservations pricing](https://azure.microsoft.com/en-us/pricing/offers/reservations) (the 65% figure is footnoted to a single M64dsv2 Linux VM in East US over 36 months, priced as of January 2026); [Google's committed use discounts overview](https://docs.cloud.google.com/compute/docs/instances/committed-use-discounts-overview); [OCI pricing](https://www.oracle.com/cloud/pricing.html). Do not read the Azure rows as proof that reservations beat savings plans by seven points: the two benchmarks use different VMs.

### The mechanics that bite

- **Commitments are mostly one-way.** Microsoft's documentation says a savings plan can be neither cancelled, exchanged nor refunded, and an active AWS Savings Plan generally cannot be cancelled, resized, exchanged, sold or transferred during its term. Google CUDs are generally described as non-cancellable too, though I did not find that on a primary Google page.
- **Azure is tightening.** Per [Microsoft's policy notice](https://learn.microsoft.com/en-au/azure/cost-management-billing/reservations/reservation-exchange-policy-changes), reservation exchanges end on February 1, 2027 for services covered by savings plans, and refunds are capped at $50,000 in total canceled commitment per rolling 12 months for a billing profile or enrollment. Cancellation itself is unchanged.
- **Percent coverage is a vanity metric.** What matters is utilization (are you using what you bought?) and the stable floor you committed against.

### Worked example: what a commitment does when usage falls

This is an illustration with a hypothetical discount, not a provider quote. Suppose you commit to cover $50,000 a month of on-demand-equivalent compute, at a 30% discount, so the commitment costs $35,000 whatever you use. Any usage above $50,000 is billed on-demand.

| Monthly usage (on-demand equivalent) | Cost with commitment        | Cost with no commitment | Saving  |
| ------------------------------------ | --------------------------- | ----------------------- | ------- |
| $60,000                              | $35,000 + $10,000 = $45,000 | $60,000                 | $15,000 |
| $50,000                              | $35,000                     | $50,000                 | $15,000 |
| $40,000                              | $35,000                     | $40,000                 | $5,000  |
| $35,000                              | $35,000                     | $35,000                 | $0      |
| $30,000                              | $35,000                     | $30,000                 | -$5,000 |

The break-even is usage falling 30% below the committed amount (to $35,000). Above that you still save, but far less than the sticker discount suggested, which is why commitments should be sized to a floor that has held for months, not to peak. If the stable floor is $40,000 and you commit $50,000, you have bought $10,000 of risk. Varcio's commitment negotiator reviews historical on-demand usage, recommends strategies with projected savings and break-even periods, supports dry-run simulation, models commitments on AWS, Azure, GCP and OCI, and executes purchases on AWS, Azure and GCP only on approval. On OCI, Universal Credits are modelled, not purchased.

## Egress: the cost of data gravity

Compute is cheap to move. Data is not. Egress, the charge for data leaving a provider or a region, is the line item that makes multi-cloud architectures expensive when they are designed by diagram instead of by bytes.

| Provider               | Free allowance                                                                                                                                                                                                           | Overage (illustrative list rates)                                                                                                                                                                                                                                      |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| AWS                    | 100 GB a month to the internet, aggregated across services and regions ([AWS](https://aws.amazon.com/de/blogs/aws/aws-free-tier-data-transfer-expansion-100-gb-from-regions-and-1-tb-from-amazon-cloudfront-per-month/)) | About $0.09 per GB for the first 10 TB in common US regions, falling to about $0.05 above 150 TB per [third-party guides](https://www.cloudzero.com/blog/aws-egress-costs); some regions cost more. Check [AWS pricing](https://aws.amazon.com/ec2/pricing/on-demand/) |
| OCI                    | 10 TB a month outbound                                                                                                                                                                                                   | About $0.0085 per GB beyond, per [Oracle's own commentary](https://blogs.oracle.com/database/dont-be-fooled-by-misleading-data-egress-announcements) and third-party comparisons; verify with [OCI pricing](https://www.oracle.com/cloud/pricing.html)                 |
| Azure and Google Cloud | Smaller free tiers                                                                                                                                                                                                       | Varying tiered rates by region and destination; consult each provider's bandwidth pricing page                                                                                                                                                                         |

A worked illustration, using the figures above and ignoring free allowances for AWS: moving 50,000 GB (roughly 50 TB) out in a month costs 10,000 GB at $0.09 plus 40,000 GB at $0.085, which is $900 plus $3,400, or $4,300 on AWS-style tiered rates. On OCI-style pricing it is (50,000 minus 10,000) GB at $0.0085, or $340. That roughly 12-fold gap is why a data-heavy analytics job should sit where its data is, and why Oracle's egress pricing is a selling point. These are list prices; negotiated and committed rates, and inter-region and private-link charges, differ.

### The small charges that add up

- **Cross-AZ traffic.** Third-party guides put AWS cross-availability-zone transfer at about $0.01 per GB in each direction. A chatty service mesh across zones can quietly cost more than the instances it connects.
- **NAT gateways.** In US East a NAT gateway is commonly quoted at $0.045 per hour plus $0.045 per GB processed ([example breakdown](https://cloudchipr.com/blog/aws-nat-gateway-pricing)). Pulling container images or calling AWS services through NAT instead of a gateway or interface endpoint is a classic bill spike.
- **Cross-cloud replication.** Replicating a 10 TB dataset daily across providers means paying egress every time.

### Switching fees are coming down

Pressure from regulators is changing the exit cost. Google announced in January 2024 that it would stop charging data transfer fees for customers switching providers, and AWS followed in March 2024 (customers moving more than 100 GB must contact support for credits, according to [coverage](https://itprotoday.com/amazon-web-services/aws-follows-google-cloud-in-ending-cloud-switching-costs)). In September 2025 Google launched [Data Transfer Essentials](https://www.techradar.com/pro/google-slashes-uk-and-eu-cloud-data-transfer-fees-ahead-of-eu-data-act), which lets EU and UK customers move data to other providers free, including for multi-cloud setups rather than only for leaving. Microsoft introduced at-cost transfer fees in the EU in August 2025 under the EU Data Act, per [reporting](https://www.theregister.com/2025/09/10/big_clouds_scramble_over_eu/). Terms differ by provider and region, and the Data Act's treatment of switching charges has dates that differ between sources, so confirm with each provider before planning around them. Ordinary multi-cloud traffic still pays regular egress.

## Spot and preemptible capacity

Spare capacity sold at a discount is the largest single compute lever for the right workloads. Reported discounts and notice periods:

| Provider     | Product               | Reported discount                                                                                                                                                             | Interruption notice                                                                                        |
| ------------ | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| AWS          | EC2 Spot              | Up to 90% vs On-Demand                                                                                                                                                        | Two minutes ([AWS docs](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-spot-instances.html)) |
| Azure        | Spot VMs              | Up to 90%                                                                                                                                                                     | About 30 seconds                                                                                           |
| Google Cloud | Spot VMs              | Up to 91%, with a minimum of about 60% per one source                                                                                                                         | About 30 seconds, though sources are not consistent                                                        |
| OCI          | Preemptible instances | Always 50% off on-demand ([Oracle](https://blogs.oracle.com/cloud-infrastructure/announcing-preemptible-instances-a-new-kind-of-compute-instance-available-at-a-50-discount)) | Short notice before deletion                                                                               |

The Azure and Google figures come from [a Flexera comparison](https://www.flexera.com/blog/finops/understanding-excess-cloud-capacity-amazon-ec2-azure-google-spot-instances-vms/) and other secondary sources; discounts vary by region, machine type and demand.

Spot is a good fit for stateless web tiers behind a load balancer, CI runners, batch and data processing, and worker queues, and a poor fit for single-instance databases or anything that cannot checkpoint. Diversify across instance types and zones, and design for the interruption rather than hoping it does not come.

Illustration with hypothetical rates: 200 batch workers at $0.20 an hour for 730 hours cost $29,200 a month on demand. At a 65% spot discount that is $10,220. Add 5% for work re-run after interruptions and you pay about $10,731, a saving of roughly $18,469 (63%). The saving is real but only if interruption handling is real; a job that restarts from zero on every eviction can eat the discount.

## Rightsizing and idle waste

The least glamorous lever is often the biggest. Rightsizing means matching instance and database sizes to measured utilization, usually within a family so no re-architecture is needed. On a single instance, halving the size roughly halves the price: a $0.40 an hour machine at 730 hours is $292 a month, and its half-size sibling is $146. Multiply by a fleet and the number gets attention.

Each provider ships native recommendations, and they are a reasonable start. Varcio reads Google's Recommender output, Azure Resource Graph and Azure Monitor data, and OCI's Cloud Advisor and Cloud Guard signals alongside CloudWatch metrics on AWS. Beyond rightsizing, the classic zero-regret list is the same everywhere: unattached disks and orphaned snapshots, idle load balancers and NAT gateways, stopped instances with attached storage, oversized databases and non-production environments running all weekend.

Two cautions. Rightsizing from averages hides peaks, so look at high percentiles over a representative period. And a savings plan bought before rightsizing locks in the old, larger size.

## Kubernetes: requests, usage and idle

A cloud bill shows nodes, not workloads. Every team shares the same instances, so the invoice cannot say which namespace caused the growth. And scheduling works on requests, not usage: the Kubernetes scheduler compares a pod's resource requests with node capacity to decide where it fits, which means what is reserved determines how many nodes you need, regardless of what the containers use.

That gap is large. Cast AI's [2025 Kubernetes Cost Benchmark Report](https://cast.ai/press-release/new-kubernetes-cost-benchmark-report-reveals-persistent-cloud-waste/) found average CPU utilization of 10% (down from 13% the year before) and memory utilization of 23% across clusters, drawn from the vendor's own customer data before its automation was applied and excluding clusters under 50 CPUs. A later edition reportedly put CPU at 8% and memory at 20%. This is vendor research from a company that sells optimization, so read it as directional rather than as a census, but it matches what most platform teams see when they first look.

### Requests versus usage: who pays?

Allocation tools have to choose how to charge a namespace for a node. An illustration with a hypothetical $30 per vCPU per month:

| Team     | CPU requested | CPU actually used | Request-based charge | Usage-based charge |
| -------- | ------------- | ----------------- | -------------------- | ------------------ |
| Payments | 40 vCPU       | 6 vCPU            | $1,200               | $180               |
| Search   | 20 vCPU       | 15 vCPU           | $600                 | $450               |
| Batch    | 10 vCPU       | 9 vCPU            | $300                 | $270               |

Request-based charging pushes teams to trim their requests, because they are paying for reservation. Payments is billed $1,200 for $180 of work, and has an incentive to fix it. Usage-based charging looks fairer but leaves $1,020 for Payments plus smaller amounts for others sitting in an "idle" bucket that someone must absorb, and teams then have no incentive to trim. The common compromise is to allocate by the higher of requests and usage, show the idle cost explicitly, and decide whether to share it proportionally or leave it with the platform team. [OpenCost](https://www.cncf.io/blog/2024/10/31/opencost-advances-to-the-cncf-incubator/), the vendor-neutral project that reached CNCF Incubating status in October 2024, is commonly described as treating cluster idle cost as asset cost minus workload cost; the specification and source are the place to confirm exact formulas.

On AWS, [Split Cost Allocation Data for EKS](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data.html) pushes pod-level cost into the Cost and Usage Report using CPU and memory consumption, and since October 2025 supports importing Kubernetes labels as cost allocation tags. If you run on EKS and want billing-grade allocation inside the invoice, it is worth enabling.

### What Varcio does on Kubernetes

Varcio maps container cost to namespace, deployment and team (read from team, owner or cost-center labels) and rightsizes from measured utilization. It supports four data modes: Kubecost, OpenCost, the native Kubernetes API or a bundled Helm-deployed in-cluster agent that pushes metrics outbound and reads usage from metrics-server (the agent is available on Business and Enterprise plans). The 21 Kubernetes detectors flag:

- Request versus usage drift for CPU and memory, and idle pods still reserving requests
- Spot candidates for batch and worker workloads, and node bin-packing headroom
- DaemonSet overhead, orphaned Persistent Volumes and claim utilization gaps
- LoadBalancer services without endpoints, plus missing requests or limits and privileged containers

The analytical product runs on read-only credentials, and write-back through the agent is opt-in with every change needing approval. See the [Kubernetes cost management page](https://varcio.com/platform/kubernetes-cost-management).

## FOCUS: one schema for four invoices

The FinOps Open Cost and Usage Specification ([FOCUS](https://focus.finops.org/what-is-focus/)) is an open standard from the FinOps Foundation that gives provider billing data one shared schema, column naming and set of definitions. The ambition is that a query written once works on AWS, Azure, Google Cloud, Oracle and SaaS exports. Recent milestones:

| Version       | Ratified                                     | Notable additions                                                                                           |
| ------------- | -------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| 1.3           | December 2025 (sources say the 4th or 5th)   | SplitCostAllocationData column for pod and task level attribution; a separate Contract Commitment dataset   |
| 1.4           | June 4, 2026                                 | Two datasets (including Invoice Detail and Billing Period), 47 columns, six attributes, 17 glossary entries |
| 1.5 (planned) | December 2026 per the project's release plan | AI scope such as token consumption and model identity                                                       |

### The cost columns that matter

FOCUS separates cost concepts that provider reports tend to blur:

- **BilledCost** is what appears on the invoice, before amortization.
- **ContractedCost** applies negotiated discounts; if none apply it defaults to list cost.
- **EffectiveCost** is the amortized cost, spreading upfront commitment purchases across the usage they cover. Per the [v1.3 spec](https://focus.finops.org/docs/specification/v1-3/columns/effective-cost/), a purchase that covers future eligible charges must show zero effective cost.
- Commitment discounts are, in effect, the gap between contracted and effective cost.

Worked example (illustrative numbers): you pay $36,000 upfront for a one-year reservation on January 1. BilledCost shows a $36,000 charge in January and nothing in February. EffectiveCost shows the purchase line at $0 and spreads $3,000 a month across the covered usage (about $98.63 a day on a 365-day year). Anyone comparing teams on billed cost will think the January team is expensive and the others free. Anyone using effective cost sees the real run rate. This is the single most common reason multi-cloud dashboards disagree with finance.

### Adoption: what is and is not settled

Microsoft documents a [FOCUS cost and usage details schema](https://learn.microsoft.com/en-us/azure/cost-management-billing/dataset-schema/cost-usage-details-focus) for Azure, and commentary indicates exports from the other major providers, but provider support is opt-in and not uniform across versions, and I could not confirm the current export status of every provider for 1.3 and 1.4. Check each provider's billing export documentation, and run the FOCUS Validator on whatever you ingest. One reported gap as of September 2026 is that no major AI API provider had published a formal conformance statement.

Practically: even where a provider emits FOCUS-shaped data, you still need your own allocation (tags, accounts, Kubernetes labels) on top. FOCUS standardizes the columns, not your ownership model. Varcio normalizes spend and inventory into its own cross-cloud ledger, which is what the 23 cross-cloud detectors run against; FOCUS is the open format you can use alongside it for your own warehouse and BI.

## Varcio detector coverage by cloud

| Surface            | Active detectors | Primary data sources                                                                                |
| ------------------ | ---------------- | --------------------------------------------------------------------------------------------------- |
| AWS                | 102              | Cost Explorer, Cost and Usage Report via Athena, CloudWatch                                         |
| Microsoft Azure    | 73               | Azure Cost Management, Resource Graph, Azure Monitor                                                |
| Google Cloud       | 59               | BigQuery billing export, Asset Inventory, Recommender                                               |
| Oracle Cloud (OCI) | 38               | Usage API, Cost and Usage Reports, Monitoring, Resource Search, Cloud Advisor, Cloud Guard, Budgets |
| Kubernetes         | 21               | Kubecost, OpenCost, native API or in-cluster agent                                                  |
| Cross-cloud        | 23               | Normalized cross-cloud ledger                                                                       |
| **Total**          | **316**          |                                                                                                     |

Every finding is costed and ranked by savings, confidence and effort, so a single queue drives the work regardless of which cloud it came from.

**AWS (102 detectors).** The deepest coverage and the widest remediation action set of any provider. Onboarding uses IAM AssumeRole with an external ID and no stored static keys, and the role can stay read-only until you enable remediation. Typical early wins are unattached EBS volumes, orphaned snapshots, idle NAT gateways and underutilized databases. See the [AWS cost optimization page](https://varcio.com/platform/aws-cost-optimization).

**Azure (73 detectors).** Subscription and resource group coverage with budget and policy enforcement and rightsizing behind approval gates. The connection is a Service Principal scoped to chosen subscriptions, stored encrypted. See the [Azure cost management page](https://varcio.com/platform/azure-cost-management).

**Google Cloud (59 detectors).** Billing export, asset inventory, monitoring and Recommender output, with an encrypted service account key scoped to billing and asset inventory and short-lived tokens minted per call. Project-level attribution keeps spend traceable to a team. See the [Google Cloud cost optimization page](https://varcio.com/platform/gcp-cost-optimization).

**OCI (38 detectors).** Usually the afterthought in cost tooling, and treated here as a first-class surface. Ten OCI remediation types are available, such as stopping idle instances, deleting unattached volumes and making public buckets private, along with parking for instances and instance pools. The vendor is candid that AWS still has the widest remediation set. See the [OCI cost optimization page](https://varcio.com/platform/oci-cost-optimization).

**Cross-cloud (23 detectors).** These run against the normalized ledger and catch what provider-native tools cannot: duplicated environments across clouds and redundant workloads spanning providers, plus patterns such as unassigned spend and AI cost issues. The waste exists only in the gaps between clouds, which is where a unified platform earns its place.

**AI workloads.** GPU and model spend is often the least attributed line on the bill. The AI Infrastructure module covers Amazon SageMaker and Bedrock, Google Vertex AI, and Azure OpenAI, AI Foundry and Azure ML; AI Economics traces tokens and dollars to the owning team. Idle endpoints and over-provisioned GPU instances are typically the largest and safest early wins. See our [guide to cloud AI cost control](/articles/varcio-generative-ai-mlops-copilots-bedrock-azure-openai-gemini).

## When native tools are enough

Honesty is cheaper than a wasted purchase. If you run one cloud, have a small estate and a person who reads the bill monthly, the provider's own cost explorer, anomaly detection and recommendations will carry you a long way, and they are free or close to it. A platform starts paying off when you have several clouds or accounts, need allocation that finance trusts, want costed findings ranked in a single queue, or need approvals and an audit trail around remediation. For the unit economics, anomaly and forecasting side of the story, see our [FinOps unit economics guide](/articles/varcio-finops-unit-economics-anomaly-detection-roi-benchmarks).

## A sensible rollout order

1. **Connect your largest cloud account first** with read-only access, reconcile spend against the invoice, and review the first costed findings.
2. **Add the remaining clouds and Kubernetes clusters** so the normalized ledger and cross-cloud detectors have data to compare.
3. **Fix the cheap wins before committing.** Delete idle resources and rightsize, then size commitments to each cloud's stable floor.
4. **Set tag policies and budgets**, then enable pull request cost review for Terraform changes.
5. **Turn on approvals in Slack or Teams**, and consider Autopilot only for low-risk cleanup. Our guide to [safe cost automation](/articles/varcio-safe-cloud-cost-automation-approval-gated-remediation-autopilot-security) explains the guardrails.

To see these detectors run on your own accounts, use the free 14-day trial from the [Varcio platform page](https://varcio.com/platform).

## Frequently asked questions

### How many waste detectors does Varcio have for each cloud?

Varcio runs 316 active detectors: 102 for AWS, 73 for Azure, 59 for Google Cloud, 38 for Oracle Cloud Infrastructure, 21 for Kubernetes and 23 cross-cloud detectors that run on a normalized ledger.

### What is the FOCUS standard and why does it matter for multi-cloud?

FOCUS, the FinOps Open Cost and Usage Specification, defines a common schema and column definitions for billing data across providers. It lets you compare BilledCost, ContractedCost and EffectiveCost (the amortized figure) the same way on every cloud instead of translating each invoice by hand. FOCUS 1.4 was ratified on June 4, 2026.

### Are commitment discounts transferable between clouds?

No. AWS Savings Plans, Azure reservations and savings plans, Google committed use discounts and OCI Universal Credits each apply only inside their own provider. The practical consequence is that you size and track commitments per cloud, against that cloud's stable usage floor, and treat a commitment as a fixed obligation.

### Why is Kubernetes cost allocation difficult?

The cloud bill shows nodes, but teams consume pods. Scheduling works on resource requests, which are often set once and never revisited, so what a team reserves can differ widely from what it uses. Allocation tools must choose whether to charge for requests, usage or the higher of the two, and decide who pays for idle capacity.

### How does Varcio connect to AWS, Azure, GCP and OCI?

Each provider uses its native trust model. AWS uses IAM AssumeRole with an external ID and no stored static keys. Azure uses an encrypted Service Principal, GCP an encrypted service account key scoped to billing and asset inventory, and OCI an encrypted API signing key.

### Can Varcio find waste that spans multiple clouds?

Yes. 23 cross-cloud detectors run against the normalized ledger to find duplicated environments and redundant workloads that no single provider's tooling can see.