Cutting VM cloud costs in seven steps

Over-provisioned virtual machines are one of the largest sources of cloud waste. The Flexera 2025 State of the Cloud report finds that 59% of organisations now run a dedicated FinOps team, which says something about how structural the problem has become. For Swiss IT leaders and cloud engineers, right-sizing VMs is no longer an optional tidy-up but a measurable financial lever.

This article sets out seven concrete steps to detect over-provisioning, match resources to actual usage, and keep the bill down over time.

Quick guide: the seven steps

1. Audit current VM resource usage: collect CPU, RAM and storage metrics over at least 30 days.
2. Identify the over-provisioned VMs: find instances running below 20% of allocated resources.
3. Set thresholds per workload type: calibrate vCPU/RAM ratios by profile, compute, memory or general.
4. Resize outside production first: apply the new sizes to test environments before production.
5. Roll out to production in phases: migrate in batches, inside maintenance windows.
6. Automate monitoring and alerts: catch consumption drift continuously.
7. Run a periodic review: a quarterly cycle keeps resources aligned with usage.

Matching resources to usage

1. Audit current usage

Start by collecting CPU, RAM and disk I/O metrics over at least 30 days. That window captures the cyclical variation: month-end peaks, overnight batches, quiet periods.

Monitoring tools such as Grafana or VictoriaMetrics aggregate the data per instance and per project. The aim is a factual baseline for the gap between what is allocated and what is consumed.

Without that visibility there is no way to tell structural over-provisioning from a one-off peak.

2. Identify the over-provisioned VMs

The symptom: a VM holds 8 vCPU and 32 GB of RAM while average use stays below 15% of CPU and 25% of memory. Billing follows what is allocated, not what is consumed.

Three categories make the sorting easier: over-provisioned below 20% average use, correctly sized between 40 and 70%, under-provisioned with regular peaks above 85%. The classification rests on the data gathered in the previous step.

Instances below 20% over 30 days are the priority. Concentrating on that segment is what makes the exercise pay.

3. Set thresholds per workload type

Each workload calls for its own vCPU/RAM ratio, and the three Hikube instance families are built on those ratios. CPU-intensive work such as CI/CD and compilation maps to the s1 family at 1:2. General applications, APIs and web services map to u1 at 1:4. Databases and caches map to m1 at 1:8, memory first.

Setting the thresholds before resizing avoids two common failures: cutting too aggressively and degrading performance, or keeping generous margins out of caution and recreating the problem.

Document the target thresholds per category and validate them with the application teams. It takes two to four hours depending on the size of the estate, and everything that follows depends on it.

4. Resize outside production first

Applying the new sizes to development and staging measures the effect on application performance without putting production at risk.

On Hikube cloud instances, moving from a u1.2xlarge at 8 vCPU and 32 GB to a u1.xlarge at 4 vCPU and 16 GB halves the billed resources, for workloads whose real usage justifies it. The catalogue runs from s1.small to m1.8xlarge, and the prices are published.

Then run the usual load and functional tests against the resized instances. If latency and throughput stay within acceptable bounds, the configuration is validated.

5. Roll out to production in phases

Work in batches of 10 to 20% of the estate. Schedule migrations inside your own maintenance windows and watch application metrics for 48 to 72 hours after each batch.

The graduated approach limits exposure. If something misbehaves after a batch, the rollback covers a subset of the estate rather than all of it.

Observed order of magnitude: two to five days of implementation effort for a 20 to 40% cut in the monthly bill, depending on how over-provisioned the estate was. The first effects show up in the next billing cycle.

6. Automate monitoring and alerts

Real-time monitoring is what stops the drift returning once the work is done. Two thresholds are enough: average CPU below 15% over seven days, which flags over-provisioning, and above 85% over seven days, which flags the opposite.

The stack that deploys inside the tenant, Grafana with VictoriaMetrics and VictoriaLogs, creates those alerts with per-project and per-environment thresholds. Wiring them to a notification channel is what turns an alert into a response time. The monitoring documentation covers the setup.

Without it, over-provisioning comes back within three to six months: teams size new VMs on cautious estimates, and the gap reopens.

7. Run a periodic review

A quarterly review of allocations turns right-sizing into a standing practice rather than a one-off project. Each review compares current usage against the thresholds from step 3 and surfaces the new candidates.

Folding it into the budget process makes the savings quantifiable and the tooling justifiable. The 36-month TCO calculator gives the frame, and the article on comparative TCO sets out the method.

Budget four to eight hours per cycle. Without a regular review, over-provisioning returns to its original level within six to twelve months.

What over-provisioning actually costs

The direct cost is the billing of allocated but unused resources. It commonly represents 20 to 40% of the cloud budget, depending on FinOps maturity. The Flexera 2025 State of the Cloud report shows that workload growth mechanically amplifies the waste each year.

The indirect cost is less visible: instance types multiply, billing becomes opaque, spending gets hard to forecast. For a Swiss company under nFADP, GDPR or FINMA obligations, a badly sized estate also complicates infrastructure audits. The jurisdiction side is covered in the article on sovereign cloud.

Manual or automated right-sizing

Manual suits estates under 50 VMs with stable load profiles: metric exports, a tracking sheet, documented decisions. The benefit is control over every call.

Automated becomes worthwhile beyond 100 VMs, or when profiles shift often. FinOps tools analyse trends and produce recommendations with a stated confidence level.

The hybrid approach is the pragmatic one: automate detection and recommendation, keep a human validation before production. Only the application teams hold the context the tool lacks.

What Hikube brings to this

The three instance families are calibrated on explicit vCPU/RAM ratios, s1 at 1:2, u1 at 1:4, m1 at 1:8. Resizing is therefore a matter of picking the size that matches the real load profile, not of negotiating a discount.

The monitoring stack that deploys in each tenant gives visibility per project and per environment, with no third-party tool to integrate.

Usage-based billing means every resize translates straight into a reduction, with no minimum commitment and no change penalty. Data stays in Switzerland, across three independent datacentres in Geneva, Gland and Lucerne.

To frame a sizing audit, an engineer answers within 24 business hours.

Frequently asked questions

What savings should I expect

Organisations running a structured programme see 20 to 40% off the monthly bill. The scale depends entirely on how over-provisioned the estate was to begin with: an already-tight estate will release nothing.

How often should sizing be reassessed

A quarterly cycle suits most organisations. Monitoring dashboards keep the gap between allocated and consumed resources visible at all times, so obvious cases can be handled without waiting for the review.

Can right-sizing degrade performance

Yes, if the sizing is wrong. That is exactly what the non-production validation in step 4 and the batched migration in step 5 are for. A size change takes effect when the instance restarts, and you choose when that happens: no window is imposed on you.

Which tools detect over-provisioning

Grafana and VictoriaMetrics cover metric collection and alerting, and deploy inside the tenant. For containerised workloads, a per-namespace cost tool adds visibility on managed Kubernetes.

Is right-sizing worth it on a small estate

An estate of 10 to 50 VMs sees a measurable return within two to four weeks. The granularity of the catalogue, from s1.small to m1.8xlarge, allows fine adjustment even on a small infrastructure.