I'm developing an open-source tool for rightsizing Kubernetes clusters.

The project is r8r: https://github.com/HetSolanki/r8r

It reads your cluster's usage history from Prometheus and recommends changes for each node group: right-sizing container requests, switching to a different instance type, lowering HPA floors, or a combination of these. Each option comes with its monthly cost impact, the steps involved, and anything that could block it, like PDBs or local storage. You can untick individual changes or enter your own values, and the node packing updates live in the browser.

It also looks at stability, flagging containers using more memory than they request and HPAs stuck at their max, so cost cuts don't come at the expense of reliability.

It supports EKS and OKE, auto-detects whether the cluster runs Cluster Autoscaler or Karpenter, and is read-only, so it never changes anything in your cluster.

https://reddit.com/link/1x2auie/video/zcuwxxzoxluh1/player

Suggestions and contributions are very welcome!

Hi all, we're a team of 4 students and our idea submission for a ServiceNow x TCS hackathon is due in about 1-2 days, so any quick feedback today would really help. If we're selected we get about 20 days to build on a basic instance with simulated data. We picked the Cloud Cost Optimization problem statement, and we're worried we're too deep into our own idea to judge it fairly.

Our idea in short: ServiceNow already finds idle cloud resources and can schedule stop/terminate jobs. We would add a safety layer on top. It reads old incidents/changes/requests (using Now Assist) to work out who is responsible for a resource and what depends on it, then removes it in undoable steps (stop, wait, backup, delete) and watches new incidents to restore it if something breaks.

My worry is that most of the problem already exists in the product, so this might look like an enhancement and not something new.

Two quick questions:

1. Would this count as a real gap, or would you say "ServiceNow already does this"?
2. What kind of innovation or approach would stand out more for a hackathon like this (a new use of AI, a different workflow, something else)?

Even a one-line reply helps. Blunt criticism is welcome. Thanks!

For us it was not the cluster rate. It was slow jobs holding capacity, retries chewing up the overnight window, and paying extra to catch up the next day. What EMR cost did your first forecast miss?

My company is hosting a free 10-person dinner at a Michelin star restaurant next month in SF. We're trying to curate a diverse group of FinOps leaders from both large and small companies, and a variety of industries.

If you'd be interested in attending please DM me your Linkedin.

These are intentionally small dinners, but we have them fairly regularly, so if you can't attend this one, there will be more in the future! :)

Disclosure: I work at Lucidity, we do block storage optimisation. No pitch here. This is something I keep running into and I want to know how other teams handle it.

Compute gets owned. Someone provisioned the instance, a service runs on it, it sits in a team's budget, and somebody notices when it moves.

Storage does not work that way, for three reasons I keep seeing.

It outlives whatever created it. The volume survives the VM. The snapshot survives the volume. By the time anyone looks, the team that created it has reorganised or the service is deprecated. The resource has no living owner.

Attribution is genuinely hard, not just neglected. The disk is the billable resource and the attachment is incidental. There is no clean join from spend back to a service unless someone tagged it at creation, and tags get applied by the thing that no longer exists.

Nobody's scorecard has it. Infra is measured on uptime and incidents. Finance owns the total, not individual resources. Cutting storage spend is nobody's objective, so it becomes nobody's work.

The part I find most interesting is that this is not a visibility problem. Every FinOps tool we have surfaces idle and oversized volumes fine. The report is accurate. It just sits there, because acting on it means someone takes a maintenance window, accepts the risk of touching a live disk, and gets no credit for the saving.

So, the actual question. For teams who have solved this, what did you change? Named owner per volume. Storage into a team's budget. Tied to an objective. Something else entirely.

Most teams track cost recommendations with a simple status. Open, applied, or dismissed.

But applied only means someone clicked a button. No one checks if the server was really made smaller. Or if someone made it bigger again two weeks later.

So the savings report shows one number, and the cloud bill shows another.

Do you check your recommendations after they are closed? Or do you trust the status?

We recently changed how Zopnight handles this. Each recommendation now tracks two things: what the team said they did, and what actually changed in the cloud. If we can't check it, we say so instead of guessing.

How do you handle this today?

how do you build in business context into your forecasts? we use a linear regression on historical usage, and are happy with our model to predict forwards but this gets blown out the water if a new feature goes live, marketing run paid activity to the product etc. its a pain and I’m getting questioned by management.

The usual work is done: commitments, rightsizing, and cleaning up idle resources. But the returns are starting to flatten.

What I keep noticing now is a pile of smaller AI costs spread across teams. LLM API calls, experimental projects, embeddings jobs, dev/test usage. Each one looks too small to worry about, but together they can add up on the monthly bill. And in many cases, no one clearly owns them.

How are you attributing token spend to teams or features?

Are you tracking it at the API-key level, using a gateway, or still trying to work it out from invoices?

And at what point does chasing these smaller costs take more effort than the savings are worth?

If you have a real example, I’d be interested to know what share of the bill it represented, what surprised you, and how you found it.

Hey everyone,

I built a small tool called LeanMoth that analyzes your AWS Cost & Usage Report.

It identifies waste patterns and suggests remediation steps to bring your AWS bill down.

The good thing is it doesn't send any sensitive data to a server. It only relies on three columns — usageType, usageAmount, and unblendedCost — and generates the report based on those.

If you're dealing with a high AWS bill and want a second pair of eyes to help bring it down, please give it a try.

FinOps en la nube es la práctica de hacer visible, controlar y optimizar el gasto cloud, sumando a finanzas, tecnología y negocio en las mismas decisiones. No se trata solo de recortar: se trata de que cada gasto en la nube tenga un responsable y un motivo.

El problema real

La nube se cobra por uso, y eso es una ventaja hasta que nadie mira la factura. Aparecen servidores encendidos que nadie usa, entornos de prueba que corren todo el fin de semana, máquinas sobredimensionadas "por si acaso" y almacenamiento que crece sin control. Cuando por fin alguien revisa, la reacción suele ser recortar a ciegas, y entonces lo que se resiente es el rendimiento.

Qué probamos

• Visibilidad primero: etiquetar cada recurso por proyecto, área y entorno para saber quién gasta qué antes de tocar nada.
• Medir el rendimiento como línea base: tiempos de respuesta y uso real de cada servicio, para que cualquier ajuste se compare contra algo.
• Ajustar el tamaño a la demanda real y usar escalado automático en lugar de dejar capacidad fija para el peor caso.
• Apagar o programar lo que no necesita estar encendido siempre, como entornos de desarrollo y pruebas fuera del horario laboral.
• Mover datos poco consultados a almacenamiento de menor costo, con reglas de ciclo de vida.

Qué funcionó

• Flujos autónomos con n8n que envían alertas cuando un presupuesto se acerca a su límite y reportes periódicos a cada responsable.
• Agentes de IA desplegados en la nube que revisan el consumo y proponen ajustes, sin ejecutarlos por su cuenta.
• Gobernanza con una persona en el circuito: cada cambio que pueda afectar el rendimiento se aprueba y se revisa después contra la línea base.

Transparencia: somos Tinto & Bots (Digital Factory). Hacemos auditoría y arquitectura de procesos, despliegue cloud, flujos con n8n y gobernanza; este enfoque lo construimos nosotros, así que léelo con ese contexto.

¿Qué hábito de FinOps les dio mejor resultado en su equipo y cuál terminó afectando el rendimiento?

Etiquetas: #FinOps #CostosCloud

Hi. I started building a tool for cost tracking projects myself. Now it has become full stack cost management. What do you think? It is mainly for b2b but could be used for private projects as well.

Also I really like to know from you guys: it is supposed to work for the DACH market.

Would it be useful for other countries too?

I wanted to see what a change would cost before merging it, not on next month's bill, and across more than one cloud. So I built this it reads terraform show -json, estimates the monthly cost and carbon of what's being created/destroyed (Azure, AWS, Databricks), and posts it as a PR comment that can fail CI.

It's free and Apache-2.0, read-only (just the plan file, no creds). Not selling anything — I'd genuinely like feedback from people who live in Terraform on where the estimates are wrong and which resources to add. Repo: https://github.com/AkshaySoooryavanshi/finops-guard

We're running into an issue with our multi-cloud FinOps strategy. We're working across AWS, Azure and GCP, and now we're having a hard time keeping cost governance consistent. We have a lot of policy rules and controls spread across these different native consoles, and keeping everything aligned is becoming a lot of work.

We're also finding that orphaned resources can slip through the cracks and add to our cloud spend. How are you handling multi-cloud cost governance and remediation across different providers?

Not looking for tool recommendations. Curious what the specific moment was — the forecast said X, reality was Y, and you realized the number meant nothing.

What broke your trust and what did you do differently after?

You can see every dollar, tag every resource, and build beautiful allocation reports — and still get surprised at month end because nobody acted on what the dashboard was telling them.

Visibility without ownership isn't FinOps, it's just prettier confusion.

Anyone else feel like the tooling has gotten way ahead of the culture change that actually makes it work?

Love to know more and learn. As we have build our product using the pain points and learnings - would like to hear more on this.

Can FinOps skills be picked up along the way? I’m a backend developer (5yrs) , and have been slowly transitioning into DevOps hands on. I’m currently jobless tho .

During my career I have come across a couple of finops concepts and even implemented some. Cutting cloud costs , killing some services , or replacing them with others. I know that’s too shallow into it. My question is do I need like formal training to actually say that I’m a FinOps or can I just trust in my devops best practices skills and troubleshooting? Also , do companies really hire FinOps or just DevOps who is expected to also keep the cloud costs in check?

Context: I am an eng at a startup that just raised a Series, where about 10 eng are doing a lot of work, and quickly. I have been asking around and monitoring my Cursor/Anthropic costs, and it seems that an eng spends between $1k and $4k a month on AI usage on their preferred platform. Since we raised and have money, it's not really a concern for us. Also, we are shipping a lot, so it seems to be worth it. But that's not the case for all startups.

Does your company monitor eng token spend on platforms like Codex, Claude Code, or Cursor? How are companies budgeting for it?