r/FinOps

One thing we've noticed is that most teams know how much they're spending, but not exactly why the bill increased. Digging through services, resources, regions, and usage data takes time, so it often gets pushed aside.

We've been working on a tool to help us answer those questions:

What actually caused the increase?

Which resources are responsible?

Is it expected growth or just waste?

What can be optimized without affecting workloads?

We're looking for a few real-world cloud environments to test it against and get honest feedback.

No catch—we're genuinely trying to validate whether the insights are useful.

If the tool doesn't find meaningful savings, that's useful feedback for us too. If it does, we'd discuss a success-based pricing model instead of charging upfront.

I'm also curious—how do you currently investigate unexpected cloud cost spikes? Is it mostly AWS Cost Explorer, Azure Cost Management, GCP Billing, custom dashboards, or something else?

Would love to hear what's worked (or hasn't) for you.

A Uni student and built a free tool that finds the cheapest AWS EC2 Spot instances with ML price predictions and generates ready-to-apply Terraform configs.

No account setup needed. Would love brutal honest feedback from people who actually use Spot and AWS cloud services here is the link in case the attached one doesn’t work.

cloud-9opt.com

Hi r/FinOps,

A small software company account we manage recently generated approximately USD 62.7k in estimated/pending charges in less than 24 hours, through AWS Marketplace usage for Anthropic Claude models on Amazon Bedrock Edition.

Some relevant context:

• the account historically had low, predictable monthly costs;
• there was no legitimate prior usage of Amazon Bedrock, Anthropic Claude models, or AI Marketplace workloads;
• the abnormal usage appeared across multiple AWS regions within a very short period;
• MFA was enabled;
• AWS later sent a security notification indicating the account may have been accessed by a third party;
• during emergency containment, we found and removed new access keys that were not created or authorized by us, and requested that AWS reconstruct the relevant CloudTrail/IAM timeline;
• we requested a security + billing review before the charges are treated as ordinary account usage.

I’m not asking this subreddit to decide the billing dispute. The broader FinOps question is this:

Detection is not containment.

Budgets, anomaly detection, billing alerts, dashboards, and reports are important. But even if all of them are configured correctly and alert immediately, there may still be a dangerous gap between:

• time to detect;
• time to understand the alert;
• time to reach the right person;
• time to revoke credentials or stop usage;
• time to confirm the spend has actually stopped.

For high-cost AI or Marketplace services, that gap may be enough to generate a major financial impact.

In our case, the disputed amount was generated within only a few hours through massive usage distributed across multiple regions. By the time the abnormal activity became apparent and emergency containment actions were taken, the financial exposure had already become significant.

That made me question whether traditional FinOps controls are sufficient for modern AI workloads and cloud marketplaces.

From a FinOps perspective:

1. What controls actually contain financial blast radius after credential compromise, rather than merely detecting it?
2. Are budgets, anomaly detection, and billing alerts enough for high-cost AI/Marketplace usage, or do they mostly provide visibility after the exposure has already happened?
3. How do you handle multi-region risk when expensive services can be activated or consumed globally?

The main lesson for me is that a compromised credential is not only a security incident. In modern cloud environments, it can become a financial incident within hours.

How are mature FinOps teams designing controls for time-to-impact, not just time-to-detection, especially for AI and Marketplace-based services across cloud providers?

I keep coming back to a number I read this week from a public agent-failure trace study. Failed runs spent roughly 58 percent of their tokens after the first warning signal appeared, meaning an explicit tool error or a repeat tool call with identical arguments. The model already had enough evidence to stop and it kept going. That is not a model quality problem. It is a budget-discipline problem, and I think most FinOps setups today do not have the surface to catch it.

The same reading dropped two other data points I have not been able to shake. Anthropic's Dynamic Workflows can run up to 16 concurrent subagents with 1000 total in a single run. If your kill switch is a monthly bill anomaly rule, that ceiling can produce a very expensive Wednesday afternoon before your Thursday dashboard flags anything. And a suggestion I liked more than I expected: three cost classes as the budgeting unit. High-volume low-value work capped at cents. Standard knowledge work worth roughly $50 of human labor gets a $5 budget. High-value work worth $5,000 gets $500, because starving the agent is more expensive than feeding it. Named owner per agent. Breaker built in.

The reason this bugs me is that the FinOps industry keeps saying "attribution" as if the hard part is knowing who spent the tokens. In practice the harder part is knowing when to trip the breaker mid-run. The trace study says the signal is there. The tooling is not.

So a real question. How is your team handling this today? Are you actually cutting runs off mid-flight when the failure signal fires, or are you catching it in the next day's cost review and eating the burn?

Has anyone here struggled with multi-cloud cost analysis?

I'm a software engineer (not a FinOps specialist) and over the last few months I've been building a personal project around cloud cost analytics.

The idea actually came from conversations with colleagues and friends working with cloud platforms. A recurring complaint was how difficult it can be to get a consistent view of costs when multiple providers, accounts or distributors are involved, or to keep up with API changes.

While researching the problem, I discovered FOCUS and found the idea of a common cost and usage model extremely compelling.

I'm curious about real-world experiences.

For those managing costs across AWS, Azure and other providers:

• Do you rely mostly on native tools?
• Do you export everything into Power BI, Excel or internal dashboards?
• How do you handle cost attribution when tags are inconsistent or missing?
• Is multi-cloud cost analysis really painful in practice?

I'm trying to understand which problems practitioners actually consider worth solving.

Interested to hear how others are dealing with it.

Curious how other FinOps folks are handling AI cost reporting right now. Traditional cloud cost allocation (tagging, showback, chargeback) is well-established, but LLM API spend seems to break a lot of the usual patterns:

• Costs are per-call rather than per-resource, so traditional tagging strategies don't map cleanly
• A single feature can have wildly variable cost depending on prompt length, retries, or agentic loops — same feature, same day, could cost 10x depending on usage patterns
• Finance wants "cost per outcome" or "cost per customer," but the raw data is token counts and API logs, which isn't something you can hand to a CFO as-is
• FOCUS (FinOps Open Cost and Usage Spec) has been extending to cover AI/ML costs anyone actually using FOCUS 1.1 for this yet, or still building custom internal reporting?

How is your team handling this: internal tooling, spreadsheets, one of the newer AI-specific cost platforms? And separately: is anyone actually attributing AI costs by feature/team/department in a way finance trusts, or is it still mostly "here's the total bill, we think"?

I run a small cloud-firewall/NAT product, and before I get to that (disclosure up front, mods OK'd this post — see the bottom), I genuinely want to compare notes with people operating this at scale across many clients, because the maths gets ugly faster for you than it does for a single tenant.

The thing I keep running into: the cloud-native egress controls are metered per gigabyte, and that meter never stops scaling with the client's traffic.

Rough numbers, US figures, so you can sanity-check against your own invoices:

• AWS NAT Gateway — ~$0.045/GB processed, plus ~$0.045/hr per gateway.
• AWS Network Firewall — ~$0.065/GB inspected, plus $0.395/endpoint-hr ($288/mo per AZ), billed per endpoint per AZ, so a 2–3 AZ design multiplies the hourly floor before a single byte moves.
• Azure Firewall — a per-GB processing charge on top of a per-hour SKU floor (Standard ~$1.25/hr).

For one tenant that's an annoyance. Across an estate it's a structural margin problem, because:

1. Your managed-service price is fixed, but your cost base floats with the client's traffic. You quote a monthly number; their egress doubles after some launch or batch job; your firewall/NAT line doubles with it and quietly eats the spread.
2. The per-AZ hourly floors stack before any data moves. Multi-AZ inspection means paying the endpoint-hour several times per client just to be resilient — multiply across N tenants.
3. It's two meters, not one. Egress filtering and NAT each meter per-GB, so the same gigabyte often gets charged twice on its way out.
4. You usually can't cleanly pass it through. Clients want a predictable monthly number; a traffic-indexed true-up is painful to explain and worse to forecast.

So the real question for this sub: how are you actually dealing with this? The options I've seen MSSPs take, none free:

• Eat it as cost of goods — fine until a chatty tenant turns a profitable account unprofitable.
• Pass it through as a metered line item — honest, but kills the "predictable managed service" pitch and invites bill-shock arguments monthly.
• Centralise inspection (one shared firewall behind a GWLB / transit hub) to amortise the hourly floors — helps per-hour, does nothing for per-GB, concentrates blast radius.
• Roll your own on pfSense/OPNsense/VyOS to dodge the meter — kills per-GB cost but you now own patching, HA, config drift and multi-tenant management by hand.
• Stay on the mega-NGFWs (Palo, Fortinet, Check Point) where MSSP programs and multi-tenancy are mature — but the licensing/complexity is a different pain, and overkill if all you need is egress + NAT.

Genuinely interested in what's working: are you centralising, DIY-ing the NAT/firewall layer, passing per-GB through, and how are you keeping fleet management sane? And for those who've moved off cloud-native — what did the migration actually cost in engineer time?

Disclosure (mods approved this post): I'm the founder of Enforza, which is one of the options above — so take this as "here's what we built and why", not a neutral survey. It's a cloud-managed firewall + secure NAT gateway you run as a normal Linux VM (an NVA) inside the client's own network/account, built on standard Linux network primitives. It does L3/L4/L7 egress filtering (by FQDN/SNI), ingress, east-west and secure source-NAT, and runs as a transparent appliance behind an AWS Gateway Load Balancer if you want centralised inspection without re-architecting routing.

Why it's relevant to this thread: it's priced flat per firewall, no per-GB data-processing charge — so the cost base stops floating with each client's traffic. At modest egress it tends to land 60–80% cheaper than a cloud-native firewall stacked with a NAT gateway — directional, workload-dependent, so run your own numbers, don't trust mine. To be straight about what it does and doesn't:

• It replaces the firewall/NAT metering — you still pay AWS/Azure for the VM and normal bandwidth. Not a way to dodge your CSP's infra bill.
• No TLS decryption and no key custody. FQDN/SNI filtering reads the hostname already in the clear (SNI, Host header, DNS).
• Multi-tenant by default (each client an isolated tenant), whole fleet from one console — GitOps/policy-as-code or UI — with logs to each client's own SIEM, not through us.
• Small bootstrapped team, but not a weekend project — in production ~3 years. It's the focused egress/NAT/inspection set most cloud teams use, not a full enterprise NGFW suite; I won't pretend it matches Palo/Fortinet feature-for-feature.

Site's in my profile / I'll drop it in a comment if anyone wants it rather than linking in the body. Mostly I'd rather hear how you're solving the per-GB problem today — happy to be told the DIY or centralised route beats what we do for your shape of estate.

Cloudability used to be a leader in the space however it has been going down the drain ever since acquired by IBM on all fronts including innovation and customer support experience.

Currently looking to replace Cloudability, any recommendations from the group here?

Updated: realized no FinOps tool can check all the boxes however I would like to hear your experience on how and which FinOps tool makes your life better from an engineer, finance, leader persona perspective?

I have been looking into taking this cert but would prefer not to spend the $500+ needed to buy the study materials from the Foundation.

Are there any other materials I could use or even a set a practice questions I could leverage that should be good enough to prepare for the exam?

Hello everyone, currently digging into workflow-layer economics and trying to figure out how people track unexpected runtime spikes at scale.

At an early stage simple margin buffers are fine because volume is bounded. But once you move past basic apps, factors like failed loops, retries, and context window inflation create a ton of cost variance that is hard to forecast or map to clean client billing.

For those running agent or voice workflows in production, or working on complex ai products what do you currently use to understand costs and failures at the individual workflow level?

More importantly, what's something you still can't easily answer with your current setup? Like why did a specific workflow suddenly cost 2x more, or which exact customer trigger is driving the increase? Are you guys just manually digging through raw api logs to catch leakage like infinite loops, or has it not become a big enough issue for your teams yet?

Curious to hear how other teams handle the infrastructure discipline here.

Attempting to tie token usage and cost to business outcomes/deliverables within a company.

Think FinOps, Head of Engineering type use.

Looking to talk to:

- Engineers who've felt this pain firsthand

- Finance/ops people who've tried to wrangle AI budgets

https://tokenview-landing.vercel.app/

Most Copilot business cases I saw in my organization model one line: $30 per user per month times headcount. With Cowork in GA, and all the latest announcement from Microsoft, this is going to change.

Bill 1: the seats. $30 per user per month on an annual commitment. This is the only bill most teams model, and it is the one that is fixed whether or not the user ever opens Copilot.

Bill 2: the agents (the new variable layer). Copilot Cowork went GA and will be metered starting 1st July, roughly $0.01 per Copilot Credit, billed on actual usage and separate from the seat. This is the part that behaves like a cloud bill: it scales with how much agentic work people run, and it is easy to leave uncapped. Treat it like any consumption line. Set tenant, group, and user spend limits and watch the credit burn rate.

Bill 3: the waste (the unit-cost killer). The metric that matters is not seats purchased, it is cost per active user, or better, cost per task that actually shipped. At 40% adoption your true cost per active user is $75, not $30. Most "Copilot is expensive" complaints are low-adoption complaints in disguise.

Bill 4: the price change. Microsoft has a global pricing update landing July 1. Renewals before was a smart move.

Putting it together: the seat price is the headline. Your adoption rate and your credit burn are what actually set the unit cost.

What I got wrong earlier: I modeled Copilot like a flat SaaS seat and ignored the agent/credit layer entirely, because in the early previews it was free. The moment Cowork will start metering, the "fixed" forecast became a variable one, and the job will flip from license optimization to usage governance. I also over-trusted vendor adoption stats. Measure your own active-user rate, do not borrow the deck's, there are some build-in reports on the M365 Admin console to start with that.

How are you going to handle the credit-metered agent layer, capping at the tenant level, charging it back to teams, or just watching it for now?

A few days back I made a post in r/ProductMarketing about a payroll system that we were building. It is like a payroll system which steams your money and earns yield for the idle funds. In normal terms its like earned wage access in normal payroll systems where if the funds are kept idle, it earns yield for the company

You can check it out here: https://www.reddit.com/r/ProductMarketing/s/BFplhEVsGY

I got some really good feedbacks and thought of creating a complete finops suite for companies, DAOs (Decentralized Autonomous Organizations) so that their money is not kept idle. Their money should move

One thing I found out was companies keep a budget for their employees, bills and so on. So we are trying to build a platform where companies will come, create buckets of their budget, allocate a budget for each bucket. If that bucket is of employees, they can even further add people to the bucket and set a rate. Then they deposit an amount that will run the entire company and fill the company buckets one by one

But there is one twist: You idle funds will earn interest. It can be less but if the companies have a good amount of money then even 5% is also good considering that they are keeping their funds idle. So, its like a finance and treasury management suite for companies to manage their employees, budgets, bills but the money that is kept in your treasury will actually be earning yield for you

This is mainly for a blockchain solution and the reason is simple. RN every good team wants to move global and they might hop from bank to bank, in blockchains this problem is actually tackled very well. Using stable coins like USDC, USDT tokens can be transferred easily

I would love to know your feedbacks about this entire idea and also would love to know how your finance stack looks like so that I can draw some inspiration from them. If you also face a problem about something that messes up your finops then also please please write it down in the comments cuz I really want to solve a real problem and don't want to create new ones

I am a financial analyst in the uk. Total work experience more than a decade in Asia and the UK. Based on my reading I have come to know that FinOps people do not have expertise in both worlds (as they should I think). I have finance qualifications and experience but I dont have the cloud side and for that I have already done AWS Cloud Practitioner. Currently I am doing AWS Solutions Architect Associate. Next stop will be FinOps Certified Practitioner and FinOps Focus Analyst. This is my phase 1. After completing phase 1 I plan to go get my hands dirty. Get a temp role or an entry level job. Then after a while I plan to do phase 2 of certifications like Kubernetes Admin, Terrform, AWS Solutions Pro etc. Intention is to become an expert with experience in the cloud infrastructure world and I already have the finance side I believe. Am I heading in the right direction? My goal is to be able to understand any cloud infra fully as I believe without that you cannot do any cloud financial management. Please drop your advice and let me know if I need a reality check or calibration.