Compare EBS Volume Types and Tune Performance

Introduction

30 Second Summary

Picking the wrong storage for a cloud application can mean paying ten times more than you need to. AWS offers six different EBS volume types, each built for a different performance profile.

In this project, you will create real volumes of all six types and compare their specifications in the AWS console. You will also use Elastic Volumes to live-switch between types and set up Multi-Attach to share a single volume across two instances.

What You'll Build

You will build an EBS volume comparison lab using two EC2 instances to explore every volume type and performance feature tested on the SAA-C03 exam.

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

• Six EBS volumes (gp3, gp2, io2, io1, st1, sc1) created and compared side by side in the console.
• A live Elastic Volumes type-switch from gp2 to gp3 to io2, plus independently tuned IOPS and throughput on a gp3 volume.
• An io2 Multi-Attach volume connected to two EC2 instances simultaneously, with an understanding of instance-level bandwidth limits.
• Secret Mission: Calculate monthly storage costs for real-world scenarios and recommend the cheapest volume type for each.

Are there any prerequisites?

You need an AWS account with admin access and basic familiarity with EC2 (launching instances and connecting via SSH).

This project assumes you have completed prior EBS projects in this learning path. If this is your first time working with EBS, start with the earlier projects in the series first.

Launch Two EC2 Instances in the Same Availability Zone

This project is a hands-on lab where you create, compare, and modify real EBS volumes. To do that, you need EC2 instances to attach those volumes to.

You will launch two instances in the same Availability Zone because EBS volumes can only attach to instances within their own AZ. The second instance is specifically for the Multi-Attach exercise later in the project.

In this step, get ready to:

• Launch EBS-Lab-Instance-A with Amazon Linux 2023.
• Launch EBS-Lab-Instance-B in the same Availability Zone.
• Connect to Instance A via SSH.

Launch Instance A

• In the search bar at the top of the AWS Management Console, type EC2 and select EC2 from the results.
• Click Launch instances.
• Under Name and tags, enter EBS-Lab-Instance-A.
• Under Application and OS Images, confirm Amazon Linux 2023 AMI is selected. It should be the default and marked Free tier eligible.
• Under Instance type, select t3.micro.
• Under Key pair (login), select an existing key pair from the dropdown.

Need to create a key pair?

Click Create new key pair. Enter a name, select .pem as the file type, and click Create key pair.

Your browser downloads the .pem file automatically. Save it somewhere you can find it later.

• Under Network settings, keep the default VPC and subnet.
• Note the Availability Zone that gets auto-selected (for example, us-east-1a). Write this down. You will need to pick the same AZ for Instance B.
• Expand Advanced details at the bottom of the page.
• Scroll down and confirm EBS-optimized instance is set to Enabled. It is on by default for t3.micro.
• Leave the default 8 GiB gp3 root volume under Configure storage.
• Click Launch instance.

You should see a success message confirming your instance is launching.

Why the same Availability Zone?

EBS volumes are locked to a single Availability Zone. A volume in us-east-1a can only attach to instances in us-east-1a.

Later in this project, you will attach a single volume to both instances at the same time using Multi-Attach. That feature also requires all instances to share the same AZ.

What is EBS-optimized?

An EBS-optimized instance has dedicated bandwidth for EBS I/O, separate from its regular network traffic. The t3.micro is a Nitro-based instance, so it comes with EBS optimization enabled by default.

Launch Instance B in the same Availability Zone

Instance B uses identical settings to Instance A, with one critical difference. You need to manually select the same Availability Zone.

• Back on the EC2 dashboard, click Launch instances again.
• Under Name and tags, enter EBS-Lab-Instance-B.
• Select the same AMI (Amazon Linux 2023), instance type (t3.micro), and key pair as Instance A.
• Under Network settings, click Edit.
• Expand the Subnet dropdown and select the subnet that matches the Availability Zone you wrote down from Instance A (for example, the us-east-1a subnet).
• Leave everything else the same.
• Click Launch instance.

• Navigate back to your Instances dashboard by clicking Instances in the left sidebar.
• Wait for both instances to show Running in the Instance state column, with 2/2 checks passed in the Status check column. This can take 1-2 minutes.
• Confirm both instances are in the same Availability Zone by checking the Availability Zone column on the Instances dashboard.

Instances not in the same AZ?

If your two instances ended up in different Availability Zones, terminate Instance B (select it, then Instance state > Terminate instance). Then relaunch it, making sure to select the correct subnet matching Instance A's AZ.

Help me fix my Availability Zone mismatch.

Connect to Instance A via SSH

You need a terminal connection to Instance A for running AWS CLI commands later in the project.

• Select EBS-Lab-Instance-A in the Instances dashboard.
• Click Connect at the top of the page.
• Select the SSH client tab. This page shows the exact SSH command you need.

• Open a terminal on your local machine. Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
• Type PowerShell (Windows) or Terminal (macOS) and press Enter to open it.
• Navigate to the folder where your key pair .pem file is saved by running:

cd [[PEM_FOLDER="folder where you saved your .pem file, e.g. ~/Downloads"]]

• Connect to Instance A by running this SSH command:

ssh -i [[PEMPATH="your-key.pem"]] ec2-user@[[EC2_A_IP="Instance A public IPv4 address"]]

What does this command do?

• ssh opens a secure shell connection to a remote server.
• -i specifies the private key file to authenticate with.
• ec2-user is the default username for Amazon Linux instances.

• If prompted to confirm the host fingerprint, type yes and press Enter.

You should see the Amazon Linux prompt. Keep this terminal window open for the rest of the project.

Connection timing out or refused?

• Make sure Instance A's status checks show 2/2 checks passed before attempting to connect.
• Confirm your security group allows inbound SSH on port 22. The default security group created during launch should include this rule.
• Check that you copied the correct public IPv4 address from Instance A (not Instance B).

Help me troubleshoot my SSH connection to EC2.

Seeing a permissions error on your key file?

If you see a warning about your key file being too open, your .pem file's permissions need to be restricted.

On macOS or Linux, run chmod 400 your-key.pem in your terminal. On Windows PowerShell, right-click the file, go to Properties > Security > Advanced, disable inheritance, and remove all users except your own.

Help me fix my .pem file permissions.

Both instances are running and you have a live SSH session into Instance A. Next up, you will create one volume of every EBS type and compare their specs side by side.

Create and Compare All Six Volume Types

Your two EC2 instances are running in the same Availability Zone and your SSH connection to Instance A is active. Now it's time to create the EBS volumes you will work with for the rest of this project.

AWS offers six different EBS volume types split into two categories: SSD-backed for random I/O and HDD-backed for sequential throughput. In this step, you will create one of each type and compare their specs in the console.

In this step, get ready to:

• Create four SSD-backed volumes (gp3, gp2, io2, io1).
• Create two HDD-backed volumes (st1, sc1).
• Compare all six volumes' specifications side by side in the console.

Create the four SSD volumes

You will create all four SSD volume types one at a time, each in the same Availability Zone as your instances. The first volume is gp3, which is the most commonly used general purpose type.

• In the EC2 console left navigation, click Volumes under Elastic Block Store.
• Click Create volume.
• For Volume type, select General Purpose SSD (gp3).
• Set Size to 10 GiB.
• Leave the default IOPS (3000) and Throughput (125 MB/s) unchanged.
• For Availability Zone, select the same AZ as your instances (e.g., us-east-1a).
• Scroll down to Tags and click Add tag.
• Enter Name for the Key and gp3-test for the Value.
• Click Create volume.

What are IOPS and throughput?

IOPS stands for Input/Output Operations Per Second. It measures how many read or write operations a volume can handle each second. Higher IOPS means faster performance for small, random data access like database queries.

Throughput measures how much data (in MB/s) a volume can transfer per second. Higher throughput means faster performance for large, sequential data access like reading log files. These two metrics define how each volume type performs.

Now create the gp2 volume. This type works differently from gp3 because it ties performance directly to volume size.

• Click Create volume.
• For Volume type, select General Purpose SSD (gp2).
• Set Size to 10 GiB.
• Notice there are no IOPS or Throughput fields to configure.
• For Availability Zone, select the same AZ as your instances.
• Add a tag with Key Name and Value gp2-test.
• Click Create volume.

Why doesn't gp2 have IOPS or Throughput fields?

gp2 ties its IOPS directly to volume size at a rate of 3 IOPS per GiB. A 10 GiB volume gets a baseline of 30 IOPS, but AWS enforces a minimum of 100 IOPS. Volumes under 1 TiB can burst to 3,000 IOPS using an I/O credit system.

gp3 decouples IOPS and throughput from size completely. That is why gp3 shows separate fields for these settings and gp2 does not.

Next, create the two provisioned IOPS volumes. These are designed for workloads that need guaranteed, consistent performance.

• Click Create volume.
• For Volume type, select Provisioned IOPS SSD (io2).
• Set Size to 10 GiB.
• Set IOPS to 500.
• For Availability Zone, select the same AZ as your instances.
• Add a tag with Key Name and Value io2-test.
• Click Create volume.

Now create the io1 volume with the same settings.

• Click Create volume.
• For Volume type, select Provisioned IOPS SSD (io1).
• Set Size to 10 GiB.
• Set IOPS to 500. This is the maximum for a 10 GiB io1 volume (50 IOPS per GiB x 10 GiB = 500 IOPS).
• For Availability Zone, select the same AZ as your instances.
• Add a tag with Key Name and Value io1-test.
• Click Create volume.

io1 vs io2 for the exam

io2 has 99.999% durability compared to 99.8-99.9% for io1. It also supports up to 1,000 IOPS per GiB (max 256,000 IOPS), while io1 supports up to 50 IOPS per GiB (max 64,000 IOPS).

io2 also supports I/O fencing for Multi-Attach scenarios, which io1 does not. In practice, io2 has replaced io1 for nearly all use cases.

Create the two HDD volumes

HDD volumes are designed for large, sequential workloads like log processing and data warehousing. They have a minimum size of 125 GiB, which is much larger than the SSD minimum.

• Click Create volume.
• For Volume type, select Throughput Optimized HDD (st1).
• Set Size to 125 GiB (the minimum for HDD volumes).
• For Availability Zone, select the same AZ as your instances.
• Add a tag with Key Name and Value st1-test.
• Click Create volume.

Finally, create the coldest and cheapest volume type.

• Click Create volume.
• For Volume type, select Cold HDD (sc1).
• Set Size to 125 GiB.
• For Availability Zone, select the same AZ as your instances.
• Add a tag with Key Name and Value sc1-test.
• Click Create volume.

HDD volumes cannot be boot volumes

st1 and sc1 cannot be used as the root volume for an EC2 instance. Only SSD volume types (gp3, gp2, io2, io1) can serve as boot volumes. This is a common exam question.

You should now see all six volumes listed on the Volumes page, each with a state of available.

Don't see all six volumes?

Make sure you are in the correct AWS region. Volumes only appear in the region where they were created.

If a volume shows a different Availability Zone than your instances, delete it and recreate it in the correct AZ. Check your instances' AZ by going to Instances and looking at the Availability Zone column.

Why can't I see all my EBS volumes in the console?

Compare volume specs in the console

With all six volumes created, you can now inspect each one to see how AWS reports their performance characteristics. This comparison is where the differences between volume types become concrete.

• Select any volume by clicking its checkbox in the list.
• In the panel below the list, click the Details tab.
• Review the Volume type, Size, IOPS, Throughput, and Encryption status for the selected volume.
• Repeat this for each of the six volumes, noting the differences.

Key observations across all six types

• gp3 shows explicit IOPS (3,000) and Throughput (125 MB/s) even at just 10 GiB. These values are independent of size.
• gp2 shows IOPS based on size (100 IOPS minimum for small volumes). There is no separate throughput setting.
• io2 and io1 show your provisioned IOPS values. io2 has 99.999% durability compared to 99.8-99.9% for all other types.
• st1 and sc1 show no IOPS setting. Their performance is measured in throughput (MB/s).
• Only io1 and io2 support Multi-Attach. The other four types do not.

You now have a complete set of all six EBS volume types to reference. Next up, you will use Elastic Volumes to live-switch between types without any downtime.

Live-Switch Volume Types with Elastic Volumes

In the last step, you created all six EBS volume types and compared their specs side by side. You now have a solid mental model of the SSD and HDD categories.

What happens when your workload outgrows its current volume type? Elastic Volumes lets you change a volume's type, size, IOPS, and throughput while it stays attached to a running instance. Zero downtime required.

In this step, get ready to:

• Attach the gp2-test volume to Instance A and live-switch it to gp3.
• Modify the same volume again from gp3 to io2 without detaching or rebooting.
• View the full modification history using the AWS CLI from Instance A.

Attach the gp2 volume and modify it to gp3

The gp2 to gp3 migration is one of the most common Elastic Volumes operations and a frequent SAA-C03 exam topic. gp3 is 20% cheaper per GiB than gp2 and decouples IOPS and throughput from volume size.

First, attach the gp2 volume to an instance so you can modify it while it is in use.

• In the EC2 console, go to Elastic Block Store in the left sidebar, then click Volumes.
• Select the gp2-test volume.
• Click Actions, then click Attach volume.
• In the Instance dropdown, choose EBS-Lab-Instance-A.
• Accept the suggested device name.
• Click Attach volume.

The volume state changes from Available to in-use. Now you can modify it while it stays attached.

• Select the gp2-test volume again.
• Click Actions, then click Modify volume.
• Change the Volume type dropdown from gp2 to gp3.

Two new fields appear: IOPS and Throughput. With gp2, performance was tied to volume size. gp3 lets you configure these values independently.

• Leave IOPS at 3000 and Throughput at 125 MB/s.
• Click Modify.
• Click Modify again in the confirmation dialog.
• Watch the Volume state column in the Volumes list.

The state changes to in-use - modifying (0%), then in-use - optimizing, and finally back to in-use when the modification is complete.

What are the modification states?

Every Elastic Volumes modification goes through three states: modifying, optimizing, and completed.

Size increases take effect during the optimizing stage. Performance changes (IOPS and throughput) can take minutes to hours to fully apply.

Why is gp2 to gp3 such a common migration?

gp3 costs $0.08/GiB-month compared to gp2's $0.10/GiB-month. That is a 20% savings just by switching types.

gp3 also gives you 3,000 IOPS and 125 MB/s of throughput as a free baseline regardless of volume size. With gp2, you would need a 1,000 GiB volume to reach 3,000 baseline IOPS (3 IOPS per GiB). The SAA-C03 exam loves asking about this migration path.

Modify the same volume from gp3 to io2

Elastic Volumes supports chaining modifications on the same volume. You can go from gp2 to gp3, and then from gp3 to io2, all without detaching.

• Wait for the first modification to reach the completed state. This usually takes a few minutes.
• Select the gp2-test volume again.
• Click Actions, then click Modify volume.
• Change the Volume type dropdown from gp3 to io2.
• Set IOPS to 1000.
• Click Modify.
• Click Modify again to confirm.
• Watch the Volume state column go through the same modifying, optimizing, and completed cycle.

How many times can you modify a volume?

You can modify a volume up to 4 times in a rolling 24-hour period. Each modification must reach the completed state before you can start the next one.

You also cannot decrease a volume's size. If you need a smaller volume, you must create a new one and migrate data to it. You cannot cancel a submitted modification either. These are key details for the SAA-C03 exam.

Modify volume option is greyed out?

The previous modification must reach the completed state before you can start another. Refresh the Volumes page and check the Volume state column. If it still shows optimizing, wait a few more minutes.

Help me figure out why I can't modify my EBS volume.

Observe the modification history with the CLI

The AWS console shows only the current state of a volume. To see the full history of all your modifications, including original and target types, you can use the AWS CLI from your SSH session on Instance A.

• In your SSH terminal connected to Instance A, view all volume modifications by running this command:

aws ec2 describe-volumes-modifications --region [[AWS_REGION="your AWS region e.g. us-east-1"]] --query "VolumesModifications[*].{ID:VolumeId,From:OriginalVolumeType,To:TargetVolumeType,State:ModificationState,Progress:Progress}" --output table

What does this command do?

• describe-volumes-modifications fetches the modification history for all EBS volumes in the specified region.
• The --query flag filters the output down to five useful fields: volume ID, original type, target type, modification state, and progress percentage.
• The --output table flag formats the results as a readable table instead of raw JSON.

You should see a table with two rows. One row shows the gp2 to gp3 modification, and the other shows the gp3 to io2 modification. Each row shows its state and progress percentage.

AWS CLI is pre-installed on Amazon Linux 2023

Amazon Linux 2023 includes the AWS CLI by default. The CLI uses the instance's IAM role for authentication if one is attached.

If your instance does not have an IAM role, you can configure credentials manually by running aws configure and entering your AWS access key ID and secret access key when prompted.

Seeing 'Unable to locate credentials'?

This means your instance does not have an IAM role attached and no credentials are configured. Run aws configure and enter your AWS access key ID, secret access key, and region when prompted.

If you see an empty table, your modifications may still be in progress. Wait a few minutes and run the command again.

Help me troubleshoot my AWS CLI command on EC2.

Your gp2-test volume has traveled from gp2 to gp3 to io2, all while staying attached to a running instance. Next up, you will tune a gp3 volume's IOPS and throughput independently to see how gp3 decouples performance from capacity.

Tune gp3 IOPS and Throughput Independently

In the last step, you used Elastic Volumes to live-switch a volume's type without any downtime. Now you'll explore the feature that makes gp3 the default choice for most workloads.

With gp2, performance is locked to volume size. gp3 breaks that link, letting you dial IOPS and throughput up or down without touching the volume size at all.

In this step, get ready to:

• Attach the gp3-test volume and double its IOPS from 3,000 to 6,000.
• Increase throughput from 125 MB/s to 250 MB/s without changing IOPS or size.
• Review your t3.micro instance's EBS bandwidth limits and understand the instance-level bottleneck.

Attach the gp3 volume and increase its IOPS

Your gp3-test volume is currently unattached. You need to attach it to an instance before you can tune its performance and see the results.

• In the EC2 console, go to Elastic Block Store, then Volumes.
• Select the volume named gp3-test. This is the one you originally created as gp3, not the volume you converted from gp2 in the last step.
• Click Actions, then Attach volume.
• In the Instance dropdown, select EBS-Lab-Instance-A.
• Accept the suggested device name.
• Click Attach volume.

Now you'll modify the volume's IOPS while it stays attached and in use.

• Select the gp3-test volume again.
• Click Actions, then Modify volume.
• Change IOPS from 3000 to 6000.
• Leave Throughput at 125 MB/s.
• Leave Size at 10 GiB.
• Click Modify.
• Click Modify again to confirm.

Watch the Volume state column. It changes to in-use - modifying as the modification begins.

Why is doubling IOPS without changing size a big deal?

With gp2, IOPS are tied to volume size at a ratio of 3 IOPS per GiB. To get 6,000 IOPS on gp2, you would need a 2,000 GiB volume.

You just doubled the IOPS on a 10 GiB volume without touching its size. This decoupling is gp3's biggest advantage over gp2 and a frequent SAA-C03 exam topic.

Modify volume greyed out?

• If a previous modification from Step 3 is still in progress, wait for it to reach the completed state before starting a new one.
• Each volume can only be modified 4 times per rolling 24-hour period. If you have hit this limit, wait and try again later.
• Help me figure out why I can't modify my EBS volume.

Increase throughput independently

You changed IOPS without touching throughput. Now you'll change throughput without touching IOPS, proving that both knobs are fully independent on gp3.

• Wait for the IOPS modification to reach the completed state. Check by selecting the volume and looking at the Volume state column.
• Select the gp3-test volume.
• Click Actions, then Modify volume.
• Leave IOPS at 6000.
• Change Throughput from 125 to 250 MB/s.
• Click Modify, then confirm.

• Once the modification completes, select the gp3-test volume and check the Details tab.
• Confirm you see 6,000 IOPS and 250 MB/s throughput on a 10 GiB volume.

How does this compare to gp2?

On gp2, the maximum throughput is 250 MB/s. You need a 334 GiB volume to reach it. gp3 lets you configure the same throughput on a volume as small as 1 GiB.

gp3 is also 20% cheaper per GiB than gp2 ($0.08 vs $0.10). You get more control and pay less.

Still seeing the old throughput value?

• The modification may still be in the optimizing state. Wait a few minutes and refresh the page.
• Make sure you modified the original gp3-test volume, not the volume you converted from gp2. The converted volume is now io2.
• Help me troubleshoot my gp3 volume modification.

Check your instance's EBS bandwidth limits

Your gp3 volume can now deliver 6,000 IOPS and 250 MB/s. But can your t3.micro instance actually use all of that performance? Every EC2 instance type has its own EBS-optimized bandwidth limits that cap how much I/O the instance can push to its volumes.

• In the EC2 console left navigation, click Instance Types.
• In the search bar, type t3.micro.
• Click on t3.micro in the results.
• Scroll down to the EBS optimized section.

You should see these baseline and burst maximum values for the t3.micro:

• Baseline bandwidth: 87 Mbps.
• Baseline IOPS: 500.
• Baseline throughput: 10.88 MB/s.
• Maximum bandwidth: 2,085 Mbps.
• Maximum IOPS: 11,800.
• Maximum throughput: 260.62 MB/s.

Why does the instance matter more than the volume?

EBS performance is the lower of the volume's capability and the instance's EBS bandwidth. Your gp3 volume is provisioned for 6,000 IOPS, but the t3.micro can only sustain 500 IOPS at baseline.

The instance can burst to 11,800 IOPS temporarily. Once burst credits run out, it throttles back to 500 IOPS. At that point, the instance is the bottleneck, not the volume.

Provisioning 80,000 IOPS on a gp3 volume attached to a t3.micro would be wasted money. Always match your volume's provisioned performance to an instance type that can deliver it.

SAA-C03 exam tip

When an exam question mentions a specific instance type, check whether the instance's EBS bandwidth can handle the volume's provisioned IOPS. A volume's performance only matters if the instance can match it.

Your gp3 volume is tuned and you understand how instance bandwidth caps affect real-world performance. Next, you'll set up Multi-Attach with an io2 volume connected to both of your EC2 instances at the same time.

Set Up Multi-Attach with io2

Your gp3 volume now runs at 6,000 IOPS and 250 MB/s on just 10 GiB of storage. You also discovered that the t3.micro instance's baseline bandwidth can bottleneck even the fastest volume.

In this step, you will set up Multi-Attach, a feature that lets you connect a single io2 volume to multiple EC2 instances at the same time. This is used for clustered applications that need shared block storage, and it is a high-frequency topic on the SAA-C03 exam.

In this step, get ready to:

• Create an io2 volume with Multi-Attach enabled.
• Attach the volume to two EC2 instances simultaneously.
• Verify the shared volume is visible from both instances via SSH.

Create an io2 volume with Multi-Attach enabled

Multi-Attach only works with io1 and io2 volumes. You will use io2 because it offers 99.999% durability and supports I/O fencing for data consistency.

• In the EC2 console left navigation, go to Elastic Block Store, then Volumes.
• Click Create volume.
• Select Provisioned IOPS SSD (io2) as the volume type.
• Set Size to 4 GiB.
• Set IOPS to 100.
• Select the same Availability Zone as both of your instances.
• Scroll down to Amazon EBS Multi-Attach and select Enable Multi-Attach.
• Under Tags, click Add tag.
• Enter Name as the key and io2-multiattach as the value.
• Click Create volume.

Your new volume appears with a state of available. Select the volume and check the Details tab to confirm Multi-Attach shows as Enabled.

What is Multi-Attach?

Multi-Attach lets a single EBS volume connect to up to 16 Nitro-based instances in the same Availability Zone. All instances get full read/write access to the shared block storage.

This is designed for clustered applications like Oracle RAC or shared-state workloads. The io2 variant also supports I/O fencing through NVMe reservations, which prevents data corruption when multiple instances write simultaneously.

Don't see the Multi-Attach option?

Make sure you selected Provisioned IOPS SSD (io2) as the volume type. Multi-Attach is only available for io1 and io2 volumes.

Help me troubleshoot the Multi-Attach option not appearing when I create an EBS volume.

Attach the volume to both instances

With Multi-Attach enabled, you can attach this single volume to both of your EC2 instances. Each attachment is done separately through the console.

• Select the io2-multiattach volume.
• Click Actions, then Attach volume.
• Choose EBS-Lab-Instance-A from the Instance dropdown.
• Click Attach volume.

Now attach the same volume to your second instance.

• Select the io2-multiattach volume again.
• Click Actions, then Attach volume.
• Choose EBS-Lab-Instance-B from the Instance dropdown.
• Click Attach volume.

The volume now shows in-use with two attachments. Select the volume and look at the Attachments section in the Details tab. You should see both instance IDs listed.

Multi-Attach constraints for the exam

• Multi-Attach only works with io1 and io2 volumes. It does not work with gp3, gp2, st1, or sc1.
• On Windows EC2 instances, only io2 supports Multi-Attach. io1 does not.
• Up to 16 Nitro-based instances can attach to the same volume.
• All instances must be in the same Availability Zone as the volume.
• Multi-Attach volumes cannot be used as boot volumes.
• io2 Multi-Attach volumes support I/O fencing through NVMe reservations for data consistency. io1 does not support I/O fencing.

Attach volume option greyed out?

Confirm the volume's Availability Zone matches your instances. You cannot attach a volume to an instance in a different AZ.

Also check that the volume state is available or in-use (with Multi-Attach enabled). A volume that is in-use without Multi-Attach cannot be attached to a second instance.

Help me troubleshoot why I can't attach my io2 volume to a second EC2 instance.

Verify the shared volume from both instances

The console confirms two attachments, but let's verify from inside each instance. You will use lsblk to list the block devices each instance can see.

• In your existing SSH session on Instance A, list all block devices by running this command:

lsblk

You should see the io2-multiattach volume listed as an attached device (something like nvme1n1 or nvme2n1) alongside your other attached volumes and the root volume.

Now you need to connect to Instance B to confirm the same volume appears there too.

• Open a new terminal window on your Windows machine. Press the Windows key, type PowerShell, and press Enter.
• Navigate to the folder where your key pair file is saved.
• Connect to Instance B by running this command:

ssh -i [[PEMPATH="path to your .pem key file"]] ec2-user@[[EC2B_PUBLIC_IP="Instance B public IPv4 address"]]

Where do I find Instance B's public IP?

In the EC2 console, go to Instances. Select EBS-Lab-Instance-B and look for the Public IPv4 address field in the Details tab.

You should see the Amazon Linux prompt, confirming you are connected to Instance B.

• List the block devices on Instance B by running this command:

lsblk

You should see the same io2-multiattach volume listed as an attached device. Both instances now have full read/write access to this shared volume.

Do not format or mount this volume from both instances

Standard file systems like ext4 or XFS are not safe for simultaneous writes from multiple instances. Doing so can corrupt your data.

In production, Multi-Attach requires a clustered file system that coordinates writes across instances. For this lab, seeing the attachment on both instances is enough to demonstrate the feature.

Can't connect to Instance B?

Make sure you are using Instance B's public IPv4 address, not Instance A's. Double-check the address in the EC2 console.

If you see a Permission denied error, confirm you are using the same key pair file (.pem) that you selected when launching both instances.

Help me troubleshoot SSH connection issues to my second EC2 instance.

Secret mission

Cost Optimization Calculator

The SAA-C03 exam loves volume cost optimization questions. In this challenge, you will calculate the monthly cost for three real-world storage scenarios, compare volume types, and recommend the cheapest option for each.

Before you go

Clean Up Your Resources

You created EC2 instances and EBS volumes that will continue to charge your account if left running. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Cost warning

The io2 volumes are the most expensive resources in this project due to per-IOPS charges. The two 125 GiB HDD volumes also add to storage costs. If you are not continuing immediately, delete everything to avoid unexpected charges.

The t3.micro instances are free tier eligible for the first 12 months, but the EBS volumes beyond the 30 GB free tier allowance are not.

Resources you used:

• 2 x t3.micro EC2 instances (EBS-Lab-Instance-A and EBS-Lab-Instance-B).
• 1 x gp2-test volume (converted to io2 via Elastic Volumes).
• 1 x gp3-test volume (10 GiB, tuned to 6,000 IOPS and 250 MB/s).
• 1 x io2-test volume (10 GiB).
• 1 x io1-test volume (10 GiB).
• 1 x st1-test volume (125 GiB).
• 1 x sc1-test volume (125 GiB).
• 1 x io2-multiattach volume (4 GiB).

Keep everything running

No action needed. Choose this if you are still actively building or want to continue experimenting with the volumes.

• The t3.micro instances are free tier eligible for the first 12 months of your AWS account.
• The io2 volumes will incur per-IOPS charges as long as they exist. These are the most expensive resources in this lab.
• The st1 and sc1 volumes are the largest at 125 GiB each, but cost relatively little ($0.045/GiB and $0.015/GiB respectively).

Pause - I'll come back to this later

Stop the EC2 instances to eliminate compute charges, but keep your volumes for later. Storage charges will still apply while volumes exist.

• In the EC2 console, go to Instances.
• Select both EBS-Lab-Instance-A and EBS-Lab-Instance-B.
• Click Instance state, then Stop instance.
• Consider deleting the io2 volumes to reduce costs while paused. They have the highest per-IOPS charges.

Delete - I don't want to use this again

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

• In the EC2 console, go to Elastic Block Store, then Volumes.
• Select each attached volume one at a time. Click Actions, then Detach volume. Wait for each to show available before continuing.
• Select all 7 volumes you created (not the root volumes). Click Actions, then Delete volume.
• Go to Instances. Select both EBS-Lab-Instance-A and EBS-Lab-Instance-B.
• Click Instance state, then Terminate instance. This also deletes their root volumes automatically.
• Confirm termination when prompted.

Mission accomplished

Nice Work!

You just completed a comprehensive tour of every EBS volume type. You now have hands-on experience with all six storage options that AWS offers.

You've learned how to:

• Created and compared all 6 EBS volume types (gp3, gp2, io2, io1, st1, sc1), understanding the difference between SSD and HDD categories and when to use each one.
• Live-switched a volume from gp2 to gp3 to io2 using Elastic Volumes and tuned gp3 IOPS and throughput independently from volume size.
• Set up Multi-Attach with an io2 volume connected to two EC2 instances simultaneously, learning the requirements for Nitro instances, same-AZ placement, and I/O fencing.
• Secret Mission: Calculated real-world storage costs across all volume types and identified the cheapest option for database, log processing, and high-availability scenarios.

Ready to quiz yourself?