Summary
Give us 30 minutes, and your cloud environment will never look the same again.
We will show you how to identify your biggest savings opportunities and implement a simple FinOps governance framework.
The good news is that reducing your cloud bill does not require a twelve month transformation project or a complete architecture redesign. Seven targeted actions, implementable in less than five business days, can generate between 20% and 40% savings across AWS, Azure, or GCP without impacting service quality or putting production environments at risk.
At Leonys, we work daily with CIOs, CTOs, and teams looking to regain control of their cloud consumption. The observation is almost always the same: the most profitable optimization levers are rarely the most complex ones. They are often well known FinOps quick wins, but they are rarely implemented methodically due to lack of time, governance, or tooling.
This article reviews the seven highest ROI actions, in the order we recommend implementing them. At the end, you will find an FAQ covering the main risks, along with a call to action to download our detailed checklist.
Whether you are looking to reduce your cloud bill before the next quarterly closing, prepare for a FinOps audit, or simply demonstrate tangible results to your finance leadership, this guide is designed to deliver visible impact within seven to ten days of implementation.
Why focus on quick savings instead of a full redesign?
Before getting into the practical steps, let’s set the context. Many companies associate AWS cost optimization, Azure optimization, or GCP cloud optimization with major architecture transformations such as replatforming, serverless migration, or large scale containerization. These initiatives can absolutely be relevant, but they are also expensive, time consuming, and risky. In most environments we audit, however, 60% to 70% of achievable savings do not require any major redesign. They come from better operational hygiene.
A FinOps quick win is based on three criteria: measurable impact above 5% of the cloud bill, implementation in less than one week, and full reversibility. That last point is critical. An action that can be rolled back in two clicks is an action you can test without going through heavy architecture committee approvals.
The seven levers below meet all three criteria. They apply equally well to multi cloud and single provider environments, as well as to SMEs and large enterprises. The only real difference is the absolute amount of savings, while the percentage of savings remains remarkably consistent across different contexts.
Good to know
Most companies can reduce their cloud bill by 20% to 40% without any major technical redesign.
The fastest savings almost always come from the same levers: unused instances, non production environments running continuously, and oversized resources.
The real challenge is not technical complexity, but execution discipline.
1. Identify and shut down idle instances
This is the starting point of any enterprise cloud cost reduction initiative. An idle instance is a virtual machine, container, or managed service consuming billable resources without generating business value. Common examples include test environments forgotten after production releases, abandoned proof of concept instances, machines provisioned for consultants who have left the company, or workloads whose business sponsor changed priorities without informing the operations team.
How do you identify them in practice?
On AWS, combine CloudWatch data such as average CPU usage below < 5% over 14 days and near zero network traffic with your EC2 and RDS inventory. On Azure, use Azure Advisor alongside VM metrics. On GCP, the Recommender section highlights inactive instances. Removing idle cloud instances typically generates 8% to 15% immediate savings.
The golden rule: before permanently deleting anything, create a snapshot and shut it down for 7 days. If nobody reports an issue, you can safely remove it. This “quarantine” approach prevents 95% of unintended side effects.
2. Implement scheduling for non production environments
Are your development, testing, and pre production environments running 24 hours a day, 7 days a week?
In 80% of the environments we review, the answer is yes, even though they are only actively used during business hours, which represents roughly 45 hours per week out of 168. Without proper scheduling for non production environments, nearly 73% of billed compute time on these workloads is wasted.
The technical solution is straightforward: automate the shutdown of non production resources at 8 PM and during weekends, then restart them at 7 AM on weekdays. AWS provides Instance Scheduler, Azure offers Automation Runbooks, and GCP includes Cloud Scheduler. For Kubernetes containers, tools such as KEDA or kube downscaler handle this efficiently.
Typical savings on the affected environments range from 60% to 70%. Across the total cloud bill, this often represents 10% to 18% savings depending on the production to non production ratio. Combined with the first optimization lever, you can already reach around 20% cumulative savings within two days of work.
One commonly overlooked detail: databases and related managed services must be scheduled consistently with application instances. Otherwise, you end up paying for databases running with no applications actually using them.
3. Rightsizing: adjust instance sizes to actual workload demand
Cloud instance rightsizing consists of replacing an m5.4xlarge running at 8% CPU usage with an m5.xlarge that still comfortably handles the workload at a fraction of the cost. It is one of the most profitable and lowest risk FinOps quick wins, provided it is executed methodically.
The three step method:
- First, collect 30 days of CPU, memory, IOPS, and network metrics for each production instance.
- Then identify the instances whose peak usage consistently remains below 40% of their allocated capacity.
- Finally, resize the instances while keeping a 2x safety margin above the observed peak usage.
Native recommendation tools such as AWS Compute Optimizer, Azure Advisor, and GCP Recommender handle around 70% of the work, but their recommendations should always be validated by the application team. Some workloads have bursty usage patterns that are poorly reflected by rolling averages. Ignoring this can lead to performance incidents during financial closing periods or seasonal traffic peaks.
Expected savings from a well executed rightsizing program typically range from 15% to 25% on production compute resources. Once the environment is stabilized, combining this approach with Reserved Instances or Savings Plans can generate an additional 20% to 30% savings on the affected workloads.
4. Optimize storage tiers and storage classes
Storage typically represents between 15% and 30% of a cloud bill, yet it remains one of the most poorly managed cost areas. The reason is simple: cloud storage tier pricing strongly rewards organizations that place the right data in the right storage class, while heavily penalizing the others. By default, however, most data ends up stored in the most expensive tier.
Four actions to implement this week.
- First, enable lifecycle policies on your S3 buckets, Blob Storage, or Cloud Storage environments. Objects that have not been accessed for 30 days can automatically move to an Infrequent Access tier with up to 40% lower costs, and after 90 days to Archive tiers with savings of up to 80%.
- Second, remove unused EBS snapshots, unattached managed disks, and orphaned images. This alone typically generates 3% to 8% direct savings.
- Third, audit your provisioned volumes. A gp3 volume configured with 16,000 provisioned IOPS while real usage never exceeds 3,000 IOPS is simply wasted money, often representing hundreds of euros per month unnecessarily spent.
- Fourth, review your backup retention policies. Keeping daily backups for two years is rarely necessary and always expensive.
This category of actions is one of the most effective ways to reduce cloud costs quickly because it has virtually no visible operational impact. The data remains accessible, with only slightly higher latency for colder storage tiers.
5. Audit logs, metrics, and observability costs
This is probably the most underestimated optimization lever. Logging, metrics, and tracing costs have surged over the past three years with the widespread adoption of observability platforms. CloudWatch, Datadog, New Relic, Splunk, and Elastic all charge for data ingestion, storage, and queries. Without proper governance, observability costs can represent 10% to 20% of the total cloud bill.
Three questions to ask yourself.
What is the ratio between the logs that are actually consulted and the logs being ingested?
If less than 5% of your logs are actually reviewed within 30 days, you are essentially paying for a vault full of data nobody uses.
What is the default retention policy currently configured?
Keeping 90 days of hot storage for your entire application history is rarely justified. In 80% of cases, 14 days in hot storage followed by cold archive storage is more than enough.
Which custom metrics are you sending?
On AWS CloudWatch, each custom metric costs $0.30 per month. Multiply that by 50,000 metrics across a microservices platform, and you are looking at roughly $15,000 per month.
Implement trace sampling, with 10% to 20% generally sufficient for stable production environments, apply ingestion filtering policies for DEBUG logs, and run a quarterly audit of unused dashboards. Typical savings range from 30% to 50% of observability costs, representing around 4% to 10% of the total cloud bill.
6. Reduce data egress costs
Data egress costs are one of the most invisible yet expensive cloud cost drivers. Whenever data leaves the cloud, whether to the internet, another provider, or even between regions of the same provider, every gigabyte is billed between $0.01 and $0.12. At the scale of a platform serving millions of users or running multi region analytics pipelines, those costs increase very quickly.
Four concrete actions.
- First, map your data flows. Where is your data leaving the cloud? Which services are involved? How frequently do transfers occur? Flow log tools such as VPC Flow Logs on AWS, along with their Azure and GCP equivalents, can provide this visibility within a few hours.
- Second, deploy a CDN in front of all static content delivered to external users, using solutions such as Cloudflare, CloudFront, Akamai, or Fastly. Cacheable content no longer leaves your storage directly, which can reduce egress costs by up to ten times.
- Third, group services that exchange large volumes of traffic within the same region and availability zone. An inter availability zone request may cost very little individually, but at 50 million requests per day, the total becomes significant.
- Fourth, negotiate data egress discount programs with your cloud provider, such as AWS Direct Connect or Azure ExpressRoute, if your traffic volumes justify it, typically beyond 50 TB per month.
7. Rationalize environments and reduce multi account sprawl
How many AWS accounts, Azure subscriptions, or GCP projects does your organization currently have? And how many of them are actually necessary?
Cloud sprawl, meaning the uncontrolled multiplication of environments, is one of the silent enemies of FinOps. Every account that is not attached to a centralized governance policy creates opportunities for forgotten instances, suboptimal configurations, and non shared pricing commitments.
This week’s action: inventory all your accounts and subscriptions, identify orphaned environments with no owner, no significant monthly spend, or no recent activity, consolidate the ones that can be grouped together, and share commitments such as Reserved Instances, Savings Plans, or Committed Use Discounts at the organization level rather than per isolated account. On both GCP and AWS, commitment sharing across consolidated accounts is a native capability that is often left disabled simply because teams are unaware of it.
This last action may not generate the most visible savings in absolute numbers, but it lays the foundation for every future optimization effort. Without proper multi account governance, the first six optimization levers will eventually be bypassed within a few months through the creation of yet another “exceptional” environment that never truly remains exceptional.
How do you measure the results after one week?
A cloud cost reduction initiative without rigorous measurement has no real demonstrable value. Before applying any quick win, establish a baseline over the previous seven days, including total cost, cost per service, and cost per environment.
After implementation, wait for 14 full days, representing a complete weekly billing cycle, before comparing results. Present the savings both in absolute value such as euros or dollars and as percentages, while isolating any business volume variations that could distort the analysis.
A simple FinOps dashboard, even one built in Excel to start with, is more than enough. What matters is not the sophistication of the tool, but the consistency of the measurement process.
A FinOps cost reduction checklist applied every month will always outperform a sophisticated dashboard reviewed only twice a year.
Take action this week
You now have the seven most effective levers to start reducing your enterprise cloud bill in less than five days.
The proposed sequence is intentional. Starting with idle instances and environment scheduling delivers visible results within 48 hours, which immediately builds credibility with leadership teams and helps unlock support for the next optimization actions.
One final recommendation: do not try to implement all seven levers in parallel. Apply one per day, measure the results, document the outcomes, and communicate the impact. Over seven days, the cumulative effect consistently delivers better results than launching everything at once, because each action generates learnings that improve the next ones.
Whether you operate on AWS, Azure, GCP, or in a multi cloud environment, and whether your monthly bill is €5,000 or €500,000, these quick wins work.
The question is no longer whether you should do it, but when you will dedicate a week to getting it done.
Get the “7 Quick Wins” Checklist + FinOps Scorecard
To go further and structure your approach, download our free detailed 7 Quick Wins checklist and the Leonys FinOps Scorecard. These two resources provide:
- A day by day action plan with ready to use CLI commands for AWS, Azure, and GCP.
- A FinOps maturity assessment framework covering 12 key dimensions.
- Dashboard templates to track your savings week after week.
- Industry benchmark thresholds to help position and evaluate your performance.
Get the “7 Quick Wins” Checklist + FinOps Scorecard
Would you prefer to speak directly with a Leonys expert to structure your approach?
Book a free 30 minute diagnostic session and leave with an estimated projection of the savings achievable across your environment.
FAQ
The risks do exist, but they are manageable. The main one is the impact on application performance when rightsizing is too aggressive. An instance resized too close to its observed peak usage may struggle during exceptional events such as Black Friday, annual financial closing periods, or unexpected marketing campaigns.
The best way to mitigate this risk is to maintain a 2x safety margin and schedule a monthly review to adjust resources when needed.
The second risk involves deleting idle instances. A service used only once per quarter by the finance team may appear inactive for 89 days and suddenly become critical on the 90th day.
The best safeguard is the quarantine process described earlier, including a systematic snapshot before any permanent deletion.
Finally, be careful with overly aggressive scheduling on shared environments. If the data team runs ETL jobs at 10 PM, shutting down the environment at 8 PM becomes counterproductive.
The rule is simple: build the scheduling strategy together with the actual users of the environment, never impose it solely from the platform team. A proper cloud cost audit will systematically help identify these dependencies.
The yo yo effect is one of the classic traps of reactive FinOps initiatives. Costs are reduced in April, attention shifts to other priorities in May, and by July the cloud bill is back to its original level, sometimes even higher.
The root cause is simple: no structural mechanisms were implemented to prevent waste from reappearing.
Three effective safeguards.
- First, enforce a strict tagging policy for every new resource. Any resource created without tags for owner, environment, and cost center should automatically be rejected by the infrastructure pipeline.
- Second, implement budgets and alerts by project or team. As soon as a budget line exceeds 80% of its allocated threshold, the responsible owner should automatically be notified.
- Finally, establish a 30 minute monthly FinOps review ritual that systematically reapplies the cloud cost reduction checklist.
These three mechanisms require very little effort to implement, usually just a few man days, yet they help stabilize savings over the long term. Without them, you may achieve a short term cost reduction, but not a real operational transformation.
