A. Amazon Machine Image (AMI): The Blueprint for Your Server
What is an AMI?
An Amazon Machine Image (AMI) is essentially a template that contains all the information needed to launch an EC2 instance (a virtual server in the cloud).
Think of it like a recipe or a blueprint:
A recipe contains a list of ingredients (the software) and instructions on how to combine them (the configuration).
An AMI contains a snapshot of the root volume (the operating system, application server, and applications), launch permissions, and block device mapping.
When you launch an EC2 instance, you must select an AMI. AWS provides many pre-configured AMIs (e.g., with Ubuntu, Windows, or Amazon Linux already installed), or you can create your own custom AMI.
Key Components of an AMI:
A template for the root volume for the instance (e.g., an operating system, an application server, and applications).
Launch permissions that control which AWS accounts can use the AMI to launch instances.
Block device mapping that specifies the volumes to attach to the instance when it's launched.
Real-Life Example:
You need to launch ten identical web servers running your company's website. Instead of manually installing Apache, and your code on each one, you:
Launch one EC2 instance from a standard Linux AMI.
Install and configure all the necessary software on it.
Create a custom AMI from this perfectly configured instance.
Now, you can launch ten new instances directly from your custom AMI. They will all be perfect clones, ready to serve traffic immediately. This is also the foundation for Auto Scaling groups!
Step-by-Step: Create an AMI
- Launch and configure an EC2 instance (install software, set up environment).
- Go to EC2 Dashboard → Instances. Select your instance → Actions → Image → Create Image. Name your image and click Create Image.
- AWS creates an AMI and stores it under AMIs.
Install Sample Software
SSH into your EC2 and run:
bash
CopyEdit
sudo apt update -y
sudo apt install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginxg
echo "Hello from Morris Ndeobi AMI" | sudo tee /var/www/html/index.html
Run Test in browser:
• Visit your EC2’s public IP.
• You should see the message: "Hello from Morris Ndeobi AMI"
4.Launch EC2 from Custom AMI
Go to AMIs, select your new image.
- Test Your New EC2 • Once launched, go to Public IP of the new instance. • Open in browser. • You should see: "Hello from Morris Ndeobi AMI"
Your entire setup is cloned and working!
B. EBS Multi-Attach: Definition, requirements, use cases, limitations.
The Definition What does it Entail
Think of an EBS Volume as a super-powered, virtual USB thumb drive for your AWS servers (which are called EC2 instances).
Normally, a USB drive can only be plugged into one computer at a time. That's how regular EBS volumes work.
EBS Multi-Attach is a special superpower that lets you plug that same exact USB drive into multiple computers at the same time. All the computers can see the files on the drive and read from it or write to it.
In technical terms: It's a feature that allows a single EBS volume (a type of storage) to be attached to multiple EC2 instances in the same AWS Availability Zone simultaneously.
- The Requirements (What do you need to use it?) You can't just use any old USB drive or any old computer for this. There are rules:
The Right Type of "USB Drive": You must use a io2 or io1 EBS volume type. The common, cheaper type (gp2, gp3) doesn't have this superpower.
The Right "File System": The volume must be formatted with a cluster-aware file system. Regular file systems (like NTFS or ext4) would get horribly corrupted because the computers wouldn't know how to share the drive without stepping on each other's toes.
Examples of cluster-aware file systems are GPFS (from IBM), OCFS2 (from Oracle), or Windows Server Failover Clustering.
Location, Location, Location: All the EC2 instances you're attaching the volume to must be in the exact same data center (the same AWS Availability Zone). You can't stretch this superpower across different cities.
- The Use Cases (When would you use this?) You wouldn't use this for your personal photos. This is for big, important, specialized jobs.
Use Case 1: The Super-Fast, Shared Database
Scenario: You have a super-demanding database (like SAP HANA) that needs super low-latency (super fast) storage. Instead of having the database files on one server's slow storage, you put them on one super-fast io2 volume. Then, you attach that same volume to multiple application servers. All the servers can talk to the database files at lightning speed without any delay.
Use Case 2: The High-Availability Cluster
Scenario: You have a critical application that must never go down. You set up two servers in a "cluster." Both servers have access to the same set of data on the multi-attach volume. If one server catches on fire and dies, the other server immediately takes over, already having access to all the data. There's no need to copy files over; it's already there!
Use Case 3: The Giant, Shared Scratch Pad
Scenario: You're running a massive data analysis job that needs to process a huge amount of temporary data. You can have multiple worker servers all reading from and writing to the same temporary space on the multi-attach volume, making the whole process much faster.
The Limitations (The "Gotchas!")
This superpower comes with big warnings. Remember the LEGOs? If two people try to build different things on the same baseplate at the same time, it becomes a mess.
The Big One: Corruption Risk: If the applications on your multiple servers do not know how to coordinate with each other, they will corrupt the data. The cluster-aware file system is the "referee" that prevents this. Without it, it's a guaranteed disaster. AWS just provides the shared disk; it's your job to manage the software on top of it.
Not for Everyday Use: This is a specialized tool for databases and clustered applications. You would never use it to host a regular website or store your personal files.
Cost: The io1 and io2 volume types are the premium, expensive types of EBS storage. You're paying for both the high performance and the multi-attach feature.
Limited Reach: Remember, all servers must be in the same data center (Availability Zone). You can't use this for a disaster recovery setup spread across different locations.
The Perfect Simple Analogy
Think of a Google Doc.
A normal EBS volume is like a Microsoft Word file on your laptop. Only you can open and edit it. To give it to someone else, you have to email it to them (make a copy).
An EBS Multi-Attach volume is like a shared Google Doc. You send the link to your teammates, and multiple people can be in the document at the same time, editing and seeing each other's changes live.
The "cluster-aware file system" is like the rules Google Docs uses to stop you from typing over the same sentence someone else is typing. Without those rules, the document would be a mess!
I hope that makes it clear! It's a powerful but very specialized tool.
*Steps on how to Set Up EBS Multi-Attachment
*
- You must have a viable instance. So go ahead and create two instances.
- Go to EC2 → Volumes → Create Volume.
- Attach the volume to each instance via Actions → Attach Volume.
- SSH into each instance and mount the volume using Linux commands. lsblk.
Now do the same for the second instance volume.
C. ** SNAPSHOTS: The Incremental Backup for Your Disks
**What is a Snapshot?
A snapshot is a backup of an Amazon Elastic Block Store (EBS) volume at a point in time. EBS volumes are the virtual hard disks you attach to your EC2 instances to store data.
The most important thing to know about snapshots is that they are incremental. This means when you create a new snapshot, only the blocks on the volume that have changed since your last snapshot are saved.
How Do Incremental Snapshots Work?
You create your first snapshot (Snapshot A). This copies all the data blocks from your EBS volume to Amazon S3 (a highly durable storage service).
You make some changes to your disk.
You create a second snapshot (Snapshot B). Snapshot B only saves the data blocks that were changed
Benefits:
Cost-Effective: You only pay for the changed data.
Durable: Stored automatically in Amazon S3.
Flexible: You can create a new EBS volume from a snapshot in any Availability Zone, which is key for disaster recovery.
Steps to Recover Volume via Snapshot:
1.Make Sure You Have EC2 + EBS Volume Running
You should have:
• EC2 running (from earlier)
• EBS volume mounted and data written (e.g., hello.txt)
- Create a Snapshot
Go to EC2 Dashboard → Elastic Block Store → Volumes
Select your EBS volume
Click Actions → Create Snapshot
Name it: my backup snapshot
. Delete the Original Volume (Optional for Testing)
Warning: This will remove the original data (but we have a backup)
• Detach the volume from EC2
• Go to Volumes → Select → Delete
. Restore Volume from Snapshot
Go to EC2 → Snapshots
Find your snap shot with the name my backup snapshot
- Delete the Original Volume (Optional for Testing) Warning: This will remove the original data (but we have a backup) • Detach the volume from EC2
• Go to Volumes → Select → Delete
- Restore Volume from Snapshot
Go to EC2 → Snapshots
Find your snapshot (My backup snapshots)
o Same Availability Zone as your EC2
o Volume Type: gp2
or io1/io2 if you are attaching it to more than one ec2
Click Create Volume
- Attach the Restored Volume to EC2 • Go to Volumes → Select new one → Attach Volume
Choose EC2 instance and set device name (e.g., /dev/xvdf)
- Mount and Check Your Data SSH into EC2 and run:
bash
CopyEdit
Check device
lsblk.
Mount it
sudo mkdir /restore
sudo mount /dev/xvdf /restore
Create a mount point
sudo mkdir /restore
View the restored file
cat /restore/hello.txt
You should see the file: Hello from EBS!
Now you have successfully created a backup of your EBS volume by taking a snapshot, and then used that snapshot to restore the volume. This means your data is safely stored and can be recovered or replicated whenever needed.
EBS, Snapshots, and AMIs Over View
EBS (Elastic Block Store)
EBS provides persistent storage for your EC2 instances. It forms the foundation for snapshots and is an essential component of Amazon Machine Images (AMIs).
Snapshot
A snapshot is essentially a backup of an EBS volume. You can use it to restore data, spin up new volumes, or even build AMIs.
AMI (Amazon Machine Image)
An AMI acts like a blueprint for launching EC2 instances. It’s created from EBS snapshots and contains everything needed to start a server—operating system, applications, and configurations.
How it Works in Practice
When you launch a new EC2 instance from an AMI:
AWS pulls the EBS snapshots embedded in the AMI.
Those snapshots are used to recreate the necessary EBS volumes.
The volumes are then attached to your instance so it can boot up with your chosen setup.
Wrapping It All Up
In today’s fast-paced cloud landscape, mastering AMIs, snapshots, and EBS Multi-Attach isn’t just about technical knowledge—it’s about creating infrastructure that’s dependable, scalable, and built for the future. These AWS features give you the control and flexibility to design solutions that solve real-world problems effectively.
As Alan Kay once said: “The best way to predict the future is to invent it.”
So here’s the takeaway: don’t stop at theory. Try it out. Create your own AMI, set up an automated snapshot routine, and test Multi-Attach in a lab environment. Explore what’s possible, push the limits, and remember—when it comes to the cloud, progress belongs to those who experiment boldly.
Top comments (2)
Great guide! Could you clarify a few points in the EBS Multi-Attach section?
Thank you for your response.
**You can use either io1 or io2, but for this illustration I used io1.
** this wasn't discussed but for a cluster aware storage across multiple EC2s, FSx or EFs are best bet.
** You don't use ext4 for multiple DB nodes sharing the same volumes. It's not cluster aware. You need a cluster aware FS like GFS2.