Amazon EBS: Understanding Storage, Snapshots, and Data Recovery ☁️

As I continue my AWS Cloud Foundations journey, I'm exploring how AWS services work beyond simply launching virtual servers.

This time, I worked with Amazon Elastic Block Store (Amazon EBS), a service that provides persistent block storage for Amazon EC2 instances.

But creating storage is only part of the story. What happens when data is deleted, and you need it back?

That was one of the things I explored in this hands-on lab.

Think of an EC2 instance as a computer in the cloud. Like any computer, it needs storage for its operating system, files, and application data.

Amazon EBS provides that storage through volumes that can be attached to EC2 instances. These volumes persist independently of the life of the instance.

EBS also supports snapshots, which capture a point-in-time representation of a volume's data. A snapshot can be used to create another volume for recovery or duplication.

This was the architecture i deployed.

For this lab, I created a new 1 GiB General Purpose SSD (gp2) EBS volume named My Volume and attached it to an existing EC2 instance named Lab. The goal was to add separate storage to the instance and explore how EBS snapshots can be used to recover data.

After attaching the volume, I connected to the EC2 instance using AWS Systems Manager Session Manager, which provided a terminal session without requiring me to connect through SSH.

I started by running df -h to check the filesystems mounted on the instance. The output showed the existing 8 GiB root volume, but my newly attached EBS volume was not listed yet.

This was because attaching a volume in AWS does not automatically make its filesystem accessible in Linux. I needed to prepare and mount it first.

I created an ext3 filesystem on the new volume, created**** /mnt/data-store as its mount point, and mounted the volume there. I also added an entry to /etc/fstab so Linux could mount it automatically during startup.

Running df -h again showed the additional storage mounted at /mnt/data-store, with approximately 975 MiB available. I then created a file named file.txt on the volume and verified that its contents had been written successfully.

With the file in place, I created an EBS snapshot named My Snapshot. A snapshot preserves a point-in-time representation of a volume's data, allowing a new volume to be created from that saved state.

My AWS console showed a 1 GiB source volume and a completed snapshot with a reported size of 53 MiB. This helped me understand that a volume's provisioned capacity is different from the amount of data represented in its snapshot. AWS snapshots do not need to store empty blocks as though they contain data.

To test the snapshot, I deleted file.txt from the original volume. When I checked /mnt/data-store again, the file was no longer there.

I then created a new EBS volume from My Snapshot, attached it to the same EC2 instance, and mounted it at a separate path: /mnt/data-store2.

Using a different mount point allowed me to access the restored volume independently of the original one. When I listed the restored directory and read file.txt, the file was present with its original contents: some text has been written.

This was the key outcome of the lab: even after deleting the file from the original volume, I was able to recover the saved version by creating a new volume from the snapshot.

This lab helped me understand how EBS volumes and snapshots work together. An EBS volume provides storage for an EC2 instance, while a snapshot preserves a point-in-time version of its data that can be used to create another volume.

More importantly, I saw how this works in practice: I added storage to an existing instance, prepared it in Linux, saved a snapshot, deleted a file, and recovered that file from the snapshot.