AMIを取得してEC2を再作成したときに引き継がれる設定・再設定が必要な設定（2026年版）

こんにちは、林です。

前回、AWS BackupでEC2を復元したときに設定がどこまで引き継がれるかを確認しました。

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

AWS Backupは復旧ポイントに元のインスタンスの設定を記録していて、復元するときにその設定を適用します。では、AMIを取得して起動し直す場合はどうなるのでしょうか。

AMIからEC2を起動する手順の記事はいくつかありますが、元のインスタンスの設定がどこまで引き継がれるかをまとめたものは見当たりませんでした。

そこで、稼働中のEC2からイメージを作成し、そのAMIで起動し直したときに何が引き継がれるかを、AWS Backupのときと同じ方法で確認してみました。

検証方法

次の手順で、元のインスタンスと再作成したインスタンスの設定を比較しました。

1. 既定値と違う設定を入れたEC2インスタンスを作り、設定を記録する
2. そのインスタンスからAMIを作成する
3. 作成したAMIから2通りで起動する
   • AMIのみ: AMI IDとインスタンスタイプ、サブネットだけ指定する
   • 起動テンプレート: 元のインスタンスからget-launch-template-dataで取り出した設定を起動テンプレートにして起動する
4. 起動した2台の設定を、1で記録した元の設定と比較する

起動テンプレートのパターンは、同じIPアドレスで起動できるかも確認するため、元のインスタンスを終了してから起動しています。

元のインスタンスの設定は以下のとおりです。
再作成後に設定が引き継がれたかどうかを判断できるように、既定値のある項目はどれも既定値とは違う値にしています。

インスタンス

インスタンスメタデータ

ネットワーク

ストレージとタグ

以下の項目は確認対象外としました。

• AMI ID: 作成したAMIのIDになり、元と同じにはならないため
• テナンシー、スポットインスタンス、Dedicated Hosts、ライセンス設定、Elastic Fabric Adapter、Elastic Graphics / Elastic Inference: 特定の用途向けの設定で、今回の構成では使っていないため
• Nitro Enclaves、ネットワーク帯域幅の重み付け: t3では使えないため

検証結果

AMIのみで引き継がれたのは、ストレージの設定とIMDSv2だけでした。
起動テンプレートでは、get-launch-template-dataの出力に含まれる項目が引き継がれました。

項目ごとに分けると次のとおりです。全項目の比較表は記事の最後に載せています。

両方で引き継がれる

• インスタンスメタデータ: IMDSv2（HttpTokens）
• ストレージ: すべて（サイズ、タイプ、IOPS、スループット、暗号化、終了時に削除）

起動テンプレートのみ引き継がれる

• インスタンス: キーペア、IAMインスタンスプロファイル、ユーザーデータ、シャットダウン動作、終了保護、停止保護、詳細モニタリング、EBS最適化、プレイスメントグループ、クレジット仕様、CPUオプション、休止動作、キャパシティ予約、自動復旧
• インスタンスメタデータ: HttpTokens以外（ホップ制限、タグを許可、IPv6エンドポイント）
• ネットワーク: セキュリティグループ、プライベートIPv4アドレス（プライマリ・セカンダリ）、IPv6アドレス、パブリックIPの自動割り当て、ホスト名タイプ、ネットワークインターフェイスの説明
• タグ: インスタンス

両方で引き継がれない

• ネットワーク: 送信元/送信先チェック
• タグ: ボリューム、ネットワークインターフェイス

引き継がれなかった項目は、いずれも既定値に戻っていました。

AMIのみで起動したインスタンスには、VPCのデフォルトのセキュリティグループが設定されていました。

プライベートIPv4アドレスとIPv6アドレスは、元のインスタンスを終了してから起動テンプレートで起動したところ、元と同じアドレスが割り当てられました。元のインスタンスが稼働している間は同じアドレスを使えないため、この2つを引き継ぐには元のインスタンスを先に終了しておく必要があります。

AMIに記録されている情報

AMIのみで引き継がれた項目が少なかったため、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
            }
        }
    ]
}

ブロックデバイスマッピングはルートボリュームの分のみを載せています。

記録されているのは、ブロックデバイスマッピングと、ブートモードやアーキテクチャといったOSの起動に関わる属性です。ブロックデバイスマッピングは、起動時にどのデバイス名にどのようなボリュームをアタッチするかの定義で、スナップショットIDやサイズ、IOPS、暗号化の有無が含まれています。インスタンスの設定に関わるものはImdsSupportだけでした。

ImdsSupportがv2.0のAMIから起動すると、インスタンスはIMDSv2が必須になり、ホップ制限は2になります。AMIのみで起動したインスタンスがIMDSv2必須だったのは、このためです。

起動テンプレートで再作成する手順

1. AMIを作成する

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

--no-rebootを指定しない場合、インスタンスを再起動してからイメージを作成します。

2. 元のインスタンスから設定を取り出す

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

出力をそのままcreate-launch-templateに渡すとエラーになるため、3箇所を書き換えます。

# "ami-09xxxxxxxxxxxxxxx" を手順1で作成したAMIのIDに置き換える
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

書き換えたのは3箇所です。

• ImageId: 元のインスタンスが起動に使ったAMIのIDが設定されているため、作成したAMIのIDに置き換える
• SnapshotId: データボリュームの分が空文字になっているため削除する
• Placement: GroupNameとGroupIdの両方が含まれていて、どちらか一方しか指定できないため、GroupIdを削除する

書き換えずに渡すと、次のエラーになります。

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.

SnapshotIdを削除しても、ボリュームはAMIのスナップショットから作られます。AvailabilityZoneIdはAvailabilityZoneと重複するため、GroupIdと合わせて削除しています。

元のインスタンスを残したまま起動する場合は、IPアドレスが重複しないようにNetworkInterfacesのPrivateIpAddressesとIpv6Addressesも削除します。

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

今回は元のインスタンスを終了してから起動しているため、この2つは残しています。

3. 起動テンプレートを作って起動する

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

出力されたインスタンスIDを控えておき、次のコマンドで設定を確認します。

比較に使ったコマンド

元のインスタンスと再作成したインスタンスで次のコマンドを実行し、出力を比較しました。比較表の括弧内に書いたAPIパラメータ名は、この出力の項目名です。

ID=<インスタンスID>

# インスタンス、インスタンスメタデータ（MetadataOptions）、ネットワーク、インスタンスのタグ
aws ec2 describe-instances --instance-ids $ID

# 終了保護、停止保護、シャットダウン動作、ユーザーデータはdescribe-instancesに含まれないため、属性ごとに取得する
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

# クレジット仕様
aws ec2 describe-instance-credit-specifications --instance-ids $ID

# セカンダリプライベートIPv4アドレス、IPv6アドレス、ネットワークインターフェイスの説明とタグ
aws ec2 describe-network-interfaces --filters Name=attachment.instance-id,Values=$ID

# ストレージ（BlockDeviceMappings）とボリュームのタグ
aws ec2 describe-volumes --filters Name=attachment.instance-id,Values=$ID

まとめ

AMIを取得してEC2を再作成したときに、元のインスタンスの設定が引き継がれるかを確認しました。

• AMIに記録されるのはボリュームの構成とIMDSv2の設定だけで、それ以外のインスタンスの設定は記録されない
• 元のインスタンスからget-launch-template-dataで取り出した設定を起動テンプレートにすれば、元と同じ設定で再作成できる
• 元のインスタンスを終了してから起動すれば、プライベートIPv4アドレスとIPv6アドレスも引き継げる
• 送信元/送信先チェックと、ボリューム・ネットワークインターフェイスのタグは、どちらの方法でも引き継がれない

AWS Backupの復元と比較すると、AMIだけで引き継がれる範囲はストレージとIMDSv2に限られます。AMIからEC2を再作成する手順には、引き継がれない項目を設定し直す手順も入れておく必要があります。

この記事がどなたかの参考になれば幸いです。最後までご覧いただきありがとうございました！

付録：全項目の比較表

○は引き継がれた項目、×は引き継がれなかった項目です。×には再作成後の値を併記しています。

インスタンス

インスタンスメタデータ（MetadataOptions）

ホップ制限の2は、ImdsSupportがv2.0のAMIから起動したときの値です。

ネットワーク

IPアドレスの○は、元のインスタンスを終了してから起動した結果です。

ストレージ（BlockDeviceMappings）

タグ

参考

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/