I've had a Linux t1.micro running a small Apache/PHP/Postgresql website for a couple of years now (referred herein as "original instance"). Works like a charm.

I wanted to migrate the site to the new (cheaper) t2.micro instance. I couldn't find any step by step instructions for how to do this, but took note of this and this.

My basic approach was

  1. Create snapshots of the two volumes (root and a data drive for the postgresql data) used by the original instance
  2. Create a new HVM AMI from the root and data snapshots just taken (ELASTIC BLOCK STORE > Snapshots > select original instance root snaphot > Actions > Create Image), with
    • Architecture = x86_64, same as the original instance
    • Root device and data volume device names = same as the original instance
    • Virtualization type = Hardware-assisted virtualization (HVM, for compatibility with the new t2 VM format)
    • Kernel ID = "Use default" (I tried to used the same Kernel ID as the original instance, but the AMI create failed saying it couldn't use that for a HVM AMI)
  3. Create and launch a new instance with the AMI just created at step 2

Problem: upon starting this new instance, it shuts down immediately with a Client.InstanceInitiatedShutdown error. How can I troubleshoot this?

Am I naive to think I can use a root snapshot that works in a PVM environment in an HVM environment? Is there an easier way to migrate from t1 to t2?

I'm hoping not to have to re-build my server in t2 from scratch and migrate data manually (I didn't use any automated build scripts).

Edit: I ended up rebuilding the t2 instance from scratch :P


1 Answer 1


I was going from HVM to PV and noticing the same issue. It turned out that I (my automation) was still attaching block storage to /dev/sda1, what I needed for my HVM AMI, but needed to attached it to /dev/xvda.

  • For me the same thing happens on an LC. For some reason AWS doesn't match mount with AMI when it validates the LC.
    – eco
    Apr 12, 2019 at 18:15
  • I had the same issue on a HVM instance (latest HVM Amazon Linux kernel 5.10) ami-0f9fc25dd2506cf6d. Had to switch from sda1 to xvda, which was easy enough to verify by manually launching and checking the volume device in the console.
    – Akom
    May 2, 2022 at 15:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .