Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A $1k AWS mistake

geocod.io

Post reply on HN
Print view View original

261–270 of 281 posts

Re: A $1k AWS mistake

#261

Post by belter »

array_key_first wrote: post #251
belter wrote: post #149

Earlier quoted context omitted.

> And moreover, it makes migrating away from AWS quite expensive in a lot of circumstances. Please get some training...and stop spreading disinformation. And to think on this thread only my posts are getting downvoted.... "Free data transfer out to internet when moving out of AWS" - https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-i...

It's not disinformation at all, there's a lot of hurdles to this. In the link you posted , it even says Amazon can't actually tell if you're leaving AWS or not so they're going to charge you the regular rate. You need explicit approval from them to get this 'free' data transfer.

It feels like you are intentionally missing the point. The blog makes it quite clear that the purpose of notifying AWS is so they stop charging you for that specific type of traffic. How else would they know whether the spike is normal production usage, which is billable, or part of a migration effort?

There is nothing in the blog suggesting that this requires approval from some committee or that it is anything more than a simple administrative step. And if AWS were to act differently, you have grounds to point to the official blog post and request that they honor the stated commitment.

Re: A $1k AWS mistake

#262

Post by belter »

zdc1 wrote: post #247
sgarland wrote: post #99

Earlier quoted context omitted.

> 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.

The business and technical argument for Aurora is that it delivers significantly higher performance for the same underlying hardware compared to MySQL or PostgreSQL: https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/aurora-sigmo...

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.

Re: A $1k AWS mistake

#263

Post by belter »

shermantanktop wrote: post #167
belter wrote: post #116

Earlier quoted context omitted.

These topics are not advanced...they are foundational scenarios covered in any entry level AWS or AWS Cloud third-party training. But over the last few years, people have convinced themselves that the cost of ignorance is low. Companies hand out unlimited self-paced learning portals, tick the “training provided” box, and quietly stop validating whether anyone actually learned anything. I remember when you had to spen…

If I accept your premise (which I think is overstated) I’d say it’s a good thing. We used to ship software with literally 100lbs of manual and sell expensive training, and then consulting when they messed up. Tons of perverse incentives. The expectation that it just works is mostly a good thing.

> The expectation that it just works is mostly a good thing.

Not if its an Airbus A220 or similar. They made it easy to take off, but it is still a large commercial aircraft...easy to fly...for pilots...

Re: A $1k AWS mistake

#264

Post by [deleted] »

belter wrote: post #261
array_key_first wrote: post #251

Earlier quoted context omitted.

It's not disinformation at all, there's a lot of hurdles to this. In the link you posted , it even says Amazon can't actually tell if you're leaving AWS or not so they're going to charge you the regular rate. You need explicit approval from them to get this 'free' data transfer.

It feels like you are intentionally missing the point. The blog makes it quite clear that the purpose of notifying AWS is so they stop charging you for that specific type of traffic. How else would they know whether the spike is normal production usage, which is billable, or part of a migration effort? There is nothing in the blog suggesting that this requires approval from some committee or that it is anything more…

[deleted]

Re: A $1k AWS mistake

#265

Post by belter »

Nevermark wrote: post #175
belter wrote: post #121

Earlier quoted context omitted.

This has nothing about punching down. Writing a blog about this basic mistake, and presenting as advice shows a strong lack of self awareness. Its like when Google bought thousands of servers without ECC memory, but felt they were so smart they could not resist telling the world how bad that was and writing a paper about it...Or they could have hired some real hardware engineers from IBM or Sun...

> Writing a blog about this basic mistake, and presenting as advice shows a strong lack of self awareness. You realize they didn’t ask you to read their article right? They didn’t put it on your fridge or in your sandwich. Policing who writes what honest personal experience on the Internet is not a job that needs doing. But if you do feel the need to police, don’t critique the writer, but HN for letting interested re…

They are doing Enterprise sales and were founded in 2014...These type of technical blogs are normally written to demonstrate the company internal expertise, demonstrate skills of the engineering team to motive hiring etc... Does this inspire confidence?

Re: A $1k AWS mistake

#266

Post by next_xibalba »

jjav wrote: post #260
Waterluvian wrote: post #76

Earlier quoted context omitted.

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 expe…

> 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.

> Unfortunately, that's not correct

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”.

Re: A $1k AWS mistake

#267

Post by sgarland »

belter wrote: post #262
zdc1 wrote: post #247

Earlier quoted context omitted.

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.

The business and technical argument for Aurora is that it delivers significantly higher performance for the same underlying hardware compared to MySQL or PostgreSQL: https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/aurora-sigmo... 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 potenti…

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).

0: https://hackmysql.com/are-aurora-performance-claims-true/

Re: A $1k AWS mistake

#268

Post by parliament32 »

Waterluvian wrote: post #76
Havoc wrote: post #37

These sort of things show up about once a day between the three big cloud subreddit. Often with larger amounts And it’s always the same - clouds refuse to provide anything more than alerts (that are delayed) and your only option is prayer and begging for mercy. Followed by people claiming with absolute certainty that it’s literally technically impossible to provide hard capped accounts to tinkerers despite there bein…

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 expe…

> 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.

Re: A $1k AWS mistake

#269

Post by sgarland »

zdc1 wrote: post #247
sgarland wrote: post #99

Earlier quoted context omitted.

> 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.

Re: A $1k AWS mistake

#270

Post by belter »

sgarland wrote: post #267
belter wrote: post #262

Earlier quoted context omitted.

The business and technical argument for Aurora is that it delivers significantly higher performance for the same underlying hardware compared to MySQL or PostgreSQL: https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/aurora-sigmo... 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 potenti…

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, yo…

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.

Post reply on HN