Mastering EC2 Storage with Amazon EBS

Introduction

30 Second Summary

Think about how your phone stores photos. Some go to internal storage, some to the cloud. The decisions about where data lives, how fast you can access it, and how to back it up are the same decisions cloud architects make every day.

In this project, you will create and manage multiple types of EBS storage volumes on a running EC2 instance, perform live volume modifications, implement cross-region disaster recovery with snapshots, and encrypt volumes using AWS KMS.

What You'll Build

A complete EBS storage lab environment where you exercise every EBS operation tested on the SAA-C03 exam.

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

• A running EC2 instance with attached EBS volumes of different types, demonstrating the performance characteristics of all six volume types.
• A cross-region snapshot copy demonstrating disaster recovery readiness.
• An encrypted volume created via the snapshot-copy method, with account-level default encryption enabled.
• Secret Mission: Tackle a multi-scenario Instance Store vs. EBS architecture challenge with exam-difficulty questions.

Are there any prerequisites?

You should be comfortable launching and terminating EC2 instances via the AWS Console. If you have completed Project 1 (EC2 Fundamentals) or have equivalent experience, you are ready to go.

Before We Start

Before We Start...

Launch Your Lab Instance

Every EBS operation you'll practice in this project requires a running EC2 instance to attach volumes to.

In this step, you'll launch a t3.micro instance and review all six EBS volume types that appear on the SAA-C03 exam. This gives you both the lab environment and the mental framework for the hands-on work ahead.

In this step, get ready to:

• Launch a t3.micro EC2 instance in your default VPC.
• Verify your instance is running and record its Availability Zone.
• Review the six EBS volume types and their exam-relevant characteristics.

Launch a t3.micro EC2 instance

You need a current-generation instance that supports Elastic Volumes and is EBS-optimized by default. The t3.micro fits perfectly and is covered under the free tier for eligible accounts.

• In the AWS Console, use the search bar at the top to search for EC2 and select the EC2 service.
• In the left navigation pane, click Instances.
• Click Launch instances in the top right.

What is an AMI?

An AMI (Amazon Machine Image) is a template that contains the operating system and software configuration for your instance. Think of it as a pre-built hard drive image that your instance boots from.

• Under Name and tags, enter EBS-Storage-Lab in the Name field.
• Under Application and OS Images (Amazon Machine Image), confirm Quick Start is selected and Amazon Linux is chosen.
• Under Amazon Machine Image (AMI), select Amazon Linux 2023 AMI (marked Free tier eligible).
• Under Instance type, select t3.micro from the dropdown.
• Under Key pair (login), select Proceed without a key pair (Not recommended). You will not need SSH access for this project.
• Under Network settings, keep the defaults. The wizard automatically selects your default VPC and a default subnet in one Availability Zone.
• Under Configure storage, keep the default 8 GiB gp3 root volume.
• In the Summary panel on the right, review your configuration.
• Click Launch instance.

Why no key pair?

Key pairs are used for SSH access to the instance. This project focuses entirely on EBS storage operations through the AWS Console, so you won't need to connect to the instance directly.

You should see a success message with a link to your new instance. Click the instance ID link to navigate to the Instances page.

Instance went to terminated instead of running?

This usually means your account has a limit or the selected instance type is unavailable in the chosen AZ. Try launching again in a different Availability Zone, or check your account's EC2 service quotas.

help me troubleshoot why my EC2 instance went to terminated immediately after launch

Verify your instance is running and note key details

Before creating EBS volumes, you need to confirm your instance is ready and record the Availability Zone it landed in. EBS volumes must be in the same AZ as the instance you attach them to.

• On the Instances page, wait for the Instance state column to show Running. You may need to click the refresh icon.
• Click on your EBS-Storage-Lab instance to open its details.
• In the Details tab, find the Availability Zone field (for example, us-east-1a). Write this down or keep it visible.
• Also note the Instance ID (starts with i-) for reference.

Why does the Availability Zone matter?

EBS volumes exist in a single Availability Zone. You can only attach a volume to an instance that lives in the same AZ. If you need storage in a different AZ, you must create a snapshot and restore it there. This is a common exam question.

Understand EBS volume types (exam knowledge)

The SAA-C03 exam tests your ability to choose the right EBS volume type for a given scenario. There are six types split into two categories: SSD-backed (for random I/O) and HDD-backed (for sequential I/O).

Review the specifications below and pay attention to the size ranges, IOPS limits, and use cases. You'll use these to make architectural decisions later.

What are IOPS?

IOPS stands for Input/Output Operations Per Second. It measures how many read or write operations a storage device can perform each second. Higher IOPS means faster performance for workloads that access many small pieces of data (like databases).

SSD-backed volumes (random I/O)

• gp3 (General Purpose SSD): 1 to 65,536 GiB. Baseline 3,000 IOPS and 125 MiB/s included free. Provision up to 80,000 IOPS and 2,000 MiB/s independently of volume size. Ratio: 500 IOPS per GiB. Can be a boot volume. Best for most workloads as the cost-effective default.
• gp2 (Previous-gen General Purpose SSD): 1 to 16,384 GiB. 3 IOPS per GiB (minimum 100, maximum 16,000). Volumes smaller than 1 TiB can burst to 3,000 IOPS via I/O credits. Throughput 128 to 250 MiB/s. Can be a boot volume. Used for legacy workloads still on gp2.
• io2 Block Express (Provisioned IOPS SSD): 4 to 65,536 GiB. Up to 256,000 IOPS on Nitro instances (1,000:1 IOPS-to-GiB ratio). Up to 4,000 MiB/s throughput. 99.999% durability. Sub-millisecond latency. Can be a boot volume. Best for mission-critical databases (Oracle, SAP HANA).
• io1 (Previous-gen Provisioned IOPS SSD): 4 to 16,384 GiB. Up to 64,000 IOPS on Nitro instances (50:1 IOPS-to-GiB ratio). Up to 1,000 MiB/s throughput. 99.8% to 99.9% durability. Can be a boot volume. Used for legacy high-IOPS workloads.

HDD-backed volumes (sequential I/O)

• st1 (Throughput Optimized HDD): 125 to 16,384 GiB. Max 500 MiB/s throughput. Baseline 40 MiB/s per TiB. Cannot be a boot volume. Best for big data, ETL, data warehouses, and log processing.
• sc1 (Cold HDD): 125 to 16,384 GiB. Max 250 MiB/s throughput. Baseline 12 MiB/s per TiB. Cannot be a boot volume. Best for infrequently accessed cold data where lowest cost matters.

Exam traps to watch for

st1 and sc1 cannot be boot volumes. If the exam question mentions a boot volume, the answer must be gp2, gp3, io1, or io2.

gp2 performance is tied to volume size (3 IOPS per GiB). gp3 decouples IOPS from size, making it cheaper and more flexible.

io2 has a 1,000:1 IOPS-to-GiB ratio versus io1's 50:1 ratio. A 100 GiB io2 volume supports up to 100,000 IOPS. A 100 GiB io1 volume supports only 5,000 IOPS.

Why gp3 over gp2 for new workloads?

gp3 is the current default volume type. It includes 3,000 IOPS and 125 MiB/s in the base price regardless of volume size. With gp2, you need a 1,000 GiB volume just to get 3,000 IOPS baseline. gp3 costs roughly 20% less per GiB while delivering equal or better performance.

Your lab instance is running and you have a solid grasp of all six volume types. Next up, you'll create your first standalone EBS volume and attach it to this instance to see the volume lifecycle in action.

Create, Attach, and Explore EBS Volumes

Your instance is running and you know its Availability Zone. Now it is time to give it additional storage by creating a standalone EBS volume and attaching it.

In this step, you will create a gp3 volume, attach it to your running instance, and then practice the detach/re-attach lifecycle. This gives you hands-on experience with the constraint that EBS volumes and instances must share the same Availability Zone.

In this step, get ready to:

• Create a standalone 10 GiB gp3 volume in your instance's Availability Zone.
• Attach and detach the volume to understand the EBS lifecycle.
• Re-attach the volume so it is ready for the next step.

Create a standalone gp3 volume

EBS volumes can be created independently of any instance. Once created, they sit in an "available" state until you attach them.

• In the left sidebar of the EC2 console, click Volumes under Elastic Block Store.
• Click Create volume in the top right corner.
• For Volume type, select General Purpose SSD (gp3).
• Set Size to 10 GiB.
• Leave IOPS at 3000 (the default baseline, included free with gp3).
• Leave Throughput at 125 MiB/s (the default baseline, included free).
• For Availability Zone, select the SAME AZ as your instance (e.g., us-east-1a). This is critical.
• Leave Encryption unchecked. You will encrypt a volume later in the project.
• Scroll down to Tags and click Add tag.
• Enter Name as the Key and Lab-GP3-Volume as the Value.
• Click Create volume.

You should see a green success banner. The volume state changes from "creating" to "available" within a few seconds.

Why does the Availability Zone matter?

EBS volumes are tied to a single Availability Zone. You can only attach a volume to an instance in the same AZ. If you picked a different AZ, the attach operation would fail.

To move data to a different AZ, you create a snapshot and restore it in the target AZ. You will practice this in a later step.

Don't see the volume?

Make sure you are viewing the correct region in the top right of the console. The volume only appears in the region where you created it.

If the volume shows "error" state, check that you selected an AZ that actually exists in your region.

Help me troubleshoot my EBS volume creation issue

Attach the volume to your running instance

A volume in the "available" state is not connected to any instance. Attaching it makes the volume accessible to your EC2 instance as a block device.

• In the Volumes list, select the checkbox next to Lab-GP3-Volume.
• Click Actions, then select Attach volume.
• In the Instance field, select your EBS-Storage-Lab instance.
• For Device name, accept the suggested device (e.g., /dev/sdf or xvdf).
• Click Attach volume.

The volume state should change from "available" to "in-use". This confirms the volume is now connected to your instance.

Attach option greyed out?

Check that the volume state is "available" (not already in-use). Also confirm the volume is in the same Availability Zone as your instance. If the AZs do not match, AWS will not allow the attachment.

Help me figure out why I cannot attach my EBS volume

Detach the volume (non-destructive operation)

Detaching a volume disconnects it from the instance without deleting any data. The volume returns to "available" state and can be re-attached to the same instance or a different one in the same AZ.

• Select the checkbox next to Lab-GP3-Volume.
• Click Actions, then select Detach volume.
• Click Detach to confirm.

The volume state returns to "available". Your data is still on the volume, safe and intact.

What is the exam scenario for moving volumes across AZs?

A common SAA-C03 question asks: "How do you move an EBS volume from one AZ to another?" The answer is to create a snapshot of the volume, then create a new volume from that snapshot in the target AZ. You cannot directly move or attach across AZs.

Now re-attach the volume so it is ready for the next step.

• Select Lab-GP3-Volume again.
• Click Actions, then Attach volume.
• Select your EBS-Storage-Lab instance and click Attach volume.

Confirm the volume state shows "in-use" again. You have successfully completed the full attach/detach/re-attach lifecycle.

Volume stuck in "detaching" state?

If the volume does not return to "available" after a few seconds, make sure no processes on the instance are actively writing to the volume. For this lab, the volume has no filesystem or active writes, so detach should complete instantly. Try refreshing the Volumes page.

Help me troubleshoot my EBS volume detach issue

You now have a gp3 volume attached and ready. Next up, you will modify this volume live on a running instance, changing its size and type without any downtime.

Modify EBS Volumes with Elastic Volumes

In the previous step, you created a standalone EBS volume, attached it to your instance, and proved that detaching preserves data.

Now imagine your application's storage needs change. Maybe you need more space, or your database suddenly needs higher IOPS. In the past, you'd have to stop your instance, create a new volume, migrate data, and swap volumes. Elastic Volumes eliminates that pain by letting you modify size, type, IOPS, and throughput on a running instance with zero downtime.

In this step, get ready to:

• Increase a volume's size from 10 GiB to 20 GiB on a running instance.
• Change the volume type from gp3 to io2 without detaching.
• Master the IOPS/throughput bottleneck concept and the volume selection decision framework for the SAA-C03 exam.

Increase volume size on a running instance

Your Lab-GP3-Volume is currently 10 GiB and attached to your running instance. You are going to double its size to 20 GiB without stopping or detaching anything.

• Return to EC2 > Elastic Block Store > Volumes in the AWS Console.
• Select your Lab-GP3-Volume (currently 10 GiB, in-use).
• Click Actions, then Modify volume.
• Change the Size field from 10 to 20 GiB.
• Leave IOPS and Throughput at their defaults.
• Click Modify, then click Modify again to confirm.

Watch the modification state in the Volume state column. It progresses through: modifying then optimizing then completed. The size increase takes effect once the volume reaches the optimizing state (usually within seconds).

What are Elastic Volumes rules?

Elastic Volumes let you modify size, type, IOPS, and throughput without stopping the instance or detaching the volume (on current-generation instances like your t3.micro).

Key constraints to remember for the exam:

• You CANNOT decrease volume size. To shrink, you must create a smaller volume and migrate data.
• Maximum 4 modifications per volume in a rolling 24-hour period.
• Each modification must reach "completed" before starting another.
• Performance changes (IOPS/throughput) can take minutes to hours to fully apply.

Modify option greyed out?

Make sure you have selected the volume checkbox before clicking Actions. If the modify option is still unavailable, the volume may have a pending modification that has not reached "completed" yet. Wait a few minutes and refresh the page.

Help me troubleshoot why I can't modify my EBS volume

Change volume type from gp3 to io2

Now that your volume is 20 GiB, you will change its type from gp3 to io2. This simulates a real-world scenario where a workload's IOPS requirements increase beyond what gp3 can guarantee.

• Wait for the previous modification to reach the completed state before proceeding.
• Select Lab-GP3-Volume again.
• Click Actions, then Modify volume.
• Change the Volume Type from gp3 to io2.
• Set IOPS to 3000.
• Confirm the size remains at 20 GiB.
• Click Modify, then confirm.
• Observe the modification progress in the volume list. Once it reaches completed, your volume is now an io2 volume.

What is io2 Block Express?

As of April 30, 2025, all new and previously created io2 volumes are io2 Block Express volumes. You do not need to select Block Express separately. It provides up to 256,000 IOPS, 4,000 MiB/s throughput, and 99.999% durability.

Why does gp3 to io2 matter for the exam?

When you change from gp2 to gp3 without specifying IOPS/throughput, AWS provisions performance to match or exceed the source volume. The default for a new gp3 is 3,000 IOPS and 125 MiB/s. If the source gp2 volume had higher baseline IOPS due to its size, gp3 will match it.

The io2 volume type has a 1,000:1 IOPS-to-GiB ratio, compared to io1's 50:1. A 100 GiB io2 volume supports 100,000 IOPS, while a 100 GiB io1 volume supports only 5,000 IOPS. This is a frequent exam comparison.

Modification not starting?

If the type change won't start, your previous size modification may not have fully completed yet. Navigate to Volumes, select your volume, and check the Modifications history tab. Each modification must reach "completed" before you can start another.

Help me figure out why my EBS volume modification is stuck

Understand IOPS and throughput performance (exam deep-dive)

Provisioning high IOPS on a volume does not guarantee you will actually achieve that performance. The actual performance your application experiences is determined by a bottleneck relationship between the volume and the instance.

What is the performance bottleneck concept?

Actual performance is the MINIMUM of two values:

• The volume's provisioned performance (IOPS/throughput).
• The instance type's EBS performance limit.

For example, if you provision 80,000 IOPS on a gp3 volume but attach it to a t3.micro (which supports far fewer IOPS), the instance becomes the bottleneck. For full performance, you need an EBS-optimized instance with sufficient dedicated EBS bandwidth.

What are EBS-optimized instances?

EBS-optimized instances provide dedicated bandwidth between EC2 and EBS, minimizing contention with other network traffic. Current-generation instance types (T3, M5, C5, R5, and newer) are EBS-optimized by default.

Performance guarantees differ by volume type. io1/io2 volumes deliver at least 90% of provisioned IOPS 99.9% of the time. gp2/gp3 volumes deliver at least 90% of provisioned IOPS 99% of the time.

For the SAA-C03 exam, you need a decision framework that maps workload characteristics to the correct volume type. Review the following table and commit it to memory.

Volume selection decision framework

• Need predictable, independently adjustable IOPS? Choose gp3.
• Need more than 80,000 IOPS? Choose io2.
• Need sub-millisecond latency for a critical database (Oracle, SAP HANA)? Choose io2 Block Express.
• Need high throughput for big data/ETL with sequential reads? Choose st1.
• Need cheapest storage for cold, infrequently accessed data? Choose sc1.
• Migrating from gp2 and want lower cost with same or better performance? Choose gp3.

Exam scenario to remember

If an exam question describes an application provisioned at high IOPS but only achieving a fraction of that, the answer is almost always an instance bottleneck. The fix is to upgrade to a larger instance type with higher EBS bandwidth.

You have successfully modified a volume's size and type on a running instance. You now understand the Elastic Volumes rules, the bottleneck concept, and the volume selection decision framework. Next up, you will create snapshots and implement cross-region disaster recovery.

Create Snapshots and Implement Cross-Region DR

You have a modified volume running on a live instance. But what happens if that volume fails, or an entire AWS region goes offline?

In this step, you will create EBS snapshots to back up your volume data, restore a volume from a snapshot, and copy a snapshot to a completely different AWS region. This cross-region copy is the foundation of disaster recovery on AWS.

In this step, get ready to:

• Create an EBS snapshot from your attached volume.
• Restore a new volume from that snapshot.
• Copy the snapshot to another region for disaster recovery.

Create a snapshot of your volume

A snapshot captures all the data written to your volume at a point in time. Think of it as a save point you can always restore from.

• In the EC2 console, select Elastic Block Store in the left sidebar.
• Select Volumes.
• Select your Lab-GP3-Volume (the 20 GiB io2 volume).
• Click Actions, then Create snapshot.
• In the Description field, enter Lab-Snapshot-DR-Test.
• Click Add tag.
• Set Key to Name and Value to Lab-DR-Snapshot.
• Click Create snapshot.

• Navigate to Elastic Block Store > Snapshots in the left sidebar to monitor progress.
• Wait for the Status column to show completed. This may take a minute for a 20 GiB volume.

How do EBS snapshots work?

The first snapshot of a volume is a full copy of all written data blocks. Every snapshot after that is incremental, meaning it only captures blocks that changed since the last snapshot.

Snapshots are stored in Amazon S3 (managed by AWS, not visible in your S3 console). Each snapshot contains all the information needed to restore the full volume, even though only changed blocks are stored incrementally.

Why does incremental matter for the exam?

• You are billed for the amount of data stored in snapshots, not the full volume size.
• Deleting a snapshot removes only data blocks not referenced by other snapshots.
• Snapshot data is automatically replicated across all Availability Zones in the region.

Restore a volume from the snapshot

Now that you have a completed snapshot, you can use it to create a brand new volume. This is how you recover data or move volumes between Availability Zones.

• In the Snapshots view, select your Lab-DR-Snapshot.
• Click Actions, then Create volume from snapshot.
• Set Volume type to gp3.
• Set Size to 20 GiB (must be equal to or larger than the snapshot source).
• Set Availability Zone to your instance's AZ (the same one you noted earlier, e.g., us-east-1a).
• Click Create volume.
• Navigate back to Volumes and verify the new volume appears with state available.

Why can I restore to any AZ?

You can restore a snapshot to any Availability Zone in the same region. This is how you move data between AZs. Remember, you cannot directly attach a volume to an instance in a different AZ. The workflow is: snapshot the volume, then create a new volume from that snapshot in the target AZ.

Don't see the new volume?

Make sure your snapshot status shows completed before attempting to create a volume from it. Also confirm you are viewing volumes in the correct region (check the region dropdown in the top-right corner of the console).

Having trouble restoring from a snapshot?

Copy the snapshot to another region for disaster recovery

Your snapshot currently exists in one region. If that entire region went down, your backup would be lost too. Copying the snapshot to a different region gives you true disaster recovery.

• In the Snapshots view, select your Lab-DR-Snapshot.
• Click Actions, then Copy snapshot.
• In the Destination Region dropdown, choose a different region from your primary (e.g., us-west-2 if your primary is us-east-1).
• In the Description field, enter DR-Copy-Cross-Region.
• Check the Encrypt this snapshot checkbox.
• For KMS Key, select the default aws/ebs key in the destination region.
• Click Copy snapshot.

• Switch to your destination region using the region dropdown in the top-right corner of the console.
• Navigate to EC2 > Snapshots in the destination region.
• Verify you can see the snapshot copy with description DR-Copy-Cross-Region. Wait for its status to reach completed.
• Switch back to your primary region when done.

What is cross-region snapshot behavior?

The first copy to a new region is always a full (non-incremental) copy. Subsequent copies can be incremental if: the same KMS key is used, the previous copy still exists in the destination, and it has not been archived.

AWS allows up to 20 concurrent snapshot copy requests per destination region. Copying incurs data transfer charges between regions.

How would this work as a DR strategy?

In production, you would automate regular cross-region snapshot copies using Amazon Data Lifecycle Manager or AWS Backup. If your primary region fails, you restore volumes from snapshots in the DR region and launch new instances there.

Exam scenario to remember

If the exam asks: "How can a company ensure EBS data survives a regional outage?" the answer involves automating cross-region snapshot copies and restoring volumes in the DR region.

Snapshot copy stuck in pending?

Cross-region copies take longer than in-region snapshots because data must physically transfer between regions. A 20 GiB snapshot typically completes within a few minutes, but network conditions vary. Confirm you switched to the correct destination region in the console to check status.

Help me troubleshoot my cross-region snapshot copy.

You now have a complete disaster recovery workflow in place. Your data exists in two separate AWS regions. Next up, you will tackle EBS encryption to secure your volumes and learn the critical snapshot-copy encryption method tested on the SAA-C03.

Encrypt EBS Volumes

Your disaster recovery strategy is in place with cross-region snapshots. Now it's time to address the other side of data protection: encryption.

In this step, you will encrypt EBS volumes using AWS KMS keys. You will also learn the critical exam workflow for encrypting an existing unencrypted volume, since you cannot toggle encryption on a volume directly.

In this step, get ready to:

• Create a new encrypted EBS volume using the default KMS key.
• Encrypt an existing unencrypted volume using the snapshot-copy method.
• Enable account-level default EBS encryption for your region.

Create a new encrypted volume

The simplest way to get an encrypted volume is to enable encryption at creation time. AWS handles all the cryptographic operations transparently on the EC2 host server.

• In the left sidebar of the EC2 console, click Volumes under Elastic Block Store.
• Click Create volume.
• Set Volume type to gp3.
• Set Size to 5 GiB.
• Set Availability Zone to the same AZ as your instance (e.g., us-east-1a).
• Check the Encrypt this volume checkbox.
• For KMS Key, select the default aws/ebs key.
• Add a tag with Key = Name and Value = Lab-Encrypted-Volume.
• Click Create volume.

The volume state will change to available within seconds. You will see a lock icon or "Encrypted" indicator in the volume details.

How does EBS encryption work?

EBS encryption uses AWS KMS symmetric keys. The encryption happens on the EC2 host server, making it completely transparent to your applications.

It encrypts data at rest on the volume, data in transit between the instance and the volume, all snapshots created from the volume, and any volumes restored from those encrypted snapshots. There is no performance impact.

You can attach both encrypted and unencrypted volumes to the same instance simultaneously.

Encrypt an existing unencrypted volume using the snapshot-copy method

This is a critical exam topic. You cannot directly encrypt an existing unencrypted volume. Instead, you use a multi-step workflow involving snapshots.

Why can't you just encrypt an existing volume?

EBS encryption is set at volume creation time and cannot be changed afterward. The only way to get an encrypted copy of existing data is to snapshot the volume, copy the snapshot with encryption enabled, and then create a new volume from the encrypted snapshot.

You will encrypt your Lab-GP3-Volume (currently unencrypted and attached to your instance) using this method. The process has four stages: snapshot, copy with encryption, create volume, and verify.

First, create an unencrypted snapshot of the source volume:

• In the Volumes list, select your Lab-GP3-Volume (the io2 volume, 20 GiB).
• Click Actions, then Create snapshot.
• Enter a description such as Unencrypted-Snapshot-for-Encryption.
• Click Create snapshot.
• Navigate to Snapshots in the left sidebar under Elastic Block Store.
• Wait for the snapshot status to show completed.

Next, copy that snapshot with encryption enabled:

• Select the snapshot you just created.
• Click Actions, then Copy snapshot.
• Set Destination Region to the same region you are currently in (this copies within the same region but adds encryption).
• Check the Encrypt this snapshot checkbox.
• For KMS Key, select aws/ebs (the default AWS managed key).
• Click Copy snapshot.
• Wait for the new encrypted snapshot copy to reach completed status.

Finally, create a new encrypted volume from the encrypted snapshot:

• Select the encrypted snapshot copy.
• Click Actions, then Create volume from snapshot.
• Set Volume type to gp3.
• Set Availability Zone to the same AZ as your instance.
• Click Create volume.
• Verify the new volume shows as encrypted with available state.

What is the full encryption workflow for the exam?

The exam frequently asks: "How do you encrypt an existing unencrypted EBS volume?" The answer is always: Snapshot the volume, copy the snapshot with encryption enabled, then create a new volume from the encrypted snapshot.

You cannot toggle encryption on an existing volume. You also cannot remove encryption from an encrypted volume or snapshot.

Sharing encrypted snapshots

Encrypted snapshots cannot be shared publicly. You can only share them with specific AWS accounts, and those accounts must have access to the KMS key used for encryption.

Enable default EBS encryption for your region

Instead of manually checking the encryption box each time, you can enable encryption by default for your entire region. Every new volume and snapshot copy will be automatically encrypted.

• In the left sidebar of the EC2 console, scroll down and click Settings.
• Click the Data protection and security tab.
• In the EBS encryption section, click Manage.
• Select Enable.
• For the KMS Key, keep the default AWS managed key (aws/ebs).
• Click Update EBS encryption.

You should see a confirmation that EBS encryption by default is now enabled for this region.

What does default encryption affect?

• All new EBS volumes and snapshot copies in this region are automatically encrypted.
• Existing volumes and snapshots are not affected.
• This is a region-specific setting. You must enable it separately in each region.
• Once enabled, you cannot disable encryption for individual volumes in that region.

Exam knowledge: encryption and KMS keys

Copying a snapshot with a different KMS key creates a full (non-incremental) copy with additional storage costs. This matters for cross-account sharing, where the receiving account uses its own KMS key.

Remember: encrypted snapshots cannot be shared publicly. You can only share them with specific accounts that have access to the KMS key.

Don't see the EBS encryption settings?

Make sure you clicked Settings at the bottom of the EC2 left sidebar (not the general AWS settings). Then look for the Data protection and security tab.

If you do not see the Manage button, your IAM user may lack permissions for ec2:EnableEbsEncryptionByDefault. Help me troubleshoot EBS encryption permissions in my AWS account.

Secret mission

Instance Store vs. EBS Architecture Challenge

Ready for an exam-level challenge? Apply your EBS knowledge to five real-world architecture scenarios where you must choose between instance store and EBS volume types under constraints that mirror the SAA-C03 exam.

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 created a small EC2 instance and several EBS volumes and snapshots that incur ongoing charges while they exist.

Cost warning

Your t3.micro instance costs approximately $0.01/hour while running. EBS volumes cost pennies per day based on size and type. Snapshots are billed for the data stored. The cross-region snapshot copy also incurred a small data transfer charge.

If you are not planning to continue experimenting, deleting all resources is recommended to avoid any charges.

Resources you used:

• 1 EC2 instance (EBS-Storage-Lab, t3.micro).
• Multiple EBS volumes (Lab-GP3-Volume, Lab-Encrypted-Volume, Restored-from-Snapshot, Encrypted-Volume-from-Snapshot, plus the root volume).
• EBS snapshots in your primary region (Lab-DR-Snapshot, Unencrypted-Snapshot-for-Encryption, Encrypted-Snapshot-Copy).
• Cross-region snapshot copy (DR-Copy-Cross-Region) in your DR region.
• Account-level default EBS encryption setting (enabled in your primary region).

Keep everything running

No action needed. Choose this if you are still actively experimenting with EBS volumes, snapshots, or encryption. Monitor your costs in the AWS Billing dashboard.

• Your EC2 instance will continue to incur compute charges while running.
• EBS volumes incur storage charges regardless of whether they are attached.
• Snapshots incur charges based on the amount of data stored.

Pause - I'll come back to this later

Shut down your instance to stop compute charges while keeping your volumes and snapshots intact for later.

• Navigate to EC2 > Instances.
• Select your EBS-Storage-Lab instance.
• Click Instance state > Stop instance.
• Confirm the stop action.

What still costs money when paused?

Stopping the instance eliminates compute charges. However, all EBS volumes (including the root volume) and snapshots continue to incur storage charges. The cross-region snapshot copy in your DR region also continues to incur charges.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow these steps in order.

• Navigate to EC2 > Instances.
• Select your EBS-Storage-Lab instance.
• Click Instance state > Terminate instance.
• Confirm the termination. This deletes the root volume automatically (since Delete on termination is enabled by default).

Next, delete all remaining EBS volumes.

• Navigate to EC2 > Elastic Block Store > Volumes.
• Select all lab volumes (Lab-GP3-Volume, Lab-Encrypted-Volume, Restored-from-Snapshot, Encrypted-Volume-from-Snapshot).
• If any volume shows in-use state, select it and click Actions > Detach volume first. Wait for the state to change to available.
• Select all lab volumes, then click Actions > Delete volume.
• Confirm the deletion.

Next, delete all snapshots in your primary region.

• Navigate to EC2 > Elastic Block Store > Snapshots.
• Select all lab snapshots (Lab-DR-Snapshot, Unencrypted-Snapshot-for-Encryption, Encrypted-Snapshot-Copy).
• Click Actions > Delete snapshot.
• Confirm the deletion.

Now switch to your DR region and delete the cross-region snapshot copy.

• Click the region selector in the top-right corner of the AWS Console.
• Switch to your DR region (e.g., us-west-2 if your primary was us-east-1).
• Navigate to EC2 > Elastic Block Store > Snapshots.
• Select the DR-Copy-Cross-Region snapshot.
• Click Actions > Delete snapshot.
• Confirm the deletion.

Finally, revert the default EBS encryption setting if you want to.

• Switch back to your primary region.
• Navigate to EC2 > Settings (in the left sidebar) > Data protection and security tab.
• In the EBS encryption section, choose Manage.
• Select Disable, then choose Update EBS encryption.

What does disabling default encryption do?

Disabling this setting only affects future volumes. Volumes and snapshots that are already encrypted stay encrypted permanently. You cannot remove encryption from an existing volume or snapshot.

Nice Work!

Nice Work!

Nice work! You just built a complete EBS storage lab covering every operation tested on the SAA-C03 exam.

You've learned how to:

• Create, attach, and modify EBS volumes on a running instance using Elastic Volumes, changing size and volume type without downtime.
• Implement a cross-region disaster recovery workflow by creating incremental snapshots and copying them to a secondary region.
• Encrypt existing unencrypted volumes using the snapshot-copy encryption method and enable account-level default EBS encryption with AWS KMS.
• Master the Instance Store vs. EBS decision framework through exam-level architecture scenarios, including the IOPS/throughput bottleneck concept between volume performance and instance EBS bandwidth.

Ready to quiz yourself?