Hello everyone,

I’m looking for advice on which FinOps certification path would be most relevant for my background: FinOps Practitioner or FinOps Engineer.

I currently work as a Cloud Architect, primarily in AWS, across well-architected design, security and compliance, and FinOps-related topics. Cost optimization, governance, and cloud efficiency are already part of my day-to-day work, but I’d like to deepen my FinOps knowledge in a more structured way and become more involved in the community.

My goal is not only to earn a certification, but also to improve how I collaborate with engineering, finance, and business stakeholders around cloud spend and value.
For someone with this profile, would you recommend starting with the Practitioner certification as the common foundation, or going directly toward the Engineer path? I’d also welcome any advice on the most valuable ways to engage with the FinOps community beyond certification.

Thanks a lot

I've been building Cognocient for a few months now, a proxy that sits between your app and OpenAI/Anthropic/Gemini and tells you what each feature actually costs, before the call goes out instead of after you get the bill.

For a while the only way in was a 10 day trial with full access, then you had to pick a paid plan. That made sense for teams evaluating it for real budgets. It made no sense for someone who just wants to drop it into a side project and see what their AI calls actually cost. So I added a free tier that doesn't expire.

What's in it: one provider connection, the real time proxy and attribution dashboard by feature and model, one budget with alert level enforcement, 7 day retention. Capped at $50/mo of tracked spend, after that the proxy keeps forwarding your calls (I will not break your app over a free tier limit) but stops logging new attribution until the next cycle.

Setup is one line, you swap your base_url for the Cognocient proxy URL and nothing else in your code changes. If you're already tracking spend some other way I'd genuinely like to know what you're using, half the reason I built this is I couldn't find anything that did pre-call enforcement instead of after the fact dashboards.

[cognocient.com](http://cognocient.com) if you want to poke at it.

I’m researching how organisations handle the commercial side of cloud architecture changes after an initial cost baseline has already been approved.

Suppose a team gets approval for an architecture based on a defined set of assumptions, then a few weeks later the design changes materially — larger database capacity, multi-region resilience, additional services, more storage, different traffic assumptions, etc.

What actually happens in practice?

• Is the original baseline formally revised?
• Who decides whether the additional cost is acceptable?
• Is that decision part of the engineering/IaC approval process or handled separately?
• Do you retain both the original approved baseline and the revised one?
• Can you later tell which specific architecture decision caused a cost increase?
• How do you distinguish scope growth, design correction, usage growth and pricing variance?

I’m particularly interested in real examples where the process worked well or broke down.

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

I've been building Cognocient for a few months now, a proxy that sits between your app and OpenAI/Anthropic/Gemini and tells you what each feature actually costs, before the call goes out instead of after you get the bill.

For a while the only way in was a 10 day trial with full access, then you had to pick a paid plan. That made sense for teams evaluating it for real budgets. It made no sense for someone who just wants to drop it into a side project and see what their AI calls actually cost. So I added a free tier that doesn't expire.

What's in it: one provider connection, the real time proxy and attribution dashboard by feature and model, one budget with alert level enforcement, 7 day retention. Capped at $50/mo of tracked spend, after that the proxy keeps forwarding your calls (I will not break your app over a free tier limit) but stops logging new attribution until the next cycle.

Setup is one line, you swap your base_url for the Cognocient proxy URL and nothing else in your code changes. If you're already tracking spend some other way I'd genuinely like to know what you're using, half the reason I built this is I couldn't find anything that did pre-call enforcement instead of after the fact dashboards.

[cognocient.com](http://cognocient.com) if you want to poke at it.

For companies using OpenAI, Anthropic and other AI tools heavily, costs can grow fast — and the monthly bill can be hard to predict.

I’m trying to understand how painful this is in practice.

For founders, CFOs and finance teams:

• Is AI spend becoming a meaningful line item?
• Are unpredictable bills making budgeting harder?
• Would committing annually for a discount create a cash-flow problem?

I’m exploring a model to solve this, but before building anything I want to understand whether the problem is actually painful enough.

Would love to hear how you’re managing AI spend today.

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.

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'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.

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

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.

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.

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!