1
votes

I have created an AMI from a current Linux EC2 instance. There is an EBS attached to the original EC2. When the AMI was created, how does that treat the EBS? I am worried about losing data.

I am attempting to implement Blue/Green deployment for our dev/test/prod environments. We have a current & stable Linux-EC2 instance in test that hosts our application. I created an AMI from that instance so that I could create a second EC2. This would save time and prevent having to reconfigure everything. Everything seemed to work fine.

I now have to do this for our prod environment. I was made aware that there is an EBS instance attached to the current EC2 instance, just as in test. We are worried that when we make an AMI of the prod EC2, there might be some sort of disconnect between the AMI and the EBS.

I have some decent knowledge in AWS service, but I am far from being an pro. I would like to ask any AWS experts out there... do I have anything to worry about? How does creating an AMI instance of a current EC2 affect the attached components/services such as an EBS?

Again, the main worry is about losing data. We don't want our end users in prod to lose data by us assuming that our EBS will transition smoothly to the newly cloned AMI and any EC2 we create from that AMI.

Thanks in advance!

1

1 Answers

2
votes

An AMI consists of a snapshot (or snapshots) of the EBS volume (or volumes) plus a small amount of configuration metadata. What you do with an AMI, later, has no impact whatsoever on the instance that served as the source of that AMI or its EBS volumes.

You can use the AMI to create new instances, and when you do that, new EBS volumes are created for the new instances from the AMI's associated snapshots, and they have no relationship to/no connection with the original EBS volume(s) that were used when making the snapshots. Any given EBS volume is only ever attached to a single instance at a time.

You can also delete the AMI with no impact to the source instance and no impact to any instances launched from that AMI. Of course if you delete an AMI you can't use it to launch any new instances, but once an instance is launched from an AMI the instance has no further need of that source AMI.

There is essentially nothing to worry about.

The only real concern is that when you create an AMI, the only guaranteed way for that AMI to be a pristine clone of the source instance is not to select the "no reboot" option. AMIs created with "no reboot" selected are usually fine, but machines you create with such an AMI will power up with a hard drive that looks like a machine that had power suddenly pulled, and will have to clean up the filesystem. So, it's best to let the system reboot your source machine when creating an AMI. In production, that could be a concern to be mindful of... but the source instance will not be disturbed, otherwise.