Amazon Elastic Compute Cloud
Linux インスタンス用ユーザーガイド

インスタンスメタデータとユーザーデータ

インスタンスメタデータは、インスタンスに関するデータで、実行中のインスタンスを設定または管理するために使用します。インスタンスメタデータは、ホスト名、イベント、およびセキュリティグループなどのカテゴリに分けられます。

インスタンスメタデータを使用して、インスタンスの起動時に指定したユーザーデータにアクセスすることもできます。たとえば、インスタンスを設定するためにパラメータを指定したり、単純なスクリプトを含めたりすることができます。汎用 AMI をビルドし、ユーザーデータを使って起動時に提供された構成ファイルを変更することができます。たとえば、さまざまな小規模ビジネスを対象としたウェブサーバーを実行する場合に、すべてのサーバーで同じ汎用 AMI を使用し、起動時にユーザーデータで指定したAmazon S3バケットからコンテンツを取得できます。随時新規顧客を追加するには、顧客のバケットを作成し、そのコンテンツを追加し、ユーザーデータのコードに提供された固有のバケット名を使って AMI を起動します。複数のインスタンスを同時に起動する場合、ユーザーデータはその予約においてすべてのインスタンスで使用可能です。同じリザベーションの一部である各インスタンスには固有のami-launch-index番号があるため、実行する操作を制御するコードを書くことができます。たとえば、最初のホストがクラスタの最初のマスターノードとして自身を選択する場合があります。詳しい AMI 起動例については、例: AMI 作成インデックス値を参照してください。

EC2 インスタンスには、インスタンスの起動時に生成されるインスタンスアイデンティティドキュメントなどの動的データも含まれます。詳細については、「動的データのカテゴリ」を参照してください。

重要

インスタンスメタデータおよびユーザーデータにはそのインスタンス自体内からのみアクセスできるものの、データは認証または暗号化手法によって保護されていません。インスタンス、そしてインスタンス上で実行される任意のソフトウェアに対して直接アクセス権がある可能性がある人は、メタデータを表示できます。そのため、パスワードまたは存続期間の長い暗号化キーなどの機密データは、ユーザーデータとして保管しないようにしてください。

インスタンスメタデータサービスの構成

次のいずれかのメソッドを使って、実行中のインスタンスからインスタンスメタデータにアクセスできます。

  • インスタンスメタデータサービスバージョン 1 (IMDSv1) – リクエスト/レスポンスメソッド

  • インスタンスメタデータサービスバージョン 2 (IMDSv2) – セッション志向メソッド

デフォルトでは、IMDSv1またはIMDSv2のいずれか、あるいは両方を使用できます。インスタンスメタデータサービスは、所定のリクエストについて、IMDSv2に固有のPUTまたはGETヘッダーがそのリクエストに存在するかどうかによって、IMDSv1とIMDSv2リクエストを区別します。

各インスタンスのインスタンスメタデータサービスを、ローカルコードまたはユーザーが IMDSv2を使用しなければいけないように構成できます。IMDSv2を使用しなければならないように指定すると、IMDSv1はもう機能しなくなります。詳細については、「インスタンスメタデータオプションの構成」を参照してください。

インスタンスメタデータサービスバージョン 2の仕組み

IMDSv2は、セッション志向リクエストを使用します。セッション志向リクエストを使用して、セッション期間 (1 秒~6 時間) を定義するセッショントークンを作成します。指定した期間中、それ以降のリクエストに同じセッショントークンを使用できます。指定した期間が期限切れになった後、将来のリクエストに使用する新しいセッショントークンを作成する必要があります。

次の例では、LinuxシェルスクリプトとIMDSv2を使って、最上位インスタンスメタデータアイテムを取得しています。コマンド例:

  • PUTリクエストを使って、6 時間 (21,600 秒) のセッショントークンを作成する

  • セッショントークンヘッダーを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" -v http://169.254.169.254/latest/meta-data/

トークンを作成した後、期限切れになるまで再使用することができます。次のコマンド例では、インスタンスの起動に AMI の ID が使用されていますが、前の例で $TOKENに保管されたトークンが再使用されています。

[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ami-id

IMDSv2を使ってインスタンスメタデータをリクエストする際は、リクエストに次の項目が含まれている必要があります。

  1. PUTリクエストを使って、インスタンスメタデータサービスに対してセッションを開始します。PUT リクエストは、インスタンスメタデータサービスに対するそれ以降のGETリクエストに含まれるべきトークンを返します。このトークンは、IMDSv2を使ってメタデータにアクセスするのに必要です。

  2. トークンを、インスタンスメタデータサービスに対するすべてのGETリクエストに含めます。トークン使用がrequiredに設定されている場合、有効なトークンがないリクエスト、または有効期限切れのトークンを持つリクエストは401 - UnauthorizedHTTP エラーコードを受け取ります。トークン使用要件の変更に関する情報については、AWS CLI Command Referencemodify-instance-metadata-optionsを参照してください。

    • トークンはインスタンス固有のキーです。トークンは他の EC2 インスタンスで有効ではなく、生成されたインスタンスの外で使用しようとすると拒否されます。

    • PUTリクエストには、トークンの有効期限 (TTL) を最大 6 時間 (21,600 秒) まで秒単位で指定するヘッダーが含まれている必要があります。トークンは論理的セッションを表します。TTL は、トークンが有効な時間の長さ、つまりセッションの期間を指定します。

    • トークンの期限が切れた後、インスタンスメタデータにアクセスし続けるためには、別の PUTを使って新しいセッションを作成する必要があります。

    • 各リクエストについてトークンを再使用するか、あるいは新しいトークンを作成することを選択できます。少数のリクエストでは、インスタンスメタデータサービスにアクセスする必要があるたびに、トークンを生成してすぐに使用するほうが簡単かもしれません。ただし、効率を重視するなら、インスタンスメタデータをリクエストする必要があるたびにPUTリクエストを書くより、トークン期間を長く指定して再使用することができます。それぞれが独自のセッションを表す同時トークンの数については実際的に制限がありません。ただし、IMDSv2は通常のインスタンスメタデータサービス接続とスロットリングの制限によって制約を受けます。詳細については、「Throttling」を参照してください。

HTTP GETおよびHEADメソッドはIMDSv2インスタンスメタデータリクエストで許可されています。 PUT リクエストは、X-Forwarded-For ヘッダーが含まれている場合、拒否されます。

デフォルトで、PUTリクエストに対するレスポンスには IP プロトコルレベルで1のレスポンスホップリミット (有効期限) があります。ホップリミットを拡大するには、modify-instance-metadata-optionsコマンドを使ってホップリミットを調整できます。たとえば、インスタンスで実行されているコンテナサービスとの下位互換性のためにホップリミットを拡大する必要があるかもしれません。詳細については、AWS CLI Command Referencemodify-instance-metadata-optionsを参照してください。

インスタンスメタデータサービスバージョン 2使用への移行

インスタンスメタデータサービスバージョン 2 (IMDSv2) の使用はオプションです。インスタンスメタデータサービスバージョン 1 (IMDSv1) は引き続き無限にサポートされます。IMDSv2の使用に移行することを選択した場合、次のツールと移行パスを使用することが推奨されます。

IMDSv2への移行に役立つツール

お使いのソフトウェアでIMDSv1が使用されている場合、次のツールを使ってIMDSv2を使用するようソフトウェアを再構成することができます。

  • AWS ソフトウェア:最新バージョンの AWS SDK および CLI サポートIMDSv2。IMDSv2を使用するには、EC2 インスタンスの AWS SDK および CLI のバージョンが最新であることを確認する必要があります。CLI の更新に関する情報については、AWS Command Line Interface ユーザーガイドAWS CLI の最新バージョンのアップグレードを参照してください。

  • CloudWatch: IMDSv1トークンベースのセッションを使用しません。CloudWatch メトリクスMetadataNoTokenを通じてトークンベースのセッションを使用していないインスタンスメタデータまで呼び出し数をトラッキングできます。このメトリクスは、IMDSv1を使用している呼び出し数をトラッキングします。このメトリクスをゼロまでトラッキングすることにより、すべてのソフトウェアがIMDSv2を使用するようアップグレードされたかどうか、そしてそのタイミングを判断できます。詳細については、「インスタンスメトリクス」を参照してください。

  • EC2 API および CLI へ更新する: 既存のインスタンスについては、modify-instance-metadata-optionsCLI コマンド (またはModifyInstanceMetadataOptionsAPI) を使用して、IMDSv2の使用を義務付けることができます。新しいインスタンスについては、run-instancesCLI コマンド (またはRunInstancesAPI) およびmetadata-optionsパラメータを使用して、IMDSv2の使用を義務付ける新しいインスタンスを起動できます。

  • IAM ポリシーおよび SCP: 条件キーを使って、IMDSv2のみの使用を指定しないかぎり、ユーザーが新しいインスタンスを起動したり、実行中のインスタンスを変更したりするのをブロックすることができます。また、別の条件キーを使用して、IMDSv1経由で取得された EC2 ロール資格情報で行われたそれ以降の API 呼び出しをブロックすることもできます。それらの条件キー (次のセクションで説明) は、IAM ポリシーまたは AWS Organizations サービスコントロールポリシー (SCPs) で使用することができます。その他の情報については、次のセクションのすべてのインスタンスがIMDSv2に移行されたときを参照してください。

IMDSv2アクセスを必要とする推奨パス

上記のツールを使用する際、IMDSv2への移行にこのパスに従うことを推奨します。

  1. スタート時

    SDK、CLI、および EC2 インスタンスでロール資格情報を使用するソフトウェアを、IMDSv2対応バージョンに更新します。次に、IMDSv2 リクエストを使ってインスタンスメタデータに直接アクセスする (つまり、SDK を使用しない) ソフトウェアを変更します。CLI の更新に関する情報については、AWS Command Line Interface ユーザーガイドAWS CLI の最新バージョンのアップグレードを参照してください。

  2. 移行中

    CloudWatchメトリクスMetadataNoTokenを確認することで、移行進捗状況をトラッキングします。これには、インスタンスのIMDSv1に対する呼び出し数が表示されます。詳細については、「インスタンスメトリクス」を参照してください。

  3. すべてのインスタンスで準備が完了したら

    CloudWatch メトリクスMetadataNoTokenがゼロ使用を記録した時点で、すべてのインスタンスの準備が完了しています。この段階では、modify-instance-metadata-optionsコマンドを使ったIMDSv2使用が必要となります。実行中のインスタンスでこれらの変更を行うことができます。インスタンスを再起動する必要はありません。新規に起動されたインスタンスでは、run-instancesコマンドを使って、IMDSv2 のみが使用されるよう指定することができます。インスタンスメタデータオプションの指定は、API または AWS CLI を通じてのみ使用できます。現在、AWS マネジメントコンソール経由では使用できません。詳細については、AWS CLI Command Referencerun-instancesおよびmodify-instance-metadata-optionsを参照してください。

  4. すべてのインスタンスがIMDSv2に移行されたら

    IAM 条件を使って、IAM ユーザーはインスタンスがIMDSv2を使用しない限りインスタンスを起動できないよう強制することができます。詳細については、次のセクションの すべての新しいインスタンスで IMDSv2 の使用を強制するにはを参照してください。また IAM 条件を使って、IAM ユーザーが実行中のインスタンスを変更してIMDSv1を最有効化できないように強制し、さらにインスタンスメタデータサービスがインスタンス上で使用できるよう強制することもできます。

    さらに、追加の保護レイヤーを選択して、IMDSv1からIMDSv2の変更を強制することもできます。EC2 ロール資格情報経由で呼び出された API に関するアクセス管理レイヤーでは、IAMポリシーまたは AWS Organization サービスコントロールポリシー (SCP) で新しい条件キーを使用することができます。具体的には、IAM ポリシーで値2.0とともにポリシー条件キーec2:RoleDeliveryを使用することにより、IMDSv1から取り込まれた EC2 ロール資格情報を使った API 呼び出しがAccess Deniedレスポンスを受け取ります。同じことは、SCP によって義務付けられる条件を使ってより広く達成できます。これにより、IMDSv1経由で送信された資格情報を使って実際に API を呼び出すことができないよう徹底されます。これは、指定した条件に一致しない API 呼び出しはすべてAccess Deniedエラーを受け取るためです。詳細については、AWS Organizations ユーザーガイドサービスコントロールポリシーを参照してください。

インスタンスメタデータオプションの構成

インスタンスメタデータオプションを使うと、インスタンスメタデータをリクエストする際にIMDSv2の使用を義務付ける新規または既存インスタンスを構成し、PUTリスポンスホップリミットを指定し、さらにインスタンスメタデータへのアクセスをオフにすることがdけいます。また、IAM ポリシーまたは SCP で、IMDSv2の使用を義務付けるよう構成されている場合にのみインスタンスを起動できる、または許可されるホップ数を制限する、あるいはIMDS がすべて無効化されるよう強制する条件キーを使用することもできます。新規または既存インスタンスでインスタンスメタデータオプションを構成するには、 AWS SDK または CLI を使用します。詳細については、AWS CLI Command Referencerun-instancesおよびmodify-instance-metadata-optionsを参照してください。

注記

注意深く実行し、変更を行う前に慎重なテストを実施する必要があります。以下の情報を記録します。

  • IMDSv2の使用を強制する場合、インスタンスメタデータアクセスのためにIMDSv1を使用するアプリケーションまたはエージェントは休憩します。

  • インスタンスメタデータへのアクセスをすべてオフにする場合、インスタンスメタデータアクセスに依存して機能するアプリケーションまたはエージェントは休憩します。

すべての新しいインスタンスでIMDSv2の使用を強制するには

IAM ユーザーがインスタンスメタデータをリクエストする際にIMDSv2の使用を義務付けるインスタンスみを起動できるようにするには、IMDSv2を必要とする条件が満たされないとインスタンスを起動できないように指定することができます。

次の手順では、AWS CLI を使用してポリシーを作成し、アタッチする方法を示します。AWS マネジメントコンソール を使用する手順については、IAM ユーザーガイド の「IAM ポリシーを作成する (コンソール)」と「ポリシーをユーザーに直接アタッチすることによるアクセス権限の追加」を参照してください。

  1. 以下を含む JSON ポリシードキュメントを作成します。

    • ec2:RunInstancesアクション。これは、新しいインスタンスを起動するIAMユーザー許可を付与します。

    • requiredに設定されたec2:MetadataHttpTokens条件。これは、起動するインスタンスについて、IMDSv2を必要とするよう構成しなければならないことを指定します。これは、インスタンスメタデータ取得リクエストにセキュアトークンヘッダーを使用します。

    以下に、ポリシードキュメントの例を示します。

    { "Version": "2012-10-17", "Statement": [{ "Sid": "RunInstanceWithImdsV2Only", "Effect": "Allow", "Action": "ec2:RunInstances", "Resource": "*", "Condition": { "StringEquals": { "ec2:MetadataHttpTokens": "required" } } }] }
  2. create-policy コマンドを使用して新しい管理ポリシーを作成し、新しいポリシーの内容として使用するために作成した JSON ドキュメントを指定します。

    $ aws iam create-policy --policy-name my-policy --policy-document file://JSON-file-name
  3. attach-user-policy コマンドを使用して、管理ポリシーを指定した IAM ユーザーにアタッチします。--user-name パラメータで、IAM ユーザーのわかりやすい名前 (ARN ではなく) を指定します。

    $ aws iam attach-user-policy --policy-arn arn:aws:iam::account-id:policy/my-policy --user-name IAM-friendly-name

ec2:MetadataHttpTokensec2:MetadataHttpPutResponseHopLimit、およびec2:MetadataHttpEndpointIAM 条件キーを使って、 RunInstancesおよび ModifyInstanceMetadataOptionsAPI および対応する CLI の使用を制御することもできます。これらのキーの有効な条件については、AWS CLI Command Referencerun-instancesおよびmodify-instance-metadata-options を参照してください。ポリシーが作成され、API 呼び出しのパラメータが条件キーを使ったポリシーに指定された状態に一致しない場合、API または CLI 呼び出しは Access Denied リスポンスに失敗します。これらの条件キーを使用してポリシーを作成する方法の例として、前述のポリシー例を使用できます。

既存インスタンスでIMDSv2の使用を義務付けるには

既存インスタンスに対して、インスタンスメタデータをリクエストする際にIMDSv2を使用を義務付けるようオプトインすることができます。modify-instance-metadata-optionsCLI コマンドを使って、http-tokensパラメータをrequiredに設定できます。

aws ec2 modify-instance-metadata-options --instance-id i-1234567898abcdef0 --http-tokens required

例ポリシーは提供しませんが、ec2:MetadataHttpTokens 条件キーを使って ModifyInstanceMetadataOptions API および RunInstancesAPI の使用を制御することもできます。

既存インスタンスで PUT レスポンスホップリミットを変更するには

既存インスタンスについて、PUTリスポンスホップリミットの設定を変更することができます。modify-instance-metadata-optionsCLI コマンドを使って、http-put-response-hop-limitパラメータを必要なホップ数に設定できます。以下の例では、ホップリミットが3に設定されています。

aws ec2 modify-instance-metadata-options --instance-id i-1234567898abcdef0 --http-put-response-hop-limit 3

既存インスタンスのインスタンスメタデータへのアクセスをオフにするには

既存インスタンスについて、使用中のインスタンスメタデータサービスのバージョンに関係なく、インスタンスメタデータサービスの HTTP エンドポイントを無効化することによりインスタンスメタデータへのアクセスをオフにすることができます。HTTP エンドポイントを有効化することにより、この変更はいつでも元に戻すことができます。modify-instance-metadata-optionsCLI コマンドを使って、http-endpointパラメータを disabledに設定できます。

aws ec2 modify-instance-metadata-options --instance-id i-1234567898abcdef0 --http-endpoint disabled

インスタンスメタデータの取得

インスタンスメタデータは実行中のインスタンスから取得できるため、Amazon EC2 コンソールまたは AWS CLI を使用する必要はありません。これは、インスタンスから実行するスクリプトを記述しているときに便利です。たとえば、インスタンスメタデータからインスタンスのローカル IP アドレスにアクセスして、外部アプリケーションへの接続を管理できます。

インスタンスメタデータはいくつかのカテゴリに分けられます。各インスタンスメタデータカテゴリの説明については、インスタンスメタデータのカテゴリを参照してください。

実行中のインスタンス内からインスタンスメタデータのすべてのカテゴリを表示するには、次の URI を使用します。

http://169.254.169.254/latest/meta-data/

IP アドレス 169.254.169.254 は、リンクローカルアドレスで、インスタンスからのみ有効です。詳細については、Wikipedia の リンクローカルアドレスを参照してください。

インスタンスメタデータおよびユーザーデータの取得に使用する HTTP リクエストに対しては課金されません。

コマンドフォーマットは、IMDSv1とIMDSv2のどちらを使うかによって異なります。デフォルトでは、両方のインスタンスメタデータサービスを使用できます。IMDSv2の使用を義務付けるには、インスタンスメタデータサービスの構成を参照してください。

次の例のように、cURL などのツールを使用できます。

IMDSv2IMDSv1
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" -v http://169.254.169.254/latest/meta-data/
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/

また、Instance Metadata Queryツールをダウンロードすることもできます。これにより、URI 全体またはカテゴリ名を入力する必要なく、インスタンスメタデータサービスバージョン 1.0 を使って、インスタンスメタデータに対してクエリを実行できます。

リスポンスおよびエラーメッセージ

すべてのインスタンスメタデータがテキスト (HTTP コンテンツタイプ text/plain) として返されます。

特定のメタデータリソースに対するリクエストは、適切な値または 404 - Not Found HTTP エラーコード (リソースを使用できない場合) を返します。

一般的なメタデータリソースに対するリクエスト (/ で終わる URI) は、使用可能なリソースのリストまたは 404 - Not Found HTTP エラーコード (使用可能なリソースがない場合) を返します。リスト項目は個別の行に表示され、各行の末尾には改行記号 (ASCII 10) が付いています。

インスタンスメタデータサービスバージョン 2を使って行われたリクエストについては、次の HTTP エラーコードが返されます。

  • 400 - Missing or Invalid ParametersPUTリクエストが無効である。

  • 401 - UnauthorizedGETリクエストが無効なトークンを使用している。推奨されるアクションは新しいトークンを生成することです。

  • 403 - Forbidden–リクエストが許可されていないか、あるいはインスタンスメタデータサービスがオフです。

インスタンスメタデータの取得の例

使用できるインスタンスメタデータのバージョンを取得する

次の例では、使用できるインスタンスメタデータのバージョンを取得しています。これらのバージョンは、Amazon EC2 API バージョンと必ずしも関連しているとは限りません。以前のバージョンに存在する構造および情報に依存するスクリプトがある場合は、以前のバージョンを使用することができます。

IMDSv2IMDSv1
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" -v 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 2016-06-30 2016-09-02 latest
IMDSv1
[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 2016-06-30 2016-09-02 latest

上位レベルのメタデータ項目を取得する

次の例では、上位レベルのメタデータ項目を取得しています。詳細については、「インスタンスメタデータのカテゴリ」を参照してください。

IMDSv2IMDSv1
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" -v http://169.254.169.254/latest/meta-data/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/
IMDSv1
[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/

次の例では、前の例で取得された最上位メタデータアイテムの値のいくつかを取得しています。IMDSv2 リクエストは、前の例のコマンドで作成された保管済みトークン (期限内であると仮定) を使用します。

IMDSv2IMDSv1
IMDSv2
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ami-id ami-0abcdef1234567890
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/ami-id ami-0abcdef1234567890

 

IMDSv2IMDSv1
IMDSv2
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/reservation-id r-0efghijk987654321
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/reservation-id r-0efghijk987654321

 

IMDSv2IMDSv1
IMDSv2
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/local-hostname ip-10-251-50-12.ec2.internal
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/local-hostname ip-10-251-50-12.ec2.internal

 

IMDSv2IMDSv1
IMDSv2
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/public-hostname ec2-203-0-113-25.compute-1.amazonaws.com
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-hostname ec2-203-0-113-25.compute-1.amazonaws.com

使用可能なパブリックキーのリストを取得する

次の例では、使用できるパブリックキーの一覧を取得しています。

IMDSv2IMDSv1
IMDSv2
[ec2-user ~]$ `curl -X PUT "http://169.254.169.254/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/public-keys/ 0=my-public-key
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/ 0=my-public-key

パブリックキー0が使用できるフォーマットを示す

次の例は、パブリックキー0のフォーマットを示しています。

IMDSv2IMDSv1
IMDSv2
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/public-keys/0/ openssh-key
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/0/ openssh-key

パブリックキー0を取得する (OpenSSH キーフォーマット)

次の例では、パブリックキー0を取得しています (OpenSSH キーフォーマット)。

IMDSv2IMDSv1
IMDSv2
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v 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
IMDSv1
[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

インスタンスのサブネット ID を取得する

次の例では、インスタンスのサブネット ID を取得しています。

IMDSv2IMDSv1
IMDSv2
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id subnet-be9b61d7
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id subnet-be9b61d7

Throttling

クエリはインスタンスメタデータサービスでインスタンスごとにスロットリングし、インスタンスからインスタンスメタデータサービスへの同時接続数を制限します。

AWS セキュリティ認証情報を取得するためにインスタンスメタデータサービスを使用している場合、毎回のトランザクションで、または高頻度のスレッドやプロセスから同時に認証情報をクエリしないようにします。スロットリングの原因となる可能性があります。代わりに、認証情報をキャッシュに格納して有効期限が近づくまで待つことをお勧めします。

インスタンスメタデータサービスにアクセスする際にスロットリングした場合、エクスポネンシャルパックオフ戦略でクエリを再試行します。

インスタンスメタデータサービスの制限

ローカルファイアウォールルールを使って、プロセスの一部またはすべてからインスタンスメタデータサービスへのアクセスを無効化することを検討できます。

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で実行中のプロセス以外のすべてのプロセスによるインスタンスメタデータサービスへのアクセスを禁止しています。

$ 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 の使用も検討できます。次の例では、インスタンスメタデータサービスへのアクセスをルートユーザーにのみ制限しています。

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 のデフォルトは最初に一致したルールです。

インスタンスユーザーデータの使用

インスタンスユーザーデータを使用する場合は、次の点に注意してください。

  • ユーザーデータは、base64 でエンコードされている必要があります。Amazon EC2コンソールは、base64 エンコードを実行したり、base64 エンコード入力を受け入れたりできます。

  • ユーザーデータは raw 形式の 16 KB に制限されます (以前は base64 エンコード)。base64 エンコード後の 文字列の長さサイズ n は、ceil(n/3)*4 です。

  • ユーザーデータを取得するときにユーザーデータを base64 デコードする必要があります。インスタンスのメタデータあるいはコンソールを使用してデータを取得する場合、自動的にデコードされます。

  • ユーザーデータは不透明なデータとして取り扱われ、指定したデータがそのまま返されます。このデータを解釈できるかどうかは、インスタンスによって異なります。

  • インスタンスを停止してユーザーデータを変更した場合、インスタンスを起動しても、更新されたユーザーデータはは実行されません。

起動時にインスタンスユーザーデータを指定する

インスタンスの起動時のユーザーデータを指定できます。詳細については、「インスタンス起動ウィザードを使用してインスタンスを起動する」および「Linux インスタンスでの起動時のコマンドの実行」を参照してください。

インスタンスユーザーデータを変更する

ルートボリュームが EBS ボリュームの場合は、停止状態のインスタンスのユーザーデータを変更することができます。詳細については、「インスタンスユーザーデータの表示と更新」を参照してください。

インスタンスユーザーデータを取得する

実行中のインスタンス内からユーザーデータを取得するには、次の URI を使用します。

http://169.254.169.254/latest/user-data

ユーザーデータのリクエストは、データをそのままの状態で返します (コンテンツタイプ application/octet-stream)。

この例は、カンマで区切られたテキストとして指定されたユーザーデータを返します。

IMDSv2IMDSv1
IMDSv2
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/user-data 1234,john,reboot,true | 4512,richard, | 173,,,
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/user-data 1234,john,reboot,true | 4512,richard, | 173,,,

この例では、スクリプトとして指定されたユーザーデータを返します。

IMDSv2IMDSv1
IMDSv2
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/user-data #!/bin/bash yum update -y service httpd start chkconfig httpd on
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/user-data #!/bin/bash yum update -y service httpd start chkconfig httpd on

お使いのコンピュータからインスタンスのユーザーデータを取得するには、「ユーザーデータと AWS CLI」を参照してください。

動的データの取得

実行中のインスタンス内から動的データを取得するには、次の URI を使用します。

http://169.254.169.254/latest/dynamic/

この例では、高レベルのインスタンスアイデンティティカテゴリを取得する方法を表示しています。

IMDSv2IMDSv1
IMDSv2
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v 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

動的データの詳細およびその取得方法の例については、「インスタンスアイデンティティドキュメント」を参照してください。

例: AMI 作成インデックス値

この例は、ユーザーデータおよびインスタンスメタデータの両方を使用してインスタンスを設定する方法を示しています、

この例では、Alice がお気に入りの データベース AMI の 4 つのインスタンスを起動したいと考えています。そのうち最初の 1 つはマスターとして、残りの 3 つはレプリカとして動作します。これらのインスタンスを起動するときに、各レプリカントのレプリケーション戦略に関するユーザーデータを追加したいと考えています。このデータはすべての 4 つのインスタンスで使用可能となるので、どの部分が各インスタンスに該当するかをそれぞれが認識できるように、ユーザーデータを構築する必要があります。この構築は、各インスタンスに対して一意となる ami-launch-index インスタンスメタデータ値を使用して行うことができます。

Alice が構築したユーザーデータを次に示します。

replicate-every=1min | replicate-every=5min | replicate-every=10min

replicate-every=1min データは最初のレプリカントの設定を定義し、replicate-every=5min は 2 番目のレプリカントの設定を定義するというように、それぞれが定義を行います。Alice は、個別のインスタンスのデータをパイプシンボル (|) で区切って、このデータを ASCII 文字列として指定することにしました。

Alice は、run-instancesコマンドを使用して 4 つのインスタンスを起動します。このとき、次のユーザーデータを指定します。

aws ec2 run-instances --image-id ami-0abcdef1234567890 --count 4 --instance-type t2.micro --user-data "replicate-every=1min | replicate-every=5min | replicate-every=10min"

起動したすべてのインスタンスに、ユーザーデータのコピーと次に示す一般的なメタデータが含まれています。

  • AMI ID: ami-0abcdef1234567890

  • 予約 ID: r-1234567890abcabc0

  • パブリックキー: none

  • セキュリティグループ名: default

  • インスタンスタイプ: t2.micro

ただし、各インスタンスには所定の一意のメタデータが含まれます。

インスタンス 1

メタデータ
instance-id i-1234567890abcdef0
ami-launch-index 0
public-hostname ec2-203-0-113-25.compute-1.amazonaws.com
public-ipv4 67.202.51.223
local-hostname ip-10-251-50-12.ec2.internal
local-ipv4 10.251.50.35

インスタンス 2

メタデータ
instance-id i-0598c7d356eba48d7
ami-launch-index 1
public-hostname ec2-67-202-51-224.compute-1.amazonaws.com
public-ipv4 67.202.51.224
local-hostname ip-10-251-50-36.ec2.internal
local-ipv4 10.251.50.36

インスタンス 3

メタデータ
instance-id i-0ee992212549ce0e7
ami-launch-index 2
public-hostname ec2-67-202-51-225.compute-1.amazonaws.com
public-ipv4 67.202.51.225
local-hostname ip-10-251-50-37.ec2.internal
local-ipv4 10.251.50.37

インスタンス 4

メタデータ
instance-id i-1234567890abcdef0
ami-launch-index 3
public-hostname ec2-67-202-51-226.compute-1.amazonaws.com
public-ipv4 67.202.51.226
local-hostname ip-10-251-50-38.ec2.internal
local-ipv4 10.251.50.38

Alice は ami-launch-index 値を使用して、ユーザーデータのどの部分が特定のインスタンスに該当するかを判断できます。

  1. そのインスタンスの 1 つに接続し、ami-launch-index を取得して、それがレプリカントの 1 つであることを確認します。

    IMDSv2IMDSv1
    IMDSv2
    [ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/meta-data/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ami-launch-index 2

    次のステップでは、IMDSv2が前のIMDSv2コマンドからの保管済みトークン (期限内であると仮定) を使用するようリクエストします。

    IMDSv1
    [ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/ami-launch-index 2
  2. 変数としてami-launch-indexを保存します。

    IMDSv2IMDSv1
    IMDSv2
    [ec2-user ~]$ ami_launch_index=`curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ami-launch-index`
    IMDSv1
    [ec2-user ~]$ ami_launch_index=`curl http://169.254.169.254/latest/meta-data/ami-launch-index`
  3. ユーザーデータを変数として保存します。

    IMDSv2IMDSv1
    IMDSv2
    [ec2-user ~]$ user_data=`curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/user-data`
    IMDSv1
    [ec2-user ~]$ user_data=`curl http://169.254.169.254/latest/user-data`
  4. 最後に、Alice はcutコマンドを使用して、そのインスタンスに該当するユーザーデータの部分を抽出します。

    IMDSv2IMDSv1
    IMDSv2
    [ec2-user ~]$ echo $user_data | cut -d"|" -f"$ami_launch_index"replicate-every=5min
    IMDSv1
    [ec2-user ~]$ echo $user_data | cut -d"|" -f"$ami_launch_index" replicate-every=5min

インスタンスメタデータのカテゴリ

次の表は、インスタンスメタデータのカテゴリをまとめたものです。

重要

赤のテキストでフォーマットされたカテゴリ名は、インスタンスに固有のデータ用のプレースホルダーです。たとえば、mac はネットワークインターフェイスの MAC アドレスを表します。プレースホルダーを実際の値に置き換える必要があります。

データ 説明 導入されたバージョン
ami-id インスタンスの起動に使用される AMI ID。 1.0
ami-launch-index 同時に複数のインスタンスを起動した場合、この値はインスタンスが起動された順序を示します。最初に起動されたインスタンスの値は 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
block-device-mapping/ami root/boot ファイルシステムを含む仮想デバイス。 2007-12-15
block-device-mapping/ebsN 任意の Amazon EBS ボリュームに関連付けられた仮想デバイス。Amazon EBS ボリュームは、起動の時点またはインスタンスが最後に開始された時点で存在している場合にのみ、メタデータで使用できます。N は、Amazon EBS ボリュームのインデックス(ebs1ebs2 など)を示します。 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
elastic-gpus/associations/elastic-gpu-id インスタンスにアタッチされている Elastic GPU がある場合、その ID と接続情報を含めた Elastic GPU に関する情報の JSON 文字列が含まれます。 2016-11-30
elastic-inference/associations/eia-id インスタンスにアタッチされた Elastic Inference アクセラレーターがある場合、その ID とタイプを含めた Elastic Inference アクセラレーターに関する情報の JSON 文字列が含まれます。 2018-11-29
events/maintenance/history インスタンスの完了またはキャンセルされたメンテナンスイベントがある場合は、イベントに関する情報を含む JSON 文字列を含みます。詳細については、「完了またはキャンセルされたイベントのイベント履歴を表示するには」を参照してください。 2018-08-17
events/maintenance/scheduled インスタンスがアクティブなメンテナンスイベントがある場合は、イベントに関する情報を含む JSON 文字列を含みます。詳細については、「予定されたイベントの表示」を参照してください。 2018-08-17
hostname インスタンスのプライベート IPv4 DNS ホスト名。複数のネットワークインターフェイスが存在する場合、これは eth0 デバイス (デバイス番号が 0 のデバイス) を示します。 1.0
iam/info インスタンスに関連付けられた IAM ロールがある場合、インスタンスの LastUpdated の日付、InstanceProfileArn、InstanceProfileId など、インスタンスプロファイルが更新された最終時刻に関する情報が格納されます。そうでない場合は、なしになります。 2012-01-12
iam/security-credentials/role-name インスタンスに関連付けられた IAM ロールがある場合、role-name はロールの名前になり、role-name に、そのロールに関連付けられた一時的なセキュリティ認証情報が格納されます (詳細については、「インスタンスメタデータからセキュリティ認証情報を取得する」を参照してください)。そうでない場合は、なしになります。 2012-01-12
identity-credentials/ec2/info [内部使用のために留保] Amazon EC2 インフラストラクチャの残りのインスタンスを識別するために AWS が使用する認証情報に関する情報。 2018-05-23
identity-credentials/ec2/security-credentials/ec2-instance [内部使用のために留保] Amazon EC2 インフラストラクチャの残りのインスタンスを識別するために AWS が使用する認証情報に関する情報。 2018-05-23
instance-action バンドルの準備のために再起動する必要があることをインスタンスに伝えます。有効な値: none | shutdown | bundle-pending. 2008-09-01
instance-id このインスタンスの ID。 1.0
instance-type インスタンスの種類。詳細については、「インスタンスタイプ」を参照してください。 2007-08-29
kernel-id このインスタンスで起動したカーネルの ID (ある場合)。 2008-02-01
local-hostname インスタンスのプライベート IPv4 DNS ホスト名。複数のネットワークインターフェイスが存在する場合、これは eth0 デバイス (デバイス番号が 0 のデバイス) を示します。 2007-01-19
local-ipv4 インスタンスのプライベート IPv4 アドレス。複数のネットワークインターフェイスが存在する場合、これは eth0 デバイス (デバイス番号が 0 のデバイス) を示します。 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 アドレス。VPC 内に起動されたインスタンスに対してのみ返されます。 2016-06-30
network/interfaces/macs/mac/local-hostname インターフェイスのローカルホスト名。 2011-01-01
network/interfaces/macs/mac/local-ipv4s インターフェイスに関連付けられたプライベート IPv4 アドレス。 2011-01-01
network/interfaces/macs/mac/mac インスタンスの MAC アドレス。 2011-01-01
network/interfaces/macs/mac/owner-id ネットワークインターフェイスの所有者の ID。複数インターフェイスの環境では、インターフェイスは Elastic Load Balancing などのサードパーティによってアタッチできます。インターフェイス上のトラフィックは、常にインターフェイス所有者に対して課金されます。 2011-01-01
network/interfaces/macs/mac/public-hostname インターフェイスのパブリック DNS (IPv4)。このカテゴリは、enableDnsHostnames 属性が true に設定されている場合にのみ返されます。詳細については、「Using DNS with Your VPC」を参照してください。 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
product-codes インスタンスに関連付けられた AWS Marketplace 製品コード (ある場合)。 2007-03-01
public-hostname インスタンスのパブリック DNS。このカテゴリは、enableDnsHostnames 属性が true に設定されている場合にのみ返されます。詳細については、「Amazon VPC ユーザーガイド」の「VPC での DNS の使用」を参照してください。 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」を参照してください。

2016-11-15
spot/termination-time

スポットインスタンス のオペレーティングシステムがシャットダウン信号を受信するおよその時刻 (UTC)。この項目は、スポットインスタンスに Amazon EC2 による終了のマークが付けられている場合にのみ存在し、時刻値 (たとえば 2015-01-05T18:02:00Z) が含まれます。ユーザー自身が スポットインスタンス を終了した場合、termination-time 項目に時刻は設定されません。詳細については、「termination-time」を参照してください。

2014-11-05

動的データのカテゴリ

次の表は、動的データのカテゴリをまとめたものです。

データ 説明 導入されたバージョン
fws/instance-monitoring 顧客が CloudWatch で詳細な 1 分間隔のモニタリングを有効にしているかどうかを示す値。有効な値: enabled | disabled 2009-04-04
instance-identity/document インスタンス ID、プライベート IP アドレスなど、インスタンスの属性を含む JSON。「インスタンスアイデンティティドキュメント」を参照してください。 2009-04-04
instance-identity/pkcs7 署名に対してドキュメントの真正性およびコンテンツを確認するために使用されます。「インスタンスアイデンティティドキュメント」を参照してください。 2009-04-04
instance-identity/signature オリジンおよび権限を確認するために使用できるデータ。「インスタンスアイデンティティドキュメント」を参照してください。 2009-04-04