インスタンスメタデータの取得
インスタンスメタデータは実行中のインスタンスから取得できるため、Amazon EC2 コンソールまたは AWS CLI を使用する必要はありません。これは、インスタンスから実行するスクリプトを記述しているときに便利です。例えば、インスタンスメタデータからインスタンスのローカル IP アドレスにアクセスして、外部アプリケーションへの接続を管理できます。
インスタンスメタデータはいくつかのカテゴリに分けられます。各インスタンスメタデータカテゴリの説明については、インスタンスメタデータのカテゴリを参照してください。
実行中のインスタンス内にあるインスタンスメタデータの、すべてのカテゴリを表示するには、以下の IPv4 または IPv6 URI を使用します。
IPv4
http://169.254.169.254/latest/meta-data/
IPv6
http://[fd00:ec2::254]/latest/meta-data/
これらの IP アドレス は、リンクローカルアドレスであり、インスタンスからのみ使用することが可能です。詳細については、Wikipedia の「リンクローカルアドレス
このセクションの例では、インスタンスメタデータサービスの IPv4 アドレスを使用します。169.254.169.254
。IPv6 アドレスを使用して EC2 インスタンスのインスタンスメタデータを取得する場合は、IPv6 アドレスを有効にして使用してください。fd00:ec2::254
。インスタンスメタデータサービスの IPv6 アドレスは、IMDSv2 コマンドと互換性があります。IPv6 アドレスは、Nitro System 上に構築されたインスタンス上でのみアクセスできます。
コマンドフォーマットは、IMDSv1とIMDSv2のどちらを使うかによって異なります。デフォルトでは、両方のインスタンスメタデータサービスを使用できます。IMDSv2の使用を義務付けるには、IMDSv2 の使用を参照してください。
PowerShell コマンドレットを使用して URI を取得できます。例えば、バージョン 3.0 以降の PowerShell を実行している場合、次の cmdlet を使用します。
PowerShell の使用を避けたい場合は、GNU Wget や cURL などのサードパーティツールをインストールしてください。
Windows インスタンスにサードパーティツールをインストールする場合は、HTTP の呼び出し方法および出力形式がここに記載されているものとは異なることがあるので、必ず付属のドキュメントをよく読んでください。
Linux インスタンスからインスタンスメタデータを取得するコマンドについては、「Windows インスタンス用 Amazon EC2 ユーザーガイド」の「インスタンスメタデータの取得」を参照してください。
コスト
インスタンスメタデータおよびユーザーデータの取得に使用する HTTP リクエストに対しては課金されません。
考慮事項
インスタンスメタデータの取得に関する問題を回避するには、次の点を考慮してください。
-
AWS SDK はデフォルトで IMDSv2 コールを使用します。IMDSv2 呼び出しに応答がない場合、SDK は呼び出しを再試行し、それでも失敗した場合は、IMDSv1 を使用します。これにより、遅延が発生することがあります。コンテナ環境では、ホップ制限が 1 の場合、コンテナへの到達は余分なネットワークホップと見なされるため、IMDSv2 応答は返されません。IMDSv1 へのフォールバックプロセスとその結果として生じる遅延を回避するために、コンテナ環境でホップ制限を 2 に設定することをお勧めします。詳細については、インスタンスメタデータオプションの設定 を参照してください。
-
カスタム Windows AMI を使用して Windows インスタンスを起動する場合、インスタンスメタデータサービスがインスタンスで動作するように、AMI は Sysprep を使用して作成された標準化されたイメージである必要があります。そうでなければ、インスタンスメタデータサービスは機能しません。
-
IMDSv2 でトークンを取得する際には、
/latest/api/token
を使用する必要があります。 バージョン固有の任意のパス (例:/2021-03-23/api/token
) にPUT
リクエストを発行した場合は、メタデータサービスから 403 Forbidden エラーが返されます。この応答は意図されたものです。
リスポンスおよびエラーメッセージ
すべてのインスタンスメタデータがテキスト (HTTP コンテンツタイプ text/plain
) として返されます。
特定のメタデータリソースに対するリクエストは、適切な値または 404 - Not Found
HTTP エラーコード (リソースを使用できない場合) を返します。
一般的なメタデータリソースに対するリクエスト (/ で終わる URI) は、使用可能なリソースのリストまたは 404 - Not Found
HTTP エラーコード (使用可能なリソースがない場合) を返します。リスト項目は個別の行に表示され、各行の末尾には改行記号 (ASCII 10) が付いています。
インスタンスメタデータサービスバージョン 2を使って行われたリクエストについては、次の HTTP エラーコードが返されます。
-
400 - Missing or Invalid Parameters
–PUT
リクエストが無効である。 -
401 - Unauthorized
–GET
リクエストが無効なトークンを使用している。推奨されるアクションは新しいトークンを生成することです。 -
403 - Forbidden
–リクエストが許可されていないか、あるいはインスタンスメタデータサービスがオフです。
インスタンスメタデータの取得の例
次の例は、Windows インスタンスで使用できるコマンドを示しています。Linux インスタンスからインスタンスメタデータを取得するコマンドについては、「Windows インスタンス用 Amazon EC2 ユーザーガイド」の「インスタンスメタデータの取得」を参照してください。
例
使用できるインスタンスメタデータのバージョンを取得する
次の例では、使用できるインスタンスメタデータのバージョンを取得しています。各バージョンは、新しいインスタンスのメタデータカテゴリがリリースされたときのインスタンスメタデータビルドを参照します。インスタンスメタデータビルドのバージョンは、Amazon EC2 API のバージョンとは相関しません。以前のバージョンに存在する構造および情報に依存するスクリプトがある場合は、以前のバージョンを使用することができます。
Amazon EC2 が新しいインスタンスメタデータビルドをリリースするたびにコードを更新する必要をなくすために、バージョン番号ではなく、パス内の latest
を使用することが推奨されます。例えば、以下のように latest
を使用します。
curl http://169.254.169.254/latest/meta-data/ami-id
上位レベルのメタデータ項目を取得する
次の例では、上位レベルのメタデータ項目を取得しています。詳細については、インスタンスメタデータのカテゴリ を参照してください。
次の例では、前の例で取得された最上位メタデータアイテムの値のいくつかを取得しています。IMDSv2 リクエストは、前の例のコマンドで作成された保管済みトークン (期限内であると仮定) を使用します。
使用可能なパブリックキーのリストを取得する
次の例では、使用できるパブリックキーの一覧を取得しています。
パブリックキー 0 が使用できるフォーマットを示す
次の例は、パブリックキー0のフォーマットを示しています。
パブリックキー 0 を取得する (OpenSSH キーフォーマット)
次の例では、パブリックキー0を取得しています (OpenSSH キーフォーマット)。
インスタンスのサブネット ID を取得する
次の例では、インスタンスのサブネット ID を取得しています。
インスタンスのインスタンスタグを取得する
次の例では、サンプルインスタンスでインスタンスメタデータのタグが有効になっており、インスタンスタグ Name=MyInstance
および Environment=Dev
が含まれています。
この例では、インスタンスのインスタンスタグキーをすべて取得しています。
次の例では、前の例で取得した Name
キーの値を取得しています。IMDSv2 リクエストは、前の例のコマンドで作成された保管済みトークン (期限内であると仮定) を使用します。
クエリスロットル
クエリはインスタンスメタデータサービスでインスタンスごとにスロットリングし、インスタンスからインスタンスメタデータサービスへの同時接続数を制限します。
AWS セキュリティ認証情報を取得するためにインスタンスメタデータサービスを使用している場合、毎回のトランザクションで、または高頻度のスレッドやプロセスから同時に認証情報をクエリしないようにします。スロットリングの原因となる可能性があります。代わりに、認証情報をキャッシュに格納して有効期限が近づくまで待つことをお勧めします。IAM ロールとロールに関連付けられたセキュリティ認証情報の詳細については、「インスタンスメタデータからのセキュリティ認証情報の取得」を参照してください。
インスタンスメタデータサービスにアクセスする際にスロットリングした場合、エクスポネンシャルバックオフ戦略でクエリを再試行します。
インスタンスメタデータサービスのアクセス制限
ローカルファイアウォールルールを使って、プロセスの一部またはすべてからインスタンスメタデータサービスへのアクセスを無効化することを検討できます。
Nitro System 上に構築されたインスタンス では、VPC 内のネットワークアプライアンス (仮想ルーターなど) がパケットを IMDS アドレスに転送し、かつ、インスタンス上のデフォルトの送信元/送信先チェックが無効な場合、IMDS がユーザー自身のネットワークから到達可能になります。VPC の外側にある送信元から IMDS に到達しないようにするには、送信先 IMDS の IPv4 アドレスが 169.254.169.254(IPv6 エンドポイントを有効にしている場合は、fd00:ec2::254)であるパケットをドロップするように、ネットワークアプライアンスの設定を変更することをお勧めします。
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 コマンドプロンプトから設定する必要があり、拒否または許可の特定のプリンシパルに設定できません。