Hacker News Reader

Comment by eropple | Hacker News Reader

The x1e.xlarge isn't much cheaper (about 15%) than an r4.4xlarge, which has the same amount of RAM and 16 Xeon vCPUs at 53 ECUs versus 4 Skylake vCPUs at 12 (!) ECUs.

I don't quite understand why this exists. Maybe playing in-family reserved instance games, but this seems a little weird. I can't think of a reason why I would use the x1e.xlarge or recommend it to anyone.

View on HN

While fewer workloads today are CPU-bound in general, these will probably be an especially big win for commercial software use cases in particular. Customers running workloads with processor-based licensing (think databases) now have more options for increasing available RAM without taking on more CPU licenses.

(disclosure, I work for AWS)

For something really memory-bound. joneholland's suggestion of Redis seems plausible, and you can imagine other data tasks that are CPU-light but RAM-heavy (memcache?).

And not what you were commenting on, but the larger of the new sizes also provide a bit more flexibility in that space above r4.16xl's RAM capacity, or where the big r4s have excess compute compared to what your DB, etc. really wants.

We have some places at work where Python multiprocessing RAM overhead, rather than CPU, is sadly the limiting factor for our concurrent requests/sec., but I doubt it's extreme enough to make x1e attractive for it.

It seems to be a perfect fit for redis, since that only uses a single core. We run redis on R4s today and it wastes most of the cores.

You forgot the local SSD in the x1e.xlarge.

Reply on news.ycombinator.com