Recently I have experienced an interesting situation where an AWS Marketplace AMI, specifically Debian 10, blocked me from upgrading the instance type. In this specific case, the situation did not allow me to simply migrate to a newer version of Debian, so I had to find a workaround. This article will explain how I did it.

What was the problem?

So it turns out, AWS Marketplace AMI maintainers can set limitations when it comes to compatibility with instance families and generations. In this specific case, the Debian 10 AMI was not compatible with c6 or c7 instances, so I was stuck on the c5 generation. This is quite unfortunate, because the c5 generation is not the latest one, while it costs the same as the c6 generation. Usually, a newer generation means better performance, so I wanted to upgrade.

The methods I tried

Method 1: Modify the instance type

The most straightforward way of upgrading an instance is just turning it off and changing the instance type. This is what I tried first, but it did not work. The error message was the following:
"The instance configuration for this AWS Marketplace product is not supported. Please see the AWS Marketplace site for more information about supported instance types, regions, and operating systems."

Method 2: Reattach the EBS volume to a new instance

Since an in-place upgrade did not work, I figured I could simply launch a newer instance type from a new AMI, detach its EBS volume, and attach the old EBS volume to the new instance. This resulted in the same error message as before.

This means the EBS volume is tied to the AMI, and sticks to the limitations of the AMI. Now I had to think on how to get around this.

Method 3: Create a new EBS volume from a snapshot

I figured that a restored snapshot might not have this link to the original AMI, because it is a new EBS volume. So I created a snapshot from the old EBS volume, and created a new EBS volume from the snapshot. I tried to attach it to the newer instance, but sadly I still got the same error message... This means the snapshot also has this link to the original AMI.

Method 4: Create a new EBS volume and copy the data

The last method I tried was to create a new EBS volume, and copy the data from the old EBS volume to the new one. This is a bit more complicated, but it worked. Here are the steps I took:

• Create a migration instance, from the same generation as the original instance, for copying the data (you don't want to do this on the original instance, as it might lead to corrupted files or other inconsistencies)
• Create a new EBS volume with the same size as the old one
• Detach the old EBS volume from the original instance
• Attach both the new EBS volume and the old EBS volume to the migration instance
• Connect to the migration instance through the SSM console for example
• Run lsblk to see the device name of the EBS volumes. You should be able to identify them by their size, their partitions and their mountpoints
• Run sudo dd if=/dev/nvme1n1 of=/dev/nvme2n1 bs=1M to copy the data from the old EBS volume to the new one. Replace /dev/nvme1n1 and /dev/nvme2n1 with the device names of the old and new EBS volumes respectively

After this, you can detach the old EBS volume from the migration instance, and attach the new EBS volume to the original instance. You are now able to change the instance type to a newer generation.

You can verify the instance type by checking the kernel log for the DMI information. In my case, the instance type was c6a.large:

admin@ip-10-0-10-11:/var/log$ grep --binary-files=text 'DMI: Amazon' kern.log
Nov 10 07:18:10 ip-10-0-10-11 kernel: [    0.000000] DMI: Amazon EC2 c5a.large/, BIOS 1.0 10/16/2017
Nov 10 07:50:32 ip-10-0-10-11 kernel: [    0.000000] DMI: Amazon EC2 c6a.large/, BIOS 1.0 10/16/2017

Word of caution

The method described above is not without its risks. If you are not careful, you might end up with a corrupted EBS volume, or even worse, a corrupted instance. Here are some things to keep in mind:

• Make sure you have correctly backed up any important data. More specifically, make sure you have a snapshot of the EBS volume
• Make sure you are copying the data from the old EBS volume to the new one, and not the other way around. If you are not careful, you might end up with an empty EBS volume

Other thoughts

Since the AMI used in this article is free, I do not see any issues in using it. However, if you are using any Marketplace AMI, you might want to check the terms and conditions of the AMI before using this method. I am not responsible for any damages caused by using this method.

Conclusion

Overcoming AWS Marketplace AMI limitations, particularly with Debian 10, demanded ingenuity. While direct instance modifications and EBS volume reattachments fell short, a successful method involved creating a new EBS volume and orchestrating a meticulous data copy.

A word of caution: this method carries risks. Safeguard your data with proper backups and ensure meticulous attention to the data copy direction. Remember, the success lies in copying from the old EBS volume to the new one.

In the realm of AWS intricacies, navigating these challenges requires both creativity and caution. Proceed with care, and you might just unlock new possibilities for your instance upgrades.

Remember, each cloud adventure is unique—happy upgrading!