Utilisez Instance Metadata Service - Amazon Elastic Compute Cloud
Fonctionnement d’IMDSv2Transition vers l’IMDSv2Kits SDK pris en chargeExemples pour IMDSv2Exemples pour IMDSv1

Utilisez Instance Metadata Service

Vous pouvez accéder aux métadonnées d’instance à partir d’une instance en cours d’exécution en utilisant l’une des méthodes suivantes :

  • Service des métadonnées d’instance Version 2 (IMDSv2) – méthode orientée session

    Pour obtenir des exemples, consultez Exemples pour IMDSv2.

  • Service des métadonnées d’instance Version 1 (IMDSv1) – méthode de demande/réponse

    Pour obtenir des exemples, consultez Exemples pour IMDSv1.

Par défaut, vous pouvez utiliser IMDSv1 ou IMDSv2, ou les deux.

Vous pouvez configurer le service des métadonnées d’instance (IMDS) sur chaque instance afin que le code local ou les utilisateurs locaux doivent utiliser IMDSv2. Lorsque vous spécifiez que IMDSv2 doit être utilisé, IMDSv1 ne fonctionne plus. Pour plus d’informations sur la configuration de votre instance pour l’utilisation d’IMDSv2, veuillez consulter la rubrique Configuration du service des métadonnées d’instance.

Les en-têtes PUT ou GET sont uniques à IMDSv2. Si ces en-têtes sont présents dans la requête, celle-ci est destinée à IMDSv2. Si aucun en-tête n’est présent, on suppose que la requête est destinée à IMDSv1.

Pour un examen approfondi d’IMDSv2, veuillez consulter le billet de blog Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service.

Fonctionnement de Service des métadonnées d’instance Version 2

IMDSv2 utilise des demandes orientées session. Lorsque vous utilisez des demandes orientées session, vous créez un jeton de session qui définit la durée de la session, qui doit être d’une seconde au minimum et de six heures au maximum. Durant la période spécifiée, vous pouvez utiliser le même jeton de session pour les demandes suivantes. Une fois la période spécifiée arrivée à expiration, vous devez créer un nouveau jeton de session à utiliser pour les futures demandes.

Note

Les exemples de cette section utilisent l’adresse IPv4 du service des métadonnées d’instance (IMDS) : 169.254.169.254. Si vous récupérez des métadonnées d’instance pour les instances EC2 sur l’adresse IPv6, assurez-vous d’activer et d’utiliser l’adresse IPv6 à la place : [fd00:ec2::254]. L’adresse IPv6 de l’IMDS est compatible avec les commandes IMDSv2. L’adresse IPv6 n’est accessible que sur les instances basées sur Nitro dans un sous-réseau compatible IPv6 (double pile ou IPv6 uniquement).

L’exemple suivant utilise un script shell Linux et PowerShell ainsi que IMDSv2 pour extraire les éléments de métadonnées d’instance de haut niveau. Chaque exemple :

  • Crée un jeton de session d’une durée de six heures (21 600 secondes) en utilisant la demande PUT

  • Stockez l’en-tête du jeton de session dans une variable nommée TOKEN (sous Linux) ou token (sous Windows).

  • Demande les éléments de métadonnées de haut niveau à l’aide du jeton

Vous pouvez exécuter deux commandes distinctes ou les combiner.

Commandes distinctes

Tout d’abord, générez un jeton à l’aide de la commande suivante.

[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`

Utilisez ensuite le jeton pour générer des éléments de métadonnées de niveau supérieur à l’aide de la commande suivante.

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

Commandes combinées

Vous pouvez stocker le jeton et combiner les commandes. L’exemple suivant combine les deux commandes ci-dessus et stocke l’en-tête du jeton de session dans une variable nommée TOKEN.

Note

En cas d’erreur lors de la création du jeton, un message d’erreur remplace le jeton valide dans la variable et la commande ne fonctionne pas.

[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/

Une fois que vous avez créé un jeton, vous pouvez le réutiliser jusqu’à son expiration. Dans l’exemple de commande suivant, qui extrait l’ID de l’AMI utilisée pour lancer l’instance, le jeton stocké dans $TOKEN dans l’exemple précédent est réutilisé.

[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/ami-id
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/

Une fois que vous avez créé un jeton, vous pouvez le réutiliser jusqu’à son expiration. Dans l’exemple de commande suivant, qui extrait l’ID de l’AMI utilisée pour lancer l’instance, le jeton stocké dans $token dans l’exemple précédent est réutilisé.

PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} `
	-Method GET -uri http://169.254.169.254/latest/meta-data/ami-id

Lorsque vous utilisez IMDSv2 pour demander les métadonnées d’une instance, la demande doit inclure les éléments suivants :

  1. Utilisez une demande PUT pour lancer une session sur le service des métadonnées d’instance. La demande PUT renvoie un jeton qui doit être inclus dans les demandes GET suivantes envoyées au service des métadonnées d’instance. Le jeton est obligatoire pour accéder aux métadonnées à l’aide de IMDSv2.

  2. Incluez le jeton dans toutes les demandes GET envoyées à l’IMDS. Lorsque l’utilisation de jeton est définie sur required, les demandes sans jeton valide ou contenant un jeton arrivé à expiration reçoivent un code d’erreur HTTP 401 - Unauthorized.

    • Le jeton est une clé propre à l’instance. Le jeton n’est pas valide sur les autres instances EC2 et sera rejeté si vous tentez de l’utiliser ailleurs que sur l’instance sur laquelle il a été généré.

    • La demande PUT doit inclure un en-tête spécifiant la durée time-to-live (TTL) du jeton, en secondes, jusqu’à six heures au maximum (21 600 secondes). Le jeton représente une session logique. La durée de vie (TTL) définit la durée de validité du jeton et, par conséquent, la durée de la session.

    • Une fois qu’un jeton est arrivé à expiration, pour pouvoir continuer à accéder aux métadonnées de l’instance, vous devez créer une nouvelle session en utilisant un autre PUT.

    • Vous pouvez choisir de réutiliser un jeton ou d’en créer un nouveau pour chaque demande. Pour un faible nombre de demandes, il peut être plus facile de générer et d’utiliser immédiatement un jeton chaque fois que vous avez besoin d’accéder à l’IMDS. Cependant, pour une plus grande productivité, vous pouvez spécifier une durée plus longue pour le jeton et le réutiliser plutôt que de devoir écrire une demande PUT chaque fois que vous avez besoin de demander des métadonnées d’instance. Il n’existe pas de limite pratique au nombre de jetons simultanés, chacun représentant sa propre session. IMDSv2 est toutefois soumis aux limites normales de connexion de l’IMDS. Pour en savoir plus, consultez Limitation des demandes.

Les méthodes HTTP GET et HEAD sont autorisées dans les demandes de métadonnées d’instance IMDSv2. Les demandes PUT sont rejetées si elles contiennent un en-tête X-Forwarded-For.

Par défaut, la réponse aux demandes PUT possède une durée time-to-live (hop limit) de réponse de 1 au niveau du protocole IP. Si vous avez besoin d’une durée de vie plus longue, vous pouvez l’ajuster à l’aide de la commande AWS CLI modify-instance-metadata-options. Par exemple, vous pouvez avoir besoin d’une durée de vie plus élevée pour des raisons de compatibilité en amont avec les services de conteneur s’exécutant sur l’instance. Pour en savoir plus, consultez Configurer les options de métadonnées d’instance pour les instances existantes.

Passer à l’utilisation de Service des métadonnées d’instance Version 2

Lorsque vous effectuez la migration vers IMDSv2, nous vous recommandons d’utiliser les outils et le chemin de transition suivants.

Outils facilitant la migration vers IMDSv2

Si votre logiciel utilise IMDSv1, utilisez les outils suivants pour faciliter sa reconfiguration vers IMDSv2.

Logiciel AWS

Les dernières versions de l’AWS CLI et des kits SDK AWS prennent en charge IMDSv2. Pour utiliser IMDSv2, veillez à ce que vos instances EC2 possèdent les dernières versions de la CLI et des kits SDK. Pour plus d’informations sur la mise à jour de la CLI, consultez Installation, mise à jour et désinstallation d’AWS CLI dans le Guide de l’utilisateur AWS Command Line Interface.

Tous les packages logiciels Amazon Linux 2 prennent en charge IMDSv2. Dans Amazon Linux 2023, IMDSv1 est désactivé par défaut.

Pour connaître les versions minimales du kit SDK AWS qui prennent en charge IMDSv2, veuillez consulter Utilisation d’un kit SDK AWS pris en charge.

Analyseur de packages IMDS

L’analyseur de packages IMDS est un outil open source qui identifie et journalise les appels IMDSv1 depuis la phase de démarrage de votre instance. Cela peut aider à identifier le logiciel qui effectue des appels IMDSv1 sur les instances EC2, ce qui vous permet de déterminer exactement ce que vous devez mettre à jour pour que vos instances soient prêtes à utiliser IMDSv2 uniquement. Vous pouvez exécuter l’analyseur de packages IMDS à partir d’une ligne de commande ou l’installer en tant que service. Pour plus d’informations, consultez IMDS Packet Analyzer sur GitHub.

CloudWatch

IMDSv2 utilise des sessions basées sur un jeton, mais pas IMDSv1. La métrique CloudWatch MetadataNoToken suit le nombre d’appels au service des métadonnées d’instance (IMDS) qui utilisent IMDSv1. En suivant cette métrique jusqu’à zéro, vous pouvez déterminer si la totalité de votre logiciel a été mis à niveau vers IMDSv2 et le moment auquel cela se produit.

Après avoir désactivé IMDSv1, vous pouvez utiliser la métrique MetadataNoTokenRejected CloudWatch pour suivre le nombre de tentatives et de refus d’un appel IMDSv1. En suivant cette métrique, vous pouvez déterminer si votre logiciel doit être mis à jour pour utiliser IMDSv2.

Pour en savoir plus, consultez Métriques des instances.

Mises à jour des API et des CLI EC2

Pour les nouvelles instances, vous pouvez utiliser l’API RunInstances pour lancer les nouvelles instances qui nécessitent l’utilisation d’IMDSv2. Pour en savoir plus, consultez Configurer les options de métadonnées d’instance pour les nouvelles instances.

Pour les instances existantes, vous pouvez utiliser l’API ModifyInstanceMetadataOptions afin d’imposer l’utilisation d’IMDSv2. Pour en savoir plus, consultez Configurer les options de métadonnées d’instance pour les instances existantes.

Pour exiger l’utilisation de IMDSv2 sur toutes les nouvelles instances lancées par des groupes Auto Scaling, ces derniers peuvent utiliser un modèle de lancement ou une configuration de lancement. Lorsque vous créez un modèle de lancement ou une configuration de lancement, vous devez configurer les paramètres MetadataOptions pour exiger l’utilisation de IMDSv2. Le groupe Auto Scaling lance de nouvelles instances à l’aide du nouveau modèle de lancement ou de la nouvelle configuration de lancement, mais les instances existantes ne sont pas affectées. Vous pouvez utiliser l’API ModifyInstanceMetadataOptions pour exiger l’utilisation d’IMDSv2 sur les instances existantes d’un groupe Auto Scaling. Vous pouvez également résilier les instances : le groupe Auto Scaling lancera de nouvelles instances de remplacement avec les paramètres des options de métadonnées d’instance définis dans le nouveau modèle ou la nouvelle configuration de lancement.

Utilisation d’une AMI qui configure IMDSv2 par défaut

Lorsque vous lancez une instance, vous pouvez la configurer automatiquement pour utiliser IMDSv2 par défaut (le paramètre HttpTokens est défini sur required) en la lançant avec une AMI configurée avec le paramètre ImdsSupport défini sur v2.0. Vous pouvez définir le paramètre ImdsSupport sur v2.0 lorsque vous enregistrez l’AMI à l’aide de la commande CLI register-image, ou vous pouvez modifier une AMI existante à l’aide de la commande CLI modify-image-attribute. Pour en savoir plus, consultez Configurer l’AMI.

Politiques IAM et politiques de contrôle des services

Vous pouvez utiliser une politique IAM ou une politique de contrôle des services (SCP) AWS Organizations pour contrôler les utilisateurs comme suit :

  • Impossible de lancer une instance à l’aide de l’API RunInstances sauf si l’instance est configurée pour utiliser IMDSv2.

  • Impossible de modifier une instance en cours d’exécution à l’aide de l’API ModifyInstanceMetadataOptions pour réactiver IMDSv1.

La politique IAM ou la politique de contrôle des services doit contenir les clés de condition IAM suivantes :

  • ec2:MetadataHttpEndpoint

  • ec2:MetadataHttpPutResponseHopLimit

  • ec2:MetadataHttpTokens

Si un paramètre de l’appel d’API ou de CLI ne correspond pas à l’état spécifié dans la politique contenant la clé de condition, l’appel de l’API ou de la CLI échoue avec la réponse UnauthorizedOperation.

Vous pouvez en outre choisir une couche de protection supplémentaire afin d’imposer le passage de IMDSv1 à IMDSv2. Au niveau de la couche de gestion des accès concernant les API appelées via des informations d’identification de rôle EC2, vous pouvez utiliser une nouvelle clé de condition dans les politiques IAM ou les politiques de contrôle des services (SCP) AWS Organizations. Si vous utilisez la clé de condition ec2:RoleDelivery avec la valeur 2.0 dans vos politiques IAM, les appels d’API effectués avec des informations d’identification de rôle EC2 obtenues à partir de IMDSv1 recevront une réponse UnauthorizedOperation. Vous pouvez aboutir au même résultat plus généralement avec cette condition requise par une SCP. Cela permet de s’assurer que les informations d’identification fournies via IMDSv1 ne peuvent pas être utilisées pour appeler des API, car tout appel d’API ne respectant pas la condition spécifiée recevra une erreur UnauthorizedOperation.

Par exemple les stratégies IAM, consultez Utiliser des métadonnées d’instance. Pour plus d’informations sur les politiques de contrôle des services, consultez Politiques de contrôle des services dans le Guide de l’utilisateur AWS Organizations.

Nous vous recommandons, tout en utilisant les outils mentionnés précédemment, de suivre ce chemin pour la migration vers IMDSv2.

Etape 1 : Au départ

Mettez à jour les kit SDK, les CLI et vos logiciels utilisant des informations d’identification de rôle sur leurs instances EC2 vers des versions compatibles avec IMDSv2. Pour plus d’informations sur la mise à jour de la CLI, consultez Mise à niveau vers la dernière version d’AWS CLI dans le Guide de l’utilisateur AWS Command Line Interface.

Modifiez ensuite les logiciels accédant directement aux métadonnées de l’instance (en d’autres termes, n’utilisant pas un kit SDK) à l’aide des demandes IMDSv2. Vous pouvez utiliser l’analyseur de packages IMDS pour identifier le logiciel que vous devez modifier pour utiliser les requêtes IMDSv2.

Étape 2 : suivre la progression de votre transition

Suivez la progression de votre transition à l’aide de la métrique CloudWatch MetadataNoToken. Cette métrique indique le nombre d’appels IMDSv1 à l’IMDS sur vos instances. Pour en savoir plus, consultez Métriques des instances.

Étape 3 : quand il n’y a aucune utilisation de IMDSv1

Quand la métrique CloudWatch MetadataNoToken n’enregistre aucune utilisation de IMDSv1, vos instances sont prêtes à passer entièrement à l’utilisation de IMDSv2. A ce stade, voici ce que vous pouvez faire :

  • Pays par défaut

    Vous pouvez configurer IMDSv2 pour qu’il soit obligatoire comme compte par défaut. Lorsqu’une instance est lancée, la configuration de l’instance est automatiquement définie sur la valeur par défaut du compte.

    Pour définir la valeur par défaut du compte, procédez comme suit :

    • Console Amazon EC2 : sur le tableau de bord EC2, sous Attributs du compte, Protection et sécurité des données, pour les valeurs par défaut de l’IMDS, définissez le service de métadonnées de l’instance sur Activé et la version des métadonnées sur V2 uniquement (jeton requis). Pour en savoir plus, consultez Définissez IMDSv2 comme valeur par défaut pour le compte.

    • AWS CLI: utilisez la commande CLI modify-instance-metadata-defaults et spécifiez et. --http-tokens required --http-put-response-hop-limit 2

  • Nouvelles instances

    Lors du lancement d’une nouvelle instance, vous pouvez effectuer les opérations suivantes :

    • Console Amazon EC2 : dans l’assistant de lancement d’instance, définissez Metadata accessible (Métadonnées accessibles) sur Enabled (Activé) et Metadata version (Version des métadonnées) sur V2 only (token required) (V2 uniquement [jeton obligatoire]). Pour en savoir plus, consultez Configurer l’instance au lancement.

    • AWS CLI : utilisez la commande de CLI run-instances pour spécifier que seul IMDSv2 doit être utilisé.

  • Instances existantes

    Pour les instances existantes, vous pouvez exécuter les opérations suivantes :

    • Console Amazon EC2 : sur la page Instances, sélectionnez votre instance, choisissez Actions, Paramètres de l’instance, Modifier les options des métadonnées d’instance et, pour IMDSv2, choisissez Requis. Pour en savoir plus, consultez Exigence d’utilisation d’IMDSv2.

    • AWS CLI : utilisez la commande CLI modify-instance-metadata-options pour spécifier que seul l’IMDSv2 doit être utilisé.

    Vous pouvez modifier les options des métadonnées d’instance sur les instances en cours d’exécution, et vous n’avez pas besoin de redémarrer les instances après avoir modifié ces options.

Étape 4 : vérifiez que vos instances ont bien été migrées vers IMDSv2

Vous pouvez vérifier si des instances ne sont pas encore configurées pour l’utilisation d’IMDSv2. En d’autres termes, si IMDSv2 est toujours configuré comme optional. Si des instances sont toujours configurées sur optional, vous pouvez modifier les options des métadonnées d’instance pour rendre IMDSv2 required en répétant l’étape 3 précédente.

Pour filtrer vos instances :

  • Console Amazon EC2 : sur la page Instances, filtrez vos instances à l’aide du filtre IMDSv2 = facultatif. Pour plus d’informations sur le filtrage, veuillez consulter la rubrique Filtrer des ressources à l’aide de la console. Vous pouvez également voir si IMDSv2 est requis ou facultatif pour chaque instance : dans la fenêtre Préférences, activez IMDSv2 pour ajouter la colonne IMDSv2 au tableau Instances.

  • AWS CLI : utilisez la commande CLI describe-instances et filtrez par metadata-options.http-tokens = optional, comme suit :

    aws ec2 describe-instances --filters "Name=metadata-options.http-tokens,Values=optional" --query "Reservations[*].Instances[*].[InstanceId]" --output text

Étape 5 : lorsque toutes vos instances ont été migrées sur IMDSv2

Les clés de condition IAM ec2:MetadataHttpTokens, ec2:MetadataHttpPutResponseHopLimit et ec2:MetadataHttpEndpoint peuvent être utilisées pour contrôler l’utilisation des API RunInstances et ModifyInstanceMetadataOptions et des CLI correspondantes. Si une stratégie est créée et qu’un paramètre de l’appel d’API ne correspond pas à l’état spécifié dans la stratégie à l’aide de la clé de condition, l’appel de l’API ou de l’interface de ligne commande échoue avec la réponse UnauthorizedOperation. Par exemple les stratégies IAM, consultez Utiliser des métadonnées d’instance.

En outre, après avoir désactivé IMDSv1, vous pouvez utiliser la métrique MetadataNoTokenRejected CloudWatch pour suivre le nombre de tentatives et de refus d’un appel IMDSv1. Si, après avoir désactivé IMDSv1, vous avez un logiciel qui ne fonctionne pas correctement et que la MetadataNoTokenRejected métrique enregistre les appels IMDSv1, il est probable que ce logiciel doive être mis à jour pour utiliser IMDSv2.

Utilisation d’un kit SDK AWS pris en charge

Pour utiliser IMDSv2, vos instances EC2 doivent utiliser une version du kit SDK AWS compatible avec IMDSv2. Les dernières versions de tous les kits SDK AWS prennent en charge l’utilisation de IMDSv2.

Important

Nous vous recommandons de vous tenir au courant des versions du kit SDK afin de rester à jour avec les dernières fonctionnalités, mises à jour de sécurité et dépendances sous-jacentes. L’utilisation continue d’une version du kit SDK non prise en charge n’est pas recommandée et est effectuée à votre discrétion. Pour plus d’informations, veuillez consulter la politique de maintenance des kits SDK et des outils AWS dans le Guide de référence des kits SDK et des outils AWS.

Voici les versions minimales qui prennent en charge IMDSv2 :

Exemples pour IMDSv2

Exécutez les exemples suivants sur votre instance Amazon EC2 pour récupérer les métadonnées de l’instance pour IMDSv2.

Sur les instances Windows, vous pouvez utiliser Windows PowerShell ou installer cURL ou wget. Si vous installez un outil tiers sur une instance Windows, assurez-vous de lire avec attention la documentation fournie car la méthode d’appel du HTTP et le format de sortie peuvent être différents de ce qui figure dans la présente documentation.

Obtenir les versions disponibles des métadonnées d’instance

Cet exemple permet d’obtenir les versions disponibles des métadonnées d’instance. Chaque version fait référence à un build de métadonnées d’instance lorsque de nouvelles catégories de métadonnées d’instance ont été publiées. Les versions de métadonnées d’instance ne sont pas en corrélation avec les versions de l’API Amazon EC2. Les versions antérieures sont disponibles au cas où vous ayez des scripts reposant sur la structure et les informations présentes dans une version précédente.

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

Obtenir les éléments de métadonnées de niveau supérieur

Cet exemple permet d’obtenir les éléments de métadonnées de niveau supérieur. Pour de plus amples informations sur la réponse , veuillez consultez PUT Object dans le .

Notez que les balises ne sont incluses dans cette sortie que si vous en avez autorisé l’accès. Pour en savoir plus, consultez Autoriser l’accès aux identifications dans les métadonnées d’instance.

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/

Obtenir les valeurs des éléments de métadonnées

Les exemples suivants permettent d’extraire les valeurs de certains de éléments de métadonnées de niveau supérieur qui ont été obtenus dans l’exemple précédent. Ces demandes utilisent le jeton stocké qui a été créé à l’aide de la commande de l’exemple précédent. Le jeton ne doit pas avoir expiré.

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

Obtenir la liste des clés publiques disponibles

Cet exemple permet d’obtenir la liste des clés publiques disponibles.

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

Montrer les formats pour lesquels une clé publique 0 est disponible

Cet exemple montre les formats pour lesquels une clé publique 0 est disponible.

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

Obtenir la clé publique 0 (au format clé OpenSSH)

Cet exemple permet d’obtenir la clé publique 0 (au format clé 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

Obtenir l’ID de sous-réseau d’une instance

Cet exemple permet d’obtenir l’ID de sous-réseau pour une instance.

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

Obtenir les identifications d’une instance

Vous pouvez également renommer l’instance à l’aide d’identifications dans les métadonnées d’instance si votre instance est configurée pour accéder aux identifications à partir des métadonnées d’instance. Pour en savoir plus, consultez Extraire les identifications à partir des métadonnées d'instance.

Exemples pour IMDSv1

Exécutez les exemples suivants sur votre instance Amazon EC2 pour récupérer les métadonnées de l’instance pour IMDSv1.

Sur les instances Windows, vous pouvez utiliser Windows PowerShell ou installer cURL ou wget. Si vous installez un outil tiers sur une instance Windows, assurez-vous de lire avec attention la documentation fournie car la méthode d’appel du HTTP et le format de sortie peuvent être différents de ce qui figure dans la présente documentation.

Obtenir les versions disponibles des métadonnées d’instance

Cet exemple permet d’obtenir les versions disponibles des métadonnées d’instance. Chaque version fait référence à un build de métadonnées d’instance lorsque de nouvelles catégories de métadonnées d’instance ont été publiées. Les versions de métadonnées d’instance ne sont pas en corrélation avec les versions de l’API Amazon EC2. Les versions antérieures sont disponibles au cas où vous ayez des scripts reposant sur la structure et les informations présentes dans une version précédente.

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

Obtenir les éléments de métadonnées de niveau supérieur

Cet exemple permet d’obtenir les éléments de métadonnées de niveau supérieur. Pour de plus amples informations sur la réponse , veuillez consultez PUT Object dans le .

Notez que les balises ne sont incluses dans cette sortie que si vous en avez autorisé l’accès. Pour en savoir plus, consultez Autoriser l’accès aux identifications dans les métadonnées d’instance.

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/

Obtenir les valeurs des éléments de métadonnées

Les exemples suivants permettent d’extraire les valeurs de certains de éléments de métadonnées de niveau supérieur qui ont été obtenus dans l’exemple précédent.

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

Obtenir la liste des clés publiques disponibles

Cet exemple permet d’obtenir la liste des clés publiques disponibles.

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

Montrer les formats pour lesquels une clé publique 0 est disponible

Cet exemple montre les formats pour lesquels une clé publique 0 est disponible.

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

Obtenir la clé publique 0 (au format clé OpenSSH)

Cet exemple permet d’obtenir la clé publique 0 (au format clé 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

Obtenir l’ID de sous-réseau d’une instance

Cet exemple permet d’obtenir l’ID de sous-réseau pour une instance.

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

Obtenir les identifications d’une instance

Vous pouvez également renommer l’instance à l’aide d’identifications dans les métadonnées d’instance si votre instance est configurée pour accéder aux identifications à partir des métadonnées d’instance. Pour en savoir plus, consultez Extraire les identifications à partir des métadonnées d'instance.