AWS Cloud Practitioner Study Notes · Part 42
Amazon EC2 Instance Lifecycle: Reboot, Stop, Hibernate, and Terminate
AWS Cloud Practitioner study notes explaining EC2 lifecycle states, billing, IP address changes, EBS persistence, hibernation, and termination behavior.
The Amazon EC2 instance lifecycle describes what happens when an instance is launched, runs, reboots, stops, hibernates, starts again, or is terminated. The differences matter because each action affects compute billing, RAM, IP addresses, the underlying host, and EBS volumes differently.
This is Part 42 of the AWS Cloud Practitioner Study Notes. The highest-value exam distinction is:
Reboot → restart the operating system on the same instance
Stop → shut down and later start the instance, losing RAM
Hibernate → stop while saving RAM to the EBS root volume
Terminate → delete the instance permanentlyThe lifecycle at a glance
Launch
↓
Pending
↓
Running
/ | \
/ | \
Reboot Stop Hibernate
| ↓ ↓
| Stopped Stopped
| | |
└────┴── Start
↓
Pending
↓
Running
Running → Terminate → TerminatedEC2 may also display transitional states such as stopping, shutting-down, and terminating while an operation is in progress.
Pending
Pending is the preparation state after an instance is launched or started. AWS is allocating or preparing the resources needed to make the instance available, such as the underlying host, networking, EBS volumes, and operating system boot process.
Launch or Start
↓
Pending
↓
RunningThe instance is not ready for normal SSH, RDP, or application traffic while it is pending. User data may run during the boot process according to the operating system and user-data configuration; by default, EC2 user data scripts run on the first boot.
Running
In the running state, the instance is operational. You can connect to it, run applications, access attached storage, and call AWS APIs using an attached IAM role.
Compute charges apply while the instance is running. Other charges, such as EBS storage, may apply regardless of whether the instance is running.
Reboot
Rebooting is similar to restarting a physical computer:
Running
↓ Reboot
RunningThe instance remains on the same host computer. Its instance ID, private IPv4 address, EBS volumes, and Elastic IP remain associated. The operating system and applications restart, so RAM contents are cleared and there is a brief interruption.
An automatically assigned public IPv4 address also remains through a reboot. Rebooting does not stop compute billing.
Use reboot when the operating system needs a restart, a kernel update requires it, or an application needs to be restarted while preserving the instance and its network identity.
Application is slow
↓
Reboot
↓
Same instance, brief interruptionStop
Stopping shuts down an EBS-backed instance and releases its underlying host. When the instance is started again, AWS typically places it on a new host, although the exact host behavior can vary.
Running
↓ Stop
Stopped
↓ Start
Pending → RunningThe following normally remain:
- Instance ID
- Private IPv4 address
- EBS root volume and attached EBS data volumes
- Security-group associations
- IAM instance profile association
The following are lost or changed:
- RAM and CPU state are lost.
- An automatically assigned public IPv4 address is released and a new one is assigned on start.
- The underlying host may change.
An Elastic IP is the exception to the automatic public-IP change. An Elastic IP remains associated when the instance is stopped and started, subject to the association and current AWS pricing rules.
When stopped, the instance does not incur running-instance compute charges. You still pay for retained resources such as EBS volumes and snapshots. An Elastic IP may also incur charges depending on its state and AWS pricing rules.
Exam shortcut: stop a development instance overnight to avoid EC2 compute charges, but remember that EBS storage charges continue.
Start
Starting a stopped instance always moves it through pending before it returns to running:
Stopped
↓ Start
Pending
↓
RunningThe instance ID, private IPv4 address, EBS volumes, and security configuration generally remain. The automatically assigned public IPv4 address can change. Compute billing resumes when the instance is running.
Do not rely on an auto-assigned public IP as a permanent application endpoint. Use an Elastic IP, a load balancer, or DNS-based service discovery when the design requires a stable endpoint.
Hibernate
Hibernation is a specialised form of stopping. EC2 saves the contents of RAM to the encrypted EBS root volume, then shuts down the instance. On a later start, EC2 reloads the RAM contents and resumes the processes that were running.
Running
↓ Hibernate
RAM saved to EBS root volume
↓
Stopped
↓ Start
RAM restored and processes resumeHibernation can be useful when an application has a long startup process or when you want to preserve a warmed-up state. It is not the same as a normal stop: a normal stop loses RAM and starts the operating system fresh.
Hibernation requires an eligible EBS-backed instance and must be enabled at launch. Important requirements include:
- A supported Region, AMI, and instance family
- An EBS root volume rather than an instance-store root volume
- Enough encrypted root-volume space for the RAM image and operating system usage
- A supported EBS volume type
- A supported operating system and RAM size
Hibernated instances do not incur running-instance compute charges, but the EBS root volume and other retained resources continue to incur charges. The public IPv4 behavior follows stop/start behavior, so an automatically assigned address can change when the instance resumes.
Terminate
Termination permanently deletes the EC2 instance. A terminated instance cannot be restarted:
Running
↓ Terminate
TerminatedThe instance identity, RAM, CPU state, and associated temporary networking state are gone. By default, the root EBS volume is deleted when the instance terminates. Additional EBS volumes are preserved or deleted according to their DeleteOnTermination setting.
Example:
EC2 instance
├── Root EBS volume → Usually deleted by default
└── Data EBS volume → Depends on DeleteOnTerminationTermination ends EC2 instance charges, but any retained EBS volumes, snapshots, or other resources continue to incur charges until they are removed or their billing state changes.
Before terminating an important instance, verify backups, AMIs, EBS snapshots, data-volume settings, and dependencies. Termination protection can help prevent accidental termination, but it is not a backup.
Resource behavior comparison
| Resource or characteristic | Reboot | Stop and start | Hibernate | Terminate |
|---|---|---|---|---|
| Instance ID | Kept | Kept | Kept | Deleted |
| Private IPv4 address | Kept | Kept | Kept | Removed |
| Auto-assigned public IPv4 | Kept | New address on start | Can change on resume | Removed |
| Elastic IP | Kept | Kept | Kept | Disassociated or released according to configuration |
| EBS root volume | Kept | Kept | Kept | Usually deleted by default |
| Additional EBS volumes | Kept | Kept | Kept | Depends on DeleteOnTermination |
| RAM contents | Cleared | Lost | Saved to root EBS and restored | Lost |
| CPU state | Reset | Lost | Restored with hibernation | Lost |
| Underlying host | Same host | Typically new host | Typically new host | None |
| Running-instance compute charge | Continues | Stops while stopped | Stops while hibernated | Stops |
The table describes normal EBS-backed behavior. Special instance types, Spot Instances, network-interface configurations, and AWS-initiated events can have additional rules, so check the relevant EC2 documentation for production decisions.
Production scenarios
Reboot for a controlled restart
An application needs an operating-system restart after maintenance. Reboot the instance. The instance remains the same and its private network identity is preserved, but the application is briefly unavailable.
Stop a non-production environment
A development environment is not needed overnight. Stop it after working hours and start it the next day. This avoids running-instance compute charges while retaining EBS data. Do not depend on the automatically assigned public IPv4 address remaining unchanged.
Hibernate a warmed-up workload
An instance takes a long time to initialise its application state. If the instance and AMI meet the requirements, hibernate it so the RAM image is saved and restored later.
Terminate after migration
An application has moved to an Auto Scaling group or a replacement architecture. After verifying backups and data-volume settings, terminate the old instance. Do not assume that terminating the instance automatically deletes every attached EBS volume.
Common exam questions
Which action preserves RAM contents?
Hibernate.
Which action usually changes an automatically assigned public IPv4 address?
Stop and start, or hibernate and resume. An Elastic IP remains stable when it remains associated.
Which action keeps the instance on the same underlying host?
Reboot.
What state follows Start?
Pending, then Running.
Does a stopped instance incur EC2 compute charges?
No running-instance compute charges. EBS storage, snapshots, Elastic IP charges where applicable, and other retained resources can still cost money.
Can a terminated instance be restarted?
No. Termination is permanent for the instance. Recovery requires a backup, AMI, or another recovery mechanism.
Final memory map
Reboot
→ same host, RAM cleared, public IP kept, compute billing continues
Stop
→ host released, RAM lost, auto public IP may change, compute billing stops
Hibernate
→ RAM saved to encrypted EBS, compute billing stops, resume restores state
Terminate
→ instance deleted, root EBS usually deleted, cannot restartThe fastest exam sequence to remember is: Reboot = restart; Stop = shut down; Hibernate = save RAM; Terminate = delete.