Cloud architecture should survive the second budget cycle.
The second budget cycle is the real test
Every cloud migration gets approved once. A business case is written, a transformation budget is allocated, and the work begins. The architecture looks clean on the whiteboard.
Twelve months later, finance opens the invoice dashboard. The questions start.
Why cloud costs surprise people
The first budget cycle funds the migration. The second budget cycle funds operations. These are fundamentally different cost profiles:
- Migration costs are project-shaped: bounded, one-time, with a clear end date
- Operational costs are utility-shaped: recurring, variable, and sensitive to usage patterns nobody predicted
The architecture that was "cost-effective" during migration may be expensive at steady state. Oversized instances, orphaned storage, and unoptimized data transfer add up quietly.
Design for the CFO's questions
A durable cloud architecture answers these questions without heroic investigation:
- What does each workload cost per month?
- Which costs are fixed and which scale with usage?
- What happens to the bill if traffic doubles?
- Where is the waste — and is it intentional (resilience) or accidental?
Theory of constraints in cloud economics
Every cloud environment has one bottleneck that dominates cost. Finding and addressing that single constraint delivers more savings than optimizing everything else combined.
The boring cloud stack wins here too
Postgres, object storage, queues, and plain HTTP are not just technically reliable — they are financially predictable. Exotic managed services often have pricing models that look reasonable at small scale and become expensive at production volume.
Good architecture is not the cheapest architecture. It is the architecture that still makes sense after finance has looked at a year of invoices.