Bleeding OpEx? The Pragmatic Guide to Cloud Cost Control in 2022

The promise of the cloud was simple: "Pay only for what you use."

The reality in 2022? You are paying for zombie instances, unattached storage volumes, and egress bandwidth that costs more than the compute itself. I recently audited a mid-sized SaaS company in Oslo. They were burning 40,000 NOK monthly on "dev" environments that no one had logged into since November 2021. That is not overhead; that is negligence.

With electricity prices in Southern Norway (NO1/NO2) hitting record highs this winter, efficiency isn't just a DevOps concern—it's a CFO mandate. Let's cut the fluff and look at how to stop the financial bleeding without sacrificing the latency required for the Nordic market.

1. The "Zombie" Infrastructure Audit

Hyperscalers love it when you spin up a resource and forget it. The first step in any cost optimization strategy is identifying resources with near-zero utilization. If you are running Linux, don't guess. Measure.

We often assume a server is "busy" because it's running. But if your Load Average on a 4-core system is consistently 0.05, you are paying for premium air.

Identifying Idle CPU via CLI

Use sysstat tools to look at historical data, not just the current moment. If you haven't installed sysstat, do it now.

# Install sysstat (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install sysstat -y

# Check CPU utilization history for the current day
sar -u

If your %idle is consistently above 95% over a 30-day period, you are over-provisioned. In a Kubernetes environment, you can query Prometheus to find pods that are requesting way more CPU than they use. Here is a PromQL query for your Grafana dashboard:

sum(rate(container_cpu_usage_seconds_total{container!=""}[5m])) by (pod) 
/ 
sum(kube_pod_container_resource_requests_cpu_cores) by (pod) 
* 100

Pro Tip: Development environments do not need to run 24/7. Use a simple cron job or a CI/CD pipeline hook to shut down non-production VDS instances at 18:00 CET and wake them up at 07:00 CET. That alone cuts compute costs by ~60%.

2. The Storage Trap: IOPS and Orphans

Storage billing is insidious. You often pay separately for capacity, IOPS (Input/Output Operations Per Second), and throughput. A common mistake is using a generic HDD volume for a database, realizing it's too slow, upgrading to an SSD, and forgetting to delete the old volume.

Furthermore, many providers cap your IOPS based on volume size. To get high speed, you're forced to buy 1TB of space you don't need. This is where the architecture of CoolVDS differs significantly. By standardizing on local NVMe storage without artificial IOPS throttling, you avoid the "capacity-for-performance" tax.

Finding Large, Old Log Files

Before you expand storage, clean up what you have. Log rotation is often misconfigured.

# Find files larger than 500MB modified more than 30 days ago
find /var/log -type f -size +500M -mtime +30 -exec ls -lh {} \;

# Truncate a massive log file without breaking the file handle (better than rm)
: > /var/log/nginx/access.log

3. The Egress Bandwidth Shock

Data ingress (coming in) is usually free. Data egress (going out) is where the markup is 300% or more. If you serve media or heavy JSON payloads to users in Bergen or Trondheim from a server in Frankfurt, you are paying a premium for transit.

Hosting in Norway isn't just about lower latency (though sub-5ms ping to Oslo is nice); it's about avoiding cross-border transit fees. Ensure your provider peers directly at NIX (Norwegian Internet Exchange). If your traffic stays local, your costs drop, and your throughput improves.

Nginx Gzip Configuration

The cheapest bandwidth is the bandwidth you don't use. Ensure compression is aggressive. In your nginx.conf:

gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
gzip_min_length 256;

4. The Hidden Cost of Compliance (Schrems II)

Cost isn't just the monthly invoice; it's the Total Cost of Ownership (TCO), which includes legal risk. Since the Schrems II ruling in 2020, relying on US-owned hyperscalers involves complex Standard Contractual Clauses (SCCs) and Transfer Impact Assessments (TIAs). Datatilsynet (The Norwegian Data Protection Authority) has been clear: you are responsible for where your data lives.

If you have to hire legal consultants to justify your hosting architecture, you have already failed at cost optimization. Choosing a purely European provider like CoolVDS removes the transatlantic transfer headache entirely. Your data stays under EEA jurisdiction. Zero legal overhead.

5. Database Optimization: Stop Throwing RAM at Bad Queries

I've seen it a dozen times: a MySQL server crashes, so the admin doubles the RAM. The server crashes again a week later. The problem isn't RAM; it's unoptimized queries doing full table scans.

Enable the slow query log to identify the actual culprits before upgrading your plan.

# In /etc/mysql/my.cnf or /etc/my.cnf
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 2
log_queries_not_using_indexes = 1

Once you identify the bad queries, use EXPLAIN to optimize them. Often, a single index change can save you from upgrading to a 64GB RAM instance.

Summary: Predictability is King

Variable billing models are great for startups with zero traffic. They are terrible for scaling businesses. The unpredictability forces you to keep cash reserves for "bad months" where traffic spikes.

For high-performance workloads, the math implies a shift back to predictable Virtual Dedicated Servers. You get raw NVMe performance and dedicated KVM resources without the "noisy neighbor" effect common in container-heavy public clouds.

Stop paying for the brand name on the invoice. Pay for the cycles you actually use. Deploy a high-performance, cost-controlled instance on CoolVDS today and see the difference a dedicated architecture makes to your bottom line.