ra2 studio - Fotolia
AWS currently has five categories of EC2 instance families: general purpose, compute-optimized, graphics processing...
unit instances, memory-optimized and storage-optimized. Within each family, there are several specific types of EC2 instances, each of which is available in different sizes.
Each time AWS upgrades an Elastic Compute Cloud (EC2) instance type, it continues to support the old one and bumps up the version number. For example, the original Amazon EC2 instance type was M1. When AWS added new hardware, a new instance type -- M2 -- was created. By mid-2016, the most current instance type was M4.
The type of workload your organization runs will indicate which instance type is best. For most applications, the generic instance families are a good start. After running an application on a generic instance and monitoring CPU and memory use in Amazon CloudWatch, an administrator may determine if he needs to switch to a different type.
In general, when starting new workloads, it's best to choose the most current generation of EC2 instance types. Often, they are the cheaper and faster options. For example, the M1.large costs 17.5 cents per hour, and has 4 EC2 Compute Units (ECU) and 7.5 GB of RAM; the M4.large costs 12 cents per hour, and has 6.5 ECU and 8 GB of RAM.
When selecting between types of EC2 instances, you can only modify the size. With Reserved Instances, if an admin bought an M4.large and decided to switch to a bigger instance, he can bump that up to an M4.xlarge, but he can't increase the CPU by switching to a C4.large.
The T type and the M types of EC2 are generic. The biggest difference between those types of EC2 instances is that the T is smaller, but contains burst capacity. This is ideal for websites that experience nonstandardized traffic. For example, if a website has only occasional usage, it doesn't need 100% CPU all the time, so a T type would be ideal. But if it has a steady amount of traffic, an M type is preferred.
Compute-optimized instances offer more CPU and less RAM. For example, the C4.large offers 8 ECU, but only 3.75 GB of RAM. This is ideal for CPU-intensive applications, such as build scripts or heavy calculations. If you notice servers using 100% CPU, but only 20% RAM, you may want to consider switching to a compute-optimized instance type.
RAM-optimized instances are the reverse of the compute-optimized instances, offering lower CPU, but more RAM. This is ideal for applications, such as in-memory cache systems or indexing systems. Apache Solr or other full-text indexing applications may work well with RAM-optimized instances, as they can load more of the indexes in RAM instead of having to queue from disks.
Storage-optimized instances also come in two flavors: I and D types. While I types have solid-state drives (SSDs), D types have regular hard drives. These types of EC2 instances are ideal for database-style applications that are focused more on data storage than accessing data. SSDs are significantly faster, but are also much more expensive than traditional hard disk drives. If speed is a priority, choose the I type. Otherwise, go with the less-costly D type.
The last instance family is the most unique. Graphics processing unit-optimized instances are ideal for heavy math processing and are used extensively in scientific processing, such as genome sequencing. They are expensive -- the cheapest G2.xlarge costs 65 cents per hour. If you do need a G-type instance, check the Spot Instances market. If an admin is doing batch processing, he might as well get the compute power for less money.
Each application has different needs, so it's important to select the appropriate EC2 instance type and size. When it comes to size, a good bet is to start small and see how fast the application runs. Picking a size too large means spending more money than needed; shoot for about 75% CPU usage, and then scale out as appropriate.
Keep in mind that you should optimize an application for the number of offered CPUs. M4.large provides two vCPUs; bumping up to the M4.xlarge increases the output to four vCPUs and even more RAM. It's not always best to bump up the instance size, as two large instances cost essentially the same as one xlarge. Instance sizes allow admins to scale up, if needed, but they also make it harder to dynamically adjust the size. It's easy to remove an instance; it's harder to change the instance size.
Large instances are suitable when using a build instance. Build instances are ideal for developers because they don't have to rely on having powerful machines available. For example, a company could use several C4.2xlarge instances only when it needs to build something. Picking a very large instance type for this scenario is ideal, because it builds faster and admins spend less time waiting for processing to complete. While it can be costly to use a C4.2xlarge, it's more expensive to use a smaller instance and have developers sit around waiting for something to complete. When picking instance sizes, keep in mind the cost of picking something too small. Don't forget to turn off instances when they aren't building; use an Elastic Block Store-backed instance to easily start and stop the instance.
In general, keep instance sizes small, but don't be afraid to scale out as needed, and be prepared to occasionally launch that 2xlarge instance with high CPU if a developer needs something to finish quickly. It's also good to check CloudWatch metrics for instances and watch for bottlenecks. This allows an admin to choose a more appropriate instance classification, depending on how much CPU and RAM the application uses.
Meet the family of AWS EC2 instances
HVM instance type gets preferred treatment
In microservices deployments, t2.nano instance good fit