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.
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.
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.
4TB of RAM is pretty impressive, especially if they are actually making money on this offering. It must be pretty expensive to have them sit idle at all.
For anyone else that is curious, the old SLA was %99.95.
https://web.archive.org/web/20171114180320/https://aws.amazo...
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.
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.
4TB of RAM is pretty impressive, especially if they are actually making money on this offering. It must be pretty expensive to have them sit idle at all.
What is the pricing on a x1e.xlarge? I'm not seeing it listed:
Looking like $1.209 per hour through Sydney. You might have chosen a region without them.
Anyone using x1e.32xlarge for anything around here?
Not personally, but stuff like SAP HANA really likes having piles of RAM thrown at it.