Back in 2017, I wrote about the pitfalls of Amazon Web Services' EC2 "t2" instance types, borne out of our own experience…since then they offered an "unlimited" option (to avoid the performance impacts but with an added cost) as well as new "t3" instance types in 2018. I think it's time to revisit the world of AWS EC2 instance types as a whole and understand what each brings to the cloud game.

Amazon's EC2 landscape has exploded in recent years with new instance types, newer generations, and even new CPUs available. Navigating that landscape often involves lots of guesswork - but since we've already done a lot of that guesswork I hope we can save you some time when it comes to choosing instance types and sizes to meet your needs but helping you understand your choices better.

The Basics: Designations of AWS Instance Types

Let us start with the basics. First, let's understand what the basic designations of an instance type means. They are typically in the form "xN…", where "x" is a letter and "N" is a number defining the generation of that type - for instance, "t2" and "t3" - "t2" is the second generation of the "t" instance type, and "t3" is a newer generation of the same type - typically that means that the underlying hardware it runs on is newer, and may be faster - if your image runs on a newer generation¹, you are probably better off running on that generation, but be sure to check pricing differences as they can vary.

Note that the number is not the same across types - the latest “tX” generation is “t3”, while the latest “mX” generation is “m5” etc. The numbers only refer to the generation within that specific type.

Another gotcha is that some of the newest instance types might not be available in a given availability zone as they roll out the new hardware, so if you are deploying using multiple availability zones for redundancy (as any highly available service should), be sure to test the instance type in each zone first where you need to use it.

Sometimes there may be an additional letter after the number - that typically indicates a variation of the instance type - for instance an "a", as in "t3a", may indicate that the underlying hardware uses AMD processors instead of Intel Xeon processors - which might offer a cost savings or a performance boost if you are better optimized for AMD. In some cases, a "d" indicates that the instance will also have some "ephemeral" (non-persistent) SSD disk volumes available for temporary storage ².

AWS Instance Type Meanings

Now, what do those letters mean? Well, I haven't seen AWS define an official meaning for them, but they do seem to follow some logical meaning, so here is a table of many of the common instance types with a mnemonic-style meaning for each. There may be more than what is listed here as they add new types and variations…

As you get lower down the list, you start getting into more specific-purpose instances for engineering, simulations etc. Let's concentrate at the top half of the list.

AWS Instance Types: What You Get

For the most part, the differences will be in the balance of CPU (measured in "vCPUs" or more specifically an execution thread in a physical CPU core), RAM and certain storage optimizations. There can also be some differences in local storage (some instances come with some local disks, but these disks will be erased if the instance is stopped) and maximum network performance - for example, t3 instances have a maximum network performance of up to 5Gb/s, while m5 instances can be 10 or 25Gb/s depending on the size.

A good rule of thumb for sizes of instances these days, although not a hard rule, is that a "large" instance of any type has 2 vCPUs, with each size larger (xlarge, 2xlarge, 4xlarge etc.) being a multiplier on the number of vCPUs (4, 8, 16 etc.) and whatever the baseline RAM for that type is. The cost of the next larger instance also roughly doubles the previous size’s cost.

The baseline instance type is the "m" or "Medium”, offering a well-balanced mix of CPU, RAM and storage. The m5.large offers 2 vCPUs and 8GB RAM on 3.1GHz Intel Xeon® Platinum 8175 processors. Don’t be fooled into thinking the “m” stands for “Memory”, though.

Similar to the “m” series, but available at a much lower cost is the “t”, or “Turbo”, series I’ve mentioned before. They are good for cases where the CPU spends little time executing code – say, for instance, a basic web server, where most of the time is spent waiting for I/O. See the previous articles if you need a refresher on the pitfalls of these instances if your CPU usage is larger than expected. These are the only Intel-based instance types that are offered in sizes less than a "large". A t3.large has the same 2 vCPU and 8GB RAM, but remember that you only get a 60% baseline CPU performance, and if you exceed your credits you will get throttled to that 60%. In addition, they run on somewhat slower hardware, with the “t3” using 2.5 GHz Intel Scalable Processors and a bit less peak networking and storage bandwidth. They make for great development systems, and even are useful for some production purposes where CPU usage is minimal, and cost is a consideration. If you need the CPU performance to be more predictable however, look at the “m” series.

Since 2017, AWS added a "t2 Unlimited" option, where you could avoid the throttling for a time by "borrowing" credits from the future up to a set limit, and then paying a surcharge for CPU utilization beyond that (See our article https://blogs.iuvotech.com/aws-ec2-t2-unlimited-option for a more detailed explanation.) With the introduction of the "t3" generation, the Unlimited option is on by default, but you can choose the original credit/throttling model if you want billing to remain constant.

If you need more CPU power for heavy compute purposes but the RAM limits are OK, you can instead go for the "c" or "Compute" optimized instance type for a little less cost. Here a c5.large gets you 2 vCPU, but just 4GB RAM while a c5.xlarge doubles it to 4 vCPU and 8GB RAM. We use these for heavy-processing units such as grid computing where fast processors and more cores are a benefit.

Flipping the requirements, if what you need is more RAM, the "r" (“RAM”) memory-optimized instances double the RAM for the size over the "m" types, such that an r5.large gives you 16GB of RAM with the same 2 vCPU.

If you have some extreme RAM needs, like you need to run a large in-RAM database, AWS has added the "x1" types, the latest being "x1e", which offers an x1e.32xlarge with 128 vCPU and 3,904 GB of RAM! Beware though, it isn't cheap - almost $27 per hour! That could cost you close to $20,000 per month!

If you have need for fast cores AND RAM, the relatively new "z1d" types offer the same double-RAM sizes of the "r" series, plus a sustained 4.0GHz CPU performance on all cores and local NVMe temporary storage - basically the best of everything!

One of the newest general-purpose types is the new ARM-based instances, the "a" or “ARM” series. Rather than use an Intel-compatible processor, these use a custom-built "Graviton" CPU based on the 64-bit Cortex-A72 ARM processor, providing a good low-cost alternative for workloads that don't require a lot of horsepower. An a1.large tops out at 2 vCPU and 4 GB RAM, but costs about 40% less than a t3.large and you don't have to worry about throttling! It is also the only other instance type that offers a size smaller than "large", with an a1.medium option with 1vCPU and 2GB RAM. You just need to run a compatible OS. Sorry, but you won't be running Windows Server on it just yet, if ever, but Ubuntu, Red Hat and Amazon Linux are available. So, if you are looking for a low-cost scale-out flexible Linux platform, consider this one.

The various storage-optimized instances are, as you'd expect, optimized to provide for more storage-based needs. The "i" series provides high IOPS with up to 60TB of local NVMe SSD drives, "d" instances provide up to 48TB of local high-performance HDD-based storage, and "h" instances provide both local HDD storage and more of a balance in CPU and memory, which make these instances good for a variety of large data uses, such as scalable NoSQL database, data warehousing, distributed computing with MapReduce and Hadoop, and distributed file systems.

By the way, EC2 is not the only resource on AWS where you need to choose instance sizes. Several other resources, such as RDS, ElastiCache, etc. also provide their services by running on top of EC2 instances, so you choose your performance by choosing the appropriate instance type there as well. You just don’t need to manage the operating system etc. as it is all done for you. Those resources are usually more limited in choices, however. For instance, currently a MySQL RDS instance is limited to the current “t”, “m” and “r” instance types.

I hope this helps understand at least some of the instance types that are available to you and gives you a starting point for planning out your own instances based on your needs.

If you need further assistance with AWS Cloud services, we’re here to help! Contact us today.

------------------------------------------------------------------

¹Your machine image (AMI) needs to support the features of the new generation. For instance, t3 instances require support for the Amazon Enhanced Network Adapter (ENA) and NVMe built-in to the image. We built our own CentOS 6 images to meet some requirements that originally didn't have the ENA driver (it is not available by default on CentOS 6), so we couldn't start using t3 instances until we built a new image with it. But that's a different article to write…

²And I mean temporary! If the instance is stopped and started again, those disks will be blank - as in not even partitioned, never mind having a filesystem or any data that was there before. So use them wisely - or don't use them at all.