Jessica A.,
Too Long; Didn't Read
The cloud should be cheaper than on-premise. Often it isn't—because resources are running that nobody needs anymore, instances are over-dimensioned, and no one truly understands the bill. With a few targeted measures, you can save 20-40%. And quite quickly.
"Why are we paying 50,000 francs per month for... what exactly?"
That’s the question that comes up sooner or later. From the CFO. Or from the CEO. Or from someone who is looking at the cloud bill for the first time in a meaningful way.
And then you’re standing there. And the honest answer is often: "Good question."
(Don’t worry. You’re not alone. We see this all the time.)
Why cloud costs get out of control
Cloud makes it ridiculously easy to scale resources up. A few clicks, a Terraform script — boom, 50 new instances.
Scaling down? That’s easy to forget.
Or the developer who created the instance is on vacation. Or has quit. Or no longer remembers what it was for.
And so the zombies pile up. Instances that keep running. Volumes nobody needs. Snapshots from two years ago. All costing money. Every month. Automatically.
Studies show: On average, 30% of cloud spending is pure waste. Not "something that could be optimized" — but money spent on things that benefit no one.
The good news? You can recover that.
7 strategies that really work
Here are the measures that deliver the fastest results for our customers. Sorted from "you can start tomorrow" to "you’ll need a bit of lead time".
1. Find and kill zombie resources
What: Identify and delete all unused cloud resources.
Why it works: 10-20% of your resources are probably running without any real usage. Just... forgotten.
How much you save: 10-25% of total costs. Immediately.
What you should do:
EC2/VM instances with <5% CPU over 30 days? Candidates.
Volumes without an attachment? Get rid of them.
Snapshots older than 90 days? Still really needed?
Dev/Test environments running 24/7? Turn them off at night.
A Swiss fintech we worked with saved 18,000 francs per month just by hunting zombies. Implemented in two weeks.
(The CTO was... surprised. And a little embarrassed.)
2. Right-sizing: align resources with reality
What: Reduce instances to match actual usage.
Why it works: Most resources are over-provisioned. "Better too big than too small" gets expensive.
How much you save: 15-30% on compute costs.
What you should do:
Analyze CPU, memory, and disk over 30 days
Instances with average utilization <40%? Candidates for downsizing
Test in non-prod, then roll out to prod
Caution: Don’t look only at averages. Peak load still has to work. And some workloads need headroom.
AWS Compute Optimizer and Azure Advisor give you recommendations directly. Free of charge. Use that as a starting point.
3. Reserved Instances for stable workloads
What: Commit to 1-3 years and receive a 40-60% discount.
Why it works: For workloads that run 24/7 anyway, pay-as-you-go is simply expensive.
How much you save: 40-60% on the affected instances.
What you should do:
Production databases, core services — everything that runs continuously
Analyze at least 6 months of historical usage
Buy RIs for about 70-80% of the baseline (not 100% — keep flexibility)
Caution: RIs are a commitment. If you no longer need the instance, you still pay for it. So start conservatively.
4. Spot Instances for flexible workloads
What: Use spare cloud capacity at a 70-90% discount.
Why it works: Cloud providers have excess capacity. You can use it cheaply — but they can take it away at any time.
How much you save: 70-90% on suitable workloads.
Suitable for:
Batch processing
Data analytics
CI/CD build jobs
Machine learning training
Dev/Test environments
Not suitable for: Anything that cannot be interrupted. Production databases? No.
Many CI/CD systems (GitLab, Jenkins) natively support Spot Instances. That’s an easy win.
5. Automatically shut down Dev/Test
What: Shut down development and test environments at night and on weekends.
Why it works: Your developers don’t work 24/7 (hopefully). So why should the instances?
How much you save: 60-70% on Dev/Test costs.
What you should do:
Scheduled scaling: up at 08:00, down at 18:00
Weekends completely off
Exceptions only on explicit request
A retail company we work with saved 12,000 francs per month this way. The developers didn’t even notice.
(Okay, one complained. But he also worked at 3 a.m. That’s a different problem.)
6. Tagging: know what costs what
What: Tag all resources with Owner, Project, Environment.
Why it works: You can only optimize what you can measure. Without tags, you don’t know who is causing what.
How much you save: Directly: 0%. But it enables everything else.
What you should do:
Define a tagging standard (Owner, Project, Environment, Cost Center)
Enforce policies (no resource without tags)
Report costs by tags
Without tagging, FinOps is almost impossible. That is the foundation. Invest time here.
7. Establish monthly cost reviews
What: Review costs regularly — not just when things are on fire.
Why it works: Cloud usage changes. Once optimized, it is outdated after 6 months.
How much you save: Preserves the other savings over the long term.
What you should do:
Monthly 30-60 minute meeting (Finance + IT + key teams)
Review top 10 cost drivers
Identify new anomalies
Define quick wins for next month
The ritual dies if nobody champions it. The CFO or CTO has to want it.
More on this in our article You pay for 100 licenses, but only 40 are used.
The order that works
You don’t have to do everything at once. Here is the order we recommend:
Week 1-2: Kill zombie resources, set up Dev/Test shutdown
→ First savings, no risk
Week 3-4: Right-size the obvious cases
→ More savings, low risk
Month 2: Introduce tagging, Reserved Instances for stable workloads
→ Foundation for long-term optimization
Month 3+: Establish monthly reviews, Spot Instances where useful
→ Continuous improvement
The most common mistake
The biggest mistake we see: Optimize once and then forget it.
You do a project. Save 30%. Celebrate. Move on to the next topic.
Two years later: costs are back at the old level. Or higher.
Why? Because cloud usage is not static. New features, new teams, new workloads. Waste comes back. Automatically.
FinOps is not a project. It is a process. Like fitness. You don’t go to the gym once and stay fit forever.
(That would be nice. But it doesn’t work that way.)
What you can do this week
Pull the last 6 months of cloud bills — Look at the trend. Is it rising? Why?
List 5 resources you suspect — The instance that was set up "just quickly." The test environment from 2 years ago.
Ask the owners — "Do you still need this?" The answer is more often "no" than you think.
Calculate the impact — 20% of your monthly cloud bill. That is realistic savings potential. Is it worth it?
The point
Cloud cost optimization is not rocket science. Most savings come from obvious things: resources nobody needs. Instances that are too big. Dev environments running at night.
The hard part is not the technology. It is the discipline to look at it regularly.
The companies that have their cloud costs under control are not the ones with the best tools. They are the ones that invest 30 minutes every month to review them.
That sounds unsexy. It is. But it works.
