Shovel cash into the furnace that is AWS/Azure. It’s fine.
For a while at least.
Don’t do cost optimisation Link to heading
I encourage early stage tech companies to not even think about their AWS/Azure bill until it reaches $10k/y. At that point, it wants a timeboxed 1 hour sanity check, with perhaps a few hours of tightening up unused services, then don’t look again until it reaches $20k.
I don’t generally advocate that startups actively burn a material slice of their limited cash on cloud infrastructure services, but it’s more acceptable than the typical engineer thinks.
Well, do it, but only occasionally Link to heading
For early-stage, high growth companies the primary goal is always iterating the product until reaching product-market fit, and spending time on cost optimisation is diametrically opposed to this goal.
Your roadmap will thank you Link to heading
Why? It’s almost certain that there’s only one engineer who knows enough about the product’s underlying infrastructure to safely do cost optimisation. It’s certain this tech is also currently the blocker for the eight next highest value product feature experiments.
By saving $400/m in tweaks, you’re often costing days, sometimes weeks of critical path focus from some of the most resource-constrained people in the company – a pretty wild net loss.
Having said that, don’t completely ignore it Link to heading
The flip side of this is when you leave it for years, like the session I just came out of with a clients’ engineers, where our findings were ~2 days of tuning work that will shave ~60% off their 6-figure AWS bill.
As always, it’s complicated, and the real value resides somewhere in the middle – but the easy rule you can apply as a senior engineer is kinda like what your mechanic would suggest as a servicing schedule for your car:
1 hour every 6 months or $10k annualised spend increase, whichever comes first.