Due to increased query sizes on our presto clusters (causing aggregation failures), I’m in the middle of evaluating moving from 16 core 64GB RAM general purpose EC2 machines (m4.4xlarge) to 64 core 256GB RAM general purpose machines (a 4x increase in power/RAM).
Here is the list of m4 and m5 models for 16-core/64GB and 64-core/256GB specs. Below, we’ll see how they compare to each other and what the best option is.
| Type | vCPU | ECU | Memory (GiB) | Instance Storage (GB) | Linux/UNIX Usage |
|---|
| m4.4xlarge | 16 | 53.5 | 64 GiB | EBS Only | $0.80 per Hour |
| m4.16xlarge | 64 | 188 | 256 GiB | EBS Only | $3.20 per Hour |
| m5.4xlarge | 16 | 70 | 64 GiB | EBS Only | $0.768 per Hour |
| m5.16xlarge | 64 | 256 | 256 GiB | EBS Only | $3.072 per Hour |
For reference:
EC2 uses the EC2 Compute Unit (ECU) term to describe CPU resources for each instance size where one ECU provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.
There are a few good things to notice here:
- For m4.4xlarge to m4.16xlare, we are getting 4x the resources for exactly 4x the cost ($.80 x 4 = $3.20). The one exception is we get less than 4x the ECU units (so technically less than 4x the processing power). So, compute roughly scales linearly within a model it seems.
- Pretty much the exact same situation holds true for the m5 models; going from xlarge to 16xlarge is exactly a 4x increase in cost and resources except for ECUs which are a little less than 4x.
- The m5 models have more ECUs than their m4 counterparts and they also cost less, so they are a better deal both performance and cost wise.
So, we’ll go with m5.16xlarge instances which cost $3.072 an hour. This comes out to $2,211 a month.
Coding Stream of Consciousness 