EC2 Instance Lifecycle Overview
- EC2 instance lifecycle determines how an EC2 instance transitions through different states from the moment it is launched to its termination
EC2 Instance Lifecycle
Instance Launch
- Pending
- When the instance is first launched is enters into the pending state
- Running
- After the instance is launched, it enters into the running state
- Charges are incurred for each second, with a one-minute minimum, that the instance running is running, even if the instance remains idle
Instance Start & Stop (EBS-backed instances only)
- Only an EBS-backed instance can be stopped and started.
- Instance store-backed instance cannot be stopped and started.
- An instance can be stopped & started in case the instance fails a status check or is not running as expected
- Stop
- After the instance is stopped, it enters in stopping state and then to stopped state.
- Charges are only incurred for the EBS storage and not for the instance hourly charge or data transfer.
- While the instance is stopped, its root volume can be treated like any other volume, and modified for e.g. repair file system problems or update software or change the instance type, user data, EBS optimization attributes, etc
- Volume can be detached from the stopped instance, and attached to a running instance, modified, detached from the running instance, and then reattached to the stopped instance. It should be reattached using the storage device name that’s specified as the root device in the block device mapping for the instance.
- Start
- When the instance is started, it enters into pending state and then into running
- An instance, when stopped and started, is launched on a new host
- Any data on an instance store volume (not root volume) would be lost while data on the EBS volume persists
- EC2 instance retains its private IP address as well as the Elastic IP address.
- If the instance has an IPv6 address, it retains its IPv6 address.
- However, the public IP address, if assigned instead of the Elastic IP address, would be released
- For each transition of an instance from
stopped
torunning
, charges per second are incurred when the instance is running, with a minimum of one minute every time the instance is started
Instance Hibernate
- Instance hibernation signals the operating system to perform hibernation (suspend-to-disk), which saves the contents from the instance memory (RAM) to the EBS root volume
- Instance’s EBS root volume and any attached EBS data volumes are persisted, including the saved contents of the RAM.
- Any EC2 instance store volumes remain attached to the instance, but the data on the instance store volumes is lost.
- When the instance is restarted, the EBS root volume is restored to its previous state and the RAM contents are reloaded. Previously attached data volumes are reattached and the instance retains its instance ID.
- After the instance is hibernated, it enters in stopping state and then to stopped state.
- When the instance is restarted
- It enters the
pending
state and the instance is moved to a new host computer (though in some cases, it remains on the current host). - EBS root volume is restored to its previous state
- RAM contents are reloaded
- Processes that were previously running on the instance are resumed
- Previously attached data volumes are reattached and the instance retains its instance ID
- Instance retains private IPv4 addresses and any IPv6 addresses
- Instance retains its Elastic IP address
- Instance releases its Public IPv4 address and would get a new one
- It enters the
- Hibernation prerequisites
- Supported instance families – C3, C4, C5, M3, M4, M5, R3, R4, R5, & T2
- Instance RAM size – must be less than 150 GB.
- Instance size – not supported for bare metal instances.
- Supported AMIs must be an HVM AMI that supports hibernation
- Root volume type – must be EBS volume and not instance store
- EBS root volume size – must be large enough to store the RAM contents
- EBS root volume MUST be encrypted to ensure the protection of sensitive content that is in memory at the time of hibernation
- Enable hibernation at launch, as changing it is not supported on an existing instance
- Purchasing options – Only On-Demand Instances and Reserved Instances supported
- Limitations or Unsupported Actions
- Changing the instance type or size of a hibernated instance
- Creating snapshots or AMIs from hibernated instances or instances for which hibernation is enabled
- the data on any instance store volumes is lost
- can’t hibernate an instance that has more than 150 GB of RAM.
- can’t hibernate an instance that is in an Auto Scaling group or used by ECS. If the instance is in an Auto Scaling group is hibernated, the EC2 Auto Scaling service marks the stopped instance as unhealthy, and may terminate it and launch a replacement instance.
- An instance cannot be hibernated for more than 60 days.
Instance Reboot
- Both EBS-backed and Instance store-backed instances can be rebooted
- An instance remains on the same host computer and maintains its public DNS name, private IP address
- Data on the EBS and Instance store volume is also retained
- AWS recommends using EC2 to reboot the instance instead of running the operating system reboot command from the instance as it performs a hard reboot if the instance does not cleanly shut down within four minutes also creates an API record in CloudTrail if enabled.
Instance Retirement
- An instance is scheduled to be retired when AWS detects an irreparable failure of the underlying hardware hosting the instance.
- When an instance reaches its scheduled retirement date, it is stopped or terminated by AWS.
- If the instance root device is an EBS volume, the instance is stopped and can be started again at any time.
- If the instance root device is an instance store volume, the instance is terminated, and cannot be used again.
Instance Termination
- An instance can be terminated, and it enters into the shutting-down, and then the terminated state
- After an instance is terminated, it can’t be connected and no charges are incurred
- Instance Shutdown behavior
- Each EBS-backed instance supports the
InstanceInitiatedShutdownBehavior
attribute which determines whether the instance would be stopped or terminated when a shutdown command is initiated from the instance itself for e.g. shutdown, halt or poweroff command in linux - Default behavior for the instance to be stopped.
- A shutdown command for an Instance store-backed instance will always terminate the instance
- Each EBS-backed instance supports the
- Termination protection
- Termination protection (
DisableApiTermination
attribute) can be enabled on the instance to prevent it from being accidentally terminated DisableApiTermination
from the Console, CLI or API.- Instance can be terminated through EC2 CLI.
- Termination protection does not work for instances when
- part of an Autoscaling group
- launched as Spot instances
- terminating an instance by initiating shutdown from the instance
- Termination protection (
- Data persistence
- EBS volume has a
DeleteOnTermination
attribute which determines whether the volumes would be persisted or deleted when an instance they are associated with are terminated - Data on Instance store volume data does not persist
- Default is to delete the root device volume and preserve any other EBS volumes. i.e.
- Data on EBS root volumes have the
DeleteOnTermination
flag set to true and would be deleted by default - Additional EBS volumes attached have the
DeleteOnTermination
flag set to false are not deleted but just detached from the instance
- Data on EBS root volumes have the
- EBS volume has a
AWS Certification Exam Practice Questions
- Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
- AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
- AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
- Open to further feedback, discussion and correction.
- What does Amazon EC2 provide?
- Virtual servers in the Cloud
- A platform to run code (Java, PHP, Python), paying on an hourly basis.
- Computer Clusters in the Cloud.
- Physical servers, remotely managed by the customer.
- A user has enabled termination protection on an EC2 instance. The user has also set Instance initiated shutdown behavior to terminate. When the user shuts down the instance from the OS, what will happen?
- The OS will shutdown but the instance will not be terminated due to protection
- It will terminate the instance
- It will not allow the user to shutdown the instance from the OS
- It is not possible to set the termination protection when an Instance initiated shutdown is set to Terminate
- A user has launched an EC2 instance and deployed a production application in it. The user wants to prohibit any mistakes from the production team to avoid accidental termination. How can the user achieve this?
- The user can the set DisableApiTermination attribute to avoid accidental termination
- It is not possible to avoid accidental termination
- The user can set the Deletion termination flag to avoid accidental termination
- The user can set the InstanceInitiatedShutdownBehavior flag to avoid accidental termination
- You have been doing a lot of testing of your VPC Network by deliberately failing EC2 instances to test whether instances are failing over properly. Your customer who will be paying the AWS bill for all this asks you if he being charged for all these instances. You try to explain to him how the billing works on EC2 instances to the best of your knowledge. What would be an appropriate response to give to the customer in regards to this?
- Billing commences when Amazon EC2 AMI instance is completely up and billing ends as soon as the instance starts to shutdown.
- Billing commences when Amazon EC2 initiates the boot sequence of an AMI instance and billing ends when the instance shuts down.
- Billing only commences only after 1 hour of uptime and billing ends when the instance terminates.
- Billing commences when Amazon EC2 initiates the boot sequence of an AMI instance and billing ends as soon as the instance starts to shutdown.
Any data on an instance store volume (not root volume) would be lost while data on the EBS volume persists. Can you explain little more on the above point. I see different in documentation
Instances that use instance stores for the root device automatically have instance store volumes available, with one serving as the root device volume. When an instance is launched, the image that is used to boot the instance is copied to the root volume (typically sda1). Any data on the instance store volumes persists as long as the instance is running, but this data is deleted when the instance is terminated (instance store-backed instances do not support the Stop action) or if it fails (such as if an underlying drive has issues).
This behavior explains the scenario, where you can have an EBS-backed instance where the root volume is the EBS volume and the instance can have instance store volume attached as data volumes (which are not root volumes). In this case, if you restart the EBS-backed instance, the data on the instance store volumes would be lost while the EBS root volume may or may not persist depending upon the termination flag. Key point here is the Instance is restarted (stopped and started) which cannot be done if its a Instance Store-backed volume and Instance store volumes are data volumes
>>Key point here is the Instance is restarted which **** cannot be done if its a Instance Store-backed volume **** and Instance store volumes are data volumes
Instance store-backed instances can be restarted, right?
From http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html
The data in an instance store persists only during the lifetime of its associated instance. If an instance reboots (intentionally or unintentionally), data in the instance store persists.
restarted here is stopped and started cause that is the terminology i have seen been used. Instance store backed instance can be rebooted.
For answer to qn #4, I think the option should be “D”.
If you decide that you no longer need an instance, you can terminate it. As soon as the state of an instance changes to shutting-down or terminated, we stop charging for that instance
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html
From EC2 FAQs …
Q: When does billing of my Amazon EC2 systems begin and end?
Billing commences when Amazon EC2 initiates the boot sequence of an AMI instance. Billing ends when the instance terminates, which could occur through a web services command, by running "shutdown -h", or through instance failure. When you stop an instance, we shut it down but don't charge hourly usage for a stopped instance, or data transfer fees, but we do charge for the storage for any Amazon EBS volumes. To learn more, visit the AWS Documentation.
Table above says, you start incurring charges as soon as you enter shutting-down status. Is that table from AWS docs ?
yup thats an table from official AWS documentation ….
As per table above, question 4, Option D seems to be correct answer
For termination, its as per the EC2 FAQs
Q: When does billing of my Amazon EC2 systems begin and end?
Billing commences when Amazon EC2 initiates the boot sequence of an AMI instance. Billing ends when the instance terminates, which could occur through a web services command, by running "shutdown -h", or through instance failure. When you stop an instance, we shut it down but don't charge hourly usage for a stopped instance, or data transfer fees, but we do charge for the storage for any Amazon EBS volumes.
Yes, this is correct. I was referring to table just before questions. In table you specified, billing end as soon as ec2 instance enters shutting-down status.
Hi jay,
Again, I appreciate your good work here.
I already passed solution architect (score 916) and sysops (score 918) with a lot of help from your blog.
Now I am going to write the developer one.
I see a lot of back and forth about ec2 charges. regarding the question 4. I think option B is the correct one based on the table in aws link below:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html
none of the following states are chargeable except RUNNING state.
pending
RUNNING “Billable”
stopping
stopped
shutting-down
terminated
would you take a look at the table in the link and clarify this?
Thanks again,
farzin
Congrats farzinemami, thats a great score.
Actually the billing part of the EC2 has undergone a lot of changes from being charged per hour even for a partial use to per minute and second billing.
Hi Jayendra,
Your blog is amazing! Thank you very much for sharing your notes they are helping me a lot with my studies.
Regarding question 4, I agree it should be Option D
“You are not billed for any instance usage while an instance is not in the running state. In other words, when you terminate an instance, you stop incurring charges for that instance as soon as its state changes to shutting-down. ”
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesShuttingDown.html
It seems that EC2 FAQs are not specific enough. What are your thoughts?
Many thanks,
Francesc
EC2 FAQs do not cover the billing is much detail but they do have pretty much key information @ https://aws.amazon.com/ec2/faqs/#Billing
But agreed, for all the combinations you need to go through the documentation.
Hi JayendraPatil.
Need a clarity on the Question No 2.
Even though the termination protection is ON, how can the instance be terminated.?
Refer https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination
DisableApiTermination attribute does not prevent you from terminating an instance by initiating shutdown from the instance (using an operating system command for system shutdown) when the InstanceInitiatedShutdownBehavior attribute is set.
Hello Jayendra,
You may probably need to update the below statement:
Charges for full hour are incurred for every transition from stopped to running, even if the transition is within the same hour for e.g. if you stop and start your instances 2 times in an hour, you would be charged for 3 full hours, one for the start and then for the 2 transitions as if you had 3 instances running during that hour.
As per AWS documentation, their billing is now in minute wise.
“When you stop an instance, we shut it down. We don’t charge usage for a stopped instance, or data transfer fees, but we do charge for the storage for any Amazon EBS volumes. Each time you start a stopped instance we charge a minimum of one minute for usage. After one minute, we charge only for the seconds you use. For example, if you run an instance for 20 seconds and then stop it, we charge for a full one minute. If you run an instance for 3 minutes and 40 seconds, we charge for exactly 3 minutes and 40 seconds of usage.”