Stop Bleeding Budget: The Pragmatic Guide to Cloud Cost Optimization in 2020

The Cloud Promise vs. The Billing Reality

It is May 2020. The narrative for the last five years has been relentless: "Move everything to the cloud. It scales infinitely. You only pay for what you use."

If you are reading this, you likely know the uncomfortable truth that follows. You aren't paying for what you use. You are paying for what you provisioned, what you forgot to turn off, and for every gigabyte of data that dares to leave the data center. I have audited infrastructure for three major Oslo-based fintechs this quarter. The pattern is identical: massive over-provisioning on Hyperscalers (AWS, Azure, GCP) to mask poor application performance.

We need to return to engineering sanity. Cost optimization isn't just about accounting; it is a systems architecture discipline. It requires looking at CPU steal time, understanding storage I/O blending, and realizing when a predictable monthly invoice beats an elastic credit card drain.

1. Identify and Kill Zombie Resources

The first step is ruthless cleanup. In a recent audit, we found a Kubernetes cluster running 40% of its pods in a loop of crashing and restarting. The bill didn't care that the app wasn't working; the compute was reserved.

Before you scale up, scale down. Use standard Linux tools to find idle processes consuming memory.

# Check for processes consuming memory but low CPU (potential leaks or zombies)
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head -10

If you are running Docker, do not let containers run wild. In 2020, running a container without limits is negligence. If a Java application decides to eat the heap, the OOM killer might take down your SSH daemon instead of the container if you aren't careful.

Hard limits are mandatory:

docker run -d --name analytics-worker \
  --memory="1g" \
  --memory-swap="1g" \
  --cpus="1.5" \
  coolvds/data-processor:v2

By enforcing these constraints, you force developers to optimize code rather than simply throwing more expensive RAM at the problem.

2. The "Egress" Trap and Local Peering

Data ingress is usually free. Data egress is where the hyperscalers extract their margin. If you serve heavy media assets or large datasets to users in Norway, serving them from a data center in Frankfurt or Ireland is technically inefficient and financially punishing.

The Latency Equation:

• Oslo to Frankfurt (AWS): ~25-30ms
• Oslo to NIX (Norwegian Internet Exchange): ~1-3ms

For a high-traffic e-commerce site, that latency adds up during the TCP handshake and TLS termination. But the cost is the real killer. Moving 10TB of traffic out of a major cloud provider can cost hundreds of dollars. On a provider like CoolVDS, which peers directly at NIX, bandwidth is often bundled or significantly cheaper.

Pro Tip: If you are hosting static assets, offload them. But for the core application logic and database, keep them close to your users. A VPS in Oslo doesn't just lower latency; it removes the unpredictability of bandwidth billing.

3. Database Tuning: The Alternative to "Upsizing"

The knee-jerk reaction to a slow database is upgrading the instance type. This is expensive and often unnecessary. Most performance issues in 2020 stem from disk I/O bottlenecks or poor buffer configuration.

If you are using MySQL or MariaDB 10.4, your innodb_buffer_pool_size should hold your "hot" data. If your dataset is 4GB and you have 8GB RAM, allocate 5-6GB to the pool. Do not leave it at the default.

Optimize my.cnf before paying for more cores:

[mysqld]
# 70-80% of Total RAM for Dedicated DB Server
innodb_buffer_pool_size = 6G 

# Independent flush thread for NVMe storage (Essential for high IOPS)
innodb_flush_neighbors = 0 
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000

# Durability vs Performance trade-off (Set to 2 for non-critical logs)
innodb_flush_log_at_trx_commit = 1 

Note the innodb_flush_neighbors = 0. This setting is crucial for NVMe storage. Old spinning rust (HDD) needed neighbor flushing to optimize head movement. On modern NVMe drives—standard with CoolVDS instances—this is overhead. Turn it off to reduce latency.

4. Storage I/O: The Hidden Bottleneck

Cloud providers often throttle IOPS (Input/Output Operations Per Second) based on disk size. To get high speed, you are forced to provision a 1TB drive even if you only need 50GB of space. This is an artificial cost floor.

This is where specialized VPS providers shine. We architect CoolVDS using local NVMe arrays. We don't throttle IOPS to force upgrades because the hardware can handle it. You get raw throughput without the storage tax.

Test your current disk speed. If you are getting less than 400MB/s on a "Premium" SSD plan, you are being throttled.

# Test write speed with dd (careful on production!)
dd if=/dev/zero of=testfile bs=1G count=1 oflag=direct

# Real-world benchmark using fio (The industry standard)
fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=1 --size=512M --numjobs=2 --runtime=240 --group_reporting

5. The Hybrid Approach: Predictability Wins

The "Pragmatic CTO" doesn't run everything on a VPS, nor everything on Lambda. We use a hybrid model.

Conclusion

Cost optimization in 2020 is about matching the workload to the infrastructure. Public cloud is excellent for elasticity, but it charges a premium for it. For your core, predictable, always-on workloads—your databases, your backend APIs, your internal tools—the math favors high-performance VPS.

When you deploy on CoolVDS, you aren't just getting a server. You are getting a predictable invoice, NIX-peered low latency, and hardware that doesn't throttle your success. Stop paying the "laziness tax" of default cloud configs.

Ready to audit your infrastructure? Start by benchmarking your current I/O against a CoolVDS NVMe instance. You might be surprised at what you are paying for versus what you are actually getting.