With so many options at your disposal, how do you know which to use?<\/strong><\/h3>\nOver time, Amazon has tried different ways to make the list easier to navigate.<\/p>\n
For example, instance types are grouped into \u201cfamilies,\u201d and different families have different characteristics \u2014 each optimized for different kinds of workload.<\/p>\n\n\n![\"\"](\"https:\/\/miro.medium.com\/max\/4096\/1*KBDNNWgF-Jp0PqvMZ0QBfw.jpeg\")
<\/div>\n<\/div>\n<\/figure>\nOne approach was the\u00a0EC2 Compute Unit<\/strong>\u00a0(or\u00a0\u201cECU\u201d<\/strong>), a unit that Amazon created to measure the relative CPU performance of an instance type.<\/p>\nLooking 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.<\/p>\n
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.<\/strong><\/p>\nAWS replaced the ECU by the vCPU \u2014 which is a better name and a simpler concept.<\/p>\n
Act I: You can have any size, as long as it\u2019s Small<\/strong><\/h3>\nLaunched in mid-2006, EC2 was one of the first AWS services \u2014 hot on the heels of SQS and S3.<\/p>\n
You can still read\u00a0Jeff Barr\u2019s blog post<\/a>\u00a0announcing the service, with an explanation of scalability that works as well today as it did 15 years ago.<\/p>\nIn that first release, there was no configurability; all instances were created equal. You\u2019d get one size, and you\u2019d like it. The original instance type was renamed \u201cSmall,\u201d and they added \u201cLarge\u201d and \u201cExtra Large\u201d \u2014 with more CPU, memory, and storage to match.<\/p>\n
Three instances. One unit to compare them. Simple so far. Right?<\/strong><\/h5>\n\n\n\n\n\n<\/div>\n![\"\"](\"https:\/\/miro.medium.com\/max\/960\/1*ZXNEokkzzWB707g9-j6_tw.jpeg\")
<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/figure>\n
<\/h3>\nAct II: The golden years of ECU<\/strong><\/h3>\nEven with the first three instance types, the EC2 Compute Unit could be confusing.<\/p>\n
The new instance types were larger in every dimension \u2014 CPU power, memory, and disk storage \u2014 and all three of these factors will affect the performance of an instance, not just the CPU.<\/p>\n
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.<\/p>\n
After 2007, new instance types started to come thick and fast \u2014 not just a neat line, but more and more choices of CPU, memory, and storage.<\/p>\n
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\u00a0how many ECUs it had<\/a>.<\/p>\nFor customers, the ECU helped make sense of the growing list of instance types. But it took a while for new EC2 users to understand.<\/strong><\/h6>\nIt wasn\u2019t 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.<\/strong><\/h6>\nFor Amazon, the ECU allowed them to provide consistent CPU capacity for each instance type, even as they were busy upgrading the underlying hardware.<\/p>\n
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.<\/p>\n
If you have an EC2 deployment that\u2019s working, it\u2019ll keep working, all the way back to that day 1 instance type (today called the m1.small).<\/strong><\/p>\nAct III: Exit, pursued by a pair (of alternative measures)<\/strong><\/h3>\nIn 2014 The ECU just started to disappear from the EC2 console and documentation.<\/p>\n
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 \u2014 not harder.<\/p>\n
<\/div>\n<\/div>\n<\/figure>\nOne approach was the\u00a0EC2 Compute Unit<\/strong>\u00a0(or\u00a0\u201cECU\u201d<\/strong>), a unit that Amazon created to measure the relative CPU performance of an instance type.<\/p>\n 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.<\/p>\n 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.<\/strong><\/p>\n AWS replaced the ECU by the vCPU \u2014 which is a better name and a simpler concept.<\/p>\n Launched in mid-2006, EC2 was one of the first AWS services \u2014 hot on the heels of SQS and S3.<\/p>\n You can still read\u00a0Jeff Barr\u2019s blog post<\/a>\u00a0announcing the service, with an explanation of scalability that works as well today as it did 15 years ago.<\/p>\n In that first release, there was no configurability; all instances were created equal. You\u2019d get one size, and you\u2019d like it. The original instance type was renamed \u201cSmall,\u201d and they added \u201cLarge\u201d and \u201cExtra Large\u201d \u2014 with more CPU, memory, and storage to match.<\/p>\n Even with the first three instance types, the EC2 Compute Unit could be confusing.<\/p>\n The new instance types were larger in every dimension \u2014 CPU power, memory, and disk storage \u2014 and all three of these factors will affect the performance of an instance, not just the CPU.<\/p>\n 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.<\/p>\n After 2007, new instance types started to come thick and fast \u2014 not just a neat line, but more and more choices of CPU, memory, and storage.<\/p>\n 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\u00a0how many ECUs it had<\/a>.<\/p>\n For Amazon, the ECU allowed them to provide consistent CPU capacity for each instance type, even as they were busy upgrading the underlying hardware.<\/p>\n 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.<\/p>\n If you have an EC2 deployment that\u2019s working, it\u2019ll keep working, all the way back to that day 1 instance type (today called the m1.small).<\/strong><\/p>\n In 2014 The ECU just started to disappear from the EC2 console and documentation.<\/p>\n 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 \u2014 not harder.<\/p>\nAct I: You can have any size, as long as it\u2019s Small<\/strong><\/h3>\n
Three instances. One unit to compare them. Simple so far. Right?<\/strong><\/h5>\n
<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/figure>\n<\/h3>\n
Act II: The golden years of ECU<\/strong><\/h3>\n
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.<\/strong><\/h6>\n
It wasn\u2019t 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.<\/strong><\/h6>\n
Act III: Exit, pursued by a pair (of alternative measures)<\/strong><\/h3>\n