The purpose of the testing for this paper is to push APEX File Storage to its performance limits. This means using solid-state EBS volumes and large EC2 instances for lots of storage performance, compute, and RAM.

The cluster used for the testing in this paper has the following configuration:

6x Node APEX File Storage cluster

• EC2 node type: m5dn.24xlarge
• EBS volume: gp3, 8000 IOPs, 1000 MiB/s, 512 GB
• 12x EBS volumes per EC2 instance

A bit of math is involved in calculating how to configure each component. For the EBS volumes, the maximum throughput provided by the gp3 EBS volumes is 1000MiB/s. Throughput of the gp3 EBS volumes is to a certain extent tied to IOPs and to a certain extent capacity. Amazon documentation states that 1 IOP = .25MiB/s of throughput per gp3 volume. To achieve the maximum of 1000MiB/s, the volume needs to have at least to 4000 IOPs and be at least 32 GiB in capacity. For details, see Amazon EBS: gp3 volume performance.

For the APEX File Storage configuration used in these tests, there were 12x EBS volumes attached to each EC2 instance. That is a lot of storage throughput, so the m5dn.24xlarge EC2 instance type was chosen as the APEX File Storage node type. This is the most performant EC2 instance qualified for APEX File Storage at the time of this writing.

The m5dn.24xlarge instance provides 19,000 Mbps of EBS throughput and 25 Gbps of network performance. For details. See Amazon EC2: m5 instance types.

This is a bit confusing because there are a lot of different units of measurement involved. There is far more potential storage performance than what the m5dn.24xlarge EC2 instance can deliver, which is okay. The purpose of these tests is to push performance, so it makes sense to have enough EBS storage performance to drive the m5dn.24xlarge EC2 instance!