

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Accéder aux métadonnées d’une instance EC2
<a name="instancedata-data-retrieval"></a>

Vous pouvez accéder aux métadonnées de l'instance EC2 depuis l'intérieur de l'instance elle-même ou depuis la console EC2 SDKs, l'API ou le. AWS CLI Pour obtenir les paramètres de métadonnées d’instance actuels d’une instance à partir de la console ou de la ligne de commande, consultez [Interroger les options de métadonnées d’instance pour les instances existantes](#query-IMDS-existing-instances).

Vous pouvez également modifier les données de l’utilisateur pour les instances avec un volume racine EBS. L’instance doit être à l’état arrêté. Pour obtenir des instructions de la console, consultez [Mettre à jour les données de l’utilisateur de l’instance](user-data.md#user-data-modify). Pour un exemple de Linux utilisant le AWS CLI, voir [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html). Pour un exemple de Windows utilisant les outils pour Windows PowerShell, voir[Données utilisateur et outils pour Windows PowerShell](user-data.md#user-data-powershell).

**Note**  
Vous n’êtes pas facturé pour les requêtes HTTP utilisées pour récupérer les métadonnées d’instance et les données utilisateur.

## Considérations sur l’accès aux métadonnées d’instance
<a name="imds-considerations"></a>

Pour éviter les problèmes liés aux métadonnées d'instance, tenez compte des points suivants.

**Échec du lancement de l'instance dû à IMDSv2 l'application (`HttpTokensEnforced=enabled`)**  
Avant d'activer IMDSv2 l'application, vous devez prendre en charge tous les logiciels de l'instance IMDSv2, après quoi vous pouvez modifier la valeur par défaut en disable IMDSv1 (`httpTokens=required`), après quoi vous pouvez activer l'application. Pour plus d’informations, consultez [Passer à l’utilisation de Service des métadonnées d’instance Version 2](instance-metadata-transition-to-version-2.md).

**Format de la commande**  
Le format de commande est différent selon que vous utilisez le service de métadonnées d'instance version 1 (IMDSv1) ou le service de métadonnées d'instance version 2 (IMDSv2). Par défaut, vous pouvez utiliser les deux services de métadonnées d’instance. Pour imposer l'utilisation de IMDSv2, veuillez consulter [Utilisez Instance Metadata Service](configuring-instance-metadata-service.md).

**Si IMDSv2 nécessaire, IMDSv1 ne fonctionne pas**  
Si vous utilisez IMDSv1 et ne recevez aucune réponse, il est probable que cela IMDSv2 soit nécessaire. Pour vérifier si IMDSv2 c'est nécessaire, sélectionnez l'instance pour en afficher les détails. La **IMDSv2**valeur indique **Obligatoire** (vous devez utiliser IMDSv2) ou **Facultatif** (vous pouvez utiliser l'un IMDSv2 ou l'autreIMDSv1). 

**(IMDSv2) /latest/api/token À utiliser pour récupérer le jeton**  
L’envoi de requêtes `PUT` à tout chemin spécifique d’une version, par exemple `/2021-03-23/api/token`, a pour effet que le service de métadonnées retourne des erreurs 403 Interdit. Ce comportement est prévu.

**Version des métadonnées**  
Pour éviter de devoir mettre à jour votre code chaque fois qu’Amazon EC2 publie un nouveau build des métadonnées d’instance, nous vous recommandons d’utiliser `latest` dans le chemin d’accès, et non le numéro de version.

**IPv6 soutien**  
Pour récupérer les métadonnées d'une instance à l'aide d'une IPv6 adresse, assurez-vous d'activer et d'utiliser l'IPv6 adresse de l'IMDS `[fd00:ec2::254]` au lieu de l' IPv4adresse`169.254.169.254`. L'instance doit être une [instance basée sur Nitro](instance-types.md#instance-hypervisor-type) lancée dans un [sous-réseau compatible](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range). IPv6

**(Windows) Création d'une version personnalisée à AMIs l'aide de Windows Sysprep**  
Pour garantir le fonctionnement de l’IMDS lorsque vous lancez une instance à partir d’une AMI Windows personnalisée, l’AMI doit être une image standardisée créée avec Windows Sysprep. Sinon, l’IMDS ne fonctionnera pas. Pour de plus amples informations, veuillez consulter [Créer une AMI Amazon EC2 à l’aide de Windows Sysprep](ami-create-win-sysprep.md).

**Dans un environnement de conteneurs, envisagez de reconfigurer ou d’augmenter la limite de saut à 2**  
L' AWS SDKs utilisateur IMDSv2 appelle par défaut. Si l' IMDSv2 appel ne reçoit aucune réponse, certains AWS SDKs relancent l'appel et, en cas d'échec, utilisentIMDSv1. Cela peut entraîner un retard, en particulier dans un environnement de conteneurs. Pour ceux AWS SDKs qui en ont *besoin* IMDSv2, si la limite de sauts est de 1 dans un environnement de conteneur, l'appel risque de ne pas recevoir de réponse du tout car le fait d'accéder au conteneur est considéré comme un saut réseau supplémentaire.  
Pour atténuer ces problèmes dans un environnement de conteneur, pensez à modifier la configuration pour transmettre les paramètres (tels que Région AWS) directement au conteneur, ou envisagez d'augmenter la limite de sauts à 2. Pour en savoir plus sur l’impact de la limite de saut, consultez la section [Ajout d’une défense en profondeur contre les pare-feu ouverts, les proxys inversés et les vulnérabilités SSRF grâce aux améliorations apportées au service de métadonnées d’instance EC2](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/). Pour plus d’informations sur la modification de la limite de saut, consultez la section [Modifier la durée de vie de la réponse PUT](configuring-IMDS-existing-instances.md#modify-PUT-response-hop-limit).

**Limite de paquets par seconde (PPS)**  
Il existe une limite de 1024 paquets par seconde (PPS) pour les services qui utilisent des adresses [lien-local.](using-instance-addressing.md#link-local-addresses) Cette limite inclut l’ensemble des [requêtes DNS du résolveur Route 53](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#vpc-dns-limits), des demandes IMDS (Instance Metadata Service), des demandes [NTP (Amazon Time Service Network Time Protocol)](set-time.md) et des demandes du [Windows Licensing Service (pour les instances basées sur Microsoft Windows)](https://aws.amazon.com/windows/resources/licensing/). 

**Considérations supplémentaires sur l’accès aux données utilisateur**
+ Les données utilisateur sont traitées comme des données opaques : ce que vous spécifiez est ce que vous obtenez en retour. Il appartient à l’instance d’interpréter et d’agir sur les données utilisateur.
+ Les données utilisateur doivent être codées en base64. Selon l’outil ou le SDK que vous utilisez, le codage base64 peut être effectué pour vous. Par exemple :
  + La console Amazon EC2 peut effectuer l’encodage base64 pour vous ou accepter les entrées codées en base64.
  + [AWS CLI la version 2](https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html#cliv2-migration-binaryparam) effectue le codage en base64 des paramètres binaires pour vous par défaut. AWS CLI la version 1 effectue le codage en base64 du `--user-data` paramètre pour vous.
  +  AWS SDK pour Python (Boto3) Procède au codage base64 du `UserData` paramètre pour vous.
+ Les données d’utilisateur sont limitées à 16 Ko en format brut, avant qu’elles soient encodées en base64. La taille d’une chaîne de longueur *n* après l’encodage base64 est ceil(*n*/3)\$14.
+ Les données utilisateur doivent être décodées en base64 lorsque vous les récupérez. Si vous les récupérez à l’aide des métadonnées d’instance ou de la console, les données sont décodées automatiquement.
+ Si vous arrêtez une instance, modifiez ses données utilisateur et démarrez l’instance, les données utilisateur mises à jour ne sont pas exécutées automatiquement lorsque vous démarrez l’instance. En ce qui concerne les instances Windows, vous pouvez configurer les paramètres de manière à ce que les scripts de données utilisateur mis à jour soient exécutés une fois au démarrage de l’instance ou à chaque redémarrage ou démarrage de l’instance.
+ Les données utilisateur sont un attribut d’instance. Si vous créez une AMI à partir d’une instance, les données utilisateur d’instance ne sont pas incluses dans l’AMI.

## Accédez aux métadonnées de l’instance depuis une instance EC2
<a name="instancedata-inside-access"></a>

Puisque vos métadonnées d’instance sont disponibles à partir de votre instance en cours d’exécution, vous n’avez pas besoin d’utiliser la console Amazon EC2, ni la AWS CLI. Cela peut être utile lorsque vous écrivez des scripts à exécuter depuis votre instance. Par exemple, vous pouvez accéder à l’adresse IP locale de votre instance à partir des métadonnées d’instance afin de gérer une connexion à une application externe.

Tous les éléments suivants sont considérés comme des métadonnées d’instance, mais ils sont accessibles de différentes manières. Sélectionnez l’onglet qui représente le type de métadonnées d’instance auquel vous souhaitez accéder pour obtenir plus d’informations.

------
#### [ Metadata ]

Les propriétés des métadonnées d’instance sont divisées en catégories. Pour obtenir une description de chaque catégorie de métadonnées d’instance, consultez [Catégories de métadonnées d’instance](ec2-instance-metadata.md#instancedata-data-categories).

Pour accéder aux propriétés des métadonnées de l'instance depuis une instance en cours d'exécution, récupérez les données à partir du IPv4 ou IPv6 URIs. Ces adresses IP sont des adresses locales et ne sont valables qu’à partir de l’instance. Pour de plus amples informations, veuillez consulter [Adresses lien-local](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 ]

Pour récupérer des données dynamiques depuis une instance en cours d'exécution, utilisez l'une des méthodes suivantesURIs.

**IPv4**

```
http://169.254.169.254/latest/dynamic/
```

**IPv6**

```
http://[fd00:ec2::254]/latest/dynamic/
```

**Exemples : accès avec cURL**  
Les exemples suivants permettent `cURL` de récupérer les catégories d’identité d’instance de haut niveau.

*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
```

**Exemples : Accès avec PowerShell**  
Les exemples suivants permettent PowerShell de récupérer les catégories d'identité d'instance de haut niveau.

*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
```

Pour plus d’informations sur les données dynamiques et pour des exemples sur la façon de les récupérer, consultez [Documents d'identité d'instance pour les EC2 instances Amazon](instance-identity-documents.md).

------
#### [ User data ]

Pour récupérer les données utilisateur d'une instance, utilisez l'une des méthodes suivantes URIs. Pour récupérer les données utilisateur à l'aide de l' IPv6 adresse, vous devez l'activer, et l'instance doit être une [instance basée sur Nitro](instance-types.md#instance-hypervisor-type) dans un sous-réseau compatible. IPv6

**IPv4**

```
http://169.254.169.254/latest/user-data
```

**IPv6**

```
http://[fd00:ec2::254]/latest/user-data
```

Une demande de données utilisateur renvoie les données telles qu’elles sont (type de contenu `application/octet-stream`). Si l’instance ne possède aucune donnée utilisateur, la demande renvoie `404 - Not Found`.

**Exemples : Accès avec cURL pour récupérer du texte séparé par des virgules**  
Les exemples suivants permettent de `cURL` récupérer des données utilisateur qui ont été spécifiées sous la forme de texte séparé par des virgules.

*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,,,
```

**Exemples : Accès avec PowerShell pour récupérer du texte séparé par des virgules**  
Les exemples suivants permettent de PowerShell récupérer des données utilisateur spécifiées sous forme de texte séparé par des virgules.

*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,,,
```

**Exemples : Accès avec cURL pour récupérer un script**  
Les exemples suivants permettent `cURL` de récupérer des données utilisateur qui ont été spécifiées sous la forme d’un script.

*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
```

**Exemples : Accès avec PowerShell pour récupérer un script**  
Les exemples suivants permettent PowerShell de récupérer les données utilisateur spécifiées sous forme de script.

*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
<powershell>
$file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
New-Item $file -ItemType file
</powershell>
<persist>true</persist>
```

*IMDSv1*

```
Invoke-RestMethod -uri http://169.254.169.254/latest/user-data
<powershell>
$file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
New-Item $file -ItemType file
</powershell>
<persist>true</persist>
```

------

## Interroger les options de métadonnées d’instance pour les instances existantes
<a name="query-IMDS-existing-instances"></a>

Vous pouvez modifier les options des métadonnées d’instance pour les instances existantes.

------
#### [ Console ]

**Pour interroger les options de métadonnées d’instance pour une instance existante**

1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Dans le panneau de navigation, choisissez **Instances**.

1. Sélectionnez votre instance et vérifiez les champs suivants :
   + **IMDSv2**— La valeur est **obligatoire** ou **facultative**.
   + **Autoriser les balises dans les métadonnées de l’instance** : la valeur est **Activé** ou **Désactivé**.

1. Choisissez **Actions**, **Paramètres de l’instance**, puis **Modifier les options des métadonnées d’instance**.

   La boîte de dialogue indique si le service de métadonnées d’instance est activé ou désactivé pour l’instance sélectionnée.

------
#### [ AWS CLI ]

**Pour interroger les options de métadonnées d’instance pour une instance existante**  
Utilisez la commande [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 ]

**Pour interroger les options de métadonnées d'instance pour une instance existante à l'aide des outils de PowerShell**  
Utilisez l’applet de commande [Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html).

```
(Get-EC2Instance `
    -InstanceId i-1234567898abcdef0).Instances.MetadataOptions
```

------

## Réponses et messages d’erreur
<a name="instance-metadata-returns"></a>

Toutes les métadonnées d’instance sont retournées sous forme de texte (type de contenu HTTP `text/plain`).

Une requête pour une ressource de métadonnées spécifique retourne la valeur appropriée ou un code d’erreur HTTP `404 - Not Found` si la ressource n’est pas disponible.

Une requête pour une ressource de métadonnées générale (l’URI se termine par un /) retourne une liste de ressources disponibles ou un code d’erreur HTTP `404 - Not Found` si une telle ressource n’existe pas. Les éléments de la liste se trouvent sur des lignes séparées se terminant par des sauts de ligne (ASCII 10).

Si une IMDSv1 demande ne reçoit aucune réponse, il est probable que cela IMDSv2 soit nécessaire.

Pour les requêtes effectuées via IMDSv2, les codes d'erreur HTTP suivants peuvent être renvoyés :
+ `400 - Missing or Invalid Parameters` – La demande `PUT` n’est pas valide.
+ `401 - Unauthorized` – La demande `GET` utilise un jeton non valide. Il est recommandé dans ce cas de générer un nouveau jeton.
+ `403 - Forbidden` : la demande n’est pas autorisée ou l’IMDS est désactivé.
+ `404 - Not Found` : la ressource n’est pas disponible ou n’existe pas.
+ `503` : la demande n’a pas pu être exécutée. Réitérez la demande.

Si l’IMDS renvoie une erreur, **curl** imprime le message d’erreur dans la sortie et renvoie un code d’état de réussite. Le message d’erreur est stocké dans la variable `TOKEN`, ce qui entraîne l’échec des commandes **curl** utilisant le jeton. Si vous appelez **curl** à l’aide de l’option **-f**, elle renvoie un code d’état d’erreur en cas d’erreur du serveur HTTP. Si vous activez la gestion des erreurs, le shell peut détecter l’erreur et arrêter le script.

## Limitation des demandes
<a name="instancedata-throttling"></a>

Nous limitons les requêtes envoyées par chaque instance à l’IMDS et appliquons des limites au nombre de connexions simultanées possible depuis une instance vers l’IMDS. 

Si vous utilisez l'IMDS pour récupérer des informations d'identification de AWS sécurité, évitez de demander des informations d'identification lors de chaque transaction ou simultanément à partir d'un grand nombre de threads ou de processus, car cela pourrait entraîner un ralentissement. Nous vous conseillons plutôt de placer les informations d’identification en cache jusqu’à ce que leur date d’expiration approche. Pour plus d’informations sur le rôle IAM et les informations d’identification de sécurité associées au rôle, consultez [Extraire les informations d’identification de sécurité à partir des métadonnées d’instance](instance-metadata-security-credentials.md).

Si vous rencontrez des limitations alors que vous tentez d’accéder à l’IMDS, renvoyez une requête avec une stratégie de backoff exponentiel.

# Utilisez Instance Metadata Service
<a name="configuring-instance-metadata-service"></a>

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 de métadonnées d'instance version 2 (IMDSv2) : méthode orientée session

  Pour obtenir des exemples, consultez [Exemples pour IMDSv2](#instance-metadata-retrieval-examples).
+ Service de métadonnées d'instance version 1 (IMDSv1) — une request/response méthode

  Pour obtenir des exemples, consultez [Exemples pour IMDSv1](#instance-metadata-retrieval-examples-imdsv1).

Par défaut, vous pouvez utiliser l'un IMDSv1 ou IMDSv2 l'autre ou les deux.

Vous pouvez configurer le service de métadonnées d'instance (IMDS) sur chaque instance pour n'accepter que les IMDSv2 appels, ce qui entraînera l'échec des IMDSv1 appels. Pour plus d'informations sur la configuration de votre instance à utiliser IMDSv2, consultez[Configuration du service des métadonnées d’instance](configuring-instance-metadata-options.md).

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

Pour un examen approfondi de IMDSv2, voir [Ajouter une défense approfondie contre les pare-feux ouverts, les proxys inverses et les vulnérabilités SSRF grâce à des améliorations apportées au service de métadonnées d'instance EC2](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/).

**Topics**
+ [Fonctionnement de Service des métadonnées d’instance Version 2](#instance-metadata-v2-how-it-works)
+ [Utiliser un AWS SDK compatible](#use-a-supported-sdk-version-for-imdsv2)
+ [Exemples pour IMDSv2](#instance-metadata-retrieval-examples)
+ [Exemples pour IMDSv1](#instance-metadata-retrieval-examples-imdsv1)

## Fonctionnement de Service des métadonnées d’instance Version 2
<a name="instance-metadata-v2-how-it-works"></a>

IMDSv2 utilise des requêtes axées sur les sessions. 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' IPv4 adresse du service de métadonnées d'instance (IMDS) :`169.254.169.254`. Si vous récupérez des métadonnées d'instance pour des instances EC2 via l' IPv6 adresse, assurez-vous d'activer et d'utiliser l' IPv6 adresse à la place :. `[fd00:ec2::254]` L' IPv6 adresse de l'IMDS est compatible avec IMDSv2 les commandes. L' IPv6 adresse n'est accessible que sur les [instances basées sur Nitro](instance-types.md#instance-hypervisor-type) dans un [sous-réseau IPv6 pris en charge](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) (double pile ou IPv6 uniquement).

Les exemples suivants utilisent un script shell IMDSv2 pour récupérer les éléments de métadonnées de l'instance de niveau supérieur. 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

### Exemple Linux
<a name="how-imdsv2-works-example-linux"></a>

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 permet d’obtenir 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
```

### Exemple Windows
<a name="how-imdsv2-works-example-windows"></a>

```
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 permet d’obtenir 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 demandez IMDSv2 des métadonnées d'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.

1. 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 aucune limite pratique quant au nombre de jetons simultanés, chacun représentant sa propre session. IMDSv2 est toutefois toujours limité par la connexion IMDS normale et les limites de limitation. Pour de plus amples informations, veuillez consulter [Limitation des demandes](instancedata-data-retrieval.md#instancedata-throttling).

Les méthodes HTTP `GET` et `HEAD` sont autorisées dans les demandes de métadonnées d'instance IMDSv2. Les requêtes `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 limite de sauts plus importante, vous pouvez l'ajuster à l'aide de la [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) AWS CLI commande. 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 de plus amples informations, veuillez consulter [Configurer les options de métadonnées d’instance pour les instances existantes](configuring-IMDS-existing-instances.md).

## Utiliser un AWS SDK compatible
<a name="use-a-supported-sdk-version-for-imdsv2"></a>

Pour utiliser IMDSv2, vos instances EC2 doivent utiliser une version du AWS SDK qui prend en charge l'utilisation. IMDSv2 Les dernières versions de tous les AWS SDKs supports utilisant 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, consultez la [politique de maintenance de AWS SDKs and Tools](https://docs.aws.amazon.com/sdkref/latest/guide/maint-policy.html) dans le *guide de référence AWS SDKs and Tools*.

Les versions minimales prises en charge sont les suivantes 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 pour .NET](https://github.com/aws/aws-sdk-net) : 3.3.634.1
+ [AWS SDK pour C\$1\$1](https://github.com/aws/aws-sdk-cpp) : 1.7.229
+ [AWS SDK pour Go](https://github.com/aws/aws-sdk-go) : 1.25.38
+ [AWS SDK pour Go](https://github.com/aws/aws-sdk-go-v2) v2 — 0.19.0
+ [AWS SDK pour 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 SDK pour Node.js — JavaScript 2.722.0](https://github.com/aws/aws-sdk-js)
+ [AWS SDK pour Kotlin](https://github.com/awslabs/aws-sdk-kotlin) : 1.1.4
+ [AWS SDK pour PHP](https://github.com/aws/aws-sdk-php) : 3.147.7
+ [AWS SDK pour Python (Botocore) — 1.13.25](https://github.com/boto/botocore)
+ [AWS SDK pour Python (Boto3)](https://github.com/boto/boto3) : 1.12.6
+ [AWS SDK pour Ruby](https://github.com/aws/aws-sdk-ruby) : 3.79.0

## Exemples pour IMDSv2
<a name="instance-metadata-retrieval-examples"></a>

Exécutez les exemples suivants sur votre instance Amazon EC2 afin de 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, veillez à lire attentivement la documentation qui l’accompagne, car les appels et les résultats peuvent être différents de ceux décrits ici.

**Topics**
+ [Obtenir les versions disponibles des métadonnées d’instance](#instance-metadata-ex-1)
+ [Obtenir les éléments de métadonnées de niveau supérieur](#instance-metadata-ex-2)
+ [Obtenir les valeurs des éléments de métadonnées](#instance-metadata-ex-2a)
+ [Obtenir la liste des clés publiques disponibles](#instance-metadata-ex-3)
+ [Montrer les formats pour lesquels une clé publique 0 est disponible](#instance-metadata-ex-4)
+ [Obtenir la clé publique 0 (au format clé OpenSSH)](#instance-metadata-ex-5)
+ [Obtenir l’ID de sous-réseau d’une instance](#instance-metadata-ex-6)
+ [Obtenir les identifications d’une instance](#instance-metadata-ex-7)

### Obtenir les versions disponibles des métadonnées d’instance
<a name="instance-metadata-ex-1"></a>

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
<a name="instance-metadata-ex-2"></a>

Cet exemple permet d’obtenir les éléments de métadonnées de niveau supérieur. Pour plus d’informations sur les éléments de la réponse, consultez la rubrique [Catégories de métadonnées d’instance](ec2-instance-metadata.md#instancedata-data-categories).

Notez que les balises ne sont incluses dans cette sortie que si vous en avez autorisé l’accès. Pour de plus amples informations, veuillez consulter [Activation de l’accès aux balises dans les métadonnées d’instance](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/
```

------

### Obtenir les valeurs des éléments de métadonnées
<a name="instance-metadata-ex-2a"></a>

Ces exemples permettent d’obtenir les valeurs de certains des éléments de métadonnées de premier niveau 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
<a name="instance-metadata-ex-3"></a>

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
<a name="instance-metadata-ex-4"></a>

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)
<a name="instance-metadata-ex-5"></a>

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
<a name="instance-metadata-ex-6"></a>

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
<a name="instance-metadata-ex-7"></a>

Si l’accès aux balises d’instance dans les métadonnées d’instance est activé, vous pouvez obtenir les balises d’une instance à partir des métadonnées d’instance. Pour de plus amples informations, veuillez consulter [Extraire les identifications à partir des métadonnées d’instance](work-with-tags-in-IMDS.md#retrieve-tags-from-IMDS).

## Exemples pour IMDSv1
<a name="instance-metadata-retrieval-examples-imdsv1"></a>

Exécutez les exemples suivants sur votre instance Amazon EC2 afin de 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, veillez à lire attentivement la documentation qui l’accompagne, car les appels et les résultats peuvent être différents de ceux décrits ici.

**Topics**
+ [Obtenir les versions disponibles des métadonnées d’instance](#instance-metadata-ex-1-imdsv1)
+ [Obtenir les éléments de métadonnées de niveau supérieur](#instance-metadata-ex-2-imdsv1)
+ [Obtenir les valeurs des éléments de métadonnées](#instance-metadata-ex-2a-imdsv1)
+ [Obtenir la liste des clés publiques disponibles](#instance-metadata-ex-3-imdsv1)
+ [Montrer les formats pour lesquels une clé publique 0 est disponible](#instance-metadata-ex-4-imdsv1)
+ [Obtenir la clé publique 0 (au format clé OpenSSH)](#instance-metadata-ex-5-imdsv1)
+ [Obtenir l’ID de sous-réseau d’une instance](#instance-metadata-ex-6-imdsv1)
+ [Obtenir les identifications d’une instance](#instance-metadata-ex-7-imdsv1)

### Obtenir les versions disponibles des métadonnées d’instance
<a name="instance-metadata-ex-1-imdsv1"></a>

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
<a name="instance-metadata-ex-2-imdsv1"></a>

Cet exemple permet d’obtenir les éléments de métadonnées de niveau supérieur. Pour plus d’informations sur les éléments de la réponse, consultez la rubrique [Catégories de métadonnées d’instance](ec2-instance-metadata.md#instancedata-data-categories).

Notez que les balises ne sont incluses dans cette sortie que si vous en avez autorisé l’accès. Pour de plus amples informations, veuillez consulter [Activation de l’accès aux balises dans les métadonnées d’instance](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/
```

------

### Obtenir les valeurs des éléments de métadonnées
<a name="instance-metadata-ex-2a-imdsv1"></a>

Ces exemples permettent d’obtenir les valeurs de certains des éléments de métadonnées de premier niveau 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
<a name="instance-metadata-ex-3-imdsv1"></a>

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
<a name="instance-metadata-ex-4-imdsv1"></a>

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)
<a name="instance-metadata-ex-5-imdsv1"></a>

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
<a name="instance-metadata-ex-6-imdsv1"></a>

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
<a name="instance-metadata-ex-7-imdsv1"></a>

Si l’accès aux balises d’instance dans les métadonnées d’instance est activé, vous pouvez obtenir les balises d’une instance à partir des métadonnées d’instance. Pour de plus amples informations, veuillez consulter [Extraire les identifications à partir des métadonnées d’instance](work-with-tags-in-IMDS.md#retrieve-tags-from-IMDS).

# Passer à l’utilisation de Service des métadonnées d’instance Version 2
<a name="instance-metadata-transition-to-version-2"></a>

Si vous souhaitez configurer vos instances pour accepter uniquement les appels du service de métadonnées d'instance version 2 (IMDSv2), nous vous recommandons d'utiliser les outils et le chemin de transition suivants.

**Topics**
+ [Outils de transition vers IMDSv2](#tools-for-transitioning-to-imdsv2)
+ [Chemin recommandé pour exiger IMDSv2](#recommended-path-for-requiring-imdsv2)

## Outils de transition vers IMDSv2
<a name="tools-for-transitioning-to-imdsv2"></a>

Les outils suivants peuvent vous aider à identifier, surveiller et gérer la transition de votre logiciel de IMDSv1 vers IMDSv2. Pour obtenir des instructions sur l'utilisation de ces outils, reportez-vous à[Chemin recommandé pour exiger IMDSv2](#recommended-path-for-requiring-imdsv2).

**AWS logiciel**  
Les dernières versions du AWS SDK AWS CLI et du kit de développement prennent en charge l'IMDSv2. Pour utiliser IMDSv2, mettez à jour vos instances EC2 afin d'utiliser les dernières versions. Pour connaître les versions minimales du AWS SDK prises en charge IMDSv2, consultez[Utiliser un AWS SDK compatible](configuring-instance-metadata-service.md#use-a-supported-sdk-version-for-imdsv2).  
Tous les packages logiciels Amazon Linux 2 et Amazon Linux 2023 sont pris en charge IMDSv2. Amazon Linux 2023 est désactivé IMDSv1 par défaut.

**Analyseur de packages IMDS**  
IMDS Packet Analyzer est un outil open source qui identifie et enregistre les IMDSv1 appels pendant la phase de démarrage et les opérations d'exécution de votre instance. En analysant ces journaux, vous pouvez identifier avec précision le logiciel effectuant des IMDSv1 appels sur vos instances et déterminer ce qui doit être mis à jour pour IMDSv2 ne prendre en charge que vos instances. 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, voir [AWS ImdsPacketAnalyzer](https://github.com/aws/aws-imds-packet-analyzer)ci-dessous *GitHub*.

**CloudWatch**  
CloudWatch fournit les deux mesures suivantes pour surveiller vos instances :  
`MetadataNoToken`— IMDSv2 utilise des sessions basées sur des jetons, ce qui n'est IMDSv1 pas le cas. La `MetadataNoToken` métrique suit le nombre d'appels utilisés par le service de métadonnées d'instance (IMDS). 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.  
`MetadataNoTokenRejected`— Une fois que vous avez désactivé IMDSv1, vous pouvez utiliser la `MetadataNoTokenRejected` métrique pour suivre le nombre de tentatives et de refus d'un IMDSv1 appel. En suivant cette métrique, vous pouvez déterminer si votre logiciel doit être mis à jour pour être utilisé IMDSv2.  
Pour chaque instance EC2, ces métriques s'excluent mutuellement. Lorsque cette option IMDSv1 est activée (`httpTokens = optional`), `MetadataNoToken` émet uniquement. Lorsque cette IMDSv1 option est désactivée (`httpTokens = required`), `MetadataNoTokenRejected` émet uniquement. Pour savoir dans quels cas utiliser ces mesures, consultez[Chemin recommandé pour exiger IMDSv2](#recommended-path-for-requiring-imdsv2).  
Pour de plus amples informations, veuillez consulter [Métriques des instances](viewing_metrics_with_cloudwatch.md#ec2-cloudwatch-metrics).

**Lancer APIs**  
**Nouvelles instances :** utilisez l'[RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)API pour lancer de nouvelles instances nécessitant l'utilisation de IMDSv2. Pour de plus amples informations, veuillez consulter [Configurer les options de métadonnées d’instance pour les nouvelles instances](configuring-IMDS-new-instances.md).  
**Instances existantes :** utilisez l'[ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html)API pour exiger l'utilisation IMDSv2 d'instances existantes. Pour de plus amples informations, veuillez consulter [Configurer les options de métadonnées d’instance pour les instances existantes](configuring-IMDS-existing-instances.md).  
**Nouvelles instances lancées par les groupes Auto Scaling :** pour exiger l'utilisation de toutes IMDSv2 les nouvelles instances lancées par les groupes Auto Scaling, vos groupes Auto Scaling peuvent utiliser un modèle de lancement ou une configuration de lancement. Lorsque vous [créez un modèle de lancement](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-launch-template.html) ou [une configuration de lancement](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/create-launch-configuration.html), 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.   
**Instances existantes dans un groupe Auto Scaling :** utilisez l'[ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html)API pour exiger l'utilisation d'IMDSv2 instances existantes, ou mettez fin aux instances et 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 de lancement ou dans la nouvelle configuration de lancement.

**AMIs**  
AMIs configuré avec le `ImdsSupport` paramètre défini sur `v2.0` lancera les instances qui nécessitent IMDSv2 par défaut. Amazon Linux 2023 est configuré avec`ImdsSupport = v2.0`.  
**Nouveau AMIs :** utilisez la commande [register-image CLI](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html) pour définir le `ImdsSupport` paramètre sur `v2.0` lors de la création d'une nouvelle AMI.  
**Existant AMIs :** utilisez la commande [modify-image-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-image-attribute.html)CLI pour définir le `ImdsSupport` paramètre sur `v2.0` lorsque vous modifiez une AMI existante.  
Pour de plus amples informations, veuillez consulter [Configurer l’AMI](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-ami-configuration).

**Contrôles au niveau du compte**  
Vous pouvez configurer des valeurs par défaut pour toutes les options de métadonnées de l'instance au niveau du compte. Les valeurs par défaut sont automatiquement appliquées lorsque vous lancez une instance. Pour plus d'informations, voir[Définir IMDSv2 comme valeur par défaut pour le compte](configuring-IMDS-new-instances.md#set-imdsv2-account-defaults).  
Vous pouvez également imposer l'obligation d'utilisation IMDSv2 au niveau du compte. Lorsque IMDSv2 l'application est activée :  
+ **Nouvelles instances :** les instances configurées pour être lancées avec IMDSv1 activé ne pourront pas être lancées
+ **Instances existantes IMDSv1 désactivées :** les tentatives d'activation IMDSv1 sur des instances existantes seront empêchées.
+ **Instances existantes IMDSv1 activées :** les instances existantes IMDSv1 déjà activées ne seront pas affectées.
Pour de plus amples informations, veuillez consulter [Appliquer IMDSv2 au niveau du compte](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level).

**Politiques IAM et SCPs**  
Vous pouvez utiliser une stratégie IAM ou une politique de contrôle des AWS Organizations services (SCP) pour contrôler les utilisateurs comme suit :  
+ Impossible de lancer une instance à l'aide de l'[RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)API à moins que l'instance ne soit configurée pour être utilisée IMDSv2.
+ Impossible de modifier une instance existante à l'aide de l'[ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html)API pour la réactiverIMDSv1.
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 qui contient la clé de condition, l'appel d'API ou de CLI échoue avec une `UnauthorizedOperation` réponse.  
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, en ce qui concerne les API appelées via les informations d'identification du rôle EC2, vous pouvez utiliser une clé de condition dans les politiques IAM ou les politiques de contrôle des AWS Organizations services ()SCPs. Plus précisément, en utilisant la clé de condition `ec2:RoleDelivery` avec une valeur de `2.0` dans vos politiques IAM, les appels d'API effectués avec les informations d'identification du rôle EC2 obtenues IMDSv1 recevront une `UnauthorizedOperation` réponse. Vous pouvez aboutir au même résultat plus généralement avec cette condition requise par une SCP. Cela garantit que les informations d'identification fournies via IMDSv1 ne peuvent pas être réellement utilisées pour appeler, APIs car tout appel d'API ne correspondant pas à la condition spécifiée recevra une `UnauthorizedOperation` erreur.  
Par exemple les stratégies IAM, consultez [Utiliser des métadonnées d’instance](ExamplePolicies_EC2.md#iam-example-instance-metadata). Pour plus d'informations SCPs, consultez la section [Politiques de contrôle des services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de AWS Organizations l'utilisateur*.

**Politiques déclaratives**  
Utilisez les politiques déclaratives (une fonctionnalité de AWS Organizations) pour définir de manière centralisée les paramètres par défaut des comptes IMDS, y compris leur IMDSv2 application, au sein de votre organisation. Pour un exemple de politique, consultez l'onglet **Métadonnées d'instance** dans la section [Politiques déclaratives prises en charge](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples) du *Guide de l'AWS Organizations utilisateur*.

## Chemin recommandé pour exiger IMDSv2
<a name="recommended-path-for-requiring-imdsv2"></a>

**Topics**
+ [Étape 1 : Identifier les instances avec IMDSv2 =optional et auditer leur utilisation IMDSv1](#path-step-1)
+ [Étape 2 : mettre à jour le logiciel pour IMDSv2](#path-step-2)
+ [Étape 3 : Exiger IMDSv2 des instances](#path-step-3)
+ [Étape 4 : définir IMDSv2 =required comme valeur par défaut](#path-step-4)
+ [Étape 5 : appliquer les instances à exiger IMDSv2](#path-step-5)

### Étape 1 : Identifier les instances avec IMDSv2 =optional et auditer leur utilisation IMDSv1
<a name="path-step-1"></a>

Pour évaluer l'étendue de votre IMDSv2 migration, identifiez les instances configurées pour autoriser l'un IMDSv1 ou IMDSv2 l'autre des appels et des IMDSv1 appels d'audit.

1. **Identifiez les instances configurées pour autoriser l'une IMDSv1 ou l'autre des options IMDSv2 suivantes :**

------
#### [ Amazon EC2 console ]

   1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. Dans le panneau de navigation, choisissez **Instances**.

   1. Pour afficher uniquement les instances configurées pour autoriser IMDSv1 ou IMDSv2, ajoutez le filtre **IMDSv2 = facultatif**.

   1. Sinon, pour savoir si IMDSv2 c'est **facultatif** ou **obligatoire** pour toutes les instances, ouvrez la fenêtre des **préférences** (icône en forme de roue dentée), activez-la **IMDSv2**et choisissez **Confirmer**. La **IMDSv2**colonne est alors ajoutée au tableau **Instances**.

------
#### [ AWS CLI ]

   Utilisez la commande [describe-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-options.html) 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
   ```

------

1. **L'audit IMDSv1 fait appel à chaque instance :**

   Utilisez la CloudWatch métrique`MetadataNoToken`. Cette métrique indique le nombre d' IMDSv1 appels à l'IMDS sur vos instances. Pour plus d'informations, consultez la section [Mesures relatives aux instances](https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics).

1. **Identifiez les logiciels présents sur vos instances qui passent des IMDSv1 appels :**

   Utilisez l'[analyseur de paquets IMDS](https://github.com/aws/aws-imds-packet-analyzer) open source pour identifier et enregistrer les IMDSv1 appels pendant la phase de démarrage et les opérations d'exécution de votre instance. Utilisez ces informations pour identifier le logiciel à mettre à jour afin que vos instances soient prêtes à être utilisées IMDSv2 uniquement. Vous pouvez exécuter l’analyseur de packages IMDS à partir d’une ligne de commande ou l’installer en tant que service.

### Étape 2 : mettre à jour le logiciel pour IMDSv2
<a name="path-step-2"></a>

Mettez à jour tous les SDKs logiciels qui utilisent les informations d'identification de rôle sur vos instances CLIs, ainsi que les logiciels qui utilisent les informations d'identification des rôles, vers des versions IMDSv2 compatibles. Pour en savoir plus sur la mise à jour de la CLI, consultez la section [Installation ou mise à jour de la dernière version de l’ AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) dans le *Guide de l’utilisateur AWS Command Line Interface *.

### Étape 3 : Exiger IMDSv2 des instances
<a name="path-step-3"></a>

Après avoir confirmé l'absence d' IMDSv1 appels par le biais de la `MetadataNoToken` métrique, configurez vos instances existantes en conséquence IMDSv2. Configurez également toutes les nouvelles instances à requérir IMDSv2. En d'autres termes, IMDSv1 désactivez-le sur toutes les instances existantes et nouvelles.

1. **Configurez les instances existantes pour exiger IMDSv2 :**

------
#### [ Amazon EC2 console ]

   1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. Dans le panneau de navigation, choisissez **Instances**.

   1. Sélectionnez votre instance.

   1. Choisissez **Actions**, **Paramètres de l’instance**, puis **Modifier les options des métadonnées d’instance**.

   1. Pour **IMDSv2**, choisissez **Obligatoire**.

   1. Choisissez **Enregistrer**.

------
#### [ AWS CLI ]

   Utilisez la commande [modify-instance-metadata-options](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-options.html)CLI pour spécifier que seule cette IMDSv2 option doit être utilisée. 

------
**Note**  
Vous pouvez modifier ce paramètre sur les instances en cours d'exécution. La modification prend effet immédiatement sans qu'il soit nécessaire de redémarrer l'instance.

   Pour de plus amples informations, veuillez consulter [Exiger l'utilisation de IMDSv2](configuring-IMDS-existing-instances.md#modify-require-IMDSv2).

1. **Surveillez les problèmes après la désactivation IMDSv1 :**

   1. Suivez le nombre de tentatives et de refus d'un IMDSv1 appel à l'aide de la `MetadataNoTokenRejected` CloudWatch métrique.

   1. Si la `MetadataNoTokenRejected` métrique enregistre les IMDSv1 appels à une instance qui rencontre des problèmes logiciels, cela indique que le logiciel doit être mis à jour pour être utilisé IMDSv2.

1. **Configurez les nouvelles instances pour exiger IMDSv2 :**

------
#### [ Amazon EC2 console ]

   1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. Suivez les étapes pour [lancer une instance](ec2-launch-instance-wizard.md).

   1. Développez **les détails avancés**, et pour **la version des métadonnées**, choisissez **V2 uniquement (jeton requis)**.

   1. Dans le panneau **Summary** (Résumé), vérifiez la configuration de votre instance, puis choisissez **Launch instance** (Lancer l’instance).

      Pour de plus amples informations, veuillez consulter [Configurer l’instance au lancement](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-instance-settings).

------
#### [ AWS CLI ]

   AWS CLI: utilisez la commande [run-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/run-instances.html) et spécifiez que IMDSv2 c'est obligatoire.

------

### Étape 4 : définir IMDSv2 =required comme valeur par défaut
<a name="path-step-4"></a>

Vous pouvez définir IMDSv2 =required comme configuration par défaut au niveau du compte ou de l'organisation. Cela garantit que toutes les instances nouvellement lancées sont automatiquement configurées pour être requises IMDSv2.

1. **Définissez le niveau par défaut du compte :**

------
#### [ Amazon EC2 console ]

   1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. Dans le panneau de navigation, sélectionnez **Dashboard** (Tableau de bord).

   1. Sur la fiche **Attributs du compte**, sous **Paramètres**, sélectionnez **Protection et sécurité des données**.

   1. **Dans la section **Paramètres par défaut de l'IMDS**, sélectionnez Gérer.**

   1. Pour le **service de métadonnées d'instance**, choisissez **Enabled**.

   1. Pour la **version des métadonnées**, choisissez **V2 uniquement (jeton requis)**.

   1. Choisissez **Mettre à jour**.

------
#### [ AWS CLI ]

   Utilisez la commande [modify-instance-metadata-defaults](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-defaults.html)CLI et spécifiez `--http-tokens required` et`--http-put-response-hop-limit 2`.

------

   Pour de plus amples informations, veuillez consulter [Définir IMDSv2 comme valeur par défaut pour le compte](configuring-IMDS-new-instances.md#set-imdsv2-account-defaults).

1. **Vous pouvez également définir la valeur par défaut au niveau de l'organisation à l'aide d'une politique déclarative :**

   Utilisez une politique déclarative pour définir la valeur par défaut de l'organisation IMDSv2 sur obligatoire. Pour un exemple de politique, consultez l'onglet **Métadonnées d'instance** dans la section [Politiques déclaratives prises en charge](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples) du *Guide de l'AWS Organizations utilisateur*.

### Étape 5 : appliquer les instances à exiger IMDSv2
<a name="path-step-5"></a>

Une fois que vous avez confirmé qu'il n'existe aucune IMDSv1 dépendance à l'égard de l'une de vos instances, nous vous recommandons de l'appliquer IMDSv2 à toutes les nouvelles instances.

Utilisez l'une des options suivantes pour appliquer IMDSv2 :

1. **Appliquer IMDSv2 à l'aide d'une propriété de compte**

   Vous pouvez imposer l'utilisation de IMDSv2 au niveau du compte pour chacun d'entre eux Région AWS. Lorsqu'elles sont appliquées, les instances ne peuvent être lancées que si elles sont configurées pour l'exiger IMDSv2. Cette application s'applique quelle que soit la configuration de l'instance ou de l'AMI. Pour de plus amples informations, veuillez consulter [Appliquer IMDSv2 au niveau du compte](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level). Pour appliquer ce paramètre au niveau de l'organisation, définissez une politique déclarative. Pour un exemple de politique, consultez l'onglet **Métadonnées d'instance** dans la section [Politiques déclaratives prises en charge](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples) du *Guide de l'AWS Organizations utilisateur*.

   Pour éviter un renversement de l'application, vous devez utiliser une politique IAM pour empêcher l'accès à l'[ModifyInstanceMetadataDefaults](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataDefaults.html)API. Pour de plus amples informations, veuillez consulter [Utiliser une politique IAM](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-iam-policy).
**Note**  
Ce paramètre ne modifie pas la version IMDS des instances existantes, mais bloque l'activation IMDSv1 sur les instances existantes actuellement IMDSv1 désactivées.
**Avertissement**  
Si IMDSv2 l'application est activée et n'`httpTokens`est définie ni `required` dans la configuration de l'instance au lancement, ni dans les paramètres du compte, ni dans la configuration de l'AMI, le lancement de l'instance échouera. Pour plus d’informations sur le dépannage, consultez [Le lancement d'une instance IMDSv1 activée échoue](troubleshooting-launch.md#launching-an-imdsv1-enabled-instance-fails).

1. **Vous pouvez également appliquer IMDSv2 en utilisant les clés de condition IAM ou SCP suivantes :**
   + `ec2:MetadataHttpTokens`
   + `ec2:MetadataHttpPutResponseHopLimit`
   + `ec2:MetadataHttpEndpoint`

   Ces touches de condition contrôlent l'utilisation du [RunInstances[ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html) APIs et du correspondant CLIs. 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](ExamplePolicies_EC2.md#iam-example-instance-metadata).

# Limiter l’accès au service des métadonnées d’instance
<a name="instance-metadata-limiting-access"></a>

Vous pouvez envisager d’utiliser des règles de pare-feu locales pour désactiver l’accès au service des métadonnées d’instance à partir de certains ou de tous les processus.

Pour les [Instances basées sur Nitro](instance-types.md#instance-hypervisor-type), IMDS peut être accessible à partir de votre propre réseau lorsqu’un appareil réseau au sein de votre VPC, telle qu’un routeur virtuel, transfère des paquets à l’adresse IMDS et que la valeur par défaut [source/destination check](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck) (vérification origine/destination) est désactivée sur l’instance. Pour empêcher une source extérieure à votre VPC d'atteindre l'IMDS, nous vous recommandons de modifier la configuration de l'appliance réseau afin de supprimer les paquets contenant l' IPv4adresse de destination de l'IMDS `169.254.169.254` et, si vous avez activé le point de IPv6 terminaison, l' IPv6 adresse de l'IMDS. `[fd00:ec2::254]`

## Limiter l’accès à l’IMDS pour les instances Linux
<a name="instance-metadata-limiting-access-linux"></a>

**Utilisation d’éléments iptables pour limiter l’accès**

L’exemple suivant utilise des éléments Linux iptables et le module `owner` associé pour empêcher le serveur web Apache (en fonction de son ID utilisateur d’installation par défaut `apache`) d’accéder à l’adresse 169.254.169.254. Il utilise une *règle de refus* pour rejeter toutes les demandes de métadonnées d'instance (qu'elles IMDSv1 proviennent ou IMDSv2) de tout processus exécuté sous le nom de cet utilisateur.

```
$ sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner --uid-owner apache --jump REJECT
```

Vous pouvez aussi envisager d’autoriser uniquement l’accès à des utilisateurs ou des groupes particuliers à l’aide de *règles d’autorisation (allow)*. Les règles allow peuvent être plus faciles à gérer du point de vue de la sécurité, car elles nécessitent que vous déterminiez quels sont les logiciels ayant besoin d’accéder aux métadonnées d’instance. Si vous utilisez des *règles allow*, vous risquez moins d’autoriser accidentellement un logiciel à accéder au service des métadonnées en cas de modification ultérieure des logiciels ou de la configuration sur une instance. Vous pouvez également combiner une utilisation de groupes avec des règles allow, afin de pouvoir ajouter et supprimer des utilisateurs dans un groupe autorisé sans avoir à modifier la règle du pare-feu.

L’exemple suivant empêche tous les processus d’accéder à l’IMDS, à l’exception des processus qui s’exécutent dans le compte utilisateur `trustworthy-user`.

```
$ sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner ! --uid-owner trustworthy-user --jump REJECT
```

**Note**  
Pour utiliser des règles de pare-feu locales, vous devez adapter les commandes de l’exemple précédent à vos besoins. 
Par défaut, les règles iptables ne sont pas persistantes après un redémarrage du système. Elles peuvent être rendues persistantes en utilisant des fonctionnalités du système d’exploitation qui ne sont pas décrites ici.
Le module iptables `owner` correspond uniquement à l’appartenance au groupe si le groupe est le groupe principal d’un utilisateur local donné. Les autres groupes n’ont pas de correspondance.

**Utilisation de PF ou de IPFW pour limiter l’accès**

Si vous utilisez FreeBSD ou OpenBSD, vous pouvez également envisager d’utiliser PF ou IPFW. Les exemples suivants permettent de limiter l’accès à l’IMDS à l’utilisateur root uniquement.

**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
```

**Note**  
L’ordre des commandes PF et IPFW a de l’importance. PF prend par défaut la valeur de la dernière règle correspondante et IPFW prend par défaut la valeur de la première règle correspondante.

## Limiter l’accès à l’IMDS pour les instances Windows
<a name="instance-metadata-limiting-access-windows"></a>

**Utilisation du pare-feu Windows pour limiter l’accès**

L' PowerShell exemple suivant utilise le pare-feu Windows intégré pour empêcher le serveur Web Internet Information Server (sur la base de son ID utilisateur d'installation par défaut`NT AUTHORITY\IUSR`) d'accéder au 169.254.169.254. Il utilise une *règle de refus* pour rejeter toutes les demandes de métadonnées d'instance (qu'elles IMDSv1 proviennent ouIMDSv2) de tout processus exécuté sous le nom de cet utilisateur.

```
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
```

Vous pouvez aussi envisager d’autoriser uniquement l’accès à des utilisateurs ou des groupes particuliers à l’aide de *règles d’autorisation (allow)*. Les règles allow peuvent être plus faciles à gérer du point de vue de la sécurité, car elles nécessitent que vous déterminiez quels sont les logiciels ayant besoin d’accéder aux métadonnées d’instance. Si vous utilisez des *règles allow*, vous risquez moins d’autoriser accidentellement un logiciel à accéder au service des métadonnées en cas de modification ultérieure des logiciels ou de la configuration sur une instance. Vous pouvez également combiner une utilisation de groupes avec des règles allow, afin de pouvoir ajouter et supprimer des utilisateurs dans un groupe autorisé sans avoir à modifier la règle du pare-feu.

L’exemple suivant empêche tous les processus s’exécutant en tant que groupe OS spécifié dans la variable `blockPrincipal` (dans cet exemple, le groupe Windows `Everyone`) d’accéder aux métadonnées d’instance, à l’exception des processus spécifiés dans `exceptionPrincipal` (dans cet exemple, un groupe appelé `trustworthy-users`). Vous devez spécifier à la fois des principaux d’autorisation (allow) et de refus (deny), car le pare-feu Windows, contrairement à la règle `! --uid-owner trustworthy-user` dans les éléments Linux iptables, ne fournit pas de mécanisme de raccourci permettant d’autoriser uniquement un principal particulier (utilisateur ou groupe) en refusant l’accès à tous les autres.

```
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
```

**Note**  
Pour utiliser des règles de pare-feu locales, vous devez adapter les commandes de l’exemple précédent à vos besoins. 

**Utilisation de règles netsh pour limiter l’accès**

Vous pouvez envisager de bloquer tous les logiciels à l’aide de règles `netsh`, mais ces règles sont beaucoup moins souples.

```
C:\> netsh advfirewall firewall add rule name="Block metadata service altogether" dir=out protocol=TCP remoteip=169.254.169.254 action=block
```

**Note**  
Pour utiliser des règles de pare-feu locales, vous devez adapter les commandes de l’exemple précédent à vos besoins. 
`netsh`Les règles doivent être définies à partir d’une invite de commande élevée et ne peuvent pas être définies sur des principaux deny ou allow particuliers.