Edit: A very kind reader gave me a heads up that the ECU appears on the current EC2 pricing page (and now is an optional column on the instance request page). Whether I simply completely overlooked it, or Amazon trialed removing it or is A:B testing (there seems to be some debate within Amazon about whether to keep it and punt it), I can’t say with certainty. But I have to assume the latter as I look at the pricing page frequently, most certainly in consideration of this entry. The pricing tables are template driven (in HTML template, HTTP requests to data source that sends that data through to a callback where it is rendered), and the Wayback Machine seems to show the template being largely unchanged over time, though there is a week and a half gap during which I did this post. The styles that could choose to hide or display the ECU column unfortunately didn’t get captured, so I can’t check there, my motivation simply being interest rather than trying to prove I wasn’t imagining.
Generally you need some basis of comparison when you provision cloud hardware, understanding how each of the components perform to determine how it fits your workload.
On the Amazon EC2 platform, computational performance was generally expressed via ECUs – Elastic Compute Units. These reduced and expressed the computational performance of the unit into a single metric. This value was a product of both the underlying hardware (newer processors performing better than old processors. Higher speed processors performing better than lower speed processors, at least within a given architectural family), and the governor that restricted your use of the same.
The number of cores was a separate concern, and in some cases could be a negative: a high ECU and minimal cores could be optimal for some workloads that don’t scale across cores elegantly, while a medium ECU and numerous cores fit other workloads better.
Instead instances are promoted by vCPUs and a narrative that describes the expected performance (e.g. “Compute optimized”).
vCPUs are something that in-house IT shops are more accustomed to when provisioning virtual machines on often very lightly provisioned hardware. On heavily provisioned hardware with governors, however, vCPUs can be meaningless or deceptive as a performance measure.
The m3.medium instance type, for instance, takes 160 seconds to run the command-
sysbench --test=cpu --cpu-max-prime=40000 run
I ran this on several instances, across availability zones, to complete consistency. This is restricted by a governor, not contention or hardware limits, which is a little strange given that the instance types page implies that it has the full run of the core which is clearly not the case.
The t2.micro (a new instance that again changes the conclusions of previous entries on here), which features exactly the same Xeon E5-2670, performs the same benchmark in 69.5 seconds, or less than half the time. Both of them have 1 vCPU, and on all of the instances I provisioned ran on apparently identical hardware.
The t2.micro has a novel governor that will restrict you from using it heavily for long periods of time.
The c2.large instance has 2 vCPUs, but restricting the benchmark to a single thread and it completed in 70s, or about the same as the t2.micro when it wasn’t governed. Running it across two vCPUs saw it complete in 40 seconds.
None of this is to say or even hint at Amazon being deceptive in any way — they clearly provide a narrative for each instance type that describes appropriate uses and expected performance — and truthfully the ECU unit was often of questionable use. On the last remaining place where you can see the ECU (the final review stage of an instance configuration), for instance, it claimed that the m3.medium provided 3 ECU, while the c2.large provided 7. Yet realistically the c2.large offers more than 4x more performance. Things get even more complex when you consider that the newer HVM instances allow you to use the full capabilities of AVX, where workloads can see dramatic speedups.
As with most things in life, your mileage may vary, and you should always test assumptions.
Anyways, I found all of this rather fascinating. In a discussion comparing EC2 versus Digital Ocean (where in my tests the $5 instance performed the test in 99 seconds, the $10 instance doing it in 88 seconds) I and others realized that Amazon largely removed ECUs with close to no fanfare.