Amazon Web Services (AWS) is the clear visionary in the public cloud market today. They have a vast selection of products and solutions, but they are first and foremost known for their EC2 (Amazon Elastic Compute Cloud) service – providing compute resources in the cloud.

When you go shopping for clothes you have a vast choice. You can choose a small, medium, large or even extra large size, according to your build or your weight. You can pick out stripes, circles, patterns or solid colors. What you choose depends on your preferences, your needs, and what you can afford.

Choosing a compute instance is no different. In this post, we will survey some of the flavors and types AWS has available for you and best-suited use cases for each of them. We will discuss AWS EC2 instances, including the different pricing models, types and flavors. And, although not quite a comparison of apples to apples, we will try to present them side-by-side with the available OpenStack options.

Click here to learn about AWS APIs and OpenStack APIs.

EC2 Instance Types and Flavors

On-Demand

This is the baseline compute offering of AWS. You can easily provision any type and size of compute resource and pay by the hour. AWS On-Demand instances are suitable for those who are getting their feet wet with AWS or for random or unplanned compute resource usage.

Reserved Instances (RIs)

When you pay upfront for an item, you can usually obtain a considerable discount because you are paying for something that you might not fully utilize; on AWS this is no different. In addition, purchasing RIs guarantees resources are available when demanded. There are three types of RI plans, including commitment with nothing upfront, paying all, or partial upfront. According to AWS, these can generate a significant cost reduction of up to 75%.

Spot Instances

Welcome to the stock market of AWS. You can specify what is the maximum you are willing to pay (your “bid”) per hour on a particular instance type. The spot price change between AWS regions is basically is set by AWS according to their available “spare” compute capacity. Instances are terminated when their price exceeds the maximum price you wanted to pay, so you need to have a resilient application architecture that will not be affected by instances going down. According to Amazon, using spot instances can generate costs saving of up to 90%.

Dedicated Hosts

Think of a dedicated host as just that – a full physical server that you own. You have complete control and visibility of the sockets and physical cores of the instance. Basically, the purpose of this resource is to support customers who can’t host their workloads on AWS shared compute infrastructure due to compliance and regulations.

AWS Flavors

Each of the aforementioned instance types comes in multiple flavors.

Each instance comprises three basic resources:

CPU RAM Disk

The flavors available in AWS today include:

T2 (General Purpose) : These instances start with a set baseline and the capability to burst above their default CPU capability . They are usually hosted on high-end CPU servers. These instances are limited in their CPU throughput, based on the CPU credit system that is used in AWS . This means you cannot use 100% CPU in this instance all day long; there is a limit on how much CPU can be used with these instances.

M4 and M3 (General Purpose) : These instances are suitable for small and mid-size databases; data processing tasks that require additional memory, caching fleets, and for running backend servers of enterprise applications.

C4 and C3 (Compute Optimized) : These instances support CPU intensive workloads, such as web-servers, batch processing, distributed analytics, high performance science and engineering applications, ad serving, MMO gaming and video-encoding.

X1 and R3 (Memory Optimized) : These instances are optimized for large-scale, enterprise-class, in-memory applications, such as databases and cache servers.

G2 (Graphics Optimized) : These instances are suitable for 3D application streaming, machine learning, video encoding and other applications that can make use of a server-side graphics or GPU processor.

I2 and D2 (Storage Optimized) : These instances are optimized for very disk intensive workloads or instances that require a very large amount of local storage.

The following table summarizes the instance types and their configurations:

Model vCPU CPU Credits / hour GPUs Mem (GiB) Storage SSD Storage (GB) Storage (GB) Dedicated EBS Bandwidth (Mbps) t2.nano 1 3 – 0.5 EBS-Only – – – t2.micro 1 6 – 1 EBS-Only – – – t2.small 1 12 – 2 EBS-Only – – – t2.medium 2 24 – 4 EBS-Only – – – t2.large 2 36 – 8 EBS-Only – – – m4.large 2 – – 8 – EBS-only – 450 m4.xlarge 4 – – 16 – EBS-only – 750 m4.2xlarge 8 – – 32 – EBS-only – 1,000 m4.4xlarge 16 – – 64 – EBS-only – 2,000 m4.10xlarge 40 – – 160 – EBS-only – 4,000 m3.medium 1 – – 3.75 – 1 x 4 – – m3.large 2 – – 7.5 – 1 x 32 – – m3.xlarge 4 – – 15 – 2 x 40 – – m3.2xlarge 8 – – 30 – 2 x 80 – – c4.large 2 – – 3.75 EBS-Only – – 500 c4.xlarge 4 – – 7.5 EBS-Only – – 750 c4.2xlarge 8 – – 15 EBS-Only – – 1,000 c4.4xlarge 16 – – 30 EBS-Only – – 2,000 c4.8xlarge 36 – – 60 EBS-Only – – 4,000 c3.large 2 – – 3.75 – 2 x 16 – – c3.xlarge 4 – – 7.5 – 2 x 40 – – c3.2xlarge 8 – – 15 – 2 x 80 – – c3.4xlarge 16 – – 30 – 2 x 160 – – c3.8xlarge 32 – – 60 – 2 x 320 – – x1.32xlarge 128 – – 1,952 – 2 x 1,920 – 10,000 r3.large 2 – – 15.25 – 1 x 32 – – r3.xlarge 4 – – 30.5 – 1 x 80 – – r3.2xlarge 8 – – 61 – 1 x 160 – – r3.4xlarge 16 – – 122 – 1 x 320 – – r3.8xlarge 32 – – 244 – 2 x 320 – – g2.2xlarge 8 – 1 15 – 1 x 60 – – g2.8xlarge 32 – 4 60 – 2 x 120 – – i2.xlarge 4 – – 30.5 – 1 x 800 SSD – – i2.2xlarge 8 – – 61 – 2 x 800 SSD – – i2.4xlarge 16 – – 122 – 4 x 800 SSD – – i2.8xlarge 32 – – 244 – 8 x 800 SSD – – d2.xlarge 4 – – 30.5 – – 3 x 2000 HDD – d2.2xlarge 8 – – 61 – – 6 x 2000 HDD – d2.4xlarge 16 – – 122 – – 12 x 2000 HDD – d2.8xlarge 36 – – 244 – – 24 x 2000 HDD –

OpenStack Instance Types and Flavors

OpenStack is a solution for the private cloud. The different options available from AWS mentioned above have been tweaked over the years, to match their user requirements and to maximize their monetization on each and every instance type.

AWS has invested considerable work in developing the supporting infrastructure for these instance types and flavors – mainly a metering and billing mechanism. In Openstack, these do not exist. This does not mean that you could not create the ecosystem to support such a business model – but it is not something that comes out-of-the-box with a vanilla installation of OpenStack. You will most probably have to create your own, or use a third-party tool to do it for you.

Check out this infographic for a look at OpenStack deployment tools.

Flavors

By default, these are the flavors available to you:

m1.tiny (1 VCPU/0 GB Disk/512 MB RAM)

m1.smaller (1 VCPU/0 GB Disk/1024 MB RAM)

m1.small (1 VCPU/10 GB Disk/2048 MB RAM)

m1.medium (2 VCPU/10 GB Disk/3072 MB RAM)

m1.large (4 VCPU/10 GB Disk/8192 MB RAM)

m1.xlarge (8 VCPU/10 GB Disk/8192 MB RAM)

You can create your own flavors within your OpenStack environment to suit your needs.

The following is an example script that creates a set of M3 instances (M3 was chosen because there are basically no specific features used; You can adapt the creation script to match your specific environment and different offerings. The SSD backed disks are substituted here by regular disks, without redundancy).

A simple CSV file containing the values for the flavors should be named flavors.csv:

Name,CPU,RAM,Disk

m3.medium,1,3840,4

m3.large,2,7680,32

m3.xlarge,4,15360,40

m3.2xlarge,8,30720,80

The syntax for the command is :

nova flavor-create FLAVOR_NAME FLAVOR_ID RAM_IN_MB ROOT_DISK_IN_GB NUMBER_OF_VCPUS

The script to create the flavors would be:

#!/bin/bash

INPUT=flavors.csv

OLDIFS=$IFS

IFS=,

[ ! -f $INPUT ] && { echo “$INPUT file not found”; exit 99; }

while read Name CPU RAM Disk

do

nova flavor-create $Name auto $RAM $Disk $CPU

done < $INPUT

IFS=$OLDIFS

Summary

Instance types and flavors allow you to choose the resource that best meets the requirements of your application based on different criteria. We discussed some of the criteria you should take into account when choosing a flavor. If you opt to implement an OpenStack solution, you can use a script similar to the one above to create a set of flavors that mirror those offered in AWS or create your own instance catalog to meet the requirements of your own private enterprise cloud.