Cloud cost is a design decision

Almost every cloud bill we are asked to look at was set months before anyone thought about cost. The overspend is not a procurement failure. It is what the architecture does when it meets real traffic.

The four places it usually goes

Storage nobody has a lifecycle policy on. Object storage is cheap enough that nobody prunes it. Then you have four years of database snapshots, per-tenant uploads, debug artefacts and one client's 2019 export, all still being served. The fix is a lifecycle rule, which costs nothing to add and is tedious to retrofit across a large bucket.

Egress, which is the one that surprises people. Data leaving the region is billed separately and often dwarfs the compute beside it. A single misconfigured cache or a chatty internal service turns an affordable architecture into an expensive one. This one shows up in month two and then grows.

Eager everything. A queue consumer that polls at full resolution, a cron that runs hourly to update a number nobody reads, an autoscaler that scales out before the load arrives and never scales back in. Each is individually small. Together they are usually the largest line item.

Log retention at INFO in production, forever. Nobody decides this. A default does it for them.

Why "we will optimise later" does not work

Optimising afterwards is materially harder than getting it right at design time, because the cheap fixes are structural:

• A lifecycle policy has to walk every existing object, not just new ones.
• Egress is set by the topology. Putting a cache in front of something is easy; changing which region a service talks to is a migration.
• Log retention, once set high and queried for months, cannot be lowered without losing the history people now depend on.

Every one of these is a few hours of thought during design and a few days of work after launch. That asymmetry is the whole argument.

What we actually do

On any new build, the cost model is written before the code:

1. What is the unit? Users, jobs, documents, messages. You cannot control a number you are not measuring.
2. What grows with customers, and what does not? Storage and egress almost always do, and they are the two that hurt.
3. What happens at ten times the traffic, and which line items move?
4. What is the first thing we would turn off at 3am, and does anything break?

Question four matters more than it sounds. A system with a documented, safe degradation path is cheaper to run and more resilient than one that cannot be throttled without taking something down.

The bit that is not about money

None of this is cost-cutting for its own sake. A design that writes nothing to disk it does not need, caches sensibly, and can be degraded deliberately is a design that fails better. It survives a traffic spike, a third-party outage, and a client whose usage grows forty times in a quarter.

You get the resilience for free, because the two problems have the same solution.

What we do not do

We do not start with a spend-reduction exercise and a savings target. That optimises the bill and quietly makes the product worse, and nobody notices until an incident.

The starting point is always the same: make the traffic visible, name the unit, and find out which line items are structural. Usually that is enough, and it leaves a system that is better than the one we were handed.