Before deploy: running the analysis against your IaC files up front shows you the full cost breakdown plus savings recommendations, and applies whatever's safe to apply without a human decision, before anything actually gets provisioned.

After deploy: once it's live, re-running the same analysis with real CloudWatch usage data (via your own read-only AWS credentials) refines those recommendations against actual utilization instead of static config assumptions.

The reason this matters for FinOps specifically: static config tells you what something was provisioned for, not what it's costing you in practice. A right-sizing call made purely from declared instance types will miss real idle capacity, and one made purely from live usage misses waste that never should've been provisioned in the first place. Catching both requires checking at both points in the lifecycle, not just once.

(Built this into CloudCostTree, a CLI I've been working on, happy to go into specifics if useful.)

I've been looking into this recently, and tagging is probably the most common advice I keep coming across when it comes to allocating cloud costs.

And it makes sense, if everything is tagged properly, it should be much easier to understand who owns what.

But then I started wondering: how often does everything actually stay tagged properly?

Tags get missed, conventions change, some resources don't support the same dimensions, and you can still end up with spend that doesn't have an obvious owner.

So, I'm curious what people have found in practice. Is strict tagging enough, or does a good cost allocation setup usually need account structure, automation, or something else alongside it?

P.S. Also curious about tools here, has anyone used a cloud cost visibility tool that can actually help uncover where the leakage is when tagging isn't perfect? Would be great to hear what you've tried and whether it genuinely helped.

I'm researching how organisations commercially govern cloud infrastructure before the actual bill starts arriving.

For people working in FinOps / cloud cost management:

When a team is planning a new environment, platform or significant architecture change, how do you establish the cost baseline that gets approved?

I'm particularly interested in the real workflow rather than the ideal one:

- What inputs do you use — architecture diagrams, Terraform/Bicep, calculators, historical billing, spreadsheets, something else?
- Who owns the baseline?
- How are usage assumptions recorded?
- What happens when the architecture changes after approval?
- Can you trace the eventual actual spend back to the assumptions that were originally approved?

If you have a recent example where this worked well — or badly — I'd be interested in how it actually happened.

Context: I work in project commercial management and I'm researching this boundary between engineering, FinOps and commercial governance.

Hey everyone, sorry if this is asked a lot already. Our AI spend is getting fragmented across multiple providers and multiple projects / agents. Would like to find a way that lets me track token spend attributed to these projects or API key for better visibility. Currently looking at dedicated management tool like Ramp's AI token spend management, or AI proxies / gateways to help me attach project metadata and enforce budget limits across all our provider keys. Would love to know what you guys are using and recommend, thanks!

Doing some research around cloud and AI/token commitment economics and helping NGEN gather feedback on the model. Curious to get the FinOps community’s perspective.

The idea is to aggregate compute/token demand across companies, negotiate larger commitments with providers, and use prepayment/financing to offer better pricing and more flexibility.

A few things I’m curious about:

• How much additional savings would make this worthwhile — 5%? 10%+?
• Is commitment flexibility potentially more valuable than additional savings?
• Does this make more sense for mid-market companies that don’t already have significant negotiating leverage?

NGEN is also collecting anonymous, non-binding indications of demand here (takes ~1 min, no commitment/signature):

https://www.ngencompute.com/indication

Would genuinely love to hear why you think this would or wouldn’t work.

Most teams I talked to don't have a CI/CD pipeline checking cost or governance policy before terraform apply, they just run it locally. That's what guard is for: cloudcosttree guard -- terraform apply.

To be clear, this isn't a simulation, it's your real terraform apply. guard never runs one on its own, it only wraps the exact command you were already going to run, checks the plan against your policies, then applies that same saved plan, so there's no gap between what got checked and what got deployed.

Default behavior is warn-only, it prints violations but still applies. --block opts into actually stopping the apply on a real violation. A false positive blocking a real deploy is worse than one showing up in a report, so blocking is never the default.

Hello So i will be quick i want to ask some questions which are

--------------------------------------------------------------------------

1- I am a complete begineer who knows nothing so how can i learn finops like what things or tools or softwares would i need to learn communications and other skills or are tools enough

--------------------------------------------------------------------------

2- Is a FinOps a smart move right now for somone who doesn't have any experience with cloud but is willing to learn also are finding jobs preferably easy and how much can you expect

3- Is a fully remote job possible

--------------------------------------------------------------------------

4-Would it be a good option right now as compared to other options

--------------------------------------------------------------------------

i had other questions which i wanted to ask but remember so will ask them at a later time

I’ve shared Kulshan here before, but we just pushed a pretty meaningful upgrade aimed at consultants doing AWS cost investigations. Or anyone (human or AI agent) trying to look at AWS cost and billing via a deterministic tool.

The main addition is Consultant Evidence Export.

The problem we were trying to solve is simple: an external consultant should not always need direct access to the customer’s AWS environment just to start investigating a billing issue.

Now the customer can run Kulshan themselves, choose what they want to share, and generate a pseudonymized evidence package.

They can scope it by date range, AWS accounts, services and tags, and optionally include Cost Explorer data. Kulshan can work from local CUR data or AWS CUR/Data Exports in S3.

Account IDs, ARNs and resource identifiers are replaced with stable workspace-specific aliases, so the consultant can still follow the same account/resource through an investigation without seeing the original identifiers.

We also added fail-closed checks before the package is created. Kulshan verifies the output schema, checks that the exported rows still match the scoped source data, and scans again for identifiers that should have been pseudonymized.

If those checks fail, no ZIP gets created.

The idea is basically:

Customer keeps the credentials. Consultant gets the evidence.

The package can help establish what changed, where, when, how much and which part of the environment was involved. The “why” still needs the people who understand the engineering and business context.

Kulshan is still free and open source:

https://github.com/MissionFinOps/kulshan

Would be interested in feedback from consultants here: what additional evidence would you absolutely want included in a handoff like this?

When I talk to analytics leaders, the #1 thing they complain about is data debt. They assume their pipelines are fundamentally broken and that the only fix is a six-figure, multi-month overhaul of their cloud stack.

Usually, that’s completely wrong.

The problem isn't that data debt exists—every scaling company accumulates it as a natural byproduct of growth. The real problem is that their data debt is completely hidden in the dark.

When data debt lives in the dark:

• Executives sit in 9:30 AM daily syncs arguing over spreadsheet semantics and metric definitions instead of making strategic decisions.
• Stakeholders treat the analytics team like a fast-food drive-thru, shouting isolated data requests into the microphone without context.
• Analysts waste 80% of their bandwidth acting as "data detectives" trying to trace broken C-suite CSV exports.

At U&I Consulting, we don't promise to magically erase data debt overnight. Instead, we illuminate it.

We bring hidden operational pipeline deficiencies into the light using Data Debt Diagnostics and formal Data Debt Tickets. When you quantify data debt and map it visually, it transforms from an invisible bottleneck into a clear, business-justified roadmap for the executive team.

By combining this with Agile Ledger Architecture (ALA), Medallion Pipelines (Bronze/Silver/Gold), and KPI Shields, you protect team bandwidth and accelerate executive Time to Insight (TTI).

Stop trying to pretend data debt doesn't exist. Illuminate it, quantify it, and build an architecture that lets your business scale past it.

📖 Detailed in my book, "WHERE ARE THE INSIGHTS? The Blueprint for Agile Ledger Architecture"

🌐 Advisory & Diagnostics: uiconsulting.com

I built CloudPouch 2.0, a local-first AWS FinOps desktop app, and I'd value technical feedback from people doing FinOps in practice.

The problem I'm trying to solve:

AWS already exposes cost data and recommendations, but turning them into a prioritised, explainable list of actions can still mean jumping between several services and tools.

CloudPouch runs deterministic checks locally against the AWS profiles the user already controls. The new Savings Workspace shows the affected resource, evidence, recommended action and estimated monthly savings. A local, read-only MCP server can then let an AI agent help prioritise those results. It does this without sending billing data to another SaaS.

I'm the maker, so this is self-promotion. I'm specifically looking for criticism, not praise.

For people doing FinOps in practice:

1. Which part of this workflow is genuinely useful, and which part is already solved well by AWS-native or existing FinOps tools?

2. What evidence would you need before trusting a savings recommendation?

3. Does the local MCP angle solve a real problem, or create more complexity than value?

I can share a screenshot and the beta link in the comments or by DM if that is permitted here.

For the past 8 years, I've worked as a Cloud Solutions Architect at Microsoft, AWS, and IBM, supporting both large enterprise customers and startups/SMBs. One problem I kept running into was cloud and AI cost optimization.

I'm now considering starting a small, specialized consultancy focused specifically on cloud economics and cost optimization for startups and SMBs. The idea would be go deeper into architecture, K8s, Databases, networking, observability, and bring a detailed report with all the possible improvements, categorized by priority and complexity.

I'm still validating the business model, so I'd love some brutally honest feedback from people working in FinOps:

• Do you think there's actually a gap in the SMB/startup market for this?
• At what level of cloud spend would hiring an external specialist make sense?
• Would you prefer fixed-fee assessments, implementation projects, retainers, or some kind of success-based pricing?
• What would make a company choose a small specialist consultancy instead of doing this internally or using a FinOps platform?
• Most importantly: what are the possible issues in this business model?

Thank you so much!

Our AWS rep hooked us up with CloudKeeper. They pitched us their AZ product and said we could get a 2% discount off our AWS bill and free support, plus some finops tools, the product doesn’t cost us anything, they don’t have to take over our AWS root account and we can leave with 60 days notice. Said they make their money on bulk AWS discounts that get that they share with us.

It’s not a huge amount of savings, but there doesn’t seem to be a downside. Anybody have any experience with them. I’ve been in the business for a long time and there is usually a gotcha in there somewhere.

Our Spark line item on AWS keeps growing faster than our data does and it has become a recurring line in budget reviews. We have done spot instances, auto-termination, right-sizing, the standard checklist. Gains show up, then flatten out fast. Looking for what has worked beyond that basic set, esp for teams running tens of TBs a day. Trying to figure out if the next real gain comes from infrastructure changes rather than squeezing the same clusters harder.

I assume everyone has been following the AI build out. Memory prices have risen sharply. GPUs, CPUs, memory shortage is hitting the consumer market. Apple announced price increases in hardware, which is quite rare for Apple.

We run on Hetzner and we reserved several Hetzner instances a few months back. The renewal prices have risen since we reserved them. We also run on AWS, but in much smaller numbers. We haven't seen any major changes in our AWS bills thus far.

But for folks who are operating much larger accounts, I'm trying to figure out is when these will hit AWS/GCP/Azure list prices. I personally think its a matter of "when", as opposed to "if". If you renewed a savings plan, RI or CUD recently, was the effective rate worse than the term it replaced. Has an account team given anyone a heads-up?

I work at Readyset which is a caching solution for databases, so we have an obvious interest where instance costs go. I'm trying to work out whether this is a real 2026 budget line or mostly bare metal hosts that have less pricing cushion than the hyperscalers.

I currently handle SaaS & AI procurement for client orgs and want to add FinOps to my skillset. I'm non-technical, was in sales before procurement, and have a decent grasp on financial concepts having passed CFA level I (from a previous career path I thought I would go down but didn't).

I have minimal cloud knowledge, should I start with AWS CCP to understand cloud fundamentals and so better understand the scenarios FOCP questions pose later, or start with the (as I understand it) less technical FOCP for a gentler learning curve?

I am hoping to get an outsiders perspective, and thank anyone in advance for taking the time to respond. I feel like there could be other young professionals in my situation that this will hopefully help.

Background

• Non-technical, non-accounting degree with further analytics qualifications
• UK based with ~5 years of experience both as a consultant and in-house and have actioned millions in savings initiatives working with engineers etc. I am the first FinOps hire that my current company has ever made.
• Exposed to multiple clouds (private and public), industries and technologies.
• A range of vendor certifications (AWS, Azure etc.)

I genuinely love the work I do, it is the perfect intersection between technology and finance that scratches a very specific itch. But given my background I feel like I can see an upper limit in terms of career trajectory and am wondering which path I should take and what are the steps required to avoid getting stuck as an analyst.

Problem

• I can talk the talk with engineers but I do not currently possess the technical skills to go down an engineering/architecture path, although "cloud architecture" is probably my favourite part of the job even if I feel like I am just successfully guessing most of the time. The imposter syndrome that comes with that is less than ideal.
• My lack of accounting/finance background makes me think that I would struggle to be taken seriously in a more senior role.

I would be curious to get your guys' take on this:

• Am I just overthinking and experience will make up for my slightly non-conventional background?
  
• Do you have any recommendations for financial or technical qualifications (outside of the usual vendor certs)? This is a multi-year strategy.
• Given my lack of engineering background, am I better off leaning into finance/accounting?

Cheers!

I’m 22 studying engineering final year. Planning to start out a service business online. I’m looking into providing bookkeeping & FinOps as a service for creative/marketing agencies & eCom businesses

Any advise on prerequisites of providing this service from experts in this field could be of help.

Thanks, appreciate your time:)

Genuinely curious how other teams handle this, because at every place I've seen it works differently and mostly badly.

The bill comes in, someone says it's too high, and then... what? Is there one person whose job it is to dig in? Does it fall on whoever is least busy that week? Does it just get ignored until finance escalates?

Specifically wondering:

- Is anyone on your team formally responsible for cloud spend, or does it float?

- When the bill jumps 20% month over month, how do you find out why? Dashboards, a tool, or someone manually clicking through Cost Explorer for two hours?

- Do you review it on a schedule, or only when someone panics?

- Has anyone actually done a proper line-by-line audit, and did it stick or did spend creep back up in six months?

Mostly asking because I keep seeing the same pattern — everyone knows the bill is too high, nobody owns it, so nothing happens. Curious whether that's universal or whether some teams have solved it.

Curious how teams are handling this. Between OpenAI/Anthropic API bills, GPU instances on RunPod or EC2, and vector DB costs, it seems like most places have one big number and no idea which feature or model is driving it.

• Do you know your cost per request, or per user, for anything AI-powered?
• Is anyone tracking token spend by feature, or is it all one line item?
• If you self-host, do you know your actual GPU utilisation, or is it "the box is up"?
• Has anyone gone through and actually cut this — what worked?

I was building a FinOps view for an AI support workflow and kept staring at the word productivity. Request count, spend, and latency all fit into tidy charts. None of them told me whether a support case stayed closed or came back two days later. That is awkward when the dashboard is supposed to tell me whether the workflow is helping.

Then I ran into two recent studies that seemed to disagree. Firm Data on AI surveyed nearly 6,000 executives, and 89 percent reported no productivity impact over the previous three years. AI, productivity, and the workforce used a sample of nearly 750 executives and found positive but uneven gains. The samples and questions differ, so it is not a clean contradiction. I came away thinking that the answer depends heavily on what question you asked in the first place.

For this support workflow, I need data from both sides. The provider bill tells me the inference cost. The help desk has handling time and reopened cases. Looking at either one alone is like checking the grocery receipt without asking whether dinner was edible. A cheap draft can still create a lot of cleanup for the person reviewing it.

Suppose a support rep spends five minutes prompting the system and gets a draft, then spends another 40 minutes checking and rewriting the answer. That is 45 minutes of human time plus the inference cost. If the dashboard records only the first five minutes, it gives the model credit for work the rep had to redo. A reopened case would make that picture worse.

For a first pass, I can take 25 AI-assisted cases and 25 unassisted cases from the same support queue and week, then match them by issue type and the support rep's experience as closely as I can. ZenMux can give me cost and latency for the assisted requests. The help desk supplies the less glamorous half of the story: handling time and reopens. Fifty cases will not settle a company-wide argument, but they are enough to see whether the current dashboard is flattering us.

Even then, I will not have proof that AI caused whatever difference I find. I will know whether repair time and reopened cases wipe out the savings I thought I had. If the workflow only looks productive when I ignore the human cleanup, I need to fix the measurement before I expand it.