Explore EC2 Instance Store Storage

Prove how EC2 instance store data behaves across reboot and stop/start cycles.

Introduction

30 Second Summary

Imagine saving a file to a hard drive that erases itself every time the computer powers off. This type of storage exists in AWS, and understanding exactly when data disappears is one of the most tested topics on the Solutions Architect exam.

In this project, you will launch an EC2 instance with a built-in NVMe SSD and test how your data behaves across different lifecycle events. You will also use the AWS CLI to explore how instance store availability and size change across different instance types.

What You'll Build

You will launch an m5d.large EC2 instance, discover and mount its NVMe SSD instance store volume, and test data persistence across reboot and stop/start lifecycle events.

By the end of this project, you'll have:

  • A formatted and mounted instance store volume with test data you wrote yourself.
  • Terminal proof that instance store data survives a reboot but vanishes after a stop/start cycle.
  • CLI output showing how instance store size is determined by the instance type you choose.
  • Secret Mission: Benchmark instance store vs. EBS I/O performance to prove the latency advantage of physically attached storage.

Are there any prerequisites?

You need an AWS account with permissions to launch EC2 instances. Basic familiarity with EC2 instances and EBS volumes is helpful.

Launch an EC2 Instance with Instance Store

To explore how instance store works, you need an EC2 instance that actually includes one. Not all instance types come with instance store volumes.

In this step, you will create an SSH key pair, look up the latest Amazon Linux 2023 AMI ID, and launch an m5d.large instance that comes with an NVMe SSD instance store volume.

In this step, get ready to:
  • Create an SSH key pair and retrieve the latest Amazon Linux 2023 AMI ID.
  • Launch an m5d.large EC2 instance with an instance store volume.
  • Connect to your instance via SSH.
Create a key pair and find the right AMI

To SSH into your EC2 instance later, you need a key pair. You also need the AMI ID for Amazon Linux 2023, which is the operating system your instance will run.

  • Open your terminal by pressing Cmd+Space (macOS) or the Windows key (Windows), then type Terminal and press Enter.
  • Create a new key pair and save the private key file by running this command:
aws ec2 create-key-pair --key-name instance-store-lab-key --query "KeyMaterial" --output text > instance-store-lab-key.pem

What does this command do?

This creates a new key pair called instance-store-lab-key in your AWS account. The --query and --output text flags extract just the private key material. The > instance-store-lab-key.pem part saves it to a file in your current directory.

  • Confirm the file was created by running:
ls instance-store-lab-key.pem

You should see instance-store-lab-key.pem in the output.

Getting an 'already exists' error?

If you see InvalidKeyPair.Duplicate, a key pair with this name already exists in your account. Delete it first with aws ec2 delete-key-pair --key-name instance-store-lab-key, then run the create command again.

Help me troubleshoot this key pair error.

SSH requires that private key files have restricted permissions. Without this, SSH will refuse to use the key.

macOS

  • Restrict permissions on the key file by running:
chmod 400 instance-store-lab-key.pem

Windows

  • Restrict permissions on the key file by running these commands one at a time:
icacls.exe instance-store-lab-key.pem /reset
icacls.exe instance-store-lab-key.pem /grant:r "$($env:USERNAME):(R)"
icacls.exe instance-store-lab-key.pem /inheritance:r

What do these commands do?

The first command resets permissions to defaults. The second grants read-only access to your user account. The third removes inherited permissions from the parent folder so no other user can access the file.

  • Now look up the latest Amazon Linux 2023 AMI ID by running this command:
aws ec2 describe-images --owners amazon --filters "Name=name,Values=al2023-ami-2023.*-x86_64" "Name=state,Values=available" --query "sort_by(Images, &CreationDate)[-1].ImageId" --output text

What does this command do?

This queries all Amazon-owned AMIs, filters for Amazon Linux 2023 images that target x86_64 processors, sorts them by creation date, and returns the ID of the newest one. The AMI ID changes over time as AWS releases new updates.

You should see an AMI ID in the output that looks like ami-0abcdef1234567890. Copy this value somewhere you can access it for the next command.

Seeing an empty result or error?

Make sure your AWS CLI is configured with a valid region. Run aws configure get region to check. If it returns nothing, run aws configure and set a region like us-east-1.

Help me troubleshoot this AMI lookup.

Understand the "d" suffix and launch your instance

EC2 instance type names follow a pattern. The letter "d" in a name like m5d.large means the instance type includes instance store volumes. Without the "d", you only get EBS volumes.

What is the 'd' suffix naming convention?

In EC2 naming, the "d" option letter means instance store volumes are included. For example, c5d, m5d, r5d, c6gd, and m6gd all include instance store. Their counterparts without the "d" (c5, m5, r5) do not.

Storage-optimized instances like the I3, I3en, I4i, D2, and D3 families always include instance store regardless of suffix. You will explore these families in a later step.

Before launching your instance, you need a security group that allows SSH access. The default VPC security group does not allow inbound SSH traffic.

  • Create a security group that allows SSH access by running this command:
aws ec2 create-security-group --group-name instance-store-lab-sg --description "Allow SSH for instance store lab" --query "GroupId" --output text

You should see a security group ID like sg-0abcdef1234567890. Copy this value.

  • Add an inbound rule that allows SSH on port 22 by running this command:
aws ec2 authorize-security-group-ingress --group-name instance-store-lab-sg --protocol tcp --port 22 --cidr 0.0.0.0/0

Why open SSH to all IP addresses?

The 0.0.0.0/0 CIDR allows SSH from any IP address. This is acceptable for a short-lived lab instance. In production, you would restrict this to your specific IP address.

  • Launch your m5d.large instance by running this command, replacing the AMI ID with the one you copied earlier:
aws ec2 run-instances --instance-type m5d.large --key-name instance-store-lab-key --image-id [[AMI_ID="your AMI ID from the previous command"]] --security-group-ids [[SG_ID="your security group ID"]] --query "Instances[0].InstanceId" --output text

What does this command do?

This launches a single m5d.large instance in your default VPC using the Amazon Linux 2023 AMI you looked up. The m5d.large comes with 1 x 75 GB NVMe SSD instance store volume, which is automatically attached at launch.

You do not need to specify block device mappings for the instance store. For NVMe-capable instance types like m5d, all supported instance store volumes are automatically attached.

You should see an instance ID in the output that looks like i-0abcdef1234567890. Copy this value. You will use it throughout the rest of this project.

Save your instance ID

You will reference this instance ID in every remaining step of this project. Save it somewhere easy to access.

  • Wait for the instance to reach the running state, then retrieve its public IP address by running these commands:
aws ec2 wait instance-running --instance-ids [[INSTANCE_ID="your instance ID"]]
aws ec2 describe-instances --instance-ids [[INSTANCE_ID="your instance ID"]] --query "Reservations[0].Instances[0].PublicIpAddress" --output text

What do these commands do?

The first command pauses until your instance transitions from pending to running. This typically takes 30 to 60 seconds. The second command retrieves the public IP address you will need for SSH.

You should see a public IP address like 3.94.123.45. Copy this value for the next substep.

Command seems to hang or returns no IP?

The wait command can take up to 60 seconds. If the describe-instances command returns None instead of an IP, your instance may have launched in a private subnet with no public IP assignment. Terminate it and relaunch, ensuring you are using the default VPC.

Help me troubleshoot my instance launch.

This instance costs money

The m5d.large instance costs approximately $0.113 per hour. No free-tier-eligible instance type includes instance store, so this cost is unavoidable for this lab. Aim to complete the project within one hour to keep costs under $0.15. You will terminate the instance in the Before You Go section.

Connect to your instance via SSH

Your instance is running and has a public IP address. Now you can connect to it over SSH using the key pair you created.

  • Connect to your instance by running this command:
ssh -i instance-store-lab-key.pem ec2-user@[[EC2_PUBLIC_IP="your instance public IP address"]]

What does this command do?

The -i flag tells SSH which private key file to use for authentication. The username ec2-user is the default user on Amazon Linux AMIs.

  • When prompted with "Are you sure you want to continue connecting?", type yes and press Enter.

You should see a prompt that looks like [ec2-user@ip-172-31-xx-xx ~]$. This confirms you are connected to your EC2 instance.

Connection timed out or refused?

  • Make sure your security group allows inbound SSH on port 22. Run aws ec2 describe-security-groups --group-names instance-store-lab-sg to check.
  • Verify the public IP address is correct by re-running the describe-instances command.
  • If you see a "Permission denied" or "unprotected private key" error, double check you ran the permissions command (chmod 400 on macOS or icacls on Windows) on your .pem file.

Help me troubleshoot my SSH connection to EC2.

Your instance is live and you are connected. Next up, you will discover the instance store volume and learn how NVMe devices appear on the system.

Discover and Understand the Instance Store Volume

Your m5d.large instance is running and you are connected via SSH. Now it is time to find the hidden storage device that makes this instance type special.

The instance store volume does not show up in the AWS Console the same way EBS volumes do. You will use Linux commands to discover it, identify it, and learn how it is encrypted at rest.

In this step, get ready to:
  • List all block devices and identify the instance store volume.
  • Install nvme-cli and inspect NVMe device details.
  • Understand how instance store encryption at rest works.
List all block devices and identify the instance store

Your instance has two storage devices: the EBS root volume that every EC2 instance gets, and the 75 GB NVMe SSD instance store volume. Both show up as NVMe devices in Linux, so you need to tell them apart.

  • In your SSH session, list all attached block devices by running this command:
lsblk

You should see two NVMe devices in the output.

What should I see?

Look for two devices in the output:

  • nvme0n1 (approximately 8 GB) is your EBS root volume. It has partitions underneath it (like nvme0n1p1) and one of those partitions is mounted at /.
  • nvme1n1 (approximately 69.9 GB) is your instance store volume. It has no partitions and no mount point. The 75 GB raw capacity shows as roughly 69.9 GiB because Linux displays sizes in gibibytes.

The quickest way to spot the instance store is to look for the device with no partitions and no mount point. It is completely blank because no one has formatted or mounted it yet.

Only seeing one NVMe device?

  • Confirm your instance type is m5d.large (with the "d"). An m5.large (without the "d") does not include an instance store volume.
  • NVMe device numbering can vary. Your instance store might appear as nvme0n1 instead. Look for the device that is roughly 70 GB with no partitions.

Still stuck? Help me figure out why my instance store volume is not showing up in lsblk

Inspect the NVMe device details

The lsblk output shows sizes and mount points, but it does not tell you which device is the EBS volume and which is the instance store. A dedicated NVMe tool can show you exactly that.

  • Install the nvme-cli tool by running this command:
sudo dnf install nvme-cli -y

You should see output ending with Complete! once the installation finishes.

Seeing a "No match" or network error?

  • Make sure you are running this command inside your SSH session on the EC2 instance, not in your local Windows terminal.
  • If you see a network error, check that your instance has internet access through its security group and subnet settings.

Need a hand? Help me troubleshoot my dnf install command on Amazon Linux 2023

  • Now list the NVMe devices with their model names by running:
sudo nvme list

What does this output tell me?

The Model column is the key. It tells you exactly what each NVMe device is:

  • Amazon Elastic Block Store is your EBS root volume.
  • Amazon EC2 NVMe Instance Storage is your instance store volume. This is the one you will format, mount, and test in the next step.

Why didn't I have to attach this volume manually?

For modern NVMe-capable instance types like m5d, c5d, and i3, all instance store volumes are automatically attached at launch. You do not need to configure block device mappings.

Older non-NVMe instance types like C3, M3, and R3 required you to manually specify block device mappings when launching. This is a historical detail, but it is good to know for exam context.

Understand instance store encryption at rest

Before you start writing data to the instance store, it is worth understanding how that data is protected. This is a frequently tested concept on the SAA-C03.

How is instance store data encrypted?

NVMe instance store volumes are automatically encrypted at rest using XTS-AES-256 hardware-based encryption. This happens at the hardware level on the host machine itself.

Each device gets a unique encryption key. That key is destroyed the moment you stop or terminate the instance. You cannot disable this encryption or provide your own keys.

How does this differ from EBS encryption?

  • Instance store encryption uses hardware-based XTS-AES-256. The keys are unique per device and destroyed on stop or terminate. You have no control over these keys.
  • EBS encryption uses AWS KMS keys. You can choose the default AWS-managed key or provide your own customer-managed key. EBS encryption is optional, and you decide when to enable it.

The SAA-C03 tests whether you know that instance store encryption is always on, always hardware-based, and always uses per-device keys that you cannot manage yourself.

You now know exactly which device is your instance store and how its data is encrypted. Next up, you will format it, mount it, and write test data so you can put it through two lifecycle events.

Format, Mount, and Write Test Data

You've identified the NVMe instance store volume on your instance and confirmed it's a raw, unformatted disk. Now it's time to put that volume to work.

In this step, you'll format the volume with a file system, mount it, and write test data to both the instance store and the EBS root volume. These two files become your "before" snapshot for the persistence tests in the next two steps.

In this step, get ready to:
  • Format and mount the instance store volume.
  • Write test data with timestamps to both volumes.
  • Verify both files exist as your "before" state.
Format and mount the instance store volume

Unlike the EBS root volume that came pre-formatted and mounted when your instance launched, the instance store volume is completely raw. You need to create a file system on it before Linux can read or write files.

  • Format the instance store volume with an ext4 file system by running this command in your SSH session:
sudo mkfs.ext4 /dev/nvme1n1

What does this command do?

mkfs.ext4 stands for "make file system." It writes the ext4 file system structure onto the raw disk at /dev/nvme1n1. Without a file system, the volume is just blank storage with no way to organize files and directories.

You should see output that ends with Writing superblocks and filesystem accounting information: done. This confirms the file system was created successfully.

Seeing a permission denied error?

Make sure you included sudo at the start of the command. Formatting a disk requires root permissions.

If you see No such file or directory, run lsblk to double check the device name. Your instance store volume might be listed under a different NVMe device name.

Help me troubleshoot the mkfs.ext4 command on my EC2 instance store volume

Now that the volume has a file system, you need to mount it to a directory so Linux knows where to access it.

  • Create a mount point and mount the volume by running these commands:
# Create the directory where the volume will be accessible
sudo mkdir -p /mnt/instance-store

# Mount the formatted volume to that directory
sudo mount /dev/nvme1n1 /mnt/instance-store

What does mounting mean?

Mounting connects a storage device to a directory in the Linux file system. After mounting, anything you save to /mnt/instance-store is physically written to the instance store volume.

The -p flag on mkdir creates any missing parent directories. It also prevents an error if the directory already exists.

  • Confirm the volume is mounted by running:
df -h /mnt/instance-store

You should see /dev/nvme1n1 mounted at /mnt/instance-store with approximately 73 GB of available space. The total is slightly less than 75 GB due to file system overhead.

Not seeing the mounted volume?

If df -h does not show /mnt/instance-store, the mount command may have failed silently. Run lsblk to check if the device has a mount point listed next to it.

If the mount point column is empty, re-run the sudo mount command. Make sure you ran the mkfs.ext4 format step first. You cannot mount a volume that has no file system.

Help me troubleshoot mounting my instance store volume

Write test data to both volumes

You're going to write a test file to each volume so you can track what happens to the data during a reboot and a stop/start cycle. Each file includes a timestamp so you can confirm later whether it's the original file or a new one.

  • Create test files on both volumes by running these commands:
# Write a test file to the instance store volume
echo "Instance store test data - written at $(date)" | sudo tee /mnt/instance-store/test-data.txt

# Write a test file to the EBS root volume
echo "EBS root volume test data - written at $(date)" > /home/ec2-user/ebs-test-data.txt

Why write to both volumes?

Writing identical test files to both volumes creates a controlled experiment. When you reboot or stop the instance later, you'll be able to compare what happened to each file side by side.

The first command uses sudo tee because the instance store mount point is owned by root. The second command uses a simple redirect (>) because /home/ec2-user/ is owned by your current user.

The first command prints the file content to your terminal as it writes. You should see a line starting with Instance store test data - written at followed by the current date and time.

Seeing a read-only file system error?

This means the volume was not mounted correctly. Run df -h /mnt/instance-store to check. If the mount point is missing, go back and re-run the sudo mount command from the previous substep.

Help me fix a read-only file system error on my instance store volume

Verify both files exist

Before you put the instance through any lifecycle events, confirm both files are readable. This is your "before" state that you'll compare against after a reboot and a stop/start.

  • Read both test files by running these commands:
# Read the instance store test file
cat /mnt/instance-store/test-data.txt

# Read the EBS root volume test file
cat /home/ec2-user/ebs-test-data.txt

You should see both messages with their timestamps. The first shows your instance store data. The second shows your EBS data.

Take a mental note of the timestamps

The timestamps prove these are the original files you wrote. In the next steps, if a file still has this exact timestamp after a reboot or stop/start, you know the data survived. If the file is gone, you know the data was lost.

Seeing No such file or directory?

If the instance store file is missing, check that the volume is still mounted with df -h /mnt/instance-store. If it is mounted, make sure the file path matches exactly: /mnt/instance-store/test-data.txt.

If the EBS file is missing, check the path: /home/ec2-user/ebs-test-data.txt. A typo in the directory name is the most common cause.

Help me find my test files on the EC2 instance

Both files are locked in. Next, you'll reboot the instance and check whether your data survives.

Test Reboot - Data Survives

Your instance store volume is formatted, mounted, and loaded with test data. Now comes the moment of truth.

In this step, you will reboot your EC2 instance and check whether the data on your instance store volume survives. This is one of the most frequently tested instance store behaviors on the SAA-C03 exam.

In this step, get ready to:
  • Reboot the instance and reconnect via SSH.
  • Re-mount the instance store volume and verify your test data survived.
  • Learn the complete data persistence rules for the SAA-C03 exam.
Reboot the instance and reconnect

When you reboot an EC2 instance, it stays on the same physical host machine. This means any physically attached storage, like your instance store volume, remains intact.

  • Reboot your instance by running this command in your SSH session:
sudo reboot

What happens during a reboot?

A reboot keeps your instance on the same physical host. The instance store disks stay attached and their data remains untouched.

This is different from a stop/start cycle, which moves the instance to a new host entirely. You will test that scenario in the next step.

Your SSH connection will disconnect immediately. This is expected.

  • Wait about 60 seconds for the instance to finish rebooting.
  • Open a new terminal window on your local Windows machine. Reconnect to your instance by running:
ssh -i [[PEMPATH="path to your .pem file"]] ec2-user@[[EC2_PUBLIC_IP="your EC2 public IPv4 address"]]

You should see the Amazon Linux 2023 prompt again, confirming you are back on the instance.

Can't reconnect?

  • If the connection times out, wait another 30 seconds and try again. The instance may still be booting up.
  • Make sure you are using the same public IP address as before. A reboot does not change the instance's public IP.
  • I can't SSH into my EC2 instance after rebooting
Re-mount the instance store and check your data

After a reboot, your instance store volume still has its data and file system intact. The mount point at /mnt/instance-store is no longer active because it was not saved in /etc/fstab.

You need to re-mount the volume manually before you can access the files on it.

  • Confirm the NVMe instance store device is still present by running:
lsblk

You should see nvme1n1 listed as a 75 GB device, just like before the reboot.

  • Re-mount the instance store volume by running:
sudo mount /dev/nvme1n1 /mnt/instance-store
  • Verify the mount is active by running:
df -h /mnt/instance-store

You should see /dev/nvme1n1 mounted at /mnt/instance-store in the output.

  • Check that your test data survived the reboot. Read both test files by running:
cat /mnt/instance-store/test-data.txt
cat /home/ec2-user/ebs-test-data.txt

Both files should display their original messages and timestamps, exactly as you wrote them in the previous step.

Why did the data survive?

A reboot keeps the instance on the same physical host machine. The NVMe SSD that holds your instance store data is physically soldered to that host.

Since the host did not change, your data stayed put. The EBS root volume also survived, but for a different reason. EBS volumes are network-attached storage that persists independently of the host.

Instance store file is missing?

  • Make sure you mounted the correct device. Run lsblk to confirm nvme1n1 is your 75 GB instance store volume.
  • If you see a wrong fs type error when mounting, the file system may have been corrupted. This is rare during a normal reboot.
  • My instance store data is missing after reboot
Review the full persistence rules for SAA-C03

You just proved with your own eyes that instance store data survives a reboot. Now let's zoom out to the complete picture.

The SAA-C03 exam tests your knowledge of exactly which lifecycle events preserve instance store data and which destroy it. Memorizing this table will save you on exam day.

When does instance store data persist?

Data PERSISTS through:

  • User-initiated reboot.
  • Operating system restart.
  • System reboot (AWS scheduled maintenance).
  • Power failure reboot.

Data is DESTROYED when:

  • The instance is stopped.
  • The instance is hibernated.
  • The instance is terminated.
  • The instance type is changed.
  • The underlying disk fails.
  • Automatic recovery is triggered.
  • The instance is retired by AWS.

Why does stop destroy data but reboot doesn't?

A reboot keeps the instance on the same physical host. A stop moves the instance off its host entirely.

When that happens, every instance store block is cryptographically erased. When the instance starts again, it lands on a new host with a fresh, empty instance store volume. You will prove this yourself in the next step.

The pattern behind the table

You do not need to memorize every row individually. The rule is simple: if the instance stays on the same physical host, data persists. If the instance moves to a different host, data is gone. Every "destroyed" event involves the instance leaving its current host.

You now have firsthand proof that instance store data survives a reboot. Next up, you will test the opposite scenario: stopping and starting the instance to watch the data disappear.

Test Stop/Start - Data Vanishes

In the previous step, you rebooted your instance and confirmed that your instance store data survived. That was the easy case.

Now it is time for the critical test that trips up many SAA-C03 candidates. When you stop an EC2 instance, AWS migrates it off its physical host and cryptographically erases every block on the instance store. You are about to see this happen with your own data.

In this step, get ready to:
  • Stop the instance using the AWS CLI and learn what happens behind the scenes.
  • Start the instance, retrieve the new public IP, and reconnect via SSH.
  • Prove that instance store data is gone while EBS data persists.
Stop the instance from the CLI

A reboot keeps the instance on the same physical host, which is why data survived. Stopping moves the instance off its host entirely, and AWS destroys the encryption keys for the NVMe instance store volumes in the process.

  • Switch to your local Windows terminal. This is the terminal you used to launch the instance, not your SSH session.
  • Stop the instance and wait for it to reach the stopped state by running these commands:
# Stop the instance (triggers host migration and instance store erasure)
aws ec2 stop-instances --instance-ids [[INSTANCE_ID="your instance ID (e.g. i-0abc123def456)"]]

# Wait until the instance fully reaches the "stopped" state
aws ec2 wait instance-stopped --instance-ids [[INSTANCE_ID="your instance ID (e.g. i-0abc123def456)"]]

What do these commands do?

  • aws ec2 stop-instances sends a stop request. You will see JSON output showing the instance moving from running to stopping.
  • aws ec2 wait instance-stopped polls the instance state every 15 seconds. It returns with no output once the instance is fully stopped.
  • The first command returns JSON showing "Name": "stopping" under CurrentState. The second command sits silently until the instance is stopped, then returns you to the prompt.

What happens behind the scenes when you stop an instance?

When you stop an EC2 instance, AWS migrates it off the physical host it was running on. The NVMe instance store volumes on that host are encrypted with XTS-AES-256 using hardware-based encryption. Each device has a unique encryption key.

When the instance stops, those encryption keys are destroyed. Every block on the instance store is cryptographically erased. You cannot disable this encryption or provide your own keys.

This is different from EBS encryption, which uses AWS KMS keys and persists across stop/start cycles. Instance store encryption is automatic, hardware-based, and non-configurable.

Getting an "invalid instance ID" error?

  • Double check that your instance ID starts with i- followed by a string of letters and numbers.
  • Make sure your AWS CLI default region matches the region where you launched the instance.

Still stuck? Ask for help here.

Start the instance and reconnect

Your instance is now stopped. When you start it again, AWS assigns it to a new physical host with a fresh, empty instance store volume.

  • Start the instance and wait for it to reach the running state by running these commands:
# Start the instance on a new physical host
aws ec2 start-instances --instance-ids [[INSTANCE_ID="your instance ID (e.g. i-0abc123def456)"]]

# Wait until the instance is fully running
aws ec2 wait instance-running --instance-ids [[INSTANCE_ID="your instance ID (e.g. i-0abc123def456)"]]

What does this do?

aws ec2 start-instances boots the instance on a new host. The wait command blocks until the instance is fully running and reachable. You will see JSON output showing the state change to pending, then the wait command returns silently once it reaches running.

Because the instance moved to a new host, its public IP address may have changed. You need to retrieve the new IP before you can reconnect.

Why did my public IP change?

EC2 assigns a new public IPv4 address every time you stop and start an instance. To keep the same IP across stop/start cycles, you would need an Elastic IP address. For this lab, retrieving the new IP is fine.

  • Retrieve the new public IP address by running:
# Query the new public IP assigned after start
aws ec2 describe-instances --instance-ids [[INSTANCE_ID="your instance ID (e.g. i-0abc123def456)"]] --query "Reservations[0].Instances[0].PublicIpAddress" --output text
  • You should see a single IP address printed in the terminal. Copy this value.
  • Reconnect to your instance via SSH using the new IP by running:
ssh -i [[PEMPATH="path to your .pem file (e.g. instance-store-lab-key.pem)"]] ec2-user@[[NEW_PUBLIC_IP="your new public IPv4 address"]]
  • You should see the Amazon Linux 2023 welcome banner and the ec2-user@ prompt. You are back on the instance.

Connection timed out or refused?

  • Make sure the wait instance-running command completed before you tried to SSH in. The instance needs a moment to finish booting after reaching the running state.
  • Confirm you are using the NEW public IP from the describe-instances output, not the old one from before the stop.
  • Wait 30 seconds and try the SSH command again. The SSH daemon sometimes takes a moment to start after a fresh boot.

Still stuck? Ask for help here.

Prove the instance store data is gone

You are now connected to the same instance, but it is running on a completely different physical host. The NVMe instance store volume is a fresh, empty disk.

  • Check the block devices on your instance by running:
# List all block devices to see what's attached
lsblk

What should I see?

You should see both nvme0n1 (your EBS root volume) and nvme1n1 (the instance store volume). The device still appears because the new host has its own physical NVMe disk. But this is an entirely new disk with no data on it.

  • Try to mount the instance store volume by running:
# Attempt to mount the instance store volume (this will fail)
sudo mount /dev/nvme1n1 /mnt/instance-store

Seeing a mount error? That is the proof.

You should see an error like wrong fs type, bad option, bad superblock on /dev/nvme1n1. This means the ext4 file system you created earlier no longer exists. The volume was cryptographically erased when you stopped the instance.

Your test file at /mnt/instance-store/test-data.txt is gone forever. There is no way to recover it.

Now check the other side of the story. Your EBS root volume traveled with the instance to its new host.

  • Verify the EBS test file is still present by running:
# Check if the file on the EBS root volume survived the stop/start
cat /home/ec2-user/ebs-test-data.txt
  • You should see the original message and timestamp you wrote earlier. The EBS data survived the stop/start cycle completely intact.

Why is this the critical SAA-C03 lesson?

You just proved the single most tested storage concept on the exam. Instance store data is ephemeral. It vanishes when you stop, hibernate, or terminate the instance. EBS data is persistent. It stays attached and intact across those same lifecycle events.

Many exam questions present a scenario where data is "lost" after an instance is stopped. The answer almost always points to instance store as the culprit.

When does instance store data persist and when does it vanish?

Data persists through: user-initiated reboot, OS restart, system reboot (AWS scheduled), and power failure reboot.

Data vanishes on: stop, hibernate, terminate, instance type change, disk failure, automatic recovery, and retirement.

The pattern to remember is simple. If the instance stays on the same physical host, data survives. If it moves to a different host, data is gone.

You now have hands-on proof that instance store data is ephemeral. Next up, you will use the AWS CLI to explore how instance store size and availability vary across different instance types.

Explore Instance Store Sizes Across Instance Types

In the last step, you proved the single most important instance store behavior for the SAA-C03. Data survives a reboot but vanishes after a stop/start cycle.

There is another concept the exam loves to test. The size and number of instance store volumes are entirely determined by the instance type you choose. In this step, you'll use the AWS CLI to explore how different instance types offer different instance store configurations, then build a decision framework for the exam.

In this step, get ready to:
  • Query instance store specs for multiple instance types using the AWS CLI.
  • Discover which instance families include instance store volumes.
  • Build a decision framework for choosing instance store vs. EBS on the exam.
Query instance store specs with the AWS CLI

The describe-instance-types command lets you look up the exact instance store configuration for any EC2 instance type. You'll run these commands from your local terminal, not the SSH session.

  • Open a new terminal window on your local machine, or switch to the local terminal where you previously ran AWS CLI commands (not the SSH session).
  • Check the instance store specs of your m5d.large by running this command:
aws ec2 describe-instance-types --instance-types m5d.large --query "InstanceTypes[*].{Type:InstanceType,TotalGB:InstanceStorageInfo.TotalSizeInGB,DiskCount:InstanceStorageInfo.Disks[0].Count,DiskSizeGB:InstanceStorageInfo.Disks[0].SizeInGB,DiskType:InstanceStorageInfo.Disks[0].Type,NVMESupport:InstanceStorageInfo.NvmeSupport}" --output table

What does this command do?

  • --instance-types m5d.large targets the specific instance type you launched.
  • --query uses a JMESPath expression to extract just the storage fields from the full response.
  • --output table formats the result as a readable table instead of raw JSON.

You should see a table confirming your instance has 1 x 75 GB NVMe SSD instance store.

Now let's see how instance store configurations change across different instance types and sizes.

  • Compare instance store configurations across four different instance types by running this command:
aws ec2 describe-instance-types --instance-types m5d.large m5d.xlarge m5d.2xlarge i3.large --query "InstanceTypes[*].{Type:InstanceType,TotalGB:InstanceStorageInfo.TotalSizeInGB,DiskCount:InstanceStorageInfo.Disks[0].Count,DiskSizeGB:InstanceStorageInfo.Disks[0].SizeInGB,DiskType:InstanceStorageInfo.Disks[0].Type}" --output table

What should I see?

Your table should show four rows with increasing storage sizes:

  • m5d.large: 1 x 75 GB NVMe SSD.
  • m5d.xlarge: 1 x 150 GB NVMe SSD.
  • m5d.2xlarge: 1 x 300 GB NVMe SSD.
  • i3.large: 1 x 475 GB NVMe SSD.

Notice how the storage doubles with each m5d size increase. The i3 (storage-optimized) family provides an even larger volume at the same large size.

Why does this matter for the exam?

The SAA-C03 tests whether you understand that instance store size is fixed by the instance type. You cannot resize an instance store volume or add more volumes to a running instance.

If you need more instance store, you must choose a larger or different instance type.

Not seeing a table output?

  • Make sure you are running this in your local terminal, not inside the SSH session to your EC2 instance.
  • Check that your AWS CLI is configured with the correct region by running aws configure get region.
  • If you see a JSON parsing error, double-check that the quotes around the --query value are correct.

Help me troubleshoot the describe-instance-types command

Discover which instance types have instance store

You have compared a handful of instance types, but dozens of EC2 instance types include instance store. The AWS CLI can filter for all of them at once.

  • List all current-generation instance types that support instance store by running this command:
aws ec2 describe-instance-types --filters "Name=instance-storage-supported,Values=true" "Name=current-generation,Values=true" --query "InstanceTypes[*].InstanceType" --output text

What does this command do?

  • The --filters parameter narrows results to instance types where instance-storage-supported is true and current-generation is true.
  • The output is a long list of instance type names. Scroll through to spot the patterns.

You should see a large list of instance type names printed to your terminal. Look at the names closely. Two patterns emerge.

What is the "d" suffix naming convention?

In EC2 instance type naming, the letter "d" after the generation number means the instance includes instance store volumes. You will see types like c5d, m5d, r5d, c6gd, and m6gd throughout the list.

If an instance type does not have a "d" in its name, it does not include instance store. For example, m5.large has no instance store, but m5d.large does.

What about storage-optimized instance families?

Storage-optimized instances always include instance store, regardless of the "d" suffix. These families are designed for workloads that need high sequential read/write access to large datasets on local storage.

The storage-optimized families include: I3, I3en, I4g, I4i, I7i, I7ie, I8g, I8ge, Im4gn, Is4gen, D2, D3, D3en, and H1. You do not need to memorize every one for the exam, but know that the I-family and D-family always come with instance store.

Seeing an empty output or error?

  • Make sure both --filters values are wrapped in quotes. Each filter is its own quoted string.
  • If you see a pagination token, the results are too large for one page. Add --no-paginate to the end of the command to get the full list.

Help me troubleshoot the filtered describe-instance-types query

Understand the SAA-C03 exam angle

For the SAA-C03 exam, you need a clear mental model of when to choose instance store vs. EBS. The exam tests this across multiple domains, including resilient architectures, high-performing architectures, and cost-optimized architectures.

When should I choose instance store?

Choose instance store when:

  • You need the lowest latency local storage. The disk is physically attached to the host machine.
  • Your data is temporary. Caches, buffers, and scratch data that can be regenerated fit perfectly.
  • Your application replicates data across a fleet. If one node fails, others hold copies of the data.
  • You want no additional storage cost. Instance store is included in the instance price.

When should I choose EBS?

Choose EBS when:

  • Data must persist beyond the instance lifecycle. EBS volumes survive stop/start and even termination (if configured).
  • You need snapshots or backups. EBS supports point-in-time snapshots stored in S3.
  • You need to detach and reattach volumes between instances. Instance store volumes cannot be detached.
  • You need encryption with custom KMS keys. Instance store encryption is automatic and uses hardware keys you cannot control.

Knowing which workloads fit each storage type is just as important as knowing the persistence rules.

What are ideal use cases for instance store?

If you see any of these workloads in an exam question, instance store is likely the right answer:

  • NoSQL databases with built-in replication like Cassandra. Each node replicates data, so losing one node's local disk is recoverable.
  • Elasticsearch clusters. Search indexes can be rebuilt from the primary data store.
  • In-memory databases where the disk is only used for spill-over or checkpointing.
  • Temporary processing scratch space for data pipelines, video encoding, or batch jobs.
  • SQL Server tempdb. This system database holds temporary tables and is rebuilt on every restart.

Exam shortcut for instance store questions

If an exam question mentions "lowest latency" or "highest I/O performance" for local storage, instance store is almost always the answer. If it mentions "data must persist" or "snapshots," the answer is EBS.

Secret mission

Benchmark Instance Store vs. EBS Performance

You have proven that instance store data is ephemeral. But there is another reason architects choose instance store for certain workloads: raw I/O performance. Use the fio benchmarking tool to measure the difference yourself.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses an m5d.large EC2 instance that costs approximately $0.113 per hour, so leaving it running will add up.

Cost warning

The m5d.large instance costs ~$0.113/hr while running. The 8 GB gp3 EBS root volume costs ~$0.064/month even when the instance is stopped.

If you are done with this lab, terminate the instance to stop all charges. Stopping the instance still incurs EBS storage costs and erases your instance store data.

Resources you used:

  • 1 x m5d.large EC2 instance (~$0.113/hr while running).
  • 1 x 8 GB gp3 EBS root volume (~$0.064/month while it exists).
  • 1 x EC2 key pair (instance-store-lab-key, no ongoing cost).

Keep everything running

No action needed. Choose this if you are still actively experimenting with the instance and plan to continue shortly.

  • Your m5d.large instance will continue running at ~$0.113/hr.
  • Your instance store data and EBS root volume data remain intact.
  • This is not recommended for a lab environment. Come back to this tab when you are ready to pause or delete.

Pause - I'll come back to this later

Stop the instance to halt compute charges. You will still be charged for the EBS root volume (~$0.064/month).

Instance store data will be lost

Stopping the instance erases all instance store data. This is the core concept you proved in Step 5. Only your EBS root volume data will survive.

  • Stop the instance from your local terminal by running:
aws ec2 stop-instances --instance-ids [[INSTANCE_ID="your EC2 instance ID"]]
  • When you return, start the instance again with:
aws ec2 start-instances --instance-ids [[INSTANCE_ID="your EC2 instance ID"]]
  • Your public IP address may change after a stop/start. Check the new IP in the EC2 console or by running aws ec2 describe-instances.

Delete - I don't want to use this again

Remove all project resources and stop all charges. This is the recommended option once you have finished the lab.

  • Terminate the EC2 instance by running this command from your local terminal:
aws ec2 terminate-instances --instance-ids [[INSTANCE_ID="your EC2 instance ID"]]

Terminating the instance also deletes the default EBS root volume automatically.

  • Delete the key pair if you no longer need it by running:
aws ec2 delete-key-pair --key-name instance-store-lab-key
  • Delete the .pem file from your local machine. It is no longer needed once the key pair is deleted from AWS.

That's a Wrap!

That's a Wrap!

Nice work! You now have hands-on proof of how EC2 instance store behaves across lifecycle events. That mental model will serve you well on the SAA-C03 exam.

Here's what you accomplished:

  • Launched an EC2 instance with an NVMe SSD instance store volume, then discovered, formatted, mounted, and wrote test data to it.
  • Proved that instance store data survives a reboot but vanishes after a stop/start cycle, while EBS data persisted through both.
  • Used the AWS CLI to explore how instance store size is tied to the instance type, and built a decision framework for choosing instance store vs. EBS on the exam.
  • Benchmarked instance store vs. EBS I/O performance using fio and proved the latency advantage of physically attached storage.

Ready to quiz yourself?