Cloud Cost Optimisation: How We Helped a SaaS Company Reduce Cloud Spend by 35%

A small SaaS company with around 50 employees approached us with a concern that had begun to surface in budget discussions. Their product was stable, usage was growing steadily, but cloud costs were no longer behaving predictably.

Monthly infrastructure spend was roughly €10,000. It wasn’t extreme, but it was drifting upward without a clear explanation. For a company of their size, even a few thousand euros of inefficiency per month was becoming noticeable.

The engineering team suspected there was some waste in the system, but there was no clear breakdown of where it was coming from.

The first step was to turn billing data into something that could actually be reasoned about.

Once we aligned cloud cost data with infrastructure usage (mainly Kubernetes metrics and resource allocation patterns), a clearer picture emerged. Roughly 30–40% of monthly spend was not directly tied to active production demand. That didn’t mean the infrastructure was broken. It meant it had grown organically without strict cost controls.

The main contributors were fairly typical:

• Development and staging environments run continuously, even when not used

• Kubernetes workloads are configured for peak capacity rather than average load

• Storage resources that were never cleaned up after deployments

• Conservative database sizing that didn’t reflect actual usage patterns

Individually, these were small inefficiencies. Together, they formed a stable layer of unnecessary baseline cost.

We focused on changes that reduced waste without introducing complexity or risk.

The first improvement came from scheduling non-production environments. Instead of running 24/7, staging and development systems were automatically shut down outside working hours. This immediately removed a noticeable portion of idle spend.

Next, we adjusted Kubernetes resource requests and autoscaling behaviour. Many services were overprovisioned by default, which made sense earlier in the company’s growth but no longer matched real usage. By reducing baseline allocations and allowing better scaling behaviour, compute usage became significantly more efficient.

We also cleaned up storage usage. Unused volumes and orphaned snapshots were removed, and lifecycle policies were introduced so older data automatically moved to cheaper storage tiers instead of remaining in high-cost storage indefinitely.

Finally, we introduced basic cost visibility per team. Not heavy FinOps processes, just clear feedback loops so engineers could see how their services contributed to total spend.

Within about six weeks, total cloud spend dropped by approximately 30–40%, while performance and reliability remained unchanged.

In practical terms, monthly costs moved from around** €10,000 to roughly €6,000–€7,000** depending on usage patterns.

That translated into a stable and sustained reduction in cloud spend, achieved without architectural changes or new infrastructure platforms—just better alignment between usage and provisioning.

The most important shift wasn’t technical. It was in how decisions were made. Before the optimisation work, cost was something that appeared at the end of the month. Afterwards, it became part of engineering discussions. Teams started questioning defaults like always-on environments and static provisioning, because they could now see the impact directly. Cloud spend stopped being a separate concern and became part of normal engineering trade-offs.

Most cloud cost problems are not caused by one bad decision. They usually emerge gradually—small infrastructure choices made during growth that never get revisited. Teams optimise for speed, reliability, and delivery pressure. Cost efficiency often becomes something to “look at later.”

In practice, meaningful savings rarely come from dramatic infrastructure rewrites. More often, they come from understanding how systems are actually used and removing the gap between real demand and assumed demand.

At ZEN Software, we help companies make their cloud environments easier to understand, operate, and scale. Sometimes that means improving architecture. Sometimes it means identifying where money quietly leaks through inefficient defaults. Usually, it is a combination of both.

If your cloud bill feels larger than it should—or harder to explain than expected—it is often worth taking a closer look before costs become part of the problem.