Cloud cost is treated as something you find out rather than something you decide. A system is designed, built, deployed, and the bill arrives with a number nobody predicted. That is avoidable — not to the rupee, but to the order of magnitude, which is the part that matters. And the exercise is worth doing before building rather than after, because the estimate frequently changes the architecture.
The method is to work from a unit of business activity rather than from infrastructure. Pick the thing your system does — an order processed, a document analysed, a user session, a message delivered — and work out what each one consumes: how many requests, how much compute time, how much data written, how much read, how much leaves the network. Then multiply by your expected volume. Doing this on paper takes an afternoon and produces a number you can defend.
The terms that dominate are rarely the ones people watch. Compute is visible and usually modest. Data egress is invisible until the invoice and can exceed compute for anything media-heavy or API-heavy. Storage that accumulates — logs, backups, uploaded files, snapshots with no expiry — grows monotonically and is the reason a bill rises while traffic is flat. Managed service minimums matter enormously at low volume, because a database with a floor price costs the same whether you have ten users or ten thousand.
That floor is the thing to check first for anything new. A serverless architecture with per-request pricing may cost almost nothing at pilot volume and become expensive at scale; a provisioned architecture is the reverse. Which side of the crossover your product sits on is calculable from your own volume estimate, and getting it wrong in either direction is expensive — a startup on provisioned capacity paying for idle machines, or a scaled product on per-request pricing paying a premium on every one.
Estimate three volumes rather than one: the pilot, the plan, and the success case at ten times the plan. That reveals whether the design is affordable if it works, which is a different question from whether it is affordable now. Architectures that are cheap at small scale and ruinous at large scale exist, and they are much easier to avoid at design time than to migrate away from once customers depend on them.
Then instrument against the estimate from the first deploy. Tag every resource with the service it belongs to, and put actual cost per unit of business activity on a dashboard alongside what you predicted. The gap between them is the most useful engineering signal available on cost — it tells you which assumption was wrong while the system is still small enough to change. Teams that never compare actual against estimate learn nothing from either.
