Cutting cloud spend without cutting performance

Most cloud cost reduction advice amounts to "turn things off," which works until it doesn't. The sustainable version requires actually understanding where the spend is going.

The audit that comes before any cost-cutting recommendation

We don't recommend cuts before running a proper cost attribution audit — tagging every resource by team, project, and environment, then analyzing spend against actual utilization metrics (CPU, memory, storage I/O) over a meaningful window, typically 30 days minimum to capture normal usage variance. This consistently surfaces the same handful of patterns: development and staging environments running at production-scale sizing around the clock, orphaned resources (volumes, snapshots, load balancers) left over from decommissioned projects nobody remembered to clean up, and over-provisioned instances sized for a peak load that happens a few hours a month.

The specific levers that cut spend without touching performance

Right-sizing based on actual utilization data, not guesswork — an instance running at 15% average CPU utilization is very likely oversized, and downsizing it has no real performance impact while meaningfully cutting cost. Reserved instances or committed use discounts for genuinely steady-state workloads — the discount for committing to 1-3 years of usage on predictable baseline load is substantial (often 30-50%+) and carries no performance tradeoff at all. Scheduled scaling for non-production environments — auto-shutting down dev and staging environments outside business hours, since almost nobody needs a staging environment running at 2am on a Saturday.

A concrete example with real numbers

For a SaaS client with roughly $34,000 in monthly AWS spend, our audit found: dev/staging environments running 24/7 despite being used roughly 10 hours a day on weekdays only (accounting for about $6,200/month in avoidable spend), a set of EC2 instances averaging under 20% CPU utilization that were candidates for downsizing (roughly $4,100/month in potential savings), and about $1,800/month in orphaned EBS volumes and unused Elastic IPs with no attached resources. Implementing scheduled shutdowns, right-sizing, and cleanup brought monthly spend down to roughly $23,500 — a 31% reduction — with zero measured impact on production performance, because none of the changes touched production-tier resources.

Where cost-cutting does trade off against performance, and how we handle it

Some savings genuinely do involve a tradeoff — spot instances for fault-tolerant batch workloads are much cheaper but can be reclaimed with short notice, which is fine for some workloads and unacceptable for others. We're explicit with clients about which recommendations are free wins (no tradeoff) versus which involve accepting some constraint in exchange for savings, rather than presenting all cost cuts as equally risk-free.

How Ndakum approaches it

Cost optimization is part of our ongoing Cloud Engineering management — we run utilization-based audits, not blanket "turn it off" recommendations.