# インスタンスメタデータを使用して EC2 インスタンスを管理する
*インスタンスメタデータ*はインスタンスに関するデータで、実行中のインスタンスを設定または管理するために使用します。インスタンスメタデータには以下が含まれます。
**インスタンスメタデータのプロパティ**
インスタンスメタデータのプロパティはホスト名、イベント、およびセキュリティグループなどで[カテゴリ](#instancedata-data-categories)分けされます。
**動的データ**
動的データはインスタンスアイデンティティドキュメントなど、インスタンスの起動時に生成されるメタデータです。詳細については「[動的データのカテゴリ](#dynamic-data-categories)」を参照してください。
**ユーザーデータ**
インスタンスメタデータを使用して、インスタンスの起動時に指定した*ユーザーデータ*にアクセスすることもできます。例えば、インスタンスを設定するためにパラメータを指定したり、単純なスクリプトを含めたりすることができます。汎用 AMI を構築し、ユーザーデータを使用して起動時に提供された設定ファイルを変更することができます。例えば、さまざまな小規模ビジネスを対象としたウェブサーバーを実行する場合に、すべてのサーバーで同じ汎用 AMI を使用し、起動時にユーザーデータで指定した Amazon S3 バケットからコンテンツを取得できます。随時新規顧客を追加するには顧客のバケットを作成し、そのコンテンツを追加し、ユーザーデータのコードに提供された固有のバケット名を使って AMI を起動します。同じ `RunInstances` 呼び出しを使用して複数のインスタンスを起動する場合、ユーザーデータはその予約においてすべてのインスタンスで使用可能です。同じリザベーションの一部である各インスタンスには固有の `ami-launch-index` 番号があるため、インスタンスが実行する操作を制御するコードを書くことができます。例えば、最初のホストはクラスター内の最初のノードとしてそれ自体を選択する場合があります。詳細な AMI 起動の例については「[1 つのリクエストで起動された各インスタンスを特定する](AMI-launch-index-examples.md)」を参照してください。
**重要**
インスタンスメタデータおよびユーザーデータにはそのインスタンス自体内からのみアクセスできるものの、データは認証または暗号化手法によって保護されていません。インスタンス、そしてインスタンス上で実行される任意のソフトウェアに対して直接アクセス権がある可能性がある人はメタデータを表示できます。そのため、パスワードまたは存続期間の長い暗号化キーなどの機密データはユーザーデータとして保管しないようにしてください。
**Topics**
+ [
## インスタンスメタデータのカテゴリ
](#instancedata-data-categories)
+ [
## 動的データのカテゴリ
](#dynamic-data-categories)
+ [
# EC2 インスタンスのインスタンスメタデータにアクセスする
](instancedata-data-retrieval.md)
+ [
# インスタンスメタデータサービスのオプションを設定する
](configuring-instance-metadata-options.md)
+ [
# ユーザーデータ入力を使用して EC2 インスタンスを起動するときにコマンドを実行する
](user-data.md)
+ [
# 1 つのリクエストで起動された各インスタンスを特定する
](AMI-launch-index-examples.md)
## インスタンスメタデータのカテゴリ
インスタンスメタデータプロパティはいくつかのカテゴリに分けられます。インスタンスメタデータのプロパティを取得するにはリクエストでカテゴリを指定します。すると、メタデータがレスポンスで返されます。
新しいカテゴリがリリースされると、新しいインスタンスメタデータビルドが新しいバージョン番号で作成されます。次の表では**[Version when category was released]** (カテゴリがリリースされたときのバージョン) 列が、インスタンスメタデータカテゴリがリリースされたときのビルドバージョンを指定しています。Amazon EC2 が新しいインスタンスメタデータビルドをリリースするたびにコードを更新する必要をなくすために、メタデータリクエストのバージョン番号の代わりに、`latest` を使用することが推奨されます。詳細については[使用できるインスタンスメタデータのバージョンを取得する](configuring-instance-metadata-service.md#instance-metadata-ex-1) を参照してください。
Amazon EC2 が新しいインスタンスメタデータカテゴリをリリースすると、新しいカテゴリのインスタンスメタデータが既存のインスタンスで使用できなくなる場合があります。[Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)では起動時に用意されたカテゴリのインスタンスメタデータのみが取得可能です。Xen ハイパーバイザーを使用するインスタンスの場合は[一度停止した後に開始](Stop_Start.md)することで、そのインスタンスで使用可能なカテゴリを更新できます。
次の表はインスタンスメタデータのカテゴリをまとめたものです。カテゴリ名のいくつかにはインスタンスに固有のデータのためのプレースホルダーが含まれています。例えば、*mac* はネットワークインターフェイスの MAC アドレスを表します。インスタンスメタデータを取得する際にはプレースホルダーを実際の値に置き換える必要があります。
| Category | 説明 | カテゴリがリリースされたときのバージョン |
| --- | --- | --- |
| ami-id | インスタンスの起動に使用される AMI ID。 | 1.0 |
| ami-launch-index | 同じ RunInstances 呼び出しを使用して複数のインスタンスを起動する場合、この値は各インスタンスの起動順序を示します。最初に起動されたインスタンスの値は 0 です。Auto Scaling または EC2 フリートを使用してインスタンスを起動する場合、この値は常に 0 です。 | 1.0 |
| ami-manifest-path | Amazon S3 での AMI のマニフェストファイルのパス。Amazon EBS-backed AMI を使用してインスタンスを起動した場合、返される結果は unknown です。 | 1.0 |
| ancestor-ami-ids | この AMI を作成するために再バンドルされたあらゆるインスタンスの AMI ID。この値はAMI マニフェストファイルが ancestor-amis キーを含む場合にのみ存在します。 | 2007-10-10 |
| autoscaling/target-lifecycle-state | Auto Scaling インスタンスの移行先となる、ターゲットの Auto Scaling ライフサイクルの状態を示す値。2022 年 3 月 10 日以降、インスタンスがターゲットのライフサイクル状態の 1 つに移行したときに表示されます。使用できる値: `Detached`\$1`InService`\$1`Standby`\$1`Terminated`\$1`Warmed:Hibernated`\$1`Warmed:Running`\$1`Warmed:Stopped`\$1`Warmed:Terminated` 「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[インスタンスメタデータを使用してターゲットライフサイクル状態を取得する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/retrieving-target-lifecycle-state-through-imds.html)」を参照してください。 | 2021-07-15 |
| block-device-mapping/ami | root/boot ファイルシステムを含む仮想デバイス。 | 2007-12-15 |
| block-device-mapping/ebsN | 任意の Amazon EBS ボリュームに関連付けられた仮想デバイス。Amazon EBS ボリュームは起動の時点、またはインスタンスが最後に開始された時点で存在している場合にのみ、メタデータで使用できます。N はAmazon EBS ボリュームのインデックス (ebs1 や ebs2 など) を示します。 | 2007-12-15 |
| block-device-mapping/ephemeralN | 非 NVMe インスタンスストアボリュームの仮想デバイス。N は各ボリュームのインデックスを示します。ブロックデバイスマッピングのインスタンスストアボリュームの数はインスタンスのインスタンスストアボリュームの実際の数に一致しない場合があります。インスタンスに使用可能なインスタンスストアボリュームの数はインスタンスタイプによって決定されます。ブロックデバイスマッピングのインスタンスストアボリュームの数が、インスタンスに利用可能な数を超える場合、追加のインスタンスストアボリュームは無視されます。 | 2007-12-15 |
| block-device-mapping/root | ルートデバイスに関連付けられた仮想デバイスまたはパーティション、あるいは仮想デバイス上のパーティション。ルート (/ または C:) ファイルシステムは所定のインスタンスに関連付けられています。 | 2007-12-15 |
| block-device-mapping/swap | swap に関連付けられた仮想デバイス。存在しない場合もあります。 | 2007-12-15 |
| events/maintenance/history | インスタンスの完了またはキャンセルされたメンテナンスイベントがある場合はイベントに関する情報を含む JSON 文字列を含みます。 | 2018-08-17 |
| events/maintenance/scheduled | インスタンスがアクティブなメンテナンスイベントがある場合はイベントに関する情報を含む JSON 文字列を含みます。詳細については[Amazon EC2 インスタンスに影響する予定されているイベントの表示](viewing_scheduled_events.md)を参照してください。 | 2018-08-17 |
| events/recommendations/rebalance | EC2 インスタンスの再調整推奨通知がインスタンスに対して送信されるおおよその時間 (UTC)。このカテゴリのメタデータの例を次に示します。\$1"noticeTime": "2020-11-05T08:22:00Z"\$1このカテゴリは通知が発された後にのみ使用できます。詳細については「[EC2 インスタンスの再調整に関する推奨事項](rebalance-recommendations.md)」を参照してください。 | 2020-10-27 |
| hostname | EC2 インスタンスが IP ベースの命名 (IPBN) を使用している場合、これはインスタンスのプライベート IPv4 DNS ホスト名です。EC2 インスタンスがリソースベースの命名 (RBN) を使用している場合、これは RBN です。複数のネットワークインターフェイスが存在する場合、これは eth0 デバイス (デバイス番号が 0 のデバイス) を示します。IPBN と RBN の詳細については[EC2 インスタンスのホスト名とドメイン](ec2-instance-naming.md)を参照してください。 | 1.0 |
| iam/info | インスタンスに関連付けられた IAM ロールがある場合、インスタンスの LastUpdated の日付、InstanceProfileArn、InstanceProfileId など、インスタンスプロファイルが更新された最終時刻に関する情報が格納されます。そうでない場合はなしになります。 | 2012-01-12 |
| iam/security-credentials/role-name | インスタンスに関連付けられた IAM ロールがある場合、role-name はロールの名前になり、role-name に、そのロールに関連付けられた一時的なセキュリティ認証情報が格納されます (詳細については[インスタンスメタデータからのセキュリティ認証情報の取得](instance-metadata-security-credentials.md)を参照してください)。そうでない場合はなしになります。 | 2012-01-12 |
| identity-credentials/ec2/info | identity-credentials/ec2/security-credentials/ec2-instance の認証情報に関する情報。 | 2018-05-23 |
| identity-credentials/ec2/security-credentials/ec2-instance | インスタンス上のソフトウェアが自身を AWS に識別し、EC2 Instance Connect や AWS Systems Manager デフォルトのホスト管理設定などの機能をサポートできるようにするインスタンスアイデンティティロール用の認証情報。これらの認証情報にはポリシーがアタッチされていないため、AWS 機能に対してインスタンスを識別する以外に追加の AWS API 許可はありません。詳細については「[Amazon EC2 インスタンスのインスタンスアイデンティティロール](iam-roles-for-amazon-ec2.md#ec2-instance-identity-roles)」を参照してください。 | 2018-05-23 |
| instance-action | バンドルの準備のために再起動する必要があることをインスタンスに伝えます。有効な値: none \$1 shutdown \$1 bundle-pending。 | 2008-09-01 |
| instance-id | このインスタンスの ID。 | 1.0 |
| instance-life-cycle | このインスタンスの購入オプション。詳細については[Amazon EC2 の請求および購入オプション](instance-purchasing-options.md)を参照してください。 | 2019-10-01 |
| instance-type | インスタンスの種類。詳細については[Amazon EC2 インスタンスタイプ](instance-types.md)を参照してください。 | 2007-08-29 |
| ipv6 | インスタンスの IPv6 アドレス。複数のネットワークインターフェイスが存在する場合、これは eth0 デバイス (デバイス番号が 0 のデバイス) のネットワークインターフェイスおよび最初に割り当てられた IPv6 アドレスを示します。ネットワークインターフェイス [0] に IPv6 アドレスが存在しない場合、この項目は設定されず、HTTP 404 応答が返されます。 | 2021-01-03 |
| kernel-id | このインスタンスで起動したカーネルの ID (ある場合)。 | 2008-02-01 |
| local-hostname | 複数のネットワークインターフェイスが存在する場合、これは eth0 デバイス (デバイス番号が 0 のデバイス) を示します。EC2 インスタンスが IP ベースの命名 (IPBN) を使用している場合、これはインスタンスのプライベート IPv4 DNS ホスト名です。EC2 インスタンスがリソースベースの命名 (RBN) を使用している場合、これは RBN です。IPBN、RBN、および EC2 インスタンスの命名の詳細については[EC2 インスタンスのホスト名とドメイン](ec2-instance-naming.md)を参照してください。 | 2007-01-19 |
| local-ipv4 | インスタンスのプライベート IPv4 アドレス。複数のネットワークインターフェイスが存在する場合、これは eth0 デバイス (デバイス番号が 0 のデバイス) を示します。これが IPv6 専用インスタンスの場合、この項目は設定されず、HTTP 404 応答が返されます。 | 1.0 |
| mac | インスタンスのメディアアクセスコントロール (MAC) アドレス。複数のネットワークインターフェイスが存在する場合、これは eth0 デバイス (デバイス番号が 0 のデバイス) を示します。 | 2011-01-01 |
| metrics/vhostmd | 使用不可 | 2011-05-01 |
| network/interfaces/macs/mac/device-number | そのインターフェイスに関連付けられた固有のデバイス番号。デバイス番号はデバイス名に対応します。例えば、2 という device-number は eth2 デバイスを指します。このカテゴリはAmazon EC2 API で使用される DeviceIndex フィールドと device-index フィールド、および AWS CLI の EC2 コマンドに対応します。 | 2011-01-01 |
| network/interfaces/macs/mac/interface-id | ネットワークインターフェイスの ID。 | 2011-01-01 |
| network/interfaces/macs/mac/ipv4-associations/public-ip | 各パブリック IP アドレスに関連付けられ、そのインターフェイスに割り当てられたプライベート IPv4 アドレス。 | 2011-01-01 |
| network/interfaces/macs/mac/ipv6s | インターフェイスに割り当てられた IPv6 アドレス。 | 2016-06-30 |
| network/interfaces/macs/mac/ipv6-prefix | ネットワークインターフェイスに割り当てられた IPv6 プレフィクス。 | |
| network/interfaces/macs/mac/local-hostname | インスタンスのプライベート IPv4 DNS ホスト名。複数のネットワークインターフェイスが存在する場合、これは eth0 デバイス (デバイス番号が 0 のデバイス) を示します。これが IPv6 専用インスタンスの場合、これはリソースベースの名前です。IPBN と RBN の詳細については[EC2 インスタンスのホスト名とドメイン](ec2-instance-naming.md)を参照してください。 | 2007-01-19 |
| network/interfaces/macs/mac/local-ipv4s | インターフェイスに関連付けられたプライベート IPv4 アドレス。これが IPv6 専用のネットワークインターフェイスである場合、この項目は設定されず、HTTP 404 応答が返されます。 | 2011-01-01 |
| network/interfaces/macs/mac/mac | インスタンスの MAC アドレス。 | 2011-01-01 |
| network/interfaces/macs/mac/network-card | ネットワークカードのインデックス。インスタンスタイプによっては複数のネットワークカードがサポートされているものもあります。 | 2020 年 11 月 1 日 |
| network/interfaces/macs/mac/owner-id | ネットワークインターフェイスの所有者の ID。複数インターフェイスの環境ではインターフェイスは Elastic Load Balancing などのサードパーティによってアタッチできます。インターフェイス上のトラフィックは常にインターフェイス所有者に対して課金されます。 | 2011-01-01 |
| network/interfaces/macs/mac/public-hostname | インターフェイスのパブリック DNS (IPv4)。このカテゴリはenableDnsHostnames 属性が true に設定されている場合にのみ返されます。詳細についてはAmazon VPC ユーザーガイドの「[DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html)」(VPC の DNS 属性) を参照してください。インスタンスにパブリック IPv6 アドレスのみがあり、パブリック IPv4 アドレスがない場合、この項目は設定されず、HTTP 404 応答が返されます。 | 2011-01-01 |
| network/interfaces/macs/mac/public-ipv4s | インターフェイスに関連付けられたパブリック IP アドレスまたは Elastic IP アドレス。インスタンスには複数の IPv4 アドレスが存在する場合があります。 | 2011-01-01 |
| network/interfaces/macs/mac/security-groups | ネットワークインターフェイスが属するセキュリティグループ。 | 2011-01-01 |
| network/interfaces/macs/mac/security-group-ids | ネットワークインターフェイスが属するセキュリティグループの ID。 | 2011-01-01 |
| network/interfaces/macs/mac/subnet-id | インターフェイスが存在するサブネットの ID。 | 2011-01-01 |
| network/interfaces/macs/mac/subnet-ipv4-cidr-block | インターフェイスが存在するサブネットの IPv4 CIDR ブロック。 | 2011-01-01 |
| network/interfaces/macs/mac/subnet-ipv6-cidr-blocks | インターフェイスが存在するサブネットの IPv6 CIDR ブロック。 | 2016-06-30 |
| network/interfaces/macs/mac/vpc-id | インターフェイスが存在する VPC の ID。 | 2011-01-01 |
| network/interfaces/macs/mac/vpc-ipv4-cidr-block | VPC のプライマリ IPv4 CIDR ブロック。 | 2011-01-01 |
| network/interfaces/macs/mac/vpc-ipv4-cidr-blocks | VPC の IPv4 CIDR ブロック。 | 2016-06-30 |
| network/interfaces/macs/mac/vpc-ipv6-cidr-blocks | インターフェイスが存在する VPC の IPv6 CIDR ブロック。 | 2016-06-30 |
| placement/availability-zone | インスタンスが起動した利用可能ゾーン。 | 2008-02-01 |
| placement/availability-zone-id | インスタンスが起動される静的アベイラビリティーゾーンの ID。このアベイラビリティーゾーン ID はアカウント間で一貫しています。ただし、アベイラビリティーゾーンとは異なる場合があります (アベイラビリティーゾーンはアカウントによって異なります)。 | 2019-10-01 |
| placement/group-name | インスタンスが起動されるプレイスメントグループの名前。 | 2020-08-24 |
| placement/host-id | インスタンスが起動されるホストの ID。専用ホスト にのみ適用されます。 | 2020-08-24 |
| placement/partition-number | インスタンスが起動されるパーティションの番号。 | 2020-08-24 |
| placement/region | インスタンスが起動される AWS リージョン。 | 2020-08-24 |
| product-codes | インスタンスに関連付けられた AWS Marketplace 製品コード (ある場合)。 | 2007-03-01 |
| public-hostname | インスタンスのパブリック DNS (IPv4)。このカテゴリはenableDnsHostnames 属性が true に設定されている場合にのみ返されます。詳細についてはAmazon VPC ユーザーガイドの「[DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html)」(VPC の DNS 属性) を参照してください。インスタンスにパブリック IPv6 アドレスのみがあり、パブリック IPv4 アドレスがない場合、この項目は設定されず、HTTP 404 応答が返されます。 | 2007-01-19 |
| public-ipv4 | パブリック IPv4 アドレス。インスタンスに Elastic IP アドレスが関連付けられている場合、返される値は Elastic IP アドレスです。 | 2007-01-19 |
| public-keys/0/openssh-key | パブリックキー。インスタンスの起動時に指定された場合のみ返されます。 | 1.0 |
| ramdisk-id | 起動時に指定された RAM ディスクの ID (該当する場合)。 | 2007-10-10 |
| reservation-id | 予約の ID。 | 1.0 |
| security-groups | インスタンスに適用されるセキュリティグループの名前。 起動後、インスタンスのセキュリティグループを変更できます。これらの変更はこの場所と network/interfaces/macs/**mac**/security-groups に反映されます。 | 1.0 |
| services/domain | リージョンのAWSリソースのドメイン。 | 2014-02-25 |
| services/partition | リソースが置かれているパーティションです。標準の AWS リージョンの場合、パーティションは `aws` です。他のパーティションにリソースがある場合、パーティションは `aws-partitionname` です。例えば、中国 (北京) リージョンにあるリソースのパーティションは`aws-cn` です。 | 2015-10-20 |
| spot/instance-action | アクション (休止、停止、または終了) およびアクションのおよその発生時刻 (UTC)。この項目が存在するのはスポットインスタンスが休止、停止、または終了のためにマークされた場合のみです。詳細については[instance-action](spot-instance-termination-notices.md#instance-action-metadata)を参照してください。 | 2016-11-15 |
| spot/termination-time | スポットインスタンスで使用しているオペレーティングシステムが、シャットダウン信号を受信するおよその時刻 (UTC)。この項目はスポットインスタンスに対し Amazon EC2 による終了のマークが付けられている場合にのみ存在し、時刻値 (例えば 2015-01-05T18:02:00Z) が含まれます。ユーザー自身がスポットインスタンスを終了した場合、termination-time 項目に時刻は記述されません。詳細については[termination-time](spot-instance-termination-notices.md#termination-time-metadata)を参照してください。 | 2014-11-05 |
| system | インスタンスの基盤となる仮想化タイプ (ハイパーバイザー) | 2022-09-24 |
| tags/instance | インスタンスに関連付けられるインスタンスタグ。インスタンスメタデータのタグへのアクセスを明示的に許可した場合のみ使用できます。詳細については[インスタンスメタデータ内のタグへのアクセスを有効にする](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS) を参照してください。 | 2021-03-23 |
## 動的データのカテゴリ
次の表は動的データのカテゴリをまとめたものです。
| Category | 説明 | カテゴリがリリースされたときのバージョン |
| --- | --- | --- |
| fws/instance-monitoring | 顧客が CloudWatch で詳細な 1 分間隔のモニタリングを有効にしているかどうかを示す値。有効な値: enabled \$1 disabled | 2009-04-04 |
| instance-identity/document | インスタンス ID、プライベート IP アドレスなど、インスタンスの属性を含む JSON。[Amazon EC2 インスタンスのインスタンスアイデンティティドキュメント](instance-identity-documents.md)を参照してください。 | 2009-04-04 |
| instance-identity/pkcs7 | 署名に対してドキュメントの真正性およびコンテンツを確認するために使用されます。[Amazon EC2 インスタンスのインスタンスアイデンティティドキュメント](instance-identity-documents.md)を参照してください。 | 2009-04-04 |
| instance-identity/signature | オリジンおよび権限を確認するために使用できるデータ。[Amazon EC2 インスタンスのインスタンスアイデンティティドキュメント](instance-identity-documents.md)を参照してください。 | 2009-04-04 |
# EC2 インスタンスのインスタンスメタデータにアクセスする
EC2 インスタンスメタデータにはインスタンス自体の内部から、または EC2 コンソール、API、SDK、または AWS CLI からアクセスできます。コンソールまたはコマンドラインからインスタンスの現在のインスタンスメタデータ設定を取得するには「[既存インスタンスのインスタンスメタデータオプションのクエリ](#query-IMDS-existing-instances)」を参照してください。
また、EBS ルートボリュームを持つインスタンスのユーザーデータを変更できます。インスタンスは停止状態である必要があります。コンソールの使用説明については「[インスタンスのユーザーデータを更新する](user-data.md#user-data-modify)」を参照してください。AWS CLI を使用する Linux の例については「[modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html)」を参照してください。Tools for Windows PowerShell を使用する Windows の例については「[ユーザーデータと Windows PowerShell用ツール](user-data.md#user-data-powershell)」を参照してください。
**注記**
インスタンスメタデータおよびユーザーデータの取得に使用する HTTP リクエストに対しては課金されません。
## インスタンスメタデータアクセス考慮事項
インスタンスメタデータの問題を回避するには、次の点を考慮してください。
**IMDSv2 の強制適用によるインスタンス起動の失敗 (`HttpTokensEnforced=enabled`)**
IMDSv2 の強制適用を有効にする前に、インスタンス上のすべてのソフトウェアが IMDSv2 をサポートするようにする必要があります。その後、デフォルトを変更して IMDSv1 を無効 (`httpTokens=required`) にし、強制適用を有効にすることができます。詳細については、[インスタンスメタデータサービスバージョン 2 の使用への移行](instance-metadata-transition-to-version-2.md) を参照してください。
**コマンド形式**
コマンド形式はインスタンスメタデータサービスバージョン 1 (IMDSv1) とインスタンスメタデータサービスバージョン 2 (IMDSv2) のどちらを使用するかによって異なります。デフォルトでは両方のバージョンのインスタンスメタデータサービスを使用できます。IMDSv2の使用を義務付けるには[インスタンスメタデータサービスを使用してインスタンスメタデータにアクセスする](configuring-instance-metadata-service.md)を参照してください。
**IMDSv2 が必要な場合はIMDSv1 は動作しません。**
IMDSv1 を使用していて、応答がない場合はIMDSv2 が必要になる可能性があります。IMDSv2 が必要かどうかを確認するにはインスタンスを選択して詳細を表示します。**[IMDSv2]** の値は**[必須]** (IMDSv2 を使用する必要がある) または **[オプション]** (IMDSv2 または IMDSv1 を使用可能) のいずれかです。
**(IMDSv2) /latest/api/token を使用してトークンを取得する**
バージョン固有の任意のパス (例: `/2021-03-23/api/token`) に `PUT` リクエストを発行した場合は、メタデータサービスから 403 Forbidden エラーが返されます。この応答は意図されたものです。
**メタデータのバージョン**
Amazon EC2 が新しいインスタンスメタデータビルドをリリースするたびにコードを更新する必要をなくすために、バージョン番号ではなく、パス内の `latest` を使用することが推奨されます。
**IPv6 サポート**
IPv6 アドレスを使用してインスタンス メタデータを取得するには、IMDS `[fd00:ec2::254]` の IPv4 アドレスではなく`169.254.169.254`IPv6 アドレスを有効にして使用するようにしてください。インスタンスはIPv6 対応[サブネットで起動された](instance-types.md#instance-hypervisor-type) Nitro ベースの[インスタンスである必要があります](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range)。
**(Windows) Windows Sysprep を使用してカスタム AMI を作成する**
カスタム Windows AMI からインスタンスを起動したときに IMDS が動作するようにするにはAMI は Sysprep を使用して作成された標準化されたイメージである必要があります。そうでない場合、IMDS は機能しません。詳細については「[Windows Sysprep を使用して Amazon EC2 AMI を作成する](ami-create-win-sysprep.md)」を参照してください。
**コンテナ環境では、再設定またはホップ制限を 2 に引き上げることを検討してください。**
AWS SDK はデフォルトで IMDSv2 コールを使用します。IMDSv2 呼び出しに応答がない場合、一部の AWS SDK は呼び出しを再試行し、それでも失敗する場合はIMDSv1 を使用します。これにより、特にコンテナ環境では遅延が発生することがあります。IMDSv2 を *必要とする* AWS SDK の場合、コンテナ環境でホップ制限が 1 の場合、コンテナへの移動は追加のネットワーク ホップとみなされ、呼び出しは応答をまったく受け取らない可能性があります。
コンテナ環境でこれらの問題を軽減するには、設定 (AWS リージョン など) をコンテナに直接渡すように設定を変更するか、ホップ制限を 2 に引き上げることを検討してください。ホップ制限の影響については、「[EC2 Instance Metadata Service の拡張により、オープンファイアウォール、リバースプロキシ、および SSRF の脆弱性に対して多層防御を追加](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/)」を参照してください。ホップ制限の変更については、「[PUT レスポンスホップリミットを変更する](configuring-IMDS-existing-instances.md#modify-PUT-response-hop-limit)」を参照してください。
**パケット/秒 (PPS) 制限**
[リンクローカル](using-instance-addressing.md#link-local-addresses)アドレスを使用するサービスには 1,024 パケット/秒 (PPS) の制限があります。この制限には[Route 53 Resolver DNS クエリ](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#vpc-dns-limits)、インスタンスメタデータサービス (IMDS) リクエスト、[Amazon Time Service Network Time Protocol (NTP)](set-time.md) リクエスト、および [Windows Licensing Service (Microsoft Windows ベースのインスタンス向け)](https://aws.amazon.com/windows/resources/licensing/) リクエストの総計が含まれます。
**ユーザーデータアクセスに関するその他の考慮事項**
+ ユーザーデータは非透過的なデータとして取り扱われ、取得時には指定したものが返されます。ユーザーデータの解釈およびそれに基づくアクションはインスタンス次第です。
+ ユーザーデータはbase64 でエンコードされている必要があります。使用しているツールまたは SDK によっては、base64 エンコードが実行される場合があります。次に例を示します。
+ Amazon EC2コンソールはbase64 エンコードを実行したり、base64 エンコード入力を受け入れたりできます。
+ [AWS CLI バージョン 2](https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html#cliv2-migration-binaryparam) は、ユーザーに対しデフォルトでバイナリパラメータの base64 エンコードを実行します。AWS CLI バージョン 1 は、ユーザーに対し `--user-data` パラメータの base64 エンコードを実行します。
+ AWS SDK for Python (Boto3) は、ユーザーに対し `UserData` パラメータの base64 エンコードを実行します。
+ ユーザーデータは raw 形式の 16 KB に制限されます (以前は base64 エンコード)。base64 エンコード後の 文字列の長さサイズ *n* はceil(*n*/3)\$14 です。
+ ユーザーデータを取得するときにユーザーデータを base64 デコードする必要があります。インスタンスのメタデータあるいはコンソールを使用してデータを取得する場合、自動的にデコードされます。
+ インスタンスを停止してユーザーデータを変更した後に、インスタンスを起動した場合でも、更新されたユーザーデータは自動的には実行されません。Windows インスタンスではインスタンスを起動したとき、またはインスタンスを再起動もしくは起動するたびに、更新されたユーザーデータスクリプトが 1 回実行されるように設定を構成することができます。
+ ユーザーデータはインスタンス属性です。インスタンスから AMI を作成する場合、インスタンスのユーザーデータは AMI に含まれません。
## EC2 インスタンス内からインスタンスメタデータにアクセスする
インスタンスメタデータは実行中のインスタンスから取得できるため、Amazon EC2 コンソールまたは AWS CLI を使用する必要はありません。これはインスタンスから実行するスクリプトを記述しているときに便利です。例えば、インスタンスメタデータからインスタンスのローカル IP アドレスにアクセスして、外部アプリケーションへの接続を管理できます。
以下はすべてインスタンスメタデータと見なされますが、さまざまな方法でアクセスされます。詳細を表示するためにアクセスするインスタンスメタデータのタイプを表すタブを選択してください。
------
#### [ Metadata ]
インスタンスメタデータプロパティはいくつかのカテゴリに分けられます。各インスタンスメタデータカテゴリの説明については[インスタンスメタデータのカテゴリ](ec2-instance-metadata.md#instancedata-data-categories)を参照してください。
実行中のインスタンス内からインスタンスメタデータプロパティにアクセスするには次の IPv4 または IPv6 URI からデータを取得します。これらの IP アドレスはリンクローカルアドレスであり、このインスタンスからのみ有効です。詳細については「[リンクローカルアドレス](using-instance-addressing.md#link-local-addresses)」を参照してください。
**IPv4**
```
http://169.254.169.254/latest/meta-data/
```
**IPv6**
```
http://[fd00:ec2::254]/latest/meta-data/
```
------
#### [ Dynamic data ]
実行中のインスタンス内から動的データを取得するには次の URI のいずれかを使用します。
**IPv4**
```
http://169.254.169.254/latest/dynamic/
```
**IPv6**
```
http://[fd00:ec2::254]/latest/dynamic/
```
**例: cURL を使用したアクセス**
次の例では`cURL` を使用して高レベルのインスタンスアイデンティティカテゴリを取得します。
*IMDSv2*
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/dynamic/instance-identity/
rsa2048
pkcs7
document
signature
dsa2048
```
*IMDSv1*
```
[ec2-user ~]$ curl http://169.254.169.254/latest/dynamic/instance-identity/
rsa2048
pkcs7
document
signature
dsa2048
```
**例: PowerShell を使用したアクセス**
次の例ではPowerShell を使用して高レベルのインスタンスアイデンティティカテゴリを取得します。
*IMDSv2*
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/dynamic/instance-identity/
document
rsa2048
pkcs7
signature
```
*IMDSv1*
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/dynamic/instance-identity/
document
rsa2048
pkcs7
signature
```
動的データの詳細およびその取得方法の例については[Amazon EC2 インスタンスのインスタンスアイデンティティドキュメント](instance-identity-documents.md)を参照してください。
------
#### [ User data ]
インスタンスからユーザーデータを取得するには次の URI のいずれかを使用します。IPv6 アドレスを使用してユーザーデータを取得するにはIPv6 アドレスが有効で、インスタンスが IPv6 対応サブネット内の [Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)である必要があります。
**IPv4**
```
http://169.254.169.254/latest/user-data
```
**IPv6**
```
http://[fd00:ec2::254]/latest/user-data
```
ユーザーデータのリクエストはデータをそのままの状態で返します (コンテンツタイプ `application/octet-stream`)。インスタンスにユーザーデータがない場合、リクエストは `404 - Not Found` を返します。
**例: cURL を使用してカンマ区切りテキストを取得するアクセス**
次の例では`cURL` を使用して、カンマ区切りテキストとして指定されたユーザーデータを取得します。
*IMDSv2*
```
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/user-data
1234,john,reboot,true | 4512,richard, | 173,,,
```
*IMDSv1*
```
curl http://169.254.169.254/latest/user-data
1234,john,reboot,true | 4512,richard, | 173,,,
```
**例: PowerShell を使用してカンマ区切りテキストを取得する**
次の例ではPowerShell を使用して、カンマ区切りテキストとして指定されたユーザーデータを取得します。
*IMDSv2*
```
[string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/user-data
1234,john,reboot,true | 4512,richard, | 173,,,
```
*IMDSv1*
```
Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} `
-Method PUT -Uri http://169.254.169.254/latest/api/token} -Method GET -uri http://169.254.169.254/latest/user-data
1234,john,reboot,true | 4512,richard, | 173,,,
```
**例: スクリプトを取得するための cURL を使用したアクセス**
次の例では`cURL` を使用して、スクリプトとして指定されたユーザーデータを取得します。
*IMDSv2*
```
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/user-data
#!/bin/bash
yum update -y
service httpd start
chkconfig httpd on
```
*IMDSv1*
```
curl http://169.254.169.254/latest/user-data
#!/bin/bash
yum update -y
service httpd start
chkconfig httpd on
```
**例: スクリプトを取得するための PowerShell を使用したアクセス**
次の例ではPowerShell を使用して、スクリプトとして指定されたユーザーデータを取得します。
*IMDSv2*
```
[string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/user-data
$file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
New-Item $file -ItemType file
true
```
*IMDSv1*
```
Invoke-RestMethod -uri http://169.254.169.254/latest/user-data
$file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
New-Item $file -ItemType file
true
```
------
## 既存インスタンスのインスタンスメタデータオプションのクエリ
既存のインスタンスのインスタンスメタデータオプションをクエリできます。
------
#### [ Console ]
**既存のインスタンスのインスタンスメタデータオプションをクエリするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、**[Instances]** (インスタンス) を選択してください。
1. インスタンスを選択して次のフィールドを確認します。
+ **[IMDSv2]** – 値は **[必須]** または **[オプション]** のいずれかです。
+ **[インスタンスメタデータのタグを許可]** – 値は **[有効]** または **[無効]** のいずれかです。
1. 選択したインスタンスで、**[アクション]**、**[インスタンスの設定]**、**[インスタンスメタデータのオプションを変更]** の順に選択してください。
ダイアログボックスには、選択したインスタンスでインスタンスメタデータサービスが有効か無効かが表示されます。
------
#### [ AWS CLI ]
**既存のインスタンスのインスタンスメタデータオプションをクエリするには**
[describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) コマンドを使用します。
```
aws ec2 describe-instances \
--instance-id i-1234567898abcdef0 \
--query 'Reservations[].Instances[].MetadataOptions'
```
------
#### [ PowerShell ]
**Tools for PowerShell を使用して既存のインスタンスのインスタンスメタデータオプションをクエリするには**
[Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html) コマンドレットを使用します。
```
(Get-EC2Instance `
-InstanceId i-1234567898abcdef0).Instances.MetadataOptions
```
------
## リスポンスおよびエラーメッセージ
すべてのインスタンスメタデータがテキスト (HTTP コンテンツタイプ `text/plain`) として返されます。
特定のメタデータリソースに対するリクエストは適切な値または `404 - Not Found` HTTP エラーコード (リソースを使用できない場合) を返します。
一般的なメタデータリソースに対するリクエスト (/ で終わる URI) は使用可能なリソースのリストまたは `404 - Not Found` HTTP エラーコード (使用可能なリソースがない場合) を返します。リスト項目は個別の行に表示され、各行の末尾には改行記号 (ASCII 10) が付いています。
IMDSv1 リクエストが応答を受信しない場合は、IMDSv2 が必要になる可能性があります。
IMDSv2 を使って行われたリクエストでは、次の HTTP エラーコードが返されます。
+ `400 - Missing or Invalid Parameters`–`PUT`リクエストが無効である。
+ `401 - Unauthorized`–`GET`リクエストが無効なトークンを使用している。推奨されるアクションは新しいトークンを生成することです。
+ `403 - Forbidden` - リクエストが許可されていないか、あるいは IMDS がオフです。
+ `404 - Not Found` – リソースが利用できないか、そのようなリソースがありません。
+ `503` - リクエストを完了できませんでした。リクエストを再試行します。
IMDS がエラーを返した場合、 はエラーメッセージを出力に**curl**出力し、成功ステータスコードを返します。エラーメッセージは `TOKEN`変数に保存され、トークンを使用する**curl**コマンドは失敗します。**-f** オプション**curl**を指定して を呼び出すと、HTTP サーバーエラーが発生した場合にエラーステータスコードが返されます。エラー処理を有効にすると、シェルはエラーを検出してスクリプトを停止できます。
## クエリスロットル
クエリは IMDS でインスタンスごとにスロットリングし、インスタンスから IMDS への同時接続数を制限します。
AWS セキュリティ認証情報を取得するために IMDS を使用している場合、毎回のトランザクションで、または高頻度のスレッドやプロセスから同時に認証情報をクエリしないようにします。スロットリングの原因となる可能性があります。代わりに、認証情報をキャッシュに格納して有効期限が近づくまで待つことをお勧めします。IAM ロールとロールに関連付けられたセキュリティ認証情報の詳細については「[インスタンスメタデータからのセキュリティ認証情報の取得](instance-metadata-security-credentials.md)」を参照してください。
IMDS にアクセスする際にスロットリングした場合、エクスポネンシャルバックオフ戦略でクエリを再試行します。
# インスタンスメタデータサービスを使用してインスタンスメタデータにアクセスする
次のいずれかのメソッドを使って、実行中のインスタンスからインスタンスメタデータにアクセスできます。
+ インスタンスメタデータサービスバージョン 2 (IMDSv2) – セッション指向メソッド
例については「[IMDSv2 の例](#instance-metadata-retrieval-examples)」を参照してください。
+ インスタンスメタデータサービスバージョン 1 (IMDSv1) – リクエスト/レスポンスメソッド
例については「[IMDSv1 の例](#instance-metadata-retrieval-examples-imdsv1)」を参照してください。
デフォルトではIMDSv1またはIMDSv2のいずれか、あるいは両方を使用できます。
IMDSv2 呼び出しのみを受け入れるように各インスタンスでインスタンスメタデータサービス (IMDS) を設定できます。これにより、IMDSv1 呼び出しが失敗します。ユーザーに IMDSv2 を使用させるようにインスタンスを設定する方法については「[インスタンスメタデータサービスのオプションを設定する](configuring-instance-metadata-options.md)」を参照してください。
`PUT` または `GET` ヘッダーは IMDSv2 に固有のものです。これらのヘッダーがリクエストに含まれている場合、そのリクエストは IMDSv2 を対象としています。ヘッダーが存在しない場合、そのリクエストは IMDSv1 を対象としているものとみなされます。
IMDSv2 の拡張のレビューの詳細については「[EC2 Instance Metadata Service の拡張により、オープンファイアウォール、リバースプロキシ、および SSRF の脆弱性に対して多層防御を追加](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/)」を参照してください。
**Topics**
+ [
## インスタンスメタデータサービスバージョン 2 の仕組み
](#instance-metadata-v2-how-it-works)
+ [
## サポートされる AWS SDK を使用する
](#use-a-supported-sdk-version-for-imdsv2)
+ [
## IMDSv2 の例
](#instance-metadata-retrieval-examples)
+ [
## IMDSv1 の例
](#instance-metadata-retrieval-examples-imdsv1)
## インスタンスメタデータサービスバージョン 2 の仕組み
IMDSv2 はセッション指向リクエストを使用します。セッション指向リクエストを使用して、セッション期間 (1 秒～6 時間) を定義するセッショントークンを作成します。指定した期間中、それ以降のリクエストに同じセッショントークンを使用できます。指定した期間が期限切れになった後、将来のリクエストに使用する新しいセッショントークンを作成する必要があります。
**注記**
このセクションの例ではインスタンスメタデータサービス (IMDS) の IPv4 アドレス `169.254.169.254` を使用します。IPv6 アドレスを使用して EC2 インスタンスのインスタンスメタデータを取得する場合はIPv6 アドレスを有効にして使用してください。`[fd00:ec2::254]`。IMDS の IPv6 アドレスはIMDSv2 コマンドと互換性があります。IPv6 アドレスには[Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)と [IPv6 対応サブネット](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) (デュアルスタックまたは IPv6 のみ) でのみアクセスできます。
次の例ではシェルスクリプトと IMDSv2 を使用して、最上位インスタンスメタデータ項目を取得します。各例の操作は次のとおりです。
+ `PUT`リクエストを使って、6 時間 (21,600 秒) のセッショントークンを作成する
+ セッショントークンヘッダーを `TOKEN` (Linux インスタンス) または `token` (Windows インスタンス) という名前の変数に保管する
+ トークンを使って最上位メタデータアイテムをリクエストする
### Linux の例
2 つの個別のコマンドを実行することも、それらを組み合わせることもできます。
**個別のコマンド**
最初に、次のコマンドを使用してトークンを生成します。
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
```
その後、次のコマンドを使用して、トークンを使用して上位レベルのメタデータアイテムを生成します。
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/
```
**組み合わされたコマンド**
トークンを保存し、コマンドを組み合わせることができます。次の例では上記の 2 つのコマンドを組み合わせて、セッショントークンヘッダーを TOKEN という名前の変数に格納します。
**注記**
トークンの作成時にエラーが発生した場合は有効なトークンの代わりにエラーメッセージが変数に格納され、コマンドは機能しません。
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/
```
トークンを作成した後、期限切れになるまで再使用することができます。次のコマンド例ではインスタンスの起動に AMI の ID が使用されていますが、前の例で `$TOKEN`に保管されたトークンが再使用されています。
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/ami-id
```
### Windows の例
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/
```
トークンを作成した後、期限切れになるまで再使用することができます。次のコマンド例ではインスタンスの起動に AMI の ID が使用されていますが、前の例で `$token`に保管されたトークンが再使用されています。
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} `
-Method GET -uri http://169.254.169.254/latest/meta-data/ami-id
```
IMDSv2を使ってインスタンスメタデータをリクエストする際はリクエストに次の項目が含まれている必要があります。
1. `PUT` リクエストを使って、インスタンスメタデータサービスに対してセッションを開始します。`PUT` リクエストはインスタンスメタデータサービスに対する後続の `GET` リクエストに含まれている必要のあるトークンを返します。このトークンはIMDSv2を使ってメタデータにアクセスするのに必要です。
1. トークンを IMDS に対するすべての `GET` リクエストに含めます。トークンの使用が `required` に設定されている場合、有効なトークンがないリクエスト、または有効期限切れのトークンを持つリクエストで `401 - Unauthorized` HTTP エラーコードが発生します。
+ トークンはインスタンス固有のキーです。トークンは他の EC2 インスタンスで有効ではなく、生成されたインスタンスの外で使用しようとすると拒否されます。
+ `PUT`リクエストにはトークンの有効期限 (TTL) を最大 6 時間 (21,600 秒) まで秒単位で指定するヘッダーが含まれている必要があります。トークンは論理的セッションを表します。TTL はトークンが有効な時間の長さ、つまりセッションの期間を指定します。
+ トークンの期限が切れた後、インスタンスメタデータにアクセスし続けるためには別の `PUT`を使って新しいセッションを作成する必要があります。
+ 各リクエストについてトークンを再使用するか、あるいは新しいトークンを作成することを選択できます。少数のリクエストではIMDS にアクセスする必要があるたびに、トークンを生成してすぐに使用するほうが簡単である場合があります。ただし、効率を重視するなら、インスタンスメタデータをリクエストする必要があるたびに`PUT`リクエストを書くより、トークン期間を長く指定して再使用することができます。それぞれが独自のセッションを表すトークンを同時に使用できる数については実際的に制限がありません。ただし、IMDSv2 では通常の IMDS 接続とスロットリングの制限によって制約を受けます。詳細については「[クエリスロットル](instancedata-data-retrieval.md#instancedata-throttling)」を参照してください。
HTTP `GET`および`HEAD`メソッドはIMDSv2インスタンスメタデータリクエストで許可されています。 `PUT` リクエストはX-Forwarded-For ヘッダーが含まれている場合、拒否されます。
デフォルトで、`PUT` リクエストに対するレスポンスには IP プロトコルレベルで `1` のレスポンスホップリミット (有効期限) があります。より大きなホップリミットが必要な場合は[modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) AWS CLI コマンドを使って調整できます。例えば、インスタンスで実行されているコンテナサービスとの下位互換性のために、ホップリミットを拡大する必要がある場合があります。詳細については「[既存インスタンスのインスタンスメタデータオプションの変更](configuring-IMDS-existing-instances.md)」を参照してください。
## サポートされる AWS SDK を使用する
IMDSv2 を使用するにはEC2 インスタンスが IMDSv2 の使用をサポートする AWS SDK バージョンを使用する必要があります。最新バージョンの AWS SDK はすべて IMDSv2 の使用をサポートしています。
**重要**
最新の機能、セキュリティアップデート、および基本的な依存関係を維持するために、SDK のリリースを常に更新することをお勧めします。サポート対象外の SDK バージョンを継続して使用することはお勧めできません。お客様の判断で行ってください。詳細については*AWS SDK とツ*ールのリファレンスガイド」の「[AWS SDK とツールのメンテナンスポリシー](https://docs.aws.amazon.com/sdkref/latest/guide/maint-policy.html)」を参照してください。
IMDSv2 の使用をサポートする最小バージョンは次のとおりです。
+ [AWS CLI](https://github.com/aws/aws-cli) – 1.16.289
+ [AWS Tools for Windows PowerShell](https://github.com/aws/aws-tools-for-powershell) – 4.0.1.0
+ [AWS SDK for .NET](https://github.com/aws/aws-sdk-net) – 3.3.634.1
+ [AWS SDK for C\$1\$1](https://github.com/aws/aws-sdk-cpp) – 1.7.229
+ [AWS SDK for Go](https://github.com/aws/aws-sdk-go) – 1.25.38
+ [AWS SDK for Go v2](https://github.com/aws/aws-sdk-go-v2) – 0.19.0
+ [AWS SDK for Java](https://github.com/aws/aws-sdk-java) – 1.11.678
+ [AWS SDK for Java 2.x](https://github.com/aws/aws-sdk-java-v2) – 2.10.21
+ [AWS Node.js 内の SDK for JavaScript](https://github.com/aws/aws-sdk-js) – 2.722.0
+ [AWS SDK for Kotlin](https://github.com/awslabs/aws-sdk-kotlin) – 1.1.4
+ [AWS SDK for PHP](https://github.com/aws/aws-sdk-php) – 3.147.7
+ [AWS SDK for Python (Botocore)](https://github.com/boto/botocore) – 1.13.25
+ [AWS SDK for Python (Boto3)](https://github.com/boto/boto3) – 1.12.6
+ [AWS SDK for Ruby](https://github.com/aws/aws-sdk-ruby) – 3.79.0
## IMDSv2 の例
Amazon EC2 インスタンスで次の例を実行して、IMDSv2 のインスタンスメタデータを取得します。
Windows インスタンスでは、Windows PowerShell を使用するか、cURL または wget をインストールすることができます。Windows インスタンスにサードパーティーツールをインストールする場合は、呼び出しおよび出力がここに記載されているものとは異なる場合があるため、必ず付属のドキュメントをよく読んでください。
**Topics**
+ [
### 使用できるインスタンスメタデータのバージョンを取得する
](#instance-metadata-ex-1)
+ [
### 上位レベルのメタデータ項目を取得する
](#instance-metadata-ex-2)
+ [
### メタデータ項目の値を取得する
](#instance-metadata-ex-2a)
+ [
### 使用可能なパブリックキーのリストを取得する
](#instance-metadata-ex-3)
+ [
### パブリックキー 0 が使用できるフォーマットを示す
](#instance-metadata-ex-4)
+ [
### パブリックキー 0 を取得する (OpenSSH キーフォーマット)
](#instance-metadata-ex-5)
+ [
### インスタンスのサブネット ID を取得する
](#instance-metadata-ex-6)
+ [
### インスタンスのインスタンスタグを取得する
](#instance-metadata-ex-7)
### 使用できるインスタンスメタデータのバージョンを取得する
次の例では使用できるインスタンスメタデータのバージョンを取得しています。各バージョンは新しいインスタンスのメタデータカテゴリがリリースされたときのインスタンスメタデータビルドを参照してください。インスタンスメタデータビルドのバージョンはAmazon EC2 API のバージョンとは相関しません。以前のバージョンに存在する構造および情報に依存するスクリプトがある場合は以前のバージョンを使用することができます。
------
#### [ cURL ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
2011-01-01
2011-05-01
2012-01-12
2014-02-25
2014-11-05
2015-10-20
2016-04-19
...
latest
```
------
#### [ PowerShell ]
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
2011-01-01
2011-05-01
2012-01-12
2014-02-25
2014-11-05
2015-10-20
2016-04-19
...
latest
```
------
### 上位レベルのメタデータ項目を取得する
次の例では上位レベルのメタデータ項目を取得しています。レスポンスの項目の詳細については「[インスタンスメタデータのカテゴリ](ec2-instance-metadata.md#instancedata-data-categories)」を参照してください。
アクセスを許可した場合にのみ、タグがこの出力に含まれることに注意してください。詳細については「[インスタンスメタデータ内のタグへのアクセスを有効にする](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS)」を参照してください。
------
#### [ cURL ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
iam/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
tags/
```
------
#### [ PowerShell ]
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
iam/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
tags/
```
------
### メタデータ項目の値を取得する
これらの例では前出の例で取得された一部の最上位メタデータ項目の値を取得しています。これらのリクエストは、前の例のコマンドを使用して作成された保管されているトークンを使用します。このトークンは有効期限が切れていない必要があります。
------
#### [ cURL ]
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/ami-id
ami-0abcdef1234567890
```
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/reservation-id
r-0efghijk987654321
```
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/local-hostname
ip-10-251-50-12.ec2.internal
```
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-hostname
ec2-203-0-113-25.compute-1.amazonaws.com
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/ami-id
ami-0abcdef1234567890
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/reservation-id
r-0efghijk987654321
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/local-hostname
ip-10-251-50-12.ec2.internal
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-hostname
ec2-203-0-113-25.compute-1.amazonaws.com
```
------
### 使用可能なパブリックキーのリストを取得する
次の例では使用できるパブリックキーの一覧を取得しています。
------
#### [ cURL ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-keys/
0=my-public-key
```
------
#### [ PowerShell ]
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-keys/
0=my-public-key
```
------
### パブリックキー 0 が使用できるフォーマットを示す
次の例はパブリックキー0のフォーマットを示しています。
------
#### [ cURL ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-keys/0/
openssh-key
```
------
#### [ PowerShell ]
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
openssh-key
```
------
### パブリックキー 0 を取得する (OpenSSH キーフォーマット)
次の例ではパブリックキー0を取得しています (OpenSSH キーフォーマット)。
------
#### [ cURL ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
```
------
#### [ PowerShell ]
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
```
------
### インスタンスのサブネット ID を取得する
次の例ではインスタンスのサブネット ID を取得しています。
------
#### [ cURL ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id
subnet-be9b61d7
```
------
#### [ PowerShell ]
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id
subnet-be9b61d7
```
------
### インスタンスのインスタンスタグを取得する
インスタンスメタデータ内のインスタンスタグへのアクセスが有効になっている場合はインスタンスメタデータからインスタンスのタグを取得できます。詳細については「[インスタンスメタデータからタグを取得する](work-with-tags-in-IMDS.md#retrieve-tags-from-IMDS)」を参照してください。
## IMDSv1 の例
Amazon EC2 インスタンスで次の例を実行して、IMDSv1 のインスタンスメタデータを取得します。
Windows インスタンスでは、Windows PowerShell を使用するか、cURL または wget をインストールすることができます。Windows インスタンスにサードパーティーツールをインストールする場合は、呼び出しおよび出力がここに記載されているものとは異なる場合があるため、必ず付属のドキュメントをよく読んでください。
**Topics**
+ [
### 使用できるインスタンスメタデータのバージョンを取得する
](#instance-metadata-ex-1-imdsv1)
+ [
### 上位レベルのメタデータ項目を取得する
](#instance-metadata-ex-2-imdsv1)
+ [
### メタデータ項目の値を取得する
](#instance-metadata-ex-2a-imdsv1)
+ [
### 使用可能なパブリックキーのリストを取得する
](#instance-metadata-ex-3-imdsv1)
+ [
### パブリックキー 0 が使用できるフォーマットを示す
](#instance-metadata-ex-4-imdsv1)
+ [
### パブリックキー 0 を取得する (OpenSSH キーフォーマット)
](#instance-metadata-ex-5-imdsv1)
+ [
### インスタンスのサブネット ID を取得する
](#instance-metadata-ex-6-imdsv1)
+ [
### インスタンスのインスタンスタグを取得する
](#instance-metadata-ex-7-imdsv1)
### 使用できるインスタンスメタデータのバージョンを取得する
次の例では使用できるインスタンスメタデータのバージョンを取得しています。各バージョンは新しいインスタンスのメタデータカテゴリがリリースされたときのインスタンスメタデータビルドを参照してください。インスタンスメタデータビルドのバージョンはAmazon EC2 API のバージョンとは相関しません。以前のバージョンに存在する構造および情報に依存するスクリプトがある場合は以前のバージョンを使用することができます。
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
2011-01-01
2011-05-01
2012-01-12
2014-02-25
2014-11-05
2015-10-20
2016-04-19
...
latest
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
2011-01-01
2011-05-01
2012-01-12
2014-02-25
2014-11-05
2015-10-20
2016-04-19
...
latest
```
------
### 上位レベルのメタデータ項目を取得する
次の例では上位レベルのメタデータ項目を取得しています。レスポンスの項目の詳細については「[インスタンスメタデータのカテゴリ](ec2-instance-metadata.md#instancedata-data-categories)」を参照してください。
アクセスを許可した場合にのみ、タグがこの出力に含まれることに注意してください。詳細については「[インスタンスメタデータ内のタグへのアクセスを有効にする](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS)」を参照してください。
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
iam/
instance-action
instance-id
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
tags/
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
iam/
instance-action
instance-id
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
tags/
```
------
### メタデータ項目の値を取得する
これらの例では、前の例で取得した一部の最上位メタデータ項目の値を取得しています。
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/ami-id
ami-0abcdef1234567890
```
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/reservation-id
r-0efghijk987654321
```
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/local-hostname
ip-10-251-50-12.ec2.internal
```
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-hostname
ec2-203-0-113-25.compute-1.amazonaws.com
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/ami-id
ami-0abcdef1234567890
```
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/reservation-id
r-0efghijk987654321
```
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/local-hostname
ip-10-251-50-12.ec2.internal
```
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-hostname
ec2-203-0-113-25.compute-1.amazonaws.com
```
------
### 使用可能なパブリックキーのリストを取得する
次の例では使用できるパブリックキーの一覧を取得しています。
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/
0=my-public-key
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-keys/ 0=my-public-key
```
------
### パブリックキー 0 が使用できるフォーマットを示す
次の例はパブリックキー0のフォーマットを示しています。
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/0/
openssh-key
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
openssh-key
```
------
### パブリックキー 0 を取得する (OpenSSH キーフォーマット)
次の例ではパブリックキー0を取得しています (OpenSSH キーフォーマット)。
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
```
------
### インスタンスのサブネット ID を取得する
次の例ではインスタンスのサブネット ID を取得しています。
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id
subnet-be9b61d7
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id
subnet-be9b61d7
```
------
### インスタンスのインスタンスタグを取得する
インスタンスメタデータ内のインスタンスタグへのアクセスが有効になっている場合はインスタンスメタデータからインスタンスのタグを取得できます。詳細については「[インスタンスメタデータからタグを取得する](work-with-tags-in-IMDS.md#retrieve-tags-from-IMDS)」を参照してください。
# インスタンスメタデータサービスバージョン 2 の使用への移行
インスタンスメタデータサービスバージョン 2 (IMDSv2) 呼び出しのみを許可するようにインスタンスを設定する場合は、次のツールと移行パスを使用することをお勧めします。
**Topics**
+ [
## IMDSv2 に移行するためのツール
](#tools-for-transitioning-to-imdsv2)
+ [
## IMDSv2 を必要とする推奨パス
](#recommended-path-for-requiring-imdsv2)
## IMDSv2 に移行するためのツール
次のツールは、IMDSv1 から IMDSv2 へのソフトウェアの移行を特定、モニタリング、管理するのに役立ちます。これらのツールの使用方法については、「[IMDSv2 を必要とする推奨パス](#recommended-path-for-requiring-imdsv2)」を参照してください。
**AWS ソフトウェア**
最新バージョンの AWS CLI および AWS SDK ではIMDSv2 をサポートしています。IMDSv2 を使用するには、EC2 インスタンスを更新して最新バージョンを使用してください。IMDSv2 をサポートする最低限の AWS SDK バージョンについては「[サポートされる AWS SDK を使用する](configuring-instance-metadata-service.md#use-a-supported-sdk-version-for-imdsv2)」を参照してください。
すべての Amazon Linux 2 と Amazon Linux 2023 ソフトウェアパッケージが IMDSv2 をサポートしています。Amazon Linux 2023 では、IMDSv1 はデフォルトで無効になっています。
**IMDS パケットアナライザー**
IMDS パケットアナライザーは、インスタンスの起動フェーズおよびランタイムオペレーション時の IMDSv1 呼び出しを特定してログに記録する、オープンソースツールです。これらのログを解析すると、お使いのインスタンスで IMDSv1 呼び出しを行うソフトウェアを正確に特定し、お使いのインスタンスでのみ IMDSv2 をサポートするために更新する必要があるものを特定できます。IMDS パケットアナライザーはコマンドラインから実行することも、サービスとしてインストールすることもできます。詳細については*GitHub* の [AWS ImdsPacketAnalyzer](https://github.com/aws/aws-imds-packet-analyzer) のページを参照してください
**CloudWatch**
CloudWatch では、インスタンスのモニタリング用に次の 2 つのメトリクスが用意されています。
`MetadataNoToken` – IMDSv2 はトークンベースのセッションを使用します。ただし、IMDSv1 はこれを使用しません。`MetadataNoToken` メトリクスは IMDSv1 を使用しているインスタンスメタデータサービス (IMDS) への呼び出しの数を追跡します。このメトリクスをゼロまでトラッキングすることにより、すべてのソフトウェアが IMDSv2 を使用するようアップグレードされたかどうか、およびいつアップデートが行われたかを測定できます。
`MetadataNoTokenRejected` – IMDSv1 を無効にした後、`MetadataNoTokenRejected` メトリクスを使用して、IMDSv1 呼び出しが試行および拒否された回数を追跡できます。このメトリクスを追跡することで、IMDSv2 を使用するようにソフトウェアを更新する必要があるかどうかを確認できます。
各 EC2 インスタンスのこれらのメトリクスは相互排他的です。IMDSv1 が有効になっている場合 (`httpTokens = optional`) は、`MetadataNoToken` のみが出力されます。IMDSv1 が無効になっている場合 (`httpTokens = required`) は、`MetadataNoTokenRejected` のみが出力されます。これらのメトリクスをいつ使用すべきかについては、「[IMDSv2 を必要とする推奨パス](#recommended-path-for-requiring-imdsv2)」を参照してください。
詳細については「[インスタンスメトリクス](viewing_metrics_with_cloudwatch.md#ec2-cloudwatch-metrics)」を参照してください。
**API の起動**
**新しいインスタンス:** [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html) API を使用して、IMDSv2 の使用を必須とする新しいインスタンスを起動します。詳細については「[新規インスタンスのインスタンスメタデータオプションの設定](configuring-IMDS-new-instances.md)」を参照してください。
**既存のインスタンス:** [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html) API を使用して、既存のインスタンスでの IMDSv2 の使用を必須にします。詳細については「[既存インスタンスのインスタンスメタデータオプションの変更](configuring-IMDS-existing-instances.md)」を参照してください。
**Auto Scaling グループによって起動された新しいインスタンス:** Auto Scaling グループによって起動されたすべての新しいインスタンスで IMDSv2 の使用を必須とするには、Auto Scaling グループで起動テンプレートまたは起動設定を使用できます。[起動テンプレートの作成](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-launch-template.html)時や[起動設定の作成](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/create-launch-configuration.html)時に、IMDSv2 の使用が必須となるように `MetadataOptions` パラメータを設定する必要があります。Auto Scaling グループは新しい起動テンプレートまたは起動設定を使用して新しいインスタンスは新しいインスタンスを起動しますが、既存のインスタンスは影響を受けません。
**Auto Scaling グループ内の既存のインスタンス**: [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html) API を使用して、既存のインスタンスで IMDSv2 の使用を必須にします。または、インスタンスを終了すると、Auto Scaling グループが新しい起動テンプレートまたは起動設定で定義されているインスタンスメタデータオプション設定を使用して新しい代替インスタンスを起動します。
**AMI**
`ImdsSupport` パラメータを `v2.0` に設定して構成された AMI は、デフォルトで IMDSv2 を必要とするインスタンスを起動します。Amazon Linux 2023 は `ImdsSupport = v2.0` を使用して設定されます。
**新しい AMI:** 新しい AMI を作成するときは、[register-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html) CLI コマンドを使用して `ImdsSupport` パラメータを `v2.0` に設定します。
**既存の AMI:** 既存の AMI を変更するときは、[modify-image-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-image-attribute.html) CLI コマンドを使用して `ImdsSupport` パラメータを `v2.0` に設定しますい。
詳細については「[AMI を設定する](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-ami-configuration)」を参照してください。
**アカウントレベルのコントロール**
すべてのインスタンスメタデータオプションのデフォルト値をアカウントレベルで設定できます。デフォルト値は、インスタンスの起動時に自動的に適用されます。詳細については、「[IMDSv2 をアカウントのデフォルトとして設定する](configuring-IMDS-new-instances.md#set-imdsv2-account-defaults)」を参照してください。
IMDSv2 を使用する要件をアカウントレベルで強制適用することもできます。IMDSv2 の強制適用が有効になっている場合:
+ **新しいインスタンス:** IMDSv1 が有効化された状態で起動するように設定されたインスタンスは起動が失敗します
+ **IMDSv1 が無効になっている既存のインスタンス:** 既存のインスタンスで IMDSv1 を有効にする試みは阻止されます。
+ **IMDSv1 が有効になっている既存のインスタンス:** IMDSv1 が既に有効になっている既存のインスタンスは影響を受けません。
詳細については「[アカウントレベルで IMDSv2 を強制適用する](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level)」を参照してください。
**IAM ポリシーおよび SCP**
以下に示すように、ユーザーの管理にはIAM ポリシーを使用することも、AWS Organizations サービスコントロールポリシー (SCP) を使用することもできます。
+ インスタンスが IMDSv2 を使用するように設定されていない限り、[RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html) API を使用してそのインスタンスを起動することはできません。
+ [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html) API を使用して実行中のインスタンスを変更し、IMDSv1 を再度有効にすることはできません。
IAM ポリシーまたは SCP には次の IAM 条件キーを含める必要があります。
+ `ec2:MetadataHttpEndpoint`
+ `ec2:MetadataHttpPutResponseHopLimit`
+ `ec2:MetadataHttpTokens`
API および CLI 呼び出し時のパラメータが、条件キーが含まれているポリシーで指定した状態と一致しない場合、これらの API または CLI の呼び出しは失敗し `UnauthorizedOperation` レスポンスが返されます。
さらに、追加の保護レイヤーを選択して、IMDSv1からIMDSv2の変更を強制することもできます。EC2 ロールの認証情報経由で呼び出された各 API に関するアクセス管理レイヤーでは、IAM ポリシーまたは AWS Organizations サービスコントロールポリシー (SCP) で条件キーを使用できます。具体的にはIAM ポリシーで値 `2.0` を設定した条件キー `ec2:RoleDelivery` を使用していると、IMDSv1 から取得した EC2 ロールの認証情報を使用した API コールに対して、`UnauthorizedOperation` レスポンスが返されます。同じことはSCP によって義務付けられる条件を使ってより広く達成できます。これにより、指定した条件と一致しない API コールに対しては `UnauthorizedOperation` エラーが返されるため、実際に IMDSv1 から取得した認証情報を使用して API を呼び出すことはできなくなります。
IAM ポリシーの例は[インスタンスメタデータの使用](ExamplePolicies_EC2.md#iam-example-instance-metadata)を参照してください。SCP の詳細については「*AWS Organizations ユーザーガイド 」の「サービスコントロ*ールポリシー [(SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
**宣言型ポリシー**
宣言型ポリシー (AWS Organizations の機能) を使用して、組織全体の IMDS アカウントデフォルト (IMDSv2 の強制適用を含む) を一元的に設定します。ポリシーの例については、「*AWS Organizations ユーザーガイド*」の「[サポートされている宣言型ポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples)」セクションにある「**インスタンスメタデータ**」タブを参照してください。
## IMDSv2 を必要とする推奨パス
**Topics**
+ [
### ステップ 1: IMDSv2=optional を使用するインスタンスを特定し、IMDSv1 の使用状況を監査する
](#path-step-1)
+ [
### ステップ 2: ソフトウェアを IMDSv2 に更新する
](#path-step-2)
+ [
### ステップ 3: インスタンスで IMDSv2 を要求する
](#path-step-3)
+ [
### ステップ 4: IMDSv2=required をデフォルトとして設定する
](#path-step-4)
+ [
### ステップ 5: インスタンスに IMDSv2 を要求するように強制する
](#path-step-5)
### ステップ 1: IMDSv2=optional を使用するインスタンスを特定し、IMDSv1 の使用状況を監査する
IMDSv2 移行の範囲を評価するには、IMDSv1 または IMDSv2 のいずれかを許可するように設定されたインスタンスを特定し、IMDSv1 呼び出しを監査します。
1. **IMDSv1 または IMDSv2 のいずれかを許可するように設定されたインスタンスを特定する:**
------
#### [ Amazon EC2 console ]
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、**[Instances]** (インスタンス) を選択してください。
1. IMDSv1 または IMDSv2 を許可するように設定されたインスタンスのみを表示するには、フィルター「**IMDSv2 = optional**」を追加します。
1. または、IMDSv2 がすべてのインスタンスで**オプション**か**必須**かを確認するには、**[設定]** ウィンドウ (歯車アイコン) を開き、**[IMDSv2]** をオンにして **[確認]** を選択します。これにより **IMDSv2** 列が**インスタンス**テーブルに追加されます。
------
#### [ AWS CLI ]
[describe-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-options.html) コマンドを使用して、次のように `metadata-options.http-tokens = optional` でフィルタリングします。
```
aws ec2 describe-instances --filters "Name=metadata-options.http-tokens,Values=optional" --query "Reservations[*].Instances[*].[InstanceId]" --output text
```
------
1. **各インスタンスで IMDSv1 呼び出しを監査する:**
CloudWatch メトリクス `MetadataNoToken` を使用します。このメトリクスはインスタンスの IMDS に対する IMDSv1 呼び出しの数を示します。詳細については、「[インスタンスのメトリクス](https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics)」を参照してください。
1. **IMDSv1 呼び出しを行うインスタンス上のソフトウェアを特定する:**
オープンソースの [IMDS パケットアナライザー](https://github.com/aws/aws-imds-packet-analyzer)を使用して、インスタンスの起動フェーズおよびランタイムオペレーション中に IMDSv1 呼び出しを特定し、ログに記録します。この情報を使用して、更新するソフトウェアを特定し、インスタンスが IMDSv2 のみを使用する準備を行います。IMDS パケットアナライザーはコマンドラインから実行することも、サービスとしてインストールすることもできます。
### ステップ 2: ソフトウェアを IMDSv2 に更新する
インスタンスでロール認証情報を使用するすべてのSDK、CLI、ソフトウェアを IMDSv2 対応バージョンに更新します。詳細については *AWS Command Line Interface ユーザーガイド」の「[AWS CLI の最新バージョンをインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください*。
### ステップ 3: インスタンスで IMDSv2 を要求する
`MetadataNoToken` メトリクスを通じて IMDSv1 呼び出しがゼロになったことを確認したら、IMDSv2 を要求するように既存のインスタンスを設定します。また、IMDSv2 を要求するようにすべての新しいインスタンスを設定します。つまり、すべての既存のインスタンスと新しいインスタンスで IMDSv1 を無効にします。
1. **IMDSv2 を要求するように既存のインスタンスを設定する:**
------
#### [ Amazon EC2 console ]
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、**[Instances]** (インスタンス) を選択してください。
1. インスタンスを選択してください。
1. **[アクション]**、**[インスタンスの設定]**、**[インスタンスメタデータのオプションを変更]** の順に選択してください。
1. **[IMDSv2]** の場合は**[必須]** を選択してください。
1. [**Save**] を選択してください。
------
#### [ AWS CLI ]
IMDSv2 のみを使用するように指定するには、[modify-instance-metadata-options](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-options.html) CLI コマンドを使用します。
------
**注記**
この設定は、実行中のインスタンスで変更できます。変更は、インスタンスを再起動しなくてもすぐに有効になります。
詳細については「[IMDSv2 の使用を要求する](configuring-IMDS-existing-instances.md#modify-require-IMDSv2)」を参照してください。
1. **IMDSv1 を無効にした後の問題を監視する:**
1. `MetadataNoTokenRejected` CloudWatch メトリクスを使用して、IMDSv1 呼び出しが試行および拒否された回数を追跡できます。
1. ソフトウェアの問題が発生しているインスタンスで `MetadataNoTokenRejected` メトリクスが IMDSv1 呼び出しを記録する場合、これは IMDSv2 を使用するためにソフトウェアを更新する必要があることを示します。
1. **IMDSv2 を要求するように新しいインスタンスを設定する:**
------
#### [ Amazon EC2 console ]
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. [インスタンスを起動](ec2-launch-instance-wizard.md)するには、次のステップに沿って操作します。
1. **[高度な詳細]** を展開し、**[メタデータバージョン]** で **[V2 のみ (トークンが必要)]** を選択します。
1. **[Summary]** (概要) パネルでインスタンスの設定を確認し、**[Launch instance]** (インスタンスを起動) を選択してください。
詳細については「[起動時にインスタンスを設定する](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-instance-settings)」を参照してください。
------
#### [ AWS CLI ]
AWS CLI: [run-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/run-instances.html) CLI コマンドを使用して、IMDSv2 が必須となるように指定します。
------
### ステップ 4: IMDSv2=required をデフォルトとして設定する
IMDSv2=required は、アカウントレベルまたは組織レベルのいずれかでデフォルト設定として設定できます。これにより、新しく起動されたすべてのインスタンスが IMDSv2 を要求するように自動的に設定されます。
1. **アカウントレベルのデフォルトを設定する:**
------
#### [ Amazon EC2 console ]
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、**ダッシュボード**を選択してください。
1. **[アカウント属性]** カードの **[設定]** で、**[データ保護とセキュリティ]** を選択します。
1. **[IMDS のデフォルト]** で **[管理]** を選択します。
1. **[インスタンスメタデータサービス]** で、**[有効にする]** を選択します。
1. **[メタデータバージョン]** で、**[V2 のみ (トークンが必要)]** を選択します。
1. **[Update]** (更新) を選択してください。
------
#### [ AWS CLI ]
[modify-instance-metadata-defaults](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-defaults.html) CLI コマンドを使用して、`--http-tokens required` と `--http-put-response-hop-limit 2` を指定します。
------
詳細については「[IMDSv2 をアカウントのデフォルトとして設定する](configuring-IMDS-new-instances.md#set-imdsv2-account-defaults)」を参照してください。
1. **または、宣言型ポリシーを使用して組織レベルのデフォルトを設定します。**
宣言型ポリシーを使用して、IMDSv2 の組織のデフォルトを必須に設定します。ポリシーの例については、「*AWS Organizations ユーザーガイド*」の「[サポートされている宣言型ポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples)」セクションにある「**インスタンスメタデータ**」タブを参照してください。
### ステップ 5: インスタンスに IMDSv2 を要求するように強制する
どのインスタンスにも IMDSv1 への依存がないことを確認したら、すべての新しいインスタンスに IMDSv2 を強制適用することが推奨されます。
次の 2 つのオプションのいずれかを使用して IMDSv2 を強制適用します。
1. **アカウントプロパティを使用して IMDSv2 を強制適用する**
各 AWS リージョンに対し、アカウントレベルで IMDSv2 の使用を強制できます。使用が強制されると、インスタンスを起動できるのは IMDSv2 が必須として設定されている場合のみになります。この強制は、インスタンスまたは AMI の設定方法を問わずに適用されます。詳細については「[アカウントレベルで IMDSv2 を強制適用する](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level)」を参照してください。この設定を組織レベルで適用するには、宣言型ポリシーを設定します。ポリシーの例については、「*AWS Organizations ユーザーガイド*」の「[サポートされている宣言型ポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples)」セクションにある「**インスタンスメタデータ**」タブを参照してください。
強制適用が取り消されないようにするため、IAM ポリシーを使用して [ModifyInstanceMetadataDefaults](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataDefaults.html) API へのアクセスを防ぐ必要があります。詳細については「[IAM ポリシーを使用する](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-iam-policy)」を参照してください。
**注記**
この設定は既存のインスタンスの IMDS バージョンを変更しませんが、IMDSv1 が現在無効になっている既存のインスタンスでの IMDSv1 の有効化が阻止されます。
**警告**
IMDSv2 の強制適用が有効になっており、`httpTokens` が起動時のインスタンス設定、アカウント設定、または AMI 構成のいずれかで `required` に設定されていない場合、インスタンスの起動は失敗します。トラブルシューティング情報については、「[IMDSv1 が有効化されたインスタンスの起動が失敗する](troubleshooting-launch.md#launching-an-imdsv1-enabled-instance-fails)」を参照してください。
1. **別の手段として、次の IAM または SCP 条件キーを用いて IMDSv2 を強制適用します。**
+ `ec2:MetadataHttpTokens`
+ `ec2:MetadataHttpPutResponseHopLimit`
+ `ec2:MetadataHttpEndpoint`
これらの条件キーは [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html) API と [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html) API、および対応する CLI の使用を制御します。ポリシーを作成し、条件キーを使用してポリシーに指定した状態と API コールのパラメータが一致しない場合、API コールまたは CLI コールは失敗して `UnauthorizedOperation` レスポンスが返されます。
IAM ポリシーの例は[インスタンスメタデータの使用](ExamplePolicies_EC2.md#iam-example-instance-metadata)を参照してください。
# インスタンスメタデータサービスへのアクセスを制限する
ローカルファイアウォールルールを使って、プロセスの一部またはすべてからインスタンスメタデータサービス (IMDS) へのアクセスを無効化することを検討できます。
[Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)ではVPC 内のネットワークアプライアンス (仮想ルーターなど) がパケットを IMDS アドレスに転送し、かつ、インスタンス上のデフォルトの[送信元/送信先チェック](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck)が無効な場合、IMDS がユーザー自身のネットワークから到達可能になります。VPC の外側にある送信元から IMDS に到達しないようにするには送信先 IMDS の IPv4 アドレスが `169.254.169.254` (IPv6 エンドポイントを有効にしている場合はIMDS の IPv6 アドレスが `[fd00:ec2::254]`) であるパケットをドロップするように、ネットワークアプライアンスの設定を変更することをお勧めします。
## Linux インスタンスの IMDS アクセスを制限する
**iptables を使ったアクセス制限**
次の例ではLinux iptables およびその`owner`モジュールを使って、Apache ウェブサーバーが (デフォルトインストールユーザー ID `apache`に基づいて) 169.254.169.254 にアクセスするのを防ぐことができます。*拒否ルール*を使って、そのユーザーとして実行中のプロセスからのインスタンスメタデータリクエスト (IMDSv1またはIMDSv2) をすべて拒否します。
```
$ sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner --uid-owner apache --jump REJECT
```
また、*ルールの許可*を使うことで、特定のユーザーまたはグループへのアクセスを許可することを検討できます。ルールの許可はどのソフトウェアがインスタンスメタデータへのアクセスが必要かについてユーザーが決定しなければならないため、セキュリティ観点からみたときに管理しやすいかもしれません。*ルールの許可* を使用すると、後にインスタンスのソフトウェアまたは構成を変更した場合に、誤ってソフトウェアがメタデータサービス (アクセスする意図がなかった) にアクセスするのを許可する可能性が低くなります。また、ファイアウォールのルールを変更しなくても許可されたグループにユーザーを追加/削除できるよう、グループ使用をルールの許可と組み合わせることもできます。
次の例ではユーザーアカウント `trustworthy-user` で実行中のプロセス以外のすべてのプロセスによる IMDS へのアクセスを禁止しています。
```
$ sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner ! --uid-owner trustworthy-user --jump REJECT
```
**注記**
ローカルファイアウォールルールを使用するには前の例のコマンドをニーズに合わせて変更する必要があります。
デフォルトではiptables ルールはシステム再起動全体で永続しません。ここには説明されていない OS 機能を使って永続的にすることができます。
iptables `owner`モジュールはグループが所定のローカルユーザーのプライマリグループである場合にのみツールメンバーシップと一致します。他のグループは一致しません。
**PF または IPFW を使ってアクセスを制限する**
FreeBSD または OpenBSD を使用している場合、PF または IPFW の使用も検討できます。次の例ではIMDS へのアクセスをルートユーザーにのみ制限しています。
**PF**
```
$ block out inet proto tcp from any to 169.254.169.254
```
```
$ pass out inet proto tcp from any to 169.254.169.254 user root
```
**IPFW**
```
$ allow tcp from any to 169.254.169.254 uid root
```
```
$ deny tcp from any to 169.254.169.254
```
**注記**
PF および IPFW コマンドの順序は重要となります。PF のデフォルトは最後に一致したルールであり、IPFW のデフォルトは最初に一致したルールです。
## Windows インスタンスの IMDS アクセスを制限する
**Windows ファイアウォールを使ってアクセスを制限する**
次の PowerShell 例では組み込み Windows ファイアウォールを使って、インターネット情報サービスウェブサーバー (デフォルトインストールユーザー ID の`NT AUTHORITY\IUSR`に基づいて) が 169.254.169.254 にアクセスするのを防いでいます。*拒否ルール*を使って、そのユーザーとして実行中のプロセスからのインスタンスメタデータリクエスト (IMDSv1またはIMDSv2) をすべて拒否します。
```
PS C:\> $blockPrincipal = New-Object -TypeName System.Security.Principal.NTAccount ("NT AUTHORITY\IUSR")
PS C:\> $BlockPrincipalSID = $blockPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value
PS C:\> $BlockPrincipalSDDL = "D:(A;;CC;;;$BlockPrincipalSID)"
PS C:\> New-NetFirewallRule -DisplayName "Block metadata service from IIS" -Action block -Direction out `
-Protocol TCP -RemoteAddress 169.254.169.254 -LocalUser $BlockPrincipalSDDL
```
また、*ルールの許可*を使うことで、特定のユーザーまたはグループへのアクセスを許可することを検討できます。ルールの許可はどのソフトウェアがインスタンスメタデータへのアクセスが必要かについてユーザーが決定しなければならないため、セキュリティ観点からみたときに管理しやすいかもしれません。*ルールの許可* を使用すると、後にインスタンスのソフトウェアまたは構成を変更した場合に、誤ってソフトウェアがメタデータサービス (アクセスする意図がなかった) にアクセスするのを許可する可能性が低くなります。また、ファイアウォールのルールを変更しなくても許可されたグループにユーザーを追加/削除できるよう、グループ使用をルールの許可と組み合わせることもできます。
次の例では`exceptionPrincipal`で指定したプロセス (この例では`trustworthy-users`と呼ばれるグループ) 以外の、変数 `blockPrincipal` (この例では Windows グループ`Everyone`) で指定された OS グループとして実行中のすべてのプロセスによるインスタンスメタデータへのアクセスを禁止しています。Windows ファイアウォールはLinux iptables の`! --uid-owner trustworthy-user`とは異なり、その他すべてを拒否することにより、特定のプリンシパル (ユーザーまたはグループ) のみを許可するショートカット機構を提供しないため、拒否と許可プリンシパルの両方を指定する必要があります。
```
PS C:\> $blockPrincipal = New-Object -TypeName System.Security.Principal.NTAccount ("Everyone")
PS C:\> $BlockPrincipalSID = $blockPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value
PS C:\> $exceptionPrincipal = New-Object -TypeName System.Security.Principal.NTAccount ("trustworthy-users")
PS C:\> $ExceptionPrincipalSID = $exceptionPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value
PS C:\> $PrincipalSDDL = "O:LSD:(D;;CC;;;$ExceptionPrincipalSID)(A;;CC;;;$BlockPrincipalSID)"
PS C:\> New-NetFirewallRule -DisplayName "Block metadata service for $($blockPrincipal.Value), exception: $($exceptionPrincipal.Value)" -Action block -Direction out `
-Protocol TCP -RemoteAddress 169.254.169.254 -LocalUser $PrincipalSDDL
```
**注記**
ローカルファイアウォールルールを使用するには前の例のコマンドをニーズに合わせて変更する必要があります。
**netsh ルールを使ってアクセスを制限する**
`netsh`ルールを使ってすべてのソフトウェアをブロックすることを検討できますが、柔軟性は大幅に低下します。
```
C:\> netsh advfirewall firewall add rule name="Block metadata service altogether" dir=out protocol=TCP remoteip=169.254.169.254 action=block
```
**注記**
ローカルファイアウォールルールを使用するには前の例のコマンドをニーズに合わせて変更する必要があります。
`netsh`ルールは elevated コマンドプロンプトから設定する必要があり、拒否または許可の特定のプリンシパルに設定できません。
# インスタンスメタデータサービスのオプションを設定する
インスタンスメタデータサービス (IMDS) はすべての EC2 インスタンスでローカルに実行されます。*インスタンスメタデータオプション*はEC2 インスタンス上の IMDS のアクセシビリティと動作を制御する一連の設定を参照してください。
各インスタンスで、以下のインスタンスメタデータオプションを設定できます。
**[インスタンスメタデータサービス (IMDS)]**: `enabled` \$1 `disabled`
インスタンスで IMDS を有効または無効にすることができます。無効にすると、ユーザーまたはコードはインスタンスのインスタンスメタデータにアクセスできなくなります。
IMDS のインスタンスにはIPv4 (`169.254.169.254`) と IPv6 (`[fd00:ec2::254]`) という 2 つのエンドポイントがあります。IMDS を有効にすると、IPv4 エンドポイントが自動的に有効になります。IPv6 エンドポイントを有効にする場合は明示的に有効にする必要があります。
**[IMDS IPv6 エンドポイント]**: `enabled` \$1 `disabled`
インスタンスで IPv6 IMDS エンドポイントを明示的に有効にできます。IPv6 エンドポイントが有効になっている場合、IPv4 エンドポイントは有効なままになります。IPv6 エンドポイントは[Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)と [IPv6 対応サブネット](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) (デュアルスタックまたは IPv6 のみ) でのみサポートされています。
**[メタデータのバージョン]**: `IMDSv1 or IMDSv2 (token optional)` \$1 `IMDSv2 only (token required)`
インスタンスメタデータをリクエストするとき、IMDSv2 呼び出しはトークンを要求します。IMDSv1 呼び出はトークンを要求しません。IMDSv1 または IMDSv2 呼び出しを許可する (トークンがオプションの場合) か、IMDSv2 呼び出しのみを許可する (トークンが必須の場合) ように、インスタンスを設定できます。
**[メタデータレスポンスのホップ制限]**: `1`～`64`
ホップ制限はPUT レスポンスが実行できるネットワークホップの数です。ホップ制限は最小 `1`、最大 `64` に設定できます。コンテナ環境では、`1` のホップ制限によって問題が発生する可能性があります。これらの問題を軽減する方法については、[インスタンスメタデータアクセス考慮事項](instancedata-data-retrieval.md#imds-considerations) でコンテナ環境に関する情報を参照してください。
**[インスタンスメタデータ内のタグにアクセスする]**: `enabled` \$1 `disabled`
インスタンスのメタデータからインスタンスのタグへのアクセスを有効または無効にすることができます。詳細については[インスタンスメタデータを使用して EC2 インスタンスのタグを表示する](work-with-tags-in-IMDS.md) を参照してください。
インスタンスの現在の設定を確認するには、「[既存インスタンスのインスタンスメタデータオプションのクエリ](instancedata-data-retrieval.md#query-IMDS-existing-instances)」を参照してください。
## インスタンスメタデータオプションを設定する場所
インスタンスメタデータオプションは次のようにさまざまなレベルで設定できます。
+ **アカウント** – 各 AWS リージョンのアカウントレベルで、インスタンスメタデータオプションのデフォルト値を設定できます。インスタンスが起動すると、インスタンスメタデータオプションは自動的にアカウントレベルの値に設定されます。これらの値は起動時に変更できます。アカウントレベルのデフォルト値は既存のインスタンスには影響しません。
+ **AMI** – AMI を登録または変更するときに、`imds-support` パラメータを `v2.0` に設定できます。この AMI でインスタンスを起動すると、インスタンスメタデータバージョンは自動的に「IMDSv2」に設定され、ホップ制限は「2」に設定されます。
+ **インスタンス** – 起動時にインスタンスのすべてのインスタンスメタデータオプションを変更し、デフォルト設定を上書きできます。実行中または停止中のインスタンスで起動した後に、インスタンスメタデータオプションを変更することもできます。変更は IAM または SCP ポリシーによって制限される可能性があることに注意してください。
詳細については[新規インスタンスのインスタンスメタデータオプションの設定](configuring-IMDS-new-instances.md)および[既存インスタンスのインスタンスメタデータオプションの変更](configuring-IMDS-existing-instances.md)を参照してください。
## インスタンスメタデータオプションの優先順位
各インスタンスメタデータオプションの値はインスタンスの起動時に優先順位に従って決定されます。最上位の優先順位を持つ階層は次のとおりです。
+ **優先順位 1: 起動時のインスタンス設定** – 値は起動テンプレートまたはインスタンス設定のいずれかで指定できます。ここで指定された値はアカウントレベルまたは AMI で指定された値を上書きします。
+ **優先順位 2: アカウント設定** – インスタンスの起動時に値が指定されていない場合はアカウントレベルの設定 (AWS リージョンごとに設定) によって値が決まります。アカウントレベルの設定では各メタデータオプションの値が含まれているか、まったく指定がないことが示されるかのどちらかです。
+ **優先順位 3: AMI 設定** – インスタンスの起動時に、またはアカウントレベルで値が指定されていない場合はAMI 設定によって値が決まります。これは`HttpTokens` と `HttpPutResponseHopLimit` にのみ該当します。
各メタデータオプションは個別に評価されます。インスタンスは直接インスタンス設定、アカウントレベルのデフォルト、および AMI からの設定を組み合わせて設定できます。
IAM または SCP ポリシーによって変更が制限されていない限り、実行中または停止中のインスタンスで起動した後に、任意のメタデータオプションの値を変更できます。
**注記**
アカウントレベルでの IMDSv2 の強制適用設定の評価は、優先順位によってインスタンスの IMDS 設定が判断された後で行われます。IMDSv2 の強制適用を有効にすると、IMDSv1 が有効化されているインスタンスは失敗します。強制適用に関する詳細については、「[アカウントレベルで IMDSv2 を強制適用する](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level)」を参照してください。
**警告**
IMDSv2 の強制適用が有効になっており、`httpTokens` が起動時のインスタンス設定、アカウント設定、または AMI 構成のいずれかで `required` に設定されていない場合、起動は失敗します。
**例 1 – メタデータオプションの値を判断する**
この例ではEC2 インスタンスはアカウントレベルで `HttpPutResponseHopLimit` が `1` に設定されているリージョンで起動されます。指定された AMI では`ImdsSupport` が `v2.0` に設定されています。起動時に、インスタンスでメタデータオプションが直接指定されることはありません。インスタンスは次のメタデータオプションを使用して起動されます。
```
"MetadataOptions": {
...
"HttpTokens": "required",
"HttpPutResponseHopLimit": 1,
...
```
これらの値は次のように決定されました。
+ **起動時にメタデータオプションが指定されていない:** インスタンスの起動時に、メタデータオプションの特定の値が、インスタンス起動パラメータにも、起動テンプレートにも指定されていませんでした。
+ **アカウント設定が次に優先される:** 起動時に特定の値が指定されていない場合はリージョン内のアカウントレベルの設定が優先されます。つまり、アカウントレベルで設定されたデフォルト値が適用されます。この場合は`HttpPutResponseHopLimit` が `1` に設定されました。
+ **AMI 設定が最後に優先される:** 起動時またはアカウントレベルで `HttpTokens` (インスタンスメタデータバージョン) に特定の値が指定されていない場合はAMI 設定が適用されます。この場合はAMI 設定 `ImdsSupport: v2.0` により、`HttpTokens` が `required` に設定されました。AMI 設定 `ImdsSupport: v2.0` は `HttpPutResponseHopLimit: 2` 設定するように設計されていますが、優先順位の高いアカウントレベルの設定 `HttpPutResponseHopLimit: 1` によって上書きれることに注意してください。
**例 2 – メタデータオプションの値を判断する**
この例ではEC2 インスタンスは前の例 1 と同じ設定で起動されますが、起動時にインスタンスで直接 `HttpTokens` が `optional` に設定されています。インスタンスは次のメタデータオプションを使用して起動されます。
```
"MetadataOptions": {
...
"HttpTokens": "optional",
"HttpPutResponseHopLimit": 1,
...
```
`HttpPutResponseHopLimit` の値は例 1 と同じ方法で決定されます。ただし、`HttpTokens` の値は次のように決定されます。起動時にインスタンスで設定されているメタデータオプションが最優先されます。AMI が `ImdsSupport: v2.0` で設定されている (つまり、`HttpTokens` が `required` に設定されている) 場合でも、起動時にインスタンスで指定されている値 (`HttpTokens` が `optional` に設定されている) が優先されます。
**例 3 – HttpTokensEnforced が有効化されているメタデータオプションの値を判断する**
この例では、リージョン内のアカウントに `HttpTokens = required` と `HttpTokensEnforced = enabled` があります。
次の EC2 インスタンス起動試行を検討します。
+ `HttpTokens` を `optional` に設定した起動試行 – アカウントレベルでの強制適用が有効 (`HttpTokensEnforced = enabled`) になっており、アカウントのデフォルトよりも起動パラメータが優先されるため、起動が失敗します。
+ `HttpTokens` を `required` に設定した起動試行 — アカウントレベルの強制適用に従っているため、起動は正常に行われます。
+ `HttpTokens` 値が指定されていない起動試行 – 値はアカウント設定に基づいてデフォルトの `required` になるため、起動は正常に行われます。
### インスタンスのメタデータバージョンを設定する
インスタンスの起動時におけるインスタンス*メタデータバージョン*の値は、**[IMDSv1 または IMDSv2 (トークンはオプション)]** (`httpTokens=optional`) か **[IMDSv2 のみ (トークンは必須)]** (`httpTokens=required`) のいずれかになります。
インスタンスの起動時に、メタデータバージョンの値を手動で指定するか、デフォルト値を使用できます。値を手動で指定すると、すべてのデフォルト値が上書きされます。値を手動で指定しないことを選択した場合は、デフォルト設定の組み合わせによって判断されます。
次のフローチャートは、起動時におけるインスタンスメタデータバージョンが、構成の異なるレベルでの設定と、強制適用が評価される場所によって判断される仕組みを示しています。次の表は、各レベル固有の設定を示しています。
![\[インスタンスメタデータバージョンと IMDSv2 の強制適用の評価ポイントを示すフローチャート。\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/imds-defaults-launch-flow.png)
この表は起動時のインスタンスのメタデータバージョン (列 4 の **[結果として生じるインスタンス設定]** で示される) が、さまざまなレベルの設定によってどのように決定されるかを示しています。優先順位は左から右で、次のように最初の列が最も優先されます。
+ 列 1: **[起動パラメータ]** - 起動時に手動で指定するインスタンスの設定を表します。
+ 列 2: **[アカウントレベルのデフォルト]** - アカウントの設定を表します。
+ 列 3: **[AMI のデフォルト]** - AMI の設定を表します。
| 起動パラメータ | アカウントレベルのデフォルト | AMI のデフォルト | 結果として生じるインスタンス設定 |
| --- | --- | --- | --- |
| V2 のみ (トークンが必要) | 指定なし | V2 のみ | V2 のみ |
| V2 のみ (トークンが必要) | V2 のみ | V2 のみ | V2 のみ |
| V2 のみ (トークンが必要) | V1 または V2 | V2 のみ | V2 のみ |
| V1 または V2 (トークンはオプション) | 指定なし | V2 のみ | V1 または V2 |
| V1 または V2 (トークンはオプション) | V2 のみ | V2 のみ | V1 または V2 |
| V1 または V2 (トークンはオプション) | V1 または V2 | V2 のみ | V1 または V2 |
| 未設定 | 指定なし | V2 のみ | V2 のみ |
| 未設定 | V2 のみ | V2 のみ | V2 のみ |
| 未設定 | V1 または V2 | V2 のみ | V1 または V2 |
| V2 のみ (トークンが必要) | 指定なし | null | V2 のみ |
| V2 のみ (トークンが必要) | V2 のみ | null | V2 のみ |
| V2 のみ (トークンが必要) | V1 または V2 | null | V2 のみ |
| V1 または V2 (トークンはオプション) | 指定なし | null | V1 または V2 |
| V1 または V2 (トークンはオプション) | V2 のみ | null | V1 または V2 |
| V1 または V2 (トークンはオプション) | V1 または V2 | null | V1 または V2 |
| 未設定 | 指定なし | null | V1 または V2 |
| 未設定 | V2 のみ | null | V2 のみ |
| 未設定 | V1 または V2 | null | V1 または V2 |
## IAM 条件キーを使用してインスタンスメタデータオプションを制限する
IAM ポリシーまたは SCP で IAM 条件キーを次のように使用できます。
+ IMDSv2 の使用を要求するようにインスタンスが設定されている場合にのみ、インスタンスの起動を許可する
+ ホップの許可数を制限する
+ インスタンスメタデータへのアクセスを無効にする
**Topics**
+ [
## インスタンスメタデータオプションを設定する場所
](#where-to-configure-instance-metadata-options)
+ [
## インスタンスメタデータオプションの優先順位
](#instance-metadata-options-order-of-precedence)
+ [
## IAM 条件キーを使用してインスタンスメタデータオプションを制限する
](#iam-condition-keys-and-imds)
+ [
# 新規インスタンスのインスタンスメタデータオプションの設定
](configuring-IMDS-new-instances.md)
+ [
# 既存インスタンスのインスタンスメタデータオプションの変更
](configuring-IMDS-existing-instances.md)
**注記**
注意深く実行し、変更を行う前に慎重なテストを実施する必要があります。以下の情報を記録します。
IMDSv2の使用を強制する場合、インスタンスメタデータアクセスのためにIMDSv1を使用するアプリケーションまたはエージェントは休憩します。
インスタンスメタデータへのアクセスをすべてオフにする場合、インスタンスメタデータアクセスに依存して機能するアプリケーションまたはエージェントは休憩します。
IMDSv2 でトークンを取得する際には`/latest/api/token` を使用する必要があります｡
(Windows のみ) PowerShell のバージョンが 4.0 より前の場合はIMDSv2 の使用を要求するために [Windows Management Framework 4.0 に更新](https://devblogs.microsoft.com/powershell/windows-management-framework-wmf-4-0-update-now-available-for-windows-server-2012-windows-server-2008-r2-sp1-and-windows-7-sp1/)する必要があります。
# 新規インスタンスのインスタンスメタデータオプションの設定
新規インスタンスに、以下のインスタンスメタデータオプションを設定できます。
**Topics**
+ [
## IMDSv2 の使用を要求する
](#configure-IMDS-new-instances)
+ [
## IMDS IPv4 および IPv6 エンドポイントを有効にする
](#configure-IMDS-new-instances-ipv4-ipv6-endpoints)
+ [
## インスタンスメタデータへのアクセスを無効にする
](#configure-IMDS-new-instances--turn-off-instance-metadata)
+ [
## インスタンスメタデータのタグへのアクセスを許可する
](#configure-IMDS-new-instances-tags-in-instance-metadata)
**注記**
これらのオプションの設定はアカウントレベルで直接、または宣言ポリシーを使用して設定されます。これらはインスタンスメタデータオプションを設定する各 AWS リージョン で設定する必要があります。宣言型ポリシーを使用すると、複数の リージョンと複数の アカウントで同時に設定を適用できます。宣言ポリシーが使用されている場合、アカウント内で直接設定を変更することはできません。このトピックでは、アカウント内で設定を直接設定する方法について説明します。宣言ポリシーの使用の詳細については*AWS Organizations「 ユーザーガイド」*の[「宣言ポリシー」](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html)を参照してください。
## IMDSv2 の使用を要求する
次の方法を使用して、新しいインスタンスで IMDSv2 の使用を必須にすることができます。
**Topics**
+ [
### IMDSv2 をアカウントのデフォルトとして設定する
](#set-imdsv2-account-defaults)
+ [
### アカウントレベルで IMDSv2 を強制適用する
](#enforce-imdsv2-at-the-account-level)
+ [
### 起動時にインスタンスを設定する
](#configure-IMDS-new-instances-instance-settings)
+ [
### AMI を設定する
](#configure-IMDS-new-instances-ami-configuration)
+ [
### IAM ポリシーを使用する
](#configure-IMDS-new-instances-iam-policy)
### IMDSv2 をアカウントのデフォルトとして設定する
インスタンスメタデータサービス (IMDS) のデフォルトバージョンは各 AWS リージョンのアカウントレベルで設定できます。つまり、*新規*インスタンスを起動すると、そのインスタンスメタデータバージョンは自動的にアカウントレベルのデフォルトに設定されます。ただし、起動時または起動後に値を手動で上書きできます。アカウントレベルの設定と手動オーバーライドがインスタンスに与える影響の詳細については「[インスタンスメタデータオプションの優先順位](configuring-instance-metadata-options.md#instance-metadata-options-order-of-precedence)」を参照してください。
**注記**
アカウントレベルのデフォルトを設定しても、*既存の*インスタンスはリセットされません。例えば、アカウントレベルのデフォルトを IMDSv2 に設定しても、IMDSv1 に設定されている既存のインスタンスは影響を受けません。既存のインスタンスの値を変更する場合はインスタンス自体の値を手動で変更する必要があります。
インスタンスメタデータバージョンのアカウントのデフォルトを IMDSv2 に設定すると、アカウント内のすべての*新しい*インスタンスを IMDSv2 で起動できます。そうすると、IMDSv1 は無効になります。このアカウントデフォルトではインスタンスを起動すると、インスタンスのデフォルト値は次のようになります。
+ コンソール: **[メタデータのバージョン]** は **[V2 のみ (トークンは必須)]** に設定され、**[メタデータレスポンスのホップ制限]** は **[2]** に設定されます。
+ AWS CLI: `HttpTokens` は `required` に設定され、`HttpPutResponseHopLimit` は `2` に設定されます。
**注記**
アカウントのデフォルトを IMDSv2 に設定する前に、インスタンスが IMDSv1 に依存していないことを確認してください。詳細については「[IMDSv2 を必要とする推奨パス](instance-metadata-transition-to-version-2.md#recommended-path-for-requiring-imdsv2)」を参照してください。
------
#### [ Console ]
**指定したリージョンのアカウントのデフォルトとして IMDSv2 を設定するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. AWS リージョン を変更するにはページの右上隅にあるリージョンセレクターを使用します。
1. ナビゲーションペインで、**ダッシュボード**を選択してください。
1. **[アカウント属性]** カードの **[設定]** で、**[データ保護とセキュリティ]** を選択します。
1. **[IMDS のデフォルト]** の横にある **[管理]** を選択してください。
1. **[IMDS のデフォルトを管理]** ページで、次の操作を実行します。
1. **[インスタンスメタデータサービス]** で、**[有効にする]** を選択してください。
1. **[Metadata version]** (メタデータバージョン) には**[V2 only (token required)**] (V2 のみ (トークンが必要)) を選択してください。
1. インスタンスがコンテナをホストする場合は**[メタデータレスポンスのホップ制限]** で **2** を指定します。それ以外の場合は**[設定なし]** を選択してください。設定なしが指定されているとき、AMI に `ImdsSupport: v2.0` の設定がある場合は起動時の値がデフォルトで **2** になります。それ以外の場合はデフォルトで **1** になります。
1. **[Update]** (更新) を選択してください。
------
#### [ AWS CLI ]
**指定したリージョンのアカウントのデフォルトとして IMDSv2 を設定するには**
[modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html) コマンドを使用して、IMDS アカウントレベルの設定を変更するリージョンを指定します。インスタンスがコンテナをホストする場合は`--http-tokens` を `required` に、`--http-put-response-hop-limit` を `2` に設定します。それ以外の場合は`-1` を指定して、設定がないことを示します。`-1` (設定なし) が指定されているとき、AMI に `ImdsSupport: v2.0` の設定がある場合は起動時の値がデフォルトで `2` になります。それ以外の場合はデフォルトで `1` になります。
```
aws ec2 modify-instance-metadata-defaults \
--region us-east-1 \
--http-tokens required \
--http-put-response-hop-limit 2
```
出力例を次に示します。
```
{
"Return": true
}
```
**指定したリージョンのインスタンスメタデータオプションのデフォルトのアカウント設定を表示するには**
[get-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-metadata-defaults.html) コマンドを使用して、リージョンを指定します。
```
aws ec2 get-instance-metadata-defaults --region us-east-1
```
出力例を次に示します。
```
{
"AccountLevel": {
"HttpTokens": "required",
"HttpPutResponseHopLimit": 2
},
"ManagedBy": "account"
}
```
`ManagedBy` フィールドは設定を設定したエンティティを示します。この例では `account`は設定がアカウントで直接設定されたことを示します。`declarative-policy`という値は宣言的ポリシーによって設定が構成されたことを意味します。詳細については「*AWS OrganizationsIAM ユーザーガイド*」の「[ マネージドポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html)」を参照してください。
**すべてのリージョンのアカウントのデフォルトとして IMDSv2 を設定するには**
すべてのリージョンの IMDS アカウントレベル設定を変更するには[modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html) コマンドを使用します。インスタンスがコンテナをホストする場合は`--http-tokens` を `required` に、`--http-put-response-hop-limit` を `2` に設定します。それ以外の場合は`-1` を指定して、設定がないことを示します。`-1` (設定なし) が指定されているとき、AMI に `ImdsSupport: v2.0` の設定がある場合は起動時の値がデフォルトで `2` になります。それ以外の場合はデフォルトで `1` になります。
```
echo -e "Region \t Modified" ; \
echo -e "-------------- \t ---------" ; \
for region in $(
aws ec2 describe-regions \
--region us-east-1 \
--query "Regions[*].[RegionName]" \
--output text
);
do (output=$(
aws ec2 modify-instance-metadata-defaults \
--region $region \
--http-tokens required \
--http-put-response-hop-limit 2 \
--output text)
echo -e "$region \t $output"
);
done
```
出力例を次に示します。
```
Region Modified
-------------- ---------
ap-south-1 True
eu-north-1 True
eu-west-3 True
...
```
**すべてのリージョンのインスタンスメタデータオプションのデフォルトアカウント設定を表示するには**
[get-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-metadata-defaults.html) コマンドを使用します。
```
echo -e "Region \t Level Hops HttpTokens" ; \
echo -e "-------------- \t ------------ ---- ----------" ; \
for region in $(
aws ec2 describe-regions \
--region us-east-1 \
--query "Regions[*].[RegionName]" \
--output text
);
do (output=$(
aws ec2 get-instance-metadata-defaults \
--region $region \
--output text)
echo -e "$region \t $output"
);
done
```
出力例を次に示します。
```
Region Level Hops HttpTokens
-------------- ------------ ---- ----------
ap-south-1 ACCOUNTLEVEL 2 required
eu-north-1 ACCOUNTLEVEL 2 required
eu-west-3 ACCOUNTLEVEL 2 required
...
```
------
#### [ PowerShell ]
**指定したリージョンのアカウントのデフォルトとして IMDSv2 を設定するには**
[Edit-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataDefault.html) コマンドレットを使用して、IMDS アカウントレベルの設定を変更するリージョンを指定します。インスタンスがコンテナをホストする場合は`-HttpToken` を `required` に、`-HttpPutResponseHopLimit` を `2` に設定します。それ以外の場合は`-1` を指定して、設定がないことを示します。`-1` (設定なし) が指定されているとき、AMI に `ImdsSupport: v2.0` の設定がある場合は起動時の値がデフォルトで `2` になります。それ以外の場合はデフォルトで `1` になります。
```
Edit-EC2InstanceMetadataDefault `
-Region us-east-1 `
-HttpToken required `
-HttpPutResponseHopLimit 2
```
出力例を次に示します。
```
True
```
**指定したリージョンのインスタンスメタデータオプションのデフォルトのアカウント設定を表示するには**
[Get-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceMetadataDefault.html) コマンドレットを使用して、リージョンを指定します。
```
Get-EC2InstanceMetadataDefault -Region us-east-1 | Format-List
```
出力例を次に示します。
```
HttpEndpoint :
HttpPutResponseHopLimit : 2
HttpTokens : required
InstanceMetadataTags :
```
**すべてのリージョンのアカウントのデフォルトとして IMDSv2 を設定するには**
[Edit-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataDefault.html) コマンドレットを使用して、すべてのリージョンの IMDS アカウントレベル設定を変更します。インスタンスがコンテナをホストする場合は`-HttpToken` を `required` に、`-HttpPutResponseHopLimit` を `2` に設定します。それ以外の場合は`-1` を指定して、設定がないことを示します。`-1` (設定なし) が指定されているとき、AMI に `ImdsSupport: v2.0` の設定がある場合は起動時の値がデフォルトで `2` になります。それ以外の場合はデフォルトで `1` になります。
```
(Get-EC2Region).RegionName | `
ForEach-Object {
[PSCustomObject]@{
Region = $_
Modified = (Edit-EC2InstanceMetadataDefault `
-Region $_ `
-HttpToken required `
-HttpPutResponseHopLimit 2)
}
} | `
Format-Table Region, Modified -AutoSize
```
正常な出力
```
Region Modified
------ --------
ap-south-1 True
eu-north-1 True
eu-west-3 True
...
```
**すべてのリージョンのインスタンスメタデータオプションのデフォルトアカウント設定を表示するには**
[Get-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceMetadataDefault.html) コマンドレットを使用します。
```
(Get-EC2Region).RegionName | `
ForEach-Object {
[PSCustomObject]@{
Region = $_
HttpPutResponseHopLimit = (Get-EC2InstanceMetadataDefault -Region $_).HttpPutResponseHopLimit
HttpTokens = (Get-EC2InstanceMetadataDefault -Region $_).HttpTokens
}
} | `
Format-Table -AutoSize
```
出力の例
```
Region HttpPutResponseHopLimit HttpTokens
------ ----------------------- ----------
ap-south-1 2 required
eu-north-1 2 required
eu-west-3 2 required
...
```
------
### アカウントレベルで IMDSv2 を強制適用する
各 AWS リージョンに対し、アカウントレベルで IMDSv2 の使用を強制できます。使用が強制されると、インスタンスを起動できるのは IMDSv2 が必須として設定されている場合のみになります。この強制は、インスタンスまたは AMI の設定方法を問わずに適用されます。
**注記**
アカウントレベルで IMDSv2 の強制適用を有効にする前に、アプリケーションと AMI が IMDSv2 をサポートしていることを確認してください。詳細については「[IMDSv2 を必要とする推奨パス](instance-metadata-transition-to-version-2.md#recommended-path-for-requiring-imdsv2)」を参照してください。IMDSv2 の強制適用が有効になっており、`httpTokens` が起動時のインスタンス設定、アカウント設定、または AMI 構成のいずれかで `required` に設定されていない場合、インスタンスの起動は失敗します。トラブルシューティング情報については、「[IMDSv1 が有効化されたインスタンスの起動が失敗する](troubleshooting-launch.md#launching-an-imdsv1-enabled-instance-fails)」を参照してください。
**注記**
この設定は既存のインスタンスの IMDS バージョンを変更しませんが、IMDSv1 が現在無効になっている既存のインスタンスでの IMDSv1 の有効化を阻止します。
------
#### [ Console ]
**指定されたリージョン内のアカウントに IMDSv2 を強制適用する**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. AWS リージョンを変更するには、ページの右上隅にあるリージョンセレクターを使用します。
1. ナビゲーションペインで、**ダッシュボード**を選択してください。
1. **[アカウント属性]** カードの **[設定]** で、**[データ保護とセキュリティ]** を選択します。
1. **[IMDS のデフォルト]** の横にある **[管理]** を選択してください。
1. **[IMDS のデフォルトを管理]** ページで、次の操作を実行します。
1. **[Metadata version]** (メタデータバージョン) には**[V2 only (token required)**] (V2 のみ (トークンが必要)) を選択してください。
1. **[IMDSv2 を強制適用]** で **[有効]** を選択します。
1. **[Update]** (更新) を選択してください。
------
#### [ AWS CLI ]
**指定されたリージョン内のアカウントに IMDSv2 を強制適用する**
[modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html) コマンドを使用して、IMDSv2 を強制適用するリージョンを指定します。
```
aws ec2 modify-instance-metadata-defaults \
--region us-east-1 \
--http-tokens required \
--http-tokens-enforced enabled
```
出力例を次に示します。
```
{
"Return": true
}
```
**特定のリージョン内のアカウントに対する IMDSv2 の強制適用設定を表示する**
[get-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-metadata-defaults.html) コマンドを使用して、リージョンを指定します。
```
aws ec2 get-instance-metadata-defaults --region us-east-1
```
出力例を次に示します。
```
{
"AccountLevel": {
"HttpTokens": "required",
"HttpTokensEnforced": "enabled"
},
"ManagedBy": "account"
}
```
`ManagedBy` フィールドは設定を設定したエンティティを示します。この例では `account`は設定がアカウントで直接設定されたことを示します。`declarative-policy`という値は宣言的ポリシーによって設定が構成されたことを意味します。詳細については、「*AWS Organizations ユーザーガイド*」の「[宣言型ポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html)」を参照してください。
**すべてのリージョンのアカウントに IMDSv2 を強制適用する**
[modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html) コマンドを使用して、すべてのリージョンで IMDSv2 を強制適用します。
```
echo -e "Region \t Modified" ; \
echo -e "-------------- \t ---------" ; \
for region in $(
aws ec2 describe-regions \
--region us-east-1 \
--query "Regions[*].[RegionName]" \
--output text
);
do (output=$(
aws ec2 modify-instance-metadata-defaults \
--region $region \
--http-tokens-enforced enabled \
--output text)
echo -e "$region \t $output"
);
done
```
出力例を次に示します。
```
Region Modified
-------------- ---------
ap-south-1 True
eu-north-1 True
eu-west-3 True
...
```
**すべてのリージョン内のアカウントに対する IMDSv2 の強制適用設定を表示する**
[get-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-metadata-defaults.html) コマンドを使用します。
```
echo -e "Region \t Level HttpTokensEnforced" ; \
echo -e "-------------- \t ------------ ----------------" ; \
for region in $(
aws ec2 describe-regions \
--region us-east-1 \
--query "Regions[*].[RegionName]" \
--output text
);
do (output=$(
aws ec2 get-instance-metadata-defaults \
--region $region \
--query 'AccountLevel.HttpTokensEnforced' \
--output text)
echo -e "$region \t ACCOUNTLEVEL $output"
);
done
```
出力例を次に示します。
```
Region Level HttpTokensEnforced
-------------- ------------ ------------------
ap-south-1 ACCOUNTLEVEL enabled
eu-north-1 ACCOUNTLEVEL enabled
eu-west-3 ACCOUNTLEVEL enabled
...
```
------
#### [ PowerShell ]
**指定されたリージョン内のアカウントに IMDSv2 を強制適用する**
[Edit-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataDefault.html) コマンドレットを使用して、IMDSv2 を強制適用するリージョンを指定します。
```
Edit-EC2InstanceMetadataDefault `
-Region us-east-1 `
-HttpToken required `
-HttpPutResponseHopLimit 2
```
出力例を次に示します。
```
@{
Return = $true
}
```
**特定のリージョン内のアカウントに対する IMDSv2 の強制適用設定を表示する**
Get-EC2InstanceMetadataDefault コマンドを使用して、リージョンを指定します。
```
Get-EC2InstanceMetadataDefault -Region us-east-1
```
出力例を次に示します。
```
@{
AccountLevel = @{
HttpTokens = "required"
HttpTokensEnforced = "enabled"
}
ManagedBy = "account"
}
```
`ManagedBy` フィールドは設定を設定したエンティティを示します。この例では `account`は設定がアカウントで直接設定されたことを示します。`declarative-policy`という値は宣言的ポリシーによって設定が構成されたことを意味します。詳細については、「*AWS Organizations ユーザーガイド*」の「[宣言型ポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html)」を参照してください。
**すべてのリージョンのアカウントに IMDSv2 を強制適用する**
[modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html) コマンドを使用して、すべてのリージョンで IMDSv2 を強制適用します。
```
echo -e "Region \t Modified" ; \
echo -e "-------------- \t ---------" ; \
for region in $(
aws ec2 describe-regions \
--region us-east-1 \
--query "Regions[*].[RegionName]" \
--output text
);
do (output=$(
aws ec2 modify-instance-metadata-defaults \
--region $region \
--http-tokens-enforced enabled \
--output text)
echo -e "$region \t $output"
);
done
```
出力例を次に示します。
```
Region Modified
-------------- ---------
ap-south-1 True
eu-north-1 True
eu-west-3 True
...
```
**すべてのリージョンのアカウントのデフォルトとして IMDSv2 を設定するには**
[Edit-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataDefault.html) コマンドレットを使用して、すべてのリージョンの IMDS アカウントレベル設定を変更します。インスタンスがコンテナをホストする場合は`-HttpToken` を `required` に、`-HttpPutResponseHopLimit` を `2` に設定します。それ以外の場合は`-1` を指定して、設定がないことを示します。`-1` (設定なし) が指定されているとき、AMI に `ImdsSupport: v2.0` の設定がある場合は起動時の値がデフォルトで `2` になります。それ以外の場合はデフォルトで `1` になります。
```
(Get-EC2Region).RegionName | `
ForEach-Object {
[PSCustomObject]@{
Region = $_
Modified = (Edit-EC2InstanceMetadataDefault `
-Region $_ `
-HttpToken required `
-HttpPutResponseHopLimit 2)
}
} | `
Format-Table Region, Modified -AutoSize
```
正常な出力
```
Region Modified
------ --------
ap-south-1 True
eu-north-1 True
eu-west-3 True
...
```
**すべてのリージョンのインスタンスメタデータオプションのデフォルトアカウント設定を表示するには**
[Get-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceMetadataDefault.html) コマンドレットを使用します。
```
(Get-EC2Region).RegionName | `
ForEach-Object {
[PSCustomObject]@{
Region = $_
HttpPutResponseHopLimit = (Get-EC2InstanceMetadataDefault -Region $_).HttpPutResponseHopLimit
HttpTokens = (Get-EC2InstanceMetadataDefault -Region $_).HttpTokens
}
} | `
Format-Table -AutoSize
```
出力の例
```
Region HttpPutResponseHopLimit HttpTokens
------ ----------------------- ----------
ap-south-1 2 required
eu-north-1 2 required
eu-west-3 2 required
...
```
------
### 起動時にインスタンスを設定する
[インスタンスを起動](ec2-launch-instance-wizard.md)する際に、以下のフィールドを設定しておくことで、IMDSv2 が使用されるようにそのインスタンスを構成できます。
+ Amazon EC2 コンソール: **[Metadata version]** (メタデータバージョン) で、**[V2 only (token required)]** (V2 のみ (トークンが必須)) を設定します。
+ AWS CLI: `HttpTokens` に `required` を設定します。
IMDSv2 が必須であることを指定する場合、**[メタデータにアクセス可能]** に **[有効]** (コンソールの場合) を設定するか、`HttpEndpoint` に `enabled` (AWS CLI の場合) を設定して、インスタンスメタデータサービス (IMDS) のエンドポイントも有効にする必要があります。
コンテナ環境ではIMDSv2 が要求されている場合、ホップ制限を `2` に設定することをお勧めします。詳細については「[インスタンスメタデータアクセス考慮事項](instancedata-data-retrieval.md#imds-considerations)」を参照してください。
------
#### [ Console ]
**新しいインスタンスで IMDSv2 の使用を要求するには**
+ Amazon EC2 コンソールで新しいインスタンスを起動するとき、**[Advanced details]** (高度な詳細) を展開し、次の操作を行います。
+ **[Metadata accessible]** (メタデータにアクセス可能) には**[Enabled]** (有効) を選択してください。
+ **[Metadata version]** (メタデータバージョン) には**[V2 only (token required)**] (V2 のみ (トークンが必要)) を選択してください。
+ (コンテナ環境) **[メタデータレスポンスのホップ制限]** で、**2** を選択してください。
詳細については「[高度な詳細](ec2-instance-launch-parameters.md#liw-advanced-details)」を参照してください。
------
#### [ AWS CLI ]
**新しいインスタンスで IMDSv2 の使用を要求するには**
次の [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) の例では`c6i.large` を `--metadata-options` に設定して `HttpTokens=required` インスタンスを起動します。`HttpTokens` の値を指定する場合は`HttpEndpoint` も `enabled` に設定する必要があります。メタデータの取得リクエストではセキュリティで保護されたトークンヘッダーは `required` に設定されるので、インスタンスメタデータのリクエストに際してはそのインスタンスは必ず IMDSv2 を使用することになります。
コンテナ環境ではIMDSv2 が要求されている場合、`HttpPutResponseHopLimit=2` を使用してホップ制限を `2` に設定することをお勧めします。
```
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--instance-type c6i.large \
...
--metadata-options "HttpEndpoint=enabled,HttpTokens=required,HttpPutResponseHopLimit=2"
```
------
#### [ PowerShell ]
**新しいインスタンスで IMDSv2 の使用を要求するには**
次の [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html) コマンドレット例は、`MetadataOptions_HttpEndpoint` が `enabled` に、`MetadataOptions_HttpTokens` パラメータが `required` に設定された `c6i.large` インスタンスを起動します。`HttpTokens` の値を指定する場合は`HttpEndpoint` も `enabled` に設定する必要があります。メタデータの取得リクエストではセキュリティで保護されたトークンヘッダーは `required` に設定されるので、インスタンスメタデータのリクエストに際してはそのインスタンスは必ず IMDSv2 を使用することになります。
```
New-EC2Instance `
-ImageId ami-0abcdef1234567890 `
-InstanceType c6i.large `
-MetadataOptions_HttpEndpoint enabled `
-MetadataOptions_HttpTokens required
```
------
#### [ CloudFormation ]
CloudFormation を使用してインスタンスのメタデータオプションを指定するには「AWS CloudFormation ユーザーガイド**」の「[AWS::EC2::LaunchTemplate MetadataOptions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html)」プロパティを参照してください。
------
### AMI を設定する
新しい AMI を登録したり、既存の AMI を変更したりするときに、`imds-support` パラメータを `v2.0` に設定できます。この AMI から起動されたインスタンスでは、**[メタデータのバージョン]** が **[V2 のみ (トークンは必須)]** (コンソールの場合) に設定されるか、`HttpTokens` が `required` (AWS CLI の場合) に設定されます。この設定が行われている場合、インスタンスメタデータがリクエストされる際には IMDSv2 を使用することが、インスタンスでの必須になります。
この AMI から起動されるインスタンスでは`imds-support` に `v2.0` を設定している場合、**[Metadata response hop limit]** (メタデータレスポンスのホップ制限) (コンソールの場合)、または `http-put-response-hop-limit` (AWS CLI の場合) が「**2**」に設定されることに注意してください。
**重要**
ご使用の AMI ソフトウェアが IMDSv2 をサポートしていない限りはこのパラメータを使用しないでください。値を `v2.0` に設定すると、元に戻すことはできません。AMI を「リセット」する唯一の方法は基礎となるスナップショットから新しい AMI を作成することです。
**IMDSv2 向けに AMI を新たに設定するには**
IMDSv2 に新しい AMI を設定するには次のいずれかの方法を使用します。
------
#### [ AWS CLI ]
以下の [register-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html) の例ではEBS ルートボリュームの指定されたスナップショットをデバイス `/dev/xvda` として使用して、AMI を登録しています。`imds-support` パラメータ用に `v2.0` を指定し、この AMI から起動するインスタンスに対して、インスタンスメタデータのリクエスト時に IMDSv2 を使用することが、この AMI から起動されるインスタンスでの必須になります。
```
aws ec2 register-image \
--name my-image \
--root-device-name /dev/xvda \
--block-device-mappings DeviceName=/dev/xvda,Ebs={SnapshotId=snap-0123456789example} \
--architecture x86_64 \
--imds-support v2.0
```
------
#### [ PowerShell ]
次の [Register-EC2Image](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-EC2Image.html) コマンドレット例は、EBS ルートボリュームの指定されたスナップショットをデバイス `/dev/xvda` として使用して、AMI を登録します。`ImdsSupport` パラメータ用に `v2.0` を指定し、この AMI から起動するインスタンスに対して、インスタンスメタデータのリクエスト時に IMDSv2 を使用することが、この AMI から起動されるインスタンスでの必須になります。
```
Register-EC2Image `
-Name 'my-image' `
-RootDeviceName /dev/xvda `
-BlockDeviceMapping (
New-Object `
-TypeName Amazon.EC2.Model.BlockDeviceMapping `
-Property @{
DeviceName = '/dev/xvda';
EBS = (New-Object -TypeName Amazon.EC2.Model.EbsBlockDevice -Property @{
SnapshotId = 'snap-0123456789example'
VolumeType = 'gp3'
} )
} ) `
-Architecture X86_64 `
-ImdsSupport v2.0
```
------
**IMDSv2 向けに既存の AMI を設定するには**
IMDSv2 向けに既存の AMI を設定するには次のいずれかの方法を使用します。
------
#### [ AWS CLI ]
次の [modify-image-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-image-attribute.html) の例ではIMDSv2 用の既存の AMI のみを変更します。`imds-support` パラメータ用に `v2.0` を指定し、この AMI から起動するインスタンスに対して、インスタンスメタデータのリクエスト時に IMDSv2 を使用することが、この AMI から起動されるインスタンスでの必須になります。
```
aws ec2 modify-image-attribute \
--image-id ami-0abcdef1234567890 \
--imds-support v2.0
```
------
#### [ PowerShell ]
次の [Edit-EC2ImageAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2ImageAttribute.html) コマンドレット例は、IMDSv2 用の既存の AMI のみを変更します。`imds-support` パラメータ用に `v2.0` を指定し、この AMI から起動するインスタンスに対して、インスタンスメタデータのリクエスト時に IMDSv2 を使用することが、この AMI から起動されるインスタンスでの必須になります。
```
Edit-EC2ImageAttribute `
-ImageId ami-0abcdef1234567890 `
-ImdsSupport 'v2.0'
```
------
### IAM ポリシーを使用する
次のいずれかを実行する IAM ポリシーを作成できます。
+ 新しいインスタンスで IMDSv2 を必須と設定する場合を除き、ユーザーが新しいインスタンスを起動することを防ぐ。
+ ユーザーが ModifyInstanceMetadataOptions API をユ呼び出して実行中のインスタンスのメタデータオプションを変更することを防ぐ。ModifyInstanceMetadataOptions httpTokens プロパティへのアクセスを制限して、実行中のインスタンスの意図しない更新が行われないようにする。
+ ユーザーが ModifyInstanceMetadataDefaults API を呼び出して httpTokens と httpTokensEnforced 両方のアカウントデフォルト設定を変更することを防ぐ。これらの 2 つのプロパティへのアクセスを制限することで、承認済みのロール以外はアカウントのデフォルトを変更できないようにします。
**IAM ポリシーにより、すべての新しいインスタンスでの IMDSv2 の使用を必須にするには**
ユーザーが起動できるインスタンスを、メタデータのリクエスト時に IMDSv2 の使用を必須としているインスタンスに限定するには、次の手順を実行します。
+ `ModifyInstanceMetadataOptions` と `ModifyInstanceMetadataDefaults` API の両方、より具体的には `httpTokens` と `httpTokensEnforced` プロパティへのアクセスを制限します。
+ 次に、アカウントのデフォルトを `httpTokens = required` と `httpTokensEnforced = enabled` に設定します。
IAM ポリシーの例については[インスタンスメタデータの使用](ExamplePolicies_EC2.md#iam-example-instance-metadata)を参照してください。
## IMDS IPv4 および IPv6 エンドポイントを有効にする
IMDS のインスタンスにはIPv4 (`169.254.169.254`) と IPv6 (`[fd00:ec2::254]`) という 2 つのエンドポイントがあります。IMDS を有効にすると、IPv4 エンドポイントが自動的に有効になります。IPv6 専用サブネットに対してインスタンスを起動しても、その IPv6 エンドポイントは無効のままになります。IPv6 エンドポイントを有効にするには明示的に有効にする必要があります。IPv6 エンドポイントを有効にしても、IPv4 エンドポイントは有効なままになります。
IPv6 エンドポイントはインスタンス起動時またはその後に有効にできます。
**IPv6 エンドポイントを有効にするための要件**
+ 選択されているインスタンスタイプは [Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)です。
+ 選択したサブネットはそのサブネットが[デュアルスタックまたは IPv6 専用](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range)である場合、IPv6 をサポートします。
IMDS IPv6 エンドポイント対応のインスタンスを起動するには以下のいずれかの方法を使用します。
------
#### [ Console ]
**インスタンス起動時に IMDS IPv6 エンドポイントを有効にするには**
+ **[Advanced details]** (高度な詳細) で以下のように指定して、Amazon EC2 コンソールで[インスタンスを起動](ec2-launch-instance-wizard.md)します。
+ **メタデータ IPv6 エンドポイント **で、**[有効]** を選択します。
詳細については「[高度な詳細](ec2-instance-launch-parameters.md#liw-advanced-details)」を参照してください。
------
#### [ AWS CLI ]
**インスタンス起動時に IMDS IPv6 エンドポイントを有効にするには**
以下の [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) の例ではIMDS 用に IPv6 エンドポイントが有効化された、`c6i.large` インスタンスを起動しています。IPv6 エンドポイントを有効にするには`--metadata-options` パラメータに `HttpProtocolIpv6=enabled` を指定します。`HttpProtocolIpv6` の値を指定する場合は`HttpEndpoint` も `enabled` に設定する必要があります。
```
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--instance-type c6i.large \
...
--metadata-options "HttpEndpoint=enabled,HttpProtocolIpv6=enabled"
```
------
#### [ PowerShell ]
**インスタンス起動時に IMDS IPv6 エンドポイントを有効にするには**
次の [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html) コマンドレット例は、IMDS 用に IPv6 エンドポイントが有効化された `c6i.large` インスタンスを起動します。IPv6 エンドポイントを有効にするには`MetadataOptions_HttpProtocolIpv6` を `enabled` に指定します。`MetadataOptions_HttpProtocolIpv6` の値を指定する場合は`MetadataOptions_HttpEndpoint` も `enabled` に設定する必要があります。
```
New-EC2Instance `
-ImageId ami-0abcdef1234567890 `
-InstanceType c6i.large `
-MetadataOptions_HttpEndpoint enabled `
-MetadataOptions_HttpProtocolIpv6 enabled
```
------
## インスタンスメタデータへのアクセスを無効にする
インスタンスを起動するときに IMDS を無効にすることで、インスタンスのメタデータへのアクセスを無効にできます。IMDS を再度有効にすると、その後でアクセスを有効にできます。詳細については「[インスタンスメタデータへのアクセスを有効にする](configuring-IMDS-existing-instances.md#enable-instance-metadata-on-existing-instances)」を参照してください。
**重要**
IMDS は起動時または起動後に無効化できます。*起動時に* IMDS を無効にすると、以下が機能しなくなる可能性があります。
インスタンスへの SSH アクセスがない可能性があります。キーは通常 EC2 インスタンスのメタデータから提供され、アクセスされるため、インスタンスのパブリック SSH キーである `public-keys/0/openssh-key` にはアクセスできません。
EC2 ユーザーデータは利用できず、インスタンスの起動時には実行されません。EC2 ユーザーデータは IMDS でホストされます。IMDS を無効にすると、ユーザーデータへのアクセスは事実上無効になります。
この機能にアクセスするには起動後に IMDS を再度有効にします。
------
#### [ Console ]
**起動時にインスタンスメタデータへのアクセスを無効にするには**
+ **[Advanced details]** (高度な詳細) で以下のように指定して、Amazon EC2 コンソールで[インスタンスを起動](ec2-launch-instance-wizard.md)します。
+ **[Metadata accessible]** (メタデータにアクセス可能) には**[Disabled]** (無効) を選択してください。
詳細については「[高度な詳細](ec2-instance-launch-parameters.md#liw-advanced-details)」を参照してください。
------
#### [ AWS CLI ]
**起動時にインスタンスメタデータへのアクセスを無効にするには**
`--metadata-options` に `HttpEndpoint=disabled` を設定し、インスタンスを起動します。
```
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--instance-type c6i.large \
...
--metadata-options "HttpEndpoint=disabled"
```
------
#### [ PowerShell ]
**起動時にインスタンスメタデータへのアクセスを無効にするには**
次の [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html) コマンドレット例は、`MetadataOptions_HttpEndpoint` が `disabled` に設定されたインスタンスを起動します。
```
New-EC2Instance `
-ImageId ami-0abcdef1234567890 `
-InstanceType c6i.large `
-MetadataOptions_HttpEndpoint disabled
```
------
#### [ CloudFormation ]
CloudFormation を使用してインスタンスのメタデータオプションを指定するには「CloudFormation ユーザーガイド**」の「[AWS::EC2::LaunchTemplate MetadataOptions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html)」プロパティを参照してください。
------
## インスタンスメタデータのタグへのアクセスを許可する
デフォルトではインスタンスメタデータ内のインスタンスタグへはアクセスできません。インスタンスごとに、アクセスを明示的に許可する必要があります。アクセスが許可されている場合、インスタンスタグ*キー*は特定の文字制限に準拠している必要があります。それ以外の場合はインスタンスの起動に失敗します。詳細については「[インスタンスメタデータ内のタグへのアクセスを有効にする](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS)」を参照してください。
# 既存インスタンスのインスタンスメタデータオプションの変更
既存のインスタンスのインスタンスメタデータオプションを変更することが可能です。
また、既存のインスタンスでインスタンスメタデータオプションを変更することをユーザーに禁止する IAM ポリシーを作成することもできます。インスタンスメタデータオプションを変更できるユーザーをコントロールするには指定したロールを持つユーザー以外のすべてのユーザーに [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html) API の使用を禁止するポリシーを指定できます。IAM ポリシーの例については[インスタンスメタデータの使用](ExamplePolicies_EC2.md#iam-example-instance-metadata)を参照してください。
**注記**
宣言ポリシーを使用してインスタンスメタデータオプションを設定した場合、アカウント内で直接変更することはできません。詳細については「*AWS OrganizationsIAM ユーザーガイド*」の「[ マネージドポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html)」を参照してください。
## IMDSv2 の使用を要求する
既存のインスタンスに対して、インスタンスメタデータのリクエスト時に IMDSv2 が使用されるようにするため、既存のインスタンスメタデータオプションを変更します。IMDSv2 が必須である場合、IMDSv1 は使用できません。
**注記**
IMDSv2 の使用を要求する前に、インスタンスが IMDSv1 呼び出しを行っていないことを確認してください。`MetadataNoToken` CloudWatch メトリクスは IMDSv1 呼び出しを追跡します。あるインスタンスの `MetadataNoToken` で IMDSv1 の使用量がゼロと記録されている場合はそのインスタンスは IMDSv2 を要求できます。
------
#### [ Console ]
**既存インスタンスでの IMDSv2 の使用を義務付けるには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、**[Instances]** (インスタンス) を選択してください。
1. インスタンスを選択してください。
1. **[アクション]**、**[インスタンスの設定]**、**[インスタンスメタデータのオプションを変更]** の順に選択してください。
1. **[インスタンスメタデータオプションの変更]** ダイアログボックスで、次の操作を行います。
1. **[インスタンスメタデータサービス]** で、**[有効にする]** を選択してください。
1. **[IMDSv2]** の場合は**[必須]** を選択してください。
1. [**Save**] を選択してください。
------
#### [ AWS CLI ]
**既存インスタンスでの IMDSv2 の使用を義務付けるには**
[modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) CLI コマンドを使って、`http-tokens` パラメータを `required` に設定できます。`http-tokens` の値を指定する場合は`http-endpoint` も `enabled` に設定する必要があります。
```
aws ec2 modify-instance-metadata-options \
--instance-id i-1234567890abcdef0 \
--http-tokens required \
--http-endpoint enabled
```
------
#### [ PowerShell ]
**既存インスタンスでの IMDSv2 の使用を義務付けるには**
[Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html) コマンドレットを使用して、`HttpTokens` パラメータを `required` に設定します。`HttpTokens` の値を指定する場合は`HttpEndpoint` も `enabled` に設定する必要があります。
```
(Edit-EC2InstanceMetadataOption `
-InstanceId i-1234567890abcdef0 `
-HttpTokens required `
-HttpEndpoint enabled).InstanceMetadataOptions
```
------
## IMDSv1 の使用を再開します
インスタンスで IMDSv2 が必須となっている場合、IMDSv1 リクエストの使用は失敗します。IMDSv2 がオプションである場合、IMDSv2 と IMDSv1 の両方が機能します。このため、IMDSv1 を復元するには、次のいずれかの方法を使用して IMDSv2 をオプション (`httpTokens = optional`) として設定します。
`httpTokensEnforced` IMDS プロパティも、既存のインスタンスで IMDSv1 を有効化する試みを阻止します。リージョン内のアカウントに対して有効化されているときに `httpTokens` を `optional` に設定しようとすると、`UnsupportedOperation` 例外が発生します。詳細については、「[トラブルシューティング](#troubleshoot-modifying-an-imdsv1-enabled-instance-fails)」を参照してください。
**重要**
IMDSv2 の強制適用が原因でインスタンスの起動が失敗する場合は、起動を正常に行うための 2 つのオプションがあります。
**インスタンスを IMDSv2 のみとして起動する** – インスタンスで実行されているソフトウェアが IMDSv2 のみを使用している (IMDSv1 に対する依存なし) 場合、インスタンスを IMDSv2 のみとして起動できます。これを実行するには、リージョン内のアカウントの起動パラメータまたはメタデータデフォルトのいずれかで `httpTokens = required` を設定することによって IMDSv2 のみに設定します。
**強制適用を無効にする** – ソフトウェアが依然として IMDSv1 に依存している場合は、リージョン内のアカウントで `httpTokensEnforced` を `disabled` に設定します。詳細については「[アカウントレベルで IMDSv2 を強制適用する](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level)」を参照してください。
------
#### [ Console ]
**インスタンスで IMDSv1 の使用を復元するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、**[Instances]** (インスタンス) を選択してください。
1. インスタンスを選択してください。
1. **[アクション]**、**[インスタンスの設定]**、**[インスタンスメタデータのオプションを変更]** の順に選択してください。
1. **[インスタンスメタデータオプションの変更]** ダイアログボックスで、次の操作を行います。
1. **[インスタンスメタデータサービス]** で、**[有効にする]** が選択されていることを確認します。
1. **[IMDSv2]** の場合は**[オプション]** を選択してください。
1. [**Save**] を選択してください。
------
#### [ AWS CLI ]
**インスタンスで IMDSv1 の使用を復元するには**
[modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) CLI コマンドを、`http-tokens` を `optional` に設定して実行すると、インスタンスメタデータのリクエスト時に IMDSv1 の使用を復元できます。
```
aws ec2 modify-instance-metadata-options \
--instance-id i-1234567890abcdef0 \
--http-tokens optional \
--http-endpoint enabled
```
------
#### [ PowerShell ]
**インスタンスで IMDSv1 の使用を復元するには**
`HttpTokens` を `optional` に設定した [Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html) コマンドレットを使用して、インスタンスメタデータのリクエスト時に IMDSv1 の使用を復元できます。
```
(Edit-EC2InstanceMetadataOption `
-InstanceId i-1234567890abcdef0 `
-HttpTokens optional `
-HttpEndpoint enabled).InstanceMetadataOptions
```
------
## PUT レスポンスホップリミットを変更する
既存インスタンスについて、`PUT`リスポンスホップリミットの設定を変更することができます。
現在、PUT 応答ホップ制限の変更をサポートしているのはAWS CLI と AWS SDK のみです。
------
#### [ AWS CLI ]
**PUT レスポンスホップリミットを変更するには**
[modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) CLI コマンドを使って、`http-put-response-hop-limit` パラメータを必要なホップ数に設定できます。以下の例ではホップリミットが`3`に設定されています。`http-put-response-hop-limit` の値を指定する場合は`http-endpoint` を `enabled` に設定することも必要です。
```
aws ec2 modify-instance-metadata-options \
--instance-id i-1234567890abcdef0 \
--http-put-response-hop-limit 3 \
--http-endpoint enabled
```
------
#### [ PowerShell ]
**PUT レスポンスホップリミットを変更するには**
[Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html) コマンドレットを使用して、`HttpPutResponseHopLimit` パラメータを必要なホップ数に設定します。以下の例ではホップリミットが`3`に設定されています。`HttpPutResponseHopLimit` の値を指定する場合は`HttpEndpoint` を `enabled` に設定することも必要です。
```
(Edit-EC2InstanceMetadataOption `
-InstanceId i-1234567890abcdef0 `
-HttpPutResponseHopLimit 3 `
-HttpEndpoint enabled).InstanceMetadataOptions
```
------
## IMDS IPv4 および IPv6 エンドポイントを有効にする
IMDS のインスタンスにはIPv4 (`169.254.169.254`) と IPv6 (`[fd00:ec2::254]`) という 2 つのエンドポイントがあります。IMDS を有効にすると、IPv4 エンドポイントが自動的に有効になります。IPv6 専用サブネットに対してインスタンスを起動しても、その IPv6 エンドポイントは無効のままになります。IPv6 エンドポイントを有効にするには明示的に有効にする必要があります。IPv6 エンドポイントを有効にしても、IPv4 エンドポイントは有効なままになります。
IPv6 エンドポイントはインスタンス起動時またはその後に有効にできます。
**IPv6 エンドポイントを有効にするための要件**
+ 選択されているインスタンスタイプは [Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)です。
+ 選択したサブネットはそのサブネットが[デュアルスタックまたは IPv6 専用](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range)である場合、IPv6 をサポートします。
現在、AWS CLI と AWS SDK のみがインスタンス起動後の IMDS IPv6 エンドポイントの有効化をサポートします。
------
#### [ AWS CLI ]
**インスタンスで IMDS IPv6 エンドポイントを有効にするには**
[modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) CLI コマンドを使って、`http-protocol-ipv6` パラメータを `enabled` に設定できます。`http-protocol-ipv6` の値を指定する場合は`http-endpoint` を `enabled` に設定することも必要です。
```
aws ec2 modify-instance-metadata-options \
--instance-id i-1234567890abcdef0 \
--http-protocol-ipv6 enabled \
--http-endpoint enabled
```
------
#### [ PowerShell ]
**インスタンスで IMDS IPv6 エンドポイントを有効にするには**
[Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html) コマンドレットを使用して、`HttpProtocolIpv6` パラメータを `enabled` に設定します。`HttpProtocolIpv6` の値を指定する場合は`HttpEndpoint` を `enabled` に設定することも必要です。
```
(Edit-EC2InstanceMetadataOption `
-InstanceId i-1234567890abcdef0 `
-HttpProtocolIpv6 enabled `
-HttpEndpoint enabled).InstanceMetadataOptions
```
------
## インスタンスメタデータへのアクセスを有効にする
使用中の IMDS のバージョンに関係なく、IMDS の HTTP エンドポイントを無効にすることによりインスタンスメタデータへのアクセスをオフにすることができます。HTTP エンドポイントを無効化することにより、この変更はいつでも元に戻すことができます。
次のいずれかの方法を使用して、インスタンスのインスタンスメタデータへのアクセスを有効にします。
------
#### [ Console ]
**インスタンスメタデータへのアクセスを有効にするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、**[Instances]** (インスタンス) を選択してください。
1. インスタンスを選択してください。
1. **[アクション]**、**[インスタンスの設定]**、**[インスタンスメタデータのオプションを変更]** の順に選択してください。
1. **[インスタンスメタデータオプションの変更]** ダイアログボックスで、次の操作を行います。
1. **[インスタンスメタデータサービス]** で、**[有効にする]** を選択してください。
1. [**Save**] を選択してください。
------
#### [ AWS CLI ]
**インスタンスメタデータへのアクセスを有効にするには**
[modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) CLI コマンドを使って、`http-endpoint` パラメータを `enabled` に設定できます。
```
aws ec2 modify-instance-metadata-options \
--instance-id i-1234567890abcdef0 \
--http-endpoint enabled
```
------
#### [ PowerShell ]
**インスタンスメタデータへのアクセスを有効にするには**
[Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html) コマンドレットを使用して、`HttpEndpoint` パラメータを `enabled` に設定します。
```
(Edit-EC2InstanceMetadataOption `
-InstanceId i-1234567890abcdef0 `
-HttpEndpoint enabled).InstanceMetadataOptions
```
------
## インスタンスメタデータへのアクセスを無効にする
使用中のインスタンスメタデータサービスのバージョンに関係なく、IMDS の HTTP エンドポイントを無効にすることにより IMDS へのアクセスをオフにすることができます。HTTP エンドポイントを有効化することにより、この変更はいつでも元に戻すことができます。
インスタンスのインスタンスメタデータへのアクセスを無効にするには次のいずれかの方法を使用します。
------
#### [ Console ]
**インスタンスメタデータへのアクセスを無効にするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、**[Instances]** (インスタンス) を選択してください。
1. インスタンスを選択してください。
1. **[アクション]**、**[インスタンスの設定]**、**[インスタンスメタデータのオプションを変更]** の順に選択してください。
1. **[インスタンスメタデータオプションの変更]** ダイアログボックスで、次の操作を行います。
1. **[インスタンスメタデータサービス]** では**[有効にする]** をオフにします。
1. [**Save**] を選択してください。
------
#### [ AWS CLI ]
**インスタンスメタデータへのアクセスを無効にするには**
[modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) CLI コマンドを使って、`http-endpoint` パラメータを `disabled` に設定できます。
```
aws ec2 modify-instance-metadata-options \
--instance-id i-1234567890abcdef0 \
--http-endpoint disabled
```
------
#### [ PowerShell ]
**インスタンスメタデータへのアクセスを無効にするには**
[Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html) コマンドレットを使用して、`HttpEndpoint` パラメータを `disabled` に設定します。
```
(Edit-EC2InstanceMetadataOption `
-InstanceId i-1234567890abcdef0 `
-HttpEndpoint disabled).InstanceMetadataOptions
```
------
## インスタンスメタデータのタグへのアクセスを許可する
実行中または停止中のインスタンス上のインスタンスメタデータ内のタグへのアクセスを許可できます。インスタンスごとに、アクセスを明示的に許可する必要があります。アクセスが許可されている場合、インスタンスタグ*キー*は特定の文字制限に準拠している必要があります。それ以外の場合はエラーが発生します。詳細については「[インスタンスメタデータ内のタグへのアクセスを有効にする](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS)」を参照してください。
## トラブルシューティング
### IMDSv1 が有効化されたインスタンスの変更が失敗する
#### 説明
以下のエラーメッセージが表示されます。
`You can't launch instances with IMDSv1 because httpTokensEnforced is enabled for this account. Either launch the instance with httpTokens=required or contact your account owner to disable httpTokensEnforced using the ModifyInstanceMetadataDefaults API or the account settings in the EC2 console.`
#### 原因
このエラーは、EC2 アカウント設定または AWS Organization 宣言型ポリシーが IMDSv2 の使用を強制する (`httpTokensEnforced = enabled`) アカウントで既存のインスタンスを IMDSv1 有効 (`httpTokens = optional`) に変更しようとするときにスローされます。
#### ソリューション
既存のインスタンスで IMDSv1 サポートが必要な場合は、リージョン内のアカウントで IMDSv2 の強制適用を無効にする必要があります。IMDSv2 の強制適用を無効にするには、`HttpTokensEnforced` を `disabled`.に設定します。詳細については、「Amazon EC2 API リファレンス」の「[ModifyInstanceMetadataDefaults](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataDefaults.html)」を参照してください。この設定をコンソールを使用して行う場合は、「[アカウントレベルで IMDSv2 を強制適用する](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level)」を参照してください。
IMDSv2 のみ (`httpTokens=required`) を使用することをお勧めします。詳細については「[インスタンスメタデータサービスバージョン 2 の使用への移行](instance-metadata-transition-to-version-2.md)」を参照してください。
# ユーザーデータ入力を使用して EC2 インスタンスを起動するときにコマンドを実行する
Amazon EC2 インスタンスの起動時に、インスタンスの起動後に自動設定タスクを実行したり、スクリプトを実行したりするのに使用するインスタンスにユーザーデータを渡すことができます。
より複雑なオートメーションのシナリオに興味がある場合、CloudFormation を検討してください。詳細については、「*AWS CloudFormation ユーザーガイド*」の「[CloudFormation を使用して Amazon EC2 でアプリケーションのデプロイ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/deploying.applications.html)」を参照してください。
Linux インスタンスでは、シェルスクリプトと cloud-init ディレクティブという 2 つのタイプのユーザーデータを Amazon EC2 に渡すことができます。また、このデータは、プレーンテキスト、ファイル (コマンドラインツールを使用してインスタンスを起動する場合に便利です)、または base64 でエンコードされたテキスト (API コール向け) で、インスタンス起動ウィザードに渡すこともできます。
Windows インスタンスでは、起動エージェントがユーザーデータスクリプトを処理します。
**考慮事項**
+ ユーザーデータは非透過的なデータとして取り扱われ、指定したデータがそのまま返されます。インスタンスによって解釈が異なります。
+ ユーザーデータはbase64 でエンコードされている必要があります。Amazon EC2 コンソールは base64 エンコードを実行したり、base64 エンコード入力を受け入れたりできます。インスタンスのメタデータまたはコンソールを使用してユーザーデータを取得する場合、自動的に base64 でデコードされます。
+ ユーザーデータは raw 形式の 16 KB に制限されます (以前は base64 エンコード)。base64 エンコード後の 文字列の長さサイズ *n* はceil(*n*/3)\$14 です。
+ ユーザーデータはインスタンス属性です。インスタンスから AMI を作成する場合、インスタンスのユーザーデータは AMI に含まれません。
## AWS マネジメントコンソール のユーザーデータ
インスタンスの起動時のインスタンスユーザーデータを指定できます。インスタンスのルートボリュームが EBS ボリュームの場合は、インスタンスを停止してユーザーデータを更新することもできます。
### Launch Wizard を使用して起動時にインスタンスのユーザーデータを指定する
EC2 コンソールで Launch Wizard を使用してインスタンスを起動するときに、ユーザーデータを指定できます。起動時にユーザーデータを指定するには、[インスタンスを起動する](ec2-launch-instance-wizard.md)手順に従います。**[User data]** (ユーザーデータ) フィールドは、インスタンス起動ウィザードの [高度な詳細](ec2-instance-launch-parameters.md#liw-advanced-details) セクションにあります。PowerShell スクリプトを **[ユーザーデータ]** フィールドに入力し、インスタンスの起動手順を完了します。
次の **[ユーザーデータ]** フィールドのスクリーンショットのスクリプト例では、ファイル名に現在の日付と時刻を使用して、Windows 一時フォルダーにファイルを作成します。`true` を含めると、インスタンスを再起動または起動するたびにスクリプトが実行されます。**[ユーザーデータは既に base64 でエンコードされています]** チェックボックスをオフのままにした場合、Amazon EC2 コンソールがユーザーに代わって base64 エンコードを実行します。
![\[Advance Details ユーザーデータテキストフィールド。\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/configure_ec2config_userdata.png)
詳細については、「[Launch Wizard を使用して起動時にインスタンスのユーザーデータを指定する](#user-data-launch-instance-wizard)」を参照してください。AWS CLI を使用するの Linux の例については、「[ユーザーデータと AWS CLI](#user-data-api-cli)」を参照してください。Windows PowerShell用ツール を使用する Windows の例については、「[ユーザーデータと Windows PowerShell用ツール](#user-data-powershell)」を参照してください。
### インスタンスユーザーデータの表示と更新
任意のインスタンスのインスタンスユーザーデータを表示し、停止したインスタンスのインスタンスユーザーデータを更新できます。
**コンソールを使用してインスタンスユーザーデータを更新するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. インスタンスを選択し、[**Actions (アクション)**]、[**Instance state (インスタンスの状態)**]、[**Stop instance (インスタンスの停止)**] の順に選択してください。
**警告**
インスタンスストアボリューム上のデータは、インスタンスを停止すると失われます。このデータを保持するには、永続ストレージにバックアップしてください。
1. 確認を求められたら、[**Stop**] を選択してください。インスタンスが停止するまで、数分かかる場合があります。
1. インスタンスが選択された状態のまま、[**Actions (アクション)**]、[**Instance settings (インスタンス設定)**]、[**Edit user data (ユーザーデータの編集)**] の順に選択してください。インスタンスの実行中はユーザーデータを変更できませんが、表示することはできます。
1. [**Edit user data (ユーザーデータの編集)**] ダイアログボックスで、ユーザーデータを更新し、[**Save (保存)**] を選択してください。インスタンスを再起動または起動するたびにユーザーデータスクリプトを実行するには、次の例に示すように `true` をユーザーデータに追加します。
![\[[Edit User Data] (ユーザデータの編集) ダイアログボックス。\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/view-change-user-data.png)
1. インスタンスを起動します。後続の再起動または開始のためにユーザーデータの実行を有効にした場合、更新されたユーザーデータスクリプトはインスタンスの開始プロセスの一部として実行されます。
## Amazon EC2 が Linux インスタンスのユーザーデータを処理する方法
次の例は、ユーザーデータを使用して、インスタンスの起動時に LAMP サーバーをセットアップするコマンドを実行します。各例では、次のタスクが実行されます。
+ ディストリビューションソフトウェアパッケージが更新されます。
+ ウェブサーバー、`php`、`mariadb` パッケージがインストールされます。
+ `httpd` サービスが開始され、有効になります。
+ ユーザー `ec2-user` が apache グループに追加されます。
+ ウェブディレクトリとその中に含まれるファイルに対して、適切な所有権とファイル権限が設定されます。
+ ウェブサーバーと PHP エンジンをテストするために、シンプルなウェブページが作成されます。
**Topics**
+ [
### 前提条件
](#user-data-requirements)
+ [
### ユーザーデータとシェルスクリプト
](#user-data-shell-scripts)
+ [
### インスタンスのユーザーデータを更新する
](#user-data-modify)
+ [
### ユーザーデータと cloud-init ディレクティブ
](#user-data-cloud-init)
+ [
### ユーザーデータと AWS CLI
](#user-data-api-cli)
+ [
### シェルスクリプトと cloud-init ディレクティブを組み合わせる
](#user-data-mime-multi)
### 前提条件
このトピックの例では、
+ インスタンスには、インターネットからアクセス可能なパブリック DNS 名が設定されていることを前提にしています。
+ インスタンスに関連付けられたセキュリティグループは、SSH (ポート 22) トラフィックを許可するように設定されているため、インスタンスに接続して出力ログファイルを表示できます。
+ Amazon Linux AMI を使用してインスタンスが起動します。コマンドとディレクティブは、他の Linux ディストリビューションでは機能しないことがあります。cloud-init のサポートなど、その他のディストリビューションについての詳細は、特定のディストリビューションのドキュメントを参照してください。
### ユーザーデータとシェルスクリプト
シェルスクリプトに慣れている場合は、この方法が最も簡単で完全に起動時に指示を送信する方法です。起動時にこれらのタスクを追加すると、インスタンスの起動にかかる時間が増えます。タスクが完了するまでさらに数分待ち、それからユーザースクリプトが正常に完了したことをテストしてください。
**重要**
デフォルトでは、ユーザーデータスクリプトと cloud-init ディレクティブは、インスタンスの最初の起動サイクル中にのみ実行されます。インスタンスを再起動するたびにユーザーデータスクリプトと cloud-init ディレクティブが実行されるように設定を更新できます。詳細については、AWS ナレッジセンターの[Amazon EC2 Linux インスタンスを再起動する度にユーザーデータを実行して自動的にファイルを作成するにはどうすればよいですか?](https://repost.aws/knowledge-center/execute-user-data-ec2)を参照してください。
ユーザーデータのシェルスクリプトは、`#!` の記号と、スクリプトを読み取るインタープリタのパス (通常は **/bin/bash)**) から始める必要があります。シェルスクリプトの概要については、*GNU オペレーティングシステム*のウェブサイトにある「[Bash Reference Manual](https://www.gnu.org/software/bash/manual/bash.html)」を参照してください。
ユーザーデータとして入力されたスクリプトはルートユーザーとして実行されます。そのため、スクリプトでは **sudo** コマンドを使用しないでください。作成したファイルはすべてルートユーザーの所有になることを忘れないでください。ルート以外のユーザーにファイルアクセスを与える場合、スクリプトで許可を適宜変更する必要があります。また、スクリプトはインタラクティブに実行されないため、ユーザーフィードバックを必要とするコマンド (`-y` フラグのない **yum update** など) を含めることはできません。
ユーザーデータスクリプトで AWS API (AWS CLI など) を使用する場合は、インスタンスを起動するときにインスタンスプロファイルを使用する必要があります。インスタンスプロファイルは、API 呼び出しを発行するためにユーザーデータスクリプトが必要とする適切な AWS 認証情報を提供します。詳細については、IAM ユーザーガイド の[インスタンスプロファイルの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)を参照してください。IAM ロールに割り当てるアクセス許可は、API で呼び出すサービスによって異なります。詳細については、「[Amazon EC2 の IAM ロール](iam-roles-for-amazon-ec2.md)」を参照してください。
cloud-init 出力ログファイルでコンソール出力がキャプチャされるため、インスタンスが意図したように動作しない場合でも、起動後、簡単にスクリプトをデバッグすることができます。ログファイルを表示するには、[インスタンスに接続](connect-to-linux-instance.md)し、`/var/log/cloud-init-output.log` を開きます。
ユーザーデータスクリプトを処理すると、`/var/lib/cloud/instances/instance-id/` にコピーされ、実行されます。実行後にスクリプトを削除することはできません。必ず `/var/lib/cloud/instances/instance-id/` のユーザーデータスクリプトを削除してから、インスタンスに AMI を作成してください。それ以外の場合、スクリプトはこの AMI から起動されたインスタンスのこのディレクトリに存在します。
### インスタンスのユーザーデータを更新する
インスタンスのユーザーデータを更新するには、まずインスタンスを停止する必要があります。インスタンスが実行されている場合は、ユーザーデータを表示できますが、変更することはできません。
**警告**
インスタンスストアボリューム上のデータは、インスタンスを停止すると失われます。このデータを保持するには、永続ストレージにバックアップしてください。
**インスタンスユーザーデータを変更するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. インスタンスを選択し、[**Instance state (インスタンスの状態)**]、[**Stop instance (インスタンスの停止)**] の順に選択してください。このオプションが無効になっている場合はインスタンスが既に停止しているか、またはルートボリュームがインスタンスストアボリュームです。
1. 確認を求められたら、[**Stop**] を選択してください。インスタンスが停止するまで、数分かかる場合があります。
1. インスタンスが選択された状態のまま、[**Actions (アクション)**]、[**Instance settings (インスタンス設定)**]、[**Edit user data (ユーザーデータの編集)**] の順に選択してください。
1. 必要に応じてユーザーデータを変更し、[**Save (保存)**] を選択してください。
1. インスタンスを起動します。新しいユーザーデータは、再起動後にインスタンス上に表示されますが、ユーザーデータスクリプトは実行されません。
### ユーザーデータと cloud-init ディレクティブ
cloud-init パッケージは、新しい Amazon Linux インスタンスが起動したときに、特定の側面を設定します。具体的には、お客様のプライベートキーでログインできるように、ec2-user の `.ssh/authorized_keys` ファイルを設定します。Amazon Linux インスタンスに対して cloud-init パッケージが実行する設定タスクの詳細については、次のドキュメントを参照してください。
+ **Amazon Linux 2023** – [カスタマイズされた cloud-init](https://docs.aws.amazon.com/linux/al2023/ug/cloud-init.html)
+ **Amazon Linux 2** – [Amazon Linux 2 上の cloud-init の使用](https://docs.aws.amazon.com/linux/al2/ug/amazon-linux-cloud-init.html)
構文は異なりますが、渡されたスクリプトと同じ方法で cloud-init ユーザーディレクティブを起動時のインスタンスに渡すことができます。cloud-init の詳細については、[https://cloudinit.readthedocs.org/en/latest/index.html](https://cloudinit.readthedocs.org/en/latest/index.html) を参照してください。
**重要**
デフォルトでは、ユーザーデータスクリプトと cloud-init ディレクティブは、インスタンスの最初の起動サイクル中にのみ実行されます。インスタンスを再起動するたびにユーザーデータスクリプトと cloud-init ディレクティブが実行されるように設定を更新できます。詳細については、AWS ナレッジセンターの[Amazon EC2 Linux インスタンスを再起動する度にユーザーデータを実行して自動的にファイルを作成するにはどうすればよいですか?](https://repost.aws/knowledge-center/execute-user-data-ec2)を参照してください。
起動時にこれらのタスクを追加すると、インスタンスの起動にかかる時間が増えます。タスクが完了するまでさらに数分待ち、それからユーザーデータディレクティブが完了したことをテストしてください。
**cloud-init ディレクティブを Amazon Linux インスタンスに渡すには**
1. [インスタンスを起動する](ec2-launch-instance-wizard.md)ための手順に従います。**[User data]** (ユーザーデータ) フィールドは、インスタンス起動ウィザードの [高度な詳細](ec2-instance-launch-parameters.md#liw-advanced-details) セクションにあります。cloud-init ディレクティブテキストを**[User data]** (ユーザーデータ) フィールドに入力してから、インスタンスの起動手順を完了します。
下の例では、ディレクティブが Amazon Linux でウェブサーバーを作成して設定します。一番上の `#cloud-config` 行は、cloud-init ディレクティブとしてコマンドを識別するために必要です。
------
#### [ AL2023 ]
```
#cloud-config
package_update: true
package_upgrade: all
packages:
- httpd
- mariadb105-server
- php8.1
- php8.1-mysqlnd
runcmd:
- systemctl start httpd
- systemctl enable httpd
- [ sh, -c, "usermod -a -G apache ec2-user" ]
- [ sh, -c, "chown -R ec2-user:apache /var/www" ]
- chmod 2775 /var/www
- [ find, /var/www, -type, d, -exec, chmod, 2775, {}, \; ]
- [ find, /var/www, -type, f, -exec, chmod, 0664, {}, \; ]
- [ sh, -c, 'echo "" > /var/www/html/phpinfo.php' ]
```
------
#### [ AL2 ]
```
#cloud-config
package_update: true
package_upgrade: all
packages:
- httpd
- mariadb-server
runcmd:
- [ sh, -c, "amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2" ]
- systemctl start httpd
- systemctl enable httpd
- [ sh, -c, "usermod -a -G apache ec2-user" ]
- [ sh, -c, "chown -R ec2-user:apache /var/www" ]
- chmod 2775 /var/www
- [ find, /var/www, -type, d, -exec, chmod, 2775, {}, \; ]
- [ find, /var/www, -type, f, -exec, chmod, 0664, {}, \; ]
- [ sh, -c, 'echo "" > /var/www/html/phpinfo.php' ]
```
------
1. インスタンスが起動し、ユーザーデータのディレクティブを実行するまで十分待ち、それから意図したタスクをディレクティブが完了したことを確認します。
この例では、ウェブブラウザで、ディレクティブが作成した PHP テストファイルの URL を入力してください。この URL は、インスタンスのパブリック DNS アドレスにスラッシュとファイル名を追加したものです。
```
http://my.public.dns.amazonaws.com/phpinfo.php
```
PHP 情報ページが表示されるはずです。PHP 情報ページが表示されない場合、使用しているセキュリティグループに HTTP (ポート 80) トラフィックを許可するルールが含まれていることを確認します。詳細については、「[セキュリティグループルールの設定](changing-security-group.md#add-remove-security-group-rules)」を参照してください。
1. (オプション) ディレクティブが期待したタスクを達成しなかった場合、あるいは単にディレクティブがエラーなしで完了したことを確認する場合は、[インスタンスに接続](connect-to-linux-instance.md)し、出力ログファイル `/var/log/cloud-init-output.log`を調べ、出力にエラーメッセージがないか探します。デバッグの詳細情報を取得するには、ディレクティブに次の行を追加します:
```
output : { all : '| tee -a /var/log/cloud-init-output.log' }
```
このディレクティブにより、**runcmd** 出力が `/var/log/cloud-init-output.log` に送信されます。
### ユーザーデータと AWS CLI
AWS CLI を使用して、インスタンスのユーザーデータを指定、変更、表示することができます。インスタンスのメタデータを使用して、インスタンスからユーザーデータを表示する方法については、[EC2 インスタンスのインスタンスメタデータにアクセスする](instancedata-data-retrieval.md)を参照してください。
Windows では、AWS CLI を使用する代わりに AWS Tools for Windows PowerShell を使用できます。詳細については、「[ユーザーデータと Windows PowerShell用ツール](#user-data-powershell)」を参照してください。
**例: ユーザーデータは、起動時に指定します。**
インスタンスの起動時にユーザーデータを指定するには、[run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) コマンドと `--user-data` パラメータを使用します。**run-instances** で、AWS CLI はユーザーデータの base64 エンコードを実行します。
次の例は、コマンドラインで文字列としてスクリプトを指定する方法を示しています。
```
aws ec2 run-instances --image-id ami-abcd1234 --count 1 --instance-type m3.medium \
--key-name my-key-pair --subnet-id subnet-abcd1234 --security-group-ids sg-abcd1234 \
--user-data echo user data
```
次の例は、テキストファイルを使用してスクリプトを指定する方法を示しています。ファイルを指定するには、必ず `file://` プレフィクスを使用してください。
```
aws ec2 run-instances --image-id ami-abcd1234 --count 1 --instance-type m3.medium \
--key-name my-key-pair --subnet-id subnet-abcd1234 --security-group-ids sg-abcd1234 \
--user-data file://my_script.txt
```
シェルスクリプトを使用したテキストファイルの例を次に示します。
```
#!/bin/bash
yum update -y
service httpd start
chkconfig httpd on
```
**例: 停止しているインスタンスのユーザーデータを変更する**
停止したインスタンスのユーザーデータは、[modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html) コマンドを使用して変更できます。**modify-instance-attribute** では、AWS CLI はユーザーデータの base64 エンコードを実行しません。
+ **Linux** コンピュータでは、base64 コマンドを使用してユーザーデータをエンコードします。
```
base64 my_script.txt >my_script_base64.txt
```
+ **Windows** コンピュータでは、certutil コマンドを使用してユーザーデータをエンコードします。このファイルを AWS CLI で使用する前に、最初の (証明書の開始) 行と最後の (証明書の終了) 行を削除する必要があります。
```
certutil -encode my_script.txt my_script_base64.txt
notepad my_script_base64.txt
```
`--attribute` および `--value` パラメータを使用して、エンコードされたテキストファイルを使用してユーザーデータを指定します。ファイルを指定するには、必ず `file://` プレフィクスを使用してください。
```
aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --attribute userData --value file://my_script_base64.txt
```
**例: 停止しているインスタンスのユーザーデータをクリアする**
既存のユーザーデータを削除するには、次の [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html) コマンドを使用します。
```
aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --user-data Value=
```
**例: ユーザーデータの表示**
インスタンスのユーザーデータを取得するには、[describe-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-attribute.html) コマンドを使用します。**describe-instance-attribute** では、AWS CLI はユーザーデータの base64 デコードを実行しません。
```
aws ec2 describe-instance-attribute --instance-id i-1234567890abcdef0 --attribute userData
```
ユーザーデータが base64 でエンコードされた出力例を次に示します。
```
{
"UserData": {
"Value": "IyEvYmluL2Jhc2gKeXVtIHVwZGF0ZSAteQpzZXJ2aWNlIGh0dHBkIHN0YXJ0CmNoa2NvbmZpZyBodHRwZCBvbg=="
},
"InstanceId": "i-1234567890abcdef0"
}
```
+ **Linux** コンピュータでは、`--query` オプションを使用してエンコードされたユーザーデータを取得し、base64 コマンドを使用してデコードします。
```
aws ec2 describe-instance-attribute --instance-id i-1234567890abcdef0 --attribute userData --output text --query "UserData.Value" | base64 --decode
```
+ **Windows** コンピュータでは、`--query` オプションを使用してコード化されたユーザーデータを取得し、certutil コマンドを使用してコードをデコードします。エンコードされた出力はファイルに保存され、デコードされた出力は別のファイルに保存されることに注意してください。
```
aws ec2 describe-instance-attribute --instance-id i-1234567890abcdef0 --attribute userData --output text --query "UserData.Value" >my_output.txt
certutil -decode my_output.txt my_output_decoded.txt
type my_output_decoded.txt
```
以下は出力の例です。
```
#!/bin/bash
yum update -y
service httpd start
chkconfig httpd on
```
### シェルスクリプトと cloud-init ディレクティブを組み合わせる
デフォルトでは、ユーザーデータに含めることができるコンテンツタイプは一度に 1 つだけです。ただし、MIME マルチパートファイルの中で `text/cloud-config` と `text/x-shellscript` のコンテンツタイプを使用して、ユーザーデータにシェルスクリプトと cloud-init ディレクティブの両方を含めることは可能です。
以下に、MIME マルチパートの形式を示します。
```
Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
#cloud-config
cloud-init directives
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"
#!/bin/bash
shell script commands
--//--
```
例えば、次のユーザーデータには cloud-init ディレクティブと bash シェルスクリプトが含まれています。cloud-init ディレクティブはファイル `/test-cloudinit/cloud-init.txt`を作成し、そのファイルに `Created by cloud-init` を書き込みます。bash シェルスクリプトはファイル `/test-userscript/userscript.txt`を作成し、そのファイルに `Created by bash shell script` を書き込みます。
```
Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
#cloud-config
runcmd:
- [ mkdir, /test-cloudinit ]
write_files:
- path: /test-cloudinit/cloud-init.txt
content: Created by cloud-init
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"
#!/bin/bash
mkdir test-userscript
touch /test-userscript/userscript.txt
echo "Created by bash shell script" >> /test-userscript/userscript.txt
--//--
```
## Amazon EC2 が Windows インスタンスのユーザーデータを処理する方法
Windows インスタンスでは、起動エージェントはユーザーデータに関連するタスクを実行します。詳細については次を参照してください:
+ [EC2Launch v2](ec2launch-v2.md)
+ [EC2Launch](ec2launch.md)
+ [EC2Config サービス](ec2config-service.md)
`UserData` テンプレート内の CloudFormation プロパティのアセンブリ例については、[UserData プロパティの Base64 エンコード](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-general.html#scenario-userdata-base64)および[AccessKey と SecretKey を含む UserData プロパティの Base64 エンコード](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-general.html#scenario-userdata-base64-with-keys)を参照してください。
ライフサイクルフックと連携する Auto Scaling グループ内のインスタンスでコマンドを実行する例については、「Amazon EC2 Auto Scaling ユーザーガイド」の「[チュートリアル: インスタンスのメタデータを使用してターゲットライフサイクル状態を取得するようにユーザーデータを設定する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/tutorial-lifecycle-hook-instance-metadata.html)」を参照してください。**
**Topics**
+ [
### ユーザーデータスクリプト
](#user-data-scripts)
+ [
### 圧縮ユーザーデータ
](#user-data-compressed)
+ [
### ユーザーデータの実行
](#user-data-execution)
+ [
### ユーザーデータと Windows PowerShell用ツール
](#user-data-powershell)
### ユーザーデータスクリプト
`EC2Config` または `EC2Launch` でスクリプトを実行するには、そのスクリプトをユーザーデータに追加するときにスクリプトを特別なタグで囲む必要があります。使用するタグは、コマンドをコマンドプロンプトウィンドウ (バッチコマンド) で実行するか、Windows PowerShell を使用するかによって異なります。
バッチスクリプトと Windows PowerShell スクリプトの両方を指定すると、バッチスクリプトが最初に実行され、インスタンスユーザーデータに表示される順序に関係なく、次に Windows PowerShell スクリプトが実行されます。
ユーザーデータスクリプトで AWS API (AWS CLI など) を使用する場合は、インスタンスを起動するときにインスタンスプロファイルを使用する必要があります。インスタンスプロファイルは、API 呼び出しを実行するためにユーザーデータスクリプトが必要とする適切な AWS 認証情報を提供します。詳細については、「[インスタンスプロファイル](iam-roles-for-amazon-ec2.md#ec2-instance-profile)」を参照してください。IAM ロールに割り当てるアクセス許可は、API で呼び出すサービスによって異なります。詳細については、「[Amazon EC2 の IAM ロール](iam-roles-for-amazon-ec2.md)」を参照してください。
**Topics**
+ [
#### バッチスクリプトの構文
](#user-data-batch-scripts)
+ [
#### Windows PowerShell スクリプトの構文
](#user-data-powershell-scripts)
+ [
#### YAML 設定スクリプトの構文
](#user-data-yaml-scripts)
+ [
#### Base64 エンコード
](#user-data-base64-encoding)
#### バッチスクリプトの構文
`script` タグを使用してバッチ スクリプトを指定します。次の例に示すように、改行を使用してコマンドを区切ります。
```
```
デフォルトでは、ユーザーデータスクリプトはインスタンスを起動すると一度だけ実行されます。インスタンスを再起動または起動するたびにユーザーデータスクリプトを実行するには、`true` をユーザーデータに追加します。
```
true
```
**EC2 ローンチ v2 エージェント**
XML ユーザーデータスクリプトを `UserData` ステージ内の EC2Launch v2 **executeScript** タスクでデタッチされたプロセスとして実行するには、ユーザーデータに `true` を追加します。
**注記**
detach タグは以前の起動エージェントではサポートされていません。
```
true
```
#### Windows PowerShell スクリプトの構文
AWS Windows AMI には [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/) が含まれており、ユーザーデータにこれらのコマンドレットを指定することができます。インスタンスに IAM ロールを関連付けている場合は、コマンドレットに認証情報を指定する必要はありません。インスタンスで実行するアプリケーションは、ロールの認証情報を使用して AWS リソース (Simple Storage Service (Amazon S3) バケットなど) にアクセスします。
`` タグを使用して Windows PowerShell スクリプトを指定します。コマンドは、改行を使って区切ります。`` タグでは、大文字と小文字が区別されます。
例えば、次のようになります。
```
$file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
New-Item $file -ItemType file
```
デフォルトでは、ユーザーデータスクリプトはインスタンスを起動すると一度だけ実行されます。インスタンスを再起動または起動するたびにユーザーデータスクリプトを実行するには、`true` をユーザーデータに追加します。
```
$file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
New-Item $file -ItemType file
true
```
`` タグを使用して、1 つ以上の PowerShell 引数を指定できます。引数が渡されない場合、EC2Launch と EC2Launch v2 はデフォルトで次の引数を追加します: `-ExecutionPolicy Unrestricted`
**例:**
```
$file = $env:SystemRoot + "\Temp" + (Get-Date).ToString("MM-dd-yy-hh-mm")
New-Item $file -ItemType file
-ExecutionPolicy Unrestricted -NoProfile -NonInteractive
```
**EC2 ローンチ v2 エージェント**
XML ユーザーデータスクリプトを `UserData` ステージ内の EC2Launch v2 **executeScript** タスクでデタッチされたプロセスとして実行するには、ユーザーデータに `true` を追加します。
**注記**
detach タグは以前の起動エージェントではサポートされていません。
```
$file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
New-Item $file -ItemType file
true
```
#### YAML 設定スクリプトの構文
EC2Launch v2 を使用してスクリプトを実行する場合は、YAML 形式を使用できます。EC2Launch v2 の設定タスク、詳細、例を表示するには、[EC2Launch v2 タスクの設定](ec2launch-v2-settings.md#ec2launch-v2-task-configuration)を参照してください。
`executeScript` タスクで YAML スクリプトを指定します。
**PowerShell スクリプトを実行するための YAML 構文の例**
```
version: 1.0
tasks:
- task: executeScript
inputs:
- frequency: always
type: powershell
runAs: localSystem
content: |-
$file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
New-Item $file -ItemType file
```
**バッチスクリプトを実行するための YAML 構文の例**
```
version: 1.1
tasks:
- task: executeScript
inputs:
- frequency: always
type: batch
runAs: localSystem
content: |-
echo Current date and time >> %SystemRoot%\Temp\test.log
echo %DATE% %TIME% >> %SystemRoot%\Temp\test.log
```
#### Base64 エンコード
Amazon EC2 API または、ユーザーデータの base64 エンコーディングが実行されないツールを使用している場合、ユーザーデータを手動でエンコードする必要があります。エンコードしない場合、実行する `script` タグまたは `powershell` タグが見つからないというエラーが記録されます。Windows PowerShell を使用してエンコードする例を次に示します。
```
$UserData = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($Script))
```
PowerShell を使用してデコードする例を次に示します。
```
$Script = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($UserData))
```
base64 エンコードの詳細については、[https://www.ietf.org/rfc/rfc4648.txt](https://www.ietf.org/rfc/rfc4648.txt)を参照してください。
### 圧縮ユーザーデータ
EC2Launch v2 は、IMDS が課す上限の 16 KB を超えるユーザーデータを送信する方法として、zip 形式のユーザーデータをサポートしています。この機能を使用するには、ユーザーデータスクリプトを `.zip` アーカイブに圧縮してから、EC2 インスタンスに渡します。EC2Launch v2 が圧縮されたユーザーデータを検出すると、圧縮されたユーザーデータスクリプトを自動的に解凍して実行します。
標準ユーザーデータと同様に、Amazon EC2 API、またはユーザーデータの base64 エンコーディングを実行しないツールを使用している場合は、圧縮されたユーザーデータを手動でエンコードする必要があります。ユーザーデータのサイズ制限と base64 エンコーディングの詳細については、「[EC2 インスタンスのインスタンスメタデータにアクセスする](instancedata-data-retrieval.md)」を参照してください。
### ユーザーデータの実行
デフォルトでは、すべての AWS Windows AMI で初回起動時のユーザーデータの実行が有効になっています。次にインスタンスが再起動されたときにユーザーデータスクリプトが実行されるように指定できます。また、インスタンスが再起動するたびにユーザーデータスクリプトが実行されるように指定することもできます。
**注記**
ユーザーデータは、初期起動後にデフォルトで実行するように有効化されていません。インスタンスを再起動または起動したときにユーザーデータが実行できるようにするには、「[その後の再起動または起動時にスクリプトを実行する](#user-data-scripts-subsequent)」を参照してください。
ユーザーデータスクリプトは、ランダムなパスワードが生成されたときにローカル管理者アカウントから実行されます。それ以外の場合、ユーザーデータスクリプトはシステムアカウントから実行されます。
#### インスタンス起動スクリプト
インスタンスユーザーデータ内のスクリプトは、インスタンスの最初の起動時に実行されます。`persist` タグが見つかった場合は、その後の再起動または開始時にユーザーデータの実行が有効になります。EC2Launch v2、EC2Launch、EC2Config のログファイルには、標準出力ストリームと標準エラーストリームの出力が含まれています。
**EC2Launch v2**
EC2Launch v2 のログファイルは `C:\ProgramData\Amazon\EC2Launch\log\agent.log` です。
**注記**
`C:\ProgramData` フォルダは非表示になっている場合があります。このフォルダを表示するには、非表示のファイルおよびフォルダを表示する必要があります。
ユーザーデータが実行されると、次の情報が記録されます。
+ `Info: Converting user-data to yaml format` – ユーザーデータが XML 形式で提供されているか
+ `Info: Initialize user-data state` – ユーザーデータ実行の開始
+ `Info: Frequency is: always` – ブートのたびにユーザーデータタスクが実行されているか
+ `Info: Frequency is: once` – ユーザーデータタスク実行は一度だけか
+ `Stage: postReadyUserData execution completed` – ユーザーデータの実行の終了
**EC2Launch**
EC2Launch のログファイルは `C:\ProgramData\Amazon\EC2-Windows\Launch\Log\UserdataExecution.log` です。
`C:\ProgramData` フォルダは非表示になっている場合があります。このフォルダを表示するには、非表示のファイルおよびフォルダを表示する必要があります。
ユーザーデータが実行されると、次の情報が記録されます。
+ `Userdata execution begins` – ユーザーデータ実行の開始
+ ` tag was provided: true` – 永続タグが見つかったか
+ `Running userdata on every boot` – 永続タグが見つかったか
+ ` tag was provided.. running powershell content` – PowerShell タグが見つかったか
+ `