Attend our Next FinOps Live Event | 26 February
How can you FINALLY save thousands of euros each month on your cloud bill?
Now that you have fallen into the click trap, I must confess: there is no magic formula that will allow you to cut your cloud consumption in half, by third, or by a three-quarters overnight.
But this article is for those who want to move from opportunistic optimization to a truly sustainable FinOps approach.
Think of the FinOps team or expert as a travel guide you take with you on your journey. Even if you sometimes forget about us at the bottom of your suitcase (we forgive you), we’ll stay by your side to build a trip together that matches your expectations and adapts without constraints.
Imagine you have a budget of €300 for a weekend trip with friends from Paris to Lille.
There are hundreds of ways to get to Lille (train, car, bike, plane) and spend this budget. By the end of the weekend, some of you will have stuck to the budget down to the last euro, others will have exceeded it by a few euros, maybe even by several hundred euros, and some will have managed to optimize it by planning, even being able to extend their stay by a day or two.
That’s FinOps: you always have to ask yourself if what you’re using matches your expectations and real needs.
You get the idea: through this article, I’ll help you reduce or control your consumption so you can stick to your budget, or maybe even better, find savings in your budget, sharing a series of rules based on my experience as FinOps Lead at AXA Group Operations. These rules have helped us better understand our consumption, analyze deployed services, and detect anomalies more effectively.
Rule 1: Forget your on-premise beliefs
One of the major mistakes in a “move to the cloud” strategy is to replicate identically what existed on-premise.
This behavior is not always detected immediately and, when it is, it’s often too late: you end up with hundreds of rightsizing recommendations coming from providers (Microsoft Advisor & AWS EC2 Optimizer) to handle (and let’s be honest, rightsizing is one of the hardest FinOps initiatives to implement).
Just because your on-premise infrastructure had 16 CPUs and 128 GB of memory doesn’t mean these specs should automatically apply in the cloud. In reality, your current needs may be very different:
- Maybe your application works perfectly with only 8 CPUs and 64 GB of memory—a setup that was hard to get before but is now available in the cloud.
- Conversely, it might need a lot of memory but little CPU, a setup not really feasible on-premise but easily achievable in the cloud (scalability).
So it’s essential to forget your previous assumptions, analyze your application behaviors, and adapt. The cloud gives you flexibility and scalability. Don’t be afraid to start small and gradually adjust your resources to your actual needs. If you make a mistake, it’s always easy to go back.
My advice: everyone dreams of driving a Porsche 911. But if your daily use comes down to driving 10 km a day, dropping the kids at school, and getting stuck in traffic, a family city car will do the job just fine—for a much lower run & maintenance cost. Before buying the Porsche, make sure it really fits your needs.
Rule 2 : Ensure you have the license to execute your potential
Being responsible for FinOps without the necessary permissions, knowledge or mandate to analyze your scope, the environment and detect anomalies makes no sense .
Every day, you’ll have to investigate, dig, and identify deviations. You must therefore have a role that gives you a complete view of your cloud usage. The scope of this role is just as crucial: a partial view of consumption will inevitably lead to a biased analysis.
My advice: don’t underestimate the importance of your role’s scope. A role that’s too restrictive will limit your effectiveness. Being a FinOps Lead isn’t just about buying reservations or Savings Plans. Even a simple reader role, like a Billing Reader at the enrollment level, can already help identify many anomalies and bring real value.
Rule 3: Stop Chasing Savings
f you were to remember only one rule from this article, it would be this one.
“This year, we need to reduce our consumption by XX M€”
I would like to address a sensitive topic. Today, we have an annual cost reduction target in euros, but from my point of view, we gradually need to move towards another type of objective.
Why? Because over the years, we gain maturity and make progress, and this euro-based objective will become increasingly difficult to achieve. Your euro savings will be disconnected from the actual FinOps maturity of your organization.
To illustrate this, let’s draw a parallel with the human body. Your weight represents the resources deployed, fat represents unused resources, and muscle is your growth. At first, you lose weight quickly. Then comes a stabilization phase where every gram becomes harder to lose. You gain muscle, your weight might even increase, but your body becomes slimmer: you have reached your optimal weight.
It’s the same with the cloud. The first year, gains of -25% to -20% are possible. The second year, -15% is already ambitious. From the third year onward, exceeding 3% optimization becomes difficult, because your consumption is already largely optimized, so savings (in euros) become increasingly rare.
You must then accept that:
- Our consumption is already optimized by actions carried out in previous years (cumulative savings)
- Part of our consumption cannot be optimized (no opportunities)
- Another part will never be optimized (complexity & technical debt)
That’s why you need to let go of this race for savings and replace it with KPIs (Key Performance Indicators) that measure the FinOps maturity of your company (I’ll come back to these KPIs later in this article)
Rule 4: The devil is in the details
Once you have the right permissions, your provider’s portal should become an extension of yourself.
Don’t limit yourself to the Billing or Cost Management sections. Every deployed service generates a cost, often invisible at first glance.
If you have specific contracts like a MACC (Azure) or a PPA (AWS), [vm9] [jh10] analyze them closely: they directly influence your architectural and optimization choices.
My advice: if your strategy is IaaS-oriented, Virtual Machines should become a perfectly mastered area (families, autoscaling, start & stop). But don’t forget the ecosystem around them: disks, backups, replication, capacity reservations… So many cost-generating services that you must understand.
At this point, you’ll understand optimization is no longer just about volumes, but about a deep understanding of usage.
Rule 5: Alone you go fast; together you go far
Cloud cost management is not solely the responsibility of the FinOps team. Even though this team can intervene in an emergency to limit a drift, it never solves the underlying problem.
Cost control concerns all stakeholders: management, finance, IT, Product Owners, developers, architects, Ops, procurement, and users. Without collective involvement, no governance will last over time.
If you wish to improve your Stop&Start strategy for non-production environments, acting alone will require a tremendous amount of energy to achieve your goal, and it will often end in failure. Making a collective decision takes time; you need to raise awareness among each persona about the benefits of this strategy, but once everyone understands it, you will surely reach your objective and no one will question its effectiveness.
My advice: You must talk to everyone. Understanding constraints and decisions often helps identify simple optimizations. Very often, a simple discussion, sharing knowledge, or an awareness session is enough to correct improper usage.
Rule 6: A single line of code can make all the difference
The cost of an application is determined as early as the development phase. Architecture, language, application logic, database queries: every choice has a direct impact on the final bill.
It’s essential to raise developers’ awareness and to test applications in conditions close to production. “It works on my machine” is not a reliable indicator when it comes to performance and costs.
Some queries produce the same functional result but use much more CPU and memory. At scale, this means oversized and costly infrastructures.
Your provider gives you the tools to detect these drifts (most consuming queries, alerts, metrics). You just need to know how to use them.
Rule 7: Integrate FinOps by Design (FinOps Driven Deployment)
Most cost overruns don’t occur in production, but well before the first deployment.
Just like TDD (Test Driven Development) or BDD (Behavior Driven Development), which are engineering practices to improve code quality, why not integrate FinOps rules as soon as resources are deployed? You could imagine blocking the deployment of resources if they don’t meet the expected standards for a given environment.
In many environments, a large share of VMs are for non-production uses. Yet they stay on at night, on weekends, and sometimes have backup or disaster recovery strategies identical to production.
These choices should be questioned as early as the design stage.
My advice: It’s essential to collectively define simple, clear, and scalable rules. For example, by default, every non-production Virtual Machine should be stopped at night and on weekends. A non-production VM running 24/7 should be the exception, not the rule.
When such rules are supported at all levels—architecture, operations teams, and executives—almost all resources naturally comply. All that’s left is to track, measure, and detect real behavioral deviations.
Rule 8: Tools for everyone
FinOps maturity involves the creation of shared tools.
For example, at AXA Group Operations, we are currently building a FinOps Starter Pack: this tool is a repository of queries, scripts, tools, and documentation, all while including the AXA environment. It is intended to be shared internally in a community-based manner, and we invite each entity to contribute to its development.
We have also implemented learning paths by persona and toolkits focused on governance and change management in order to unify the collection of budget, forecast, and pre-closing data.
My advice: if you perform a manual task more than three times, it should be automated. You will save time and make your analyses more reliable.
Rule 9: Avoid technical jargon
Metrics, Savings Plans, SKU, RightSizing, Autoscale, PPA, MACC… These terms are familiar to FinOps experts, but rarely to other stakeholders. If we don’t adapt our message, the audience will be lost and the message you want to convey, although relevant, will not be understood.
A CFO is not interested in the technical details of a Savings Plan, but in keeping within their annual budget. That’s why it’s essential to build KPIs. They must be tailored to each audience and visible to everyone through clear dashboards. The rules for building these KPIs must also be shared so that everyone understands and adopts them.
A practice that works well and helps evolve mindsets is the implementation of a scoring board based on group rules. Take the example of a KPI that shows your coverage rate by savings plans or reservations on your Virtual Machines. If you reach 80%, you get an A grade; if you are below 40%, you are a D. Your annual objective is therefore to reach a C, B, or A.
KPIs are a vast topic, and I will detail what I consider to be the 8 key KPIs for evaluating your maturity in a dedicated article.
My advice: I didn’t want to say too much in rule 3, but these indicators become your compass for measuring FinOps maturity over time—much more relevant than simply measuring euros saved, which, over time, becomes a misleading indicator.
Conclusion
Cloud cost control is neither a purely technical topic nor a problem to delegate to one team. Above all, it’s a matter of culture, shared responsibility, and understanding of usage.
Making costs visible, understandable, and actionable for everyone is the real driver of sustainable performance. When each person understands the impact of their decisions, optimization becomes natural, continuous, and aligned with business goals.
FinOps is not an end, but a way to support growth without losing control. Alone, you can correct a drift. Together, you set a course.
The cloud amplifies your choices. FinOps help you regain control.
My comments are my own and do not reflect the views of the company I work for.
Julien HATZIG. FinOPS Lead for AXA Group Operations
