Manage Block Storage with Amazon EBS

Create, attach, format, mount, and resize an EBS volume on EC2.

Introduction

30 Second Summary

Every app and server in the cloud needs its own hard drive. In AWS, that hard drive is a block storage volume managed by Amazon EBS.

In this project, you will create, attach, format, and resize an EBS volume on a running EC2 instance. You will perform every core volume operation that the AWS Solutions Architect Associate exam tests.

What You'll Build

You will launch a Linux EC2 instance and manage an EBS data volume through its full lifecycle, including creation, formatting, mounting, and a live resize with zero downtime.

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

A running EC2 instance with a separately created and attached gp3 EBS data volume containing your own files.
A live-resized volume expanded from 8 GiB to 16 GiB using Elastic Volumes with zero downtime.
A clear understanding of root volume vs data volume behavior, Availability Zone constraints, and the Delete on Termination setting.
Secret Mission: Detach your data volume, move it to a second instance, and prove your data survived the move.

Are there any prerequisites?

You need an AWS account with Free Tier eligibility. Basic familiarity with launching EC2 instances is helpful but not required.

Launch an EC2 Instance

Every EBS volume needs an EC2 instance to attach to. Before you can create and manage block storage, you need a running Linux instance in your AWS account.

In this step, you'll launch a t3.micro instance running Amazon Linux 2023, connect to it over SSH, and note which Availability Zone it lands in.

In this step, get ready to:

Launch a t3.micro EC2 instance with Amazon Linux 2023.
Verify SSH connectivity to your instance.
Note the instance's Availability Zone for the next step.

Launch a t3.micro EC2 instance

The EC2 launch wizard walks you through choosing an operating system, instance size, and access settings. You'll also see the default root volume configuration that comes with your instance.

Sign in to the AWS Management Console.
In the search bar at the top, type EC2 and select EC2 from the results.
Click Launch instances (the orange button on the dashboard).

The launch wizard opens with several configuration sections.

Under Name and tags, enter nextwork-ebs-instance.
Under Application and OS Images, confirm Amazon Linux 2023 is selected as the AMI.
Under Instance type, select t3.micro.

Now set up a key pair so you can connect to this instance over SSH.

Under Key pair (login), click Create new key pair.
Enter nextwork-ebs-key as the Key pair name.
Set Key pair type to RSA.
Set Private key file format to .pem.
Click Create key pair.

The .pem file downloads to your computer automatically. Keep track of where it saved, because you'll need it to connect via SSH shortly.

Already have a key pair?

If you already have a .pem key pair from a previous project, you can select it from the dropdown instead of creating a new one.

Under Network settings, confirm the Allow SSH traffic from checkbox is selected.
Scroll down to Configure storage.

Notice the default root volume: 8 GiB of gp3 storage with Delete on Termination set to Yes.

What is Delete on Termination?

When Delete on Termination is set to Yes, the volume is automatically deleted when you terminate the instance.

Root volumes default to Yes (deleted with the instance). Data volumes you create separately default to No (persist after termination). This distinction comes up frequently on the SAA exam.

Leave all other settings at their defaults.
Click Launch instance.

Click View all instances to return to the instances list.
Wait for the Instance state column to show Running. This may take a minute or two.

Instance not starting?

If your instance stays in a Pending state for more than a few minutes, try refreshing the page with your browser's refresh button.

If you see an error about instance limits, your account may have reached its t3.micro limit for this region. Try selecting a different region from the dropdown in the top-right corner of the console.

Help me troubleshoot my EC2 instance launch.

Connect to your instance with SSH

Your instance is running, but you need a way to run commands inside it. SSH lets you open a secure terminal session from your local computer to the remote instance.

In the Instances list, click on your nextwork-ebs-instance to open its details.
Find the Public IPv4 address field and copy the IP address.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Terminal (macOS) or PowerShell (Windows) and press Enter to open it.

macOS

Navigate to your Downloads folder and set the correct permissions on your key file by running these commands:

cd ~/Downloads
chmod 400 [[PEMFILE="your-key-file.pem"]]

Why chmod 400?

SSH requires that your private key file is not accessible by other users on the system. The chmod 400 command sets the file to read-only for you and no access for anyone else. Without this, SSH refuses to use the key.

Connect to your instance by running this command:

ssh -i [[PEMFILE="your-key-file.pem"]] ec2-user@[[EC2_PUBLIC_IP="your instance's public IPv4 address"]]

Windows

Navigate to your Downloads folder by running this command:

cd ~\Downloads

Connect to your instance by running this command:

ssh -i [[PEMFILE="your-key-file.pem"]] ec2-user@[[EC2_PUBLIC_IP="your instance's public IPv4 address"]]

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

You should see the Amazon Linux prompt, which looks something like [ec2-user@ip-172-31-xx-xx ~]$.

Can't connect via SSH?

If you see Permission denied (publickey), make sure you are using the correct .pem file for this instance. On macOS, confirm you ran chmod 400 on the key file.

If you see Connection timed out, check that your instance's security group allows inbound SSH traffic on port 22. Go back to the launch wizard and confirm the Allow SSH traffic from checkbox was selected.

Help me troubleshoot my SSH connection to EC2.

Note your instance's Availability Zone

EBS volumes can only attach to instances in the same Availability Zone. You need to know your instance's AZ so you can create your data volume in the right place.

Go back to the EC2 Console in your browser.
Click on your nextwork-ebs-instance in the Instances list.
In the instance details panel at the bottom, find the Availability Zone field (for example, us-east-1a).
Write down this exact Availability Zone value. You will need it in the next step.

Why does the Availability Zone matter?

EBS volumes are locked to a single Availability Zone. A volume in us-east-1a cannot be attached to an instance in us-east-1b.

To move data across Availability Zones, you would create a snapshot of the volume and restore it in the target zone. For this project, you just need to make sure your volume and instance share the same AZ.

Your EC2 instance is running and you're connected via SSH. Next up, you'll create a brand new EBS data volume and attach it to this instance.

Create and Attach a gp3 Data Volume

Your EC2 instance is running and accessible over SSH.

Every EC2 instance launches with a root volume that holds the operating system. In this step, you'll create a completely separate EBS data volume and attach it to your instance so your data lives independently from the OS.

In this step, get ready to:

Create an 8 GiB gp3 EBS volume in the same Availability Zone as your instance.
Attach the volume to your running EC2 instance.
Compare the Delete on Termination settings between your root and data volumes.

Create a new gp3 volume

Your instance's root volume holds the operating system, but you want a separate place to store data. You'll create a brand new EBS volume from the Volumes page in the EC2 Console.

In the EC2 Console's left sidebar, click Elastic Block Store to expand the section.
Click Volumes.
Click Create volume in the top right corner.
Set Volume type to gp3.
Set Size to 8 GiB.
In the Availability Zone dropdown, select the same Availability Zone as your instance (e.g., us-east-1a).
Leave IOPS at 3000 and Throughput at 125 MiB/s.
Click Create volume.

The console takes you to the volume details page. The State column shows Available once the volume is ready.

What is gp3?

gp3 is the latest generation of general-purpose SSD storage in EBS. Every gp3 volume includes a baseline of 3,000 IOPS and 125 MiB/s throughput at no extra cost, regardless of volume size.

Why the same Availability Zone?

EBS volumes can only attach to EC2 instances in the same Availability Zone. If you pick a different AZ, your instance won't even appear when you try to attach the volume.

You'll see this constraint in action later in the project when you intentionally try to attach a volume across AZs.

Don't see your Availability Zone in the dropdown?

Double check you are in the same AWS Region as your instance. The region selector is in the top right corner of the console. If you launched your instance in us-east-1, make sure the console still shows that region.

Still stuck? Help me find my instance's Availability Zone so I can create a volume in the same AZ.

Attach the volume to your instance

The volume exists now but it isn't connected to your instance. You need to attach it before the instance can see or use it.

On the volume details page, click Actions in the top right.
Select Attach volume.
In the Instance field, select your running instance from the dropdown.
Accept the suggested Device name (e.g., /dev/sdf).
Click Attach volume.

The volume's State changes from Available to In-use. Your data volume is now attached to your instance.

Why does the device name look different inside the instance?

The device name /dev/sdf is what the console uses. On NVMe-based instances like t3.micro, the volume appears as /dev/nvme1n1 inside the operating system.

You'll see this NVMe name when you run commands in your SSH session in the next step.

Instance not showing in the dropdown?

Your instance only appears if it is in the same Availability Zone as the volume. Go back to Instances in the left sidebar and check the Availability Zone column for your instance. If it does not match the volume's AZ, you will need to delete this volume and create a new one in the correct AZ.

Also confirm your instance is in the Running state. Stopped or terminated instances can still appear, but you should attach to a running instance for this project.

Need more help? My instance is not showing up when I try to attach my EBS volume.

Compare Delete on Termination between your volumes

Your instance now has two volumes attached. There is an important difference in how AWS treats them when you terminate the instance.

In the left sidebar, click Instances.
Select your running instance by clicking on its Instance ID.
Click the Storage tab in the instance details panel.
Under Block devices, scroll right to find the Delete on termination column.
Note the value for your root volume (/dev/xvda). It shows Yes.
Note the value for your data volume (/dev/sdf). It shows No.

What is Delete on Termination?

This setting controls what happens to a volume when its EC2 instance is terminated. Root volumes default to Yes, meaning they are automatically deleted along with the instance.

Data volumes you attach separately default to No, meaning they persist even after the instance is terminated. If you terminate your instance right now, the root volume would be deleted but your data volume would remain intact.

This is a frequently tested concept on the SAA-C03 exam.

Your data volume is attached and ready. In the next step, you'll SSH into your instance, format this volume with a filesystem, mount it, and write your first test data.

Format, Mount, and Write Data

Your data volume is attached to your instance and shows as in-use in the console. The operating system sees it as raw storage with no filesystem.

Before you can save any files, you need to format the volume with a filesystem and mount it to a directory. In this step, you will create an XFS filesystem, mount your EBS volume at /data, and write a test file.

In this step, get ready to:

Verify the attached volume appears as a block device with no filesystem.
Format the volume with an XFS filesystem and mount it at /data.
Write test data and confirm it persists on the volume.

Verify your attached volume

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

lsblk

You should see two devices: nvme0n1 (your root volume, with partitions like nvme0n1p1) and nvme1n1 (your data volume, with no partitions and no mount point).

Why does my device show as nvme1n1?

Your t3.micro instance runs on the NVMe-based Nitro platform. EBS volumes on Nitro instances appear as NVMe devices instead of the traditional /dev/xvd* names.

The device name you picked in the console (/dev/sdf) maps to /dev/nvme1n1 inside the operating system. Both names refer to the same volume.

Confirm the data volume has no filesystem yet by running:

sudo file -s /dev/nvme1n1

The output should read /dev/nvme1n1: data. The word data means the device is raw storage with no filesystem on it.

Don't see nvme1n1 in the output?

Go back to the EC2 Console and check the Volumes page. Confirm your data volume state is in-use and attached to the correct instance.
If your volume shows as available, it was not attached. Go back to Step 2 and attach it to your instance.
The NVMe device number may vary. Run lsblk and look for any device that is 8 GiB with no mount point.
Still stuck? Help me troubleshoot why my EBS volume does not appear as a block device in lsblk.

Format and mount the volume

A raw volume is like a brand new hard drive. You need to create a filesystem on it before the operating system knows how to organize files there.

Create an XFS filesystem on the volume, create a mount point directory, and mount the volume by running these commands:

# Create an XFS filesystem on the data volume
sudo mkfs -t xfs /dev/nvme1n1

# Create a directory to serve as the mount point
sudo mkdir /data

# Mount the volume to the /data directory
sudo mount /dev/nvme1n1 /data

What do these commands do?

mkfs -t xfs creates an XFS filesystem on the raw device. Amazon Linux 2023 uses XFS as its default filesystem, so this keeps things consistent.
mkdir /data creates the directory where you will access the volume's contents.
mount connects the volume to that directory. Any files you write to /data are stored on the EBS volume.

Verify the volume is mounted and shows the correct size by running:

df -hT /data

You should see /dev/nvme1n1 listed with type xfs and approximately 8.0 GiB of space.

Seeing a 'wrong fs type' or 'mount point does not exist' error?

Make sure you ran the commands in order. The mkfs command must finish before mount, and mkdir /data must exist before you mount to it.
If you see mount: /dev/nvme1n1: can't read superblock, the filesystem was not created successfully. Re-run the mkfs command.
Double check that you are using /dev/nvme1n1 (your data volume), not /dev/nvme0n1 (your root volume).
Need a hand? Help me troubleshoot errors when formatting and mounting my EBS volume.

Write test data to the volume

Write a test message to a file on your mounted volume by running this command:

sudo sh -c 'echo "Hello from my EBS volume!" > /data/testfile.txt'

Why use sudo sh -c?

The /data directory is owned by root. Running sudo sh -c executes the entire command (including the file redirect >) as root, so it has permission to write into /data.

Read the file back to confirm it was saved by running:

cat /data/testfile.txt

You should see Hello from my EBS volume! printed in your terminal.

Run lsblk one more time to confirm your data volume now shows its mount point:

lsblk

The nvme1n1 device should now show /data in the MOUNTPOINTS column.

Seeing 'Permission denied'?

Make sure you included sudo sh -c at the start of the write command. A plain sudo echo does not give root permission to the > redirect.
Confirm the volume is still mounted by running df -hT /data. If it shows no output, re-mount the volume with sudo mount /dev/nvme1n1 /data.
Still stuck? Help me troubleshoot a permission denied error when writing to my mounted EBS volume.

Your volume is formatted, mounted, and holding real data. In the next step, you will resize this volume live with zero downtime using Elastic Volumes.

Resize the Volume with Elastic Volumes

Your EBS data volume is formatted, mounted, and holding your test file. What happens when you need more storage space?

In production, resizing storage usually means downtime. AWS solves this with Elastic Volumes, a feature that lets you increase EBS volume size while the volume stays attached and in use.

In this step, get ready to:

Resize your data volume from 8 GiB to 16 GiB in the EC2 Console.
Extend the XFS filesystem to use the new space.
Verify your data survived the resize.

Modify the volume size in the EC2 Console

In the EC2 Console, click Volumes under Elastic Block Store in the left sidebar.
Select your 8 GiB data volume (the one with Delete on Termination set to No).
Click Actions, then select Modify volume.
Change the Size field from 8 to 16.
Click Modify.
Click Yes to confirm the modification.

Watch the Volume state column for your data volume. It changes from in-use to optimizing and eventually back to in-use.

What is Elastic Volumes?

Elastic Volumes is an EBS feature that lets you resize volumes, change volume types, and adjust performance settings while the volume stays attached and mounted. Your data volume just went from 8 GiB to 16 GiB with zero downtime.

The IOPS and throughput stayed at their gp3 baselines (3,000 IOPS and 125 MiB/s). You can adjust those independently too, but for this project the defaults are plenty.

Extend the filesystem to use the new space

The console resize changed the raw block device size, but the filesystem sitting on top of it still thinks it has 8 GiB. You need to extend the filesystem separately.

In your SSH session, check the block device size by running:

lsblk

You should see nvme1n1 listed as 16G. The block device knows about the new space.

Now check the filesystem size by running:

df -hT /data

The filesystem still shows approximately 8 GiB in the Size column. This is the gap you need to close.

Why didn't the filesystem expand automatically?

A block device and a filesystem are two separate layers. Resizing the EBS volume only changes the block device (the raw storage). The XFS filesystem on top of it has its own record of how much space it manages. You need to explicitly tell the filesystem to grow.

Extend the XFS filesystem to fill the entire volume by running:

sudo xfs_growfs -d /data

What does this command do?

xfs_growfs extends an XFS filesystem to fill all available space on its block device.
The -d flag tells it to grow the data section of the filesystem.
Since your data volume is a raw volume with no partition table, you skip the growpart step entirely and go straight to growing the filesystem. Root volumes have partitions and would need growpart first.

Verify the filesystem expanded by running:

df -hT /data

The Size column should now show approximately 16 GiB for the /data mount point. The filesystem type column should still show xfs.

Still seeing 8 GiB?

Make sure you ran the command with sudo. The xfs_growfs command requires root permissions.
Check the EC2 Console to confirm the volume modification completed. The volume state should show in-use or optimizing. If it still shows modifying, wait a minute and try again.
Run lsblk to confirm the block device shows 16G. If it still shows 8G, the console modification has not completed yet.

Why isn't my XFS filesystem extending after the volume resize?

Verify your data survived the resize

Confirm your test file is still intact by running:

cat /data/testfile.txt

You should see Hello from my EBS volume! printed to the terminal. Your data is completely intact.

Run lsblk one more time to see the full picture:

lsblk

You should see nvme1n1 listed as 16G with /data as its mount point. The resize is fully complete.

Key SAA exam takeaways

Elastic Volumes resizes are non-destructive. Your data stays intact throughout the process.
You can only increase volume size, never decrease it.
You can perform up to four modifications per volume in a rolling 24-hour period.
After resizing, you must manually extend the filesystem. The OS does not do this automatically.

Your data volume now has 16 GiB of space with all your files intact. Next, you will explore the key differences between root volumes and data volumes.

Explore Root Volume Behavior

In the last step, you resized your EBS data volume live from 8 to 16 GiB and extended the XFS filesystem to match. Your data survived the entire process with zero downtime.

Now it is time to explore how root volumes and data volumes behave differently. These differences are frequently tested on the SAA-C03 exam, so experiencing them firsthand gives you a major advantage.

In this step, get ready to:

Compare root volume and data volume Delete on Termination settings.
Test the Availability Zone constraint by creating a volume in a different AZ.
Review the five key SAA takeaways from this project.

Compare Delete on Termination settings

Your instance currently has two EBS volumes attached. Each has a different Delete on Termination setting that controls what happens to the volume when the instance is terminated.

In the EC2 Console, click on your running instance to open its details.
Click the Storage tab at the bottom of the page.
Find two volumes listed: the root volume with device name /dev/xvda and the data volume with device name /dev/sdf.
Look at the Delete on Termination column for each volume.

The root volume shows Yes for Delete on Termination. The data volume shows No.

What does Delete on Termination mean?

When you terminate an EC2 instance, any volume with Delete on Termination set to Yes is automatically deleted along with the instance.

Root volumes default to Yes because the operating system is tied to that specific instance. Data volumes attached after launch default to No because AWS assumes your data should outlive the instance.

Test the Availability Zone constraint

EBS volumes can only attach to instances in the same Availability Zone. You will prove this by creating a volume in a different AZ and attempting to attach it to your instance.

In the EC2 Console, click Elastic Block Store in the left sidebar, then click Volumes.
Click Create volume.
Set Volume type to gp3.
Set Size to 1 GiB.
For Availability Zone, select a different AZ than your instance. For example, choose us-east-1b if your instance is in us-east-1a.
Click Create volume.

Wait until the volume state shows available, then select it.
Click Actions, then Attach volume.

Your instance does not appear in the Instance dropdown. The console only shows instances that are in the same Availability Zone as the volume.

Click Cancel to close the attachment dialog.
With the test volume still selected, click Actions, then Delete volume.
Click Delete to confirm.

Why are EBS volumes locked to one Availability Zone?

EBS volumes are physical storage within a single data center. Each Availability Zone is a separate data center, so a volume in one AZ cannot be directly attached to an instance in another.

To move data across AZs, you would create a snapshot of the volume and restore it in the target AZ. Snapshots are a separate topic covered in a different project.

Instance appearing in the dropdown?

If your instance shows up when you try to attach, you accidentally selected the same Availability Zone as your instance when creating the test volume. Delete this volume and create a new one, making sure to pick a different AZ.

You can check your instance's AZ from the Networking tab in the instance details. Help me find my instance's Availability Zone so I can pick a different one for my test volume.

Review the key SAA takeaways

You have now experienced every core EBS volume operation firsthand. Here are five key takeaways that are frequently tested on the SAA-C03 exam.

EBS volumes are AZ-locked. You cannot attach a volume to an instance in a different Availability Zone.
Root volumes default to Delete on Termination = Yes. Data volumes attached after launch default to No. This means terminating an instance deletes the root volume but preserves data volumes.
Elastic Volumes allows live resizing with zero downtime. You can only increase volume size, never decrease it. You can make up to four modifications per volume in a rolling 24-hour period.
After resizing, you must manually extend the filesystem. For XFS, the command is xfs_growfs. The OS does not do this automatically.
gp3 provides a baseline of 3,000 IOPS and 125 MiB/s. This baseline is included at no extra charge regardless of volume size.

Bookmark these for exam day

The SAA-C03 exam loves to test whether you know that EBS volumes are AZ-locked and that root volumes are deleted on termination by default. If you remember nothing else, remember those two facts.

Secret mission

Prove Data Survives Instance Changes

Your data volume has been attached to a single instance this whole time. But what happens if that instance disappears? In this mission, you will detach your volume, attach it to a brand new instance, and prove your data survived the move.

Before you go

Clean Up Your Resources

This project created AWS resources that may incur charges once your Free Tier period expires. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Cost warning

Your t3.micro EC2 instances and gp3 EBS volumes are covered under the AWS Free Tier for 12 months. This includes 750 instance hours per month and 30 GB of total EBS storage.

If your Free Tier period has expired or you have exceeded these limits, choose Pause or Delete to avoid unexpected charges.

Resources you used:

One t3.micro EC2 instance launched in Step 1.
One gp3 EBS data volume (resized to 16 GiB in Step 4).
A second t3.micro EC2 instance, if you completed the Secret Mission.
A test volume in a different Availability Zone (should already be deleted from Step 5).

Keep everything running

No action needed. Choose this if you are still within your AWS Free Tier period and want to keep experimenting with your EBS volumes.

Your t3.micro instance is covered for 750 hours per month under the Free Tier.
Your gp3 volumes are covered up to 30 GB of total EBS storage under the Free Tier.
Monitor your usage in the AWS Billing Dashboard to avoid unexpected charges.

Pause - I'll come back to this later

Stop your EC2 instances to halt compute charges while keeping your volumes and data intact.

In the EC2 Console, select your running instance.
Click Instance state.
Click Stop instance.
Click Stop to confirm.
Repeat for any additional instances you launched during the Secret Mission.

Stopped instances do not incur compute charges. Your EBS volumes continue to use storage, but this is covered under the Free Tier if your total storage is under 30 GB.

Delete - I don't want to use this again

Terminate all instances and delete all remaining volumes to ensure zero ongoing charges.

In the EC2 Console, select each running or stopped instance.
Click Instance state.
Click Terminate instance.
Click Terminate to confirm.

Root volumes are automatically deleted when you terminate an instance. Your data volume persists because its Delete on Termination setting is No.

In the EC2 Console left sidebar, expand Elastic Block Store.
Click Volumes.
Select any volumes with a state of available.
Click Actions.
Click Delete volume.
Click Delete to confirm.

Mission accomplished

That's a Wrap!

Nice work! You just completed a full EBS volume lifecycle, from creating and attaching a volume all the way through to a live resize with zero downtime.

You've learned how to:

Created, attached, formatted, and mounted a gp3 EBS volume to a running EC2 instance, then stored data on it using an XFS filesystem.
Resized the volume live from 8 GiB to 16 GiB using Elastic Volumes and extended the filesystem to use the new space, all with zero downtime.
Explored root volume vs data volume behavior, the Delete on Termination setting, and verified that EBS volumes are locked to a single Availability Zone.
Secret Mission: Proved that EBS data volumes persist independently of EC2 instances by detaching a volume, moving it to a new instance, and confirming your data survived.

Ready to quiz yourself?