Amazon Web Services added nearly three new services per day in 2016. The challenge for the many traditional virtualization administrators and operations teams is that we are up against the velocity of AWS when organizations ask about how to get better at the business of IT. The sheer size of AWS and the breadth of services can seem overwhelming at first, so this is meant to be a simplified and quick guide to the most commonly used service to provide compute power in the AWS cloud. This is where Elastic Cloud Compute, or EC2 for short.
A Primer on AWS EC2 Instances
Amazon EC2 is a distributed compute environment which provides on-demand, reserved, spot, and scheduled instances to AWS customers through their self-service web portal or through the AWS public-facing API. Each instance is launched from an AMI which can be a commercial platform or an open source platform ranging form the base operating system all the way up to packaged applications included in the AMI. Let’s start with what the the first part of this means.
AMI
An AMI is an Amazon Machine Image. These can be the Amazon Linux derivative, or any of an array of linux or Microsoft Windows distributions. They can also include pre-installed applications which are also from both open source and commercial software vendors. The AMI catalogs include those from the AWS Marketplace ( https://aws.amazon.com/marketplace/ ) as well as those from the Community Marketplace
On-Demand Instances
The EC2 on-demand instances are provided on a per-hour billing basis based on the flavor size that you choose. We will get into the flavor sizes shortly, but the key thing to remember with on-demand is that it is at the current hourly rate and you are billed for the usage as long as you have allocated the instance.
You are charged for the use of your instances from the moment that you deploy them until you terminate and remove the resources. Even instances that are powered down are still being billed for because they are consuming space within the EC2 platform. This is important to know as you think about how to manage instances you may not be using actively. They still cost you money even when they are just sitting in an idle state.
Reserved Instances
If you’re looking to save some money on long running EC2 instances, you can buy what are called reserved Instances. This means that you buy a contract for a longer term which can significantly reduce your recurring costs. The longer the contract, the lower the per-hour rate is for EC2 Reserved Instances. Reserved instances are allocated to a region and will be applied to any active instance that you have deployed. In other words, you buy a reservation, and it will put any EC2 on-demand instance that matches into the reservation.
Spot Instances
The AWS spot instances can be compared to when a hotel has empty rooms and decides to offer them at reduced prices as you get close to the date. You can’t guarantee the price will be lower, but imagine if you could say “if the price of a room at the Four Seasons goes to 149$ a night, I’ll take it”. This is the idea of spot instances. You put in a price at which you’ll deploy instances as a lower and upper bound, and if they become available, you get them at that rate. It’s a variable marketplace and pricing configuration that is best used for more advanced AWS consumers who know they can add resources to bulk up their infrastructure based more on price than on specific performance metrics.
Scheduled Instances
There will be times when an on-demand instances are what you need in a specific time frame. This is where the scheduled instances come in. If you have an application you know needs to be scaled out or launched during specific times windows, you can use Scheduled instances to achieve this. This is somewhat different than spot instances, since it uses pricing. Your scheduled instances may qualify as reserved instances if you have an unused reservation at the time a scheduled instance is launched.
AWS EC2 Instance Types
As of AWS re:Invent in November of 2016, there are
T Series – Burstable Instances
These are described as the burstable instances. You can deploy a T series instance and spin up a variety of sizes from nano (512 MB RAM, 1 vCPU) to 2xlarge (32 GB RAM, 8 vCPU). This gives you a lot of variety to choose from when sizing your instance on the EC2 shared infrastructure. These are probably the most popular instances because they also present the lowest costs to operate in the nano, micro, and small sizing.
M Series – General Purpose Instances
These instances are like the burstable instances but with a more high-end virtual hardware allocated to them. They range from the large (8 GB RAM, 2 vCPU) to 16xlarge (256 GB RAM, 64 vCPU). The costs are rather high in the upper end of the M series instances as you can imagine.
C Series – Compute Optimized Instances
Compute optimized instances are those which only come with multi-CPU flavors and provide slightly more access to the highest performance CPU hardware in the EC2 platform.
x1 and R Series – Memory Optimized Instances
These instances are geared towards memory-intensive applications and provide a better cost flavor for increased memory within each of the available flavors over the similar instances from the burstable and general purpose flavors.
I and D Series – Storage Optimized Instances
This series puts the I in Intensity and D in Density. For high throughput storage needs, the I series will provide higher I/O capabilities to the underlying storage. D series will answer the needs of the more dense storage that handles larger storage-backed instances.
G Series – Graphics Intensive
Looking for a little more graphics power on your EC2 instance? This is where the G classification will help you out. This is ideal when looking at doing graphical work such as virtual gaming, CAD, and other graphically intensive application environments.
P Series – General Purpose GPU
In the past, you had to assign a GPU enhanced instance. Using the newly available GPU assignments within the EC2 environment, you have a lot more flexibility around enabling GPU-backed instances in your EC2 environment.
Previous Generation Instances
There are a number of instance flavors which you may still see around. These include the T1, M1, C1, CC2, M2, CR1, CG1, HI1, and HS1 instance types. As AWS moves ahead, these are being deprecated in favor of the newly assigned EC2 flavors.
Welcome to the EC2 Platform!
Hopefully this is a good start on understanding some of the differences of EC2 flavor sizes at a high-level.
Knowing the available instance types is a great way to get started on planning your deployment on AWS EC2. If you’re just starting to get think about moving to AWS, make sure to check out this article which has some ideas on what you should be thinking about. The Lightsail set of instance types was not included because it is quite different in what it is solving for EC2 customers. The FPGA instances will also be covered in a future post as this is a subject that deserves more in depth coverage.