EC2 Instance Lifecycle and State Transitions – SAP-C02 Study Guide

Purpose of This Lesson

Understanding the EC2 instance lifecycle is essential for selecting the right operational action, preserving or discarding data correctly, controlling costs, and interpreting exam scenarios involving maintenance, host failures, or instance recovery.

An EC2 instance is launched from an Amazon Machine Image (AMI) and moves through several states. The behavior of storage, memory, IP addresses, billing, and the underlying host depends on the transition selected.

Key Concepts

EC2 instance states

The primary lifecycle states are:

• Pending: AWS is launching the instance and preparing its operating system and resources.
• Running: The instance is available for normal use and compute billing applies.
• Stopping: AWS is shutting down an EBS-backed instance before placing it in the stopped state.
• Stopped: The instance is powered off but its EBS volumes remain available. It can be started again.
• Shutting-down: The instance is being permanently deleted.
• Terminated: The instance has been deleted and cannot be restarted.

A normal launch follows this path:

AMI -> pending -> running

A stop/start cycle follows this path:

running -> stopping -> stopped -> pending -> running

Termination follows this path:

running or stopped -> shutting-down -> terminated

Reboot versus stop and start

An EC2 reboot is equivalent to an operating system reboot. It does not normally move the instance to a new underlying host.

A stop followed by a start generally causes AWS to place the instance on a different physical host. This makes stop/start useful when:

• AWS schedules maintenance on the current host.
• The host is experiencing a hardware or platform problem.
• A system status check indicates an underlying infrastructure failure.
• The workload can tolerate downtime and the operator wants to force host migration.

AWS generally recommends using the EC2 reboot action rather than issuing an operating system reboot when an EC2 reboot is appropriate.

Stopping an instance

Stopping is supported for EBS-backed instances. An instance whose root volume is backed by instance store cannot be stopped; it must remain running or be terminated.

When an EBS-backed instance is stopped:

• EC2 instance usage charges stop.
• EBS volumes remain and continue to incur storage charges.
• Data in instance memory is lost.
• The instance is normally moved to another host when it is started again.
• Private IPv4 and IPv6 addresses are retained.
• A dynamic public IPv4 address is released and a new one may be assigned at the next start.
• An associated Elastic IP address is retained, subject to the normal Elastic IP billing and association rules.
• The instance ID remains the same.

The default behavior is for the root EBS volume to be deleted when the instance is terminated. This behavior can be changed with the volume’s DeleteOnTermination setting. Important data should not depend solely on the root volume; use suitable backups, snapshots, or durable data services.

Hibernation

EC2 hibernation is a specialized stop operation. Before stopping, the contents of RAM are written to the root EBS volume. When the instance starts again:

1. The root volume is restored.
2. RAM contents are loaded back into memory.
3. Previously running processes resume.
4. Previously attached data volumes are reattached.
5. The instance retains its instance ID.

Hibernation must be enabled when the instance is launched, and only supported instance types, AMIs, operating systems, and configurations qualify. The root volume must have enough capacity for the memory image. Hibernation is therefore not a universal replacement for stop/start.

Elastic IP addresses remain associated with supported hibernating instances. As with ordinary stopping, verify the supported configuration and account for EBS storage costs while the instance is hibernated.

Termination

Termination permanently deletes the instance. A terminated instance cannot be recovered or restarted.

By default, the root EBS volume is deleted during termination, while additional EBS volumes may use different DeleteOnTermination settings. Instance store data is also ephemeral and should never be treated as durable storage.

Before terminating an important workload, confirm that:

• Required data has been copied to durable storage.
• EBS snapshots or application-level backups exist where appropriate.
• The termination protection setting is understood.
• Dependent resources such as Elastic IP addresses, security groups, and load balancer registrations are handled correctly.

Instance retirement

AWS may retire an instance when it detects an irreparable failure in the underlying hardware. AWS can stop or terminate the instance around its scheduled retirement date, depending on the event and instance configuration.

Use the AWS Health Dashboard or Personal Health Dashboard to identify scheduled infrastructure events. A planned stop/start, where supported, can move an instance away from a host scheduled for maintenance. For workloads that require stronger resilience, use multiple instances across Availability Zones rather than relying on a single instance.

EC2 recovery

Amazon CloudWatch can monitor EC2 system status checks. For certain failures caused by underlying hardware or AWS platform issues, an automated CloudWatch action can recover the instance.

Recovery is intended to preserve the instance’s configuration and identity, including the instance ID and networking characteristics associated with the instance. Recovery is different from rebooting and different from launching a replacement from an AMI. It is not a substitute for application-level redundancy or backups.

Exam-Relevant Takeaways

• Stop/start requires EBS-backed storage; instance-store-root instances cannot be stopped.
• Stopping loses RAM contents. Hibernation preserves RAM by writing it to the root EBS volume.
• Stopping does not stop EBS charges. EBS volumes remain provisioned and billable.
• Private IP addresses remain stable across stop/start, while a non-Elastic public IPv4 address is released.
• Elastic IP addresses are retained when the instance is stopped or hibernated, assuming the association remains in place.
• Reboot preserves the instance’s network identity and does not affect billing.
• Stop/start can move an instance to another host; reboot generally cannot solve an underlying host failure.
• Termination is irreversible. Do not select it when the requirement is temporary shutdown or host migration.
• Hibernation must be configured at launch and has instance, AMI, operating system, and memory-size prerequisites.
• System status checks indicate AWS infrastructure or instance-system problems, while instance status checks generally concern the guest operating system and configuration.
• CloudWatch recovery addresses certain host or platform failures, but multi-AZ deployment is the stronger architectural answer for high availability.

Architecture Decision Guide

Requirement or situation	Recommended action	Important consequences
Temporarily power off an EBS-backed development instance	Stop	EC2 compute charges stop, but EBS charges continue; RAM is lost
Move an instance away from a problematic or scheduled host	Stop, then start	Causes downtime and may change the public IPv4 address
Restart the operating system without changing the host	Reboot	Network addresses and DNS name are retained
Resume a memory-intensive process quickly	Hibernate	Requires launch-time support and sufficient root EBS capacity; EBS charges continue
Permanently delete an instance	Terminate	Irreversible; root EBS data is normally deleted by default
Respond to an eligible underlying host or platform failure	CloudWatch status-check recovery	Preserves the instance identity but does not provide application-level redundancy
Protect a production service from host or AZ failure	Use multiple instances across Availability Zones, often behind a load balancer	Requires stateless design, shared or replicated data, and automated replacement

Common Exam Traps

• Confusing stop with terminate: Stop is reversible for EBS-backed instances; termination is permanent.
• Assuming stopped means free: EC2 compute charges stop, but attached EBS volumes and other resources continue to incur charges.
• Expecting a public IPv4 address to remain unchanged: Only an Elastic IP is designed to remain associated through stop/start.
• Using reboot to fix a host failure: Reboot restarts the guest OS but generally does not migrate the instance to a new host.
• Assuming hibernation works automatically: Hibernation must be enabled at launch and is limited to supported configurations.
• Treating instance store as durable: Instance store data is ephemeral and is lost when the instance is stopped, terminated, or moved as part of certain lifecycle events.
• Assuming recovery replaces high availability: Recovery handles selected infrastructure failures for one instance; it does not protect an application from all host, AZ, software, or data failures.
• Forgetting the root-volume deletion setting: Termination normally deletes the root EBS volume, but DeleteOnTermination controls the behavior.

Real-World Engineer Notes

• Use Auto Scaling groups and multi-AZ placement for services that must survive instance or host failure. A single recoverable instance is still a single point of failure.
• For stateful workloads, separate the operating system from durable data. Store data on appropriately protected EBS volumes, managed databases, or other durable AWS services.
• Use Elastic IP addresses only when a stable public address is genuinely required. For most web workloads, DNS, load balancers, or service discovery provide a more resilient abstraction.
• Before a planned stop/start, verify application shutdown behavior, data consistency, monitoring, and startup automation.
• Instance retirement notifications should trigger a controlled replacement or migration process rather than a last-minute manual response.
• Test hibernation and recovery with the exact AMI, instance type, operating system, and workload. Support and performance characteristics are configuration-specific.
• Use CloudWatch alarms and Systems Manager automation where appropriate, but ensure automated actions do not create data-loss or restart loops.

Quick Reference Summary

• Reboot: OS restart; retains IP addresses and DNS name; no lifecycle billing change.
• Stop: Available for EBS-backed instances; loses RAM; retains private IPs; releases dynamic public IPv4; EBS charges continue.
• Start: Returns a stopped instance through pending to running and may place it on a new host.
• Hibernate: Saves RAM to the root EBS volume and resumes processes later; must be enabled at launch.
• Terminate: Permanent deletion; default root EBS deletion applies.
• Retirement: AWS-initiated action due to irreparable host hardware failure or scheduled maintenance.
• Recovery: CloudWatch-assisted recovery for eligible system or platform failures; not a replacement for redundancy.

Flashcards

1. Q: Which EC2 instances can be stopped?

A: EBS-backed instances. Instances with an instance-store root volume cannot be stopped.

1. Q: What happens to RAM during a normal stop?

A: RAM contents are lost.

1. Q: What happens to RAM during hibernation?

A: RAM is written to the root EBS volume and restored when the instance starts.

1. Q: What happens to EBS charges when an instance is stopped?

A: EBS storage charges continue because the volumes remain provisioned.

1. Q: Which IP address types are retained through stop/start?

A: Private IPv4, IPv6, and associated Elastic IP addresses are retained; a dynamic public IPv4 address is released.

1. Q: What is the main difference between reboot and stop/start?

A: Reboot restarts the OS and generally keeps the same host; stop/start powers off the instance and generally moves it to another host.

1. Q: Can a terminated EC2 instance be restarted?

A: No. Termination is permanent.

1. Q: What is the default fate of the root EBS volume at termination?

A: It is normally deleted, controlled by the DeleteOnTermination attribute.

1. Q: When should hibernation be enabled?

A: At instance launch, provided the AMI, operating system, instance type, and storage configuration support it.

1. Q: What kind of failure can EC2 recovery address?

A: Certain underlying hardware or AWS platform failures detected through system status checks.

1. Q: What AWS dashboard helps identify scheduled instance retirement?

A: The AWS Health Dashboard, including account-specific Personal Health Dashboard events.

1. Q: Is EC2 recovery equivalent to multi-AZ high availability?

A: No. Recovery helps restore one eligible instance; multi-AZ architecture protects the application against broader failures.

Practice Questions

Question 1

A company runs a development server using an EBS-backed EC2 instance. The server is used only during business hours. The company wants to reduce compute costs overnight but must preserve the attached data volumes. Which action should it automate?

A. Terminate the instance and recreate it from the AMI each morning
B. Stop the instance at night and start it in the morning
C. Reboot the instance at night
D. Delete the EBS volumes overnight

Correct answer: B

Explanation: Stopping an EBS-backed instance eliminates EC2 compute charges while retaining its EBS volumes. Rebooting does not stop compute billing, and terminating risks permanent data loss and requires recreation.

Question 2

An EC2 instance reports a system status check failure. The workload is not currently deployed across multiple instances. The organization wants an automated response that attempts to restore the instance while preserving its identity. Which solution is most appropriate?

A. Configure a CloudWatch alarm to recover the instance
B. Reboot the instance from inside the operating system
C. Terminate the instance and wait for AWS to restore it
D. Stop the instance store volume and restart it

Correct answer: A

Explanation: CloudWatch can invoke EC2 recovery for certain underlying hardware or platform failures detected by system status checks. Rebooting may not move the instance off a failed host, and termination is irreversible.

Question 3

A company stops and later starts an EC2 instance. The instance must continue using the same private address, but its public address may change. Which networking behavior makes this possible without additional configuration?

A. The private IPv4 address is retained, while the dynamic public IPv4 address is released
B. Both addresses are released and reacquired from the same pools
C. The public IPv4 address is retained, while the private IPv4 address changes
D. Both addresses are retained only when the instance uses instance store

Correct answer: A

Explanation: Private IPv4 addresses remain associated with the network interface through stop/start. A non-Elastic public IPv4 address is released when the instance stops and may change when it starts again.

Question 4

A stateful application takes several minutes to rebuild its in-memory cache after a shutdown. The company wants the application to resume its processes and memory state after a planned pause. Which EC2 capability should the architect evaluate?

A. Reboot
B. Hibernation
C. Termination protection
D. Instance retirement

Correct answer: B

Explanation: Hibernation saves RAM contents to the root EBS volume and restores them on startup, allowing supported workloads to resume processes. It must be enabled at launch and requires a supported configuration with adequate root-volume capacity.

Question 5

An EC2 instance is scheduled for retirement because AWS identified an issue with its underlying hardware. The workload can tolerate a short maintenance window, and the organization wants to move the instance to a different host before the retirement date. Which action should be considered first?

A. Reboot the instance repeatedly
B. Stop and start the instance during an approved maintenance window
C. Change the instance security group
D. Disable system status checks

Correct answer: B

Explanation: A stop/start cycle generally places the instance on a different host and can address planned host maintenance when the instance type and storage configuration support stopping. Rebooting generally does not migrate the instance to another host.