Virtualization

How to create a new AMI from a snapshot and launch a new VM

Nick Hardiman shows you the steps to taking a snapshot of your Amazon Machine Image and launching a new VM from it to build in redundancy for your service.

I took a factory-fresh AWS micro-instance and loaded a Drupal CMS onto it. Now my EC2 machine is running a customer service, but it is not enterprise-ready - it is not resilient. I copy my original EC2 machine so I have a pair of identical servers. Next I will stick a load balancer between them and the customer.

This process takes the original image, turns it off, takes a snapshot of the EBS volume, makes a new AMI using this snapshot, then launches a new VM from my AMI. If you are used to traditional IT and not AWS IT, you won't recognise those acronyms. They are part of Amazon's new jargon.

AWS jargon

This article contains a fair amount of Amazon-specific acronyms and buzzwords, so here is a mini-glossary as a reminder.

  • AMI (Amazon Machine Image): An EBS volume that contains an Operating System and other bits required to launch instances. My new AMI doesn't have any optional extras, so it is exactly like a physical computer's disk volume, with file system, kernel, applications and everything else needed to boot up (to be pedantic, it's not exactly the same, but most people won't notice any difference).
  • EBS (Elastic Block Storage): One of Amazon's cloud storage infrastructure services. This is where the new AMI is stored. An EBS volume looks like a hard disk drive volume. I could rent many EBS volumes, add files to them and mount them on my instance.
  • EC2 (Elastic Compute Cloud): The collective name for Amazon's cloud computing services for customers.
  • instance: a complete running virtual machine. Every time you launch an AMI, you get to choose its virtual hardware: maybe a Micro computer with the power of a net-top, or perhaps a High Memory Quadruple Extra Large number-crunching monster with a huge price tag, many processing cores and huge memory. I often call an instance a VM or EC2 machine.
  • Root device: The EBS volume used to boot up my new instance.
  • Snapshot: A copy of your EBS volume (i.e., an image of the virtual hard disk drive). AWS will make an AMI from your snapshot with some behind-the-scenes tinkering. If you are used to VMware snapshots, you will find EC2 snapshots are not the same.

Examine the original EC2 machine.

My new EC2 machine must not be in the same area as the original VM, to make sure maintenance doesn't affect both machines at the same time. My new instance must have the same security group as the original VM to avoid unpleasant blockages.

  1. Open the AWS console.
  2. Find the availability zone and make a note of it.
  3. Note the security group.

Take a snapshot and make a new AMI

  1. Find the entry for your original VM. Click the Amazon EC2 tab | set your Region in the drop-down list | Instances link in left navbar.
  2. Right click (or ctrl-click if you live in the pastel world of Mac OSX) the instance name. The Instance Management context menu appears.
  3. Select Create Image (EBS AMI). A Create image window opens. (See Figure A below.)
  4. Enter a name and description. This is for your use, not Amazon's.
  5. Click the Create This Image button. A confirmation message appears. Behind the scenes the original  EC2 machine is switched off, the EBS volume is copied to a snapshot, and the EC2 machine is switched on again.
  6. Close the window. The list of images looks disappointingly unchanged - only the original image is listed.
  7. Press the refresh button. The status check shows a warning about your original EC2 machine because the Instance Reachability Check fails.
  8. Wait a couple minutes, try again and your original EC2 machine is back to normal.
  9. View your original volume, new snapshot, and new AMI. Click Volumes, Snapshots and AMIs links in the left navbar.

Figure A

AWS assigns unique identifiers for pretty much everything: your new AMI is labelled with an identifier along the lines of ami-12345678 and the snapshot gets snap-12345678.

Launch a new instance

The AWS hypervisor takes a copy of the AMI template and adds secret sauce to turn it into a running VM. The secret sauce contains host name, MAC address, IP addresses, billing items and firewall rules.

  1. Find your new AMI. AMIs link in left navbar.
  2. Tick the checkbox. A description of the AMI appears in the lower pane.
  3. Click the Launch button. The Request Instances Wizard opens.
  4. Follow the wizard.
    • The INSTANCE DETAILS boxes come first. Change the availability zone to somewhere away from the original instance. Hit the continue button at the bottom of the window. Enter a name like "second web server" or "cms02".
    • I chose my existing keypair in the CREATE KEY PAIR box. I can SSH to both boxes with the same credentials.
    • I chose the same security group in the CONFIGURE FIREWALL box.
    • I hit the Launch button in the REVIEW box.
  5. If you want more practice, terminate the instance and restart it - that's fine. Use the new AMI image to launch another one. Repetition is good for learning.

Figure B

My Instances (click to enlarge)

If you were only running one free instance before, you are now being billed for renting the second instance.

Figure C

The bill (click to enlarge)

Clean up

If you aren't going to load balance the pair of EC2 machines immediately, there's no point hanging onto your work. It's easy to get to this point again.

  • Terminate the second VM.
  • De-register the AMI.
  • Delete the snapshot.
  • Close the AWS console.

About

Nick Hardiman builds and maintains the infrastructure required to run Internet services. Nick deals with the lower layers of the Internet - the machines, networks, operating systems, and applications. Nick's job stops there, and he hands over to the ...

2 comments
ctmedia
ctmedia

When using this method, does the data on the server remain synced between your two AIM instances? FOr example, if you have DB apps running that change daily, or if you make some server configuration changes will they be applied to both AMIs?

Nick Hardiman
Nick Hardiman

It's like copying the contents of one disk onto another. It's not clever. Keeping many copies of data in sync is an old problem, and many ways round it have appeared over the years. For instance, automated tools can update many servers, one shared file system is mounted on many servers, or a separate database cluster keeps the dynamic stuff off the servers.

Editor's Picks