The requirement that shows up on the bill
Architecture reviews usually look at whether the design is secure, whether it scales and whether it can be operated. Cost turns up afterwards, on the first bill, when changing the design is already expensive. By then the conversation is no longer about architecture, but about cuts.
Treating cost as a requirement means an architecture is not finished until it has an estimate of what it will cost to operate, per component and with its assumptions written down.
Estimating per component
A useful estimate is not a total figure, but a table:
- Each component with its estimated monthly cost.
- The assumptions that determine it: size, hours of use, data volume, region, outbound traffic.
- How it grows with usage: which components scale with users and which are fixed.
- What would be saved with usage commitments, once consumption has stabilised.
The assumptions matter as much as the numbers: when the real bill deviates, they will show exactly what changed.
Why correcting late comes expensive
Changing an architecture decision costs little on the whiteboard and a lot in production. Choosing the wrong kind of database is corrected in minutes during design; in production it requires a migration, a cutover window and risk. The same goes for the region, the network model or the distribution of services.
That is why the cost estimate goes inside the design, next to each decision record, and not in a later report.
How it fits with FinOps
The design estimate is the initial budget. Once the system goes into production, the cost pipeline measures the real spend, allocates it to each component and compares it against the estimate. The difference between estimated and actual is the signal that something in the design or the usage changed, and its explanation becomes the next decision record.
Related: Budget and forecast (FinOps series). How we apply it: Cloud Architecture.