[agiamas]

Admittedly, all of these are real issues. The thing is that for a company with 1.816 trillion (1816 billion!) market cap as of today, all of these issues are easily solvable. But it's not a matter of "we can't solve it" or even "we don't have the resources to do it, there is some higher priority problem to tackle first".

It's not an engineering problem at all at its heart.

It's a marketing/business problem that someone somewhere is thinking that Amazon can provide a free service to X users, knowing that Y (X, Y positive, Y << X) users will go over their "free tier" usage and pay for all X's costs, maybe even more, making the free tier a profitable business on its own.

[staticassertion]

> It's not an engineering problem at all at its heart.

My point is that it is definitely an engineering problem as well as a product problem.

a) It's going to be super technically difficult to build (especially in a way where it's responsive at a granular basis to handle huge blow-up bursts)

b) It's not even clear what you're supposed to be building

None of what people are proposing is well defined or easy to build.

[CuriousNinja]

The type of questions you are mentioning are basically saying different people would need different configuration options and come up every time you design any complex technical feature that is going to be used by millions of people. These are mostly product and UX questions, and NOT engineering ones. The only engineering problem I can think of is the latency in getting real time billing information.

The way you usually solve this is by having sane defaults, and giving users different mechanisms for configuration based on how complex their configuration needs are. This can take a tiered approach.

As an example, simpler and straight forward things (such as disable egress traffic from S3 if the bill exceeds X) can be in the UI itself. Then, for customers who need more control, an option to configure via json or yaml similar to cloud formation. For anyone who needs even more giving an option to call a customer defined lambda function would give them the ability to at any metrics and take appropriate action.

[staticassertion]

> NOT engineering ones

Engineering problems:

1. How do you actually have a billing system reach out to every other system? It has to resolve the resource, network with it, have IAM permissions, a network route, etc.

2. How do you handle consistency?

3. How do you make it responsive?

4. How do you add this to every billable entity?

I mean, it's just a shitload of work, and all of that just to get to a terrible idea.

> The way you usually solve this is by having sane defaults, and giving users different mechanisms for configuration based on how complex their configuration needs are. This can take a tiered approach.

The sane default is you pay for what you use, and you can listen to billing events and build all of the logic you're talking about if you want to.