Settings That Are Carried Over and Settings That Need to Be Reconfigured When Creating an EC2 Instance from an AMI (2026 Edition)

Hello, this is Hayashi.

Last time, I checked how many settings are carried over when restoring an EC2 instance with AWS Backup.

https://dev.classmethod.jp/articles/202609-aws-backup-ec2-restore-settings-check/

AWS Backup records the original instance's settings in the recovery point and applies them when restoring. So what happens when you create an AMI and relaunch from it?

There are several articles on the procedure for launching EC2 from an AMI, but I couldn't find one that summarizes how many of the original instance's settings are carried over.

So I tried creating an image from a running EC2, relaunching from that AMI, and checking what gets carried over, using the same method as with AWS Backup.

Verification Method

I compared the settings between the original instance and the recreated instance using the following steps.

1. Create an EC2 instance with settings different from the defaults and record the settings
2. Create an AMI from that instance
3. Launch from the created AMI in two ways
   • AMI only: Specify only the AMI ID, instance type, and subnet
   • Launch template: Extract settings from the original instance using get-launch-template-data, create a launch template, and launch from it
4. Compare the settings of the two launched instances with the original settings recorded in step 1

For the launch template pattern, I also checked whether it could launch with the same IP address, so I terminated the original instance before launching.

The settings of the original instance are as follows.
To be able to determine whether settings were carried over after recreation, all items with defaults were set to values different from the defaults.

Instance

Instance Metadata

Network

Storage and Tags

The following items were excluded from verification.

• AMI ID: It becomes the ID of the created AMI and cannot be the same as the original
• Tenancy, Spot instances, Dedicated Hosts, License configuration, Elastic Fabric Adapter, Elastic Graphics / Elastic Inference: Settings for specific use cases not used in this configuration
• Nitro Enclaves, Network bandwidth weighting: Cannot be used with t3

Verification Results

With AMI only, only storage settings and IMDSv2 were carried over.
With the launch template, items included in the get-launch-template-data output were carried over.

Breaking it down by item:. The comparison table for all items is at the end of the article.

Carried over with both

• Instance metadata: IMDSv2 (HttpTokens)
• Storage: All (size, type, IOPS, throughput, encryption, delete on termination)

Carried over with launch template only

• Instance: Key pair, IAM instance profile, user data, shutdown behavior, termination protection, stop protection, detailed monitoring, EBS optimized, placement group, credit specification, CPU options, hibernation behavior, capacity reservation, auto recovery
• Instance metadata: Items other than HttpTokens (hop limit, allow tags, IPv6 endpoint)
• Network: Security group, private IPv4 address (primary/secondary), IPv6 address, auto-assign public IP, hostname type, network interface description
• Tags: Instance

Not carried over with either

• Network: Source/destination check
• Tags: Volume, network interface

Items that were not carried over all reverted to their default values.

The instance launched with AMI only had the VPC's default security group configured.

For the private IPv4 address and IPv6 address, after terminating the original instance and launching with the launch template, the same addresses as the original were assigned. Since the same addresses cannot be used while the original instance is running, these two require terminating the original instance first.

Information Recorded in the AMI

Since few items were carried over with AMI only, I checked what is recorded in the AMI.

aws ec2 describe-images --image-ids ami-09xxxxxxxxxxxxxxx

{
    "BootMode": "uefi",
    "ImdsSupport": "v2.0",
    "EnaSupport": true,
    "Architecture": "x86_64",
    "Platform": "windows",
    "SourceInstanceId": "i-07xxxxxxxxxxxxxxx",
    "SourceImageId": "ami-07xxxxxxxxxxxxxxx",
    "BlockDeviceMappings": [
        {
            "DeviceName": "/dev/sda1",
            "Ebs": {
                "DeleteOnTermination": true,
                "Iops": 4000,
                "SnapshotId": "snap-0bxxxxxxxxxxxxxxx",
                "VolumeSize": 160,
                "VolumeType": "gp3",
                "Throughput": 250,
                "Encrypted": true
            }
        }
    ]
}

Only the root volume's block device mapping is shown here.

What is recorded is the block device mappings and OS boot-related attributes such as boot mode and architecture. The block device mappings are definitions of which volumes to attach to which device names at launch, and include snapshot IDs, sizes, IOPS, and encryption status. The only item related to instance settings was ImdsSupport.

When launching from an AMI with ImdsSupport set to v2.0, the instance will have IMDSv2 required and the hop limit will be 2. This is why the instance launched with AMI only had IMDSv2 required.

Procedure for Recreating with a Launch Template

1. Create an AMI

aws ec2 create-image \
  --instance-id i-07xxxxxxxxxxxxxxx \
  --name sample-image \
  --description "image of sample-sv"

If --no-reboot is not specified, the instance will be rebooted before creating the image.

2. Extract Settings from the Original Instance

aws ec2 get-launch-template-data \
  --instance-id i-07xxxxxxxxxxxxxxx \
  --query 'LaunchTemplateData' --output json > ltdata.json

Since passing the output directly to create-launch-template results in an error, modify three places.

# Replace "ami-09xxxxxxxxxxxxxxx" with the AMI ID created in step 1
jq --arg ami "ami-09xxxxxxxxxxxxxxx" '
  .ImageId = $ami
  | .BlockDeviceMappings |= map(.Ebs |= del(.SnapshotId))
  | .Placement |= del(.GroupId, .AvailabilityZoneId)
' ltdata.json > tmp.json && mv tmp.json ltdata.json

Three places were modified.

• ImageId: It contains the ID of the AMI used to launch the original instance, so replace it with the ID of the created AMI
• SnapshotId: The data volume entry is an empty string, so delete it
• Placement: Both GroupName and GroupId are included, but only one can be specified, so delete GroupId

If passed without modification, the following errors occur.

The snapshot ID '' is not valid. The expected format is snap-xxxxxxxx or snap-xxxxxxxxxxxxxxxxx.
You cannot specify a value for GroupId and GroupName in the same request.

Even if SnapshotId is deleted, the volume will be created from the AMI's snapshot. AvailabilityZoneId is redundant with AvailabilityZone, so it is deleted along with GroupId.

If launching while keeping the original instance, also delete PrivateIpAddresses and Ipv6Addresses from NetworkInterfaces to avoid IP address conflicts.

jq '.NetworkInterfaces |= map(del(.PrivateIpAddresses, .Ipv6Addresses))' \
  ltdata.json > tmp.json && mv tmp.json ltdata.json

Since I terminated the original instance before launching this time, these two are left in.

3. Create a Launch Template and Launch

aws ec2 create-launch-template \
  --launch-template-name sample-lt-from-instance \
  --launch-template-data file://ltdata.json \
  --query 'LaunchTemplate.LaunchTemplateId' --output text

aws ec2 run-instances \
  --launch-template LaunchTemplateId=lt-0dxxxxxxxxxxxxxxx \
  --query 'Instances[0].InstanceId' --output text

Note the output instance ID and check the settings with the following command.

Commands Used for Comparison

I ran the following commands on both the original instance and the recreated instance, and compared the outputs. The API parameter names in parentheses in the comparison table correspond to items in this output.

ID=<instance ID>

# Instance, instance metadata (MetadataOptions), network, instance tags
aws ec2 describe-instances --instance-ids $ID

# Termination protection, stop protection, shutdown behavior, and user data are not included in describe-instances, so retrieve them per attribute
aws ec2 describe-instance-attribute --instance-id $ID --attribute disableApiTermination
aws ec2 describe-instance-attribute --instance-id $ID --attribute disableApiStop
aws ec2 describe-instance-attribute --instance-id $ID --attribute instanceInitiatedShutdownBehavior
aws ec2 describe-instance-attribute --instance-id $ID --attribute userData

# Credit specification
aws ec2 describe-instance-credit-specifications --instance-ids $ID

# Secondary private IPv4 addresses, IPv6 addresses, network interface description and tags
aws ec2 describe-network-interfaces --filters Name=attachment.instance-id,Values=$ID

# Storage (BlockDeviceMappings) and volume tags
aws ec2 describe-volumes --filters Name=attachment.instance-id,Values=$ID

Summary

I verified which settings of the original instance are carried over when recreating an EC2 from an AMI.

• Only the volume configuration and IMDSv2 settings are recorded in the AMI; other instance settings are not recorded
• By using get-launch-template-data to extract settings from the original instance as a launch template, you can recreate with the same settings
• If you terminate the original instance before launching, the private IPv4 address and IPv6 address can also be carried over
• Source/destination check and volume/network interface tags are not carried over by either method

Compared to AWS Backup restoration, the range carried over by AMI alone is limited to storage and IMDSv2. The procedure for recreating an EC2 from an AMI needs to include steps to reconfigure items that are not carried over.

I hope this article is helpful to someone. Thank you for reading to the end!

Appendix: Comparison Table for All Items

○ indicates items that were carried over, × indicates items that were not. × entries also show the value after recreation.

Instance

Instance Metadata (MetadataOptions)

The hop limit of 2 is the value when launching from an AMI with ImdsSupport set to v2.0.

Network

The ○ for IP addresses is the result of launching after terminating the original instance.

Storage (BlockDeviceMappings)

Tags

References

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instance-block-device-mapping.html

https://docs.aws.amazon.com/cli/latest/reference/ec2/create-image.html

https://docs.aws.amazon.com/cli/latest/reference/ec2/get-launch-template-data.html

https://dev.classmethod.jp/articles/202609-aws-backup-ec2-restore-settings-check/