In 2026, nearly every second IT director in large enterprises faces the same challenge: cloud bills are increasing by 15-20% monthly without apparent reasons, and there’s no transparency into where the money is going. After migrating to the cloud, IT expenses become unpredictable: orphaned resources, overprovisioning of Kubernetes clusters, forgotten dev environments, and a lack of Reserved Instances all turn the cloud budget into a black box. Multi-cloud strategies, which have become the de facto standard for large organizations, only amplify this complexity by multiplying it by the number of providers.
My position is unequivocal: without the consistent implementation of FinOps, a multi-cloud strategy will inevitably lead to uncontrolled cost growth that doesn’t correlate with real business value. FinOps is not just a set of tools, but a cultural shift that combines financial accountability with engineering practices, making cloud costs transparent and manageable.
Architectural reasons for cost growth
The primary reason for uncontrolled cost growth in a multi-cloud environment lies in the very nature of cloud computing and the absence of corresponding processes. The cloud offers unlimited resources on a pay-as-you-go model, which is its advantage but also its main risk. Any developer can launch a virtual machine or database, and if it’s not shut down after use, it will continue to incur costs. In large organizations, especially in the banking sector where hundreds of microservices and test environments are deployed, this leads to the accumulation of “cloud junk.”
For example, in a large bank with several million clients, utilizing Oracle DB, SAP, IBM ABS, and CRM (Salesforce/Dynamics) as key systems, plus a dozen internal applications reading the same data via an API Gateway, a typical architecture includes several Kubernetes clusters, a Data Lake for analytics, and numerous dev/test/staging environments. Each of these components, deployed in AWS and Azure, creates its own cost item. Without a unified approach to tagging, monitoring, and resource lifecycle management, it becomes nearly impossible to track which specific project or team is generating particular costs. This is not a technology problem, but a problem of lacking discipline and transparency.
A common mistake: FinOps as a one-off action
The most frequent mistake I’ve observed in FinOps projects is that organizations perceive it as a one-time optimization or the implementation of a new tool. They launch a pilot project, purchase a FinOps platform, conduct an initial audit, and reduce costs by 10-15%. After this, they consider the mission accomplished and revert to old habits. However, technology only reinforces processes. Poor management isn’t fixed by replacing a platform or a one-off action.
The correct approach is to embed FinOps into daily operations. This means regular meetings between finance and engineering teams, clear definition of budget owners for each cloud resource, automation of tagging and monitoring, and continuous team training. Without such a cultural shift and a continuous process, any initial FinOps successes will be temporary, and cloud costs will begin to rise again.
How FinOps solves the problem of multi-cloud costs
FinOps provides a structured approach to managing cloud costs, which is particularly crucial in multi-cloud architectures. Here are the key elements:
- Transparency and visibility: FinOps mandates the tagging of all cloud resources. This allows for precise identification of which resource belongs to which project, team, or business unit. For instance, SL Global Service assists clients in setting up centralized dashboards that aggregate costs from AWS, Azure, and GCP, providing a unified view for financial and IT directors. Without this, the CFO sees only the total provider bill, not its breakdown.
- Resource optimization: FinOps focuses on continuous optimization. This includes identifying and shutting down unused resources (e.g., forgotten dev environments), right-sizing virtual machines and databases, and utilizing Reserved Instances or Savings Plans for predictable workloads. The largest cloud expenditures often arise not from expensive services, but from resources that everyone forgets about 3-4 months after launch.
- Culture of accountability: FinOps shifts the mindset from “the cloud is free” to “every resource has a price.” Engineers begin to understand the financial implications of their architectural decisions. This is achieved through regular cost reports for each team, setting budget limits, and integrating FinOps metrics into DevOps and CI/CD processes. For example, using Terraform for Infrastructure as Code (IaC) allows not only for automated deployment but also for embedding cost control policies directly into the infrastructure code, which is a vital element of FinOps.
Risks and limitations
FinOps is not a panacea and has its limitations. Firstly, it requires significant investment in cultural change and training. If business leaders and IT management are not ready for these changes, FinOps will remain merely a formality. Secondly, FinOps may be excessive for small companies with fewer than 5-7 cloud services and a small budget. In such cases, simply enabling Reserved Instances and auto-shutdown of dev environments will yield most of the benefits without complex processes.
Furthermore, FinOps can be challenging to implement in legacy environments where there is no clear tagging or deployment automation. In such scenarios, an inventory and standardization effort is necessary first, which can be time-consuming. Do not start FinOps implementation if you lack a clear cloud budget owner on the IT side who has the authority to influence engineering decisions.
Consistent FinOps implementation transitions the cloud budget from “unpredictable expenses” to a managed item with transparent allocation across teams. In practice, this resolves most CFO queries about bill justifications and allows for next year’s planning without a “just in case” buffer. Before launching a tender for a FinOps platform, conduct an audit of your current cloud usage and identify a business-side budget owner. 80% of future problems are visible at this stage, and it costs you nothing. The SL Global Service teams manage such projects from as-is assessment to production support, helping to integrate FinOps practices into daily operations.