Cutting cloud spend is easy if you're willing to trade away reliability. The harder — and more useful — problem is cutting cost while your error budget stays flat or improves. Here's what actually moved the needle on a high-traffic e-commerce platform.
Start with data, not intuition
Before touching a single instance size, we spent a week just measuring: CloudWatch metrics, cost allocation tags per service, and request-level tracing to see which paths were actually expensive versus which ones just felt expensive because they were noisy.
Two findings changed our priorities immediately:
- A background worker fleet was provisioned for peak load 24/7, even though peak only happened for about 4 hours a day.
- A handful of endpoints were doing N+1 queries that looked cheap per-request but added up to a large chunk of database CPU at scale.
What actually saved money
- Right-sizing instances based on real utilization, not the defaults we'd inherited. Several services were running on general-purpose instances two sizes larger than they needed.
- Autoscaling background workers on a schedule, instead of running fixed capacity around the clock.
- Fixing the N+1 queries, which reduced database load enough that we could downsize the primary instance tier.
- Moving infrequently accessed assets to cheaper storage tiers, since not everything needs to live on the hot path.
// Before: fixed worker pool, always-on
const workerPool = new WorkerPool({ size: 20 });
// After: scheduled scaling tied to actual traffic patterns
const workerPool = new WorkerPool({
size: getScheduledCapacity(currentHour),
});
The reliability check
None of this matters if it comes at the cost of incidents. We tracked p95/p99 latency and error rate through the whole rollout, and rolled changes out gradually per-service rather than all at once. By the end, latency was flat or slightly better — the N+1 fixes alone bought us some of that back.
Result: a 38% reduction in monthly AWS spend, with no increase in error rate or latency regressions.