Create, Attach, Snapshot, and Move Amazon EBS Volumes – SAP-C02 Study Guide

Purpose of This Lesson

This hands-on workflow demonstrates how to provision an additional Amazon Elastic Block Store (EBS) volume, attach it to an EC2 instance, prepare it for Linux use, create a snapshot, and restore that snapshot as a volume in another Availability Zone.

The exercise highlights an important EBS design rule: an EBS volume is tied to a single Availability Zone, while an EBS snapshot is regional and can be used to create a new volume in another Availability Zone within the same Region.

Key Concepts

EBS volumes are Availability Zone-specific

An EBS volume can be attached only to an EC2 instance in the same Availability Zone. A volume created in us-east-1a cannot be directly attached to an instance in us-east-1b.

To move the data to another Availability Zone:

1. Create a snapshot of the source volume.
2. Create a new EBS volume from that snapshot.
3. Select the destination Availability Zone.
4. Attach the new volume to the destination EC2 instance.

This creates a new volume; it does not move the original volume or provide simultaneous multi-AZ access.

Root volumes and data volumes

An EC2 instance commonly has a root EBS volume created from the AMI. Additional EBS volumes can be used for application data, logs, databases, or other persistent storage.

The root volume is often configured to be deleted when the instance terminates. Additional data volumes may remain unless their DeleteOnTermination setting is enabled or they are explicitly deleted. Always verify the setting and clean up unused volumes to avoid charges.

Selecting an EBS volume type

Common volume families include:

• gp3: General-purpose SSD with independently configurable volume size, IOPS, and throughput. It is a common default for general workloads.
• gp2: Previous-generation general-purpose SSD. Performance is linked more closely to volume size than with gp3.
• io2: Provisioned IOPS SSD for workloads requiring high, predictable I/O performance and high durability.
• st1: Throughput Optimized HDD for frequently accessed, throughput-intensive workloads such as big-data processing. It cannot be used as a boot volume.
• sc1: Cold HDD for infrequently accessed, throughput-oriented data. It also cannot be used as a boot volume.
• standard: Magnetic legacy storage. It is generally unsuitable for new designs except for specific legacy requirements.

The correct choice depends on IOPS, throughput, latency, durability, boot-volume support, and cost requirements. Do not select a provisioned-IOPS volume merely because it has a higher maximum performance ceiling.

Attaching a volume is not the same as mounting it

After an EBS volume is attached to an EC2 instance, the operating system still needs to recognize and use it:

1. Confirm the device with lsblk.
2. Create a file system if the volume is new.
3. Create a mount-point directory.
4. Mount the file system.
5. Add a persistent mount configuration if it must survive a reboot.

Linux device names shown by EC2 and the operating system may differ. Use the device path reported by the operating system rather than assuming the console name is identical.

File systems and persistent mounts

A new, empty volume has no file system. For example, an ext4 file system can be created with:

sudo mkfs -t ext4 /dev/xvdf
sudo mkdir /data
sudo mount /dev/xvdf /data

For persistent mounting, add an /etc/fstab entry. Using the file system UUID is generally safer than relying on a device name that may change:

sudo blkid /dev/xvdf
sudo nano /etc/fstab

Example entry:

UUID=<filesystem-uuid> /data ext4 defaults,nofail 0 2

The nofail option can prevent an instance from failing to boot if the volume is temporarily unavailable. Test the configuration with mount -a before rebooting.

Do not run mkfs on a volume containing required data. Formatting destroys the existing file system and its contents.

EBS snapshots

An EBS snapshot is an incremental, point-in-time backup of an EBS volume. Snapshots are managed through Amazon S3 behind the scenes, but users do not access them as ordinary S3 objects or configure an S3 bucket for standard snapshot operation.

Important properties include:

• Snapshots are regional resources.
• A snapshot can create volumes in any Availability Zone in the same Region.
• Cross-Availability Zone restoration is performed by creating a new volume from the snapshot.
• Snapshots can be copied to another Region for disaster recovery or migration.
• A snapshot does not automatically provide a live, continuously synchronized replica.
• The first snapshot captures the initial data set; later snapshots are incremental, although deleting snapshots does not necessarily remove all blocks still referenced by other snapshots.

Exam-Relevant Takeaways

• An EBS volume and its EC2 instance must be in the same Availability Zone.
• To make EBS data available in another Availability Zone, snapshot the source volume and restore the snapshot as a new volume in the destination Availability Zone.
• EBS snapshots are regional. They are not limited to the source Availability Zone.
• An attached volume still requires operating-system configuration before applications can use it.
• A new volume must be formatted before mounting, but a restored volume already contains its file system and should normally be mounted directly.
• Use gp3 for many general-purpose SSD workloads when independently tuning IOPS and throughput is useful.
• Use io2 when the workload requires provisioned IOPS, consistently low latency, or high durability characteristics.
• st1 and sc1 are HDD options for throughput-oriented data and are not boot-volume choices.
• EBS is not a multi-AZ shared file system. For shared access from multiple instances, evaluate Amazon EFS, FSx, or another service appropriate to the workload.
• EBS snapshots are backups and migration mechanisms, not a substitute for application-level replication or synchronous multi-AZ storage.

Architecture Decision Guide

Requirement	Appropriate approach	Important consideration
General-purpose EC2 block storage	gp3 EBS volume	Tune size, IOPS, and throughput independently as needed
High and predictable IOPS	io2 EBS volume	Validate required IOPS, latency, and cost
Move data to another Availability Zone	Snapshot, then create a volume in the target AZ	The target volume is a separate resource
Share a file system across AZs and instances	Amazon EFS or an appropriate FSx service	EBS does not provide general multi-instance file sharing
Boot an EC2 instance	EBS root volume or another supported boot option	st1 and sc1 are not boot-volume types
Persist a mount after reboot	/etc/fstab, preferably with UUID	Test the entry and consider nofail
Regional backup or recovery	EBS snapshots, optionally copied cross-Region	Plan retention, encryption, and restore testing
Preserve data after EC2 termination	Disable DeleteOnTermination for the data volume	Terminating an instance does not necessarily delete every attached volume

Common Exam Traps

• Confusing a snapshot with a volume: A snapshot is not directly attached to an instance. Restore it to an EBS volume first.
• Assuming snapshots are Availability Zone resources: EBS volumes are AZ-specific; snapshots are regional.
• Trying to attach one volume across AZs: Direct attachment is impossible across Availability Zones.
• Assuming attachment makes the disk usable: Linux still needs a file system and mount point.
• Formatting a restored volume: A volume restored from a snapshot already contains data. Formatting it destroys that data.
• Using device names as permanent identifiers: Device mappings can appear differently inside the guest operating system. UUID-based mounts are more reliable.
• Treating EBS as shared storage: Standard EBS attachment is intended for a single EC2 instance at a time. Multi-Attach is limited to specific volume types and compatible applications; it is not a general-purpose shared file system.
• Assuming a snapshot is a synchronous replica: Snapshot creation and restoration are backup operations, not continuous replication.
• Forgetting encryption requirements: Encrypted volumes should be created with the required AWS KMS key. Snapshots inherit encryption state, and encrypted snapshots can be copied subject to AWS KMS permissions and configuration.
• Ignoring cleanup: Terminating instances may leave data volumes and snapshots behind, producing ongoing storage charges.

Real-World Engineer Notes

• Prefer stable identifiers such as file system UUIDs or labels in /etc/fstab.
• Before creating a snapshot for backup or migration, coordinate with the application when crash consistency matters. For databases, use database-native backup or quiescing procedures when appropriate.
• Snapshot restoration can be slower on first access because blocks may need to be initialized. For latency-sensitive workloads, consider Fast Snapshot Restore in the required Availability Zones, while accounting for its cost and configuration requirements.
• Use lifecycle policies, such as Amazon Data Lifecycle Manager where appropriate, to automate EBS snapshot retention and reduce operational drift.
• Apply tags such as Name, Environment, Application, Owner, and BackupPolicy to volumes and snapshots. Tags support inventory, automation, charge allocation, and cleanup.
• Before deleting a volume, confirm that it is detached and that no required data exists only on that volume. Take a final snapshot when the retention policy requires it.
• For cross-Region disaster recovery, copy snapshots to the recovery Region and plan how to recreate networking, IAM permissions, KMS keys, EC2 instances, and application configuration.

Quick Reference Summary

Volume creation:
  Select volume type and size
  Select the target Availability Zone
  Configure encryption, IOPS, throughput, and tags

Initial Linux setup:
  lsblk
  sudo mkfs -t ext4 /dev/<device>
  sudo mkdir /data
  sudo mount /dev/<device> /data

Persistent mount:
  Identify the UUID with blkid
  Add UUID-based entry to /etc/fstab
  Test with sudo mount -a

Move data to another AZ:
  Snapshot source EBS volume
  Create a new volume from the snapshot in the target AZ
  Attach the new volume to the target instance
  Mount it without formatting

Flashcards

1. Q: Can an EBS volume in us-east-1a be attached directly to an instance in us-east-1b?

A: No. The volume and instance must be in the same Availability Zone.

1. Q: How do you make EBS data available in another Availability Zone?

A: Create a snapshot, restore it as a new volume in the destination AZ, and attach the new volume.

1. Q: Are EBS snapshots AZ-specific?

A: No. They are regional resources.

1. Q: What must be done before a new empty EBS volume can store files on Linux?

A: Create a file system, create a mount point, and mount the volume.

1. Q: Should a volume restored from a snapshot be formatted before mounting?

A: Normally no; formatting would erase the restored file system and data.

1. Q: Which EBS type is commonly used for general-purpose SSD storage with independently configurable IOPS and throughput?

A: gp3.

1. Q: Which EBS types are throughput-oriented HDD options and cannot be used as boot volumes?

A: st1 and sc1.

1. Q: What is the purpose of /etc/fstab?

A: It defines file systems that should be mounted automatically, including after a reboot.

1. Q: Why are UUIDs preferred over device names in /etc/fstab?

A: Device names can vary across reattachments or reboots, while a file system UUID identifies the file system more reliably.

1. Q: Does an EBS snapshot provide continuous synchronous replication?

A: No. It is a point-in-time backup and restore mechanism.

1. Q: What happens to an additional data volume when its EC2 instance is terminated?

A: It may remain unless DeleteOnTermination is enabled or the volume is manually deleted.

1. Q: What service should be considered when multiple instances need shared file access across Availability Zones?

A: Amazon EFS or an appropriate Amazon FSx service, rather than standard EBS.

Practice Questions

Question 1

An application stores data on an EBS volume attached to an EC2 instance in us-east-1a. The application must be moved to a new instance in us-east-1b, and the data must be preserved. Which approach satisfies the requirement?

A. Attach the existing EBS volume directly to the new instance.
B. Create an EBS snapshot, restore it as a volume in us-east-1b, and attach the new volume.
C. Copy the EBS volume into an S3 bucket and attach the bucket to the instance.
D. Change the Availability Zone attribute of the existing EBS volume.

Correct answer: B

An EBS volume is restricted to its Availability Zone. A snapshot can be restored as a new volume in another AZ within the same Region.

Question 2

An engineer attaches a newly created 100 GiB EBS volume to a Linux EC2 instance. The volume appears in lsblk, but applications cannot write to /data. What is the most likely missing step?

A. Enable an internet gateway.
B. Create an IAM role for the volume.
C. Create a file system and mount the volume to /data.
D. Copy the volume to Amazon S3.

Correct answer: C

EBS provides block storage. The operating system must create or recognize a file system and mount it before applications can use it through a directory.

Question 3

A company needs general-purpose SSD storage for an EC2 workload. It wants to adjust IOPS and throughput independently of volume size. Which EBS type is the best initial choice?

A. gp2
B. gp3
C. sc1
D. standard

Correct answer: B

gp3 supports independent configuration of volume size, IOPS, and throughput, making it a flexible general-purpose SSD option.

Question 4

A restored EBS volume contains a file system and application data from a snapshot. What should the administrator do before using it on a new EC2 instance?

A. Run mkfs to initialize the volume.
B. Mount the existing file system without formatting it.
C. Create a new snapshot and delete the restored volume.
D. Convert it to an S3 object.

Correct answer: B

Restoring from a snapshot reproduces the volume contents. Running mkfs would overwrite the existing file system and destroy the restored data.

Question 5

A team wants several EC2 instances in different Availability Zones to concurrently access a shared file system using normal directory semantics. Which service is generally more appropriate than standard EBS?

A. Amazon EFS
B. EBS gp3 attached separately to each instance
C. An EBS snapshot mounted by every instance
D. Amazon S3 accessed as a block device

Correct answer: A

Amazon EFS is designed for shared file access across instances and Availability Zones. A standard EBS volume is not a general-purpose multi-instance, multi-AZ file system.