Stacklet's Cloud AI FinOps Benchmark covers Azure AI, Bedrock and Vertex AI with one policy set
Stacklet announced the product in a Business Wire release from Arlington, Virginia. The company described it as a set of tested controls that define what good cloud AI cost governance looks like across Amazon Web Services, Google Cloud, and Microsoft Azure. IT Brief Australia covered the launch on September 23, and IT Brief Canada ran the same story. Both follow the release closely. The analyst site Efficiently Connected published its own commentary, which is the only independent analysis available so far.
The controls cover five areas. According to the company, the benchmark spans GPU compute, foundation models, custom models, storage, and token usage, and connects directly to Stacklet's control plane. Named services include AWS Bedrock and SageMaker, Google Vertex AI, and Azure AI. Stacklet says the set continues to grow as providers ship new capabilities.
Stacklet describes how it built the controls: its team studied each provider's AI services at the API level, mapping where cost hides, how it accrues, and which configurations drive waste, then translated those findings into tested controls. That means Stacklet looked at how each provider's management APIs expose resources that cost money, then wrote policies against them.
For Microsoft shops, the Azure coverage is the one real gap in the announcement. "Azure AI" is the only Microsoft name in the release. It doesn't list which Azure resource types or deployment kinds get controls, or whether every control has an equivalent on all three clouds. Buyers whose AI spending runs mainly through Azure should ask Stacklet for the exact list of Azure controls before assuming they match what's available for Bedrock and SageMaker.
Four actions make the Cloud AI FinOps Benchmark an enforcement tool
Stacklet's argument is simple. CEO Travis Stanfield summed it up: "But watching a dashboard doesn't save anyone money," and added that teams need "a standard for what good looks like and a way to act on it". The company says the same controls that measure an environment can also fix it, through automated policies and agentic AI to fix and prevent waste.
The release lists four example actions. Each one targets a different way AI spending gets out of hand:
- Retiring idle endpoints targets inference deployments that keep billing after their traffic stops.
- Pausing stalled training jobs targets expensive compute that is no longer making progress.
- Blocking unapproved models gives FinOps and platform teams a way to limit which models developers can use.
- Alerting when token usage crosses a set threshold handles metered spending, where the problem is volume, not idle hardware.
Stacklet's release says AI infrastructure is one of the least-governed parts of the cloud bill because inference runs around the clock, idle environments linger, jobs and artifacts pile up, and token usage climbs unchecked. Token costs are the item traditional FinOps tools were never built for. A virtual machine left running is easy to spot. A model endpoint quietly using more tokens every week looks like ordinary use until someone sets a threshold.
Efficiently Connected calls the design structurally interesting because it puts assessment and enforcement in one control plane. The analyst notes that most FinOps tools on the market today still separate these concerns: one product tells you what's wrong, another theoretically fixes it. The same commentary is careful to call this Stacklet's claim. No outside test has confirmed it.
The packs come ready out of the box and adjustable, so teams can tune remediation and notification workflows to their environment. The release doesn't say whether the remediation actions are switched on by default or whether they start in alert-only mode. That choice decides how risky it is to roll the benchmark out.
Terraform checks and runtime scans catch cloud AI costs at two different stages
The second main feature is timing. Stacklet says the controls work both on live resources and before anything is deployed: they act on running resources and also check Terraform and other infrastructure-as-code (IaC) files, the configuration files that define cloud resources, before those resources are created.
Stacklet's earlier writing on general cloud waste explains why it covers both stages. In one company post, Stacklet argued that IaC is often not used consistently across teams. Some developers still create resources directly in the provider's console, and some waste, such as idle or underused resources, only shows up days or weeks after going live. The same post gives an IaC-stage example that applies directly to AI: a policy that stops expensive GPUs from being used for development machines.
For AI, the two stages catch different problems. A pre-deployment check can reject a Terraform plan that asks for an oversized GPU or an unapproved model before any money is spent. A runtime check is the only way to catch an endpoint that went quiet after launch, or a training job that stalled halfway through. Avalara's Lindbergh Matillano, Director of Cloud & AI Optimization and the only customer quoted in the launch, made the point about timing: AI cost builds up during experimentation and development, before a workload reaches production.
The release doesn't say which Terraform versions, CI/CD systems or provider modules the pre-deployment checks support. Teams that build Azure AI resources with Bicep or ARM templates, Microsoft's own IaC formats, should check coverage directly. The release names only Terraform and "infrastructure-as-code" in general.
Cloud Custodian shows what kind of controls Stacklet is selling
Stacklet's background explains what the benchmark actually is. Stacklet, the company behind CNCF's Cloud Custodian, sells a commercial platform built on that open-source policy engine, which is hosted by the Cloud Native Computing Foundation. Stacklet's own materials say the platform uses one declarative policy language for the build, deploy and run stages. They claim support for more than 500 cloud resource types and more than 1,500 policies. Those figures are Stacklet's own and describe the platform in general, not the new benchmark.
Our inference is that the Cloud AI FinOps Benchmark is a curated set of those policies, written for AI resources and maintained by Stacklet. That fits the release's description of newly expanded coverage of cloud AI and GPU resources and ready-made packs. Stacklet hasn't said which of these controls, if any, will also go into the open-source Cloud Custodian project. Teams that already run Custodian themselves shouldn't assume they'll get them.
The existing platform also shapes how remediation happens in practice. Stacklet's earlier materials describe multi-step remediation workflows that connect to Slack, Jira and ServiceNow, plus exception handling so certain resources can be exempted from a policy without switching the policy off. Those features matter most for the more drastic actions in the new benchmark. A training job that looks stalled might be doing a long checkpoint. An endpoint that looks idle might be a disaster-recovery standby. An exception process is what stops an automated cost policy from causing an outage.
In March 2025, Stacklet also launched Jun0, an AI assistant the company said quickly takes teams from insights to action. The "agentic AI" in the new release probably refers to that line of work. The release doesn't explain what the agentic part does on its own versus what it only suggests.
Stacklet chose the name "Benchmark"; it isn't an industry standard
The word "benchmark" can mislead. It doesn't compare cloud providers' prices, it isn't a certification from AWS, Google or Microsoft, and no independent body oversees it. It is Stacklet's definition of good practice, written as policies that run on Stacklet's platform.
Efficiently Connected, in commentary a month before the launch, noted that the FinOps Foundation has published operational guidance, but quantitative benchmarks for AI cloud governance, specifically what "good" looks like for inference cost efficiency, token attribution, and autonomous remediation coverage, do not yet exist in any standardized form. The analyst was also direct about the business reason: If Stacklet defines the measurement framework for AI FinOps governance maturity, competitors will be evaluated against Stacklet's frame of reference by default.
That doesn't make the controls less useful. Filling an empty space with a practical, opinionated baseline is a reasonable product decision. Buyers should still treat the benchmark's pass/fail results as Stacklet's view. What counts as "idle" or "stalled", and where a token threshold belongs, depends on each workload.
The evidence so far is also limited. The launch has no published savings figures, pricing or independent test results. Avalara's endorsement is about intent: Matillano said the company is "looking forward to trying" the benchmark. That means Avalara hadn't reported an evaluation or any savings when the product launched. Stacklet's company boilerplate claims customers have seen cost reductions of up to 50%. That is a marketing figure for the whole platform, not a result for this benchmark.
What this means for Azure and multi-cloud FinOps teams
The benchmark is worth a look if you already use Stacklet, or if your AI spending is spread across Azure AI and at least one other cloud and nobody has a single list of which inference endpoints, training jobs and model deployments are running. If your AI spending sits mostly in one cloud and you haven't yet identified where the waste is, finding that out comes before buying a new tool.
For teams that do evaluate it, the key decision is how fast to let automated fixes run. Retiring endpoints, pausing jobs and blocking models all affect service availability, and the release doesn't say what approval steps exist. It makes sense to run the benchmark in report-only or notification mode first, match its findings to the owners of each workload, and only then turn on automatic fixes for the categories where a false positive costs little. This rollout order is our recommendation based on the actions Stacklet lists. The company hasn't published one.
- Stacklet's Cloud AI FinOps Benchmark was announced September 10, 2026. It is available now and covers GPUs, foundation models, custom models, storage and token thresholds on Microsoft Azure, AWS and Google Cloud.
- The only Microsoft service Stacklet names is "Azure AI", so ask for the specific list of Azure resource types and check they match the Bedrock and SageMaker coverage before you commit.
- Pre-deployment checks are confirmed for Terraform. Teams that build Azure resources with Bicep or ARM templates should confirm those formats are supported.
- Start with alerts and set up exceptions before you let the benchmark retire endpoints, pause training jobs or block models in production.
- Treat the benchmark's pass/fail results as Stacklet's definition of good practice, since there is no neutral AI FinOps standard to compare them with.
- Ask for pricing and a trial on your own environment, because the launch has no published savings figures and the one named customer hadn't yet reported results.
The Cloud AI FinOps Benchmark is a practical attempt to move AI cost control from dashboards to enforcement, and the Azure coverage makes it relevant to Microsoft-heavy organizations with more than one cloud. Its value depends on how deep the per-service coverage goes and how safely its automated fixes behave on real workloads. That evidence will come from early customers like Avalara once they report what the controls caught and what they saved.