AWS Compute Blog
Understanding the lifecycle of Amazon EC2 Dedicated Hosts
This post is written by Benjamin Meyer, Sr. Solutions Architect, and Pascal Vogel, Associate Solutions Architect.
Amazon Elastic Compute Cloud (Amazon EC2) Dedicated Hosts enable you to run software on dedicated physical servers. This lets you comply with corporate compliance requirements or per-socket, per-core, or per-VM licensing agreements by vendors, such as Microsoft, Oracle, and Red Hat. Dedicated Hosts are also required to run Amazon EC2 Mac Instances.
The lifecycles and states of Amazon EC2 Dedicated Hosts and Amazon EC2 instances are closely connected and dependent on each other. To operate Dedicated Hosts correctly and consistently, it is critical to understand the interplay between Dedicated Hosts and EC2 Instances. In this post, you’ll learn how EC2 instances are reliant on their (dedicated) hosts. We’ll also dive deep into their respective lifecycles, the connection points of these lifecycles, and the resulting considerations.
What is an EC2 instance?
An EC2 instance is a virtual server running on top of a physical Amazon EC2 host. EC2 instances are launched using a preconfigured template called Amazon Machine Image (AMI), which packages the information required to launch an instance. EC2 instances come in various CPU, memory, storage and GPU configurations, known as instance types, to enable you to choose the right instance for your workload. The process of finding the right instance size is known as right sizing. Amazon EC2 builds on the AWS Nitro System, which is a combination of dedicated hardware and the lightweight Nitro hypervisor. The EC2 instances that you launch in your AWS Management Console via Launch Instances are launched on AWS-controlled physical hosts.
What is an Amazon EC2 Bare Metal instance?
Bare Metal instances are instances that aren’t using the Nitro hypervisor. Bare Metal instances provide direct access to physical server hardware. Therefore, they let you run legacy workloads that don’t support a virtual environment, license-restricted business-critical applications, or even your own hypervisor. Workloads on Bare Metal instances continue to utilize AWS Cloud features, such as Amazon Elastic Block Store (Amazon EBS), Elastic Load Balancing (ELB), and Amazon Virtual Private Cloud (Amazon VPC).
What is an Amazon EC2 Dedicated Host?
An Amazon EC2 Dedicated Host is a physical server fully dedicated to a single customer. With visibility of sockets and physical cores of the Dedicated Host, you can address corporate compliance requirements, such as per-socket, per-core, or per-VM software licensing agreements.
You can launch EC2 instances onto a Dedicated Host. Instance families such as M5, C5, R5, M5n, C5n, and R5n allow for the launching of different instance sizes, such as4xlarge
and 8xlarge
, to the same host. Other instance families only support a homogenous launching of a single instance size. For more details, see Dedicated Host instance capacity.
As an example, let’s look at an M6i Dedicated Host. M6i Dedicated Hosts have 2 sockets and 64 physical cores. If you allocate a M6i Dedicated Host, then you can specify what instance type you’d like to support for allocation. In this case, possible instance sizes are:
large
xlarge
2xlarge
4xlarge
8xlarge
12xlarge
16xlarge
24xlarge
32xlarge
metal
The number of instances that you can launch on a single M6i Dedicated Host depends on the selected instance size. For example:
- In the case of
xlarge
(4 vCPUs), a maximum of 32m6i.xlarge
instances can be scheduled on this Dedicated Host. - In the case of
8xlarge
(32 vCPUs), a maximum of 4m6i.8xlarge
instances can be scheduled on this Dedicated Host. - In the case of
metal
(128 vCPUs), a maximum of 1m6i.metal
instance can be scheduled on this Dedicated Host.
When launching an EC2 instance on a Dedicated Host, you’re billed for the Dedicated Host but not for the instance. The cost for Amazon EBS volumes is the same as in the case of regular EC2 instances.
Exemplary M6i
Dedicated Host instance selections: m6i.xlarge
, m6i.8xlarge
and m6i.metal
Understanding the EC2 instance lifecycle
Amazon EC2 instance lifecycle states and transitions
Throughout its lifecycle, an EC2 instance transitions through different states, starting with its launch and ending with its termination. Upon Launch
, an EC2 instance enters the pending
state. You can only launch EC2 instances on Dedicated Hosts in the available
state. You aren’t billed for the time that the EC2 instance is in any state other than running
. When launching an EC2 instance on a Dedicated Host, you’re billed for the Dedicated Host but not for the instance. Depending on the user action, the instance can transition into three different states from the running state:
- Via
Reboot
from therunning
state, the instance enters therebooting
state. Once the reboot is complete, it reenters therunning
state. - In the case of an Amazon EBS-backed instance, a
Stop
orStop-Hibernate
transitions the running instance into thestopping
state. After reaching the stopped state, it remains there until further action is taken. ViaStart
, the instance will reenter thepending
and subsequently therunning
state. ViaTerminate
from thestopped state
, the instance will enter theterminated
state. As part of aStop
orStop-Hibernate
and subsequentStart
, the EC2 instance may move to a different AWS-managed host. OnReboot
, it remains on the same AWS-managed host. - Via
Terminate
from therunning
state, the instance will enter theshutting-down
state, and finally theterminated
state. An instance can’t be started from theterminated
state.
Understanding the Amazon EC2 Dedicated Host lifecycle
Amazon EC2 Dedicated Host lifecycle states and transitions
An Amazon EC2 Dedicated Host enters the available
state as soon as you allocate it in your AWS account. Only if the Dedicated Host is in the available
state, you can launch EC2 instances on it. You aren’t billed for the time that your Dedicated Host is in any state other than available
. From the available
state, the following states and state transitions can be reached:
- You can Release the Dedicated Host, transitioning it into the
released
state. Amazon EC2 Mac Instances Dedicated Hosts have a minimum allocation time of 24h. They can’t be released within the 24h. You can’trelease
a Dedicated Host that contains instances in one of the following states:pending, running, rebooting, stopping
, orshutting
down. Consequently, you mustStop
orTerminate
any EC2 instances on the Dedicated Host and wait until it’s in theavailable
state before being able torelease
it. Once an instance is in thestopped
state, you can move it to a different Dedicated Host by modifying its Instance placement configuration. - The Dedicated Host may enter the
pending
state due to a number of reasons. In case of an EC2 Mac instance, stopping or terminating a Mac instance initiates a scrubbing workflow of the underlying Dedicated Host, during which it enters thepending
state. This scrubbing workflow includes tasks such as erasing the internal SSD, resetting NVRAM, and more, and it can take up to 50 minutes to complete. Additionally, adding or removing a Dedicated Host to or from a Resource Group can cause the Dedicated Host to go into thepending
state. From thepending
state, the Dedicated Host will reenter theavailable
state. - The Dedicated Host may enter the
under-assessment
state if AWS is investigating a possible issue with the underlying infrastructure, such as a hardware defect or network connectivity event. While the host is in theunder-assessment
state, all of the EC2 instances running on it will have theimpaired
status. Depending on the nature of the underlying issue and if it’s configured, the Dedicated Host will initiate host auto recovery.
If Dedicated Host Auto Recovery is enabled for your host, then AWS attempts to restart the instances currently running on a defect Dedicated Host on an automatically allocated replacement Dedicated Host without requiring your manual intervention. When host recovery is initiated, the AWS account owner is notified by email and by an AWS Health Dashboard event. A second notification is sent after the host recovery has been successfully completed. Initially, the replacement Dedicated Host is in the pending
state. EC2 instances running on the defect dedicated Host remain in the impaired
status throughout this process. For more information, see the Host Recovery documentation.
Once all of the EC2 instances have been successfully relaunched on the replacement Dedicated Host, it enters the available
state. Recovered instances reenter the running
state. The original Dedicated Host enters the released-permanent-failure
state. However, if the EC2 instances running on the Dedicated Host don’t support host recovery, then the original Dedicated Host enters the permanent-failure
state instead.
Conclusion
In this post, we’ve explored the lifecycles of Amazon EC2 instances and Amazon EC2 Dedicated Hosts. We took a close look at the individual lifecycle states and how both lifecycles must be considered in unison to operate EC2 Instances on EC2 Dedicated Hosts correctly and consistently. To learn more about operating Amazon EC2 Dedicated Hosts, visit the EC2 Dedicated Hosts User Guide.