EC2 AMI Creation Incorrectly Includes Ephemeral Volumes

0

I have an EC2 instance has a root volume (/dev/sda1) and no additional EBS volumes, running Windows. The resulting AMI includes block device mappings for the root volume and 26 ephemeral volumes (xvdca through xvdcz). This occurs with both the AWS CLI and the AWS Management Console. When launching an instance from the created AMI, the instance fails the "Instance reachability check" and is unreachable.

Troubleshooting Steps Taken: Verified that the source instance only has a root volume.

Tried various variations of the aws ec2 create-image command with different --block-device-mappings configurations, including: -Explicitly defining only the root volume. -Explicitly excluding each ephemeral volume using "NoDevice": "true". -Explicitly excluding each ephemeral volume using "NoDevice": "".

Confirmed that the AWS CLI is configured correctly and has the necessary permissions.

Reproduced the issue using the AWS Management Console, confirming it is not a CLI-specific problem. I tried the --block-device-mappings parameter to explicitly define the root volume and exclude the ephemeral volumes. Example Command:

aws ec2 create-image --instance-id i-0d8e10fedd2d16aab --name "AMI-RootOnly-20250504" --block-device-mappings "[{"DeviceName": "/dev/sda1", "Ebs": {"VolumeSize": 500, "VolumeType": "gp2", "DeleteOnTermination": true}}, {"DeviceName": "xvdca", "NoDevice": ""}, {"DeviceName": "xvdb", "NoDevice": ""}, {"DeviceName": "xvdcc", "NoDevice": ""}, {"DeviceName": "xvdcd", "NoDevice": ""}, {"DeviceName": "xvdce", "NoDevice": ""}, {"DeviceName": "xvdf", "NoDevice": ""}, {"DeviceName": "xvdg", "NoDevice": ""}, {"DeviceName": "xvdh", "NoDevice": ""}, {"DeviceName": "xvdi", "NoDevice": ""}, {"DeviceName": "xvdj", "NoDevice": ""}, {"DeviceName": "xvdck", "NoDevice": ""}, {"DeviceName": "xvdcl", "NoDevice": ""}, {"DeviceName": "xvdcm", "NoDevice": ""}, {"DeviceName": "xvdcn", "NoDevice": ""}, {"DeviceName": "xvdco", "NoDevice": ""}, {"DeviceName": "xvdcp", "NoDevice": ""}, {"DeviceName": "xvdcq", "NoDevice": ""}, {"DeviceName": "xvdcr", "NoDevice": ""}, {"DeviceName": "xvdcs", "NoDevice": ""}, {"DeviceName": "xvdct", "NoDevice": ""}, {"DeviceName": "xvdcu", "NoDevice": ""}, {"DeviceName": "xvdcv", "NoDevice": ""}, {"DeviceName": "xvdcw", "NoDevice": ""}, {"DeviceName": "xvdcx", "NoDevice": ""}, {"DeviceName": "xvdcy", "NoDevice": ""}, {"DeviceName": "xvdcz", "NoDevice": ""}]"


Same result, the resulting EC2 instance is unreachable.
asked 12 days ago32 views
1 Answer
0

The issue you're experiencing with the EC2 AMI creation incorrectly including ephemeral volumes is unusual and concerning. Typically, when creating an AMI from an EC2 instance, it should only include the block device mappings for the volumes that are actually attached to the instance. In your case, since you only have a root volume, the AMI should only include that.

The fact that the AMI is including 26 ephemeral volumes (xvdca through xvdcz) suggests there might be an underlying configuration issue with the source instance or a potential bug in the AMI creation process.

Here are some additional troubleshooting steps and suggestions:

  1. Double-check the block device mappings of the source instance: Use the AWS CLI command aws ec2 describe-instances --instance-id your-instance-id to verify that the instance truly only has the root volume attached.

  2. Examine the AMI details: After creating the AMI, use the aws ec2 describe-images --image-id your-ami-id command to inspect the block device mappings of the created AMI. This will help you understand what's actually being included in the AMI.

  3. Try creating the AMI without specifying block device mappings: Instead of explicitly defining the block device mappings, try creating the AMI without any block device mapping parameters. This should, in theory, create an AMI that mirrors the exact configuration of the source instance.

  4. Check for any custom AMI creation scripts or processes: Ensure that there are no custom scripts or processes in your environment that might be interfering with the AMI creation process.

  5. Verify the instance type: Confirm that the instance type you're using doesn't have any special considerations for block device mappings. Some instance types, like M3, have specific requirements for instance store volumes.

  6. Consider creating a new EC2 instance: As a test, you could create a new EC2 instance from a standard Windows AMI, ensure it only has a root volume, and then try creating an AMI from this new instance. This could help isolate whether the issue is specific to your original instance or a more general problem.

  7. Contact AWS Support: If the issue persists after trying these steps, it would be advisable to contact AWS Support. This behavior seems abnormal and could potentially be a bug in the AMI creation process that AWS needs to address.

Remember, when launching instances from your AMI, ensure that you're not specifying any additional block device mappings that could interfere with the instance's ability to boot properly. The "Instance reachability check" failure suggests that the instance is unable to start correctly, which could be related to these unexpected ephemeral volume mappings.

If none of these steps resolve the issue, working directly with AWS Support would be the best course of action to diagnose and resolve this unusual behavior.
Sources
Troubleshoot Amazon EC2 instance launch issues - Amazon Elastic Compute Cloud
Add block device mappings to an AMI - Amazon Elastic Compute Cloud
create-image — AWS CLI 2.27.8 Command Reference

profile picture
answered 12 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions