It's because AWS is designed in a such a way that it's very easy to spend a lot, and very difficult to know why.

If you can throw money at the problem and invest engineering resources to do cost optimization later, this is often a valid strategy.

It's often easy to test if scaling the instance size/count resolves a performance issue. If it does, you know you can fix the problem by burning money.

When you have reasonable certainty of the outcome spending money is easier than engineering resources.

And later it's easier for an engineer to justify performance optimizations, if the engineer can point to a lower cloud bill..

I'm not saying it's always a well considered balance, just that burning money temporarily is a valid strategy.

>If you can throw money at the problem and invest engineering resources to do cost optimization later, this is often a valid strategy.

If only AWS had thousands of engineers to create a UX that makes cost info all upfront and easy to budget. Clearly it's beyond their capability /s

>I'm not saying it's always a well considered balance, just that burning money temporarily is a valid strategy.

Yes, but I bet a majority of AWS users don't want that to be the default strategy.