This might be speaking the obvious, but I think that the lack of half-decent cost controls is not intentionally malicious. There is no mustache-twirling villain who has a great idea on how to !@#$ people out of their money. I think it's the play between incompetence and having absolutely no incentive to do anything about it (which is still a form of malice).
I've used AWS for about 10 years and am by no means an expert, but I've seen all kinds of ugly cracks and discontinuities in design and operation among the services. AWS has felt like a handful of very good ideas, designed, built, and maintained by completely separate teams, littered by a whole ton of "I need my promotion to VP" bad ideas that build on top of the good ones in increasingly hacky ways.
And in any sufficiently large tech orgnization, there won't be anyone at a level of power who can rattle cages about a problem like this, who will want to be the one to do actually it. No "VP of Such and Such" will spend their political capital stressing how critical it is that they fix the thing that will make a whole bunch of KPIs go in the wrong direction. They're probably spending it on shipping another hacked-together service with Web2.0-- er. IOT-- er. Blockchai-- er. Crypto-- er. AI before promotion season.
> I think that the lack of half-decent cost controls is not intentionally malicious
It wasn't when the service was first created. What's intentionally malicious is not fixing it for years.
Somehow AI companies got this right form the get go. Money up front, no money, no tokens.
It's easy to guess why. Unlike hosting infra bs, inference is a hard cost for them. If they don't get paid, they lose (more) money. And sending stuff to collections is expensive and bad press.
> Somehow AI companies got this right form the get go. Money up front, no money, no tokens.
That’s not a completely accurate characterization of what’s been happening. AI coding agent startups like Cursor and Windsurf started by attracting developers with free or deeply discounted tokens, then adjusted the pricing as they figure out how to be profitable. This happened with Kiro too[1] and is happening now with Google’s Antigravity. There’s been plenty of ink spilled on HN about this practice.
[1] disclaimer: I work for AWS, opinions are my own
I think you’re talking about a different thing? The bad practice from AWS et al is that you post-pay for your usage, so usage can be any amount. With all the AI things I’ve seen, either:
- you prepay a fixed amount (“$200/mo for ChatGPT Max”)
- you deposit money upfront into a wallet, if the wallet runs out of cash then you can’t generate any more tokens
- it’s free!
I haven’t seen any of the major model providers have a system where you use as many tokens as you want and then they bill you, like AWS has.
> There is no mustache-twirling villain who has a great idea on how to !@#$ people out of their money.
I dunno, Aurora’s pricing structure feels an awful lot like that. “What if we made people pay for storage and I/O? And we made estimating I/O practically impossible?”
A year ago I did a back of the napkin calculation and was surprised when I realised Aurora would cost the same or more as my current RDS for Postgres setup. Any discussion with costs inevitably has someone chiming in with a "have you considered Aurora?" and I don't quite understand why it's so loved.
Because a. People by and large don’t run their own benchmarks b. Aurora does legitimately have some nice features, though a lot of them are artificially restricted from RDS (like the max volume size).
The biggest cool thing Aurora MySQL does, IMO, is maintain the buffer pool on restarts. Not just dump / restore, but actually keeps its residence. They split it out from the main mysqld process so restarting it doesn’t lose the buffer pool.
But all in all, IMO it’s hideously expensive, doesn’t live up to its promises, and has some serious performance problems due to the decision to separate compute and storage by a large physical distance (and its simplification down to redo log only): for example, the lack of a change buffer means that secondary indices have to be written synchronously. Similarly, since AWS isn’t stupid, they have “node-local” (it’s EBS) temporary storage, which is used to build the aforementioned secondary indices, among other things. The size of this is not adjustable, and simply scales with instance size. So if you have massive tables, you can quite easily run out of room in this temporary storage, which at best kills the DDL, and at worst crashes the instance.
Even if you are not currently hitting performance limits of your current engine, Aurora would maintain the same throughput and latency on smaller instance classes. Which is where the potential cost savings come from...
On top of that, with Aurora Serverless with variable and unpredictable workloads you could have important cost savings.
Except it isn’t nearly as fast as it claims [0]. And in real-world tests, I have never found it to beat RDS.
You can get an insane amount of performance out of a well-tuned MySQL or Postgres instance, especially if you’ve designed your schema to exploit your RDBMS’ strengths (e.g. taking advantage of InnoDB’s clustering index to minimize page fetches for N:M relationships).
And if you really need high performance, you use an instance with node-local NVMe storage (and deal with the ephemerality, of course).
Well the article you linked to....confirms that Aurora is faster than MySQL on equivalent hardware, especially for write-heavy workloads, just that the “5× faster” claim only holds under very specific benchmark conditions.
Also from the link...when MySQL is properly tuned, the performance gap narrows substantially but is still 1,5x to 3x for the workloads tested in the article something I would call massive.
The benchmarks were just that - synthetic benchmarks. I’ve ran actual production workloads against both, and Aurora never won. IFF you have an incredibly write-heavy workload, and you have few to no secondary indices, then Aurora might win; I’d also suggest you reconsider your RDBMS choice.
Most workloads are somewhere between 90:10 to 98:2 reads:writes, and most tables have at least one (if not more) secondary indices.
You’re of course welcome to disagree, but speaking as a DBRE who has used both MySQL and Postgres, RDS and Aurora in production, I’m telling you that Aurora does not win on performance.
> There is no mustache-twirling villain who has a great idea on how to !@#$ people out of their money.
Unfortunately, that's not correct. A multi-trillion dollar company most absolutely has not just such a person, but many departments with hundreds of people tasked with precisely that, maximizing revenue by exploting every dark pattern they can possibly think of.
It would be good to provide a factual basis for such a confident contradiction of the GP. This reads as “no, your opinion is wrong because my opinion is right”.
AWS isn't for tinkerers and doesn't have guard rails for them, that's it. Anybody can use it but it's not designed for you to spend $12 per month. They DO have cost anomaly monitoring, they give you data so you can set up your own alerts for usage or data, but it's not a primary feature because they're picking their customers and it isn't the bottom of the market hobbyist. There are plenty of other services looking for that segment.
I have budgets set up and alerts through a separate alerting service that pings me if my estimates go above what I've set for a month. But it wouldn't fix a short term mistake; I don't need it to.
> I think it's the play between incompetence and having absolutely no incentive to do anything about it
The lack of business case is the most likely culprit. "You want to put engineering resources into something that only the $100/mo guys are going to use?"
You might be tempted to think "but my big org will use that", but I can guarantee compliance will shut it down -- you will never be permitted to enable a feature that intentionally causes hard downtime when (some external factor) happens.
I've used AWS for about 10 years and am by no means an expert, but I've seen all kinds of ugly cracks and discontinuities in design and operation among the services. AWS has felt like a handful of very good ideas, designed, built, and maintained by completely separate teams, littered by a whole ton of "I need my promotion to VP" bad ideas that build on top of the good ones in increasingly hacky ways.
And in any sufficiently large tech orgnization, there won't be anyone at a level of power who can rattle cages about a problem like this, who will want to be the one to do actually it. No "VP of Such and Such" will spend their political capital stressing how critical it is that they fix the thing that will make a whole bunch of KPIs go in the wrong direction. They're probably spending it on shipping another hacked-together service with Web2.0-- er. IOT-- er. Blockchai-- er. Crypto-- er. AI before promotion season.