I am going to go out on a limb and guess that this is almost entirely down to your finance department attempting to understand and control the monthly cloud spend. This is obviously fine, but rather than "oh, another 2xlarge, we have to add a couple hundred bucks to our budget" the reverse should be true; you have $x to spend per month on average with a reasonable growth plan built in.

In the build and test example, the answer to "how much compute is running?" is based off developer velocity and so "it depends" is a fair answer. When nobody is shipping any builds, your cost should be $0. (I've found that this is kind of hard for enterprise-y finance departments to wrap their heads around and is why all those esoteric billing notifications AWS services even exist)

Pre-cloud services days, finance departments had a much easier time. You had racks of physical boxes that had static costs attached to them, you had a static monthly bandwidth bill that let you run at a certain speed, and you had salary costs which are also pretty static month-to-month. The idea of "scale to 0" was completely unheard of. What do you mean your QA environment doesn't cost anything on the weekends when nobody's doing anything? etc etc etc, you get my point.