EC2 Instance Lifecycle Lab — Stop, Start, Terminate & What Really Happens

Introduction

Here’s something that might surprise you: I’ve seen production outages caused not by complex architectural failures, but by engineers who didn’t fully understand what happens when you click “Stop” on an EC2 instance. One team lost their application’s public endpoint because nobody realized the public IP would change on restart. Another team thought stopping an instance was the same as pausing a video—they expected everything to resume exactly as before.

This lab teaches you what actually happens behind the scenes during EC2 instance lifecycle transitions. We’re going beyond the documentation bullet points into the reality of how AWS handles your instance when you stop it, start it again, or terminate it permanently.

Why does EC2 lifecycle knowledge matter in real AWS environments? Because in production, assumptions get expensive. When you stop an instance, AWS releases it from the underlying host. When you start it again, it might land on completely different hardware. That public IP your application depends on? Gone. That root volume you thought would disappear on termination? It might still be there, quietly accumulating storage charges.

Who is this lab for? Anyone preparing for AWS certifications, DevOps engineers managing EC2 fleets, developers who deploy to AWS, or anyone who wants to stop guessing and start understanding what their infrastructure actually does.

From an architect’s perspective, lifecycle misunderstandings are among the most common sources of confusion I encounter. Engineers often conflate “stop” with “hibernate,” assume EBS volumes always get deleted on termination, or don’t realize that a stopped instance still incurs EBS storage costs.

Common beginner mistakes I see repeatedly:

• Assuming public IPs persist through stop/start cycles
• Believing stopped instances are completely free
• Not understanding the difference between instance store and EBS-backed instances
• Forgetting that “Delete on Termination” is a per-volume setting, not a global default
• Treating terminate like stop, then wondering where their data went

Let’s fix all of that today.

Lab Overview

In this hands-on lab, you will observe and test the complete EC2 instance lifecycle. You’ll watch what happens to instance state, IP addresses, and EBS volumes as you transition an instance through stopped, running, and terminated states.

Skills you’ll gain:

• Confidently manage EC2 instance states without fear of data loss
• Predict exactly what will change during each lifecycle transition
• Understand EBS volume persistence rules and how to configure them
• Recognize the cost implications of each instance state
• Debug lifecycle-related issues like a Solutions Architect

Real-world scenarios where this knowledge is critical:

Consider a deployment pipeline that stops instances during maintenance windows. If your application hardcodes the public IP, every maintenance window breaks your users’ bookmarks. Or imagine an auto-scaling scenario where terminated instances leave behind orphaned EBS volumes—I’ve seen AWS bills climb by thousands of dollars from forgotten storage.

Production outages often happen because someone assumed “stop” meant “pause in place.” When that instance restarts on different hardware with a different public IP, load balancers lose their targets, DNS records become stale, and applications fail health checks. Understanding the lifecycle prevents these entirely preventable failures.

EC2 Stop vs Start vs Terminate — What Changes and Why

Before diving into the hands-on steps, let me give you the mental model that will make everything click. Each lifecycle action affects your instance’s compute, storage, and networking resources differently, and understanding this matrix is what separates confident engineers from those who are guessing.

When you stop an instance, AWS performs a graceful shutdown of your operating system and releases the underlying physical host. Your instance literally doesn’t exist as a running process on any server anymore. However, your EBS volumes remain intact and attached (in a detached-but-associated state), and your private IP stays reserved because it’s tied to your Elastic Network Interface. The public IP, though, gets released back to AWS’s pool immediately.

When you start that stopped instance, AWS provisions new compute capacity, which might be on entirely different physical hardware in the same Availability Zone. Your EBS root volume gets reattached, the OS boots up fresh (uptime resets to zero), and you receive a brand new public IP from AWS’s pool. Your private IP remains unchanged because it’s still bound to your ENI.

When you terminate an instance, everything about that compute resource is destroyed permanently. The instance ID becomes invalid, all network interfaces are deleted (releasing both public and private IPs), and your EBS volumes are either deleted or orphaned depending on their individual “Delete on Termination” settings.

EC2 Lifecycle Quick Reference Table

This table should become your mental checklist before performing any lifecycle operation in production. Print it, bookmark it, tattoo it on your forearm—whatever helps you remember.

Stop vs Hibernate — A Critical Distinction

I need to address something that causes significant confusion: stopping an instance is not the same as hibernating it, even though both result in a “stopped” state in the console.

When you stop an instance, the operating system shuts down completely. Everything in RAM is lost. When the instance starts again, the OS boots from scratch, your applications need to reinitialize, and any in-memory caches are cold. It’s essentially a full reboot.

When you hibernate an instance, AWS saves the contents of RAM to your encrypted EBS root volume before stopping. On restart, the RAM contents are loaded back, and your instance resumes exactly where it left off—running processes, open connections, cached data, everything. It’s like closing a laptop lid versus shutting it down completely.

However, hibernation has requirements that stop doesn’t. Your root volume must be encrypted, the instance must be launched with hibernation enabled, you need sufficient EBS storage space for the RAM contents, and only certain instance types support it. If you need true “pause and resume” behavior, hibernation is what you want, but you must configure it at launch time.

For this lab, we focus on the standard stop/start behavior since it’s the default and most commonly encountered in production environments.

Prerequisites

Before starting this lab, ensure you have:

• AWS account with permissions to manage EC2 instances and EBS volumes
• One running EC2 instance (t2.micro or t3.micro is fine for this lab)
• Basic EC2 console familiarity — you should know how to navigate to the EC2 dashboard
• SSH or SSM Session Manager access to your instance (for verification commands)
• AWS CLI (optional) — useful for command-line validation but not required

If you don’t have a running instance yet, refer to our previous lab: {link to Lab 0.3 — Launching Your First EC2 Instance}.

Step-by-Step Hands-On Lab

Step 1: Identify a Running EC2 Instance

What to do: Navigate to the EC2 Dashboard in your AWS Console. In the left navigation panel, click “Instances” to view your instance list. Locate an instance with the state showing as “running” (indicated by a green circle).

Why it matters: You need a baseline understanding of what your instance looks like in a healthy running state before observing how lifecycle changes affect it.

What you should see: Your instance row displays the Instance ID (something like i-0abc123def456789), Instance State as “running,” a Public IPv4 address (if launched in a public subnet with auto-assign enabled), a Private IPv4 address, and the Instance Type.

Console path: AWS Console → Services → EC2 → Instances

Step 2: Observe Instance Details

What to do: Click on your instance ID to open the instance details page. Document the following values—you’ll compare them after each lifecycle transition:

• Instance State: running
• Public IPv4 address: (note this exactly)
• Private IPv4 address: (note this exactly)
• Availability Zone: (note this)
• Root device name: /dev/xvda or /dev/sda1

Now click the “Storage” tab and note your root volume’s details, including the Volume ID and the “Delete on termination” setting.

Why it matters: These baseline values let you observe exactly what changes (and what doesn’t) during lifecycle transitions. The “Delete on termination” setting is particularly critical—it determines whether your data survives instance termination.

Common misconfiguration: Many engineers never check the “Delete on termination” setting until after they’ve lost data. AMIs can have different defaults, and console launch wizards don’t always make this setting obvious.

Step 3: Stop the EC2 Instance

What to do: With your instance selected, click “Instance state” in the top menu, then select “Stop instance.” Confirm the action when prompted.

Why it matters: Stopping an instance is fundamentally different from terminating it. When you stop an instance, AWS shuts down the operating system gracefully (like a normal shutdown), releases the instance from its underlying physical host, and preserves the EBS root volume.

What you should see: The instance state transitions from “running” to “stopping” to “stopped.” This typically takes 30 seconds to 2 minutes depending on the instance type and what the OS needs to shut down.

Console path: EC2 → Instances → Select Instance → Instance State → Stop Instance

Sample observation: Watch the Instance State column. You’ll see the indicator change from green (running) to orange (stopping) to red (stopped).

Step 4: Observe Changes After Stopping

What to do: Once the instance shows “stopped,” examine the same details you documented in Step 2.

What you should see:

• Instance State: stopped
• Public IPv4 address: (BLANK — this is critical to notice)
• Private IPv4 address: unchanged
• Availability Zone: unchanged
• Root volume: still attached, still exists

Why this matters tremendously: The public IP is gone. AWS released it back to the pool. This is the number one source of “why can’t I connect to my instance” tickets after a maintenance window. If your application, DNS records, or firewall rules referenced that public IP, they’re now pointing at nothing—or worse, at someone else’s instance that received your old IP.

The private IP remains because it’s tied to the Elastic Network Interface (ENI), which stays attached to the instance. The EBS volume persists because that’s the entire point of EBS-backed instances—your storage exists independently of instance state.

Step 5: Start the EC2 Instance Again

What to do: With your stopped instance selected, click “Instance state” and select “Start instance.”

Why it matters: When AWS starts your instance, it provisions new underlying hardware, boots your preserved EBS volume, and assigns networking resources. The instance might run on completely different physical hardware than before.

What you should see: The instance transitions from “stopped” to “pending” to “running.” The pending state indicates AWS is allocating resources and booting the instance.

Step 6: Observe Changes After Starting

What to do: Once running, examine your instance details again.

What you should see:

• Instance State: running
• Public IPv4 address: NEW ADDRESS (different from Step 2)
• Private IPv4 address: unchanged (same as Step 2)
• Availability Zone: unchanged
• Root volume: same Volume ID as before

The critical insight: Your private IP stayed the same, but you received a completely different public IP. This is AWS’s default behavior for standard public IPs. If you need a persistent public IP, you must use an Elastic IP (covered in Lab 0.5).

SSH back into your instance. Everything you installed, every file you created—it’s all still there because the EBS volume persisted through the stop/start cycle.

Step 7: Terminate the EC2 Instance

What to do: Select your instance, click “Instance state,” and choose “Terminate instance.” Read the confirmation dialog carefully before confirming.

Why it matters: Termination is permanent for the instance. There’s no “un-terminate” button. AWS will release all resources associated with the instance, and whether your EBS volume survives depends entirely on the “Delete on termination” setting.

What you should see: The instance state changes to “shutting-down” and eventually to “terminated.” Terminated instances remain visible in your console for about an hour before disappearing.

Warning: In production environments, consider enabling termination protection for critical instances. This requires a two-step process to terminate, preventing accidental destruction.

Step 8: Observe What Gets Deleted and What Remains

What to do: After termination, navigate to EC2 → Volumes in the left navigation panel.

What you should see:

If “Delete on termination” was set to Yes (the default for root volumes in most cases), your root EBS volume is gone. If it was set to No, the volume still exists in an “available” state, detached from any instance and accumulating storage charges.

Common cost trap: Volumes with “Delete on termination” set to No will persist indefinitely after instance termination. I’ve audited AWS accounts with hundreds of orphaned volumes from terminated instances—representing significant monthly waste.

Step 9: Verify EBS Behavior for Additional Volumes

What to do: If your instance had additional (non-root) EBS volumes attached, check their status in the Volumes list.

Key insight: Additional EBS volumes typically default to “Delete on termination: No.” This means they survive instance termination by default—the opposite behavior of root volumes. This design makes sense (you don’t want to lose your database volume when replacing an instance), but it can lead to orphaned volumes if you’re not tracking them.

Real Lab Experiences (Architect Insights)

Let me share some experiences that shaped how I teach EC2 lifecycle concepts.

A client once ran a batch processing job on an EC2 instance nightly. They’d stop the instance during the day to save on compute costs—smart thinking. But their monitoring system used the public IP to check job status. Every morning, the monitoring failed because the instance had a new public IP. They spent weeks debugging their monitoring tool before realizing the IP was simply different each day.

I’ve personally seen a team terminate what they thought was a test instance, only to discover it was running their staging database. The root volume was set to delete on termination. Two years of staging data, gone in seconds. Now I insist on termination protection for any instance that isn’t purely ephemeral.

The most expensive mistake I’ve witnessed: a company ran large EC2 instances for a machine learning project. They stopped the instances when not training models, thinking they were saving money. They were saving compute costs, yes—but each instance had 2TB of gp3 EBS storage attached. At roughly $0.08/GB-month, they were still paying over $160 per instance per month for storage alone. Multiply that by 20 instances over 6 months, and they’d spent nearly $20,000 on storage for stopped instances.

My advice to any junior engineer before touching production: always check the “Delete on termination” setting on volumes you care about, always use Elastic IPs for endpoints that must remain stable, and never terminate anything in production without triple-checking the instance ID.

Validation & Testing

Confirming instance state transitions:

From within your instance (before termination), run:

uptime

After a stop/start cycle, uptime resets to zero, confirming the OS fully shut down and restarted.

Validating EBS persistence:

Before stopping your instance, create a test file:

echo "persistence test" > /home/ec2-user/test-file.txt

After restarting, verify it exists:

cat /home/ec2-user/test-file.txt

Verifying public IP change:

Before stopping, run:

curl http://169.254.169.254/latest/meta-data/public-ipv4

After restarting, run the same command and compare the output.

Expected console observations:

Terminated instances display in your console with a “terminated” state for approximately one hour before being automatically removed from the instance list.

Troubleshooting Guide

Instance won’t start after stop:

Check the System Log (Actions → Monitor and troubleshoot → Get system log). Common causes include corrupted boot volumes or exhausted EBS IOPS. Verify your EBS volume status in the Volumes section—look for “error” or “impaired” states.

aws ec2 describe-instance-status --instance-id i-0abc123def456789

Root volume missing after termination:

If you expected the volume to persist, it was likely set to “Delete on termination: Yes.” Unfortunately, this cannot be recovered. Always verify this setting before terminating critical instances.

Data loss after stop/start:

If you wrote to instance store volumes (available on some instance types), that data is lost on stop. Instance store is ephemeral by design. Use lsblk to identify volume types and ensure critical data lives on EBS.

lsblk
df -h

Public IP changed unexpectedly:

This is expected behavior—not a bug. Use Elastic IPs for static addressing, or better yet, place instances behind an Application Load Balancer with a stable DNS name.

Instance terminated accidentally:

If termination protection was disabled, the instance cannot be recovered. The EBS volume might be recoverable if “Delete on termination” was set to No. Check your Volumes list immediately. For the future, enable termination protection:

aws ec2 modify-instance-attribute --instance-id i-0abc123def456789 --disable-api-termination

AWS Best Practices (Solutions Architect Level)

Security implications: Stopped instances still have EBS volumes containing your data. Ensure volumes are encrypted and that IAM policies restrict who can start instances or attach volumes to other instances.

Reliability considerations: Design your applications to handle instance replacement. Use Auto Scaling Groups, load balancers, and externalized state so that individual instance lifecycle events don’t cause application downtime.

Cost optimization: Stopped instances aren’t free—you pay for EBS storage, Elastic IPs (if not attached to a running instance), and any snapshots. For truly cost-effective stopped instances, consider creating an AMI, terminating the instance, and re-launching when needed.

Performance considerations: After a stop/start cycle, your instance runs on new hardware. Initial EBS volume access might be slightly slower if blocks haven’t been accessed recently (especially for volumes restored from snapshots).

Tagging strategy: Tag instances with lifecycle-related metadata: Owner, Environment (prod/dev/test), TerminationSafe (yes/no), and DataClassification. This enables governance at scale.

Backup and snapshot strategies: Create EBS snapshots before any risky lifecycle operation. Snapshots are incremental and cost-effective insurance against mistakes.

When to use Elastic IP vs ALB/NLB: Use Elastic IPs only when you absolutely need a static IP that you control (legacy integrations, IP whitelisting). For modern applications, use Application Load Balancers with DNS names—they’re more flexible and support multiple instances.

Real AWS Interview Questions on EC2 Lifecycle

These are actual questions I’ve encountered in Solutions Architect and DevOps Engineer interviews. Understanding these deeply will serve you well.

Question 1: “What happens to the public IP address when you stop and start an EC2 instance?”

Strong answer: The public IP is released back to AWS’s pool when you stop the instance. When you start the instance again, AWS assigns a new public IP from the pool. The new IP will almost certainly be different from the original. To maintain a static public IP across stop/start cycles, you must associate an Elastic IP with the instance. Note that Elastic IPs incur charges when not attached to a running instance.

Question 2: “A developer reports data loss after an instance stop/start. The EBS volume is intact. What happened?”

Strong answer: The developer likely stored data on an instance store volume rather than EBS. Instance store volumes are ephemeral and their contents are lost whenever the instance stops, terminates, or the underlying hardware fails. Use lsblk to identify volume types. Instance store volumes appear as NVMe devices on Nitro-based instances. Critical data should always be stored on EBS or externalized to S3, RDS, or similar persistent services.

Question 3: “How would you prevent accidental termination of a production EC2 instance?”

Strong answer: Enable termination protection using aws ec2 modify-instance-attribute --disable-api-termination. This prevents the instance from being terminated through the console, CLI, or API until protection is explicitly disabled. Additionally, use IAM policies to restrict the ec2:TerminateInstances action to specific roles, implement resource-based tagging with SCPs (Service Control Policies), and consider using AWS Config rules to detect instances without termination protection enabled.

Question 4: “You need to reduce costs for instances that run only during business hours. What’s your approach, and what are the gotchas?”

Strong answer: Implement scheduled stop/start using AWS Instance Scheduler, Lambda functions with EventBridge rules, or Auto Scaling scheduled actions. Gotchas include: public IPs change on restart (use Elastic IPs or ALB), any instance store data is lost, applications must handle cold starts gracefully, and you still pay for EBS storage during stopped periods. For significant savings on storage-heavy instances, consider creating AMIs and terminating entirely, then launching fresh instances from the AMI.

Question 5: “Explain the difference between stopping, hibernating, and terminating an EC2 instance.”

Strong answer: Stopping shuts down the OS, releases compute resources, preserves EBS volumes, and loses RAM contents. On restart, the OS boots fresh. Hibernating saves RAM contents to the encrypted EBS root volume before stopping. On restart, RAM is restored and processes resume where they left off—useful for applications with long initialization times. Terminating permanently destroys the instance and optionally deletes EBS volumes based on the “Delete on Termination” setting. Terminated instances cannot be recovered.

Frequently Asked Questions (FAQs)

Conclusion

You’ve now experienced firsthand what happens during EC2 stop, start, and terminate operations. You’ve seen public IPs disappear and change, watched EBS volumes persist through restarts, and observed the permanent nature of termination. You understand the critical difference between stop and hibernate, and you can answer interview questions on these topics with confidence.

This isn’t just checkbox knowledge for a certification exam. Understanding EC2 lifecycle behavior prevents production outages, avoids unexpected costs, and gives you the confidence to manage AWS infrastructure without second-guessing every action.

The engineers who master these fundamentals don’t panic when an instance stops unexpectedly. They know what changed, what persisted, and exactly how to recover.

Ready to lock down that public IP and never lose it again?

Continue to: Lab 0.5 — Elastic IPs & Public Networking Deep Dive {link}

Related Resources:

• Lab — Launching Your First EC2 Instance
• Understanding EBS Volume Types
• AWS EC2 Instance Lifecycle Documentation
• EBS Volume Lifecycle
• EC2 Hibernation Prerequisites