Encrypt and Snapshot EBS Data

Create EBS snapshots, encrypt volumes with KMS, and automate backups with DLM.

Introduction

30 Second Summary

Imagine your laptop's hard drive fails tomorrow. If you have a backup, you restore your files and move on. If you do not, everything is gone. The same risk applies to data stored in the cloud.

In this project, you will build a complete data protection system for Amazon EBS volumes. You will create snapshots to back up your data, encrypt volumes using AWS KMS, copy snapshots across regions for disaster recovery, and automate the entire backup lifecycle.

What You'll Build

You will build a complete EBS data protection workflow that covers snapshots, encryption, cross-region disaster recovery, and automated lifecycle management.

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

A snapshot restored to a new volume with verified data integrity, proving you can recover from data loss.
An encrypted volume created from an originally unencrypted volume using the snapshot-copy encryption workflow, which is one of the most commonly tested scenarios on the SAA-C03 exam.
A Data Lifecycle Manager policy that automatically creates and retains daily snapshots with retention rules.
Secret Mission: archive a snapshot to the EBS Snapshots Archive tier and calculate the cost savings compared to standard snapshot storage.

Are there any prerequisites?

You need an AWS account with admin access and basic familiarity with EC2 (launching instances). No prior experience with snapshots or encryption is required.

Launch an EC2 Instance and Prepare Test Data

Before you can protect data with snapshots and encryption, you need something to protect. In this step, you will launch a virtual server in AWS and attach a storage volume to it with some test data inside.

Think of an EC2 instance as a computer in the cloud, and an EBS volume as an external hard drive you plug into it. Once your test data is on that hard drive, you will have real data to snapshot, encrypt, and recover throughout the rest of this project.

In this step, get ready to:

Launch a free-tier EC2 instance in a specific Availability Zone.
Create, attach, and format an unencrypted data volume with test data.
Verify the volume is ready and unmount it cleanly for snapshotting.

Launch a free-tier EC2 instance

You need a running EC2 instance so you have a computer in the cloud to attach storage volumes to. You will launch it in a specific Availability Zone because EBS volumes are locked to a single zone.

In the AWS Management Console, check the region selector in the top-right corner of the navigation bar.
Make sure it says US East (N. Virginia) us-east-1.
If it shows a different region, click the dropdown and select US East (N. Virginia) us-east-1.

Type EC2 in the search bar at the top and select EC2 from the results.
Click Launch instances on the EC2 Dashboard.

The launch instance wizard opens with fields for naming, selecting an operating system, choosing an instance size, and more.

Under Name and tags, enter EBS-Snapshots-Lab in the Name field.
Under Application and OS Images (Amazon Machine Image), confirm Amazon Linux 2023 AMI is selected. It should be the default and is marked Free tier eligible.
Under Instance type, confirm t2.micro is selected. It is free-tier eligible.
Under Key pair (login), open the dropdown and select Proceed without a key pair (Not recommended).

Why no key pair?

You will connect to this instance using EC2 Instance Connect, a browser-based terminal built into the AWS Console. EC2 Instance Connect pushes a temporary SSH key to your instance automatically, so you do not need to create or download a key pair file.

Now you need to configure the network settings to place your instance in a specific Availability Zone.

Under Network settings, click Edit.
Leave the VPC as the default.
In the Subnet dropdown, select a subnet that shows us-east-1a in its name.
Confirm Auto-assign public IP is set to Enable. You need a public IP for EC2 Instance Connect.
Under Firewall (security groups), keep Create security group selected.
Keep the Allow SSH traffic from checkbox checked.

Under Configure storage, confirm the default root volume is 8 GiB gp3. Leave it as is.
Click Launch instance in the Summary panel on the right.

You should see a Success banner confirming the launch.

Click the instance ID link in the success banner to go to the Instances page.
Wait until the Instance state column shows Running and the Status check column shows 2/2 checks passed. This can take 1-2 minutes. Click the refresh icon if needed.

Why does the Availability Zone matter?

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

Think of it like this: your volume lives in one building, and you cannot stretch a cable to a different building. To move data between Availability Zones, you must use a snapshot. You will do exactly that later in this project.

Instance not reaching Running state?

Check that you selected us-east-1 as your region before launching. If you launched in a different region, terminate the instance and relaunch in us-east-1.

If the status checks are still initializing, give it another minute. Refresh the page by clicking the circular arrow icon above the instance list.

Help me troubleshoot my EC2 instance launch.

Create and attach an unencrypted data volume

Your instance has a root volume where the operating system lives, but you need a separate data volume to practice snapshots and encryption on. You will intentionally create this volume without encryption so you can learn the snapshot-copy encryption workflow later.

In the EC2 Console left sidebar, click Elastic Block Store to expand it, then click Volumes.
Click Create volume.

Set Volume type to General Purpose SSD (gp3).
Set Size to 8 GiB.
Set Availability Zone to us-east-1a. This must match your EC2 instance.
Make sure the Encrypt this volume checkbox is unchecked. You are creating an unencrypted volume on purpose.
Click Create volume.

You should see a success banner. The new volume appears in the list with a state of Available.

Now attach this volume to your instance.

Select the checkbox next to your new volume (the one that is Available and not In-use).
Click Actions, then Attach volume.
In the Instance field, start typing EBS-Snapshots-Lab and select your instance from the dropdown.
Leave the Device name as the suggested default (e.g., /dev/sdf).
Click Attach volume.

The volume state changes to In-use. Now you need to connect to your instance to format and mount the volume.

In the left sidebar, click Instances.
Select the checkbox next to your EBS-Snapshots-Lab instance.
Click Connect at the top of the page.
On the Connect to instance page, select the EC2 Instance Connect tab.
Keep the default username (ec2-user).
Click Connect.

A browser-based terminal window opens. You are now logged into your EC2 instance.

EC2 Instance Connect not working?

If the connection fails, make sure your instance has a public IP address. Check the Details tab of your instance for a Public IPv4 address. If the field is empty, the instance was launched without a public IP.

Also verify that the security group allows inbound SSH (port 22). The launch wizard creates this rule by default.

Help me connect to my EC2 instance using Instance Connect.

First, identify which device name Linux assigned to your new volume.

List all attached block devices by running this command:

lsblk

You should see two disks that are each 8 GiB. The one with partitions and a mountpoint of / is your root volume. The other 8 GiB disk with no mountpoint is your new data volume.

What device name should I look for?

If you launched a t2.micro instance, the data volume typically appears as xvdf. If you launched a t3.micro instance, it appears as nvme1n1.

In the commands below, replace /dev/xvdf with your actual device name if it differs.

The volume is attached but empty. Before you can store files on it, you need to format it with a file system. Think of formatting like putting shelves in an empty closet so you can organize things.

Format the volume with the ext4 file system by running this command:

sudo mkfs -t ext4 /dev/xvdf

What does this command do?

The mkfs command creates a file system on the device. The -t ext4 flag tells it to use the ext4 file system, which is the standard for Linux.

Seeing a "No such file or directory" error?

The device name depends on your instance type. Run lsblk again and look for the 8 GiB disk without a mountpoint. Use that device name instead of /dev/xvdf.

Help me find my EBS device name.

Now mount the volume so you can access it like a folder. Mounting is like opening the closet door so you can put things inside.

Create a mount point and mount the volume by running these commands:

sudo mkdir /data
sudo mount /dev/xvdf /data

What does this do?

The first command creates a folder called /data on your instance. The second command connects your EBS volume to that folder, so anything you put in /data is actually stored on the volume.

Write a test file to the volume by running this command:

echo "Hello from EBS Snapshots!" | sudo tee /data/testfile.txt

You should see Hello from EBS Snapshots! printed in the terminal. This confirms the file was written successfully.

Verify the volume is ready

Before creating a snapshot, you should verify your data is on the volume and then unmount it cleanly. AWS recommends stopping writes to a volume before snapshotting to get a consistent copy of your data.

Confirm your test file exists by running this command:

cat /data/testfile.txt

You should see Hello from EBS Snapshots! printed in the terminal.

Verify the volume is mounted and check its size by running:

df -h /data

You should see output showing the volume mounted at /data with approximately 7.8 GiB of space (some space is used by the file system itself).

Why unmount before snapshotting?

Think of it like asking everyone to hold still before you take a group photo. Unmounting ensures no data is being written mid-snapshot, which gives you a consistent, reliable backup.

Unmount the volume cleanly by running this command:

sudo umount /data

Verify the unmount worked by running:

df -h /data

This time the output should NOT show your EBS device. Instead it shows the root filesystem for /data, which means the volume is no longer mounted there.

Seeing "target is busy" when unmounting?

This means a process is still using the /data directory. Make sure your current working directory is not inside /data. Run cd ~ to go back to your home directory, then try the unmount command again.

Help me unmount my EBS volume.

Your data volume has test data on it and is cleanly unmounted. Next up, you will create your first EBS snapshot and prove you can recover data even after deleting the original volume.

Create and Restore EBS Snapshots

Your EC2 instance is running and your data volume has a test file sitting on it. Now it is time to protect that data with EBS Snapshots.

In this step, you will create snapshots, deliberately delete your volume to simulate data loss, and then restore everything from a snapshot. This proves that snapshots are a reliable safety net for your data.

In this step, get ready to:

Create your first EBS snapshot.
Simulate data loss and restore data from a snapshot.
Understand how incremental snapshots save storage costs.

Create your first snapshot

Your data volume is currently unmounted, which means nothing is writing to it. This is the best time to take a snapshot because you get a perfectly consistent copy of your data.

In the AWS Management Console, confirm you are in the us-east-1 (N. Virginia) region by checking the region selector in the top right corner.
In the left sidebar, scroll down to Elastic Block Store and click Snapshots.
Click Create snapshot.
For Resource type, select Volume.
In the Volume ID dropdown, select your 8 GiB data volume.

Picking the right volume

You will see two volumes in the dropdown. One is the root volume (the operating system drive attached to your instance). The other is the 8 GiB data volume you created in Step 1. Make sure you select the data volume, not the root volume.

Scroll down to the Tags section and click Add tag.
Enter Name as the Key and my-first-snapshot as the Value.
Click Create snapshot.

What just happened?

AWS is copying all the data from your volume to Amazon S3 in the background. The snapshot starts immediately but may take a few minutes to finish.

Snapshots are stored in Amazon S3 with 99.999999999% (11 nines) durability. Even if your EBS volume fails completely, you can always restore from a snapshot.

Why is the first snapshot a full copy?

The first snapshot of a volume always copies ALL data blocks on the volume. If your volume has 2 GB of actual data on an 8 GiB volume, the snapshot stores those 2 GB. You pay $0.05 per GB per month for standard snapshot storage.

Your snapshot should appear in the list with the status pending.
Wait a minute or two, then click the refresh icon at the top of the snapshots table.
Confirm the status changes to completed before moving on.

Snapshot stuck on pending?

Snapshots can take a few minutes to complete, especially the first one. Keep refreshing. If it stays on pending for more than 10 minutes, make sure you selected the correct volume and that it exists in us-east-1a.

Why is my EBS snapshot stuck on pending for a long time?

Simulate data loss and restore from your snapshot

You have one snapshot safely stored. Before simulating data loss, you will add a second test file and take another snapshot.

Then you will delete the original volume entirely and prove that snapshots can bring your data back from nothing.

In the left sidebar, click Instances.
Select your instance and click Connect.
On the EC2 Instance Connect tab, click Connect.

A browser-based terminal opens. You need to remount your data volume, add a second test file, and then unmount it again before taking the next snapshot.

First, identify your data volume's device name by running:

lsblk

How do I find my data volume?

You will see a list of block devices. Look for the 8 GiB device that is NOT your root volume. It is the same device you mounted in Step 1. Common names are xvdf (on t2 instances) or nvme1n1 (on t3 instances).

Remount your data volume, add a second test file, and verify both files exist by running these commands:

# Remount the data volume (replace /dev/xvdf with your device name if different)
sudo mount /dev/xvdf /data

# Create a second test file
echo "Snapshot restore works!" | sudo tee /data/second-test-file.txt

# Verify both files exist
ls /data

What does this do?

The mount command reconnects the volume to the /data directory so you can read and write to it. The tee command writes your text into a new file.

You should see both your original test file from Step 1 and the new second-test-file.txt in the output.

Not seeing the original test file?

If /data is empty or only shows the new file, you may have mounted the wrong device. Run lsblk to double-check which device is your 8 GiB data volume.

My /data directory is empty after mounting my EBS volume. Help me figure out why.

Unmount the volume cleanly before taking the next snapshot by running:

sudo umount /data

Now head back to the console to create a second snapshot.

In the left sidebar, go to Elastic Block Store and click Snapshots.
Click Create snapshot.
Select Volume as the resource type and choose the same 8 GiB data volume.
In the Tags section, add a tag with Name as the key and my-second-snapshot as the value.
Click Create snapshot.
Wait for the status to change to completed before continuing.

Now for the dramatic part. You are going to delete the original data volume entirely. Your data will be gone from the volume, but your snapshots still exist safely in Amazon S3.

In the left sidebar, click Volumes under Elastic Block Store.
Select your 8 GiB data volume (not the root volume).
Click Actions, then Detach volume.
Confirm the detach when prompted.
Wait for the volume state to change to available. You may need to refresh the page.
With the volume still selected, click Actions, then Delete volume.
Confirm the deletion.

Where did your data go?

The volume and all the data on it are permanently gone. If you did not have snapshots, that data would be lost forever. Your two snapshots still exist safely in Amazon S3, ready to bring everything back.

Time to prove that snapshots work. You will create a brand new volume from your second snapshot and verify both test files are still there.

In the left sidebar, click Snapshots under Elastic Block Store.
Select the snapshot named my-second-snapshot.
Click Actions, then Create volume from snapshot.
For Availability Zone, select us-east-1a. This must match the AZ of your EC2 instance.
Leave all other settings as defaults and click Create volume.

Why does the Availability Zone matter?

EBS volumes are locked to a single Availability Zone. You cannot attach a volume in us-east-1a to an instance in us-east-1b. To move data between AZs, you must use a snapshot.

Think of it like this: your volume lives in one building, and you cannot stretch a cable to a different building. But you can take a photo (snapshot) of the data and recreate it in the other building.

In the left sidebar, click Volumes.
Wait for the new volume's state to change to available.
Select the new volume.
Click Actions, then Attach volume.
In the Instance field, select your EC2 instance.
For Device name, enter /dev/sdf.
Click Attach volume.

Your restored volume is now attached. Head back to your EC2 Instance Connect session to mount it and verify the data.

Session expired?

If your EC2 Instance Connect session timed out, go to Instances in the left sidebar, select your instance, and click Connect again to start a new session.

Mount the restored volume and verify your data is intact by running these commands:

# Mount the restored volume (use the same device name from Step 1)
sudo mount /dev/xvdf /data

# List files to verify both test files are present
ls /data

# Display the contents of all files
cat /data/*

What does this prove?

You deleted the original volume, created a brand new volume from a snapshot, and your data is still there. Both test files survived the complete destruction of the original volume.

This is the core value of EBS Snapshots. Your data is backed up in Amazon S3 with 11 nines of durability, completely independent of the volume itself.

You should see both your original test file and second-test-file.txt in the output. The cat command should show the text from both files.

Not seeing both test files?

Make sure you created the volume from my-second-snapshot (not my-first-snapshot). The first snapshot only contains the original test file. The second snapshot contains both.

If the /data directory is empty, you may have mounted the wrong device. Run lsblk to check which 8 GiB device is the restored volume.

I restored an EBS volume from a snapshot but my data is missing. Help me troubleshoot.

Understand incremental snapshots

You now have two snapshots in your account. They look similar in the console, but behind the scenes they work very differently.

In the left sidebar, click Snapshots under Elastic Block Store.
Look at both my-first-snapshot and my-second-snapshot in the list.

Both snapshots show the same volume size, but the second snapshot only stored the blocks that changed since the first snapshot. This is called an incremental snapshot.

How do incremental snapshots work?

The first snapshot is always a full copy of all data blocks on the volume. Every snapshot after that only stores the blocks that changed since the previous snapshot.

Here is the part that confuses many people: even though the second snapshot only stores the changes, you can delete the first snapshot and the second snapshot still works perfectly for a full restore. AWS automatically manages which data blocks are needed.

Think of it like a photo album where each photo only shows what changed. AWS can reconstruct the full picture from any single snapshot.

Why this saves you money

Imagine you take daily snapshots of a 100 GB volume where only 1 GB changes per day. You pay for 100 GB (the first snapshot) plus 1 GB plus 1 GB plus 1 GB for each day after that. Without incremental snapshots, you would pay for 100 GB every single day.

For the SAA exam, remember that you pay $0.05 per GB per month for standard snapshot storage. Incremental behavior keeps that cost under control even when you snapshot frequently.

Your snapshots are safely protecting your data, and you have proven you can restore from them. Next, you will secure that data even further by encrypting your volumes with AWS KMS.

Encrypt EBS Data with AWS KMS

In the last step, you proved that snapshots can recover your data even after deleting the original volume. Your backups are solid.

There is one problem though. Your volumes and snapshots are completely unencrypted, which means anyone who gains access to the underlying storage could read your data. In this step, you will lock down your EBS data using AWS KMS, Amazon's encryption key management service.

In this step, get ready to:

Enable EBS encryption by default for your AWS account.
Encrypt an existing unencrypted volume using the snapshot-copy workflow.
Create a customer-managed KMS key for fine-grained access control.

Enable EBS encryption by default

Enabling encryption by default is like setting your phone to automatically lock. Every new EBS volume you create in this region will be encrypted without any extra steps.

In the AWS Management Console, confirm you are in the US East (N. Virginia) us-east-1 region using the region dropdown in the top-right corner.
Click Services in the top navigation bar and search for EC2. Open the EC2 Dashboard.
In the right-hand panel of the dashboard, scroll down to the Account attributes section.
Click EBS encryption.
Click Manage.
Check the box for Always encrypt new EBS volumes.
Leave the default KMS key as aws/ebs.
Click Update EBS encryption.

The EBS encryption page now shows that encryption is enabled, with aws/ebs listed as the default key.

What does encryption by default actually do?

From now on, any new EBS volume or snapshot copy you create in this region is automatically encrypted. You do not have to remember to check an encryption box every time.

This setting is region-specific. You would need to enable it separately in each AWS region you use.

Critically, it does NOT encrypt volumes or snapshots that already exist. Your current unencrypted snapshots stay unencrypted. That is exactly why you need the special workflow in the next substep.

Watch out for this exam trick

If the SAA exam asks "How do you encrypt an existing unencrypted volume?", "enable encryption by default" is a trap answer. It only affects new volumes. The correct answer is the snapshot-copy workflow you are about to learn.

Encrypt an unencrypted volume using the snapshot-copy workflow

This is one of the most commonly tested EBS scenarios on the SAA-C03 exam. The question goes like this: "A company has an unencrypted EBS volume with important data. They need to encrypt it. What should they do?"

You cannot just flip a switch to encrypt an existing volume. Encryption happens at the hardware level when data is written, so existing unencrypted data needs to be re-written through an encryption process. The snapshot-copy workflow handles this for you in three steps.

What is the snapshot-copy encryption workflow?

Step 1: Create a snapshot of the unencrypted volume (you already have one from the previous step).
Step 2: Copy that snapshot and enable encryption during the copy. Choose a KMS key.
Step 3: Create a new volume from the encrypted snapshot copy. The new volume is encrypted.

You already completed Step 1 in the previous step when you created my-first-snapshot. Now you will do Steps 2 and 3.

In the EC2 Console left sidebar, click Snapshots under Elastic Block Store.
Select the checkbox next to my-first-snapshot.
Click the Actions dropdown, then select Copy snapshot.

The Copy snapshot dialog opens. This is where you add encryption to the copy.

Leave the Destination Region set to US East (N. Virginia).
Check the box for Encrypt this snapshot.
For KMS key, select (default) aws/ebs.
Click Copy snapshot.

AWS is now creating a brand new snapshot that is byte-for-byte identical to your original, but encrypted. The original unencrypted snapshot still exists unchanged.

Wait for the new snapshot copy to appear in the Snapshots list with a status of completed. This may take a few minutes.
Click on the new snapshot copy to view its details. Confirm the Encryption field shows Encrypted and the KMS key ID references the aws/ebs key.

Don't see an encrypted snapshot?

Make sure you checked the Encrypt this snapshot box in the Copy snapshot dialog. If you missed it, the copy is unencrypted. Delete it and repeat the copy with encryption enabled.

If the snapshot is still in pending status, give it a few more minutes. Refresh the page using the circular arrow icon in the Snapshots list.

Help me troubleshoot my encrypted snapshot copy.

Now create a new encrypted volume from this encrypted snapshot.

Select the new encrypted snapshot copy in the Snapshots list.
Click Actions, then select Create volume from snapshot.
Set the Availability Zone to us-east-1a.
Confirm the Encryption field shows Enabled and the KMS key is aws/ebs.
Click Create volume.

In the left sidebar, click Volumes under Elastic Block Store.
Find your new volume in the list. Click on it and confirm the Encryption field in the details panel shows Encrypted.

You just encrypted data that started its life unencrypted. The original volume's data went through this journey: unencrypted volume, unencrypted snapshot, encrypted snapshot copy, encrypted volume.

Why can you not just turn on encryption for an existing volume?

EBS encryption works at the hardware level when data is written to the volume. Data that was already written without encryption cannot be retroactively encrypted in place.

The snapshot-copy workflow solves this by reading all the data from the unencrypted snapshot and writing it back encrypted into a new snapshot. Creating a volume from that encrypted snapshot gives you a fully encrypted copy of the original data.

Once a volume is encrypted, it stays encrypted forever. You cannot remove encryption from an encrypted volume or snapshot.

Memorize this workflow for the exam

"Unencrypted volume needs to be encrypted" = snapshot-copy workflow. Create snapshot, copy snapshot with encryption, create volume from encrypted copy. This is the answer almost every time this question appears on the SAA-C03.

Create a customer-managed KMS key

The aws/ebs key you just used is an AWS-managed key. It is free and convenient, but it gives you limited control.

For production workloads, you often need to control exactly who can use a key, rotate it on your schedule, or disable it entirely. A customer-managed key gives you all of that.

Click Services in the top navigation bar and search for KMS.
Open Key Management Service.
Click Create key.

The key creation wizard opens. It walks you through four pages of configuration.

On the Configure key page, select Symmetric for Key type.
Select Encrypt and decrypt for Key usage.
Click Next.

On the Add labels page, enter my-ebs-key in the Alias field.
Optionally add a description such as Custom key for EBS encryption.
Click Next.

On the Define key administrative permissions page, select your current IAM user or role as the key administrator.
Click Next.

On the Define key usage permissions page, select your current IAM user or role again.
Click Next.

Review the key policy on the final page.
Click Finish.

Confirm your key appears in the KMS console with the alias my-ebs-key and a status of Enabled.

AWS-managed key vs. customer-managed key

AWS-managed key (aws/ebs): Free to use. AWS rotates it automatically. You cannot control who uses it, disable it, or delete it.

Customer-managed key (my-ebs-key): Costs $1/month. You control exactly who can use it. You can rotate it, disable it, or schedule it for deletion. Every use is logged in CloudTrail for auditing.

Exam keyword triggers for KMS keys

If the SAA exam question mentions "cross-account access to encrypted volumes," "audit key usage," or "control which teams can decrypt data," the answer involves a customer-managed KMS key.

Customer-managed keys cost $1/month

You cannot delete a customer-managed KMS key instantly. There is a mandatory 7-30 day waiting period before deletion completes. The Before You Go section at the end of this project covers how to schedule this key for deletion.

Having trouble creating the key?

Make sure you are signed in with an IAM user or role that has admin access. The KMS key creation requires permissions to create keys and manage key policies.

If you do not see your user listed on the permissions pages, type your IAM username in the search box to find it.

Help me troubleshoot KMS key creation.

Your data is now protected with encryption. Next up, you will automate the entire snapshot process so backups happen on a schedule without any manual work.

Automate Snapshots with Data Lifecycle Manager

In the last step, you encrypted your EBS data using AWS KMS keys. Your volumes and snapshots are now protected with encryption keys you control.

Creating snapshots manually works for one-off backups, but in production you need snapshots to happen automatically on a schedule. Amazon Data Lifecycle Manager (DLM) does exactly this. It creates, retains, and deletes snapshots for you on autopilot.

In this step, get ready to:

Tag your data volume so DLM knows which volumes to back up.
Create a lifecycle policy that takes daily snapshots and keeps the last three.
Learn the difference between DLM default and custom policies for the SAA exam.

Tag your volume and create a DLM policy

DLM identifies which volumes to back up by looking at their tags. Before creating a policy, you need to add a specific tag to your data volume so the policy knows to include it.

In the AWS Management Console, navigate to the EC2 console.
In the left sidebar under Elastic Block Store, click Volumes.
Select your restored data volume (the 8 GiB gp3 volume currently attached to your instance).
Click the Tags tab in the lower details panel.
Click Manage tags.
Click Add new tag.
Enter Backup in the Key field.
Enter Daily in the Value field.
Click Save.

Why tag the volume first?

DLM policies target volumes based on specific tag key-value pairs. When DLM runs on its schedule, it scans for all volumes matching the tag you specify in the policy and creates snapshots of them automatically.

This tag-based approach means you can add backup protection to any volume just by tagging it. No need to modify the policy itself.

Your volume is now tagged and ready for DLM to discover. Next, create the lifecycle policy that targets this tag.

In the left sidebar under Elastic Block Store, click Lifecycle Manager.
Click Create lifecycle policy.

A multi-step form appears. You will configure the policy type, targets, schedule, and retention settings across two screens.

On the Select policy type screen, select EBS snapshot policy.
Click Next.
Under Target resource types, select Volume.
Under Target resource tags, enter Backup for the key and Daily for the value.
In the Description field, enter Daily backup for tagged volumes.
For IAM role, leave the default role selected. DLM creates an IAM role automatically with the permissions it needs to manage snapshots.
For Policy status, make sure Enable is selected.
Click Next to go to the Configure schedule screen.

Now configure how often DLM takes snapshots and how many it keeps.

In the Schedule details section, set the frequency to every 24 hours.
For Retention type, select Count.
Set the retention count to 3.
In the Tagging section, enable Copy tags from source.
Click Review policy.
Review the summary, then click Create policy.

What does this policy do?

DLM automatically takes a snapshot of any volume tagged Backup=Daily every 24 hours. It keeps the 3 most recent snapshots and deletes older ones automatically.

No human has to remember to take backups or clean up old snapshots. The DLM service itself is free. You only pay for the snapshots it creates.

Policy creation failed?

Make sure you selected Default role for the IAM role. If your account has restrictions on creating IAM roles, you may need to create the AWSDataLifecycleManagerDefaultRole role manually.

Also confirm that the target tag key and value match exactly: Backup (capital B) and Daily (capital D). Tags are case-sensitive.

Help me troubleshoot my DLM policy creation error.

Understand default vs. custom DLM policies

The policy you just created is a custom policy because it targets specific tagged resources. For the SAA exam, you need to know when to choose a default policy instead.

What is the difference between default and custom policies?

Default policy: Targets ALL volumes in the region that do not have recent snapshots. Supports only one schedule. Uses age-based retention only (2 to 14 days). Does not support archiving, fast snapshot restore, or cross-account sharing.

Custom policy: Targets only volumes or instances with specific tags. Supports up to 4 schedules. Offers both age-based and count-based retention (up to 1,000 snapshots or 100 years). Supports cross-region copy, cross-account sharing, fast snapshot restore, and snapshot archiving.

SAA exam shortcut

If the question says "ensure all volumes are backed up with minimal configuration," think default policy. If the question mentions "specific retention," "cross-region DR," or "compliance requirements," think custom policy.

Verify the policy is active

In the Lifecycle Manager console, find your newly created policy in the list.
Confirm that the Status column shows ENABLED.

The first automated snapshot will be created at the next scheduled interval. You do not need to wait for it. You already proved that snapshots work by creating them manually in Step 2.

Why not wait for the first automated snapshot?

The policy runs on a 24-hour cycle, so the first automated snapshot could be up to 24 hours away. The important thing is that the policy is active and configured correctly. DLM handles the rest from here.

Your snapshots are now fully automated with DLM. Next up, you will copy a snapshot to another AWS region to set up disaster recovery.

Copy Snapshots Across Regions for Disaster Recovery

Data Lifecycle Manager is now automating your snapshot backups in us-east-1. But all of those snapshots still live in a single AWS region.

If that entire region experiences an outage, your volumes and snapshots would all be unavailable at the same time. In this step, you will copy a snapshot to us-west-2 (Oregon) to build real disaster recovery protection for your EBS data.

In this step, get ready to:

Copy an encrypted snapshot from us-east-1 to us-west-2.
Verify the cross-region snapshot copy in the destination region.
Clean up the copy to avoid ongoing storage charges.

Copy a snapshot to another region

Your encrypted snapshot copy currently lives only in us-east-1. Copying it to a different region means your data survives even if an entire region goes offline.

In the AWS Console, confirm your region is set to US East (N. Virginia) us-east-1 in the top-right corner.
In the left sidebar under Elastic Block Store, click Snapshots.
Find the snapshot that shows Yes in the Encrypted column and select its checkbox.
Click the Actions dropdown.
Select Copy snapshot.
In the Destination Region field, select US West (Oregon).
Confirm the Encrypt this snapshot checkbox is checked.
Keep the KMS key set to the default (default) aws/ebs option.
Click Copy snapshot.

What is happening behind the scenes?

AWS is copying all data blocks from your snapshot to us-west-2. Cross-region copies are always full copies (not incremental), so this takes longer and costs more than same-region operations.

The KMS key used for encryption must exist in the destination region. Your customer-managed key my-ebs-key only exists in us-east-1, which is why this copy uses the default aws/ebs key that AWS provides in every region.

Think of it like mailing a complete copy of a document to another office. You cannot just send the sticky notes with changes. The receiving office needs the full document.

The copy may take a few minutes to complete. You can continue to the next substep while it finishes.

Copy snapshot option grayed out?

Make sure you selected exactly one snapshot by checking its checkbox.

Verify the snapshot status shows completed. You cannot copy a snapshot that is still in pending status.

Why can't I copy my EBS snapshot to another region?

Verify the copy in us-west-2

Now switch to the destination region to confirm your snapshot arrived safely.

Click the region selector in the top-right corner of the console.
Select US West (Oregon) us-west-2.
In the left sidebar under Elastic Block Store, click Snapshots.

You should see your snapshot copy listed here. If the status shows pending, wait a few minutes and refresh the page until it shows completed.

What can you do with this cross-region copy?

From this snapshot, you could create a new EBS volume in us-west-2 and attach it to an EC2 instance running there. Your data is now recoverable even if the entire us-east-1 region goes offline.

You cannot share encrypted snapshots publicly. You can share them with specific AWS accounts, but the receiving account needs permissions to the KMS key that encrypted the snapshot.

AWS recommends copying any shared encrypted snapshot with your own KMS key. This protects you if the original owner revokes access to their key.

Clean up the cross-region copy

You have confirmed that cross-region copying works. Delete the copy in us-west-2 now to avoid paying for snapshot storage in two regions.

While still in the us-west-2 console, select the checkbox next to your snapshot copy.
Click the Actions dropdown.
Select Delete snapshot.
In the confirmation dialog, type delete and click Delete.
Click the region selector in the top-right corner.
Select US East (N. Virginia) us-east-1 to switch back to your primary region.

Confirm the region in the top-right corner now reads US East (N. Virginia). You are back in your primary region with all your original snapshots and resources.

Snapshot won't delete?

Make sure the snapshot status shows completed before deleting. A snapshot that is still copying cannot be deleted.

Double-check you are in the us-west-2 region. If you accidentally switched back to us-east-1, you might be looking at your original snapshots instead of the copy.

Why can't I delete my EBS snapshot in us-west-2?

Secret mission

Archive a Snapshot and Calculate Cost Savings

EBS Snapshot Archive is a cheaper storage tier for snapshots you rarely need to restore. In this mission, you will archive a snapshot and calculate exactly how much money it saves compared to standard snapshot storage. This is a favorite SAA-C03 cost optimization topic.

Before you go

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses cloud resources that incur small ongoing charges if left running.

Cost warning

Your customer-managed KMS key costs $1/month and cannot be deleted instantly. It has a mandatory 7-30 day waiting period before deletion. During that waiting period, the key is disabled but you are still charged.

EBS volumes cost approximately $0.08/GB-month, and snapshots cost $0.05/GB-month. If you are within the AWS Free Tier (30 GB of EBS storage and 1 GB of snapshot storage per month), your charges may be $0.

Resources you used:

1x EC2 instance (t2.micro or t3.micro). Free tier eligible, or approximately $0.012/hour.
EBS volumes (8 GiB gp3 each). Approximately $0.64/month each, or free tier eligible (30 GB total included).
EBS snapshots. Approximately $0.05/GB-month, or free tier eligible (1 GB snapshot storage included).
1x customer-managed KMS key. $1/month with a mandatory 7-30 day waiting period before deletion.
1x Data Lifecycle Manager policy. Free (no charge for the policy itself, only the snapshots it creates).

Keep everything running

No action needed. Choose this if you plan to continue with the next EBS project (volume types and performance) soon.

Keep your EC2 instance and primary data volume running.
Delete any extra test volumes and snapshots you created during the project that you no longer need.
Your DLM policy will continue creating daily snapshots. Keep it enabled if you want automated backups.

Pause - I'll come back to this later

Stop your EC2 instance to stop paying for compute. Your volumes and snapshots still incur storage charges.

In the EC2 Console, select your instance, then choose **Instance state** and click **Stop instance**.
Delete any snapshots you no longer need to reduce storage charges.
Disable or delete your DLM policy in the **Lifecycle Manager** console so it stops creating new snapshots while you are away.
Your EBS volumes remain attached and retain all data. When you return, start the instance again.

Delete - I don't want to use this again

Remove all project resources to bring ongoing costs to $0 (except the KMS key during its waiting period).

In the EC2 Console, select your instance, then choose **Instance state** and click **Terminate instance**. This also deletes the root volume.
Navigate to **Elastic Block Store**, then **Volumes**. Delete all remaining EBS volumes created during this project.
Navigate to **Elastic Block Store**, then **Snapshots**. Delete all snapshots in us-east-1.
Switch to the us-west-2 region in the console header. Navigate to **EBS Snapshots** and delete any cross-region snapshot copies there.
Navigate to **Lifecycle Manager** and delete your DLM policy.
Go to the **AWS KMS** Console and schedule your my-ebs-key customer-managed key for deletion. The minimum waiting period is 7 days. You will be charged $1 maximum during this period.
Switch back to us-east-1 when you are done.

Mission accomplished

That's a Wrap!

Nice work! You just built a complete EBS data protection and encryption system from scratch.

You've learned how to:

Created EBS snapshots and restored data from them after deleting the original volume, proving that snapshots protect you from data loss.
Encrypted an unencrypted EBS volume using the snapshot-copy workflow with AWS KMS, the most commonly tested EBS encryption scenario on the SAA-C03 exam.
Automated snapshot creation and retention with Amazon Data Lifecycle Manager and copied snapshots across regions for disaster recovery.
Secret Mission: Archived a snapshot to the EBS Snapshots Archive tier and calculated the cost savings compared to standard snapshot storage.

These skills map directly to SAA-C03 exam domains. Domain 1 covers Secure Architectures (30%). Domain 2 covers Resilient Architectures (26%). Domain 4 covers Cost-Optimized Architectures (20%).

Ready to quiz yourself?