Getting Started with Database Workloads on AWS

A major shift is underway as companies move their database workloads from on-premises data centers to the cloud. While using cloud service providers (CSPs) offers a wide array of advantages, the transition also requires many decisions. These include which provider to choose and which instance types and sizes are most appropriate for your workloads. In this blog, I’d like to provide some guidance to help those who are sorting through their options for running database workloads on Amazon Web Services (AWS) and Intel.

What AWS Can Do for You

By now, you’re likely familiar with the benefits of the cloud. You can save time and money on hardware upkeep and upgrades, and easily scale your workloads. The flexibility the cloud provides means you pay for only the resources that you need, and cloud service providers are generally quick to apply the latest security and privacy patches and upgrades to all their services. Nearly all CSPs offer these advantages, so determining the right CSP for you will probably involve looking at your individual needs and requirements. In that context, let’s look at a few specific strengths of Amazon Web Services (AWS).

When you consider expanding into the cloud, there’s a good chance that AWS is the first provider that comes to mind. They hold the greatest percentage of the industry market share,1  and Gartner has ranked AWS best in their Cloud Infrastructure Magic Quadrant for 10 consecutive years.2 They tend to offer more options than their competitors across the portfolio of cloud services—including storage, compute, and IoT—and are especially developer-friendly.3,4 If you seek access to a breadth of services and a variety of choices for every service, AWS is the CSP for you.

Intel and AWS have partnered for more than 14 years to provide customers with cost-effective, scalable cloud computing. Intel processors back many AWS services, including Amazon EC2 instances where Intel-backed instances are the most widely available across the AWS platform.5 For Windows and Microsoft SQL Server database workloads, Intel-backed AWS instances provide two times better price for the performance and up to 90% cost savings compared to on-prem environments.6

To help those who are trying to decide on a CSP understand the kind of performance they can expect for their workloads, we at Intel have run a series of tests with common workloads across several cloud providers. In this blog, I’ll focus on our AWS database testing on both analytical and transactional databases.

Selecting the Right Instance for the Job

Once you’ve narrowed your focus to AWS, the next task is choosing an instance type for your database workload. It’s important to consider your memory, compute, and storage requirements as you do so. AWS offers several instance categories—such as general-purpose, compute-intensive, and memory-optimized—to suit different hardware and performance needs.

Within each category, AWS offers various series that differ based on CPU model, networking needs, and more. For example, from the memory-optimized category, you might choose an R5n instance with 2nd Gen Intel® Xeon® Scalable processors and significant network bandwidth. Or maybe the R5b, which is also backed by a 2nd Gen Intel® Xeon® Scalable processor but offers more storage-focused benefits than other instances would be a better fit.

Getting the best database performance requires balancing CPU, storage, and memory to avoid a performance bottleneck. The first thing we considered in our testing was memory capacity. We wanted to cache our database fully in memory, so the instance we chose needed enough RAM relative to the size of our database. If you have similar requirements, the memory-optimized R5 instances that offer up to 768GB of memory are probably a good place to start.

However, pay close attention to the details of each series, because performance can vary significantly, especially if you change the underlying CPU. For example, in our testing, a MySQL database workload on R5 instances backed by 2nd Gen Intel Xeon Scalable processors delivered up to 1.64x the performance as the same workload on R4 instances backed by older CPUs.7 Also, note which processor features AWS lists for each instance type. On some series where AWS offers instances backed by more than one CPU generation, they disable features on newer processors that would cause large differences in performance every time you created a new instance of that type. If your workload benefits from or requires a new CPU technology, be sure to confirm that it is available on the instance.

Within each series, AWS offers several instance sizes based on the number of vCPUs available in each. Memory and other resources that affect performance metrics scale with the number of vCPUs. In addition to the memory-optimized testing we discuss above, we also tested the AWS general-purpose M5n instances to offer more points of reference for your transactional database workload. These instances, backed by 2nd Gen Intel Xeon Scalable processors, achieved up to 1.69x the performance of older M4 instances.8 We also tested analytical databases on Microsoft SQL Server and saw that our query times on M5 instances were up to 1.39x as fast as on M4 instances.9 Because every database workload differs, we tested all of these workloads on several different instance sizes.

Adding Block Storage to your Database Instances

Now that I’ve walked you through some of the CPU and memory considerations, let’s turn our focus to block storage offerings on AWS. Storage is always an important part of a database workload environment, especially when the database is larger than the memory capacity and the disks must work harder. To avoid a disk bottleneck, make sure your disks can provide the IOPS and throughput you need.

It may seem straightforward to match your needs to the disk metrics listed on the AWS website, but I’d like to alert you to a few things that could trip you up. First, always check the storage limitations of the instance you’ve chosen. Most AWS instances are optimized for and use Amazon’s Elastic Block Store (EBS) volumes, which come in tiers ranging from HDDs to high-performance SSDs. However, some instances offer NVMe drives. If your workload requires the additional performance boost of an NVMe drive, you must make sure your instance supports it. Additionally, each instance type and size has a maximum storage bandwidth; make sure you’re not inadvertently limiting disk performance by choosing an instance with a bandwidth cap lower than your workload requirement.

Once you’ve determined that your instance supports the storage performance you need, it’s time to choose the storage itself. For this exercise, we will focus on the five SSD tiers AWS offers gp2, gp3, io1, io2, and io2 Block Express (in preview as of this writing).10 Gp2, which is the default EBS volume type for EC2 instances, and gp3 tie performance to capacity. Gp2 offers 3 IOPS/GB (minimum 100 IOPS) up to 16,000 IOPS per volume, while gp3 starts at a minimum of 3,000 IOPS for any volume size. Note that the gp2 volumes offer a maximum of only 250 MB/s throughput while gp3 offers up to 1,000 MB/s.

While AWS lists single-instance databases as example applications for gp2 and gp3 disks, you might require more flexibility in choosing IOPS and bandwidth, or want to attach more than one instance to each disk. If so, you should look at the io1 and io2 volumes, which offer up to 500 IOPS/GB for a total of 64,000 IOPS. In addition, you can choose the IOPS performance you want for each volume, though you must adjust the volume capacity to fit within IOPS/GB requirements. Note that the full 64,000 IOPS is available only with instances built on the AWS Nitro System. (To see if an instance was built on Nitro, check the instance details page.) The best-performing EBS volumes, the new io2 Block Express volumes, increase IOPS and throughput maximums per volume to 256,000 IOPS and 4,000 MB/s. At the time of this writing, though, these volumes are available on only the R5b series instances.

As you can see, finding the EBS storage that’s right for you is complicated, and we haven’t touched on pricing yet. Cloud pricing can be somewhat difficult to parse, but the extremely detailed AWS pricing calculator lets you quickly gauge how much your configuration will cost before you pay a cent.11 Be sure to note the various pricing tiers and consider taking advantage of 1- and 3-year pricing reservations from AWS to lower costs on long-term projects.

Ensuring Image Consistency

Every database provider has recommended best practices to ensure the best performance. This is also true for providers of OSes and applications. Your organization might also require you to apply specific security or QA settings to all of your workloads. The more settings you must track, the easier it is to introduce error as you spin instances and workloads up and down.

One way to standardize your application images regardless of the underlying instance hardware is to take advantage of the AWS AMI library. As I mentioned previously, Intel has executed many database tests on AWS instances. In one such study of a transactional PostgreSQL database, instances backed by 2nd Gen Intel Xeon Scalable processors improved performance by up to 1.41x compared to instances backed by older Intel CPUs.12 (Note that throughout testing, the environment was identical across the instances to rule out any unfairness or inconsistencies in our comparisons.)

To accomplish this, we created a single baseline image that we could deploy on any instance. First, we spun up a very basic AWS instance. We installed all the necessary software and configured settings per the best practices for each database, such as locking pages in memory for Microsoft SQL Server. Once all of our settings were in place, we used the AWS GUI Action drop-down menu to create an image of our instance. Now, we have an AMI in place that we can select every time we want to spin up a new instance, guaranteeing each instance is identical aside from the underlying hardware.

Conclusion

Transitioning your database workloads to the cloud can be a great business decision, but to maximize the benefits, it’s important to select the right cloud service provider and virtual machine instances. Unfortunately, the number of options available can be overwhelming. I hope I’ve helped by highlighting some of the unique selling points of Amazon Web Services and key factors to consider as you explore AWS offerings.

[1] https://www.parkmycloud.com/blog/aws-vs-azure-vs-google-cloud-market-share/#:~:text=AWS%20has%2032%25%20of%20the,%25%2C%20Alibaba%20Cloud%20close%20behind
[2] https://kinsta.com/blog/google-cloud-vs-aws/
[3] https://www.varonis.com/blog/aws-vs-azure-vs-google/
[4] https://www.computerworld.com/article/3429365/aws-vs-azure-vs-google-whats-the-best-cloud-platform-for-enterprise.html
[5] https://aws.amazon.com/intel/
[6] https://aws.amazon.com/intel/, Enterprise Applications
[7] https://www.intel.com/content/www/us/en/partner/workload/amazon/more-mysql-transactions-per-minute-benchmark.html
[8] https://www.intel.com/content/www/us/en/partner/workload/amazon/ec2-m5n-improves-mysql-performance-benchmark.html
[9] https://www.intel.com/content/www/us/en/partner/workload/amazon/analyze-data-faster-on-ec2-m5n-benchmark.html
[10] https://aws.amazon.com/ebs/volume-types/
[11] https://calculator.aws/#/addService
[12] https://www.intel.com/content/www/us/en/partner/workload/amazon/postgresql-with-amazon-ec2-m5n-benchmark.html

Notices & Disclaimers
Performance varies by use, configuration and other factors. Learn more at https://intel.com/benchmarks.
Intel technologies may require enabled hardware, software or service activation.
No product or component can be absolutely secure.
Your costs and results may vary.
All product plans and roadmaps are subject to change without notice.
Intel does not control or audit third-party data. You should consult other sources to evaluate accuracy.
© Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Other names and brands may be claimed as the property of others.