# EC2 Instance Management and Lifecycle

> Chapter 6 of the Courseiva AWS-SYSOPS-ASSOCIATE curriculum — https://courseiva.com/learn/aws-sysops-associate/ec2-instance-management

**Official objective:** 6.1 — Manage Amazon EC2 instances including launch, stop, terminate, and tag

## Introduction

Amazon EC2 (Elastic Compute Cloud) is the core building block of cloud computing — it provides virtual servers that run your applications. Managing the lifecycle of these instances — launching, stopping, starting, and terminating them — is fundamental to controlling costs, maintaining availability, and keeping your infrastructure secure. For the SOA-C02 exam, you must understand how each state change works and what happens to your data at every step.

## The Library Book Analogy

Because you first need a physical space to put a book before you can read it, a computer needs a virtual server to run its software. In AWS, this virtual server is called an EC2 instance. Think of an EC2 instance like borrowing a book from a library: you request it, you use it, and when you're done, you return it so someone else can borrow it.

When you launch an instance, you pick its size (like choosing a paperback vs. an encyclopedia) and its operating system (like choosing English vs. Spanish text). Once launched, the instance runs continuously, just like a book you keep open on your desk. You can stop it (like placing a bookmark and closing the book) — the instance pauses but keeps its data so you can resume later without losing your place. You can start it again (like reopening the book to the same page) and continue working.

If you terminate an instance, it's like returning the book to the library permanently — all your notes (data) are erased, and the book is available for someone else. Tagging an instance is like adding a sticky note to the cover that says “John’s book for Project Alpha.” This helps you organise and find specific instances among hundreds. The entire lifecycle — launch, stop, start, terminate — mirrors how you manage a physical book: borrow, pause, resume, return. This analogy is specific to EC2 because it involves creating a computing environment from scratch, pausing it without destroying data, and permanently deleting it, which maps exactly to the four core instance states in AWS.

## Core explanation

Amazon EC2 (Elastic Compute Cloud) is a service that lets you rent virtual servers, called instances, in the cloud. Instead of buying and maintaining physical servers in a data centre, you launch an instance when you need computing power and terminate it when you don't. This is Infrastructure as a Service (IaaS) — you control the operating system and software, while AWS manages the underlying hardware.

An EC2 instance has several states during its lifecycle:

- **Pending**: The instance is being started. AWS allocates resources and boots the operating system. You cannot connect to it yet.
- **Running**: The instance is fully operational. You can connect to it via SSH (for Linux) or RDP (for Windows), install software, and run applications. You are billed per second for running instances.
- **Stopping**: The instance is shutting down gracefully. AWS sends a shutdown signal to the operating system, giving processes time to close. After a few seconds, the instance enters the stopped state.
- **Stopped**: The instance is not running, but its root volume (the boot disk) and data persist. You are not billed for the instance itself, but you still pay for attached storage (like EBS volumes). You can restart it later, and it will resume with the same configuration, IP addresses (if elastic), and data.
- **Terminated**: The instance is permanently destroyed. All attached root volumes are deleted by default unless you changed the 'Delete on Termination' setting. You lose all data on the instance, and you stop paying entirely. You cannot recover a terminated instance.

To start the lifecycle, you launch an Amazon Machine Image (AMI). An AMI is a template that contains the operating system, software, and configuration. Think of it as a blueprint for your instance. You choose an AMI, an instance type (like t3.micro for low workloads), a Virtual Private Cloud (VPC) to place it in, and security groups that act as firewalls.

Once running, you can monitor performance using Amazon CloudWatch metrics like CPU utilisation. You can also attach additional storage volumes (Elastic Block Store, EBS) for data that must survive instance stops.

Why does this matter? In traditional IT, if a server crashes, you had to physically replace hardware and restore from backup — which could take days. With EC2, you can launch a new instance from a snapshot in minutes. This elasticity — scaling up and down on demand — is what makes cloud computing so powerful.

Tagging is another crucial part of instance management. Tags are key-value pairs assigned to resources. For example, you might add a tag with key 'Environment' and value 'Production'. Tags help you organise, filter, and apply policies. You can cost-allocate by tag, automate start/stop schedules based on tags, and identify resources for specific teams.

The lifecycle also involves understanding the difference between stop and terminate. Stopping is like hibernating your laptop — you save all work and power down, but everything is there when you come back. Terminating is like formatting the hard drive and throwing the laptop away — the data is gone. This distinction is vital for exam questions that ask whether data persists after a state change.

Finally, you can automate lifecycle actions. For example, you can use Auto Scaling groups to automatically launch new instances when demand rises and terminate them when demand falls. You can also schedule instance start/stop using AWS Instance Scheduler to save costs outside business hours.

In the SOA-C02 exam, you will be asked what happens during each state transition, how to preserve data when terminating, and how tagging affects billing and operations.

## Real-world context

Consider a company called 'BookNest', an online bookstore that experiences huge traffic spikes during holiday sales. The IT team uses EC2 to host their e-commerce application. Here is what they actually do with instance lifecycle management.

**Step 1: Launching instances for the sales event**
The team selects an AMI pre-configured with their web server and application code. They choose a compute-optimised instance type like c5.xlarge to handle the expected load. They launch these instances in an Auto Scaling group within their VPC, placing them across multiple Availability Zones for high availability. They tag each instance with 'Service=WebApp' and 'Environment=Production' so they can filter costs and apply security policies.

**Step 2: The sale begins**
As traffic increases, the Auto Scaling group launches additional instances automatically. CloudWatch alarms track CPU utilisation. Once utilisation passes 70%, new instances spin up. Each new instance is registered with the Application Load Balancer, which distributes incoming requests. This is called scaling out.

**Step 3: Stopping non-critical instances**
After the sale, the company wants to save money. Their development and test environments are only needed during business hours. They use AWS Instance Scheduler to automatically stop instances at 8 PM each day and start them at 6 AM. Stopping an instance retains all data on the EBS volume, so developers don't lose their work. The billing stops for compute time, but storage charges remain.

**Step 4: Terminating failed or outdated instances**
One of their production instances develops a memory leak. The team decides to terminate it. First, they take a snapshot of the attached EBS volume as a backup. Then they send a termination command. The instance moves to 'shutting-down' and then 'terminated'. The root EBS volume is deleted because they kept the default 'Delete on Termination' flag. The snapshot ensures they can launch a replacement from the same data. They then launch a fresh instance from that snapshot.

**Step 5: Cleaning up after a project**
A promotional campaign ends, and the instances used for it are no longer needed. The team identifies all instances with tag 'Campaign=SummerSale' and terminates them in bulk using the AWS Management Console. They verify that no orphaned volumes remain by checking the EBS console.

Key considerations in this scenario:
- **Cost management**: Stopping unused instances saves money without losing state.
- **Data preservation**: Taking snapshots before termination protects against data loss.
- **Automation**: Auto Scaling and scheduled stops reduce manual effort.
- **Tagging discipline**: Consistent tagging enables automation and cost tracking.

This real-world workflow shows why the SOA-C02 exam focuses on the precise behaviour of each instance state — because in production, a wrong assumption about data persistence can cost the company critical data or unnecessary expense.

## Exam focus

The SOA-C02 exam tests EC2 instance lifecycle management heavily. Here is exactly what you need to know.

**Lifecycle states and transitions**
You will see questions that list instance states and ask which one allows data persistence or billing charges. The key states to memorise are: pending, running, stopping, stopped, shutting-down, terminated.

- **Traps they set**: They might ask 'What happens to the data when you stop an instance?' The correct answer: data on EBS volumes persists, but instance store volumes (ephemeral storage) are wiped. Beginners often forget that instance store volumes lose data on stop.
- **Favourite question pattern**: 'A user stops an EC2 instance and then starts it again. Which of the following is true?' Answer options include that the public IP changes (it does, unless it's an Elastic IP), and that the private IP changes (it does not, by default).
- **Termination trap**: 'An EC2 instance is terminated. The root volume is deleted. What happens to the data?' The answer: all data on the root volume is permanently lost unless a snapshot was taken. Some questions ask about the 'Delete on Termination' flag — you must know that this flag defaults to enabled for root volumes, so data is destroyed upon termination.

**Instance store vs EBS-backed instances**
- Exam questions differentiate between instances backed by instance store (ephemeral storage) and EBS-backed instances. With instance store, stopping or terminating the instance destroys all data. With EBS-backed instances, data persists when stopped (if enabled). The exam loves to ask which type loses data on stop.

**Tags and their impact**
- Tagging is tested in scenarios involving cost allocation, automation, and resource groups. They might ask: 'How can you apply a different lifecycle policy to instances based on their environment?' Answer: use tags like 'Environment=Test' and configure a schedule or Auto Scaling policy based on that tag.
- Common trap: 'A company wants to stop all instances with a specific tag at midnight. Which service should they use?' Answer: AWS Instance Scheduler or a Lambda function triggered by CloudWatch Events. An incorrect but tempting answer might be 'Auto Scaling' — but Auto Scaling manages scaling, not scheduling.

**Shutdown behaviour**
- The exam tests the difference between shutting down from within the OS versus stopping from the AWS console. Both achieve the same end state (stopped), but one can be forced if the OS shutdown fails.

**API and CLI operations**
- Know the actions: `ec2 run-instances` (launch), `ec2 stop-instances`, `ec2 start-instances`, `ec2 terminate-instances`. Also `ec2 modify-instance-attribute` for changing shutdown behaviour.

**Billing nuances**
- While an instance is stopped, you are not billed for the instance itself, but you are billed for any attached EBS volumes and Elastic IPs. A question might ask: 'A user stops an EC2 instance but still sees charges. Why?' Answer: they still have a root EBS volume attached and possibly an Elastic IP reserved.

**Scenarios they love**
- A developer needs to preserve data on an instance that will be terminated. The correct answer is to take a snapshot before terminating.
- An instance fails health checks. The SysOps administrator should terminate it and let Auto Scaling launch a replacement.
- A company wants to save costs by stopping development instances overnight. The correct tool is AWS Instance Scheduler (not Auto Scaling).

**Preparation tip**: Create a table of states and what persists (data, IP, billing) for each. Drill it until it is automatic.

## Step by step

1. **1. Choose an AMI** — An Amazon Machine Image (AMI) is a pre-configured template that contains the operating system (like Amazon Linux or Windows Server) and optionally software. You select an AMI based on your application needs. This is the foundation of the instance.
2. **2. Select an instance type** — The instance type determines the virtual hardware: CPU, memory, and network performance. For example, t3.micro is for low-traffic web servers, while m5.large balances compute and memory. You pick the type based on workload requirements.
3. **3. Configure instance details** — You set the network (VPC and subnet), assign IAM roles for permissions, and choose shutdown behaviour (stop or terminate). You also decide whether to enable detailed monitoring. These settings control how the instance interacts with other AWS services.
4. **4. Add storage and tags** — You attach storage volumes. By default, an EBS root volume is added. You can add additional EBS volumes for data. Then you add tags — key-value pairs like 'Name=WebServer' — to organise and automate actions on the instance.
5. **5. Configure security group** — A security group acts as a virtual firewall. You define inbound rules (who can access the instance, e.g., HTTP from anywhere) and outbound rules. This step is critical for security and connectivity.
6. **6. Launch and connect** — You review your settings and launch the instance. AWS generates a key pair (if not using existing one) for SSH access (Linux) or you retrieve the administrator password (Windows). Once the instance is running, you connect and start using it.
7. **7. Manage the instance: stop, start, or terminate** — When you stop an instance, it enters the stopped state, preserving EBS data but freeing compute charges. Starting it resumes from the same state. Terminating permanently destroys the instance and its root volume. You can also reboot without stopping.

## Comparisons

### Stop Instance vs Terminate Instance

**Stop Instance:**
- Preserves all data on EBS volumes
- You can restart the instance later from stopped state
- You stop paying for compute but still pay for storage

**Terminate Instance:**
- Permanently deletes the instance and its root volume
- Cannot be undone or recovered
- Stops all billing (compute and root storage)

### EBS-backed Instance vs Instance Store-backed Instance

**EBS-backed Instance:**
- Data persists across stop/start
- Root volume is an EBS volume (can be snapshotted)
- You can stop and start the instance

**Instance Store-backed Instance:**
- Data is lost on stop, terminate, or failure
- Storage is ephemeral and physically attached to host
- Cannot be stopped; only rebooted or terminated

### Public IP (Dynamic) vs Elastic IP

**Public IP (Dynamic):**
- Changes when instance is stopped and started
- No additional cost while instance is running
- Released when instance is terminated

**Elastic IP:**
- Remains the same even across stop/start
- Costs money if allocated but not attached to a running instance
- Can be reassigned to another instance

### Auto Scaling vs AWS Instance Scheduler

**Auto Scaling:**
- Launches or terminates instances based on demand metrics
- Reacts to CPU utilisation, memory, or custom metrics
- Used for dynamic scaling of production workloads

**AWS Instance Scheduler:**
- Starts and stops instances on a fixed time schedule
- Used to save costs by stopping non-production instances overnight
- Requires a Lambda function or a scheduled rule

### Default Shutdown Behaviour (Stop) vs Default Shutdown Behaviour (Terminate)

**Default Shutdown Behaviour (Stop):**
- Instance enters stopped state when OS shutdown command is issued
- Data persists on EBS volumes
- Can be restarted later

**Default Shutdown Behaviour (Terminate):**
- Instance immediately enters terminating state on OS shutdown
- Root volume is deleted by default
- Used for ephemeral or 'cattle' workloads

## Common misconceptions

- **Misconception:** When I stop an EC2 instance, all my data is lost. **Reality:** For EBS-backed instances, stopping preserves all data on EBS volumes; for instance store-backed instances, data is lost. Most instances are EBS-backed, so stopping usually keeps data. (Beginners confuse 'stop' with 'terminate' because on a physical computer, shutting down doesn't delete files, but they assume the cloud is different.)
- **Misconception:** I can recover a terminated EC2 instance like I would a deleted file on my desktop. **Reality:** Once an instance is terminated, it is permanently destroyed and cannot be recovered. You must restore from a backup or launch a new instance from an AMI or snapshot. (Because cloud services sometimes use the word 'delete' in other contexts where recovery is possible, like a recycle bin in storage services. EC2 termination is final.)
- **Misconception:** Tags are optional and have no real effect on instance behaviour or billing. **Reality:** Tags are essential for organising resources, automating actions (stop/start scheduling), and allocating costs. Without tags, managing hundreds of instances becomes chaotic. (Many beginners focus only on the core compute function and overlook management features that are critical in real-world operations.)
- **Misconception:** If I stop an instance, the public IP stays the same when I start it again. **Reality:** Unless you have an Elastic IP (a static public IP you own), stopping and starting an instance releases the public IP address, and a new one is assigned upon start. (People assume IP addresses behave like a static home address, but AWS dynamically assigns them to conserve the public IPv4 pool.)
- **Misconception:** Stopping an instance stops all billing entirely. **Reality:** Stopping stops billing for the compute portion, but you still pay for attached EBS storage, Elastic IPs (if unattached), and any other resources. (It feels like turning off a computer, which cuts electricity use. In the cloud, storage is billed independently of compute, so the bill doesn't drop to zero.)
- **Misconception:** I can stop and start any instance type without issues. **Reality:** You can stop and start any EBS-backed instance, but instances backed by instance store cannot be stopped — they can only be terminated or rebooted. (People don't distinguish between the two storage types, so they assume all instances behave the same way.)

## Key takeaways

- EC2 instances move through five primary lifecycle states: pending, running, stopping, stopped, and terminated.
- Stopping an EBS-backed instance preserves all data on EBS volumes but releases the public IP address unless an Elastic IP is attached.
- Terminating an EC2 instance permanently deletes the root EBS volume by default, so always take a snapshot before terminating if data must be kept.
- Instance store-backed instances lose all data when they are stopped, terminated, or fail; they cannot be stopped and started like EBS-backed instances.
- Tags are key-value pairs that enable cost allocation, automation of start/stop schedules, and resource organisation across your AWS account.
- You are billed for an instance only when it is in the 'running' state, but you continue to pay for attached EBS storage and allocated Elastic IPs even when the instance is stopped.
- The test always asks which data persists after a stop or terminate — memorise the storage type (EBS vs instance store) to answer correctly.
- AWS Instance Scheduler and Auto Scaling are separate services: use Instance Scheduler for time-based stop/start, and Auto Scaling for dynamic scaling based on demand.
- An AMI is a launch template that includes an operating system and software; you must choose an AMI as the starting point for any instance.
- The root volume's 'Delete on Termination' flag is enabled by default; disabling it preserves the root volume after termination, but you still lose the instance.

## FAQ

**What is the difference between stopping and terminating an EC2 instance?**

Stopping pauses the instance and retains all data on EBS volumes, so you can restart later. Terminating permanently deletes the instance and its root volume by default — you cannot recover a terminated instance.

**Does my public IP address change when I stop and start an EC2 instance?**

Yes, unless you have attached an Elastic IP. The public IP is released when the instance stops, and a new one is assigned upon start. The private IP address remains the same if you use the default VPC settings.

**Can I recover a terminated EC2 instance?**

No, once an instance is terminated, it is permanently destroyed and cannot be recovered. You must restore from a snapshot or launch a new instance from an AMI or backup.

**What happens to instance store volumes when I stop an instance?**

Instance store volumes are ephemeral — they lose all data when an instance is stopped, terminated, or fails. Only EBS-backed volumes preserve data across stops.

**Do I get charged when my instance is stopped?**

You are not charged for the instance compute time while stopped, but you still pay for any attached EBS volumes, Elastic IPs (if not associated to a running instance), and other resources.

**What is the 'Delete on Termination' flag?**

It's a setting applied to EBS volumes. When enabled (default for root volumes), the volume is automatically deleted when the instance is terminated. Disable it for data volumes you want to keep after termination.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-sysops-associate/ec2-instance-management