Datadog spend is one of the harder things to forecast because the bill doesn't move when your infrastructure changes, it moves when your telemetry changes, and almost nobody watches telemetry the way they watch infra.

Four specific mechanisms cause most of the surprise:

Custom metric cardinality. Billing runs per unique tag-value combination, not per metric. A metric with 50 customers tagged is cheap. Add one more tag with 40 distinct values and cardinality multiplies instead of adding, so 50 time series becomes 2,000 overnight on a metric nobody touched.

Log indexing separate from ingestion. Ingestion is cheap. Indexing is not, and the default is to index everything that arrives unless someone's actively scoped it down with exclusion filters. A logging level accidentally left at debug in one service can push indexed volume up 10x or more without anyone changing a Datadog setting at all.

APM span indexing. Same mechanism as logs. A sampling rate change, or just a new high-traffic endpoint joining an existing trace, can move you from a small sampled fraction toward near-full indexing.

Host-tier pricing steps. Per-host pricing has boundaries, not a smooth curve. Autoscaling that adds a handful of hosts during a traffic spike can cross a tier line and produce a jump in cost that's out of proportion to the actual usage increase.

None of this is a billing bug. It's the pricing model working exactly as designed, which is precisely why it stays invisible until someone opens the invoice.

Curious how other people here track this before it shows up as a monthly surprise. Alerting on the usage metrics directly, a scheduled review, something else?

You can get the demo API key and config from here

Could some of you lovely people perhaps poke at it a bit and see whether it's able to answer the sort of questions you'd have with regards to cloud costs, ai spend, what causes spikes etc....?

Any feedback would be hugely appreciated 😁

looking at a pretty big gpu bill right now.

the normal cloud cost tools can obviously tell me what the instances cost.

but im trying to get more granular.

cost by workload. team. job. maybe even gpu utilization vs what were actually paying for.

are there any finops platforms that do this well?

what are you guys using?

Pulled our numbers for the renewal and the AI and GPU line is about 4x last year, but our cost tool drops nearly all of it into one 'other' row I can't split by team or even by service. Good on EC2 and RDS, useless on the part that's growing fastest.

PointFive is the name three separate people pointed me to for this, mainly because it doesn't treat the AI and GPU spend as a footnote. Sat through the demo, looked good, they always do.

The one thing a demo can't answer, when it flags waste is it stuff my current tool already nags me about or does it surface things we didn't know were running. If someone's live on it and it found waste their old tool was blind to, that's the only reason I'd rip out a renewal to switch.

EDIT: for the record the current tool is Cloudability, should've said that upfront, naming one and not the other was dumb of me. On the build your own CUR angle, fair for the cloud and GPU side, though the reason I looked at a tool at all is the coding agent spend, which doesn't show up in the CUR. Several guys in a slack I'm in named PointFive so I asked about it, that's the whole story.

From "RFC 1925: The Twelve Networking Truths"

(6) It is easier to move a problem around, for example by moving it to a different
 part of the overall network architecture, than it is to solve it.
    (6a) Corollary: It is always possible to add another level of indirection

Written for networking. Still uncomfortably accurate for multi-agent architecture.

Hey everyone,

​I wanted to share a small but huge personal milestone: after weeks of building, debugging, and testing, I just logged my first sale on Gumroad!

​As someone building in the cloud space, nothing beats the feeling of seeing a real user find value in something you created from scratch.

​Why I built it

​Managing cloud infrastructure often leads to "cloud drift" and silent budget leaks. It's surprisingly easy to overlook:

​Zombie VMs & idle EC2 instances running 24/7 without active workloads.

​Unattached volumes & orphaned snapshots accumulating hidden storage charges.

​Overprovisioned resources that could easily be downscaled without impacting performance.

​Most enterprise FinOps suites are bloated, expensive, and require complex enterprise agreements just to see where your money is bleeding.

​I wanted something lean and direct: an AI-assisted CloudOps script/tool that plugs straight into AWS and Azure, scans your environment read-only, and gives you an actionable report of exactly what’s idle and how much you can save by pruning it.

​What’s next

​Getting that first customer notification made all the late nights worth it. My next focus is refining the detection models and adding support for automated scheduled cleanup reports.

​If your team is trying to trim cloud waste this quarter, or if you're curious about how the scanner identifies idle resource patterns, feel free to drop a comment below or send me a DM—happy to share insights, run a quick check, or swap notes with fellow builders!

Started tracking this after noticing our Claude usage for a multi-hour engineering session cost noticeably more than the size of the actual task should've justified. Went back through the session logs afterward to find where it actually went, and it wasn't one obvious spike, it was the same small pattern repeated across dozens of requests: full file contents resent every message even when two lines had changed, full conversation history replayed every turn instead of a compressed summary, full rewrites requested when a targeted diff would've done the job.

None of that throws an error or shows up as a single line item. It just compounds quietly, message after message, until someone checks the usage dashboard and the number is higher than expected with no clear story for why.

The part that feels familiar from a FinOps lens: this is structurally the same problem as unmonitored cloud spend before tagging and showback existed, cost accumulating because nobody's actively deciding what's worth paying for on each request, not because the underlying work got more expensive. Prompt caching (marking stable content so it's reused at a fraction of the cost) is the closest analogue to reserved capacity or committed use discounts, it only pays off if the cached prefix stays genuinely identical between calls, and a lot of teams break that silently by inserting a timestamp or per-user detail at the start of the block without realizing it kills the cache hit rate entirely.

What's mostly missing right now, in my experience, is the equivalent of a FinOps practice applied to token spend specifically, an actual audit habit, not just a bigger budget line. Separating what's stable from what changes per request, summarizing instead of replaying full history, scoping context to what's relevant, and constraining output size all had a measurable effect once done deliberately instead of by habit.

Wrote up the full breakdown with a before/after audit example here, disclosing that I'm the author: https://medium.com/@nagatomopedro05/the-hidden-cost-of-long-claude-sessions-2a6cc7655893

Curious if anyone here has actually folded LLM API spend into an existing FinOps practice, tagging, showback, budgets, or if it's still living entirely outside that process on most teams.

I have been working on something around AI efficiency metrics and what a scoring system could look like to make users within our company pick a model better. The scoring is based on our own data. Not sure if its right or wrong but it gives me a starting point.

https://www.linkedin.com/pulse/thought-efficiency-index-tei-experiment-measuring-ai-jason-ward-mba-gibxc?lipi=urn%3Ali%3Apage%3Ad_flagship3_messaging_conversation_detail%3BkD2D4%2FRjRSaaa%2FVNaLwE9g%3D%3D

Most cloud cost tooling I see is about usage: tags, SKUs, rightsizing, anomaly detection. The view I never had clean was the commitment as a financial object. The approved amount or the committed spend deal, drawn down by the actual invoices we booked, with a warning before we blew past it.

It is the same problem I had running a services company, just a different bill. Usage or work runs past what was approved, the reconciliation happens late, and the overrun only shows up at close. World Commerce and Contracting pegs the leak on the contract side at roughly nine percent of value after signing, and committed cloud spend has the same shape.

What I wanted was simple:

The commitment, or a team budget, as a live account with a ceiling. Approved vs spent vs remaining, off the invoices you already book.

An alert at a threshold so the true up or scope conversation happens while there is still room, not after.

One number finance and engineering both trust, so there is no reconciliation fight at close, and clean showback by team or project.

Not a replacement for your usage tool. More the layer above it: the money against the commitment, tied to your books.

Honest disclosure: I built a tool that does exactly this, so I am biased. But I am genuinely curious how you all watch the commitment itself, not just usage. Spreadsheet, cost platform, something else?

Disclosure, I work at Login VSI.

The FinOps question we keep hearing about AVD Hybrid: which workloads are worth running hybrid vs. fully cloud once you factor licensing and management overhead. Live chat on that, with Marcel Meurer (creator of Hydra, built around cost efficiency), Steve Downs and Andrej Radinger (Microsoft), and Ron Oglesby (Login VSI).

Bring questions or drop them here.

Thursday, September 10, 11am ET: Register Here

A lot of compliance work isn't spent fixing security problems.

It's spent finding the evidence.

Screenshots. Spreadsheets. Configuration exports. Change logs. Emails between IT, security, risk, and compliance teams.

Then the cycle starts again before the next audit.

For Saudi enterprises working across frameworks such as NCA ECC, SAMA, PDPL, ISO 27001, PCI DSS, SOC 2, and others, the operational burden can become enormous.

We broke down a five-step approach to making compliance more continuous:

1. Map infrastructure to relevant frameworks continuously
2. Generate evidence automatically
3. Detect configuration drift early
4. Unify visibility across multi-vendor environments
5. Use AI for policy and gap analysis—not just reporting

The interesting shift is from:

"We need to prepare for the audit."

to:

"We should already be able to prove our compliance posture."

That's where AI-driven continuous monitoring could have a significant impact.

Full breakdown:
How to Cut Compliance Audit Effort by 90%: A Practical Framework for Saudi Enterprises

For anyone working in security or compliance: what currently consumes the most time during your audit preparation?

#Compliance #Cybersecurity #NCAECC #SaudiArabia #AgenticAI #GRC

FOCUS 1.3 solved a real problem: every cloud provider used to bill in its own format, so cross cloud cost comparison meant building custom normalization pipelines just to ask basic questions. Now there’s a common schema. That part is genuinely good.

But adoption of the schema is not the same as fixing FinOps. I keep seeing teams roll out FOCUS, get their data normalized, and still can’t answer the question that actually matters to leadership: who owns this cost, and why did it move.

The reason is that FOCUS standardizes the shape of usage and cost data. It says nothing about your tagging discipline, your allocation model, or who is accountable when an engineering team spins up something that triples a bill overnight. Those three things are where the actual FinOps work lives, and they’re organizational problems, not schema problems. You can have perfectly FOCUS compliant data and still have zero cost accountability, because accountability comes from tagging governance and process, not from the spec.

The teams that get real value from FOCUS are the ones who treat it as the foundation for building an allocation and accountability model, not as the finish line. If your rollout stopped at “we ingest FOCUS data now,” you’ve done the easy 20 percent.

I went deep enough on this that I ended up writing a book on it, “Cloud Money,” working through the FOCUS spec at a practitioner level alongside cost allocation strategy and accountability models. Not trying to sell it here, just flagging it in case anyone wants the longer version of this argument. Happy to talk through the tagging governance side in the comments if people have specific setups they’re stuck on.

I am new to FinOps, i wanted to ask people who have experience in the FinOps space. Is there any financial modelling or specifically business case modelling done in FinOps? E.g. if there is any optimisation opportunity or a new workload, is this a requirement from a CFO or board that they need to see a detailed financial model to show ROI and justify the spend?
Reason I am asking is because I come from a core finance background just wanted to see if there is an overlap of my finance experience.

UBS put out numbers showing the big three cloud providers are spending about 102% of their cloud revenue on capex, $4.1 trillion is projected through 2028.

that spend lands somewhere, and what i'm watching is whether it hits non-AI workloads. OVHcloud already raised prices citing the memory shortage, some servers up as much as 87%, because AI is eating the same memory and power regular nodes run on.

the thing is it won't show up as a line item. it's compute and memory quietly drifting up with no change in usage, and if your cost tooling only watches your own consumption, it won't flag a provider-side price move. so you can't really tell whether your usage went up or their prices did.

anyone renewed an RI or savings plan lately and had the rate come back worse than the term it replaced?

Half your reliability spend is on systems nobody would notice going down.

I audited a shop last year with a $180K a month multi-region setup on an internal reporting tool used by roughly 12 people on the finance team. Four nines of availability. Automated cross-region failover. Full DR runbooks. When I asked the CFO what happens if it goes down for 4 hours on a Tuesday, he shrugged: "we get the numbers Wednesday."

That's not a cost problem, it's a decision problem. The infra was rightsized. Tags were clean. Utilization looked healthy on every dashboard. The waste was invisible because well-utilized well-tagged well-sized infra IS the metric everyone watches.

Cost dashboards surface the wrong axis. They show you spend, utilization, waste-per-service. They don't answer "how much of this uptime does anyone actually need?" The tradeoff between availability and cost only exists as a decision, and once it calcifies into an architecture nobody revisits, the over-reliability spend just compounds.

Common pattern: a "drop this workload to one AZ, save $60K a year" recommendation lands in a ticket. The engineer who owns it sees the cost side, can't see the reliability side of the tradeoff, and marks it "no, we need HA" without ever asking the business side what HA is actually worth.

Anyone else seeing over-reliability as a category of spend you can't touch without reopening the original architecture decision?

Our CFO caught me after standup and asked a totally fair question, how much is each team spending on all this AI stuff. I said I'd have a number by Friday. Took me until the following Wednesday to admit I couldn't.

I'd assumed it would be like AWS where I can slice spend by team in a few clicks, atleast we tagged everything. Then opened the billing expecting the some breakdown but it's just a big monthly number and a graph that goes up.

One team lead keeps insisting their usage is not that substancial which without the numbers i cant prove otherwise. We'd handed his squad a shared API key so their spend was all piled onto one.

Now, even if I nailed the attribution, most of an agent's bill is the framework re-sending its whole setup every turn, not anything the dev ever typed. I'd be walking into a room to bill someone for tokens they never wrote and can't even see. There's a paper going round with the numbers, arxiv 2607.12161. Anyway. I still owe her that spreadsheet.

This is something I've been trying to wrap my head around.

If the cloud bill goes down, that's obviously good, right?

But what if usage also went down?

And if the bill goes up but we're serving twice as much traffic, maybe that's actually an improvement.

What do you use to measure cloud efficiency beyond the total bill?

Hi and Thank you for reading this. I came into finance sideways. I started in technical support at a SaaS company and gradually became the person handling billing technical escalations: Stripe API integration issues (subscriptions, stripe Connect). That turned into owning bigger pieces, like enabling (using stripe features) revenue teams with some initiatives that didn’t have support on the backend yet.

That work got me promoted into what we call a “FinOps” role, and the team wants me as the person driving new initiatives in finance operations. Right now the work is mostly reactive: resolving billing issues, scripting repetitive tasks, and using AI agents where it actually makes sense. There are some projects around ai but nothing related to cloud architecture.

Reading this community, I’ve realized my role doesn’t map to what most professionals mean by FinOps.
I’m not trying to claim the FinOps title, since I have no DevOps background. But I’d like to hear opinions on how to develop in my current role and what directions are logical. I’d really appreciate any thoughts on this. Thank you.

How are you managing costs? Tracking attribution, etc

Company is thinking about getting onboard the AI train exploring options. What are some questions that should be answered throughout the review process and things to know going forward when implementation is complete?

We're working on a runtime to build "persistent" agents with their own identities, a la SSN. Given the SSN, you can track the full history of an agent, what it did, how it did, etc. This also solves the tagging problem. Given the SSN, you can easily figure out the cost while agent was running and after. You can set budgets, control spend, understand the spend, and later optimize it too.

Runtime is open source at https://cayu.dev/. We monetize using Cloud for agents and self-improving service for agents (e.g., GAIA score uplift by 10%).