Earlier quoted context omitted.
Sorry, I think I misunderstood what you were saying there. Could you clarify a bit more about what kind of functionality you'd prefer we support in the scenario you described? A large influx of traffic hits your application while you are unavailable to handle it. If you do not have autoscaling enabled, your application performance could suffer, if you do have it enabled your bill could grow out of bounds. We do plan…
We do plan to let you set min and max bounds for autoscaling once it is implemented. This is exactly the sort of thing I'm talking about, but for money rather than computing resources or bandwidth. I'd like a feature that where the requirement is effectively "Fall back to a serving sorry-I'm-poor.html instead of the app if the total monthly bill has exceeded $xxx". For a side project I'm more interested in not paying…
I think for most companies, it's better to set the expectation that the service costs money, bursts will cost more money, and then forgive outlier charges once or twice. It's tremendously difficult to compete against the AWS's of the world, putting work into features specifically to minimize how much people spend seems like a good way to fail a company.