EC2 Memory-Optimized Instances: R5 vs. X1

If you’re running enterprise-scale, memory-intensive workloads, such as high performance databases and real-time big data analytics, you’ll need instances that are memory optimized. In extreme cases, you might reach for the High Memory or z1d instances, but more often you’ll use the R5, R5d, R5a, X1 and X1e families. We’re going to take a look at all of them and do some cross-family comparisons.

The R5 Family

R5 instances use the Intel Xeon Platinum 8000 series (Skylake-SP) processor with a sustained all core Turbo CPU clock speed of up to 3.1 GHz. R5 instances also support the new Intel Advanced Vector Extensions 512 (AVX-512) instruction set. The AVX-512 uses ultra-wide 512-bit vector registers and has other enhancements that accelerate computational operations. A common use case is database servers, such as SQL databases and DB2 databases.

R5 instances have a 1:8 vCPU to memory ratio — for every vCPU, there are 8 GiB of memory. For example, the smallest R5 instance, the r5.large, has two vCPUs and 16 GiB of memory. The largest size, the r5.24xlarge, has 96 vCPUs and 768 GiB of memory.

Specs for the smallest and largest instance sizes.

The R5d Family

If you want to further increase the performance of your application, you can use R5d instances, which use SSD instance storage instead of EBS volumes. R5d instances offer up to 3.6TB of NVMe-based SSDs and are available in the same sizes as R5 instances. As a note, the SSD storage isn’t usually enough for all of your needs, so you’ll still probably need to add some S3 storage — and the costs that come with it.

The R5a Family

The difference between an R5a instance and an R5 instance is the processor. All R5a instances use the AMD EPYC 7000 series processors with an all core turbo clock speed of 2.5 GHz. These instances are slower, but cost about 10% less than what R5 instances do. If you don’t need as much compute, you should look into the R5a. This family offers the same sizes and memory to vCPU ratio as the R5.

Some Cost Comparisons

Since all the variations of the R family offer the same sizes, it’s easy to do some straightforward price comparisons. Here’s the On-Demand costs for the smallest and largest sizes of each family.

Prices are On-Demand for Linux, US West (Oregon).

You can see that, compared to the R5 instances, the SSD storage will cost you more, which should be balanced with the EBS cost. And if you go with the slower processor for R5a, then you pay less.

The X1 and X1e Families

The X1 and X1e families are designed for large in-memory workloads. Initially, they were intended to run SAP HANA, but they also work well for other memory-intensive workloads such as in-memory analytics and big data processing with applications like Apache Spark.

Both of these families use the same underlying compute platform: a four-socket high frequency Intel Xeon E7-8880 v3 (Haswell) processor purpose-built for highly resilient, mission-critical in-memory workloads.

The chip optimizations include high memory bandwidth and larger L3 caches that boost the performance of in-memory applications. The chip enables increased cryptographic performance via Intel AES-NI, supports Intel® Transactional Synchronization Extensions (TSX) to boost the performance of in-memory transactional data processing, and supports Advanced Vector Extensions 2 (Intel AVX2) processor instructions to expand most integer commands to 256 bits.

It’s also designed to support NUMA-optimized (non-uniform memory access) workloads, providing high memory bandwidth and low latency while accessing distant memory. The homogeneous and symmetric placement of the dual in-line memory modules (DIMMs) across each of the sockets was done specifically to maximize bandwidth and throughput while minimizing latency.

The X1 Family

The key difference between the X1 and X1e families is the vCPU to memory ratio. The X1 instances offer roughly a 1:16 ratio. For approximately 1 TiB of memory, you get 64 vCPUs. There are only two X1 sizes:

Prices are On-Demand for Linux, US West (Oregon).

There’s obviously a big price difference between the R5 family and the X1 family, but demanding workloads, such as real-time analytics, may require the faster processor and large amounts of memory that the X1 (and X1e) provide.

The X1e Family

The X1e family has smaller sizes than the X1 family, starting with the x1e.xlarge. These smaller sizes can provide a bridge solution for running high-performance enterprise-class databases like Oracle and SQL. Together, the X1 and X1e family provide a great deal of scalability. You can start with a smaller size and easily scale up as your demands grow.

The X1e instances provide double the memory for the given number of CPUs than the X1 family with a ratio of 1:32. There are six X1e instance sizes, starting from four vCPU and 122 GiB to 128 vCPU and 4TiB.

Specs for the largest and smallest instances. Prices are On-Demand for Linux, US West (Oregon).

Other X1 and X1e Costs

The X1 and X1e families are EBS-enhanced and use enhanced networking by default, so you have to compensate for the additional EBS costs. In-memory databases are usually optimized to use large block sizes at startup. You might want to use the io1 EBS volume type for this time period, since it’s the highest performance SSD volume. Once the database reaches steady state, you can change to gp2.

There are also three services that work very well with X1 and X1e — Auto Recovery, Auto Scaling and Elastic Load Balancing.

Auto Recovery

If your instance goes down, Auto Recovery automatically boots another instance and applies all the characteristics such as instance IP, elastic IPs and storage volumes. Auto Recovery can perform the same function as High Availability does for on-prem.

There are no additional EC2 charges for using Auto Recovery, but the usual CloudWatch charges apply. You can see CloudWatch pricing information here.

Auto Scaling

When customers run in-memory databases on X1 and X1e instances, they also have front-end applications that run on other instance types, applications that can scale exponentially over time. Auto Scaling takes the risk out of growth planning. You can dynamically add or remove instances based on your workload. For example, you can specify that when CPU utilization goes to 75%, a new instance is spun up. If it goes below 40%, one of the instances is stopped.

There is no additional charge for Auto Scaling, but you should also take the CloudWatch monitoring fees into account.

Elastic Load Balancing

Elastic Load Balancing (ELB) works well with Auto Scaling. With ELB, you can balance all the incoming traffic across multiple instances. If you’re running multiple front-end servers that are connecting to your in-memory database, you can balance the connectivity to that workload as you scale it using Auto Scaling. ELB incurs its own costs, which you can see here.

Optimizing High Memory EC2 Spend

It’s pretty clear that running in-memory databases can be expensive, especially as you scale up to the larger sizes, which makes cost optimization critical for any size cloud architecture. There are a number of key steps anyone running these instances should take to avoid unnecessary spend and get the most out of their cloud, including:

• Take advantage of Reserved Instances – An x1.32xlarge has an effective hourly rate that’s 29%-72% cheaper (depending on options) than its On-Demand rate. If you’re consistently running these as the backbone of your products, you need to maximize your RI usage.
• Automate instance shutdown – If you only need the power of your R5s during business hours, then using automation to automatically shut them down on nights and weekends prevents a lot of waste.
• Rightsize your instances – Make sure you have the right size instances for your workload using a tool like Cloudability’s Rightsizing feature.
• Implement a FinOps operating model – FinOps creates a culture of cost optimization across your whole organization so everyone involved across Finance, Technology and Business Leadership is working together to build the most efficient cloud for your goals.

Ready to start optimizing your costs for high memory workloads?

Sign up for a free Cloudability trial!