There's a third reason, which I suspect is the biggest. The billing is not real-time, and it's hard to make it even nearly so, especially in such a complex and heavily distributed infrastructure like AWS.
They have realtime insights into how much read/write capacity or IOPS happens on the majority of their services. Their throttling has millisecond resolution. They have no problem giving you realtime insight into when you need to push the magic button to spend more money and increase your write/read capacities. If billing isn't realtime, it's due to sheer laziness or malfeasance (plausible deniability, my guess), because the data is there.
I asked about this a few years ago. The answer I was given by various friends throughout AWS was consistently that of "oh, our customers don't want that" for whatever that's worth.
This is probably technically accurate. After all, I'm sure Amazon, as any business, weights customer voices by the amount of spend. The people spending millions don't want a hard stop (i.e., kill our production services when we hit a certain amount of spend); the only people who want it are the people spending comparatively small amounts, pre-revenue startups, individuals, etc.
This is an example where being data driven to the exclusion of all else can hurt a company; I suspect having this feature would pay dividends down the road (by being the first to provide a safety net for a startup with a fixed budget that doesn't have production workloads yet you offer a competitive advantage between cloud providers), but the effect is completely impossible to predict or track currently since it doesn't have an immediate impact on revenue or the satisfaction of large, paying customers.
Pro-tip: "the data is there" doesn't mean it's cheap to use.
There's a very simple explanation for this; realtime billing would increase the cost of the product they sell to create something most people don't need.
>Besides, if they can trigger alerts at a particular spend then they should be able to create a limit.
That's not really true. The alerts happen when the billing is re-calculated (periodically) and you've exceed a predefined, not when you hit that exact threshold.
>When you enable the monitoring of estimated charges for your AWS account, the estimated charges are calculated and sent several times daily to CloudWatch as metric data.
Real time billing is actually a Hard Problem to solve.
> Real time billing is actually a Hard Problem to solve.
I refuse to believe there is no workaround. I can understand it is not easy to fix for corporations who need AWS to make money but that is not the use case for students.
If it were, Azure for students couldn't exist. Signing up for Azure for students does not require a credit card so they must have figured out a way to prevent / stop the bleeding?
Well stop the service on that periodic cycle then if it’s over the limit?
Non-realtime limits are better than no limits at all. Besides the cloudwatch documentation seems to suggest it’s reporting on a 5 minute frequency for most of AWS.
Billing is very tricky from the metering to the final PDF bill which includes taxes, promotions and whatnot. So this is hard if you want to put limits on a certain dollar amount. You could also put hard stops on resource usage (say, no more than 500 CPU/hr/month)
Besides, AWS already complicates things way too much by handling VAT like other billable items instead of just adding it at the final step like any sane company would
I think the solution would be to allow customers to set hard limits, so they at least have an upper bound on their monthly spend, while still being charged on their actual usage (in a nonrealtime fashion).
This also solves the problem of "what to cut". If I hit my bandwidth limit AWS simply stops routing requests to my servers, if I hit my CPU limit AWS should throttle me, etc.
This feels (no disrespect to you) like a huge cop out. How many more small, "let's hack this together and hope for the best" projects are they missing out on because developers feel uncomfortable with the black box that is AWS billing? I suspect it would be a significant number, believe it or not.