0

I've scoured Google and the AWS developer forums pretty thoroughly (I think) and can't seem to find an answer.

I'm snapshotting EBS volumes with boto3 daily for DR purposes. Some of the instances using these volumes are t3., some are t2..

I'm able to create an AMI from the snapshots, great! However, when I try to create an image of the same type (namely t3.*), the console is grayed out and says, 'This instance type requires ENA support etc...'.

What's strange is that the instance does support ENA

$ sudo modinfo ixgbevf 
version: 4.1.0-k-rh7.5

When I create an AMI from a t3.* instance via the CLI, the AMI supports ENA and all is well.

The problem, though, is that I'd like to be able to build AMIs from snapshots. Hopefully someone can shed some light on this!

Thank you!

Improve this question
2
  • Can you attach a screenshot with the 'This instance type requires ENA support etc...' message? And maybe steps to reproduce the problem? It's a bit unclear (to me) what exactly are you doing...
    – MLu
    Nov 5, 2018 at 23:16
  • As far as steps go: 1) Launch t3.small instance with an EBS root volume 2) Snapshot the EBS volume of the instance 3) Browse to the snapshot > Actions > Create Image 4) Image created successfully 5) Browse to the AMI you just created 6) Click the AMI and select "Launch" 7) Note that you cannot launch a t3.small Link to error screenshot: imgur.com/bQrr8fL
    – mitch
    Nov 5, 2018 at 23:21

1 Answer 1

Reset to default
0

When you are taking a snapshot of a root volume that runs on t3 you should be able to build an Ami that can be launched on t3.

However when you do the same for a root volume that runs on t2 it should not work on t3. This is because the operating system is not configured to run with ENI on t2, it doesn't matter if it could. There is no step in between snapshot and creating an image where you could reconfigure the OS to solve this problem.

To solve this longer term, one solution is to use a configuration tool like Ansible and rebuild the root volume on t3. This also makes it much easier to upgrade to a newer OS version, say moving from Ubuntu 18.04 to 20.04 when the time comes as again it is a rebuild from scratch. For this to work efficiently you should mount your payload on a separate EBS volume or EFS if you haven't already

Improve this answer
2
  • 2
    I think the problem here is that there's a bit flag on AMIs that indicates whether or not the AMI purportedly supports ENA, and "The AMI inherits the enhanced networking enaSupport attribute from the instance." It's as if building an AMI from an actual instance (rather than assembling from snapshots) is the only way for the attribute to get set -- regardless of whether the OS on the snapshot actually supports ENA.
    – Michael - sqlbot
    Nov 6, 2018 at 10:48
  • 2
    I agree, a snapshot taken from a t3 should create an AMI that can be used for another t3, but that's not the case. What @michael-sqlbot points out is correct in my experience, the AMI doesn't receive the enaSupport attribute unless it's built from a running instance. I was hoping there was another answer to this
    – mitch
    Nov 6, 2018 at 14:39

You must log in to answer this question.

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