Understanding AWS EBS and Snapshots

While learning EC2, one thing became very clear: compute is only one part of the system. Storage is just as important. That is where AWS Elastic Block Store (EBS) comes in. EBS is the storage layer attached to EC2 instances, and understanding it made the whole idea of cloud servers feel much more practical and real.

What is EBS?

EBS, or Elastic Block Store, is basically a virtual hard disk for EC2. When an EC2 instance is launched, the operating system lives on an EBS volume. That default disk is often called the root volume. EBS can also be used to store extra data such as website files, logs, or database content.

Another important point is that EBS volumes are created inside a specific Availability Zone, and the EC2 instance must be in the same zone to attach that volume. AWS automatically replicates EBS volume data within that same zone for reliability, but not across multiple zones by default.

EBS Volumes and Snapshots

EBS mainly gives two things:

• Volume → the actual virtual disk
• Snapshot → backup of that disk

This makes EBS very useful not only for storing data, but also for backing it up and restoring it later if something goes wrong.

Types of EBS Storage

AWS offers different volume types depending on performance and use case. The main categories are:

• General Purpose SSD (gp3 / gp2) — good for most workloads like web servers and normal application storage
• Provisioned IOPS SSD — used when databases need very high input/output performance
• Throughput Optimized HDD — good for big data and large processing workloads
• Cold HDD — lower cost for data accessed less often
• Magnetic — older generation, mainly for cheap archive or backup-style use cases

For general workloads, the most recommended one is usually gp3 because it gives a good balance of performance and cost.

Step-by-Step: Adding a New EBS Volume

One of the key parts of the lesson was learning how to attach a separate EBS volume to an EC2 instance and use it for a specific folder. In the lab, the goal was to create a separate disk for website images. The same logic can be used for logs, uploads, or database files.

Step 1: Launch an EC2 Instance

Using Amazon Linux 2023 with the default 8 GB gp3 root volume. That default disk stored the operating system and initial website data.

Step 2: Check Current Disks

Inside Linux, the current disks and partitions can be checked using:

fdisk -l
df -h

fdisk -l shows the available disks and partitions, while df -h shows which partitions are actually mounted and in use. This is an important distinction.

Step 3: Create a New Volume in AWS

A new volume was created from the EC2 Volumes section with:

• Type: gp3
• Size: 5 GB
• Availability Zone: same as the instance

Matching the zone is critical. If the instance is in one zone and the volume is created in another, the volume cannot be attached.

Step 4: Attach the Volume

After creation, the new volume was attached to the instance. AWS lets us choose a device name such as /dev/sdf, but once Linux sees the device, it often appears with a name like /dev/xvdf.

Step 5: Create a Partition

After attaching the disk, it exists physically but is still raw. The next step is to create a partition:

fdisk /dev/xvdf

The flow used was:

• n → new partition
• p → primary partition
• 1 → partition number
• Press Enter for default first sector
• Press Enter for full disk usage
• w → write changes

After that, a partition like /dev/xvdf1 becomes available.

Step 6: Format the Partition

A partition must be formatted before files can be stored on it. In the lesson, one example used ext4:

mkfs.ext4 /dev/xvdf1

Another example later used xfs for a database partition. The idea is the same: formatting prepares the storage for a filesystem.

Step 7: Mount the Volume

Once formatted, the partition can be mounted to a directory. In the web example, it was mounted to the images folder:

mount /dev/xvdf1 /var/www/html/images

Mounting basically means connecting the disk to a folder. From that moment, files placed in that folder are stored on the new EBS volume, not on the root disk.

Step 8: Make the Mount Permanent

A temporary mount disappears after reboot. To keep it permanently, the mount entry must be added to /etc/fstab.

/dev/xvdf1 /var/www/html/images ext4 defaults 0 0

After editing the file, this command checks and applies the mount:

mount -a

If there is no error, the entry is valid and the mount will survive reboots.

Using EBS for Database

Instead of installing the database first and moving data later, the new disk was created and mounted to /var/lib/mysql before starting the database service. That way, database files were written directly to the separate partition from the start.

mkdir /var/lib/mysql
mount /dev/xvdh1 /var/lib/mysql
dnf install mariadb105-server -y
systemctl start mariadb

This showed a very real system administration idea: keep application data on a dedicated disk, not mixed with the operating system.

What is an EBS Snapshot?

A snapshot is a backup of an EBS volume. It is one of the most useful features of EBS because it allows storage to be restored or moved later.

The first snapshot copies the full data. Later snapshots are incremental, which means only changes are stored. That makes them very useful for regular backup strategies.

Why Snapshots Matter

Snapshots are not only for backup. They are useful for:

• Recovering lost or corrupted data
• Creating a new volume from existing data
• Changing volume type during migration
• Increasing storage while restoring
• Moving data to another Availability Zone
• Copying data to another region
• Sharing data with another AWS account

That makes snapshot one of the most powerful storage features in EC2 operations.

Step-by-Step: Snapshot Recovery Flow

The lesson simulated database corruption by deleting the data inside /var/lib/mysql. After that, MariaDB failed to start, which created the perfect recovery scenario.

Step 1: Create a Snapshot

Before corruption, a snapshot of the database volume was created from the AWS Console. This snapshot became the backup point.

Step 2: Simulate Data Loss

The data directory was cleared, and the database service failed on restart. This showed exactly why snapshots matter.

Step 3: Detach the Corrupted Volume

The corrupted volume was unmounted and detached from the instance. Then a new volume was created directly from the snapshot.

Step 4: Create a New Volume from Snapshot

This is where recovery becomes powerful. When creating a new volume from a snapshot, AWS allows changes such as:

• Increasing size
• Changing volume type
• Changing Availability Zone
• Enabling encryption

So recovery can also become a migration or upgrade opportunity.

Step 5: Reattach and Mount

The recovered volume was attached back to the instance and mounted to the same folder. As soon as that happened, the data was visible again. Then MariaDB was restarted successfully.

Snapshot → New Volume → Attach → Mount → Restore

One of the biggest lessons here was this: when a disk becomes damaged, we usually do not try to “repair” it directly. We replace it with a new one created from a reliable backup.

Other Snapshot Features

The lesson also highlighted a few extra snapshot capabilities:

• Copy snapshot to another region — useful for moving EBS data across regions
• Share snapshot with another AWS account — useful when data needs to move between accounts
• Create image from snapshot — later useful in AMI creation workflows

This means snapshots are not just for backup. They are also useful for migration, sharing, and operational flexibility.

What I Really Learned from EBS

This lesson taught me much more than “how to add storage.” It taught me how cloud storage works operationally:

• Volumes must be planned with Availability Zones in mind
• New disks are raw until partitioned and formatted
• Mount points decide where the data actually goes
• Separate disks make applications cleaner and safer
• Snapshots create a strong backup and recovery strategy

It also made Linux storage concepts much easier to connect with AWS concepts. Commands like fdisk, mkfs, mount, and fstab finally felt meaningful because they were tied directly to a real cloud use case.

Final Thoughts

EBS turned out to be one of the most practical AWS services I’ve learned so far. It connects cloud storage with real system administration. Instead of treating storage like a black box, this lesson showed me how to create, attach, partition, format, mount, backup, and recover it step by step.

For me, the biggest takeaway was that cloud storage is not just about adding space. It is about designing storage properly, separating data cleanly, and always having a recovery plan through snapshots.