Three myths about cloud cost management

This is one of those topics that looks small until it costs you something. A few things about cloud cost management that get repeated more often than they get checked.

The bill is a design document: it tells you exactly what your architecture actually does. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

“It only matters for big sites”

Cloud bills grow quietly until somebody owns them. None of that requires a large budget, only a decision and someone to own it. If it only works because one person remembers to do something, it does not work yet.

“We can deal with it after launch”

Sometimes true, usually expensive. In practice this is a scheduling problem more than a technical one.

“Our platform handles it”

Idle non-production environments are the usual first saving. Getting it slightly wrong is survivable. Ignoring it entirely is not. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

The short version

Cloud work rewards teams who automate early and punishes teams who click through consoles. Three things worth confirming about cloud cost management before you move on:

• Someone can say what the current setup is without going to look
• Tag everything so cost maps to a team or a product — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.