AWS EC2 AMIs, Snapshots, and Everything In Between.

Launching an EC2 Instance

Before we can talk about images and snapshots, we need an EC2 instance running. When you go to launch one, the default machine AWS will create is a Linux instance. For practice purposes, go with Red Hat, free tier eligible, T2 micro. One instance, all defaults. Click launch.

Now when you launch, the machine goes into a Pending state first. You cannot do anything at this point. Just wait. In a moment it will move to Running state. That is when it is ready.

Now here is something important that gets asked a lot. Once your instance is running, how do you connect to it?

You have a few options. First is EC2 Instance Connect, which opens a browser-level terminal. Yes, it works. But do not make a habit of using it. It is fine if you are in an emergency and need to quickly check something, but it is not the professional way. Second is Session Manager, which is a separate service entirely, we will cover that later. Third is the SSH client option, which gives you the actual SSH command to connect from your terminal. That is the right way to do it. Use your terminal, use PuTTY, whatever external tool you prefer. That is the approach.

What Is an AMI and Why Should You Care?

An AMI, Amazon Machine Image, is a backup of your EC2 instance. Not just a configuration backup. A full backup, including data, because it contains the volumes.

Here is a very important distinction that keeps coming up in interviews. A Launch Template contains only configuration, the seven steps you fill in when launching an instance, instance type, key pair, security group, and so on. An AMI contains actual data because it holds the volumes.

Now why would you need an AMI in real life? Two common scenarios.

Scenario one: Your team needs to launch EC2 instances that already have certain software installed. Instead of each person installing it manually every single time, you set up one machine, install everything, create an AMI from it, and tell your team to always launch from that AMI. Everyone gets a ready-to-go machine.

Scenario two: You have a machine with a lot of work done on it and you want to make changes, but you are scared those changes might break something. Take an AMI as a backup first. If anything goes wrong, you can restore from it.

Creating an AMI: Step by Step

To create an AMI, go to Actions, then Images, then Create Image.

Give it a meaningful name. If your instance has Tomcat installed, name it something like "Linux-Tomcat-Image". Write a description like "This image has Tomcat installed." This helps your team or future-you understand what is inside without guessing.

Now here are the details that matter:

Reboot Instance option: When you take an image, AWS recommends the EC2 instance should ideally be stopped. This avoids data consistency issues. But in production, you cannot always stop a machine. So AWS gives you the reboot option. If you check it, it will forcefully reboot the instance before taking the image, kicking out anyone who is logged in. If you uncheck it, it will take the image without rebooting. For practice, uncheck it.

Volumes in the image: Ask yourself how many volumes your parent EC2 instance has. If you did a default launch with only a root volume, the answer is one. So your AMI will also contain one volume. Simple relationship: AMI inherits the volumes of the parent instance.

Can you modify volume size while creating an image? Yes, and this is a certification-level point. While creating an AMI, you can increase the volume size. You cannot decrease it because decreasing risks data loss. So if your parent volume is 10 GB, you can make it 20 GB or 100 GB in the image. No problem. But not smaller.

Encryption: If your parent EC2 instance volume is not encrypted, the AMI will also not be encrypted. If the volume was encrypted using KMS (Key Management Service), the image will also be encrypted. By default the key AWS uses is "aws/ebs". This applies similarly for other services: S3 uses "aws/s3", EFS has its own key, RDS has its own. KMS provides a default key per service.

Windows vs Linux: A Billing Point You Should Not Ignore

Your Linux EC2 instance root volume is 10 GB by default. A Windows instance is 30 GB. Why does this matter?

When you copy an AMI from one region to another, AWS charges you for the data transferred. So if you copy a Linux AMI from Mumbai to Ireland, you are transferring 10 GB and getting charged for 10 GB. If you copy a Windows AMI, that is 30 GB of transfer cost. For this reason, stick to Linux for practice when you are doing cross-region AMI work.

Adding Volumes to an Image: EBS vs Instance Store

When creating an AMI, you can add additional volumes beyond the root. Click Add Volume. This is where it gets interesting.

You have two types of volumes to add: EBS volumes and Instance Store volumes.

EBS volumes: You choose the size, maximum is 16 TB. You pick the volume type. Straightforward.

Instance Store volumes: Here is something worth noting. You normally cannot create instance store volumes on your own. They are tied to specific EC2 instance types, and the database creates them automatically when you select a picker instance type. But when creating an AMI, this is one of the very few places in AWS where you can manually add instance store volumes.

How many volumes can you add in total? The maximum is 24. Instance store volumes default to 80 GB each. You can add up to 24 of them. If you launch an EC2 instance from such an image, it will have 24 instance store volumes, each 80 GB. That is 1,920 GB of temporary storage.

Why temporary? Because instance store volumes lose their data when the instance stops. The moment you stop, data is gone. Keep that in mind.

In real life, nobody is adding 24 instance store volumes. But now you know it is possible, and you know where to do it.

AMI Visibility: Public, Private, Owned by Me

When you go to AMIs in your console, you will see filters.

Owned by Me: AMIs you created.

Private Images: This also includes AMIs that someone from another AWS account shared with you.

Public Images: This one surprises people the first time. There are over a thousand public AMIs available. These are shared by AWS, third parties, and the community. You can launch EC2 instances from any of them.

One of our students once came running saying someone had created a thousand images in his account. When we looked together, he had simply clicked on Public Images filter and seen all of them listed. No hack, no problem. Just a misunderstanding.

Should you launch instances from public images? Only if you know and trust the publisher. If the AMI is from a verified provider, fine. Otherwise, be cautious. You do not know what is installed inside.

AMI Actions You Need to Know

Copy AMI: This copies your AMI from one region to another. Select the destination region, click copy. That is it. Remember, this will incur data transfer charges. So be intentional about when you do it.

Disable AMI: When you disable an AMI, nobody can launch a new EC2 instance from it. You use this to tell your team that a particular image is no longer to be used. Disabled and deleted are not the same. Disabled still exists, just not launchable.

Deprecate AMI: You can set a future deprecation date on an AMI to signal it is outdated. After that date, the AMI still works and you can still launch from it, but it is flagged as not recommended. To be honest, in real practice, people either use an AMI or delete it. Deprecation is rarely used. Think of it like expired medicine sitting in your first aid box. You know it is expired, it might still work, but ideally you should have thrown it out. Best practice: just disable or delete it.

Share AMI: You can share your AMI with another AWS account. Go to Actions, Modify Permissions, and add the account ID of the account you want to share with. The recipient will see it under their Private Images filter.

What About Instance-Store Backed AMIs?

Everything we have discussed so far is EBS-backed. That is what you will use in real life.

But there is also something called Instance-Store Backed AMIs. The process for creating one is not done through the console directly. You would need to use the CLI. The flow is: take your instance, bundle it using CLI commands, upload that bundle to an S3 bucket, and then register it from S3 as an AMI. It is indirect and more involved. We will cover this as a hands-on CLI task later. For now, you just need to know it exists and it requires CLI, not the console.

Snapshots: The Sibling of AMIs

Every time you create an AMI, AWS automatically creates a snapshot alongside it. A snapshot is a backup of a volume.

If you create two AMIs, how many snapshots do you get? Two. One snapshot per AMI.

Now think about what those snapshots contain. Your AMI was created from your EC2 instance. That instance had a root volume with the operating system on it. The snapshot is a copy of that root volume. So the snapshot also contains the OS.

Since the snapshot has the OS, can you create an AMI directly from a snapshot? Yes. In Snapshots, select your snapshot, go to Actions, and click Create Image from Snapshot. Give it a name, description, and you can also modify volume size here or add additional volumes. Then create. Done.

Also, just like AMIs, you can copy a snapshot from one region to another. And during that copy process, you can choose to encrypt the snapshot even if the original was not encrypted. This is one of the ways to retroactively encrypt your backup data.

You can also share snapshots with other accounts, the same concept as sharing AMIs.

The Recycle Bin: Your Safety Net

By default, the Recycle Bin in AWS is disabled. You have to set it up.

Here is why it matters. Imagine your team deletes an AMI by accident. Without Recycle Bin enabled, that is gone permanently. With Recycle Bin, deleted AMIs and snapshots go into the bin first and stay there for however long your retention rule says.

To use it, you create a retention rule in the Recycle Bin service. For example, keep deleted resources for 7 days. Then if someone deletes an AMI, go to Recycle Bin, find the resource, select it, and click Recover. It comes back.

One thing to keep in mind: the data sitting in your Recycle Bin is still being stored, and that storage is billable. So do not set a retention period of 365 days for hundreds of large AMIs unless you are prepared for that cost. Use it thoughtfully.

Volumes: Quick Note

Volumes are the actual storage attached to your EC2 instance. Your running instance has one root volume. The AMIs hold snapshots of those volumes. We will go into creating and managing volumes in detail in the next session. But just so the mental model is clear:

One EC2 instance running, with one root volume, means there is one volume visible under Volumes in your console. The AMIs and snapshots are separate entities, copies, not the live volume itself.

A Quick Summary Before You Practice

Here is everything we covered, all connected:

You launch an EC2 instance. It gets a root volume. You create an AMI from it, which takes a snapshot of that volume automatically. The AMI can be copied to another region, shared with another account, or used to launch new EC2 instances that already have everything set up. You can disable an AMI to prevent new launches from it. You can deprecate it to mark it as outdated. You can delete it, and if Recycle Bin is configured, you can recover it.

Snapshots can be created independently, copied across regions, encrypted during copy, and used to create new AMIs.

Instance store volumes can be added during AMI creation, up to 24 of them, but their data is temporary.

EBS volumes persist. Instance store volumes do not.