An instance can be stopped & started in case the instance fails a status check or is not running as expected
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.
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 to running, charges per second are incurred when the instance is running, with a minimum of one minute every time the instance is started
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
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.
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.
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.
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
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
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
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.