AWS Dedicated HostsNovember 13, 2017
Sometimes it’s just not desirable to have your Amazon EC2 instances deployed all willy-nilly across the AWS infrastructure. Sure it’s nice not having to manage the underlying infrastructure but in some cases you actually need to be able to manage the hosts themselves. One example is when you have licensing that is “old-fashioned” and uses physical core counts. With the default tenancy model, host core counts just don’t make sense, so what can we do?
Enter dedicated hosts. A dedicated host is an AWS physical server and hypervisor where you get to manage what goes on it. It’s dedicated in the sense that other customers can’t share that piece of hardware with you (however, note that the EBS volumes you use are still on shared infrastructure) so it’s yours to do as you please, well sort of.
Before We Start
Before we get started with using dedicated hosts, there are a few things you should be aware of in order to use the hosts efficiently.
- One host = one instance size – When you get a dedicated host from AWS, you must pick the size of the instances that will live on it, for example an M4.large instance type. This means that if you want to have M4.large and m4.xLarge instances, you’ll need two separate hosts. Also, depending on the size you select, a certain number of instances can be launched on that host before it’s out of space. For sizing please see: https://aws.amazon.com/ec2/dedicated-hosts/pricing/
- Only certain OS’s can be used – RHEL, SUSE Linux and Windows AMIs provided by AWS cannot be used with dedicated hosts. You’ll need to use your own AMIs, or the Amazon Linux AMIs. I believe this is due to licensing issues with those operating systems, but in any case be aware of this limitation.
- Instances must be Launched in a VPC – No big deal here, but you an have multiple instances on a single host and those instance can belong to different VPCs, but they must belong to a VPC.
- Autoscaling, RDS, and instance recovery are a no-go – Some features we’re accustomed to aren’t available with Dedicated Hosts
- You Pay for the Hosts – Maybe this is self-explanatory but when you order a dedicated host, you pay for that host and not the instances that reside on it. Use the host however you want, but you pay for the whole host. A host with a single instance on it might not be a good use of cash, but a fully loaded host might save you money over buying individual instances with default tenancy. Reserved instances are available for these hosts just like they are for EC2 instances which can save you money. The best savings dedicated hosts can get you though is usually related to the licensing of the instances where core counts matter.
Using Dedicated Hosts
To use dedicated hosts go to the Amazon EC2 console and select “Dedicated Hosts” in the menu. If this is the first time you’re using dedicated hosts, you’ll see a familiar getting started page. Click the “Allocate a Host” button.
Before AWS can give you a host to use, you must select an Instance type, Availability Zone and a quantity to order. I selected m4.large instances so those are the only sized instances I can use on this host. In addition, you must select whether or not you want untargeted instances to be allowed to be placed on this host. Basically this means that if you don’t specify a host, AWS might assign new instances to this host. For our purposes we’ll select no on the “Allow instance auto-placement” option. Click the “Allocate host” button.
When you’re done you should see a success message. Note: you might get an error saying you’ve hit a resource limit. I needed to request more resources from AWS before I was able to successfully complete this process.
As soon as you click the “View hosts” button you should see a host ready to go. You’ll notice that the host is available and has a utilization of 0/XX where XX is the total number of slots available for that instance type. If you refer to the table that was linked above, you’ll notice that 22 m4.large instances can be used. I now have 22 slots available for my to launch m4.large instances.
Now we can go about launching some new instances. Just go to the EC2 console and launch a new ec2 instance like you’ve probably done plenty of times. On the AMI screen, be sure to select an approved AMI such as the Amazon Linux AMI or your custom AMIs with BYOD licensing.
On the instance type screen be sure to select the instance type that matches your dedicated host type.
On the instance details screen we need to make some changes. Select the normal stuff including which VPC, number of instances etc. But you must make sure to select a subnet in the same AZ as where your dedicated host lives. It’s likely that you’ll have dedicated hosts in multiple AZs anyway, but pay attention to that. The big piece is to ensure that under Tenancy that “Dedicated Host” is selected. Once you do this, you’ll have two new drop downs in which selections need to be made.
Host: You can select Auto-Placement which (surprisingly) places your instances on any dedicated hosts that match the configuration or, select the individual host where the instance should be placed.
Affinity: Affinity lets you pin the instance to the host. If you set this to host then the instance will be stuck with this host after an instance reboot. If you leave this setting off, then a restart could cause the instance to start on another host with the same configurations.
Proceed through the rest of the normal EC2 launch settings. When you’re done you can look at your dedicated hosts and see that the utilization has changed. You can also see the instances listed in the bottom tab.
If you look in your EC2 instances console, you’ll also see the instance running there. So you can manage these instances within either screen.
Now if you’ve deleted all of the instances on a host, you can select the host and click the Actions drop down and then select “Release Hosts” to give the host back to AWS for the next customer.
Dedicated hosts have a purpose in the cloud. While specifying a host and managing the minute details about deployment might not seem like the tenets of cloud like “resource pooling”, it is a pretty valuable option for licensing reasons or for compliance purposes. Don’t rule them out in your environment.