At some point, every AWS customer finds themselves in the EC2 console, starting an instance, trying to choose an instance type. Today, there are over 300 different instance types, all with their own configurations of CPU, memory and storage (among other things). 

With so many options at your disposal, how do you know which to use?

Over time, Amazon has tried different ways to make the list easier to navigate. For example, instance types are grouped into “families,” and different families have different characteristics—each optimized for different kinds of workload.

One approach was the EC2 Compute Unit (or “ECU”), a unit that Amazon created to measure the relative CPU performance of an instance type. Looking at the number of ECUs would allow you to compare CPU performance; an instance type with two ECUs was twice as powerful as one with one ECU, and so on.

The ECU is just a measure of relative CPU performance—it was never meant to include memory, storage, or networking—but the name was a frequent source of confusion. Look through old forums or blog posts, and you’ll find people asking what the ECU meant and how many ECUs they’d need, among other questions.

In a rare case of AWS actually getting rid of something, the ECU has been retired. While you still see occasional references to it in the AWS documentation, it’s been replaced by the vCPU—which is a better name and a simpler concept.

But if we turn back the clock, we can see where the ECU came from—and follow it from creation to cancellation.

Act I: You can have any size, as long as it’s Small

Launched in mid-2006, EC2 was one of the first AWS services—hot on the heels of SQS and S3. You can still read Jeff Barr’s blog post announcing the service, with an explanation of scalability that works as well today as it did 15 years ago.

In that first release, there was no configurability; all instances were created equal. You’d get one size, and you’d like it. As Jeff explained:

Your applications run on a “virtual CPU”, the equivalent of a 1.7 GHz Xeon processor, 1.75 GB of RAM, 160 GB of local disk and 250 Mb/second of network bandwidth.

In 2007, Amazon started to add some variety. The original instance type was renamed “Small,” and they added “Large” and “Extra Large”—with more CPU, memory, and storage to match. (What happened to “Medium”? Your guess is as good as mine.)

This is when Amazon introduced the EC2 Compute Unit (ECU). The original “Small” instance type was used as the baseline and it had one ECU. The new Large type had four ECUs (two virtual cores, two ECUs each), and the Extra Large had eight ECUs (four cores, two ECUs each).

For years to come, the EC2 FAQs would say that an ECU was “the equivalent to an early-2006 1.7 GHz Xeon processor”—all going back to that original one-size-fits-all instance.

Three instances. One unit to compare them. Simple so far. Right?

Act II: The golden years of ECU

Even with the first three instance types, the EC2 Compute Unit could be confusing.

The new instance types were larger in every dimension—CPU power, memory, and disk storage—and all three of these factors will affect the performance of an instance, not just the CPU. 

Although the EC2 Compute Unit was meant to be a measure of relative CPU performance, it was easy to get the impression that it included other factors.

After 2007, new instance types started to come thick and fast—not just a neat line, but more and more choices of CPU, memory, and storage. (Two more were added while you read that sentence.) 

Instance types became specialized for particular workloads, and AWS stuck to the ECU as a way to compare their CPU performance. Whenever they introduced a new instance type, the spec sheet would include how many ECUs it had.

For customers, the ECU helped make sense of the growing list of instance types. But it took a while for new EC2 users to understand. It wasn’t always clear that ECU was only a measure of CPU performance, and it was an Amazon-specific unit that was hard to compare with other providers.

For Amazon, the ECU allowed them to provide consistent CPU capacity for each instance type, even as they were busy upgrading the underlying hardware. As Amazon installed newer and faster infrastructure, they could run instance types with the same capacity as instance types running on older infrastructure. The hardware would gradually change, and most customers never noticed.

Keeping the instance type and the underlying hardware separate makes it easier to keep old instance types available—Amazon encourages you to upgrade to newer-generation instance types, but you’re not forced to do so. If you have an EC2 deployment that’s working, it’ll keep working, all the way back to that day 1 instance type (today called the m1.small).

Act III: Exit, pursued by a pair (of alternative measures)

In 2014, Amazon quietly dropped the EC2 Compute Unit. There was no formal announcement or blog post; the ECU just started to disappear from the EC2 console and documentation.

An FAQ entry explained that Amazon had replaced the ECU “with processor information and clock speed” as a way to compare CPU performance—and they added this information to the spec sheet for instance types. (As a sign of how much AWS hates deprecating things, they took down the FAQ entry admitting they’d removed something after just a fortnight.)

This change was about making EC2 simpler to understand. The ECU had been a persistent source of confusion for customers, and dropping it meant one less thing for new customers to understand. Switching to standard metrics made EC2 instance types easier to compare— not harder.

The ECU was a nice idea, but it was never as simple as Amazon hoped.

Act IV: The distant present

If you look in the EC2 console today, you still see a somewhat abstract unit of CPU performance: the virtual CPU (or “vCPU”). The vCPU is the spiritual successor to the ECU —a way to compare the relative CPU performance of EC2 instance types, but with less confusion.

The name makes it instantly clear that this is a measure of CPU performance, nothing else. There’s much less ambiguity.

And the vCPU count can only be compared within a given instance family and generation—unlike the ECU, which tried to be a universal measure. In the list of instance types, Amazon explains what a vCPU means for each family (usually a single thread or core of a particular processor). And Amazon isn’t the only vendor to use vCPU as a measure of CPU performance—lots of other cloud providers use a similar metric.

In 2021, the vCPU is almost as old as the ECU that it replaced—and I expect Amazon to use it for quite a bit longer.

The EC2 Compute Unit was Amazon’s first attempt to create a unit to measure the relative CPU performance of EC2 instance types. It was meant to help customers compare instance types, but it was often a source of confusion and frustration.

In 2014, it was replaced with the vCPU, a more standardized unit that was simpler to understand. You can still find occasional mention of ECUs in documentation, but the concept has largely fallen out of favor.

For all its flaws, the EC2 Compute Unit tried to solve a real problem: navigating the dizzying array of EC2 instance types. EC2 is often the largest part of an AWS bill, so you want to be sure you’re using it efficiently. 

Need some help making sure you are? Give us a call.