What is an ECU? An EC2 Compute Unit, Simply Explained

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.

AWS replaced the ECU by the vCPU — which is a better name and a simpler concept.

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 were no configurability; all instances were created equal. You’d get one size, and you’d like it. The original instance type was renamed “Small,” and they added “Large” and “Extra Large” — with more CPU, memory, and storage to match.

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.

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 the older infrastructure. The hardware would gradually change, and most customers never noticed.

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 The ECU just started to disappear from the EC2 console and documentation.

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.

Doron Shachar

Jun 4 · 3 min read

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.