When it comes to deploying EC2 instances within Amazon Web Services VPCs, you may find yourself confused when presented with those tenancy options. This post aims to describe the different options that you have with AWS tenancy and how they might be used.

First and foremost, what do we mean by tenancy? Well, tenancy determines who is the owner of a resource. It might be easiest to think of tenancy in terms of housing. For instance if you have a house then you could consider it a dedicated tenant since only one family presumably lives there. However, if you have an apartment building, there is a good chance that several families have rooms in a single building which would be more like a shared tenancy model.

AWS provides a few options for tenancy including dedicated or the default type of shared. These models work in a very similar fashion to the housing example above. Shared tenancy means that multiple EC2 instances from different customers may reside on the same piece of physical hardware. The dedicated model means that your EC2 instances will only run on hardware with other instances that you’ve deployed, no other customers will use the same piece of hardware as you.

Shared Tenancy – Default

The default tenancy model is the one most commonly used with AWS. Multiple customers will share the same pieces of hardware even though they don’t interact with each other. Remember that underneath the covers in AWS, there is a physical host with a hypervisor running on it to handle the virtualization of CPU, Memory, Storage etc. Customers will choose to deploy a new EC2 instance and AWS fits that instance onto the appropriate physical host and isolate it from other customers even if they’re sharing the same physical resources. This is generally the option that you will want to use unless you have regulatory compliance or licensing restrictions causing you to pick a dedicated model. The shared tenancy model is also the cheapest option for running your EC2 instances.

Dedicated Tenancy

As mentioned previously, dedicated tenancy ensures that your EC2 instances are run on hardware specific to your account but comes at a price. AWS usually focuses on driving down costs to operate their data centers and providing you your own isolated hosts to use makes that difficult. The result is that different charges need to be added to make it worthwhile to offer to their customers. Now, you might be asking why you’d want to use a dedicated tenancy model when there are pricing complications associated with them. In some cases due to licensing restrictions some software isn’t allowed to be run on a shared tenancy model. For instance if you’re trying to use Bring Your Own License (BYOL) to AWS, some licenses are based on the Socket model where the number of hosts sockets are used for licensing. In other circumstances, regulatory compliance may dictate that you can’t use the shared model. HIPAA up until earlier this year required dedicated tenancy to ensure data confidentiality. This restriction has since been removed.

There are two different options for dedicated tenancy with AWS: Dedicated Hosts and Dedicated Instances.

Dedicated Hosts

With a dedicated host, you purchase an entire physical host from AWS and that host is billed to you on an hourly basis just like EC2 instances are billed. Once you’ve purchased that host, you’re allowed to spin up as many EC2 instances as that host will allow for no additional charges. This might seem a lot like how you would manage an on-premises solution like vSphere. You buy and license the host and then you can move your instances on it until it’s full. Dedicated hosts have a few considerations that you should be aware of to ensure the proper usage and cost reductions.

You may not mix EC2 instance types on the same dedicated host – If you purchase a dedicated instance you must decide what type of instance that you will be placing on it. For example you would purchase an m4.large host meaning that you could put as many m4.large instances on that host that you want up to the maximum (22 as of this writing) but you are not allowed to add m3.large or m4.xlarge for example. If you want to add m4.xlarge instances on dedicated hosts then you must purchase another dedicated host.

You are responsible for waste – As with the previous example, you’ll be paying for the entirety of the dedicated host. It does not make sense to purchase a dedicated host to run a single VM and leave 21 additional slots available that are unused. You’ll pay for the whole host so if you aren’t fully utilizing them, you’re wasting money.

Each host type has different maximums – Since each EC2 instance type has a different amount of CPU, Memory and storage, the dedicated hosts will offer different maximums by instance type. The current breakdown for m4 and m3 dedicated hosts are shown below but be aware that they are subject to change. Please check the latest AWS documentation for up to the minute changes.

Primary Use Cases – In addition to the compliance purposes, dedicated hosts are used for licensing purposes when the license model requires you to use sockets or cores. Specifically this option is most often used with Microsoft BYOL situations where the customer doesn’t have Software Assurance or the product doesn’t have license mobility. Since you can control the placement of workloads and ensure the socket count is being properly maintained, this option can be used. Also, if you fill the host to capacity, this option may be cheaper than the shared tenancy model but you must manage that capacity wisely.

Dedicated Instances

With a dedicated instance, you’re still receiving the benefits of having separated hosts from the rest of the AWS customers but you are not paying for the entire host all at once. You do not need to worry about the capacity of the hosts but you’re being charged a higher rate for the instances. This type of instance model is similar to the default model where you don’t worry about where the instances are, but it does ensure they’re kept separate. In addition to the higher rate that you’re charged for dedicated instances, you’re also charged a $2 per hour charge per region where dedicated instances are being used. You should be aware though, that even though the instances are on dedicated hardware, if they are using Elastic Block Storage (EBS) devices, they will be on shared hardware. The dedicated instance tenancy doesn’t include their virtual disks unless you choose instance storage.

The following table shows the price differences between some m3 and m4 instances using the default tenancy or the dedicated instance tenancy in AWS.

Dedicated Instances Use Cases – Dedicated instances might be used if you have compliance reasons that require that hosts are not shared between customers, but you don’t want to manage all of the hosts. This model can be used with BYOL options for anything licensed by the user such as Windows Desktops operating systems or MSDN as examples. The use of dedicated instances does not require License Mobility or Software Assurance. The biggest note though is that Microsoft Server licenses do not support the BYOL model here. You must purchase the licenses with the instance if you plan to use them here.

Summary

The figure below should provide a good overview of the main differences between the tenancy models. Shared will include your instances with other customers while the dedicated model ensures that only your instances will run on those hosts. Dedicated hosts are entire hosts of different sizes that are available for you to fill up as you need while dedicated instances are similar to the shared model without other customers.