This is not the best or perfect way, however this works for me and I was asked to share. This is going to be my first post. The AMI I am using is Instance Store backed. You could use the same for EBS backed AMI though I have not tried.
Let’s assume you are creating the original AMI in US-East and you want to put a copy in US-WEST.
- When you create AMI simply upload bundle to US-WEST bucket as well.
- Proceed to register AMI in US-East to ensure it works there. If it already works then try to register in US-WEST.
- You can at this point simply register the AMI from the bucket Manifest URL or it will fail complaining about Kernel.
- When this happens you need to fix the kernel-id. The rest of the steps are only done on the Target region US-West.
- In US-West you will find the OS of your choice in the publicly avalable AMIs and then proceed launch it. However you don’t need to start an instance.
- Assuming you used the AWS web console, in the following screens you can see a dropdown list of Kernel ID. Simply select the dropdown list and choose one.
- For e.g. my original AMI is based on CentOS 5.5 so in US-West I looked for CentOS5.5 and found a kernel ID.
- Note down a bunch of kernel ID from the list.Ã‚Â the kernel ids start with aki-xxxx
- Go to the US-West S3 bucket where you uploaded the AMI bundle files you wanted to migrate and find the xxxx-Manifest.xml. Download and open it in an editor of your choice.
- Let us fix our AMI’s xxxx-Manifest.xml. Look for the section of XML about machine configuration. Something like this…
[prettify] x86_64 ami /dev/sda1 root /dev/sda1 aki-9ba0f1de [/prettify] You will note there is a kernel_id element there. So edit it and replace the kernel id with the one we got in US-WEST.
- Remember to make a copy of the original Manifest.xml in case you make a mistake. Save it somewhere for future reference or rename the manifest.xml name if you are saving in the same bucket as the orignal manifest to avoid confusion.
- Upload your edited xxxx-Manifest.xml back to your AMI bucket replacing the one that is already there.
- Try to register the AMI again. If that fails try another kernel-id following the same process as above
That’s about it. Pretty simple and straightforward. I am sure Tech team at AWS are working on a better solution for this.