How to Reduce Cloud Costs for Java with FinOps

James Johnston, VP EMEA at Azul, argues that only a tight FinOps‑engineering partnership can rein in overprovisioned Java estates, reduce cloud costs, and boost performance all at once. 

In this post you will learn: 

• 29% say tracking software use across environments is difficult 

• FinOps and engineering must align on a transparent set of rules 

• Only 3% of ITAM/SAM teams do not engage in activities that support security initiatives 

FinOps adoption is maturing but it should be no surprise that FinOps is widely used in the enterprise. According to Flexera’s 2025 State of the Cloud Report, 59% of enterprises are expanding their use of their FinOps teams to regain control over spending. In fact, the number of respondents that use, or plan to use, a FinOps team increased by 8 percentage points year over year. 

Historically, FinOps has focused on visibility, tagging, and monitoring so organizations can accurately see what they are spending and can allocate the right charges back to individual departments. This is the foundation needed to enable organizations to properly budget and forecast cloud usage. There has also been a focus on anomaly detection to ensure organizations spot issues, avoid costly overspend, optimize workloads and reduce cloud waste. 

However, now FinOps teams are doubling down on reducing cloud waste and workload optimization as highlighted by the FinOps Foundation’s State of FinOps 2025 report, where both were pulled out as top priorities.

This reflects a continued move towards value through optimization, because performance is becoming a more critical factor at a time when there is growing demand for compute resources to support innovation. These costs are spiraling thanks to the growing competition for hardware resources driven by technologies like artificial intelligence. If organizations can streamline cloud resources right down to the CPU, network and data storage level it offers significant advantages. 

Consequently, planning and estimating the costs of new technologies and new workloads is just the beginning. FinOps practitioners must educate stakeholders on the benefits of optimization so they can efficiently architect for the cloud. When operations are underway, engaging engineers in workload optimization, and performing rate optimization become key activities.  

To be successful requires FinOps and engineering teams to collaborate closely, which also demands an adjustment to the DevOps mindset. This collaboration is key to optimizing cloud usage without sacrificing performance. 

Optimization through collaboration 

Collaboration is important, because the main protagonists in using cloud resources are engineering and DevOps teams. To date they have not been tasked with understanding the cost implications of spinning up new cloud instances and the danger is that they may unknowingly have a key role in driving up indirect cloud spend. 

Why? DevOps is a discipline, whose main purpose is to enable the fast development and delivery of new features and functions. 

This is a disposable infrastructure mindset with teams typically measured primarily on performance SLAs to ensure the application is in production in a timely manner and that it is highly available. If that is the priority, then DevOps is less inclined to pay attention to how much is being spent on cloud usage. Therefore, a FinOps and engineering partnership is central to overcoming the issue. 

This is especially true for data analytics platforms and AI or ML environments that require large data sets for modelling. There is a significant amount of compute needed to drive large Java estates which has the potential to increase recurring cloud charge commitments and can change budget forecasts. 

So how do you avoid this becoming a problem? 

Applying FinOps policies to Java application engineering 

What FinOps needs to work on with the engineering team is a set of transparent rules, starting with an agreed limit on how much wasted capacity the teams will tolerate. This will enable the organization to enforce utilization policies without having to wait for engineers to self-enforce rules. This also helps to balance the need for the right level of infrastructure to give developers the cloud capacity they need to build new functionality in a timely manner. 

Applying this approach to Java has some specific considerations. Java has been around for a very long time for data processing. It is incredibly robust, but there is an issue around warm-up time to deal with transactions at speed, especially if there is a big spike in traffic. Users have been concerned that latency-sensitive Java applications will not be able to provision additional server resources in time to meet traffic demand without affecting the customer experience. 

To get around this issue, many organizations have over-provisioned cloud resources as a back-up to ensure performance, scalability and flexibility. This, though, creates utilization inefficiencies – so large Java estates are low-hanging fruit for FinOps teams. 

Encouraging a culture of collaboration 

If FinOps is deployed effectively in Java environments, it enables organizations to innovate more aggressively and encourages a different approach to deploying cloud resources. 

The clear lesson is to create a culture of collaboration between FinOps and the engineering team. Like the Formula One racing teams that have just started the new season, the need for collaboration is crucial for marginal gains. Greater emphasis on teamwork will see organizations buy into the value of FinOps and enable them to optimize their Java assets to reduce cloud waste and improve performance. 

Lower your cloud costs with Java 

Azul Platform Prime is a high-performance Java platform that executes Java code faster, delivers consistent performance and improves warmup for greater elasticity so applications use fewer compute instances for the same workload, lowering cloud waste. Enterprises reduce cloud compute costs by 20%+ with Platform Prime.

 A version of this article originally appeared in Data Centre Review