Managing cloud costs is just as important as managing the technical side. This episode discusses the FinOps Foundation under the Linux Foundation, its principles and maturity model, and its connection to cloud native through tools like OpenCost and KubeCost.

So far this series has mostly discussed the technical side of cloud native: projects, architecture, and governance. But there's one side just as important for organizations: cost. Managing cloud spending can be the difference between a healthy business and one that goes quietly bankrupt. This is where FinOps comes in.
FinOps stands for Financial Operations — the practice of managing cloud costs collaboratively between finance, engineering, and business teams. This field has grown into a major movement with its own foundation, which turns out to sit under the same umbrella as CNCF.
By the end of this episode you will understand what FinOps is, know the FinOps Foundation, and see its connection to the cloud native world — including the tools born from the intersection of the two.
FinOps is a discipline that makes engineering teams accountable for the cost of the services they use, supported by the right processes and tools. Its goal isn't just cutting costs, but optimizing value: paying a fair price for the capacity actually needed.
FinOps is summarized in three principles: collaborate — teams work together across functions; everyone takes ownership — everyone is accountable for their own cloud usage; reports are accessible — cost data is easily accessible to all parties. Without these three principles, cost optimization just becomes the task of one overwhelmed team.
Interestingly, these principles are very similar to the culture we see in the cloud native ecosystem: transparency, shared ownership, and automation. That's one reason FinOps and cloud native have grown side by side so quickly.
The FinOps Foundation designed the FinOps Maturity Model, which maps an organization's maturity in managing cloud costs — from the basic level (crawl) to the advanced level (run). This model helps organizations assess their position and plan measurable improvement steps.
This maturity model is also useful for you as a framework for understanding roles in the FinOps world: cost analysts, engineers who optimize resources, up to leaders who make cloud investment decisions.
Like the project maturity levels in episode 4, the FinOps maturity model gives an honest signal: organizations can't jump from the most basic level straight to the most mature. The journey is gradual, and each stage has different practices.
The FinOps Foundation is the organization that shelters the development of FinOps practices. It was established under the Linux Foundation — right next to CNCF. Its membership spans practitioners, vendors, and academics worldwide, focused on sharing best practices and setting industry standards.
This position next to CNCF is no coincidence. Both handle big problems in the cloud world: CNCF handles how to build and run systems, FinOps handles how to pay for them. Their concerns often meet at one point: Kubernetes workloads.
For those following this series, this is good news: every cloud native concept you've learned — resource management, scaling, observability — has a direct connection to cost management that will become increasingly important in the future.
Kubernetes brings ease along with unique cost risks. Because adding capacity is easy, costs can balloon unnoticed: containers that are never turned off, idle nodes, and unused storage are common examples of hidden costs.
FinOps becomes important because it provides a language and tools to talk about these costs. Engineering teams can compare efficiency across teams, and management can see where waste comes from — something hard to do without FinOps discipline.
One key concept is unit economics: calculating the cost per meaningful unit, such as cost per transaction or per active user. With unit economics, abstract cost numbers become figures that can be compared across periods and teams.
Cost optimization in the container world often means three things: rightsizing — using appropriate resource sizes, scaling — automatically adding and removing capacity, and cleanup — removing unused resources. All three are both technical and FinOps practices.
Notice that the technical skills we've learned in this series — such as understanding requests and limits in Kubernetes — turn out to be FinOps skills too. Accurate knowledge of resources and scaling is the foundation of good cost control.
At the intersection of CNCF and FinOps, tools like OpenCost and KubeCost were born, calculating the cost of Kubernetes workloads based on actual resource usage. They answer the hardest question in the container cost world: how much does one Pod or one namespace actually cost?
These tools act as a bridge: they turn complex technical data into cost figures that finance teams can understand. If you want to see how a cost observability tool is installed in a cluster, the example below shows how via Helm:
helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm repo update
helm install opencost opencost/opencost -n opencost --create-namespaceThe helm repo add command adds the OpenCost chart repository, then helm install installs it into a dedicated namespace. This is a real example of how a FinOps tool runs on top of the cloud native infrastructure we've discussed throughout this series.
The latest trend shows the emergence of cost observability — observing costs as part of observability, not just monthly reports. Cost data is starting to be integrated with performance metrics so organizations can see efficiency in a single dashboard.
This direction clarifies the CNCF-FinOps relationship: traditional observability tells the story of system health, and cost observability tells its efficiency story. Both are two sides of responsible system management.
You don't need to wait to work at a big company to learn FinOps. Start by understanding the concepts of requests, limits, and autoscaling in Kubernetes — all of them are the foundation of cost optimization. Also learn how to read cost data from the cloud provider you practice with.
If you want to go deeper, open finops.org to learn the principles and maturity model, and read the OpenCost documentation to see how cost data is calculated. Both are open, beginner-friendly learning resources.
FinOps is a field with continuously growing demand, and the combination of technical plus financial skills is a rare, highly valued combination. An engineer who understands Kubernetes and can also explain its cost implications is an almost irreplaceable asset.
For those who enjoy numbers and analysis, FinOps can be a career direction of its own — separate yet close to the cloud native world you're learning.
The most sought-after combination is someone who understands both worlds: able to read Kubernetes dashboards while explaining their implications for the monthly budget. If you can build both skills in parallel, you'll occupy a position others find hard to fill.
Episode 13 introduced the financial side of the cloud world: FinOps with its collaborative principles, the FinOps Foundation under the Linux Foundation, its connection to Kubernetes costs, and tools like OpenCost that bridge CNCF and FinOps.
Key takeaways:
In episode 14 we'll return to the human side: the end user community and chapters — the user forum that shares practices, local communities like Cloud Native Jakarta and Cloud Native Indonesia, and how to join from your region.