Editor's Note
FinOps & Beyond, brought to you by CloudXray AI, is a weekly newsletter for practitioners tracking the forces shaping cloud, cost, and AI — and what those shifts mean for operating models, accountability, and spend decisions.
For sponsorship opportunities, click here to schedule time to talk with the team.
Table of Contents
General Tech Trends Analysis
The Vendor Selection Problem No One Talks About
I spent one day last week at RSA in San Francisco.
For those outside the security world, RSA is one of the largest cybersecurity conferences in the world. Thousands of attendees, hundreds of vendors, booths the size of small apartments. The scale of marketing investment on display is its own data point and worth its own analysis. That’s for another day.
I wasn’t there as a security practitioner. I was there to network, talk to people, observe patterns, and understand how a mature but crowded technology market operates.
What I saw was mind-boggling yet instructive.
Not because of the technology. Because of how buyers actually choose.
How People Actually Choose
While walking the floor, I started asking attendees I met a simple question (or some variation of this):
“How did you end up evaluating this vendor?”
Most people initially shrugged. A surprisingly honest answer.
Those who responded with more information gave some version of the following, often in combination:
A colleague, friend, or advisor recommended it. Someone they trust said the name out loud and it stuck. Sometimes there is a prior relationship with the vendor. The line between trusted recommendation and interested party is not always visible.
They searched Google. The results reflect SEO investment, paid placement, and domain authority, not necessarily solution quality.
They asked an AI. ChatGPT, Claude, Perplexity. The responses feel authoritative, but they are trained on the same internet that rewards SEO. The vendors with the strongest presence tend to surface first.
They found it on X or Reddit. Community signal has value, but it is also shaped. Employees participate. Advocates are cultivated. Organic and orchestrated can look the same, despite the efforts of some.
They had access to the major analyst firms — Gartner, Forrester, IDC — or reviewed G2. These feel like independent signal. They aren't. The big name analysts rankings require vendor participation and investment (aka, “Pay for Play”). G2 reviews are actively solicited and incentivized by the vendors. The independence is cosmetic.
And the most honest answer of all:
They had the coolest looking booth.
The honesty was great and none of these methods are irrational on their own. People use what is available. But together, they describe a discovery process where the shortlist is shaped by marketing investment, network proximity, and algorithm behavior before a single demo is scheduled.
The Funnel Problem
Here’s the part that often gets missed: most buyers do run a rigorous process once they have a shortlist. They demo the product. They trial it with real data. They talk to references. That part of the process is legitimate and valuable.
The problem is upstream.
If the discovery process is broken, you end up running the right process on the wrong set of vendors. You might select the best option from the pool you assembled and never know what you missed. The evaluation was sound. The inputs were not.
And when the tool you selected does not fully deliver six or twelve months later, you face a choice: live with it or go back to square one. Which means running the same discovery process again, with the same structural limitations, on a timeline that is no longer comfortable.
That is the real cost. Not a single bad decision. A cycle. Time-consuming, resource-intensive, and avoidable with better inputs at the top of the funnel.
The Stakes Are Rising
FinOps teams are being asked to own more than they used to.
The State of FinOps 2026 is unambiguous on this point. AI spend, SaaS, software licensing, private cloud, and data center costs are now standard parts of the practitioner remit. Not future ambitions, current expectations. Ninety percent of respondents now manage or plan to manage SaaS. Sixty-four percent manage licensing. Ninety-eight percent are managing AI spend. Two years ago, that last number was thirty-one percent.
Each of those categories brings its own vendor ecosystem. Its own pricing complexity. Its own set of tools claiming to solve it.
Some teams will try to stitch that together with point solutions. One tool for cloud, another for SaaS, another for AI spend. Others will look for a platform that covers the full scope. Both are legitimate approaches. But either way, the decision requires knowing what actually exists in the market, not just what has invested most heavily in being found.
That is where the shortlist problem compounds. A team evaluating a cloud cost tool in 2021 was working with a bounded problem. A team evaluating a full technology spend platform in 2026 is working with a much larger, faster-moving, and more fragmented landscape. The vendors who show up in a Google search or an analyst report represent a subset of what is available, and not necessarily the most capable subset. They are the ones who have invested in being visible.
Getting the shortlist wrong at this scope does not just mean a suboptimal contract. It means managing AI spend, SaaS sprawl, and license complexity with a platform that was not built to handle it, while still being held accountable for the outcomes at the CTO or CIO level. The State of FinOps 2026 shows 78% of FinOps teams now report into that organization. The visibility those executives expect is only as good as the tools producing it.
The Same Problem, Every Market
What stood out at RSA was not the technology. It was the pattern.
Security has thousands of vendors. FinOps has hundreds. Observability, data infrastructure, AI tooling. Different categories, same dynamic. Buyers believe they are discovering the market. In reality, they are being shown a curated version of it, shaped by marketing investment, network proximity, and algorithmic visibility before evaluation even begins.
In FinOps, I see this play out constantly. Teams run structured, thoughtful processes. They compare features, test with real data, talk to references. And still end up in a suboptimal place, not because they made a bad decision, but because the right vendors never made it into the room.
That is the real failure mode. The selection process looks rigorous. It feels objective. But the inputs were biased from the start. This is Visibility Theater applied to vendor selection.
And the problem is getting worse. As FinOps scope expands, more categories, more vendors, more noise, the gap between what is marketed and what is available widens. Teams that rely on the same discovery channels everyone else uses will keep assembling the same shortlists everyone else assembles.
Which means the most important decision is no longer how you evaluate. It is who you evaluate.
FinOps Signal
Structural Trend Quick Takeaway
The Cost Floor Is Moving
Most FinOps conversations stay inside the cloud bill. What is happening right now sits upstream of the bill, and it matters for how practitioners should think about both vendor selection and unit economics planning for the rest of 2026.
Three converging pressures are worth tracking.
Memory markets have broken from their historical pattern. This is no longer a cyclical shortage. IDC describes the current situation as a potentially permanent, strategic reallocation of global silicon wafer capacity. Every wafer allocated to ahigh-bandwith memory stack for an Nvidia GPU is a wafer not available for consumer devices or standard server modules. (IDC). Samsung and SK Hynix are reportedly planning to raise server memory prices by up to 70% in Q1 2026 alone. Combined with increases of roughly 50% across 2025, this could nearly double prices by mid-year. The broader expectation is that hyperscalers will pass these costs through to enterprise customers, with cloud pricing adjustments following. (The Register, Bisi) New fab capacity, including Micron’s Idaho plant, is not expected to contribute meaningfully until 2027 at the earliest. (IEEE Spectrum)
Energy costs add a second layer. The IEA’s March 2026 report highlights rising and volatile energy costs, driven by geopolitical disruptions. That volatility is now feeding directly into infrastructure and cloud cost pressures. (IEA) Cloud providers are facing higher infrastructure costs driven by electricity and depreciation. With capital expenditure continuing to rise to support AI workloads, even modest sustained increases in energy prices could materially affect cloud service margins. (Intellectia.AI) Markets are now signaling renewed inflation pressure, which could tighten technology budgets heading into 2026.
Forrester is seeing the same pattern. Costs are rising across the technology stack while budgets are starting to tighten. On paper, total tech spend is still growing. In practice, that growth is being offset by higher costs, which means less real buying power for teams. (Forrester)
Why this matters for practitioners. Unit economics, cost per inference, cost per transaction, cost per customer, were already a top priority in the 2026 State of FinOps report. That urgency just increased. Teams being asked to self-fund AI initiatives through efficiency gains elsewhere are doing that math against a cost floor that is actively rising. The margin for imprecision is shrinking.
Plan accordingly.
Signal: The cost floor is rising faster than most teams are adjusting their economics.
FinOps Industry
News or Market Updates
When Doing Everything Right Isn’t Enough
(Reference Article - Bass and Bytes)
The macro pressures above are structural and slow-moving. What happened to one AWS Community Builder in February is the fast-moving version of the same problem, and it is worth reading carefully.
The builder was testing autonomous agents on Amazon Bedrock. He was monitoring costs daily. He had budget alarms set. He was, by any reasonable measure, a responsible cloud citizen.
On February 23rd, his billing dashboard showed $140 for the month. Then two budget notifications arrived. Not for $100. Not for $500. But for $56,265.59. A forecast alarm followed for $70,161.62.
The root cause? Switching from native Bedrock APIs to the Project Mantle endpoint, Amazon Bedrock’s OpenAI-compatible distributed inference layer announced at re:Invent 2025, triggered a 1000x token accounting error. Same agent, similar prompts, same usage pattern. Just a different API layer. The incident was resolved. AWS corrected the billing. But the story is instructive beyond the resolution.
This is what complexity looks like at the practitioner level in 2026. A new API layer, designed to make migration easier, introduced a billing behavior that no amount of standard monitoring would have caught before the damage was done. Budget alarms fired after the fact. The billing dashboard showed accurate numbers in the wrong place. The error lived in the gap between how the cost was generated and where it was reported.
This is not a failure of discipline. It is a system failure, the kind that becomes more common as services multiply, API surfaces expand, and agentic workloads introduce consumption patterns that do not map cleanly to prior billing models.
Two things are worth noting for the broader FinOps audience.
First, AWS has since released the Projects API for Mantle, a capability designed to provide application-level cost isolation and tagging for workloads using OpenAI-compatible endpoints. It is a direct response to the attribution gap this incident exposed. (AWS announcement)
Second, a separate security researcher identified an SCP enforcement bypass on the same Mantle endpoint between December 2025 and January 2026, now patched. This suggests the service is still maturing in production environments.
The broader point: as AI inference becomes a standard part of cloud spend, the tooling and governance layer needs to keep pace with the API surface. Right now, it is not.
FinOps Company Spotlight
If you would like your company included in the Spotlight, contact the CloudXray AI Team
Category: Managed Services & Consulting
What They Do: FinOps Consulting & Advisory Services; Owners & maintainers of the single largest FinOps company directory (finops.cloudxray.ai)
Why It Matters: Companies still need guidance on implementing FinOps and understanding the landscape of companies that exist
Operator Playbook
Operator Playbook: Build Your Alert Architecture Before You Need It
Most teams set up billing alerts once and forget them. They configure a budget threshold at the account level, add a forecast alarm, and consider it done. That setup will catch a known workload running over budget. It will not catch much else.
The three alert types serve different purposes, and most environments need all three working together, independent of the tooling and solutions that you may use.
Threshold alerts tell you when spend has crossed a number you have defined. They are reactive by design. The spend has already happened by the time they fire. Set them low enough to give you response time, not just notification that the damage is done. One alert at 50% of expected spend, one at 80%, and one at 100% is more useful than a single alarm at the limit.
Forecast alerts tell you where you are heading based on current trajectory. They are only as good as the baseline they are built on. For established workloads with stable patterns, they are valuable. For new services, new API surfaces, or experimental workloads, they are effectively blind. There is no history to forecast from. Treat any new service as unmonitored until you have enough billing history for the forecast to mean something. Until then, set an alert manually before relying on historical patterns.
Anomaly detection tells you when something is behaving differently from its own historical pattern. It is the most useful of the three for catching unexpected behavior mid-cycle, but it requires a pattern to exist before it can detect deviation. Similar to Forecast alerts, set an alarm manually based on experience or type of workload. Don’t be caught.
Treat these alerts like you would an incident. Notify the on-call, troubleshoot, and build run books to help triage and resolve.
Finally, alert architecture reflects the environment you built it for. Every time that environment changes, new service, new team, new workload type, new API surface, your alerts need to be revisited at the point of change, not at the next quarterly review.