While we love developing software solutions for all of our customers, configuration and optimisation is yet another facet of our software services, often in the form of DevOps. As a result, even when our own development specialists were not initially involved in the project, we can still help to improve your application’s performance. This was the premise for the case study of Amazon Elastic Block Store optimisation we will be covering today.
What Is EBS?
Before anything else, however, let’s quickly recap what Amazon EBS is:
The Amazon Elastic Block Store provides a number of important features that are able to assist developers with data management, performance tuning and backups and is crucially best utilised for the storage of persistent data. It also provides a range of options for both storage cost and performance. These options are divided into two main categories:
SSD-backed storage for transactional workloads
Boot volumes and databases (where the performance depends primarily on IOPS)
Disk-backed storage for throughput intensive workloads
Log processing and MapReduce (in which performance depends primarily on MB/s).
AWS EBS Volumes: How to Optimise Performance and Cost
With all of this in mind, Software Planet Group were recently asked to increase a customer’s web application’s performance.
While optimising their database, we detected subpar efficiency in a disk subsystem. This was further investigated by our DevOps engineers, who confirmed that despite being based on the widely-used gp2 storage type, for a number of operations, the Amazon Elastic storage system was suboptimally configured.
Consequently, when weighing our options for disk performance optimisation, our DevOps specialists aimed to determine if EBS’ gp3 volume would be in order.
Why Choose the GP3 Volume Type
Though Amazon introduced gp2 volumes in 2014 — whose basic premise was that the larger the capacity, the faster the Input/Output Operations per Second (IOPS) — this meant that companies often had to pay for storage that they wouldn’t actually ever use. Similarly, while gp2 met the performance and throughput requirements of many applications (including virtual desktops, medium-sized databases such as SQLServer and OracleDB and development and testing environments), many companies require higher performance.
These factors led Amazon to launch the gp3 AWS EBS volume type, as gp3 enables companies to increase IOPS and throughput independently without the need for provisioning additional elastic block storage capacity. As a result, you only pay for the resources you need.
Input/Output Operations per Second (IOPS)
Testing on Different EBS Types
To determine the real-world capabilities of gp2 and gp3 storage types, we proceeded to compare their efficacy by running a random read/write performance test. The FIO utility read/wrote a 4KB block (the standard block size) with a ratio of 75/25% (i.e. 3 reads for every 1 write).
The results of the test are shown below:
AWS gp2 [r = 2265, w = 737 IOPS] = Total, IOPS: 3000 (AWS Limit 3000) within the burst balance.
AWS gp2 [r = 327, w = 123 IOPS] = Total, IOPS: 450 (AWS Limit 450) outside the burst balance.
The natural conclusion is that gp3 Elastic Block Store AWS volume types display the same performance as gp2 when the latter is operating within its “burst balance.” Note that each gp2 volume has a limited amount of I/O operations known as the Burst Balance metric, which is expressed as a simple percentage (0–100%). It is also worth pointing out that gp2 volumes that are larger than 33 GB are able to perform bursts of highly intensive I/O operations at the maximum rate of 3000 IOPS (I/O per second). This occurs for approximately 30 minutes. After that, performance begins to drop until the I/O credits are fully replenished. The replenishment rate is calculated as 3 credits * the disk size in GB (per second), or in the case of our 150 GB volume, 450 IOPS. It was precisely this drop in performance that was responsible for the disk subsystem’s problems.
After seeing great performance results in gp3, the next question we had to answer was whether its price would be equally competitive.
How to calculate the price and performance of an EBS volume
To help demystify the EBS billing system, we made use of the below calculation to determine the price and performance of the 150 GB volume for I/O operations of high intensity:
gp2
When the burst balance is utilised (after approximately 30 minutes) our gp2 volume displays constant performance of 150 GB *3 = 450 IOPS.
Throughput: 150 GB *256K = 38400 K / 1024 = 37.5 *3 = 112.5 MB/s
Price: 150 GB *0.10 USD = $15 per month.
gp3
This type of storage is not limited by the burst balance and thus performs I/O operations at a constant rate of 3000 IOPS.
Throughput: 125 MB/s (according to Amazon)
Price: 150 Gb *0.08 USD = $12 per month.
Conclusion
When it comes to EBS in AWS, Software Planet Group concluded that gp3 provides a predictable baseline performance rate of 3,000 IOPS and 125 MB/s, irrespective of volume size. As our customers soon found out, this is ideal for applications requiring high performance at a reasonable price level to boot.
Companies seeking higher performance rates may also upgrade to Amazon Elastic Block Store’s 16,000 IOPS and 1,000 MB/s for an additional fee. In any case, we recommend the new EBS volume wholeheartedly, as its official maximum throughput is 4 times higher than gp2’s:
Volume Type | gp3 | gp2 |
Max IOPS/Volume | 16,000 | 16,000 |
Max Throughput*/Volume | 1,000 MB/s | 250 MB/s |
Max IOPS/Instance | 260,000 | 260,000 |
Max Throughput/Instance | 7,500 MB/s | 7,500 MB/s |
