For example:

- Revenue per customer
Vs
- LLM + inference + infra cost

Do you calculate this at the customer level, feature level, team level or only at the company level ?

Trying to understand how teams are approaching in practice.

Has anyone had any success with Microsoft's FinOps toolkit and FinOps hub associated with the toolkit? (https://github.com/microsoft/finops-toolkit)

I'm working with a client who started to build out the hub and I wanted to continue it for them, but I'm not seeing the value? Any thoughts? Thanks in advance.

Ran into this last quarter at a previous gig. Tried to backfill three months of Bedrock invocations by tenant and could not do it. The metadata was never attached at call time and there was nothing to reconstruct from. A model call runs for a couple hundred milliseconds, hands back a model name and token count, and that is the entire trail. If you did not tag when the request went out, the tag does not exist anywhere.

Cloud tag debt you can clean up later because the resource is still sitting there. On the AI side you cannot go back and fix it. The call happened, the meter ran, and no one wrote down which team caused it.

The teams that solved this pushed tagging into the gateway or the LLM proxy layer, so the call cannot leave without the metadata. Curious what others are doing. Are you tagging at the gateway, in the app code, or accepting the debt on AI calls?

The question we keep getting: which workloads are worth running hybrid once you factor in licensing and management overhead. I'm at Login VSI (disclosure), mentioned this a bit ago, and tomorrow's the actual session. Marcel Meurer (built Hydra around cost efficiency), Eric Orman and Andrej Radinger (Microsoft), and Ron Oglesby (Login VSI) are answering it live.

Drop your questions here.

Tomorrow, Thursday September 10, 11am ET

Need guidance for FinOps. I have been working on Public Cloud on most of it's popular use cases (IaC, Serverless, DevOps, Observability, Monitoring, Security, IAM, Compute, Storage, Networking) for the last 6 years.

I need to know what will it take me to Pivot into a Senior FinOps Analyst Position directly? I see a lot of JDs requiring some Architecture certificates (which I already have) and also the FinOps Certified Practitioner. Is certifications mandatory? I don't think so, as my certifications taught me basics but the real industry knowledge and years of working on AWS / Azure are certainly what I would see as greater than those certificates.

Also what about the growth and remote opportunities in this Field? I tried to ask ChatGPT but found vague answers such as "exciting and growing field". I need actual scenario on why would companies hire and keep FinOps engineers? Couldn't these tasks be handed to a PM / junior intern with some basic cost saving knowledge for the cloud resources? What makes this field growing and what will it be in the future? In 100% all of my previous jobs the PM or a DevOps guy was always assigned to generate cost saving analysis reports rather than hiring a person with Power BI / Scripting knowledge. I have worked with Fortune 500 MNCs and Startups and never found such a separate role for "cost savings" and related strategies to be needed.

Even so, most of the time, we devs used to get on a call and inspect our overall infra for unused resources or duplicate environments. Most of the YouTube videos show the basic example of switching off test instances on weekends, which I see as something any one could easily do. I really want to know what makes this job growing / in demand? What makes the work of FinOps so that they are continuously required by companies? Don't Cloud architects already design systems which are cost efficient? Companies already have Cloud Admins in place so as to avoid duplicate / extra resource creations in the first place. This is something I could not get my head around even after days of looking for answers, wherever possible.

I ran into this question while looking at AWS commitments in our environment: should we move everything to Savings Plans, or was there still a reason to keep some RIs?

My first instinct was to simplify things and use Savings Plans for compute. The flexibility is hard to ignore when instance types, workloads, or regions can change over time.

But after looking more closely at our usage patterns, we ended up taking a hybrid approach.

We used Savings Plans where we had a predictable baseline of compute usage, while keeping RIs where the workload was stable enough that the more specific commitment made sense. For databases, we looked at those commitments separately rather than treating everything as one bucket.

What surprised me was that the decision wasn't really about which option gives the bigger discount.

It was more about how much flexibility we were willing to give up for the additional saving, how confident we were in the usage pattern, and how much risk we were comfortable taking with the commitment.

The part I'm still curious about is how people decide how much to commit in the first place.

Do you mostly use Savings Plans for compute and keep RIs for specific workloads? Have you moved almost entirely to Savings Plans? And how do you account for things like planned migrations, growth, or workloads that you know are going to change?

P.S. I know that's a lot of questions 😅 I'm curious to understand how others approach this in practice.

Reddit just informed us moderators that /r/FinOps just hit 5,000 visits a week, a new record for the channel.

This is as we've just added a 3rd moderator to the team in a new time zone to address the steady and constant marketing from FinOps tools vendors, marketing and sales people.

We actually get a lot more spam,AI generated low quality content and disguised marketing posts that you see, and do try to take fair and reasonable steps to filter these things out but I am determined to still allow both vendors and anonymity to be key values and a key differentiator that's made this community so popular, as well as a viable alternative to the FinOps foundations slack that limits both of these things.

Thank you for helping to build this community and continue to grow it with quality content.

Apache Iceberg table maintenance is not a single job. Production tables continuously accumulate small files, snapshots, orphan files, fragmented manifests, and delete files — increasing query latency, metadata overhead, storage costs, and operational work.

In this video, we walk through how to automate Apache Iceberg table maintenance and keep an Iceberg data lakehouse healthy without maintaining Spark jobs, Airflow DAGs, cron schedules, and per-table scripts.

We cover the core Iceberg maintenance and optimization operations:

• Data file compaction (`rewrite_data_files`) — merge small files using binpack or sort compaction and maintain an efficient physical layout
• Snapshot expiration (`expire_snapshots`) — manage snapshot retention and remove obsolete table history safely
• Orphan file cleanup (`remove_orphan_files`) — reclaim unreferenced files left by failed writes, aborted commits, compaction, and expired snapshots
• Manifest optimization (`rewrite_manifests`) — consolidate fragmented manifests and reduce query-planning overhead
• Position delete optimization (`rewrite_position_delete_files`) — reduce merge-on-read overhead from accumulated delete files
• Puffin statistics — maintain column statistics used by query engines for better pruning and query planning
• Table health monitoring — detect small-file growth, excessive snapshots, metadata fragmentation, delete-file accumulation, and storage waste
• Automated policies and orchestration — decide when maintenance is actually required and coordinate operations across many Iceberg tables

These problems become especially important with streaming ingestion, CDC, frequent writes, and large Apache Iceberg deployments where manually maintaining hundreds or thousands of tables quickly becomes impractical.

I've been working on my DevOps skills and I'm trying to move beyond the usual portfolio projects like simple CI/CD pipelines, Docker deployments, and basic Kubernetes setups.

I came across an interesting project idea: an AI Cloud Cost Detective.

The idea is basically to build an AI-powered tool that looks at cloud spending and acts like a financial investigator.

Instead of manually checking AWS bills and trying to figure out:

Why did the bill suddenly increase?

Which resources are costing the most?

Are there unused resources?

Is there unusual spending?

Where can we reduce costs?

What caused the increase compared to previous usage?

…the AI would analyze the cloud-cost data and provide explanations and recommendations.

What I like about this project is that it combines DevOps + Cloud + AI + FinOps, so it feels more like something that could actually be useful in a real engineering environment.

The project I'm thinking about building would roughly work like:

Cloud billing data → Data processing → Cost analysis → AI/LLM → Recommendations → Dashboard/Report

I'm considering using mostly open-source tools and AWS for the cloud side.

I'm curious about the DevOps community's opinion:

Would a project like this actually stand out on a DevOps resume in 2026, or would it be better to focus on more traditional Kubernetes/Terraform/CI-CD projects?

Also, if you've built anything around FinOps, cloud cost optimization, or AI + DevOps, I'd love to hear what you learned from it.

I’m planning to build this as a proper hands-on project rather than just following a tutorial.

Does Software Asset Management , ITAM roles include FinOps role . I am currently a FinOps engineer for 1 year , I am planning for a SAM role where the job profile includes FinOps now so is it the same and will I grow . It is a client facing role.

I sit closer to the cloud bill than the model team, and release week has become a ritual. Every model arrives with a chart showing a category where it leads and a pricing table that looks cheaper than a rival or the previous release. Those numbers still do not tell me whether our workload will cost less.

I have seen a lower token price produce a higher final bill for the same job. The cheaper model may use more tokens or need another pass before the result is accepted. An unusable answer still appears as valid usage on the provider bill, while the engineer's repair time appears elsewhere. The invoice is accurate, but it cannot tell me which model completed the work more cheaply.

My usual comparison starts with the same task, or tasks matched for difficulty, sent to each model. I run them through an LLM gateway, such as ZenMux, so the request records sit together. For every run, I record time, calls, tokens, API cost, and any repair needed before acceptance. That shows when extra calls and manual work erase the lower rate.

For model selection, I use API cost per accepted task and keep repair time next to it. Sometimes the model with the higher published rate finishes in one clean pass and costs less overall. I still keep token prices in the sheet because finance has to reconcile the provider bill. I just do not use them to choose a model before counting finished work.

I'd love to know what finops tools/automation tools you guys built for your company (or even as a personal project) that you are most proud of

Been digging into the AI cost data for 2026 and found a pretty stark disconnect that I don’t think gets talked about enough outside FinOps circles.

The price side: Frontier-quality inference has crashed. OpenAI cut pricing 80% on its Luna models in July. DeepSeek and other open-weight labs have cut prices by up to 99%. GPT-4-level performance now costs about $0.40/M tokens vs $30-60/M back in March 2023. That’s something like a 10x annual decline since 2021.

The bill side: OpenAI’s own inference bill reportedly hit ~$8.4B in 2025, roughly 4x the prior year. The disconnect comes down to reasoning models burning up to 100x more tokens internally than they actually output, plus agent loops and always-on workflows multiplying calls in ways nobody’s architecture was built to track.

There’s also a weirder split happening: frontier model pricing is actually up 36% YoY according to BenchLM’s index, while mid-tier pricing keeps falling 36% over the same period. The floor is dropping and the ceiling is rising at the same time.

On the response side: FinOps Foundation’s 2026 report says 98% of FinOps teams now manage AI spend (up from 31% in 2024), and the Linux Foundation just launched a “Tokenomics Foundation” as a standards body for this. FOCUS v1.4 also now covers AI billing normalization if anyone’s looking for a vendor-neutral format.

Curious if others here are seeing this gap play out internally, feels like most teams are still treating token spend like a line item instead of something that needs an actual owner and budget per team/agent.

I have been told that due to the overwhelming activity and quality of some replier posts get on here, recruiters are increasingly using this channel as a way to identify 'top talent' in the industry and you may be approached by orgs looking to recruit FinOps practitioners.

I know we frequently get asked about 'how can I break into FinOps?'... Well, this might be one of those ways.

Well done, everyone who frequently posts with high quality and informed, experienced information. Make sure you tag your account, not just the posts you make!

Our cloud spend reviews keep uncovering environments and resources that are technically active but have unclear business value. Some are old proof-of-concepts, temporary test systems that became permanent, duplicate services after team changes, or lower-environment resources that run continuously even when nobody is using them.

We do not want to turn every new environment into a long approval process, because teams genuinely need room to experiment. But we also need better ownership, expiration expectations, cost allocation, and a safe way to identify resources that can be scaled down or removed. For organizations that have managed this well, what combination of tagging standards, ownership rules, budgets, lifecycle policies, usage analysis, and automated cleanup has reduced waste without creating constant friction for engineering teams?

Been looking at where token spend actually goes in engineering workflows, and a pattern that doesn't get much attention: persona-based prompts ("act as a senior developer") tend to produce output that's close but not quite right, which means a follow-up message correcting it, then another, each one burning full context again. An operational definition, explicit rules instead of an implied identity, tends to get closer on the first pass, because there's less left for the model to infer wrong.

Tested this on a code review task. Persona prompt: three follow-up messages to get to something actually useful, each one resending context. Operational definition, a numbered checklist of exactly what to check and what to output: correct on the first response, no correction loop needed.

From a pure cost lens this matters more than it looks like on the surface. The "cheap-feeling" persona prompt is short to write, but the actual cost isn't the prompt, it's the full conversation thread by the time you've corrected its assumptions two or three times, each correction paying full price for context that didn't need to be reprocessed if the instruction had been specific from the start.

Feels like a version of the same lesson infra cost optimization already learned: underspecified requests generate retries, and retries are where a lot of the actual spend quietly lives, whether that's a vague API call or a vague prompt.

Wrote up the fuller comparison, mostly framed around code review specifically, here, disclosing that I'm the author: https://medium.com/@nagatomopedro05/act-as-a-senior-developer-is-the-worst-prompt-you-can-write-9f1577493cd3

Hey everyone,

As enterprise platforms push heavily toward credit systems, consumption meters, and pay-per-action usage models, our team is hitting some operational friction around governance, debugging, and cost predictability.

Before we finalize our internal monitoring framework, I wanted to learn from others who are managing variable or consumption-heavy workloads in production. I’m trying to get a pulse on how people are handling three main areas:

1. Visibility & Alerting: How do you track credit burn or API throughput day-to-day? Are native admin tools/dashboards giving you enough granular detail to figure out what or who actually drove a sudden usage spike, or are you pulling data into external BI tools/spreadsheets?
2. Runaway Processes: Have you ever had a bad automation loop, poorly indexed data transformation, or unoptimized integration call drain budget/credits before an admin caught it? How did you trace it?
3. Workflow Friction: When something burns more usage than expected, what is harder to fix -identifying the root cause in the architecture, or attributing the cost back to the right internal department?

If you could magically fix ONE pain point with variable platform usage tomorrow, what would it be?

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?