# Uso de los metadatos de la instancia para administrar su instancia de EC2
<a name="ec2-instance-metadata"></a>

Los *metadatos de instancia* son datos sobre una instancia que se pueden utilizar para configurar o administrar la instancia en ejecución. Los metadatos de instancias incluyen lo siguiente:

**Propiedades de metadatos de la instancia**  
Las propiedades de los metadatos de instancia se dividen en [categorías](#instancedata-data-categories), como, por ejemplo, nombre de host, eventos y grupos de seguridad.

**Datos dinámicos**  
Los datos dinámicos son metadatos que se generan cuando se inicia la instancia, como, por ejemplo, el documento de identidad de la instancia. Para obtener más información, consulte [Categorías de datos dinámicos](#dynamic-data-categories).

**Datos de usuario**  
También puede utilizar metadatos de instancia para obtener acceso a los *datos de usuario* que especificó al inicializar la instancia. Por ejemplo, se pueden especificar parámetros para configurar la instancia o incluir un script sencillo. También puede crear AMI genéricas y usar los datos de usuario para modificar los archivos de configuración proporcionados durante la inicialización. Por ejemplo, si ejecuta servidores web para varios negocios pequeños, todos pueden utilizar la misma AMI genérica y recuperar el contenido de un bucket de Amazon S3 que especifique en los datos de usuario en la inicialización. Para añadir un nuevo cliente en cualquier momento, cree un bucket para el cliente, añada su contenido y lance la AMI con el nombre de bucket único proporcionado a su código en los datos de usuario. Si inicia varias instancias con la misma llamada a `RunInstances`, los datos de usuario se encuentran disponibles para todas las instancias de esa reserva. Cada instancia que forme parte de la misma reserva tiene un número `ami-launch-index` único para que pueda escribir código que controla lo que hacen las instancias. Por ejemplo, el primer host se puede elegir a sí mismo como el nodo original de un clúster. Para ver un ejemplo de inicialización de AMI detallado, consulte [Identificación de las instancias inicializadas en una sola solicitud](AMI-launch-index-examples.md).

**importante**  
Aunque solo se puede obtener acceso a los metadatos de instancia y a los datos de usuario desde la propia instancia, los datos no están protegidos con métodos criptográficos ni de autenticación. Cualquier persona con acceso directo a la instancia, y prácticamente cualquier software que se ejecute en la instancia, puede ver sus metadatos. Por ello, no debería almacenar información confidencial, como contraseñas y claves de cifrado de duración prolongada, como datos de usuario.

**Topics**
+ [

## Categorías de metadatos de instancia
](#instancedata-data-categories)
+ [

## Categorías de datos dinámicos
](#dynamic-data-categories)
+ [

# Acceso a los metadatos de instancia de una instancia de EC2
](instancedata-data-retrieval.md)
+ [

# Configuración de las opciones del servicio de metadatos de instancias
](configuring-instance-metadata-options.md)
+ [

# Ejecución de comandos al lanzar una instancia de EC2 con la entrada de datos de usuario
](user-data.md)
+ [

# Identificación de las instancias inicializadas en una sola solicitud
](AMI-launch-index-examples.md)

## Categorías de metadatos de instancia
<a name="instancedata-data-categories"></a>

Las propiedades de los metadatos de instancia se dividen en categorías. Para recuperar las propiedades de los metadatos de instancia, debe especificar la categoría en la solicitud, y los metadatos se devolverán en la respuesta.

Cuando se publican nuevas categorías, se crea una nueva compilación de metadatos de instancia con un nuevo número de versión. En la siguiente tabla, la columna **Version when category was released** (Versión cuando se publicó la categoría) especifica la versión de la compilación correspondiente al momento cuando se publicó una categoría de metadatos de instancia. Para no tener que actualizar el código cada vez que Amazon EC2 publique una nueva compilación de metadatos de instancia, utilice `latest` en lugar del número de versión en las solicitudes de metadatos. Para obtener más información, consulte [Obtener las versiones disponibles de los metadatos de instancia](configuring-instance-metadata-service.md#instance-metadata-ex-1).

Cuando Amazon EC2 publica una nueva categoría de metadatos de instancia, es posible que los metadatos de instancia de la nueva categoría no estén disponibles para las instancias existentes. Con las [instancias basadas en Nitro](instance-types.md#instance-hypervisor-type), puede recuperar los metadatos de la instancia únicamente para aquellas categorías que estaban disponibles en el momento de la inicialización. Para instancias con el hipervisor Xen, se puede [detener y luego iniciar](Stop_Start.md) la instancia para actualizar las categorías que están disponibles para ella.

En la siguiente tabla se enumeran las categorías de los metadatos de instancia. Algunos de los nombres de categoría son marcadores de posición para datos que son exclusivos de su instancia. Por ejemplo, *mac* representa la dirección MAC de la interfaz de red. Debe sustituir los marcadores de posición por valores reales en el momento de recuperar los metadatos de la instancia.


| Categoría | Descripción | Versión cuando se publicó la categoría | 
| --- | --- | --- | 
| ami-id  | El ID de la AMI utilizada para iniciar la instancia. | 1.0 | 
| ami-launch-index  | Si inicia varias instancias con la misma llamada a RunInstances, este valor indica el orden de inicialización de cada instancia. El valor de la primera instancia iniciada es 0. Si inicia instancias con una flota de EC2 o Auto Scaling, este valor siempre es 0. | 1.0 | 
| ami-manifest-path  | La ruta al archivo de manifiesto de AMI en Amazon S3. Si ha utilizado una AMI respaldada por Amazon EBS para iniciar la instancia, el resultado devuelto es unknown. | 1.0 | 
| ancestor-ami-ids  | Los ID de AMI de cualquier instancia que se haya vuelto a agrupar para crear esta AMI. Este valor solo existirá si el archivo de manifiesto de AMI contenía una clave ancestor-amis. | 10-10-2007 | 
| autoscaling/target-lifecycle-state |  Valor que muestra el estado de ciclo de vida de Auto Scaling de destino al que va a pasar una instancia de Auto Scaling. Presente cuando la instancia pasa a uno de los estados de ciclo de vida de destino después del 10 de marzo de 2022. Valores posibles: `Detached` \$1 `InService` \$1 `Standby` \$1 `Terminated` \$1 `Warmed:Hibernated` \$1 `Warmed:Running` \$1 `Warmed:Stopped` \$1 `Warmed:Terminated`. Consulte [Recuperar el estado de ciclo de vida de destino a través de los metadatos de instancia](https://docs.aws.amazon.com/autoscaling/ec2/userguide/retrieving-target-lifecycle-state-through-imds.html) en la *Guía del usuario de Amazon EC2 Auto Scaling*.   | 15/07/2021 | 
| block-device-mapping/ami | El dispositivo virtual que contiene el sistema de archivos raíz o de arranque. | 15-12-2007 | 
| block-device-mapping/ebsN  | Los dispositivos virtuales asociados a cualquier volumen de Amazon EBS. Los volúmenes de Amazon EBS solo están disponibles en los metadatos si se encontraban presentes en el momento de la inicialización o la última vez que se inició la instancia. La N indica el índice del volumen de Amazon EBS (como ebs1 o ebs2). | 15-12-2007 | 
| block-device-mapping/ephemeralN  | Los dispositivos virtuales de los volúmenes de almacenes de instancias que no son de NVMe. La N indica el índice de cada volumen. Es posible que el número de volúmenes del almacén de instancias en la asignación del dispositivo de bloque no coincida con el número real de volúmenes del almacén de instancias para la instancia. El tipo de instancia determina el número de volúmenes del almacén de instancias que están disponibles para una instancia. Si el número de volúmenes de almacén de instancias en una asignación de dispositivo de bloque excede el número disponible para una instancia, los volúmenes de almacén de instancias adicionales se ignoran. | 15-12-2007 | 
| block-device-mapping/root  | Son los dispositivos o las particiones virtuales asociados a los dispositivos raíz o las particiones en el dispositivo virtual, donde el sistema de archivos raíz (/ o C:) se asocia a la instancia concreta. | 15-12-2007 | 
| block-device-mapping/swap  | Los dispositivos virtuales asociados a swap. No siempre están presentes. | 15-12-2007 | 
| events/maintenance/history | Si hay eventos de mantenimiento completados o cancelados para la instancia, contiene una cadena JSON con información sobre los eventos. | 17/08/2018 | 
| events/maintenance/scheduled | Si hay eventos de mantenimiento activos para la instancia, contiene una cadena JSON con información sobre los eventos. Para obtener más información, consulte [Ver los eventos programados que afectan a sus instancias de Amazon EC2](viewing_scheduled_events.md). | 17/08/2018 | 
| events/recommendations/rebalance | Tiempo aproximado, en UTC, en el que se emite la notificación de recomendación de reequilibrio de la instancia de EC2 para la instancia. A continuación, se muestra un ejemplo de los metadatos de esta categoría: \$1"noticeTime": "2020-11-05T08:22:00Z"\$1. Esta categoría sólo está disponible luego de emitir la notificación. Para obtener más información, consulte [Recomendación de reequilibrio de instancias de EC2](rebalance-recommendations.md). | 27/10/2020 | 
| hostname | Si la instancia de EC2 utiliza la asignación de nombre basada en IP (IPBN), este es el nombre de host de DNS IPv4 privado de la instancia. Si la instancia de EC2 utiliza asignación de nombre basada en recursos (RBN), este es el RBN. En los casos en los que existen varias interfaces de red, esto se refiere al dispositivo eth0 (el dispositivo cuyo número de dispositivo es 0). Para obtener más información sobre IPBN y RBN, consulte [Nombres de host y dominios de instancias de EC2](ec2-instance-naming.md). | 1.0 | 
|  iam/info  | Si existe un rol de IAM asociado a la instancia, contiene información acerca de la última vez que se actualizó el perfil de instancia, incluida la fecha de LastUpdated de la instancia, InstanceProfileArn e InstanceProfileId. De lo contrario, no está presente. | 12-01-2012 | 
|  iam/security-credentials/role-name  | Si hay un rol de IAM asociado a la instancia, role-name es el nombre del rol y role-name contiene las credenciales de seguridad temporales asociadas al rol (para obtener más información, consulte [Recuperar credenciales de seguridad de los metadatos de la instancia](instance-metadata-security-credentials.md)). De lo contrario, no está presente. | 12-01-2012 | 
| identity-credentials/ec2/info | Información sobre las credenciales en identity-credentials/ec2/security-credentials/ec2-instance. | 23/05/2018 | 
| identity-credentials/ec2/security-credentials/ec2-instance | Credenciales del rol de identidad de instancia que permiten que el software de la instancia se identifique como AWS para admitir características como la conexión de instancias de EC2 y la configuración de administración de host predeterminada de AWS Systems Manager. Estas credenciales no tienen políticas adjuntas, por lo que no tienen permisos de API de AWS adicionales más allá de identificar la instancia en la característica de AWS. Para obtener más información, consulte [Roles de identidad de instancia para instancias de Amazon EC2](iam-roles-for-amazon-ec2.md#ec2-instance-identity-roles). | 23/05/2018 | 
| instance-action | Notifica a la instancia que debe reiniciarse como preparación para la agrupación. Valores válidos: none \$1 shutdown \$1 bundle-pending. | 01-09-2008 | 
| instance-id | El ID de esta instancia. | 1.0 | 
| instance-life-cycle | La opción de compra de esta instancia. Para obtener más información, consulte [Opciones de facturación y compra de Amazon EC2](instance-purchasing-options.md). | 01-10-2019 | 
| instance-type  | El tipo de instancia. Para obtener más información, consulte [Tipos de instancias de Amazon EC2](instance-types.md). | 29-08-2007 | 
| ipv6  | La dirección IPv6 de la instancia. En los casos en los que existen varias interfaces de red, esto se refiere a la interfaz de red del dispositivo eth0 (el dispositivo cuyo número de dispositivo es 0) y la primera IPv6 asignada. Si no existe ninguna dirección IPv6 en la interfaz de red [0], este elemento no está configurado y da como resultado una respuesta HTTP 404. | 2021-01-03 | 
|  kernel-id  | El ID del kernel iniciado con esta instancia, si se aplica. | 01-02-2008 | 
|  local-hostname  | En los casos en los que existen varias interfaces de red, esto se refiere al dispositivo eth0 (el dispositivo cuyo número de dispositivo es 0). Si la instancia de EC2 utiliza la asignación de nombre basada en IP (IPBN), este es el nombre de host de DNS IPv4 privado de la instancia. Si la instancia de EC2 utiliza asignación de nombre basada en recursos (RBN), este es el RBN. Para obtener más información acerca de la nomenclatura de IPBN, RBN e instancias de EC2, consulte [Nombres de host y dominios de instancias de EC2](ec2-instance-naming.md). | 19-01-2007 | 
|  local-ipv4  | La dirección IPv4 privada de la instancia. En los casos en los que existen varias interfaces de red, esto se refiere al dispositivo eth0 (el dispositivo cuyo número de dispositivo es 0). Si se trata de una instancia de solo IPv6, este elemento no está configurado y da como resultado una respuesta HTTP 404. | 1.0 | 
|  mac  | La dirección de control de acceso de medios (MAC) de la instancia. En los casos en los que existen varias interfaces de red, esto se refiere al dispositivo eth0 (el dispositivo cuyo número de dispositivo es 0). | 01-01-2011 | 
| metrics/vhostmd | Ya no está disponible. | 01/05/2011 | 
|  network/interfaces/macs/mac/device-number  | El número exclusivo de dispositivo asociado a esa interfaz. El número de dispositivo se corresponde con el nombre del dispositivo; por ejemplo, un device-number de 2 es para el dispositivo eth2. Esta categoría se corresponde con los campos DeviceIndex y device-index que utilizan la API de Amazon EC2 y los comandos de EC2 para AWS CLI. | 01-01-2011 | 
|  network/interfaces/macs/mac/interface-id  | El ID de la interfaz de red. | 01-01-2011 | 
|  network/interfaces/macs/mac/ipv4-associations/public-ip  | Las direcciones IPv4 privadas asociadas a cada dirección IP pública y que están asignadas a esa interfaz. | 01-01-2011 | 
| network/interfaces/macs/mac/ipv6s | Las direcciones IPv6 asignadas a la interfaz. | 30-06-2016 | 
| network/interfaces/macs/mac/ipv6-prefix | Los prefijos de IPv6 asignados a la interfaz de red. |  | 
|  network/interfaces/macs/mac/local-hostname  |  El nombre de host DNS IPv4 privado de la instancia. En los casos en los que existen varias interfaces de red, esto se refiere al dispositivo eth0 (el dispositivo cuyo número de dispositivo es 0). Si se trata de una instancia de solo IPv6, este es el nombre basado en recursos. Para obtener más información sobre IPBN y RBN, consulte [Nombres de host y dominios de instancias de EC2](ec2-instance-naming.md).  | 19-01-2007 | 
|  network/interfaces/macs/mac/local-ipv4s  | Las direcciones IPv4 privadas asociadas a la interfaz. Si se trata de una interfaz de red de solo IPv6, este elemento no está configurado y da como resultado una respuesta HTTP 404. | 01-01-2011 | 
|  network/interfaces/macs/mac/mac  | La dirección MAC de la instancia. | 01-01-2011 | 
|  network/interfaces/macs/mac/network-card  | El índice de la tarjeta de red. Algunos tipos de instancia admiten varias tarjetas de red. | 2020-11-01 | 
| network/interfaces/macs/mac/owner-id  | El ID del propietario de la interfaz de red. En entornos con varias interfaces, un tercero puede adjuntar una interfaz, como Elastic Load Balancing. El tráfico en una interfaz se factura siempre al propietario de la interfaz. | 01-01-2011 | 
|  network/interfaces/macs/mac/public-hostname  | El DNS (IPv4) público de la interfaz. Esta categoría solo se devuelve si el atributo enableDnsHostnames está establecido en true. Para obtener más información, consulte [Atributos de DNS para su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) en la Guía del usuario de Amazon VPC. Si la instancia solo tiene una dirección IPv6 pública y ninguna dirección IPv4 pública, este elemento no está configurado y da como resultado una respuesta HTTP 404. |  01-01-2011 | 
|  network/interfaces/macs/mac/public-ipv4s  | Direcciones IP públicas o direcciones IP elásticas asociadas a la interfaz. Puede haber varias direcciones IPv4 en una instancia.  | 01-01-2011 | 
| network/interfaces/macs/mac/security-groups  | Grupos de seguridad a los que pertenece la interfaz de red. | 01-01-2011 | 
|  network/interfaces/macs/mac/security-group-ids  | Los ID de los grupos de seguridad a los que pertenece la interfaz de red. | 01-01-2011 | 
|  network/interfaces/macs/mac/subnet-id  | El ID de la subred en la que reside la interfaz. | 01-01-2011 | 
|  network/interfaces/macs/mac/subnet-ipv4-cidr-block  | El bloque de CIDR IPv4 de la subred en la que reside la interfaz. | 01-01-2011 | 
| network/interfaces/macs/mac/subnet-ipv6-cidr-blocks  | El bloque de CIDR IPv6 de la subred en la que reside la interfaz. | 30-06-2016  | 
|  network/interfaces/macs/mac/vpc-id  | El ID de la VPC en la que reside la interfaz. | 01-01-2011 | 
| network/interfaces/macs/mac/vpc-ipv4-cidr-block | El bloque de CIDR IPv4 principal de la VPC. | 01-01-2011 | 
| network/interfaces/macs/mac/vpc-ipv4-cidr-blocks | bloques de CIDR IPv4 secundarios para la VPC. | 30-06-2016  | 
| network/interfaces/macs/mac/vpc-ipv6-cidr-blocks | El bloque de CIDR IPv6 de la VPC en la que reside la interfaz. | 30-06-2016  | 
|  placement/availability-zone | La zona de disponibilidad en la que se ha iniciado la instancia. | 01-02-2008 | 
|  placement/availability-zone-id | El ID de zona de disponibilidad estática en el que se inicia la instancia. El ID de zona de disponibilidad es coherente en todas las cuentas. Sin embargo, puede ser diferente de la zona de disponibilidad, que puede variar según la cuenta. | 01-10-2019 | 
|  placement/group-name  | El nombre del grupo de ubicación en el que se inicia la instancia. | 24/08/2020 | 
|  placement/host-id  | El ID del host en el que se inicia la instancia. Aplicable solo a hosts dedicados. | 24/08/2020 | 
|  placement/partition-number  | El número de la partición en la que se inicia la instancia. | 24/08/2020 | 
|  placement/region  | La región de AWS en la que se inicia la instancia. | 24/08/2020 | 
|  product-codes  | Códigos de producto de AWS Marketplace asociados a la instancia, si existen.  | 01-03-2007 | 
|  public-hostname  | El DNS público de la instancia (IPv4). Esta categoría solo se devuelve si el atributo enableDnsHostnames está establecido en true. Para obtener más información, consulte [Atributos de DNS para su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) en la Guía del usuario de Amazon VPC. Si la instancia solo tiene una dirección IPv6 pública y ninguna dirección IPv4 pública, este elemento no está configurado y da como resultado una respuesta HTTP 404. | 19-01-2007 | 
|  public-ipv4  | La dirección IPv4 pública. Si se asocia una dirección IP elástica a la instancia, el valor devuelto es dicha dirección. | 19-01-2007 | 
|  public-keys/0/openssh-key  | Clave pública. Solo se encuentra disponible si se facilita en el momento de la inicialización de la instancia. | 1.0 | 
|  ramdisk-id  | El ID del disco RAM especificado en el momento de la inicialización, si se aplica. | 10-10-2007 | 
|  reservation-id  | El ID de la reserva. | 1.0 | 
|  security-groups  |  Los nombres de los grupos de seguridad aplicados a la instancia. Tras la inicialización, puede cambiar los grupos de seguridad de las instancias. Dichos cambios se reflejan aquí y en network/interfaces/macs/**mac**/security-groups.  | 1.0 | 
|  services/domain  |  Es el dominio para los recursos de AWS de la región.  | 25-02-2014 | 
|  services/partition  |  Partición en la que se encuentra el recurso. Para las regiones estándar de AWS, la partición es `aws`. Si tiene recursos en otras particiones, la partición es `aws-partitionname`. Por ejemplo, la partición de los recursos de la región China (Pekín) es `aws-cn`.  | 20-10-2015 | 
|  spot/instance-action  |  La acción (hibernar, detener o finalizar) y la hora aproximada, en UTC, a la que se producirá la acción. Este elemento está presente solo si se ha marcado la instancia de spot para hibernar, detener o finalizar. Para obtener más información, consulte [instance-action](spot-instance-termination-notices.md#instance-action-metadata).  | 15/11/2016 | 
|  spot/termination-time  |  La hora aproximada, en UTC, a la que el sistema operativo de la instancia de spot recibirá la señal de apagado. Este elemento está presente y contiene un valor temporal (por ejemplo, 2015-01-05T18:02:00Z) solo si la instancia de spot se ha marcado para que Amazon EC2 la finalice. El elemento termination-time no se establece en un horario si usted mismo ha finalizado la instancia de spot. Para obtener más información, consulte [termination-time](spot-instance-termination-notices.md#termination-time-metadata).  | 05-11-2014 | 
| system | El tipo de virtualización subyacente (hipervisor) de la instancia. | 24/09/2022 | 
| tags/instance | Las etiquetas de instancia asociadas a la instancia. Solo disponible si permite el acceso explícito a etiquetas en metadatos de instancia. Para obtener más información, consulte [Habilitación del acceso a etiquetas en metadatos de instancia](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS). | 23/03/2023 | 

## Categorías de datos dinámicos
<a name="dynamic-data-categories"></a>

En la siguiente tabla se enumeran las categorías de los datos dinámicos.


| Categoría | Descripción | Versión cuando se publicó la categoría | 
| --- | --- | --- | 
| fws/instance-monitoring  | Valor que muestra si el cliente ha habilitado la monitorización detallada de un minuto en CloudWatch. Valores válidos: enabled \$1 disabled | 04-04-2009 | 
| instance-identity/document  | JSON que contiene atributos de instancia, como ID de instancia, dirección IP privada, etc. Consulte [Documentos de identidad de la instancia para las instancias de Amazon EC2](instance-identity-documents.md).  | 04-04-2009 | 
| instance-identity/pkcs7  | Se utiliza para verificar la autenticidad del documento y el contenido en comparación con la firma. Consulte [Documentos de identidad de la instancia para las instancias de Amazon EC2](instance-identity-documents.md).  | 04-04-2009 | 
| instance-identity/signature  | Otras partes pueden utilizar los datos para verificar su origen y autenticidad. Consulte [Documentos de identidad de la instancia para las instancias de Amazon EC2](instance-identity-documents.md).  | 04-04-2009 | 

# Acceso a los metadatos de instancia de una instancia de EC2
<a name="instancedata-data-retrieval"></a>

Puede acceder a los metadatos de la instancia de EC2 desde la propia instancia o desde la consola de EC2, la API, los SDK o la AWS CLI. Para obtener la configuración de metadatos de la instancia actual de una instancia desde la consola o la línea de comandos, consulte [Opciones de metadatos de instancia de consulta para instancias existentes](#query-IMDS-existing-instances).

También puede modificar los datos de usuario de las instancias con un volumen raíz de EBS. La instancia debe estar detenida. Para obtener instrucciones sobre la consola, consulte [Actualización de los datos de usuario de la instancia](user-data.md#user-data-modify). Para ver un ejemplo de Linux en el que se usa la AWS CLI, consulte [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html). Para ver un ejemplo de Windows en el que se utiliza Tools for Windows PowerShell, consulte [Datos de usuario y las Tools for Windows PowerShell](user-data.md#user-data-powershell).

**nota**  
No se le cobrará por las solicitudes HTTP utilizadas para recuperar metadatos de instancia y datos de usuario.

## Consideraciones sobre el acceso a los metadatos de instancia
<a name="imds-considerations"></a>

Para evitar problemas con la recuperación de metadatos de instancia, tenga en cuenta lo siguiente.

**Fallos en el lanzamiento de la instancia debido a la aplicación de IMDSv2 (`HttpTokensEnforced=enabled`)**  
Antes de habilitar la aplicación de IMDSv2, necesita que todo el software de la instancia sea compatible con IMDSv2. Después, puede cambiar el valor predeterminado para deshabilitar IMDSv1 (`httpTokens=required`), después de lo cual podrá habilitar la aplicación. Para obtener más información, [Transición al uso de Servicio de metadatos de instancia, versión 2](instance-metadata-transition-to-version-2.md).

**Formato de comando**  
El formato del comando es diferente, en función de si utiliza la versión 1 del servicio de metadatos de instancia (IMDSv1) o la versión 2 del servicio de metadatos de instancia (IMDSv2). De forma predeterminada, puede usar ambos ambas versiones del servicio de metadatos de instancias. Para exigir el uso de IMDSv2, consulte [Uso del servicio de metadatos de instancias para acceder a metadatos de instancia](configuring-instance-metadata-service.md).

**Si se requiere IMDSv2, IMDSv1 no funciona.**  
Si utiliza IMDSv1 y no recibe respuesta, es probable que necesite IMDSv2. Para comprobar si IMDSv2 es obligatorio, seleccione la instancia para ver los detalles. El valor **IMDSv2** indica si es **obligatorio** (se debe usar IMDSv2) u **Opcional** (se puede usar IMDSv2 o IMDSv1). 

**(IMDSv2) Se usa para recuperar el token /latest/api/token**  
La emisión de solicitudes `PUT` a cualquier ruta específica de la versión, como, por ejemplo, `/2021-03-23/api/token`, da lugar a que el servicio de metadatos devuelva errores 403 Forbidden (403 Prohibido). Este es el comportamiento deseado.

**Versión de metadatos**  
Para no tener que actualizar el código cada vez que Amazon EC2 publique una nueva compilación de metadatos de instancia, se recomienda utilizar `latest` en la ruta, no el número de versión.

**Compatibilidad con IPv6**  
Para recuperar los metadatos de la instancia mediante una dirección IPv6, asegúrese de habilitar y utilizar la dirección IPv6 del IMDS `[fd00:ec2::254]` en lugar de la dirección IPv4 `169.254.169.254`. Debe ser una [instancia basada en Nitro](instance-types.md#instance-hypervisor-type) lanzada en una [subred que admita IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range).

**(Windows) Creación de las AMI personalizadas con Sysprep.**  
Para asegurarse de que el IMDS funcione cuando inicie una instancia desde una AMI de Windows personalizada, la AMI debe ser una imagen estandarizada creada con Windows Sysprep. De lo contrario, IMDS no funcionará. Para obtener más información, consulte [Creación de una AMI de Amazon EC2 con Windows Sysprep](ami-create-win-sysprep.md).

**En un entorno de contenedores, considere reconfigurar o aumentar el límite de saltos a 2.**  
Los AWS SDK utilizan llamadas a IMDSv2 de forma predeterminada. Si la llamada IMDSv2 no recibe respuesta, algunos SDK de AWS reintentan la llamada y, si aún no tienen éxito, utilizan IMDSv1. Esto puede generar un retraso, especialmente en un entorno de contenedor. Para aquellos SDK de AWS que *requieren* IMDSv2, si el límite de saltos es 1 en un entorno de contenedores, la llamada podría no recibir respuesta en absoluto, ya que ir al contenedor se considera un salto de red adicional.  
Para mitigar estos problemas en un entorno de contenedores, considere cambiar la configuración para pasar los ajustes (como la Región de AWS) directamente al contenedor, o considere aumentar el límite de saltos a 2. Para obtener información sobre el impacto del límite de saltos, consulte [Agregar defensa en profundidad contra firewalls abiertos, proxies inversos y vulnerabilidades SSRF con mejoras en el servicio de metadatos de instancias de EC2](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/). Para obtener más información sobre cómo cambiar el límite de saltos, consulte [Cambio del límite de saltos de respuesta PUT](configuring-IMDS-existing-instances.md#modify-PUT-response-hop-limit).

**Límite de paquetes por segundo (PPS)**  
Hay un límite de 1024 paquetes por segundo (PPS) para los servicios que utilizan direcciones [locales de enlace](using-instance-addressing.md#link-local-addresses). Este límite incluye la suma de las [consultas de DNS de Route 53 Resolver](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#vpc-dns-limits), las solicitudes del [servicio de metadatos de instancias (IMDS)](set-time.md), las solicitudes del protocolo de tiempo de red (NTP) del servicio temporal de Amazon y las solicitudes del [Servicio de licencias de Windows (para instancias basadas en Microsoft Windows)](https://aws.amazon.com/windows/resources/licensing/). 

**Consideraciones adicionales para el acceso a datos de usuario**
+ Los datos de usuario se tratan como datos opacos: lo que especifica es lo que obtiene en la recuperación. La instancia debe interpretar los datos de usuario y actuar sobre ellos.
+ Los datos de usuario deben estar codificados con base64. Según la herramienta o el SDK que utilice, es posible que se realice automáticamente la codificación en base64. Por ejemplo:
  + La consola de Amazon EC2 puede realizar la codificación con base64 por usted, o bien puede aceptar la entrada codificada con base64.
  + [La AWS CLI versión 2](https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html#cliv2-migration-binaryparam) realiza la codificación en base64 de los parámetros binarios de forma predeterminada. La AWS CLI versión 1 realiza la codificación en base64 del parámetro `--user-data` por usted.
  + AWS SDK para Python (Boto3) realiza la codificación en base64 del parámetro `UserData` por usted.
+ Los datos de usuario están limitados a 16 KB, sin formato, antes de cifrarlo en base64. El tamaño de una cadena de longitud *n* tras el cifrado en base64 es ceil(*n*/3)\$14.
+ Los datos de usuario deben descodificarse en base64 al recuperarlos. Los datos se descodifican automáticamente si los recupera con los metadatos de instancia o la consola.
+ Si detiene una instancia, modifica sus datos de usuario y la inicia de nuevo, los datos de usuario actualizados no se ejecutan automáticamente al iniciar la instancia. Con instancias de Windows, puede configurar los ajustes para que los scripts de datos de usuario actualizados se ejecuten una vez al iniciar la instancia, o bien cada vez que esta se inicie o se reinicie.
+ Los datos de usuario son un atributo de la instancia. Si crea una AMI a partir de una instancia, los datos de usuario de la instancia no se incluyen en la AMI.

## Acceso a los metadatos de la instancia desde una instancia de EC2
<a name="instancedata-inside-access"></a>

Puesto que los metadatos de la instancia se encuentran disponibles en la instancia en ejecución, no se necesita utilizar la consola de Amazon EC2 ni la AWS CLI. Esto puede resultar de utilidad al escribir scripts para ejecutarlos desde la instancia. Por ejemplo, puede obtener acceso a la dirección IP local de la instancia desde los metadatos de la instancia para administrar una conexión a una aplicación externa.

Todos los datos siguientes se consideran metadatos de instancia, pero se accede a ellos de diferentes maneras. Seleccione la pestaña que representa el tipo de metadatos de la instancia a los que desea acceder para ver más información.

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

Las propiedades de los metadatos de instancia se dividen en categorías. Para obtener una descripción de cada categoría de metadatos de instancia, consulte [Categorías de metadatos de instancia](ec2-instance-metadata.md#instancedata-data-categories).

Para acceder a las propiedades de metadatos de instancia desde una instancia en ejecución, obtenga los datos de las siguientes URI IPv4 o IPv6. Estas direcciones IP son direcciones de enlace local y solo son válidas desde la instancia. Para obtener más información, consulte [Direcciones de enlace 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 ]

Para recuperar datos dinámicos de una instancia en ejecución, utilice los siguientes URI.

**IPv4**

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

**IPv6**

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

**Ejemplos: acceso con cURL**  
Los ejemplos siguientes usan `cURL` para recuperar categorías de identidad de instancia de alto nivel.

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

**Ejemplos: acceso con PowerShell**  
En los ejemplos siguientes se usa PowerShell para recuperar categorías de identidad de instancia de alto nivel.

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

Para obtener más información sobre datos dinámicos y ejemplos de cómo recuperarlos, consulte [Documentos de identidad de la instancia para las instancias de Amazon EC2](instance-identity-documents.md).

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

Para recuperar datos de usuario de una instancia, utilice los siguientes URI. Para recuperar los datos de usuario mediante la dirección IPv6, debe habilitarla y la instancia debe ser una [instancia basada en Nitro](instance-types.md#instance-hypervisor-type) en una subred que admita IPv6.

**IPv4**

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

**IPv6**

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

Las solicitudes de datos de usuario devuelven los datos tal cual (tipo de contenido `application/octet-stream`). Si la instancia no tiene ningún dato de usuario, la solicitud devuelve `404 - Not Found`.

**Ejemplos: acceso con cURL para recuperar texto separado por comas**  
Los ejemplos siguientes usan `cURL` para recuperar datos de usuario especificados como texto separado por comas.

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

**Ejemplos: acceso con PowerShell para recuperar texto separado por comas**  
En los ejemplos siguientes se usa PowerShell para recuperar datos de usuario que se especificaron como texto separado por comas.

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

**Ejemplos: acceso con cURL para recuperar un script**  
Los ejemplos siguientes usan `cURL` para recuperar datos de usuario que se especificaron como 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
```

**Ejemplos: acceso con PowerShell para recuperar un script**  
En los ejemplos siguientes se usa PowerShell para recuperar datos de usuario que se especificaron como 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>
```

------

## Opciones de metadatos de instancia de consulta para instancias existentes
<a name="query-IMDS-existing-instances"></a>

Puede consultar las opciones de metadatos de instancia para sus instancias existentes.

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

**Para consultar las opciones de metadatos de una instancia existente**

1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. En el panel de navegación, seleccione **Instances (Instancias)**.

1. Seleccione su instancia y compruebe los siguientes campos:
   + **IMDSv2** – El valor es **Obligatorio** u **Opcional**.
   + **Permitir etiquetas en los metadatos de la instancia**: el valor está **Habilitado** o **Deshabilitado**.

1. Con su instancia seleccionada, elija **Acciones**, **Configuración de la instancia** y **Modificar opciones de metadatos de instancia**.

   El cuadro de diálogo muestra si el servicio de metadatos de la instancia está habilitado o deshabilitado para la instancia seleccionada.

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

**Para consultar las opciones de metadatos de una instancia existente**  
Utilice el comando [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 ]

**Para consultar las opciones de metadatos de una instancia existente mediante las herramientas para PowerShell**  
Utilice el cmdlet [Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html).

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

------

## Respuestas y mensajes de error
<a name="instance-metadata-returns"></a>

Todos los metadatos de instancia se devuelven como texto (tipo de contenido HTTP `text/plain`).

La solicitud de un recurso de metadato concreto devuelve el valor correspondiente, o bien un código de error HTTP `404 - Not Found` si no se encuentra disponible el recurso.

La solicitud de un recurso de metadato general (el URI acaba en /) devuelve una lista de recursos disponibles, o bien un código de error HTTP `404 - Not Found` si no existe dicho recurso. Los elementos de la lista aparecen en líneas separadas que acaban con saltos de línea (ASCII 10).

Si una solicitud IMDSv1 no recibe respuesta, es probable que se requiera IMDSv2.

Para las solicitudes realizadas con IMDSv2, se pueden devolver los siguientes códigos de error HTTP:
+ `400 - Missing or Invalid Parameters` – la solicitud `PUT` no es válida.
+ `401 - Unauthorized` – la solicitud `GET` usa un token no válido. La acción recomendada es generar un token nuevo.
+ `403 - Forbidden`: la solicitud no está permitida o IMDS está desactivado.
+ `404 - Not Found`: el recurso no está disponible o no existe tal recurso.
+ `503`: la solicitud no se ha podido completar. Intente realizar de nuevo la solicitud.

Si el IMDS devuelve un error, **curl** imprime el mensaje de error en el resultado y devuelve un código de estado correcto. El mensaje de error se almacena en la variable `TOKEN`, lo que provoca que se produzca un error en los comandos **curl** que utilizan el token. Si llama a **curl** con la opción **-f**, devuelve un código de estado de error en caso de que se produzca un error en el servidor HTTP. Si habilita la gestión de errores, el intérprete de comandos puede atrapar el error y detener el script.

## Limitación de consultas
<a name="instancedata-throttling"></a>

Limitamos las consultas a IMDS por cada instancia y aplicamos límites en el número de conexiones simultáneas desde una instancia a IMDS. 

Si utiliza IMDS para recuperar credenciales de seguridad de AWS, evite consultar credenciales en cada transacción o mientras se ejecuta una gran cantidad de procesos o subprocesos, ya que puede producirse una limitación controlada en las operaciones. En lugar de ello, se recomienda guardar en caché las credenciales hasta que comience a aproximarse su caducidad. Para obtener más información sobre el rol de IAM y las credenciales de seguridad asociadas al rol, consulte [Recuperar credenciales de seguridad de los metadatos de la instancia](instance-metadata-security-credentials.md).

Si experimenta limitaciones controladas al acceder a IMDS, vuelva a realizar la consulta con una estrategia de retroceso exponencial.

# Uso del servicio de metadatos de instancias para acceder a metadatos de instancia
<a name="configuring-instance-metadata-service"></a>

Para acceder a los metadatos de instancia desde una instancia en ejecución puede utilizar uno de los métodos siguientes:
+ Servicio de metadatos de instancia, versión 2 (IMDSv2): un método orientado a la sesión

  Para ver ejemplos, consulte [Ejemplos de IMDSv2](#instance-metadata-retrieval-examples).
+ Servicio de metadatos de instancia, versión 1 (IMDSv1): un método de solicitud y respuesta

  Para ver ejemplos, consulte [Ejemplos de IMDSv1](#instance-metadata-retrieval-examples-imdsv1).

De forma predeterminada, puede usar IMDSv1 o IMDSv2, o ambos.

Puede configurar el servicio de metadatos de instancias (IMDS) en cada instancia para que solo acepte llamadas a IMDSv2, lo que provocará un error en las llamadas a IMDSv1. Para obtener información acerca de cómo configurar la instancia para usar IMDSv2, consulte [Configuración de las opciones del servicio de metadatos de instancias](configuring-instance-metadata-options.md).

Los encabezados `PUT` o `GET` son exclusivos de IMDSv2. Si estas cabeceras están presentes en la solicitud, entonces la solicitud está destinada a IMDSv2. Si no hay encabezados, se supone que la solicitud está destinada a IMDSv1.

Para obtener más información, consulte [Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/) (Agregar defensa en profundidad contra firewalls abiertos, proxies inversos y vulnerabilidades SSRF con mejoras en el servicio de metadatos de instancias de EC2).

**Topics**
+ [

## Funcionamiento de Servicio de metadatos de instancia versión 2
](#instance-metadata-v2-how-it-works)
+ [

## Uso de un AWS SDK compatible
](#use-a-supported-sdk-version-for-imdsv2)
+ [

## Ejemplos de IMDSv2
](#instance-metadata-retrieval-examples)
+ [

## Ejemplos de IMDSv1
](#instance-metadata-retrieval-examples-imdsv1)

## Funcionamiento de Servicio de metadatos de instancia versión 2
<a name="instance-metadata-v2-how-it-works"></a>

IMDSv2 usa las solicitudes orientadas a la sesión. Las solicitudes orientadas a la sesión permiten crear un token de sesión que define la duración de la sesión, que puede ser de mínimo un segundo a un máximo de seis horas. En esa duración, puede utilizar el mismo token de sesión para solicitudes subsiguientes. Cuando la duración llegue a su fin, deberá crear un token de sesión nuevo para utilizarlo en las solicitudes futuras.

**nota**  
En los ejemplos de esta sección, se utiliza la dirección IPv4 del servicio de metadatos de instancia (IMDS): `169.254.169.254`. Si recupera metadatos de instancia para las instancias de EC2 a través de la dirección IPv6, asegúrese de habilitar y utilizar la dirección IPv6 en su lugar: `[fd00:ec2::254]`. La dirección IPv6 de IMDS es compatible con los comandos de IMDSv2. Solo se puede acceder a la dirección IPv6 con [instancias basadas en Nitro](instance-types.md#instance-hypervisor-type) en una [subred compatible con IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) (de doble pila o solo IPv6).

En los siguientes ejemplos se usa un script de intérprete de comandos e IMDSv2 para recuperar los elementos de metadatos de instancias de nivel superior. Cada ejemplo:
+ Crea un token de sesión que dura seis horas (21 600 segundos) con la solicitud `PUT`
+ Almacena el encabezado del token de sesión en una variable denominada `TOKEN` (instancias de Linux) o `token` (instancias de Windows)
+ Solicita los elementos de metadatos de nivel superior con el token

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

Puede ejecutar dos comandos separados o combinarlos.

**Comandos separados**

Primero, genere un token con el siguiente comando.

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

A continuación, utilice el token para generar elementos de metadatos de nivel superior mediante el siguiente comando.

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

**Comandos combinados**

Puede almacenar el token y combinar los comandos. En el siguiente ejemplo se combinan los dos comandos anteriores y se almacena el encabezado del token de sesión en una variable denominada TOKEN.

**nota**  
Si hay un error al crear el token, en lugar de un token válido, se almacena un mensaje de error en la variable y el comando no funcionará.

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

Después de crear un token, puede volverlo a usar hasta que venza. En el siguiente comando de ejemplo, que toma el ID de la AMI utilizada para lanzar la instancia, se vuelve a utilizar el token que se almacena en `$TOKEN` en el ejemplo anterior.

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

### Ejemplo de 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/
```

Después de crear un token, puede volverlo a usar hasta que venza. En el siguiente comando de ejemplo, que toma el ID de la AMI utilizada para lanzar la instancia, se vuelve a utilizar el token que se almacena en `$token` en el ejemplo anterior.

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

Al utilizar IMDSv2 para solicitar metadatos de instancia, la solicitud debe incluir lo siguiente:

1. Use una solicitud `PUT` para iniciar una sesión en el servicio de metadatos de instancia. La solicitud `PUT` devuelve un token que debe incluirse en las solicitudes `GET` subsiguientes del servicio de metadatos de instancia. El token debe acceder a los metadatos con IMDSv2.

1. Incluya el token en todas las solicitudes `GET` en IMDS. Cuando el uso del token se establece en `required`, las solicitudes sin un token válido o con un token que ha vencido reciben un código de error HTTP `401 - Unauthorized`.
   + El token es una clave específica de la instancia. El token no es válido en otras instancias de EC2 y se rechazará si intenta usarlo fuera de la instancia en la que se generó.
   + La solicitud `PUT` debe incluir un encabezado que especifique el tiempo de vida (TTL) del token, en segundos, de un máximo de seis horas (21 600 segundos). El token representa una sesión lógica. El TTL especifica el período de tiempo que es válido el token y, en consecuencia, la duración de la sesión.
   + Cuando un token caduca, para poder seguir accediendo a los metadatos de instancia hay que crear una sesión nueva con otro `PUT`.
   + Puede escoger entre volver a utilizar un token o crear uno nuevo con cada solicitud. Para una cantidad pequeña de solicitudes, puede ser más sencillo generar y usar inmediatamente un token cada vez que necesite acceder a IMDS. Pero para ser más eficientes, puede especificar una duración más larga para el token y volver a usarlo en vez de escribir una solicitud `PUT` cada vez que tenga que solicitar metadatos de instancia. No existe ningún límite práctico en cuanto a la cantidad de tokens simultáneos, cada uno de los cuales representa su propia sesión. Sin embargo, IMDSv2 sigue limitado por la conexión normal de IMDS y la limitación controlada. Para obtener más información, consulte [Limitación de consultas](instancedata-data-retrieval.md#instancedata-throttling).

Los métodos HTTP `GET` y `HEAD` están permitidos en las solicitudes de metadatos de instancia IMDSv2. Las solicitudes `PUT` se rechazan si contienen un encabezado X-Forwarded-For.

De forma predeterminada, la respuesta a las solicitudes `PUT` tiene un límite de saltos de respuesta (tiempo de vida) de `1` en el nivel del protocolo IP. Si necesita un límite de saltos mayor, puede ajustarlo con el comando [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) de AWS CLI. Por ejemplo, puede necesitar un límite de saltos mayor para una compatibilidad con versiones anteriores con servicios de contenedor ejecutándose en la instancia. Para obtener más información, consulte [Configurar las opciones de metadatos para instancias existentes](configuring-IMDS-existing-instances.md).

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

Para usar IMDSv2, las instancias de EC2 deben usar una versión de AWS SDK que admita el uso de IMDSv2. Las últimas versiones de todos los SDK de AWS son compatibles con IMDSv2.

**importante**  
Le recomendamos que se mantenga al día con las versiones del SDK para estar al tanto de las características, las actualizaciones de seguridad y las dependencias subyacentes más recientes. No se recomienda el uso continuo de una versión del SDK no admitida, hágalo según su criterio. Para obtener más información, consulte [Política de mantenimiento de SDK y herramientas de AWS](https://docs.aws.amazon.com/sdkref/latest/guide/maint-policy.html) en la *Guía de referencia de SDK y herramientas de AWS*.

Las siguientes son las versiones mínimas que admiten el uso de 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 para .NET](https://github.com/aws/aws-sdk-net): 3.3.634.1
+ [AWS SDK para C\$1\$1](https://github.com/aws/aws-sdk-cpp): 1.7.229
+ [AWS SDK para Go](https://github.com/aws/aws-sdk-go): 1.25.38
+ [AWS SDK para Go v2](https://github.com/aws/aws-sdk-go-v2) – 0.19.0
+ [AWS SDK para 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 para JavaScript en Node.js](https://github.com/aws/aws-sdk-js) – 2.722.0
+ [AWS SDK para Kotlin](https://github.com/awslabs/aws-sdk-kotlin): 1.1.4
+ [AWS SDK para PHP](https://github.com/aws/aws-sdk-php): 3.147.7
+ [AWS SDK para Python (Botocore)](https://github.com/boto/botocore) – 1.13.25
+ [AWS SDK para Python (Boto3)](https://github.com/boto/boto3): 1.12.6
+ [AWS SDK para Ruby](https://github.com/aws/aws-sdk-ruby): 3.79.0

## Ejemplos de IMDSv2
<a name="instance-metadata-retrieval-examples"></a>

Ejecute los siguientes ejemplos en su instancia de Amazon EC2 para recuperar los metadatos de la instancia para IMDSv2.

En las instancias de Windows, se puede usar Windows PowerShell o instalar cURL o wget. Si se instala una herramienta de terceros en una instancia de Windows, asegúrese de leer detenidamente la documentación asociada, ya que las llamadas y el formato de salida pueden ser distintos a lo que se indica aquí.

**Topics**
+ [

### Obtener las versiones disponibles de los metadatos de instancia
](#instance-metadata-ex-1)
+ [

### Obtener los elementos de metadatos del nivel superior
](#instance-metadata-ex-2)
+ [

### Cómo obtener los valores de los elementos de metadatos
](#instance-metadata-ex-2a)
+ [

### Obtener la lista de claves públicas disponibles
](#instance-metadata-ex-3)
+ [

### Mostrar los formatos en los que se encuentra disponible la clave pública 0
](#instance-metadata-ex-4)
+ [

### Obtener la clave pública 0 (en formato de clave OpenSSH)
](#instance-metadata-ex-5)
+ [

### Obtener el ID de subred de una instancia
](#instance-metadata-ex-6)
+ [

### Obtener las etiquetas de instancia de una instancia
](#instance-metadata-ex-7)

### Obtener las versiones disponibles de los metadatos de instancia
<a name="instance-metadata-ex-1"></a>

Este ejemplo obtiene las versiones disponibles de los metadatos de la instancia. Cada versión hace referencia a una compilación de metadatos de instancia correspondiente al momento en que se publicaron nuevas categorías de metadatos de instancia. No existe una correlación entre las versiones de compilación de metadatos de instancia y las versiones de la API de Amazon EC2. Tiene disponibles las versiones anteriores en caso de que tenga scripts que se basen en la estructura y la información presente en la versión anterior.

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

------

### Obtener los elementos de metadatos del nivel superior
<a name="instance-metadata-ex-2"></a>

Este ejemplo obtiene los elementos de metadatos del nivel superior. Para obtener más información sobre los elementos en la respuesta, consulte [Categorías de metadatos de instancia](ec2-instance-metadata.md#instancedata-data-categories).

Tenga en cuenta que se incluyen las etiquetas en este resultado solo si ha permitido el acceso. Para obtener más información, consulte [Habilitación del acceso a etiquetas en metadatos de instancia](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/
```

------

### Cómo obtener los valores de los elementos de metadatos
<a name="instance-metadata-ex-2a"></a>

En estos ejemplos se obtienen los valores de algunos elementos de metadatos de nivel superior del ejemplo anterior. Estas solicitudes usan el token almacenado creado mediante el comando del ejemplo anterior. El token no debe estar vencido.

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

------

### Obtener la lista de claves públicas disponibles
<a name="instance-metadata-ex-3"></a>

Este ejemplo obtiene la lista de las claves públicas 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
```

------

### Mostrar los formatos en los que se encuentra disponible la clave pública 0
<a name="instance-metadata-ex-4"></a>

Este ejemplo muestra los formatos en los que se encuentra disponible la clave pública 0.

------
#### [ cURL ]

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

------
#### [ PowerShell ]

```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
openssh-key
```

------

### Obtener la clave pública 0 (en formato de clave OpenSSH)
<a name="instance-metadata-ex-5"></a>

Este ejemplo obtiene la clave pública 0 (en formato de clave 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
```

------

### Obtener el ID de subred de una instancia
<a name="instance-metadata-ex-6"></a>

Este ejemplo obtiene el ID de subred de una instancia.

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

------

### Obtener las etiquetas de instancia de una instancia
<a name="instance-metadata-ex-7"></a>

Si el acceso a las etiquetas de la instancia en los metadatos de instancia está encendido, puede obtener las etiquetas para una instancia de los metadatos de instancia. Para obtener más información, consulte [Recuperar etiquetas desde los metadatos de instancia](work-with-tags-in-IMDS.md#retrieve-tags-from-IMDS).

## Ejemplos de IMDSv1
<a name="instance-metadata-retrieval-examples-imdsv1"></a>

Ejecute los siguientes ejemplos en su instancia de Amazon EC2 para recuperar los metadatos de la instancia para IMDSv1.

En las instancias de Windows, se puede usar Windows PowerShell o instalar cURL o wget. Si se instala una herramienta de terceros en una instancia de Windows, asegúrese de leer detenidamente la documentación asociada, ya que las llamadas y el formato de salida pueden ser distintos a lo que se indica aquí.

**Topics**
+ [

### Obtener las versiones disponibles de los metadatos de instancia
](#instance-metadata-ex-1-imdsv1)
+ [

### Obtener los elementos de metadatos del nivel superior
](#instance-metadata-ex-2-imdsv1)
+ [

### Cómo obtener los valores de los elementos de metadatos
](#instance-metadata-ex-2a-imdsv1)
+ [

### Obtener la lista de claves públicas disponibles
](#instance-metadata-ex-3-imdsv1)
+ [

### Mostrar los formatos en los que se encuentra disponible la clave pública 0
](#instance-metadata-ex-4-imdsv1)
+ [

### Obtener la clave pública 0 (en formato de clave OpenSSH)
](#instance-metadata-ex-5-imdsv1)
+ [

### Obtener el ID de subred de una instancia
](#instance-metadata-ex-6-imdsv1)
+ [

### Obtener las etiquetas de instancia de una instancia
](#instance-metadata-ex-7-imdsv1)

### Obtener las versiones disponibles de los metadatos de instancia
<a name="instance-metadata-ex-1-imdsv1"></a>

Este ejemplo obtiene las versiones disponibles de los metadatos de la instancia. Cada versión hace referencia a una compilación de metadatos de instancia correspondiente al momento en que se publicaron nuevas categorías de metadatos de instancia. No existe una correlación entre las versiones de compilación de metadatos de instancia y las versiones de la API de Amazon EC2. Tiene disponibles las versiones anteriores en caso de que tenga scripts que se basen en la estructura y la información presente en la versión anterior.

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

------

### Obtener los elementos de metadatos del nivel superior
<a name="instance-metadata-ex-2-imdsv1"></a>

Este ejemplo obtiene los elementos de metadatos del nivel superior. Para obtener más información sobre los elementos en la respuesta, consulte [Categorías de metadatos de instancia](ec2-instance-metadata.md#instancedata-data-categories).

Tenga en cuenta que se incluyen las etiquetas en este resultado solo si ha permitido el acceso. Para obtener más información, consulte [Habilitación del acceso a etiquetas en metadatos de instancia](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/
```

------

### Cómo obtener los valores de los elementos de metadatos
<a name="instance-metadata-ex-2a-imdsv1"></a>

En estos ejemplos se obtienen los valores de algunos elementos de metadatos de nivel superior del ejemplo anterior.

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

------

### Obtener la lista de claves públicas disponibles
<a name="instance-metadata-ex-3-imdsv1"></a>

Este ejemplo obtiene la lista de las claves públicas 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
```

------

### Mostrar los formatos en los que se encuentra disponible la clave pública 0
<a name="instance-metadata-ex-4-imdsv1"></a>

Este ejemplo muestra los formatos en los que se encuentra disponible la clave pública 0.

------
#### [ cURL ]

```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/0/
openssh-key
```

------
#### [ PowerShell ]

```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
openssh-key
```

------

### Obtener la clave pública 0 (en formato de clave OpenSSH)
<a name="instance-metadata-ex-5-imdsv1"></a>

Este ejemplo obtiene la clave pública 0 (en formato de clave 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
```

------

### Obtener el ID de subred de una instancia
<a name="instance-metadata-ex-6-imdsv1"></a>

Este ejemplo obtiene el ID de subred de una instancia.

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

------

### Obtener las etiquetas de instancia de una instancia
<a name="instance-metadata-ex-7-imdsv1"></a>

Si el acceso a las etiquetas de la instancia en los metadatos de instancia está encendido, puede obtener las etiquetas para una instancia de los metadatos de instancia. Para obtener más información, consulte [Recuperar etiquetas desde los metadatos de instancia](work-with-tags-in-IMDS.md#retrieve-tags-from-IMDS).

# Transición al uso de Servicio de metadatos de instancia, versión 2
<a name="instance-metadata-transition-to-version-2"></a>

Si desea configurar las instancias para que solo acepten las llamadas del servicio de metadatos de instancias versión 2 (IMDSv2), recomendamos que utilice las siguientes herramientas y la ruta de transición.

**Topics**
+ [

## Herramientas para la transición a IMDSv2
](#tools-for-transitioning-to-imdsv2)
+ [

## Ruta recomendada para exigir IMDSv2
](#recommended-path-for-requiring-imdsv2)

## Herramientas para la transición a IMDSv2
<a name="tools-for-transitioning-to-imdsv2"></a>

Las siguientes herramientas permiten identificar, supervisar y administrar la transición del software del IMDSv1 al IMDSv2. Para obtener instrucciones sobre cómo utilizar estas herramientas, consulte [Ruta recomendada para exigir IMDSv2](#recommended-path-for-requiring-imdsv2).

**AWS Software de**  
Las últimas versiones de los SDK AWS CLI y AWS son compatibles con IMDSv2. Para utilizar IMDSv2, actualice las instancias de EC2 para hacer uso de las versiones más recientes. Para conocer las versiones mínimas del AWS SDK compatibles con IMDSv2, consulte [Uso de un AWS SDK compatible](configuring-instance-metadata-service.md#use-a-supported-sdk-version-for-imdsv2).  
Todos los paquetes de software de Amazon Linux 2 y Amazon Linux 2023 son compatibles con IMDSv2. Amazon Linux 2023 deshabilita IMDSv1 de forma predeterminada.

**Analizador de paquetes IMDS**  
El analizador de paquetes IMDS es una herramienta de código abierto que identifica y registra las llamadas de IMDSv1 durante la fase de arranque y las operaciones del tiempo de ejecución de la instancia. Con el análisis de estos registros, puede identificar con precisión el software que realiza las llamadas a IMDSv1 en las instancias y determinar qué se debe actualizar para que solo sea compatible con IMDSv2 en las instancias. Puede ejecutar IMDS Packet Analyzer desde una línea de comandos o instalarlo como un servicio. Para obtener más información, consulte [AWS ImdsPacketAnalyzer](https://github.com/aws/aws-imds-packet-analyzer) en *GitHub*.

**CloudWatch**  
CloudWatch ofrece las dos siguientes métricas para supervisar las instancias:  
`MetadataNoToken`: IMDSv2 utiliza sesiones respaldadas por tokens, mientras que IMDSv1 no. La métrica `MetadataNoToken` realiza un seguimiento del número de llamadas al servicio de metadatos de instancia (IMDS) que están utilizando IMDSv1. Al seguir esta métrica hasta cero, puede determinar si y cuándo se ha actualizado el software para utilizar IMDSv2.  
`MetadataNoTokenRejected`: Tras inhabilitar IMDSv1, puede usar la métrica `MetadataNoTokenRejected` para hacer un seguimiento del número de veces que se intentó y rechazó una llamada de IMDSv1. Al seguir esta métrica, puede determinar si es necesario actualizar el software para utilizar IMDSv2.  
Para cada instancia de EC2, estas métricas se excluyen mutuamente. Cuando IMDSv1 está activado (`httpTokens = optional`), solo emite `MetadataNoToken`. Cuando IMDSv1 está deshabilitado (`httpTokens = required`), solo emite `MetadataNoTokenRejected`. Para saber cuándo usar estas métricas, consulte [Ruta recomendada para exigir IMDSv2](#recommended-path-for-requiring-imdsv2).  
Para obtener más información, consulte [Métricas de la instancia](viewing_metrics_with_cloudwatch.md#ec2-cloudwatch-metrics).

**Lanzamiento de las API**  
**Instancias nuevas:** Utilice la API [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html) para lanzar instancias nuevas que exijan el uso de IMDSv2. Para obtener más información, consulte [Configurar las opciones de metadatos para instancias nuevas](configuring-IMDS-new-instances.md).  
**Instancias existentes:** Utilice la API [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html) para exigir el uso de IMDSv2 en las instancias existentes. Para obtener más información, consulte [Configurar las opciones de metadatos para instancias existentes](configuring-IMDS-existing-instances.md).  
**Instancias nuevas lanzadas por los grupos de escalado automático:** Para requerir el uso de IMDSv2 en todas las instancias nuevas lanzadas por grupos de escalado automático, los cuales pueden utilizar una plantilla de lanzamiento o una configuración de lanzamiento. Al [crear una plantilla de inicialización](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-launch-template.html) o [crear una configuración de inicialización](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/create-launch-configuration.html), debe configurar los parámetros `MetadataOptions` para requerir el uso de IMDSv2. El grupo de escalado automático inicia nuevas instancias con la nueva plantilla de inicialización o la configuración de inicialización, pero las instancias existentes no resultan afectadas.   
**Instancias existentes en un grupo de escalado automático:** Utilice la API [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html) para exigir el uso de IMDSv2 en las instancias existentes o terminar las instancias, y el grupo de escalado automático lanzará nuevas instancias de sustitución con la configuración de las opciones de metadatos de la instancia definida en la plantilla de lanzamiento o en la configuración de lanzamiento.

**AMI de**  
Las AMI configuradas con el parámetro `ImdsSupport` establecido en `v2.0`, por defecto, lanzarán las instancias que exigen IMDSv2. Amazon Linux 2023 está configurado con `ImdsSupport = v2.0`.  
**AMI nuevas:** Utilice el comando CLI [register-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html) para establecer el parámetro `ImdsSupport` en `v2.0` al crear una AMI nueva.  
**AMI existentes:** Utilice el comando CLI [modify-image-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-image-attribute.html) para establecer el parámetro `ImdsSupport` en `v2.0` al modificar una AMI existente.  
Para obtener más información, consulte [Configuración de la AMI](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-ami-configuration).

**Controles a nivel de cuenta**  
Puede establecer valores predeterminados para las opciones de metadatos de instancia a nivel de cuenta. Los valores predeterminados se aplican automáticamente al lanzar una instancia. Para obtener más información, consulte [Ajuste de IMDSv2 como valor predeterminado de la cuenta](configuring-IMDS-new-instances.md#set-imdsv2-account-defaults).  
También puede hacer cumplir el requisito de usar IMDSv2 a nivel de cuenta. Cuando la aplicación de IMDSv2 está habilitada:  
+ **Instancias nuevas:** las instancias configuradas para lanzarse con IMDSv1 activado no se iniciarán
+ **Instancias existentes con IMDSv1 deshabilitado:** se impedirán los intentos de habilitar IMDSv1 en las instancias existentes.
+ **Instancias existentes con IMDSv1 activado:** las instancias existentes con IMDSv1 ya activado no se verán afectadas.
Para obtener más información, consulte [Aplicar IMDSv2 a nivel de cuenta](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level).

**Políticas de IAM y SCP**  
Puede utilizar una política de IAM o una política de control de servicio (SCP) AWS Organizations para controlar a los usuarios de IAM de la siguiente forma:  
+ No se puede iniciar una instancia con la API [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html), a menos que la instancia esté configurada para usar IMDSv2.
+ No se puede modificar una instancia existente mediante la API [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html) para volver a habilitar IMDSv1.
La política de IAM o SCP debe contener las siguientes claves de condición de IAM:  
+ `ec2:MetadataHttpEndpoint`
+ `ec2:MetadataHttpPutResponseHopLimit`
+ `ec2:MetadataHttpTokens`
Si un parámetro en la llamada API o CLI no coincide con el estado especificado en la política que contiene la clave de condición, la llamada API o CLI falla con una respuesta `UnauthorizedOperation`.  
Además, puede elegir una capa de protección adicional para forzar el cambio de IMDSv1 a IMDSv2. En la capa de administración de acceso, en relación con las API que se han llamado con credenciales de rol de EC2, puede usar una clave de condición en políticas de IAM o políticas de control de servicios (SCP) de AWS Organizations. En específico, al usar la clave de condición de política `ec2:RoleDelivery` con un valor `2.0` en las políticas de IAM, las llamadas a la API realizadas con credenciales de rol de EC2 que se han obtenido de IMDSv1 recibirán la respuesta `UnauthorizedOperation`. Se puede conseguir lo mismo de forma más extensa si dicha condición la exige una SCP. De esta manera se logra que las credenciales proporcionadas mediante IMDSv1 no se puedan usar para llamar a las API porque cualquier llamada a la API que no cumpla la condición especificada recibirá un error `UnauthorizedOperation`.  
Para ver ejemplos de políticas de IAM, consulte [Trabajar con metadatos de instancias](ExamplePolicies_EC2.md#iam-example-instance-metadata). Para obtener más información sobre las SCP, consulte [Políticas de control de servicios](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) en la *Guía del usuario de AWS Organizations*.

**Políticas declarativas**  
Utilice las políticas declarativas (una característica de AWS Organizations) para configurar de forma predeterminada la cuenta de IMDS, incluida la aplicación de IMDSv2, en toda la organización. Para ver un ejemplo de política, consulte la pestaña **Metadatos de las instancias** en la sección [Políticas declarativas compatibles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples) de la *Guía del usuario de AWS Organizations*.

## Ruta recomendada para exigir IMDSv2
<a name="recommended-path-for-requiring-imdsv2"></a>

**Topics**
+ [

### Paso 1: Identificar las instancias con IMDSv2=optional y auditar el uso de IMDSv1
](#path-step-1)
+ [

### Paso 2: Actualizar el software a IMDSv2
](#path-step-2)
+ [

### Paso 3: Requerir IMDSv2 en las instancias
](#path-step-3)
+ [

### Paso 4: Establecer IMDSv2=required como predeterminado
](#path-step-4)
+ [

### Paso 5: Aplicar las instancias que requieran IMDSv2
](#path-step-5)

### Paso 1: Identificar las instancias con IMDSv2=optional y auditar el uso de IMDSv1
<a name="path-step-1"></a>

Para evaluar el alcance de la migración a IMDSv2, identifique las instancias que estén configuradas para permitir IMDSv1 o IMDSv2 y audite las llamadas a IMDSv1.

1. **Cómo identificar las instancias que están configuradas para permitir IMDSv1 o IMDSv2:**

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

   1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. En el panel de navegación, seleccione **Instances (Instancias)**.

   1. Para ver solo las instancias configuradas para permitir IMDSv1 o IMDSv2, agregue el filtro **IMDSv2 = optional**.

   1. Como alternativa, para ver si IMDSv2 es **opcional** u **obligatorio** para todas las instancias, abra la ventana de **Preferencias** (icono de engranaje), active **IMDSv2** y seleccione **Confirmar**. Esto agrega la columna **IMDSv2** a la tabla de **Instancias**.

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

   Utilice el comando [describe-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-options.html) y filtre por `metadata-options.http-tokens = optional`, de la siguiente manera:

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

------

1. **Cómo auditar las llamadas de IMDSv1 en cada instancia:**

   Utilice la métrica de CloudWatch `MetadataNoToken`. Esta métrica muestra la cantidad de llamadas de IMDSv1 a IMDS de las instancias. Para obtener más información, consulte [Métricas de instancia](https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics).

1. **Cómo identificar el software de las instancias que realizan llamadas a IMDSv1:**

   Utilice el [analizador de paquetes IMDS](https://github.com/aws/aws-imds-packet-analyzer) de código abierto para identificar y registrar las llamadas a IMDSv1 durante la fase de arranque y las operaciones de tiempo de ejecución de la instancia. Con esta información, puede identificar el software que se va a actualizar para que las instancias estén listas para utilizarse únicamente con IMDSv2. Puede ejecutar IMDS Packet Analyzer desde una línea de comandos o instalarlo como un servicio.

### Paso 2: Actualizar el software a IMDSv2
<a name="path-step-2"></a>

Actualice todos los SDK, las CLI y el software que usen credenciales de rol en sus instancias a las versiones compatibles con IMDSv2. Para obtener más información sobre la actualización de la CLI, consulte [Instalación o actualización a la versión más reciente de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) en la *Guía del usuario de AWS Command Line Interface*.

### Paso 3: Requerir IMDSv2 en las instancias
<a name="path-step-3"></a>

Tras confirmar que no hubo llamadas de IMDSv1 mediante la métrica `MetadataNoToken`, configure las instancias existentes para que requieran IMDSv2. Además, configure todas las instancias nuevas para que requieran IMDSv2. Es decir, deshabilite IMDSv1 en todas las instancias nuevas y existentes.

1. **Cómo configurar las instancias existentes para que requieran IMDSv2:**

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

   1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. En el panel de navegación, seleccione **Instances (Instancias)**.

   1. Seleccione la instancia.

   1. Elija **Acciones**, **Configuración de la instancia** y **Modificar opciones de metadatos de instancia**.

   1. En **IMDSv2**, seleccione **Obligatorio**.

   1. Seleccione **Save**.

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

   Utilice el comando de la CLI [modify-instance-metadata-options](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-options.html) para especificar que solo se debe utilizar IMDSv2. 

------
**nota**  
Modifique esta configuración en las instancias en ejecución. El cambio se aplica de inmediato sin necesidad de reiniciar la instancia.

   Para obtener más información, consulte [Requerir el uso de IMDSv2](configuring-IMDS-existing-instances.md#modify-require-IMDSv2).

1. **Cómo controlar los problemas después de deshabilitar IMDSv1:**

   1. Realice un seguimiento del número de veces que se intentó realizar una llamada de IMDSv1 y se rechazó con la métrica de CloudWatch `MetadataNoTokenRejected`.

   1. Si la métrica `MetadataNoTokenRejected` registra las llamadas de IMDSv1 a una instancia que tiene problemas de software, esto indica que es necesario actualizar el software para poder utilizar IMDSv2.

1. **Cómo configurar las nuevas instancias para que requieran IMDSv2:**

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

   1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. Siga estos pasos para [lanzar una instancia](ec2-launch-instance-wizard.md).

   1. Amplíe **Detalles avanzados** y, en **Versión de metadatos**, seleccione **Solo V2 (se requiere un token)**.

   1. En el panel **Resumen**, revise la configuración de la instancia y, a continuación, elija **Iniciar instancia**.

      Para obtener más información, consulte [Configuración de la instancia en el momento de la inicialización](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-instance-settings).

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

   AWS CLI: use el comando [run-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/run-instances.html) y especifique que solo se requiere IMDSv2.

------

### Paso 4: Establecer IMDSv2=required como predeterminado
<a name="path-step-4"></a>

Estableza IMDSv2=required como configuración predeterminada a nivel de cuenta o de organización. Esto garantiza que todas las instancias recién lanzadas se configuren automáticamente para que requieran IMDSv2.

1. **Cómo establecer el nivel de cuenta predeterminado:**

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

   1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. En el panel de navegación, elija **Panel**.

   1. En la tarjeta **Atributos de cuenta**, en **Configuración**, elija **Protección y seguridad de datos**.

   1. En **Valores predeterminados de IMDS**, seleccione **Administrar**.

   1. En **Servicio de metadatos de instancia**, seleccione **Habilitado**.

   1. En **Versión de metadatos**, elija **Solo V2 (token obligatorio)**.

   1. Elija **Actualizar**.

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

   Utilice el comando de la CLI [modify-instance-metadata-defaults](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-defaults.html) y especifique `--http-tokens required` y `--http-put-response-hop-limit 2`.

------

   Para obtener más información, consulte [Ajuste de IMDSv2 como valor predeterminado de la cuenta](configuring-IMDS-new-instances.md#set-imdsv2-account-defaults).

1. **Como alternativa, establezca los valores predeterminados a nivel de organización mediante una política declarativa:**

   Utilice una política declarativa para establecer como obligatorio el valor predeterminado de la organización para IMDSv2. Para ver un ejemplo de política, consulte la pestaña **Metadatos de las instancias** en la sección [Políticas declarativas compatibles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples) de la *Guía del usuario de AWS Organizations*.

### Paso 5: Aplicar las instancias que requieran IMDSv2
<a name="path-step-5"></a>

Una vez que haya confirmado que ninguna de sus instancias depende de IMDSv1, le recomendamos que aplique IMDSv2 en todas las instancias nuevas.

Utilice una de las opciones siguientes para aplicar IMDSv2:

1. **Aplica IMDSv2 con una propiedad de cuenta**

   Puede aplicar el uso de IMDSv2 a nivel de cuenta para cada Región de AWS. Cuando se aplican, las instancias solo se pueden lanzar si están configuradas para que exijan IMDSv2. Esta aplicación se aplica independientemente de cómo esté configurada la instancia o la AMI. Para obtener más información, consulte [Aplicar IMDSv2 a nivel de cuenta](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level). Para aplicar esta configuración a nivel de organización, defina una política declarativa. Para ver un ejemplo de política, consulte la pestaña **Metadatos de las instancias** en la sección [Políticas declarativas compatibles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples) de la *Guía del usuario de AWS Organizations*.

   Para evitar que se revoque la aplicación, debe utilizar una política de IAM para impedir el acceso a la API [ModifyInstanceMetadataDefaults.](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataDefaults.html) Para obtener más información, consulte [Uso de una política de IAM](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-iam-policy).
**nota**  
Esta configuración no cambia la versión de IMDS de las instancias existentes, pero bloquea la activación de IMDSv1 en las instancias existentes que actualmente tienen inhabilitado IMDSv1.
**aviso**  
Si la aplicación de IMDSv2 está habilitada y `httpTokens` no está establecida en la configuración de la instancia `required` en el momento del lanzamiento, en la configuración de la cuenta o en la configuración de la AMI, el lanzamiento de la instancia fallará. Para obtener información sobre la resolución de problemas, consulte [Se produce un error al lanzar una instancia habilitada para IMDSv1](troubleshooting-launch.md#launching-an-imdsv1-enabled-instance-fails).

1. **Como alternativa, aplique IMDSv2 mediante las siguientes claves de condición de IAM o SCP:**
   + `ec2:MetadataHttpTokens`
   + `ec2:MetadataHttpPutResponseHopLimit`
   + `ec2:MetadataHttpEndpoint`

   Estas claves de condición controlan el uso de las API [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html) y [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html), así como las CLI correspondientes. Si se crea una política y un parámetro en la llamada a la API no coincide con el estado especificado en la política que usa la clave de condición, la llamada a la API o a la CLI devolverá una respuesta de error `UnauthorizedOperation`.

   Para ver ejemplos de políticas de IAM, consulte [Trabajar con metadatos de instancias](ExamplePolicies_EC2.md#iam-example-instance-metadata).

# Limitación del acceso al servicio de metadatos de instancias
<a name="instance-metadata-limiting-access"></a>

Puede considerar la posibilidad de usar reglas de firewall locales para desactivar el acceso de algunos o todos los procesos al servicio de metadatos de instancias (IMDS).

En el caso de las [instancias basadas en Nitro](instance-types.md#instance-hypervisor-type), se puede acceder a IMDS desde su propia red cuando un dispositivo de red de la VPC, como un enrutador virtual, reenvía paquetes a la dirección de IMDS y la [comprobación de origen o destino](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck) predeterminada en la instancia se encuentra deshabilitada. Para evitar que un origen externo a la VPC llegue a IMDS, se recomienda modificar la configuración del dispositivo de red para eliminar los paquetes con la dirección IPv4 de destino de IMDS `169.254.169.254` y, si habilita el punto de conexión IPv6, la dirección IPv6 de IMDS `[fd00:ec2::254]`.

## Limitación del acceso a IMDS para instancias de Linux
<a name="instance-metadata-limiting-access-linux"></a>

**Uso de iptables para limitar el acceso**

En el siguiente ejemplo se usan iptables de Linux y su módulo `owner` para impedir que el webserver Apache (basado en el ID de usuario de instalación predeterminado de `apache`) acceda a 169.254.169.254. Usa una *regla de rechazo* para rechazar todas las solicitudes de metadatos de instancia (IMDSv1 o IMDSv2) de cualquier proceso que se ejecute con ese usuario.

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

O, puede plantearse solo dar acceso a usuarios o grupos determinados, mediante el uso de *reglas de permiso*. Las reglas de permiso pueden ser más sencillas de administrar desde el punto de vista de la seguridad, ya que requieren que tome una decisión acerca del software que necesita acceso a los metadatos de instancia. Si usa *reglas de permiso*, es menos probable que permita al software de forma involuntaria acceder al servicio de metadatos (al que no pretendía dar acceso) si posteriormente cambia el software o la configuración en una instancia. También puede combinar el uso de grupos con reglas de permiso, de manera que pueda añadir y eliminar usuarios de un grupo permitido sin tener que cambiar la regla del firewall.

En el siguiente ejemplo se impide el acceso a IMDS a todos los procesos, excepto a aquellos que se ejecutan en la cuenta de usuario `trustworthy-user`.

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

**nota**  
Para usar reglas de firewall locales, debe adaptar los comandos de ejemplo anteriores para adaptarlos a sus necesidades. 
De forma predeterminada, las reglas iptables no persisten en los reinicios de sistema. Pueden convertirse en persistentes con el uso de funcionalidades del SO, que no se describen aquí.
El módulo `owner` de iptables solo coincide con la pertenencia a grupos si el grupo es el grupo principal de un usuario local determinado. Los otros grupos no coinciden.

**Uso de PF o IPFW para limitar el acceso**

Si usa FreeBSD u OpenBSD, también puede plantearse usar PF o IPFW. En los siguientes ejemplos se limita el acceso a IMDS a únicamente el usuario raíz.

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

**nota**  
El orden de los comandos PF e IPFW importa. El valor predeterminado de PF es la última regla coincidente y el de IPFW es la primera regla coincidente.

## Limitación del acceso a IMDS para instancias de Windows
<a name="instance-metadata-limiting-access-windows"></a>

**Uso del firewall de Windows para limitar el acceso**

El ejemplo de PowerShell utiliza el firewall integrado de Windows para impedir que el webserver Apache (basado en el ID de usuario de instalación predeterminado de `NT AUTHORITY\IUSR`) acceda a 169.254.169.254. Usa una *regla de rechazo* para rechazar todas las solicitudes de metadatos de instancia (IMDSv1 o IMDSv2) de cualquier proceso que se ejecute con ese usuario.

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

O, puede plantearse solo dar acceso a usuarios o grupos determinados, mediante el uso de *reglas de permiso*. Las reglas de permiso pueden ser más sencillas de administrar desde el punto de vista de la seguridad, ya que requieren que tome una decisión acerca del software que necesita acceso a los metadatos de instancia. Si usa *reglas de permiso*, es menos probable que permita al software de forma involuntaria acceder al servicio de metadatos (al que no pretendía dar acceso) si posteriormente cambia el software o la configuración en una instancia. También puede combinar el uso de grupos con reglas de permiso, de manera que pueda añadir y eliminar usuarios de un grupo permitido sin tener que cambiar la regla del firewall.

El siguiente ejemplo impide acceder a los metadatos de instancia a todos los procesos que se ejecutan como grupo de SO especificado en la variable `blockPrincipal` (en este ejemplo, el grupo Windows `Everyone`), excepto para los procesos especificados en `exceptionPrincipal` (en este ejemplo, un grupo denominado `trustworthy-users`). Debe especificar los dos principios de rechazo y de permiso porque el firewall de Windows, a diferencia de la regla `! --uid-owner trustworthy-user` en iptables de Linux, no proporciona un mecanismo abreviado para permitir solo un principal determinado (usuario o grupo) mediante el rechazo de los demás.

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

**nota**  
Para usar reglas de firewall locales, debe adaptar los comandos de ejemplo anteriores para adaptarlos a sus necesidades. 

**Uso de las reglas netsh para limitar el acceso**

Puede plantearse bloquear todo el software con reglas `netsh` pero son menos flexibles.

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

**nota**  
Para usar reglas de firewall locales, debe adaptar los comandos de ejemplo anteriores para adaptarlos a sus necesidades. 
Las reglas `netsh` deben establecerse a partir de un símbolo del sistema elevado y no pueden fijarse para denegar o permitir determinados principales.

# Configuración de las opciones del servicio de metadatos de instancias
<a name="configuring-instance-metadata-options"></a>

El servicio de metadatos de instancias (IMDS) se ejecuta de forma local en todas las instancias de EC2. *Las opciones de metadatos de instancia* hacen referencia a un conjunto de configuraciones que controlan la accesibilidad y el comportamiento del IMDS en una instancia de EC2.

Puede configurar las siguientes opciones de metadatos de instancia en cada instancia.

**Servicio de metadatos de instancias (IMDS)**: `enabled` \$1 `disabled`  
Puede habilitar o deshabilitar el IMDS en una instancia. Si está deshabilitado, ni usted ni ningún código podrá acceder a los metadatos de la instancia.  
El IMDS tiene dos puntos de conexión en una instancia: IPv4 (`169.254.169.254`) e IPv6 (`[fd00:ec2::254]`). Al habilitar el IMDS, el punto de conexión IPv4 se habilita automáticamente. Si desea habilitar el punto de conexión IPv6, tendrá que hacerlo de forma explícita.

**Punto de conexión IPv6 del IMDS**: `enabled` \$1 `disabled`  
Puede habilitar de forma explícita el punto de conexión IPv6 del IMDS en una instancia. Cuando el punto de conexión IPv6 está habilitado, el punto de conexión IPv4 permanece habilitado. El punto de conexión IPv6 solo es compatible con [instancias basadas en Nitro](instance-types.md#instance-hypervisor-type) en [subredes compatibles con IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) (de doble pila o solo IPv6).

**Versión de metadatos**: `IMDSv1 or IMDSv2 (token optional)` \$1 `IMDSv2 only (token required)`  
Al solicitar metadatos de instancia, las llamadas de IMDSv2 solicitan un token. Las llamadas de IMDSv1 no requieren un token. Puede configurar una instancia para que permita las llamadas de IMDSv1 o IMDSv2 (en las que el token es opcional) o para que solo permita las llamadas de IMDSv2 (en las que el token es obligatorio).

**Límite de saltos de respuesta de metadatos**: `1`–`64`  
El límite de saltos es el número de saltos de red que puede realizar la respuesta PUT. Puede establecer el límite de saltos en un mínimo de `1` y un máximo de `64`. En un entorno de contenedores, un límite de `1` saltos puede provocar problemas. Para obtener información sobre cómo mitigar estos problemas, consulte la información sobre entornos de contenedores en [Consideraciones sobre el acceso a los metadatos de instancia](instancedata-data-retrieval.md#imds-considerations).

**Acceso a etiquetas en metadatos de instancia**: `enabled` \$1 `disabled`  
Puede habilitar o deshabilitar el acceso a las etiquetas de la instancia desde los metadatos de instancia. Para obtener más información, consulte [Visualización de etiquetas para las instancias de EC2 mediante los metadatos de la instancia](work-with-tags-in-IMDS.md).

Para ver la configuración actual de una instancia, consulte [Opciones de metadatos de instancia de consulta para instancias existentes](instancedata-data-retrieval.md#query-IMDS-existing-instances).

## Dónde configurar las opciones de metadatos de instancia
<a name="where-to-configure-instance-metadata-options"></a>

Las opciones de metadatos de instancia se pueden configurar en diferentes niveles, de la siguiente manera:
+ **Cuenta**: puede establecer valores predeterminados para las opciones de metadatos de instancia a nivel de cuenta para cada Región de AWS. Cuando se inicia una instancia, las opciones de metadatos de instancia se configuran automáticamente en los valores a nivel de cuenta. Puede cambiar este valor en el momento de la inicialización. Los valores predeterminados a nivel de cuenta no afectan a las instancias existentes.
+ **AMI**: puede establecer el parámetro `imds-support` a `v2.0` cuando registra o modifica una AMI. Cuando se inicia una instancia con esta AMI, la versión de metadatos de instancia se establece automáticamente en IMDSv2 y el límite de saltos se establece en 2.
+ **instancia**: puede cambiar todas las opciones de metadatos de instancia en el momento de la inicialización, al anular la configuración predeterminada. También puede cambiar las opciones de metadatos de instancia después de la inicialización en una instancia en ejecución o detenida. Tenga en cuenta que los cambios pueden restringirse mediante una política de IAM o SCP.

Para obtener más información, consulte [Configurar las opciones de metadatos para instancias nuevas](configuring-IMDS-new-instances.md) y [Configurar las opciones de metadatos para instancias existentes](configuring-IMDS-existing-instances.md).

## Orden de prioridad para las opciones de metadatos de instancia
<a name="instance-metadata-options-order-of-precedence"></a>

El valor de cada opción de metadatos de instancia se determina en el momento de la inicialización de la instancia, siguiendo un orden jerárquico de prioridad. La jerarquía, con la prioridad más alta en la parte superior, es la siguiente:
+ **Prioridad 1, configuración de la instancia en la inicialización**: los valores se pueden especificar en la plantilla de inicialización o en la configuración de la instancia. Todos los valores especificados aquí anulan los valores especificados a nivel de cuenta o en la AMI.
+ **Prioridad 2, configuración de la cuenta:** si no se especifica un valor al iniciar la instancia, lo determina la configuración a nivel de cuenta (que se establece para cada Región de AWS). La configuración a nivel de cuenta incluye un valor para cada opción de metadatos o no indica ninguna preferencia.
+ **Prioridad 3, configuración de la AMI:** si no se especifica un valor al iniciar la instancia o a nivel de cuenta, lo determina la configuración de la AMI. Esto se aplica solo a `HttpTokens` y `HttpPutResponseHopLimit`.

Cada opción de metadatos se evalúa por separado. La instancia se puede ajustar con una combinación de configuración de instancia directa, valores predeterminados a nivel de cuenta y la configuración de la AMI.

Puede cambiar el valor de cualquier opción de metadatos después de la inicialización en una instancia en ejecución o detenida, a menos que los cambios estén restringidos por una política de IAM o SCP.

**nota**  
La configuración de aplicación de IMDSv2 a nivel de cuenta se evalúa después de que el orden de prioridad haya determinado la configuración del IMDS de la instancia. Cuando la aplicación de IMDSv2 está habilitada, fallarán las instancias habilitadas con IMDSv1. Para obtener más información sobre la aplicación, consulte [Aplicar IMDSv2 a nivel de cuenta](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level).

**aviso**  
Si la aplicación de IMDSv2 está habilitada y no se ha establecido `httpTokens` en `required` en la configuración de la instancia en el momento del lanzamiento, en los ajustes de la cuenta o en la configuración de la AMI, el lanzamiento fallará.

**Ejemplo 1: determine los valores de las opciones de metadatos**

En este ejemplo, se inicia una instancia de EC2 en una Región en la que `HttpPutResponseHopLimit` se establece en `1` a nivel de cuenta. La AMI especificada tiene `ImdsSupport` establecido en `v2.0`. En el momento de la inicialización, no se especifican opciones de metadatos directamente en la instancia. La instancia se inicia con las siguientes opciones de metadatos:

```
"MetadataOptions": {
    ...
    "HttpTokens": "required",
    "HttpPutResponseHopLimit": 1,
    ...
```

Estos valores se determinaron de la siguiente manera:
+ **No se especificaron opciones de metadatos en el momento de la inicialización:** durante la inicialización de la instancia, no se proporcionaron valores específicos para las opciones de metadatos ni en los parámetros de inicialización de la instancia ni en la plantilla de inicialización.
+ **La configuración de la cuenta tiene prioridad:** si no se especifican valores específicos en el momento de la inicialización, prevalece la configuración a nivel de la cuenta dentro de la Región. Esto significa que se aplican los valores predeterminados configurados a nivel de cuenta. En este caso, `HttpPutResponseHopLimit` se estableció en `1`.
+ La **configuración de la AMI tiene prioridad:** en ausencia de un valor específico en la inicialización o a nivel de cuenta para `HttpTokens` (la versión de metadatos de la instancia), se aplica la configuración de la AMI. En este caso, la configuración de AMI `ImdsSupport: v2.0` determinó que `HttpTokens` se estableció en `required`. Tenga en cuenta que, si bien la configuración de la AMI `ImdsSupport: v2.0` está diseñada para establecerse como `HttpPutResponseHopLimit: 2`, la configuración a nivel de cuenta `HttpPutResponseHopLimit: 1`, que tiene mayor prioridad, la anuló.

**Ejemplo 2: determine los valores de las opciones de metadatos**

En este ejemplo, la instancia de EC2 se inicia con la misma configuración que en el ejemplo 1 anterior, pero con `HttpTokens` configurados `optional` directamente como en la instancia en el momento de la inicialización. La instancia se inicia con las siguientes opciones de metadatos:

```
"MetadataOptions": {
    ...
    "HttpTokens": "optional",
    "HttpPutResponseHopLimit": 1,
    ...
```

El valor de `HttpPutResponseHopLimit` se determina de la misma manera que en el ejemplo 1. Sin embargo, el valor de `HttpTokens` se determina de la siguiente manera: las opciones de metadatos configuradas en la instancia en el momento de la inicialización tienen prioridad. Aunque la AMI se configuró con `ImdsSupport: v2.0` (en otras palabras, `HttpTokens` se establecieron como `required`), prevaleció el valor especificado en la instancia en el momento de la inicialización (`HttpTokens` se establecieron como `optional`).

**Ejemplo 3: determine los valores de las opciones de metadatos con HttpTokenforced activado**

En este ejemplo, el número de cuenta en la región tiene `HttpTokens = required` y `HttpTokensEnforced = enabled`.

Considere los siguientes intentos de lanzamiento de instancias de EC2:
+ Intento de lanzamiento con `HttpTokens` establecido en `optional`: el lanzamiento falla porque la aplicación a nivel de cuenta está habilitada (`HttpTokensEnforced = enabled`) y el parámetro de lanzamiento tiene prioridad sobre el valor predeterminado de la cuenta.
+ Intento de lanzamiento con `HttpTokens` establecido en `required`: el lanzamiento se realiza correctamente porque cumple con la aplicación a nivel de cuenta. 
+ Intento de lanzamiento sin especificar ningún valor de `HttpTokens`: el lanzamiento se realiza correctamente porque el valor predeterminado se establece en `required` según la configuración de la cuenta. 

### Ajuste de la versión de los metadatos de instancia
<a name="metadata-version-order-of-precedence"></a>

Cuando se lanza una instancia, el valor de la *versión de metadatos* de la instancia es **IMDSv1 o IMDSv2 (token opcional)** (`httpTokens=optional`) o **solo IMDSv2 (se requiere token) (`httpTokens=required`). **

Al iniciar la instancia, puede especificar de forma manual el valor de la versión de metadatos o usar el valor predeterminado. Si especifica el valor de forma manual, anulará los valores predeterminados. Si opta por no especificar el valor de forma manual, se determinará mediante una combinación de ajustes predeterminados.

En el siguiente diagrama de flujo se muestra cómo se determina la versión de metadatos de una instancia en el momento del lanzamiento en función de los ajustes de los distintos niveles de la configuración y en el lugar en el que se evalúa la aplicación. En la siguiente tabla se proporciona la configuración específica de cada nivel.

![\[Un diagrama de flujo que muestra los puntos de evaluación de la versión de metadatos de la instancia y de la aplicación de IMDSv2.\]](http://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/images/imds-defaults-launch-flow.png)


En la tabla se muestra cómo se determina la versión de metadatos de una instancia en el momento de la inicialización (indicada en la columna 4, en la **Configuración de la instancia resultante**) en función de los ajustes de los distintos niveles de configuración. El orden de prioridad es de izquierda a derecha, donde la primera columna tiene mayor prioridad, como se indica a continuación:
+ Columna 1: **Parámetro de inicialización**, representa la configuración de la instancia que se especifica de forma manual en la inicialización.
+ Columna 2: **Nivel de cuenta predeterminado**, representa la configuración de la cuenta.
+ Columna 3: **Valor predeterminado de la AMI**, representa la configuración de la AMI.


| Parámetro de inicialización | Nivel de cuenta predeterminado | AMI predeterminada | Configuración de la instancia resultante | 
| --- | --- | --- | --- | 
| V2 únicamente (token obligatorio) | Sin preferencias | V2 únicamente | V2 únicamente | 
| V2 únicamente (token obligatorio) | V2 únicamente | V2 únicamente | V2 únicamente | 
| V2 únicamente (token obligatorio) | V1 o V2 | V2 únicamente | V2 únicamente | 
| V1 o V2 (token obligatorio) | Sin preferencias | V2 únicamente | V1 o V2 | 
| V1 o V2 (token obligatorio) | V2 únicamente | V2 únicamente | V1 o V2 | 
| V1 o V2 (token obligatorio) | V1 o V2 | V2 únicamente | V1 o V2 | 
| No configurado | Sin preferencias | V2 únicamente | V2 únicamente | 
| No configurado | V2 únicamente | V2 únicamente | V2 únicamente | 
| No configurado | V1 o V2 | V2 únicamente | V1 o V2 | 
| V2 únicamente (token obligatorio) | Sin preferencias | null | V2 únicamente | 
| V2 únicamente (token obligatorio) | V2 únicamente | null | V2 únicamente | 
| V2 únicamente (token obligatorio) | V1 o V2 | null | V2 únicamente | 
| V1 o V2 (token obligatorio) | Sin preferencias | null | V1 o V2 | 
| V1 o V2 (token obligatorio) | V2 únicamente | null | V1 o V2 | 
| V1 o V2 (token obligatorio) | V1 o V2 | null | V1 o V2 | 
| No configurado | Sin preferencias | null | V1 o V2 | 
| No configurado | V2 únicamente | null | V2 únicamente | 
| No configurado | V1 o V2 | null | V1 o V2 | 

## Uso de las claves de condición de IAM para restringir las opciones de metadatos de instancia
<a name="iam-condition-keys-and-imds"></a>

Puede utilizar claves de condición de IAM en una política de IAM o SCP de la siguiente forma:
+ Permitir que una instancia se lance únicamente si está configurada para requerir el uso de IMDSv2
+ Restringir el número de saltos permitidos
+ Desactivar el acceso a los metadatos de instancia

**Topics**
+ [

## Dónde configurar las opciones de metadatos de instancia
](#where-to-configure-instance-metadata-options)
+ [

## Orden de prioridad para las opciones de metadatos de instancia
](#instance-metadata-options-order-of-precedence)
+ [

## Uso de las claves de condición de IAM para restringir las opciones de metadatos de instancia
](#iam-condition-keys-and-imds)
+ [

# Configurar las opciones de metadatos para instancias nuevas
](configuring-IMDS-new-instances.md)
+ [

# Configurar las opciones de metadatos para instancias existentes
](configuring-IMDS-existing-instances.md)

**nota**  
Debe proceder con cautela y realizar pruebas antes de realizar cambios. Tome nota de lo siguiente:  
Si fuerza el uso de IMDSv2, las aplicaciones o los agentes que usen IMDSv1 para acceder a metadatos de instancia se interrumpirán.
Si desactiva todo acceso a los metadatos de instancia, las aplicaciones o los agentes que confíen en que el acceso a metadatos de instancia funcione, se interrumpirán.
En el caso de IMDSv2, debe utilizar `/latest/api/token` al recuperar el token.
(Solo Windows) Si la versión de PowerShell es anterior a 4.0, debe [actualizar a Windows Management Framework 4.0](https://devblogs.microsoft.com/powershell/windows-management-framework-wmf-4-0-update-now-available-for-windows-server-2012-windows-server-2008-r2-sp1-and-windows-7-sp1/) para requerir el uso de IMDSv2.

# Configurar las opciones de metadatos para instancias nuevas
<a name="configuring-IMDS-new-instances"></a>

Puede configurar las siguientes opciones de metadatos para nuevas instancias.

**Topics**
+ [

## Requerir el uso de IMDSv2
](#configure-IMDS-new-instances)
+ [

## Habilitación de los puntos de conexión IPv4 e IPv6 de IMDS
](#configure-IMDS-new-instances-ipv4-ipv6-endpoints)
+ [

## Desactivar el acceso a los metadatos de instancia
](#configure-IMDS-new-instances--turn-off-instance-metadata)
+ [

## Permitir acceso a etiquetas en metadatos de instancia
](#configure-IMDS-new-instances-tags-in-instance-metadata)

**nota**  
Los ajustes de estas opciones se configuran a nivel de cuenta, ya sea directamente en la cuenta o mediante una política declarativa. Se deben configurar en cada Región de AWS en la que desee configurar las opciones de metadatos de la instancia. El uso de una política declarativa permite aplicar la configuración en varias regiones simultáneamente, así como en varias cuentas simultáneamente. Cuando se utiliza una política declarativa, no se puede modificar la configuración directamente en una cuenta. En este tema se describe cómo configurar el ajuste directamente dentro de una cuenta. Para obtener información sobre el uso de políticas declarativas, consulte [Políticas declarativas](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) en la *Guía del usuario de AWS Organizations*.

## Requerir el uso de IMDSv2
<a name="configure-IMDS-new-instances"></a>

Puede usar los siguientes métodos para exigir el uso de IMDSv2 en sus instancias nuevas.

**Topics**
+ [

### Ajuste de IMDSv2 como valor predeterminado de la cuenta
](#set-imdsv2-account-defaults)
+ [

### Aplicar IMDSv2 a nivel de cuenta
](#enforce-imdsv2-at-the-account-level)
+ [

### Configuración de la instancia en el momento de la inicialización
](#configure-IMDS-new-instances-instance-settings)
+ [

### Configuración de la AMI
](#configure-IMDS-new-instances-ami-configuration)
+ [

### Uso de una política de IAM
](#configure-IMDS-new-instances-iam-policy)

### Ajuste de IMDSv2 como valor predeterminado de la cuenta
<a name="set-imdsv2-account-defaults"></a>

Puede establecer el valor predeterminado del servicio de metadatos de instancias (IMDS) a nivel de cuenta para cada Región de AWS. Cuando se inicia una instancia *nueva*, la versión de metadatos de la instancia se configura automáticamente al valor a nivel de cuenta predeterminado. Sin embargo, puede anular el valor manualmente al iniciarla o después. Para obtener más información sobre cómo afectan a una instancia la configuración a nivel de cuenta y las anulaciones manuales, consulte [Orden de prioridad para las opciones de metadatos de instancia](configuring-instance-metadata-options.md#instance-metadata-options-order-of-precedence)

**nota**  
Si se establece el valor predeterminado a nivel de cuenta, no se restablecen las instancias *existentes*. Por ejemplo, si establece el valor predeterminado a nivel de cuenta en IMDSv2, las instancias existentes que estén configuradas en IMDSv1 no se verán afectadas. Si desea cambiar el valor de las instancias existentes, debe cambiarlo manualmente en las propias instancias.

Puede establecer el valor predeterminado de la cuenta para la versión de metadatos de instancia en IMDSv2, de modo que todas las instancias *nuevas* de la cuenta se inicien con IMDSv2 obligatoriamente y, de esta forma, se deshabilita IMDSv1. Con esta cuenta predeterminada, cuando lance una instancia, los valores predeterminados de la instancia serán los siguientes:
+ Consola: la **versión de metadatos** se configura en **V2 únicamente (token obligatorio)** y el **límite de saltos de respuesta de los metadatos** se establece en **2**.
+ AWS CLI: `HttpTokens` se configuran como `required` y `HttpPutResponseHopLimit` se configura en `2`. 

**nota**  
Antes de establecer el valor predeterminado de la cuenta en IMDSv2, asegúrese de que las instancias no dependan de IMDSv1. Para obtener más información, consulte [Ruta recomendada para exigir IMDSv2](instance-metadata-transition-to-version-2.md#recommended-path-for-requiring-imdsv2).

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

**Cómo configurar IMDSv2 como valor predeterminado para la cuenta de la Región especificada**

1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Para cambiar la Región de AWS, utilice el Selector de regiones ubicado en la esquina superior derecha de la página.

1. En el panel de navegación, elija **Panel**.

1. En la tarjeta **Atributos de cuenta**, en **Configuración**, elija **Protección y seguridad de datos**.

1. **Junto a los **Valores predeterminados de IMDS**, seleccione Administrar**.

1. En la página **Administrar valores predeterminados de IMDS**, haga lo siguiente:

   1. En **Servicio de metadatos de instancia**, seleccione **Habilitado**.

   1. En **Metadata version** (Versión de metadatos), elija **V2 only (token required)** (solo V2 [token obligatorio]).

   1. En el **Límite de saltos de respuesta de metadatos**, especifique **2** si las instancias alojarán contenedores. De lo contrario, seleccione **Sin preferencia**. Si no se especifica ninguna preferencia, en el momento del lanzamiento, el valor predeterminado será **2** si la AMI tiene la configuración `ImdsSupport: v2.0`; de lo contrario, el valor predeterminado será **1**.

   1. Elija **Actualizar**.

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

**Cómo configurar IMDSv2 como valor predeterminado para la cuenta de la Región especificada**  
Use el comando [modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html) y especifique la Región en la que desea modificar la configuración a nivel de cuenta de IMDS. Incluya `--http-tokens` establecidos como `required` y `--http-put-response-hop-limit` establecido en `2` si las instancias alojarán contenedores. De lo contrario, especifique `-1` si no desea indicar ninguna preferencia. Si se especifica `-1` (ninguna preferencia), en el momento del lanzamiento, el valor predeterminado será `2` si la AMI tiene la configuración `ImdsSupport: v2.0`; de lo contrario, el valor predeterminado será `1`.

```
aws ec2 modify-instance-metadata-defaults \
    --region us-east-1 \
    --http-tokens required \
    --http-put-response-hop-limit 2
```

A continuación, se muestra un ejemplo del resultado.

```
{
    "Return": true
}
```

**Cómo ver la configuración de cuenta predeterminada para las opciones de metadatos de instancia para la Región especificada**  
Use el comando [get-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-metadata-defaults.html) y especifique la Región.

```
aws ec2 get-instance-metadata-defaults --region us-east-1
```

A continuación, se muestra un ejemplo del resultado.

```
{
    "AccountLevel": {
        "HttpTokens": "required",
        "HttpPutResponseHopLimit": 2
    },
    "ManagedBy": "account"
}
```

El campo `ManagedBy` indica la entidad que configuró el ajuste. En este ejemplo, `account` indica que el ajuste se configuró directamente en la cuenta. Un valor de `declarative-policy` significaría que el ajuste se configuró mediante una política declarativa. Para obtener más información, consulte [Políticas declarativas](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) en la *Guía del usuario de AWS Organizations*.

**Configuración de IMDSv2 como servicio predeterminado para la cuenta para todas las regiones**  
Use el comando [modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html) para modificar la configuración de nivel de cuenta de IMDS para todas las regiones. Incluya `--http-tokens` establecidos como `required` y `--http-put-response-hop-limit` establecido en `2` si las instancias alojarán contenedores. De lo contrario, especifique `-1` si no desea indicar ninguna preferencia. Si se especifica `-1` (ninguna preferencia), en el momento del lanzamiento, el valor predeterminado será `2` si la AMI tiene la configuración `ImdsSupport: v2.0`; de lo contrario, el valor predeterminado será `1`.

```
echo -e "Region          \t Modified" ; \
echo -e "--------------  \t ---------" ; \
for region in $(
    aws ec2 describe-regions \
        --region us-east-1 \
        --query "Regions[*].[RegionName]" \
        --output text
    ); 
    do (output=$(
        aws ec2 modify-instance-metadata-defaults \
            --region $region \
            --http-tokens required \
            --http-put-response-hop-limit 2 \
            --output text)
        echo -e "$region        \t $output"
    );
done
```

A continuación, se muestra un ejemplo del resultado.

```
Region                   Modified
--------------           ---------
ap-south-1               True
eu-north-1               True
eu-west-3                True
...
```

**Visualización de la configuración de cuenta predeterminada para las opciones de metadatos de instancia para todas las regiones**  
Use el comando [get-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-metadata-defaults.html).

```
echo -e "Region   \t Level          Hops    HttpTokens" ; \
echo -e "-------------- \t ------------   ----    ----------" ; \
for region in $(
    aws ec2 describe-regions \
        --region us-east-1 \
        --query "Regions[*].[RegionName]" \
        --output text
    ); 
    do (output=$(
        aws ec2 get-instance-metadata-defaults \
            --region $region \
            --output text)
        echo -e "$region \t $output" 
    );
done
```

A continuación, se muestra un ejemplo del resultado.

```
Region           Level          Hops    HttpTokens
--------------   ------------   ----    ----------
ap-south-1       ACCOUNTLEVEL   2       required
eu-north-1       ACCOUNTLEVEL   2       required
eu-west-3        ACCOUNTLEVEL   2       required
...
```

------
#### [ PowerShell ]

**Cómo configurar IMDSv2 como valor predeterminado para la cuenta de la Región especificada**  
Use el cmdlet [Edit-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataDefault.html) y especifique la Región en la que desea modificar la configuración a nivel de cuenta de IMDS. Incluya `-HttpToken` establecidos como `required` y `-HttpPutResponseHopLimit` establecido en `2` si las instancias alojarán contenedores. De lo contrario, especifique `-1` si no desea indicar ninguna preferencia. Si se especifica `-1` (ninguna preferencia), en el momento del lanzamiento, el valor predeterminado será `2` si la AMI tiene la configuración `ImdsSupport: v2.0`; de lo contrario, el valor predeterminado será `1`.

```
Edit-EC2InstanceMetadataDefault `
    -Region us-east-1 `
    -HttpToken required `
    -HttpPutResponseHopLimit 2
```

A continuación, se muestra un ejemplo del resultado.

```
True
```

**Cómo ver la configuración de cuenta predeterminada para las opciones de metadatos de instancia para la Región especificada**  
Use el cmdlet [Get-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceMetadataDefault.html) y especifique la región.

```
Get-EC2InstanceMetadataDefault -Region us-east-1 | Format-List
```

A continuación, se muestra un ejemplo del resultado.

```
HttpEndpoint            : 
HttpPutResponseHopLimit : 2
HttpTokens              : required
InstanceMetadataTags    :
```

**Configuración de IMDSv2 como servicio predeterminado para la cuenta para todas las regiones**  
Use el cmdlet [Edit-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataDefault.html) para modificar la configuración de nivel de cuenta de IMDS de todas las regiones. Incluya `-HttpToken` establecidos como `required` y `-HttpPutResponseHopLimit` establecido en `2` si las instancias alojarán contenedores. De lo contrario, especifique `-1` si no desea indicar ninguna preferencia. Si se especifica `-1` (ninguna preferencia), en el momento del lanzamiento, el valor predeterminado será `2` si la AMI tiene la configuración `ImdsSupport: v2.0`; de lo contrario, el valor predeterminado será `1`.

```
(Get-EC2Region).RegionName | `
    ForEach-Object {
    [PSCustomObject]@{
        Region   = $_
        Modified = (Edit-EC2InstanceMetadataDefault `
                -Region $_ `
                -HttpToken required `
                -HttpPutResponseHopLimit 2)
    } 
} | `
Format-Table Region, Modified -AutoSize
```

Resultado previsto

```
Region         Modified
------         --------
ap-south-1         True
eu-north-1         True
eu-west-3          True
...
```

**Visualización de la configuración de cuenta predeterminada para las opciones de metadatos de instancia para todas las regiones**  
Utilice el cmdlet [Get-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceMetadataDefault.html).

```
(Get-EC2Region).RegionName | `
    ForEach-Object {
    [PSCustomObject]@{
        Region = $_
        HttpPutResponseHopLimit = (Get-EC2InstanceMetadataDefault -Region $_).HttpPutResponseHopLimit
        HttpTokens              = (Get-EC2InstanceMetadataDefault -Region $_).HttpTokens
    }
} | `
Format-Table -AutoSize
```

Ejemplo de resultado

```
Region         HttpPutResponseHopLimit HttpTokens
------         ----------------------- ----------
ap-south-1                           2 required
eu-north-1                           2 required
eu-west-3                            2 required                    
...
```

------

### Aplicar IMDSv2 a nivel de cuenta
<a name="enforce-imdsv2-at-the-account-level"></a>

Puede aplicar el uso de IMDSv2 a nivel de cuenta para cada Región de AWS. Cuando se aplican, las instancias solo se pueden lanzar si están configuradas para que exijan IMDSv2. Esta aplicación se aplica independientemente de cómo esté configurada la instancia o la AMI.

**nota**  
Antes de habilitar la aplicación de IMDSv2 a nivel de cuenta, asegúrese de que sus aplicaciones y AMI sean compatibles con IMDSv2. Para obtener más información, consulte [Ruta recomendada para exigir IMDSv2](instance-metadata-transition-to-version-2.md#recommended-path-for-requiring-imdsv2). Si la aplicación de IMDSv2 está habilitada y `httpTokens` no está establecida en la configuración de la instancia `required` en el momento del lanzamiento, en la configuración de la cuenta o en la configuración de la AMI, el lanzamiento de la instancia fallará. Para obtener información sobre la resolución de problemas, consulte [Se produce un error al lanzar una instancia habilitada para IMDSv1](troubleshooting-launch.md#launching-an-imdsv1-enabled-instance-fails).

**nota**  
Esta configuración no cambia la versión de IMDS de las instancias existentes, pero bloquea la activación de IMDSv1 en las instancias existentes que actualmente tienen inhabilitado IMDSv1.

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

**Para aplicar IMDSv2 para la cuenta de la región especificada**

1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Para cambiar la región Región de AWS, utilice el selector de regiones en la esquina superior derecha de la página.

1. En el panel de navegación, elija **Panel**.

1. En la tarjeta **Atributos de cuenta**, en **Configuración**, elija **Protección y seguridad de datos**.

1. **Junto a los **Valores predeterminados de IMDS**, seleccione Administrar**.

1. En la página **Administrar valores predeterminados de IMDS**, haga lo siguiente:

   1. En **Metadata version** (Versión de metadatos), elija **V2 only (token required)** (solo V2 [token obligatorio]).

   1. En **Aplicar IMDSv2**, seleccione **Activado.**

   1. Elija **Actualizar**.

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

**Para aplicar IMDSv2 para la cuenta de la región especificada**  
 Use el comando [modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html) y especifique la Región en la que desea aplicar IMDSv2. 

```
aws ec2 modify-instance-metadata-defaults \
    --region us-east-1 \
    --http-tokens required \
    --http-tokens-enforced enabled
```

A continuación, se muestra un ejemplo del resultado.

```
{
"Return": true
}
```

**Para ver la configuración de aplicación de IMDSv2 para la cuenta en una región específica**  
Use el comando [get-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-metadata-defaults.html) y especifique la Región.

```
aws ec2 get-instance-metadata-defaults --region us-east-1
```

A continuación, se muestra un ejemplo del resultado.

```
{
    "AccountLevel": {
        "HttpTokens": "required",
        "HttpTokensEnforced": "enabled"
    },
    "ManagedBy": "account"
}
```

El campo `ManagedBy` indica la entidad que configuró el ajuste. En este ejemplo, `account` indica que el ajuste se configuró directamente en la cuenta. Un valor de `declarative-policy` significaría que el ajuste se configuró mediante una política declarativa. Para obtener más información, consulte [Políticas declarativas](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) en la *Guía del usuario de organizaciones de AWS*.

**Para aplicar IMDSv2 para la cuenta para todas las regiones**  
Use el comando [modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html) para aplicar IMDSv2 en todas las regiones.

```
echo -e "Region          \t Modified" ; \
echo -e "--------------  \t ---------" ; \
for region in $(
    aws ec2 describe-regions \
        --region us-east-1 \
        --query "Regions[*].[RegionName]" \
        --output text
    ); 
    do (output=$(
        aws ec2 modify-instance-metadata-defaults \
            --region $region \
            --http-tokens-enforced enabled \
            --output text)
        echo -e "$region        \t $output"
    );
done
```

A continuación, se muestra un ejemplo del resultado.

```
Region                   Modified
--------------           ---------
ap-south-1               True
eu-north-1               True
eu-west-3                True
...
```

**Para ver la configuración de aplicación de IMDSv2 de la cuenta en todas las regiones**  
Use el comando [get-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-metadata-defaults.html).

```
echo -e "Region   \t Level           HttpTokensEnforced" ; \
echo -e "-------------- \t ------------   ----------------" ; \
for region in $(
    aws ec2 describe-regions \
        --region us-east-1 \
        --query "Regions[*].[RegionName]" \
        --output text
    ); 
    do (output=$(
        aws ec2 get-instance-metadata-defaults \
            --region $region \
            --query 'AccountLevel.HttpTokensEnforced' \           
            --output text)
        echo -e "$region \t ACCOUNTLEVEL $output" 
    );
done
```

A continuación, se muestra un ejemplo del resultado.

```
Region           Level          HttpTokensEnforced
--------------   ------------   ------------------
ap-south-1       ACCOUNTLEVEL   enabled
eu-north-1       ACCOUNTLEVEL   enabled
eu-west-3        ACCOUNTLEVEL   enabled
...
```

------
#### [ PowerShell ]

**Para aplicar IMDSv2 para la cuenta de la región especificada**  
Use el cmdlet [Edit-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataDefault.html) y especifique la Región en la que desea aplicar IMDSv2. 

```
Edit-EC2InstanceMetadataDefault `
    -Region us-east-1 `
    -HttpToken required `
    -HttpPutResponseHopLimit 2
```

A continuación, se muestra un ejemplo del resultado.

```
@{
    Return = $true
}
```

**Para ver la configuración de aplicación de IMDSv2 para la cuenta en una región específica**  
Use el comando Get-EC2InstanceMetadataDefault y especifique la región.

```
Get-EC2InstanceMetadataDefault -Region us-east-1
```

A continuación, se muestra un ejemplo del resultado.

```
@{
    AccountLevel = @{
        HttpTokens = "required"
        HttpTokensEnforced = "enabled"
    }
    ManagedBy = "account"
}
```

El campo `ManagedBy` indica la entidad que configuró el ajuste. En este ejemplo, `account` indica que el ajuste se configuró directamente en la cuenta. Un valor de `declarative-policy` significaría que el ajuste se configuró mediante una política declarativa. Para obtener más información, consulte [Políticas declarativas](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) en la *Guía del usuario de organizaciones de AWS*.

**Para aplicar IMDSv2 para la cuenta para todas las regiones**  
Use el comando [modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html) para aplicar IMDSv2 en todas las regiones.

```
echo -e "Region          \t Modified" ; \
echo -e "--------------  \t ---------" ; \
for region in $(
    aws ec2 describe-regions \
        --region us-east-1 \
        --query "Regions[*].[RegionName]" \
        --output text
    ); 
    do (output=$(
        aws ec2 modify-instance-metadata-defaults \
            --region $region \
            --http-tokens-enforced enabled \
            --output text)
        echo -e "$region        \t $output"
    );
done
```

A continuación, se muestra un ejemplo del resultado.

```
Region                   Modified
--------------           ---------
ap-south-1               True
eu-north-1               True
eu-west-3                True
...
```

**Configuración de IMDSv2 como servicio predeterminado para la cuenta para todas las regiones**  
Use el cmdlet [Edit-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataDefault.html) para modificar la configuración de nivel de cuenta de IMDS de todas las regiones. Incluya `-HttpToken` establecidos como `required` y `-HttpPutResponseHopLimit` establecido en `2` si las instancias alojarán contenedores. De lo contrario, especifique `-1` si no desea indicar ninguna preferencia. Si se especifica `-1` (ninguna preferencia), en el momento del lanzamiento, el valor predeterminado será `2` si la AMI tiene la configuración `ImdsSupport: v2.0`; de lo contrario, el valor predeterminado será `1`.

```
(Get-EC2Region).RegionName | `
    ForEach-Object {
    [PSCustomObject]@{
        Region   = $_
        Modified = (Edit-EC2InstanceMetadataDefault `
                -Region $_ `
                -HttpToken required `
                -HttpPutResponseHopLimit 2)
    } 
} | `
Format-Table Region, Modified -AutoSize
```

Resultado previsto

```
Region         Modified
------         --------
ap-south-1         True
eu-north-1         True
eu-west-3          True
...
```

**Visualización de la configuración de cuenta predeterminada para las opciones de metadatos de instancia para todas las regiones**  
Utilice el cmdlet [Get-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceMetadataDefault.html).

```
(Get-EC2Region).RegionName | `
    ForEach-Object {
    [PSCustomObject]@{
        Region = $_
        HttpPutResponseHopLimit = (Get-EC2InstanceMetadataDefault -Region $_).HttpPutResponseHopLimit
        HttpTokens              = (Get-EC2InstanceMetadataDefault -Region $_).HttpTokens
    }
} | `
Format-Table -AutoSize
```

Ejemplo de resultado

```
Region         HttpPutResponseHopLimit HttpTokens
------         ----------------------- ----------
ap-south-1                           2 required
eu-north-1                           2 required
eu-west-3                            2 required                    
...
```

------

### Configuración de la instancia en el momento de la inicialización
<a name="configure-IMDS-new-instances-instance-settings"></a>

Al [iniciar una instancia](ec2-launch-instance-wizard.md), puede configurarla para exigir el uso de IMDSv2 mediante la configuración de los siguientes campos:
+ Consola de Amazon EC2: establezca **Metadata version** (Versión de metadatos) en **V2 only (token required)** (Solo V2 [token obligatorio]).
+ AWS CLI: `HttpTokens` establecido en `required`.

Al especificar que IMDSv2 es obligatorio, también se debe habilitar el punto de conexión del servicio de metadatos de instancia (IMDS); para ello, se debe establecer **Metadatos accesibles** en **Habilitados** (consola) o `HttpEndpoint` en `enabled` (AWS CLI).

En un entorno de contenedores, cuando se requiere IMDSv2, recomendamos establecer el límite de saltos en `2`. Para obtener más información, consulte [Consideraciones sobre el acceso a los metadatos de instancia](instancedata-data-retrieval.md#imds-considerations).

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

**Para exigir el uso de IMDSv2 en una nueva instancia**
+ Al iniciar una nueva instancia en la consola de Amazon EC2, despliegue **Advanced details** (Detalles avanzados) y haga lo siguiente:
  + Para **Metadatos accesibles**, elija **Enabled** (Habilitado).
  + En **Metadata version** (Versión de metadatos), elija **V2 only (token required)** (solo V2 [token obligatorio]).
  + (Entorno de contenedores) Para el **límite de saltos de respuesta de metadatos**, elija **2**.

  Para obtener más información, consulte [Detalles avanzados](ec2-instance-launch-parameters.md#liw-advanced-details).

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

**Para exigir el uso de IMDSv2 en una nueva instancia**  
En el siguiente ejemplo de [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html), se inicia una instancia `c6i.large` con `--metadata-options` establecido en `HttpTokens=required`. Cuando se especifica un valor para `HttpTokens`, también se debe establecer `HttpEndpoint` en `enabled`. Debido a que el encabezado del token de seguridad está establecido en `required` para las solicitudes de recuperación de metadatos, se requiere que la instancia use IMDSv2 al solicitar los metadatos de la instancia.

En un entorno de contenedores, cuando se requiere IMDSv2, recomendamos establecer el límite de saltos en `2` con `HttpPutResponseHopLimit=2`.

```
aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type c6i.large \
	...
    --metadata-options "HttpEndpoint=enabled,HttpTokens=required,HttpPutResponseHopLimit=2"
```

------
#### [ PowerShell ]

**Para exigir el uso de IMDSv2 en una nueva instancia**  
En el siguiente ejemplo del cmdlet [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html), se inicia una instancia `c6i.large` con `MetadataOptions_HttpEndpoint` establecido en `enabled` y el parámetro `MetadataOptions_HttpTokens` en `required`. Cuando se especifica un valor para `HttpTokens`, también se debe establecer `HttpEndpoint` en `enabled`. Debido a que el encabezado del token de seguridad está establecido en `required` para las solicitudes de recuperación de metadatos, se requiere que la instancia use IMDSv2 al solicitar los metadatos de la instancia.

```
New-EC2Instance `
    -ImageId ami-0abcdef1234567890 `
    -InstanceType c6i.large `
    -MetadataOptions_HttpEndpoint enabled `
    -MetadataOptions_HttpTokens required
```

------
#### [ CloudFormation ]

Para especificar las opciones de metadatos de una instancia con CloudFormation, consulte la propiedad [AWS::EC2::LaunchTemplate MetadataOptions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html) en la *Guía del usuario de AWS CloudFormation*.

------

### Configuración de la AMI
<a name="configure-IMDS-new-instances-ami-configuration"></a>

Al registrar una AMI nueva o modificar una AMI existente, puede establecer el parámetro `imds-support` en `v2.0`. Las instancias iniciadas desde esta AMI tendrán el valor de **Metadata version** (Versión de metadatos) establecido en **V2 only (token required)** (Solo V2 [token obligatorio]) (consola) o `HttpTokens` establecido en `required` (AWS CLI). Con esta configuración, la instancia requiere que se utilice IMDSv2 al solicitar los metadatos de la instancia.

Tenga en cuenta que cuando establezca `imds-support` en `v2.0`, las instancias iniciadas desde esta AMI también tendrán **Metadata response hop limit** (Límite de saltos de respuesta de metadatos) (consola) o `http-put-response-hop-limit` (AWS CLI) establecido en **2**.

**importante**  
No utilice este parámetro a menos que el software de AMI sea compatible con IMDSv2. Después de establecer el valor en `v2.0`, no podrá deshacer el cambio. La única forma de “restablecer” la AMI es crear una AMI nueva a partir de la instantánea subyacente.

**Para configurar una nueva AMI para IMDSv2**  
Utilice uno de los siguientes métodos para configurar una nueva AMI de IMDSv2.

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

El siguiente ejemplo de [register-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html) registra una AMI mediante la instantánea especificada de un volumen raíz de EBS como dispositivo `/dev/xvda`. Especifique `v2.0` para el parámetro `imds-support` a fin de que las instancias que se lancen desde esta AMI requieran que se utilice IMDSv2 al solicitar metadatos de instancia.

```
aws ec2 register-image \
    --name my-image \
    --root-device-name /dev/xvda \
    --block-device-mappings DeviceName=/dev/xvda,Ebs={SnapshotId=snap-0123456789example} \
    --architecture x86_64 \
    --imds-support v2.0
```

------
#### [ PowerShell ]

En el siguiente ejemplo del cmdlet [Register-EC2Image](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-EC2Image.html), se registra una AMI mediante la instantánea especificada de un volumen raíz de EBS como dispositivo `/dev/xvda`. Especifique `v2.0` para el parámetro `ImdsSupport` a fin de que las instancias que se lancen desde esta AMI requieran que se utilice IMDSv2 al solicitar metadatos de instancia.

```
Register-EC2Image `
    -Name 'my-image' `
    -RootDeviceName /dev/xvda `
    -BlockDeviceMapping  ( 
    New-Object `
        -TypeName Amazon.EC2.Model.BlockDeviceMapping `
        -Property @{ 
        DeviceName = '/dev/xvda'; 
        EBS        = (New-Object -TypeName Amazon.EC2.Model.EbsBlockDevice -Property @{ 
                SnapshotId = 'snap-0123456789example'
                VolumeType = 'gp3' 
                } )      
        }  ) `
    -Architecture X86_64 `
    -ImdsSupport v2.0
```

------

**Para configurar una AMI existente para IMDSv2**  
Utilice uno de los métodos siguientes para configurar una AMI existente para IMDSv2.

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

El siguiente ejemplo [modify-image-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-image-attribute.html) modifica una AMI existente únicamente para IMDSv2. Especifique `v2.0` para el parámetro `imds-support` a fin de que las instancias que se lancen desde esta AMI requieran que se utilice IMDSv2 al solicitar metadatos de instancia.

```
aws ec2 modify-image-attribute \
    --image-id ami-0abcdef1234567890 \
    --imds-support v2.0
```

------
#### [ PowerShell ]

En el siguiente ejemplo de cmdlet [Edit-EC2ImageAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2ImageAttribute.html), se modifica una AMI existente únicamente para IMDSv2. Especifique `v2.0` para el parámetro `imds-support` a fin de que las instancias que se lancen desde esta AMI requieran que se utilice IMDSv2 al solicitar metadatos de instancia.

```
Edit-EC2ImageAttribute `
    -ImageId ami-0abcdef1234567890 `
    -ImdsSupport 'v2.0'
```

------

### Uso de una política de IAM
<a name="configure-IMDS-new-instances-iam-policy"></a>

Puede crear una política de IAM que realice una de las siguientes acciones:
+ Impide a los usuarios iniciar nuevas instancias a menos que exijan el uso de IMDSv2 en la nueva instancia.
+ Impide que los usuarios llamen a la API ModifyInstanceMetadataOptions para cambiar las opciones de metadatos de una instancia en ejecución. Restrinja el acceso a la propiedad ModifyInstanceMetadataOptions HttpTokens para evitar actualizaciones no deseadas de las instancias en ejecución.
+ Impida que los usuarios llamen a la API ModifyInstanceMetadataDefaults para cambiar la configuración predeterminada de las cuentas tanto de HttpTokens como de HttpTokensEnforced. Al restringir el acceso a estas dos propiedades, se garantizará que solo los roles autorizados puedan modificar los valores predeterminados de la cuenta.

**Para exigir el uso de IMDSv2 en todas las instancias nuevas mediante una política de IAM**  
Para asegurarse de que los usuarios solo puedan lanzar instancias que exigen el uso de IMDSv2 al solicitar metadatos de instancia, haga lo siguiente:
+ Restrinja el acceso a las API `ModifyInstanceMetadataOptions` y `ModifyInstanceMetadataDefaults`, más específicamente, a las propiedades `httpTokens` y `httpTokensEnforced`.
+ A continuación, establezca la cuenta predeterminada en `httpTokens = required` y `httpTokensEnforced = enabled`.

  Para ver una política de IAM de ejemplo, consulte [Trabajar con metadatos de instancias](ExamplePolicies_EC2.md#iam-example-instance-metadata).

## Habilitación de los puntos de conexión IPv4 e IPv6 de IMDS
<a name="configure-IMDS-new-instances-ipv4-ipv6-endpoints"></a>

El IMDS tiene dos puntos de conexión en una instancia: IPv4 (`169.254.169.254`) e IPv6 (`[fd00:ec2::254]`). Al habilitar el IMDS, el punto de conexión IPv4 se habilita automáticamente. El punto de conexión IPv6 permanece deshabilitado incluso si se lanza una instancia en una subred de solo IPv6. Para habilitar el punto de conexión IPv6, tiene que hacerlo de manera explícita. Si habilita el punto de conexión IPv6, el punto de conexión IPv4 permanece habilitado.

Puede habilitar el punto de conexión IPv6 al momento de lanzar una instancia o después.

**Requisitos para la habilitación de un punto de conexión IPv6**
+ El tipo de instancia seleccionado es una [instancia basada en Nitro](instance-types.md#instance-hypervisor-type).
+ Las subredes seleccionadas son compatibles con IPv6, y cada subred es [de doble pila o solo IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range).

Utilice uno de los siguientes métodos para lanzar una instancia con el punto de conexión IPv6 de IMDS habilitado.

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

**Para habilitar el punto de conexión IPv6 de IMDS en el momento del lanzamiento de una instancia**
+ [Lance la instancia](ec2-launch-instance-wizard.md) en la consola de Amazon EC2 con la siguiente información especificada en **Advanced details** (Detalles avanzados):
  + Para el **punto de conexión IPv6 para la obtención de metadatos**, seleccione **Activado**.

Para obtener más información, consulte [Detalles avanzados](ec2-instance-launch-parameters.md#liw-advanced-details).

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

**Para habilitar el punto de conexión IPv6 de IMDS en el momento del lanzamiento de una instancia**  
El siguiente ejemplo de [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) inicia una instancia `c6i.large` con el punto de conexión de IPv6 habilitado para IMDS. Para habilitar el punto de conexión de IPv6, para el parámetro `--metadata-options`, especifique `HttpProtocolIpv6=enabled`. Cuando se especifica un valor para `HttpProtocolIpv6`, también se debe establecer `HttpEndpoint` en `enabled`.

```
aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type c6i.large \
    ...
    --metadata-options "HttpEndpoint=enabled,HttpProtocolIpv6=enabled"
```

------
#### [ PowerShell ]

**Para habilitar el punto de conexión IPv6 de IMDS en el momento del lanzamiento de una instancia**  
En el siguiente ejemplo del cmdlet [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html), se inicia una instancia `c6i.large` con el punto de conexión de IPv6 habilitado para IMDS. Para habilitar el punto de conexión IPv6, especifique `MetadataOptions_HttpProtocolIpv6` como `enabled`. Cuando se especifica un valor para `MetadataOptions_HttpProtocolIpv6`, también se debe establecer `MetadataOptions_HttpEndpoint` en `enabled`.

```
New-EC2Instance `
    -ImageId ami-0abcdef1234567890 `
    -InstanceType c6i.large `
    -MetadataOptions_HttpEndpoint enabled `
    -MetadataOptions_HttpProtocolIpv6 enabled
```

------

## Desactivar el acceso a los metadatos de instancia
<a name="configure-IMDS-new-instances--turn-off-instance-metadata"></a>

Puede desactivar el acceso a los metadatos de la instancia si deshabilita el IMDS al iniciar una instancia. Puede activar el acceso más adelante si vuelve a habilitar el IMDS. Para obtener más información, consulte [Activación del acceso a los metadatos de instancias](configuring-IMDS-existing-instances.md#enable-instance-metadata-on-existing-instances).

**importante**  
Puede optar por deshabilitar el IMDS durante la inicialización o después. Si deshabilita el IMDS *durante la inicialización*, es posible que lo siguiente no funcione:  
Es posible que no tenga acceso mediante SSH a su instancia. `public-keys/0/openssh-key`, que es la clave de SSH pública de su instancia, no estará accesible porque normalmente se proporciona y se accede a ella desde los metadatos de la instancia de EC2.
Los datos de usuario de EC2 no estarán disponibles y no se ejecutarán al iniciar la instancia. Los datos de usuario de EC2 se alojan en el IMDS. Si deshabilita el IMDS, desactiva de forma eficaz el acceso a los datos de los usuarios.
Para acceder a esta funcionalidad, puede volver a habilitar el IMDS después de la inicialización.

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

**Para desactivar el acceso a los metadatos de instancia durante la inicialización**
+ [Lance la instancia](ec2-launch-instance-wizard.md) en la consola de Amazon EC2 con la siguiente información especificada en **Advanced details** (Detalles avanzados):
  + Para **Metadatos accesibles**, elija **Disabled** (Deshabilitado).

Para obtener más información, consulte [Detalles avanzados](ec2-instance-launch-parameters.md#liw-advanced-details).

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

**Para desactivar el acceso a los metadatos de instancia durante la inicialización**  
Lance la instancia con `--metadata-options` establecido en `HttpEndpoint=disabled`.

```
aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type c6i.large \
    ... 
    --metadata-options "HttpEndpoint=disabled"
```

------
#### [ PowerShell ]

**Para desactivar el acceso a los metadatos de instancia durante la inicialización**  
En el siguiente ejemplo del cmdlet [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html), se inicia una instancia con `MetadataOptions_HttpEndpoint` establecido en `disabled`.

```
New-EC2Instance `
    -ImageId ami-0abcdef1234567890 `
    -InstanceType c6i.large `
    -MetadataOptions_HttpEndpoint disabled
```

------
#### [ CloudFormation ]

Para especificar las opciones de metadatos de una instancia con CloudFormation, consulte la propiedad [AWS::EC2::LaunchTemplate MetadataOptions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html) en la *Guía del usuario de CloudFormation*. 

------

## Permitir acceso a etiquetas en metadatos de instancia
<a name="configure-IMDS-new-instances-tags-in-instance-metadata"></a>

De forma predeterminada, no se puede acceder a las etiquetas de instancia en los metadatos de la instancia. Para cada instancia, debe permitir el acceso de manera explícita. Si se permite el acceso, las *claves* de etiquetas de la instancia deben cumplir con restricciones de caracteres específicas; de lo contrario, fallará el lanzamiento de la instancia. Para obtener más información, consulte [Habilitación del acceso a etiquetas en metadatos de instancia](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS).

# Configurar las opciones de metadatos para instancias existentes
<a name="configuring-IMDS-existing-instances"></a>

Puede modificar las opciones de metadatos para las instancias existentes.

Además, puede crear una política de IAM que impida a los usuarios modificar las opciones de metadatos de instancias existentes. Para controlar qué usuarios pueden modificar las opciones de metadatos de instancias, especifique una política que impida a todos los usuarios que no tengan un rol determinado utilizar la API [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html). Para ver una política de IAM de ejemplo, consulte [Trabajar con metadatos de instancias](ExamplePolicies_EC2.md#iam-example-instance-metadata).

**nota**  
Si se utilizó una política declarativa para configurar las opciones de metadatos de la instancia, no podrá modificarlas directamente en la cuenta. Para obtener más información, consulte [Políticas declarativas](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) en la *Guía del usuario de AWS Organizations*.

## Requerir el uso de IMDSv2
<a name="modify-require-IMDSv2"></a>

Utilice uno de los siguientes métodos para modificar las opciones de metadatos de una instancia existente para requerir que se utilice IMDSv2 al requerir los metadatos de instancia. Cuando se requiere IMDSv2, no se puede usar IMDSv1.

**nota**  
Antes de solicitar el uso de IMDSv2, asegúrese de que la instancia no esté realizando llamadas a IMDSv1. La métrica `MetadataNoToken` de CloudWatch rastrea las llamadas de IMDSv1. Cuando `MetadataNoToken` no registra ningún uso de IMDSv1 en una instancia, la instancia estará lista para requerir IMDSv2.

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

**Para exigir el uso de IMDSv2 en una instancia existente**

1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. En el panel de navegación, seleccione **Instances (Instancias)**.

1. Seleccione la instancia.

1. Elija **Acciones**, **Configuración de la instancia** y **Modificar opciones de metadatos de instancia**.

1. En el cuadro de diálogo **Modificar opciones de metadatos de instancia**, haga lo siguiente:

   1. En **Servicio de metadatos de instancia**, seleccione **Habilitar**.

   1. En **IMDSv2**, seleccione **Obligatorio**.

   1. Seleccione **Save**.

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

**Para exigir el uso de IMDSv2 en una instancia existente**  
Use el comando de la CLI [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) y establezca el parámetro `http-tokens` en `required`. Cuando se especifica un valor para `http-tokens`, también se debe establecer `http-endpoint` en `enabled`.

```
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-endpoint enabled
```

------
#### [ PowerShell ]

**Para exigir el uso de IMDSv2 en una instancia existente**  
Utilice el cmdlet [Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html) y defina el parámetro `HttpTokens` en `required`. Cuando se especifica un valor para `HttpTokens`, también se debe establecer `HttpEndpoint` en `enabled`.

```
(Edit-EC2InstanceMetadataOption `
    -InstanceId i-1234567890abcdef0 `
    -HttpTokens required `
    -HttpEndpoint enabled).InstanceMetadataOptions
```

------

## Restauración del uso de IMDSv1
<a name="modify-restore-IMDSv1"></a>

Cuando se requiere IMDSv2 en una instancia, se producirá un error al usar una solicitud de IMDSv1. Cuando IMDSv2 sea opcional, tanto IMDSv2 como IMDSv1 funcionarán. Por lo tanto, para reemplazar IMDSv1, haga que IMDSv2 sea opcional (`httpTokens = optional`) mediante alguno de los métodos siguientes.

La propiedad IMDS de `httpTokensEnforced` también impide los intentos de habilitar IMDSv1 en una instancia existente. Si se habilita para una cuenta de una región, si se intenta establecer `httpTokens` en `optional` se producirá una excepción de `UnsupportedOperation`. Para obtener más información, consulte [Solución de problemas](#troubleshoot-modifying-an-imdsv1-enabled-instance-fails).

**importante**  
Si los lanzamientos de la instancia fallan debido a la aplicación de IMDSv2, tiene dos opciones para permitir que los lanzamientos se realicen correctamente:  
**Lanzar instancias solo como IMDSv2**: si el software que se ejecuta en las instancias usa solo IMDSv2 (sin depender de IMDSv1), puede lanzar las instancias solo como IMDSv2. Para ello, configure IMDSv2 únicamente mediante los parámetros de lanzamiento de `httpTokens = required` o los metadatos predeterminados de la cuenta de la región. 
**Desactivar la aplicación**: si su software sigue dependiendo de IMDSv1, establezca `httpTokensEnforced` en `disabled` para la cuenta de la región. Para obtener más información, consulte [Aplicar IMDSv2 a nivel de cuenta](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level).

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

**Para restaurar el uso de IMDSv1 en una instancia**

1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. En el panel de navegación, seleccione **Instances (Instancias)**.

1. Seleccione la instancia.

1. Elija **Acciones**, **Configuración de la instancia** y **Modificar opciones de metadatos de instancia**.

1. En el cuadro de diálogo **Modificar opciones de metadatos de instancia**, haga lo siguiente:

   1. Para **Servicio de metadatos de instancia**, asegúrese de que esté seleccionada la opción **Habilitar**.

   1. En **IMDSv2**, seleccione **Opcional**.

   1. Seleccione **Save**.

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

**Para restaurar el uso de IMDSv1 en una instancia**  
Puede utilizar el comando de la CLI [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) `http-tokens` establecido en `optional` para restaurar el uso de IMDSv1 cuando se solicitan metadatos de la instancia.

```
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens optional \
    --http-endpoint enabled
```

------
#### [ PowerShell ]

**Para restaurar el uso de IMDSv1 en una instancia**  
Puede usar el cmdlet [Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html) con `HttpTokens` establecido en `optional`, para restaurar el uso de IMDSv1 al solicitar los metadatos de la instancia.

```
(Edit-EC2InstanceMetadataOption `
    -InstanceId i-1234567890abcdef0 `
    -HttpTokens optional `
    -HttpEndpoint enabled).InstanceMetadataOptions
```

------

## Cambio del límite de saltos de respuesta PUT
<a name="modify-PUT-response-hop-limit"></a>

En las instancias existentes, puede modificar la configuración del límite de saltos de respuesta `PUT`.

Actualmente, solo la AWS CLI y los AWS SDK admiten cambiar el límite de saltos de respuesta PUT.

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

**Para cambiar el límite de saltos de respuesta PUT**  
Use el comando de la CLI [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) y establezca el parámetro `http-put-response-hop-limit` en el número de saltos necesario. En el siguiente ejemplo, el límite de saltos se ha establecido en `3`. Tenga en cuenta que al especificar un valor para `http-put-response-hop-limit`, también debe establecer `http-endpoint` en `enabled`.

```
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-put-response-hop-limit 3 \
    --http-endpoint enabled
```

------
#### [ PowerShell ]

**Para cambiar el límite de saltos de respuesta PUT**  
Utilice el cmdlet [Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html) y defina el parámetro `HttpPutResponseHopLimit` para el número de saltos obligatorio. En el siguiente ejemplo, el límite de saltos se ha establecido en `3`. Tenga en cuenta que al especificar un valor para `HttpPutResponseHopLimit`, también debe establecer `HttpEndpoint` en `enabled`.

```
(Edit-EC2InstanceMetadataOption `
    -InstanceId i-1234567890abcdef0 `
    -HttpPutResponseHopLimit 3 `
    -HttpEndpoint enabled).InstanceMetadataOptions
```

------

## Habilitación de los puntos de conexión IPv4 e IPv6 de IMDS
<a name="enable-ipv6-endpoint-for-existing-instances"></a>

El IMDS tiene dos puntos de conexión en una instancia: IPv4 (`169.254.169.254`) e IPv6 (`[fd00:ec2::254]`). Al habilitar el IMDS, el punto de conexión IPv4 se habilita automáticamente. El punto de conexión IPv6 permanece deshabilitado incluso si se lanza una instancia en una subred de solo IPv6. Para habilitar el punto de conexión IPv6, tiene que hacerlo de manera explícita. Si habilita el punto de conexión IPv6, el punto de conexión IPv4 permanece habilitado.

Puede habilitar el punto de conexión IPv6 al momento de lanzar una instancia o después.

**Requisitos para la habilitación de un punto de conexión IPv6**
+ El tipo de instancia seleccionado es una [instancia basada en Nitro](instance-types.md#instance-hypervisor-type).
+ Las subredes seleccionadas son compatibles con IPv6, y cada subred es [de doble pila o solo IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range).

En la actualidad, solo la AWS CLI y los AWS SDK son compatibles con la habilitación de un punto de conexión IPv6 de IMDS después del lanzamiento de una instancia.

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

**Para habilitar el punto de conexión IPv6 de IMDS para una instancia**  
Use el comando de la CLI [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) y establezca el parámetro `http-protocol-ipv6` en `enabled`. Tenga en cuenta que al especificar un valor para `http-protocol-ipv6`, también debe establecer `http-endpoint` en `enabled`.

```
aws ec2 modify-instance-metadata-options \
	--instance-id i-1234567890abcdef0 \
	--http-protocol-ipv6 enabled \
	--http-endpoint enabled
```

------
#### [ PowerShell ]

**Para habilitar el punto de conexión IPv6 de IMDS para una instancia**  
Utilice el cmdlet [Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html) y defina el parámetro `HttpProtocolIpv6` en `enabled`. Tenga en cuenta que al especificar un valor para `HttpProtocolIpv6`, también debe establecer `HttpEndpoint` en `enabled`.

```
(Edit-EC2InstanceMetadataOption `
    -InstanceId i-1234567890abcdef0 `
    -HttpProtocolIpv6 enabled `
    -HttpEndpoint enabled).InstanceMetadataOptions
```

------

## Activación del acceso a los metadatos de instancias
<a name="enable-instance-metadata-on-existing-instances"></a>

Puede activar el acceso a los metadatos de instancia al habilitar el punto de conexión HTTP del IMDS en la instancia, independientemente de la versión del IMDS que utilice. Para anular este cambio en cualquier momento, deshabilite el punto de conexión HTTP.

Utilice uno de los métodos siguientes para activar el acceso a los metadatos de una instancia en una instancia.

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

**Para activar el acceso a los metadatos de instancia**

1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. En el panel de navegación, seleccione **Instances (Instancias)**.

1. Seleccione la instancia.

1. Elija **Acciones**, **Configuración de la instancia** y **Modificar opciones de metadatos de instancia**.

1. En el cuadro de diálogo **Modificar opciones de metadatos de instancia**, haga lo siguiente:

   1. En **Servicio de metadatos de instancia**, seleccione **Habilitar**.

   1. Seleccione **Save**.

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

**Para activar el acceso a los metadatos de instancia**  
Use el comando de la CLI [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) y establezca el parámetro `http-endpoint` en `enabled`.

```
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-endpoint enabled
```

------
#### [ PowerShell ]

**Para activar el acceso a los metadatos de instancia**  
Utilice el cmdlet [Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html) y defina el parámetro `HttpEndpoint` en `enabled`.

```
(Edit-EC2InstanceMetadataOption `
    -InstanceId i-1234567890abcdef0 `
    -HttpEndpoint enabled).InstanceMetadataOptions
```

------

## Desactivar el acceso a los metadatos de instancia
<a name="disable-instance-metadata-on-existing-instances"></a>

Puede desactivar el acceso a los metadatos de instancia al deshabilitar el punto de conexión HTTP del IMDS en la instancia, independientemente de la versión del IMDS que utilice. Puede anular este cambio en cualquier momento mediante la activación del punto de conexión HTTP.

Utilice uno de los métodos siguientes para desactivar el acceso a los metadatos de una instancia.

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

**Para desactivar el acceso a los metadatos de instancia**

1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. En el panel de navegación, seleccione **Instances (Instancias)**.

1. Seleccione la instancia.

1. Elija **Acciones**, **Configuración de la instancia** y **Modificar opciones de metadatos de instancia**.

1. En el cuadro de diálogo **Modificar opciones de metadatos de instancia**, haga lo siguiente:

   1. Para **Servicio de metadatos de instancia**, desactive **Habilitar**.

   1. Seleccione **Save**.

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

**Para desactivar el acceso a los metadatos de instancia**  
Use el comando de la CLI [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) y establezca el parámetro `http-endpoint` en `disabled`.

```
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-endpoint disabled
```

------
#### [ PowerShell ]

**Para desactivar el acceso a los metadatos de instancia**  
Utilice el cmdlet [Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html) y defina el parámetro `HttpEndpoint` en `disabled`.

```
(Edit-EC2InstanceMetadataOption `
    -InstanceId i-1234567890abcdef0 `
    -HttpEndpoint disabled).InstanceMetadataOptions
```

------

## Permitir acceso a etiquetas en metadatos de instancia
<a name="modify-access-to-tags-in-instance-metadata-on-existing-instances"></a>

Puede permitir el acceso a etiquetas en los metadatos de instancia en una instancia en ejecución o detenida. Para cada instancia, debe permitir el acceso de manera explícita. Si se permite el acceso, las *claves* de etiquetas de instancia deben cumplir con restricciones de caracteres específicas; de lo contrario, dará error. Para obtener más información, consulte [Habilitación del acceso a etiquetas en metadatos de instancia](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS).

## Solución de problemas
<a name="troubleshoot-modifying-an-imdsv1-enabled-instance-fails"></a>

### Se produce un error al modificar una instancia habilitada para IMDSv1
<a name="modifying-an-imdsv1-enabled-instance-fails"></a>

#### Descripción
<a name="modifying-an-imdsv1-enabled-instance-fails-description"></a>

Ha recibido este mensaje de error:

`You can't launch instances with IMDSv1 because httpTokensEnforced is enabled for this account. Either launch the instance with httpTokens=required or contact your account owner to disable httpTokensEnforced using the ModifyInstanceMetadataDefaults API or the account settings in the EC2 console.`

#### Causa
<a name="modifying-an-imdsv1-enabled-instance-fails-cause"></a>

Este error se produce cuando se intenta modificar una instancia existente para que esté habilitada para IMDSv1 (`httpTokens = optional`) en una cuenta en la que la configuración de la cuenta EC2 o una política declarativa de la organización de AWS aplica el uso de IMDSv2 (`httpTokensEnforced = enabled`). 

#### Solución
<a name="modifying-an-imdsv1-enabled-instance-fails-solution"></a>

Si necesita compatibilidad con IMDSv1 en las instancias existentes, tendrá que deshabilitar la aplicación de IMDSv2 en la cuenta de la región. Configure `HttpTokensEnforced` en `disabled` para deshabilitar la aplicación de IMDSv2. Para obtener más información, consulte [ModifyInstanceMetadataDefaults](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataDefaults.html) en la Referencia de la API de Amazon EC2. Si prefiere configurar este ajuste mediante la consola, consulte [Aplicar IMDSv2 a nivel de cuenta](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level).

Se recomienda que use únicamente IMDSv2 (`httpTokens=required`). Para obtener más información, consulte [Transición al uso de Servicio de metadatos de instancia, versión 2](instance-metadata-transition-to-version-2.md).

 

# Ejecución de comandos al lanzar una instancia de EC2 con la entrada de datos de usuario
<a name="user-data"></a>

Al iniciar una instancia de Amazon EC2, los datos de usuario se pueden transmitir a la instancia utilizada para realizar tareas de configuración automáticas o ejecutar scripts después de que se inicie la instancia.

Si le interesan escenarios de automatización más complejos, puede considerar el uso de CloudFormation. Para obtener más información, consulte [Implementación de aplicaciones en Amazon EC2 con CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/deploying.applications.html) en la *Guía del usuario de AWS CloudFormation*.

En las instancias de Linux, puede transferir dos tipos de datos de usuario a Amazon EC2: scripts de intérprete de comandos y directivas cloud-init. También puede pasar estos datos en el asistente de inicialización de instancias como texto sin formato, como archivo (esto resulta útil para iniciar instancias con las herramientas de la línea de comandos) o como texto codificado en base64 (para llamadas a la API).

En las instancias de Windows, los agentes de inicialización gestionan los scripts de datos de usuario.

**Consideraciones**
+ Los datos de usuario se tratan como datos opacos: lo que facilita es lo que obtiene. La instancia es quien debe interpretarlos.
+ Los datos de usuario deben estar codificados con base64. La consola de Amazon EC2 puede realizar la codificación con base64 por usted, o bien puede aceptar la entrada codificada con base64. Si recupera los datos de usuario mediante los metadatos de instancia o la consola, se decodificarán automáticamente en base64.
+ Los datos de usuario están limitados a 16 KB, sin formato, antes de cifrarlo en base64. El tamaño de una cadena de longitud *n* tras el cifrado en base64 es ceil(*n*/3)\$14.
+ Los datos de usuario son un atributo de la instancia. Si crea una AMI a partir de una instancia, los datos de usuario de la instancia no se incluyen en la AMI.

## Datos de usuario en la Consola de administración de AWS
<a name="user-data-console"></a>

Puede especificar los datos de usuario de la instancia al iniciar la instancia. Si el volumen raíz de la instancia es un volumen de EBS, también puede detener la instancia y actualizar los datos de usuario.

### Especificación de los datos de usuario de la instancia durante la inicialización con Launch Wizard
<a name="user-data-launch-instance-wizard"></a>

Puede especificar los datos de usuario al lanzar una instancia con Launch Wizard en la consola de EC2. Para especificar los datos de usuario en la inicialización, siga el procedimiento para [inicializar una instancia](ec2-launch-instance-wizard.md). El campo **User data** (Datos de usuario) se encuentra en la sección [Detalles avanzados](ec2-instance-launch-parameters.md#liw-advanced-details) del asistente de inicialización de instancias. Ingrese el script de shell en el campo **User data** y, a continuación, complete el procedimiento de inicialización de instancias.

En la siguiente captura de pantalla del campo de **datos del usuario**, la secuencia de comandos de ejemplo crea un archivo en la carpeta temporal de Windows, utilizando la fecha y la hora actuales en el nombre del archivo. Al incluir `<persist>true</persist>`, el script se ejecuta cada vez que comienzas o reinicias la instancia. Si deja vacía la casilla **Los datos del usuario ya están codificados en base64**, la consola de Amazon EC2 realizará la codificación en base64 en su nombre.

![\[Campo de texto de datos del usuario de Advance Details (Detalles avanzados).\]](http://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/images/configure_ec2config_userdata.png)


Para obtener más información, consulte [Especificación de los datos de usuario de la instancia durante la inicialización con Launch Wizard](#user-data-launch-instance-wizard). Para ver un ejemplo de Linux en el que se usa la AWS CLI, consulte [Datos de usuario y las AWS CLI](#user-data-api-cli). Para ver un ejemplo de Windows en el que se utiliza Tools for Windows PowerShell, consulte [Datos de usuario y las Tools for Windows PowerShell](#user-data-powershell).

### Visualizar y actualizar los datos de usuario de la instancia
<a name="user-data-view-change"></a>

Puede ver los datos de usuario de cualquier instancia y actualizarlos en las instancias detenidas.

**Para actualizar los datos de usuario de una instancia con la consola**

1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. En el panel de navegación, seleccione **Instances (Instancias)**.

1. Seleccione la instancia y elija **Actions (Acciones)**, **Instance State (Estado de la instancia)** y **Stop instance (Detener instancia)**.
**aviso**  
Cuando detiene una instancia, se pierden los datos contenidos en los volúmenes de almacén de instancias. Para conservar estos datos, realice una copia de seguridad de ellos en un almacenamiento persistente.

1. Cuando se le pida que confirme, seleccione **Detener**. Puede que transcurran unos minutos hasta que la instancia se detenga.

1. Con la instancia aún seleccionada, elija **Actions (Acciones)**, **Instance Settings (Configuración de la instancia)** y **Edit user data (Editar datos del usuario)**. Los datos de usuario no se pueden cambiar si la instancia se está ejecutando, pero puede verlos.

1. En el cuadro de diálogo **Modificar datos del usuario**, actualiza los datos de usuario y a continuación selecciona **Guardar**. Para ejecutar los scripts de datos de usuario cada vez que comienzas o reinicias la instancia, agrega `<persist>true</persist>`, tal como se muestra en el siguiente ejemplo:  
![\[Cuadro de diálogo Edit User Data (Editar datos de usuario).\]](http://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/images/view-change-user-data.png)

1. Inicie la instancia. Si habilitaste la ejecución de los datos de usuario para arranques o reinicios posteriores, los scripts de datos de usuario actualizados se ejecutan como parte del proceso de inicio de la instancia.

## Gestión por parte de Amazon EC2 de los datos de usuario de las instancias de Linux
<a name="userdata-linux"></a>

Los siguientes ejemplos utilizan datos de usuario para ejecutar comandos que configuran un servidor LAMP cuando se inicia la instancia. En cada ejemplo, se ejecutan las siguientes tareas:
+ Se actualizan los paquetes de software de distribución.
+ Se instalan los paquetes del servidor web `php` y `mariadb`.
+ El servicio `httpd` se inicia y se activa.
+ Se añade el usuario `ec2-user` al grupo apache.
+ Se establecen los permisos de archivo y la propiedad adecuados para el directorio web y los archivos que contiene.
+ Se crea una página web sencilla para probar el servidor web y el motor PHP.

**Topics**
+ [

### Requisitos previos
](#user-data-requirements)
+ [

### Scripts de shell y datos de usuario
](#user-data-shell-scripts)
+ [

### Actualización de los datos de usuario de la instancia
](#user-data-modify)
+ [

### Directivas cloud-init y datos de usuario
](#user-data-cloud-init)
+ [

### Datos de usuario y las AWS CLI
](#user-data-api-cli)
+ [

### Combinación de scripts de shell y directivas cloud-init
](#user-data-mime-multi)

### Requisitos previos
<a name="user-data-requirements"></a>

Los ejemplos de este tema suponen lo siguiente:
+ Su instancia tiene un nombre de DNS público al que se puede acceder desde Internet.
+ El grupo de seguridad asociado a la instancia está configurado para permitir el tráfico SSH (puerto 22) para que pueda conectarse a la instancia y ver los archivos de registro de salida.
+ La instancia se inicia con una AMI de Amazon Linux. Es posible que los comandos y directivas no funcionen para otras distribuciones de Linux. Para obtener más información acerca de otras distribuciones, por ejemplo su compatibilidad con cloud-init, consulte la documentación específica.

### Scripts de shell y datos de usuario
<a name="user-data-shell-scripts"></a>

Si está familiarizado con el scripting desde el shell, esta es la forma más sencilla y completa de enviar instrucciones a una instancia tras su inicialización. Si estas tareas se agregan en el momento del arranque, aumentará la cantidad de tiempo necesario para arrancar la instancia. Conceda algunos minutos extra para que estas tareas se completen antes de probar que el script de usuario ha finalizado satisfactoriamente.

**importante**  
De forma predeterminada, los scripts de datos de usuario y las directivas de cloud-init solo se ejecutan durante el ciclo de arranque cuando se inicia una instancia por primera vez. Puede actualizar la configuración para asegurarse de que los scripts de datos de usuario y las directivas de cloud-init se ejecuten cada vez que reinicie la instancia. Para obtener más información, consulte [¿Cómo puedo utilizar los datos de usuario para ejecutar automáticamente un script con cada reinicio de mi instancia de Amazon EC2 Linux?](https://repost.aws/knowledge-center/execute-user-data-ec2) en el AWSCentro de Conocimientos.

Los scripts de shell de datos de usuario deben comenzar por los caracteres `#!` y la ruta del intérprete que se desea que lea el script (normalmente **/bin/bash)**. Para obtener una introducción a las secuencias de intérprete de comandos, consulte el [Manual de referencia de Bash](https://www.gnu.org/software/bash/manual/bash.html) en el sitio web del *Sistema operativo GNU*.

Los scripts que se introducen como datos de usuario se ejecutan como el usuario raíz; por consiguiente, no use el comando **sudo** en el script. Recuerde que los archivos que cree serán propiedad del usuario raíz; si necesita que usuarios no raíz tengan acceso a los archivos, tendrá que modificar los permisos consecuentemente en el script. Asimismo, como el script no se ejecuta de forma interactiva, no puede incluir comandos que requieran respuestas de los usuarios (como **yum update** sin la marca `-y`).

Si utiliza una API de AWS, incluida la CLI de AWS, en un script de datos del usuario, debe utilizar un perfil de instancia al iniciar la instancia. Un perfil de instancia proporciona las credenciales de AWS adecuadas requeridas por el script de datos del usuario para emitir la llamada a la API. Para obtener más información, consulte [Uso de perfiles de instancia](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) en la Guía del usuario de IAM. Los permisos que asigne al rol de IAM dependen de los servicios a los que llame con la API. Para obtener más información, consulte [Roles de IAM para Amazon EC2](iam-roles-for-amazon-ec2.md).

El archivo de registro de salida cloud-init captura la salida para que pueda depurar sus scripts fácilmente después de la inicialización si una instancia no se comporta de la manera prevista. Para ver el archivo de registro, [conéctese a la instancia](connect-to-linux-instance.md) y abra `/var/log/cloud-init-output.log`.

Cuando se procesa un script de datos del usuario, se copia y se ejecuta desde `/var/lib/cloud/instances/instance-id/`. El script no se elimina después de ejecutarse. Asegúrese de eliminar los scripts de `/var/lib/cloud/instances/instance-id/` antes de crear una AMI desde la instancia. De lo contrario, el script estará en este directorio en cualquier instancia iniciada desde la AMI.

### Actualización de los datos de usuario de la instancia
<a name="user-data-modify"></a>

Para poder actualizar los datos de usuario de la instancia, primero debe detener la instancia. Si la instancia se está ejecutando, podrá ver los datos del usuario, pero no modificarlos.

**aviso**  
Cuando detiene una instancia, se pierden los datos contenidos en los volúmenes de almacén de instancias. Para conservar estos datos, realice una copia de seguridad de ellos en un almacenamiento persistente.

**Para modificar los datos de usuario de la instancia**

1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. En el panel de navegación, seleccione **Instancias**.

1. Seleccione la instancia y elija **Instance State (Estado de la instancia)** y **Stop instance (Detener instancia)**. Si esta opción está desactivada, la instancia ya está detenida o bien su volumen raíz es un volumen del almacén de instancias.

1. Cuando se le pida que confirme, seleccione **Detener**. Puede que transcurran unos minutos hasta que la instancia se detenga.

1. Con la instancia aún seleccionada, elija **Actions (Acciones)**, **Instance Settings (Configuración de la instancia)** y **Edit user data (Editar datos del usuario)**.

1. Modifique los datos de usuario según sea necesario y después elija **Save (Guardar)**.

1. Inicie la instancia. Los nuevos datos de usuario son visibles en su instancia tras reiniciarla; sin embargo, los scripts de datos de usuario no se ejecutan.

### Directivas cloud-init y datos de usuario
<a name="user-data-cloud-init"></a>

El paquete cloud-init configura aspectos específicos de una nueva instancia de Amazon Linux cuando se inicia; lo más notable es que configura el archivo `.ssh/authorized_keys` para el usuario ec2-user, de forma que puede iniciar sesión con su propia clave privada. Para obtener más información sobre las tareas de configuración que realiza el paquete de cloud-init para las instancias de Amazon Linux, consulte la siguiente documentación:
+ **Amazon Linux 2023**: [cloud-init personalizado](https://docs.aws.amazon.com/linux/al2023/ug/cloud-init.html)
+ **Amazon Linux 2**: [uso de cloud-init en Amazon Linux 2](https://docs.aws.amazon.com/linux/al2/ug/amazon-linux-cloud-init.html)

Las directivas de usuario cloud-init se pueden pasar a una instancia durante la inicialización del mismo modo que se pasa un script, si bien la sintaxis es diferente. Para obtener más información sobre el inicio en la nube, visite [https://cloudinit.readthedocs.org/en/latest/index.html](https://cloudinit.readthedocs.org/en/latest/index.html).

**importante**  
De forma predeterminada, los scripts de datos de usuario y las directivas de cloud-init solo se ejecutan durante el ciclo de arranque cuando se inicia una instancia por primera vez. Puede actualizar la configuración para asegurarse de que los scripts de datos de usuario y las directivas de cloud-init se ejecuten cada vez que reinicie la instancia. Para obtener más información, consulte [¿Cómo puedo utilizar los datos de usuario para ejecutar automáticamente un script con cada reinicio de mi instancia de Amazon EC2 Linux?](https://repost.aws/knowledge-center/execute-user-data-ec2) en el AWSCentro de Conocimientos.

Si estas tareas se agregan en el momento del arranque, aumentará la cantidad de tiempo necesario para arrancar una instancia. Conceda unos cuantos minutos extra para que estas tareas se completen antes de probar que las directivas de datos de usuario han finalizado.

**Para pasar directivas cloud-init a una instancia de Amazon Linux**

1. Siga el procedimiento para [iniciar una instancia](ec2-launch-instance-wizard.md). El campo **User data** (Datos de usuario) se encuentra en la sección [Detalles avanzados](ec2-instance-launch-parameters.md#liw-advanced-details) del asistente de inicialización de instancias. Ingrese el texto de la directiva de inicio en la nube en el campo **User data** y, a continuación, complete el procedimiento de inicialización de instancias.

   En el siguiente ejemplo, las directivas crean y configuran un servidor web en Amazon Linux. La línea `#cloud-config` de la parte superior es obligatoria para poder identificar los comandos como directivas cloud-init.

------
#### [ AL2023 ]

   ```
   #cloud-config
   package_update: true
   package_upgrade: all
   	
   packages:
   - httpd
   - mariadb105-server
   - php8.1
   - php8.1-mysqlnd
   
   runcmd:
   - systemctl start httpd
   - systemctl enable httpd
   - [ sh, -c, "usermod -a -G apache ec2-user" ]
   - [ sh, -c, "chown -R ec2-user:apache /var/www" ]
   - chmod 2775 /var/www
   - [ find, /var/www, -type, d, -exec, chmod, 2775, {}, \; ]
   - [ find, /var/www, -type, f, -exec, chmod, 0664, {}, \; ]
   - [ sh, -c, 'echo "<?php phpinfo(); ?>" > /var/www/html/phpinfo.php' ]
   ```

------
#### [ AL2 ]

   ```
   #cloud-config
   package_update: true
   package_upgrade: all
   	
   packages:
   - httpd
   - mariadb-server
   	
   runcmd:
   - [ sh, -c, "amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2" ]
   - systemctl start httpd
   - systemctl enable httpd
   - [ sh, -c, "usermod -a -G apache ec2-user" ]
   - [ sh, -c, "chown -R ec2-user:apache /var/www" ]
   - chmod 2775 /var/www
   - [ find, /var/www, -type, d, -exec, chmod, 2775, {}, \; ]
   - [ find, /var/www, -type, f, -exec, chmod, 0664, {}, \; ]
   - [ sh, -c, 'echo "<?php phpinfo(); ?>" > /var/www/html/phpinfo.php' ]
   ```

------

1. Conceda tiempo suficiente para que la instancia se lance y ejecute las directivas en los datos de usuario y después compruebe si las directivas han completado las tareas deseadas.

   Para este ejemplo, en un explorador web, escriba la URL del archivo PHP de prueba que han creado las directivas. Esta URL es la dirección DNS pública de la instancia seguida de una barra diagonal y el nombre del archivo.

   ```
   http://my.public.dns.amazonaws.com/phpinfo.php
   ```

   Debería ver la página de información PHP. Si no puede ver la página de información de PHP, compruebe que el grupo de seguridad que usa contiene una regla que permite el tráfico HTTP (puerto 80). Para obtener más información, consulte [Configurar reglas del grupo de seguridad](changing-security-group.md#add-remove-security-group-rules).

1. (Opcional) Si las directivas no llevaron a cabo las tareas que esperaba o si simplemente desea verificar que las completaron sin errores, [conéctese a la instancia](connect-to-linux-instance.md), examine el archivo de registro de salida de cloud-init (`/var/log/cloud-init-output.log`) y busque los mensajes de error en el resultado. Para obtener información adicional sobre depuración, puede agregar las líneas siguientes a las directivas:

   ```
   output : { all : '| tee -a /var/log/cloud-init-output.log' }
   ```

   Esta directiva envía el resultado de **runcmd** a `/var/log/cloud-init-output.log`.

### Datos de usuario y las AWS CLI
<a name="user-data-api-cli"></a>

Puede usar la AWS CLI para especificar, modificar y ver los datos de usuario de la instancia. Para obtener más información acerca de cómo ver los datos de usuario de la instancia usando los metadatos de la instancia, consulte [Acceso a los metadatos de instancia de una instancia de EC2](instancedata-data-retrieval.md).

En Windows puede utilizar las AWS Tools for Windows PowerShell en vez de la AWS CLI. Para obtener más información, consulte  [Datos de usuario y las Tools for Windows PowerShell](#user-data-powershell) .

**Ejemplo: Especificar datos de usuario durante la inicialización**  
Para especificar los datos de usuario cuando lance una instancia, ejecute el comando [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) con el parámetro `--user-data`. Con **run-instances**, la AWS CLI lleva a cabo la codificación en base64 de los datos de usuario automáticamente.

En el siguiente ejemplo se muestra cómo especificar un script como cadena en la línea de comandos:

```
aws ec2 run-instances --image-id ami-abcd1234 --count 1 --instance-type m3.medium \
    --key-name my-key-pair --subnet-id subnet-abcd1234 --security-group-ids sg-abcd1234 \
    --user-data echo user data
```

En el siguiente ejemplo se muestra cómo especificar un script utilizando un archivo de texto. Asegúrese de utilizar el prefijo `file://` para especificar el archivo.

```
aws ec2 run-instances --image-id ami-abcd1234 --count 1 --instance-type m3.medium \
    --key-name my-key-pair --subnet-id subnet-abcd1234 --security-group-ids sg-abcd1234 \
    --user-data file://my_script.txt
```

En el siguiente ejemplo se muestra un archivo de texto con un script de shell.

```
#!/bin/bash
yum update -y
service httpd start
chkconfig httpd on
```

**Ejemplo: Modificar los datos de usuario de una instancia detenida**  
Puede modificar los datos de usuario de una instancia detenida con el comando [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html). Con **modify-instance-attribute**, la AWS CLI no lleva a cabo la codificación en base64 de los datos de usuario automáticamente.
+ En un equipo **Linux** utilice el comando base64 para codificar los datos de usuario.

  ```
  base64 my_script.txt >my_script_base64.txt
  ```
+ En un equipo **Windows**, use el comando certutil para codificar los datos de usuario. Para poder usar este archivo con la AWS CLI, debe eliminar la primera línea (BEGIN CERTIFICATE) y la última (END CERTIFICATE).

  ```
  certutil -encode my_script.txt my_script_base64.txt
  notepad my_script_base64.txt
  ```

Use los parámetros `--attribute` y `--value` para usar el archivo de texto codificado para especificar los datos de usuario. Asegúrese de utilizar el prefijo `file://` para especificar el archivo.

```
aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --attribute userData --value file://my_script_base64.txt
```

**Ejemplo: Borrar los datos de usuario de una instancia detenida**  
Para eliminar los datos de usuario existentes, utilice el comando [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html) de la siguiente manera:

```
aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --user-data Value=
```

**Ejemplo: Ver los datos de usuario**  
Para recuperar los datos de usuario de una instancia, utilice el comando [describe-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-attribute.html). Con **describe-instance-attribute**, la AWS CLI no lleva a cabo la descodificación en base64 de los datos de usuario automáticamente.

```
aws ec2 describe-instance-attribute --instance-id i-1234567890abcdef0 --attribute userData
```

El siguiente ejemplo es una salida de ejemplo donde se muestran los datos del usuario codificados en base64.

```
{
    "UserData": {
        "Value": "IyEvYmluL2Jhc2gKeXVtIHVwZGF0ZSAteQpzZXJ2aWNlIGh0dHBkIHN0YXJ0CmNoa2NvbmZpZyBodHRwZCBvbg=="
    },
    "InstanceId": "i-1234567890abcdef0"
}
```
+ En un equipo **Linux**, use la opción `--query` para obtener los datos de usuario codificados y el comando base64 para descodificarlos.

  ```
  aws ec2 describe-instance-attribute --instance-id i-1234567890abcdef0 --attribute userData --output text --query "UserData.Value" | base64 --decode
  ```
+ En un equipo **Windows**, use la opción `--query` para obtener los datos de usuario codificados y el comando certutil para descodificarlos. Observe que el resultado codificado se guarda en un archivo y el resultado descodificado, en otro.

  ```
  aws ec2 describe-instance-attribute --instance-id i-1234567890abcdef0 --attribute userData --output text --query "UserData.Value" >my_output.txt
  certutil -decode my_output.txt my_output_decoded.txt
  type my_output_decoded.txt
  ```

A continuación, se muestra un ejemplo del resultado.

```
#!/bin/bash
yum update -y
service httpd start
chkconfig httpd on
```

### Combinación de scripts de shell y directivas cloud-init
<a name="user-data-mime-multi"></a>

De forma predeterminada, solo puede incluir un tipo de contenido en los datos de usuario a la vez. Sin embargo, puede utilizar los tipos de contenido `text/cloud-config` y `text/x-shellscript` en un archivo MIME de varias partes para incluir tanto un script de shell como las directivas cloud-init en los datos de usuario.

A continuación se muestra el formato MIME de varias partes.

```
Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
	
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
	
#cloud-config
cloud-init directives
	
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"
	
#!/bin/bash
shell script commands
--//--
```

Por ejemplo, los siguientes datos de usuario incluyen las directivas cloud-init y un script de un shell bash. Las directivas cloud-init crean un archivo (`/test-cloudinit/cloud-init.txt`) y escriben `Created by cloud-init` en dicho archivo. El script de shell bash crea un archivo (`/test-userscript/userscript.txt`) y escribe `Created by bash shell script` en dicho archivo.

```
Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
	
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
	
#cloud-config
runcmd:
- [ mkdir, /test-cloudinit ]
write_files:
- path: /test-cloudinit/cloud-init.txt
content: Created by cloud-init
	
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"
	
#!/bin/bash
mkdir test-userscript
touch /test-userscript/userscript.txt
echo "Created by bash shell script" >> /test-userscript/userscript.txt
--//--
```

## Cómo gestiona Amazon EC2 los datos de usuario de las instancias de Windows
<a name="ec2-windows-user-data"></a>

En las instancias de Windows, el agente de inicialización realiza las tareas relacionadas con los datos de usuario. Para obtener más información, consulte los siguientes temas:
+ [EC2Launch v2](ec2launch-v2.md) 
+ [EC2Launch](ec2launch.md) 
+ [Servicio EC2Config](ec2config-service.md)

Para obtener ejemplos del ensamblado de una propiedad `UserData` en una plantilla deCloudFormation, consulte [Propiedad UserData cifrada en Base64](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-general.html#scenario-userdata-base64) y [Propiedad UserData cifrada en Base64 con AccessKey y SecretKey](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-general.html#scenario-userdata-base64-with-keys).

Para ver un ejemplo de ejecución de comandos en una instancia del grupo de escalado automático que funciona con enlaces de ciclo de vida, consulte el [Tutorial: Configurar datos de usuario para recuperar el estado de ciclo de vida de destino a través de los metadatos de la instancia](https://docs.aws.amazon.com/autoscaling/ec2/userguide/tutorial-lifecycle-hook-instance-metadata.html) en la *Guía del usuario de Amazon EC2 Auto Scaling*.

**Topics**
+ [

### Scripts de datos de usuario
](#user-data-scripts)
+ [

### Datos de usuario comprimidos
](#user-data-compressed)
+ [

### Ejecución de datos de usuario
](#user-data-execution)
+ [

### Datos de usuario y las Tools for Windows PowerShell
](#user-data-powershell)

### Scripts de datos de usuario
<a name="user-data-scripts"></a>

Para que `EC2Config` o `EC2Launch` ejecuten scripts, debe incluir el script dentro de una etiqueta especial al agregarlo a los datos de usuario. La etiqueta que se utiliza depende de si los comandos se ejecutan en una ventana del símbolo del sistema (comandos por lotes) o con Windows PowerShell.

Si se especifica tanto un script de procesamiento por lotes como un script de Windows PowerShell, el script por lotes se ejecuta en primer lugar y después lo hace el script de Windows PowerShell, independientemente del orden en el que aparezcan en los datos de usuario de la instancia.

Si utiliza una API de AWS, incluida la AWS CLI, en un script de datos del usuario, debe utilizar un perfil de instancia al iniciar la instancia. Un perfil de instancia proporciona las credenciales de AWS adecuadas requeridas por el script de datos de usuario para ejecutar la llamada a la API. Para obtener más información, consulte [Perfiles de instancias](iam-roles-for-amazon-ec2.md#ec2-instance-profile). Los permisos que asigne al rol de IAM dependen de los servicios a los que llame con la API. Para obtener más información, consulte [Roles de IAM para Amazon EC2](iam-roles-for-amazon-ec2.md).

**Topics**
+ [

#### Sintaxis de los scripts de procesamiento por lotes
](#user-data-batch-scripts)
+ [

#### Sintaxis de los scripts de Windows PowerShell
](#user-data-powershell-scripts)
+ [

#### Sintaxis de los scripts de configuración de YAML
](#user-data-yaml-scripts)
+ [

#### Codificación Base64
](#user-data-base64-encoding)

#### Sintaxis de los scripts de procesamiento por lotes
<a name="user-data-batch-scripts"></a>

Especifique un script de procesamiento por lotes con la etiqueta `script`. Separe los comandos mediante saltos de línea, como se muestra en el siguiente ejemplo.

```
<script>
    echo Current date and time >> %SystemRoot%\Temp\test.log
    echo %DATE% %TIME% >> %SystemRoot%\Temp\test.log
</script>
```

De forma predeterminada, los scripts de datos de usuario se ejecutan solo una vez, cuando se inicia la instancia. Para ejecutarlos cada vez que se inicia o se reinicia la instancia, añade `<persist>true</persist>` a los datos de usuario.

```
<script>
    echo Current date and time >> %SystemRoot%\Temp\test.log
    echo %DATE% %TIME% >> %SystemRoot%\Temp\test.log
</script>
<persist>true</persist>
```

**Agente EC2Launch v2**  
Para ejecutar un script de datos de usuario XML como un proceso independiente con la tarea **executeScript** de EC2Launch v2 en la etapa `UserData`, agregue `<detach>true</detach>` a sus datos de usuario.

**nota**  
La etiqueta detach no es compatible con los agentes de inicialización anteriores.

```
<script>
    echo Current date and time >> %SystemRoot%\Temp\test.log
    echo %DATE% %TIME% >> %SystemRoot%\Temp\test.log
</script>
<detach>true</detach>
```

#### Sintaxis de los scripts de Windows PowerShell
<a name="user-data-powershell-scripts"></a>

Las AMI de Windows de AWS incluyen las [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/), por lo que puede especificar estos cmdlets en los datos de usuario. Si asocia un rol de IAM a la instancia, no es necesario especificar credenciales para los cmdlets, ya que las aplicaciones que se ejecutan en la instancia pueden utilizar las credenciales del rol para obtener acceso a los recursos de AWS (por ejemplo, los buckets de Amazon S3).

Especifique un script de Windows PowerShell con la etiqueta `<powershell>`. Separe los comandos con saltos de línea. La etiqueta `<powershell>` no distingue entre mayúsculas y minúsculas.

Por ejemplo:

```
<powershell>
    $file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
    New-Item $file -ItemType file
</powershell>
```

De forma predeterminada, los scripts de datos de usuario se ejecutan solo una vez, cuando se inicia la instancia. Para ejecutarlos cada vez que se inicia o se reinicia la instancia, añade `<persist>true</persist>` a los datos de usuario.

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

Puede especificar uno o varios argumentos de PowerShell con la etiqueta `<powershellArguments>`. Si no se pasa ningún argumento, EC2Launch y EC2Launch v2 agregan el siguiente argumento de forma predeterminada: `-ExecutionPolicy Unrestricted`.

**Ejemplo:**

```
<powershell>
    $file = $env:SystemRoot + "\Temp" + (Get-Date).ToString("MM-dd-yy-hh-mm")
    New-Item $file -ItemType file
</powershell>
<powershellArguments>-ExecutionPolicy Unrestricted -NoProfile -NonInteractive</powershellArguments>
```

**Agente EC2Launch v2**  
Para ejecutar un script de datos de usuario XML como un proceso independiente con la tarea **executeScript** de EC2Launch v2 en la etapa `UserData`, agregue `<detach>true</detach>` a sus datos de usuario.

**nota**  
La etiqueta detach no es compatible con los agentes de inicialización anteriores.

```
<powershell>
    $file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
    New-Item $file -ItemType file
</powershell>
<detach>true</detach>
```

#### Sintaxis de los scripts de configuración de YAML
<a name="user-data-yaml-scripts"></a>

Si está utilizando EC2Launch v2 para ejecutar scripts, puede utilizar el formato YAML. Para ver tareas de configuración, detalles y ejemplos de EC2Launch v2, consulte [Configuración de tareas de EC2Launch v2](ec2launch-v2-settings.md#ec2launch-v2-task-configuration).

Especifique una secuencia de comandos YAML con el paso `executeScript`.

**Ejemplo de sintaxis de YAML para ejecutar un script de PowerShell** 

```
version: 1.0
tasks:
- task: executeScript
  inputs:
  - frequency: always
    type: powershell
    runAs: localSystem
    content: |-
      $file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
      New-Item $file -ItemType file
```

**Ejemplo de sintaxis YAML para ejecutar un script por lotes**

```
version: 1.1
tasks:
- task: executeScript
  inputs:
  - frequency: always
    type: batch
    runAs: localSystem
    content: |-
      echo Current date and time >> %SystemRoot%\Temp\test.log
      echo %DATE% %TIME% >> %SystemRoot%\Temp\test.log
```

#### Codificación Base64
<a name="user-data-base64-encoding"></a>

Si utiliza Amazon EC2 API o una herramienta que no realice codificación base64 de los datos de usuario, debe codificar los datos de usuario usted mismo. De lo contrario, se registra un error por imposibilidad de encontrar etiquetas `script` o `powershell` para ejecutar. A continuación se ofrece un ejemplo de codificación con Windows PowerShell.

```
$UserData = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($Script))
```

A continuación se ofrece un ejemplo de descodificación con PowerShell.

```
$Script = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($UserData))
```

Para obtener más información acerca de la codificación base64, consulte [https://www.ietf.org/rfc/rfc4648.txt](https://www.ietf.org/rfc/rfc4648.txt).

### Datos de usuario comprimidos
<a name="user-data-compressed"></a>

EC2Launch v2 es compatible con los datos de usuario comprimidos como una opción para enviar datos de usuario que superen el límite de 16 KB que impone IMDS. Para utilizar esta característica, comprima el script de datos de usuario en un archivo `.zip` y páselo a la instancia de EC2. Cuando EC2Launch v2 detecta datos de usuario comprimidos, descomprime automáticamente el script de datos de usuario comprimido y lo ejecuta.

Al igual que con los datos de usuario estándar, si utiliza Amazon EC2 API o una herramienta que no realice codificación base64 de los datos de usuario, debe codificar los datos de usuario comprimidos usted mismo. Para obtener más información sobre el límite de tamaño de los datos de usuario y la codificación base64, consulte [Acceso a los metadatos de instancia de una instancia de EC2](instancedata-data-retrieval.md).

### Ejecución de datos de usuario
<a name="user-data-execution"></a>

De forma predeterminada, todas las AMI de Windows de AWS tienen habilitada la ejecución de datos de usuario para la inicialización inicial. Puede especificar que los scripts de datos de usuario se ejecuten la próxima vez que la instancia se inicie o reinicie. O puede especificar que los scripts de datos de usuario se ejecuten cada vez que la instancia se inicie o reinicie.

**nota**  
Los datos de usuario no están habilitados para ejecutarse de forma predeterminada después de la inicialización inicial. Para permitir que los datos de usuario se ejecuten al reiniciar o iniciar la instancia, consulte [Ejecución de scripts durante los reinicios o inicios posteriores](#user-data-scripts-subsequent).

Los scripts de datos de usuario se ejecutan desde la cuenta del administrador local cuando se genera una contraseña aleatoria. De lo contrario, los scripts de datos de usuario se ejecutan desde la cuenta Sistema.

#### Scripts de inicialización de instancias
<a name="user-data-scripts-launch"></a>

Los scripts de los datos de usuario de la instancia se ejecutan durante la inicialización inicial de la instancia. Si se encuentra la etiqueta `persist`, significa que la ejecución de los datos de usuario está habilitada para inicios o reinicios posteriores. Los archivos de registro de EC2Launch v2, EC2Launch y EC2Config contienen información del resultado estándar y las secuencias de error estándar.

**EC2Launch v2**  
El archivo de registro de EC2Launch v2 es `C:\ProgramData\Amazon\EC2Launch\log\agent.log`.

**nota**  
Es posible que la carpeta `C:\ProgramData` esté oculta. Para ver la carpeta, debe mostrar los archivos y las carpetas ocultos.

Al ejecutar los datos de usuario, se registra la información siguiente:
+ `Info: Converting user-data to yaml format`: si los datos del usuario se proporcionaron en formato XML
+ `Info: Initialize user-data state`: el inicio de la ejecución de datos de usuario
+ `Info: Frequency is: always`: si la tarea de datos de usuario se está ejecutando en cada arranque
+ `Info: Frequency is: once`: si la tarea de datos de usuario se está ejecutando una sola vez
+ `Stage: postReadyUserData execution completed`: el final de la ejecución de datos de usuario

**EC2Launch**  
El archivo de registro de EC2Launch es `C:\ProgramData\Amazon\EC2-Windows\Launch\Log\UserdataExecution.log`.

Es posible que la carpeta `C:\ProgramData` esté oculta. Para ver la carpeta, debe mostrar los archivos y las carpetas ocultos.

Al ejecutar los datos de usuario, se registra la información siguiente:
+ `Userdata execution begins`: el inicio de la ejecución de datos de usuario
+ `<persist> tag was provided: true`: si se encuentra la etiqueta persistir
+ `Running userdata on every boot`: si se encuentra la etiqueta persistir
+ `<powershell> tag was provided.. running powershell content`: si se encuentra la etiqueta powershell
+ `<script> tag was provided.. running script content`: si se encuentra la etiqueta script
+ `Message: The output from user scripts`: si se ejecutan scripts de datos de usuario, se registra su salida

**EC2Config**  
El archivo de registro de EC2Config es `C:\Program Files\Amazon\Ec2ConfigService\Logs\Ec2Config.log`. Al ejecutar los datos de usuario, se registra la información siguiente:
+ `Ec2HandleUserData: Message: Start running user scripts`: el inicio de la ejecución de datos de usuario
+ `Ec2HandleUserData: Message: Re-enabled userdata execution`: si se encuentra la etiqueta persistir
+ `Ec2HandleUserData: Message: Could not find <persist> and </persist>`: si no se encuentra la etiqueta persistir
+ `Ec2HandleUserData: Message: The output from user scripts`: si se ejecutan scripts de datos de usuario, se registra su salida

#### Ejecución de scripts durante los reinicios o inicios posteriores
<a name="user-data-scripts-subsequent"></a>

Cuando actualiza los datos de usuario de la instancia, el contenido actualizado de los datos de usuario se refleja automáticamente en los metadatos de la instancia la próxima vez que reinicie o inicie la instancia. Sin embargo, según el agente de lanzamiento instalado, es posible que se requiera una configuración adicional para configurar los scripts de datos de usuario para que se ejecuten en reinicios o inicios posteriores.

Si elige la opción **Cerrar con Sysprep**, los scripts de datos de usuario se ejecutarán la próxima vez que comience o se reinicie la instancia, aunque no se haya habilitado la ejecución de los datos de usuario para comienzos o reinicios posteriores.

Para obtener instrucciones sobre cómo habilitar la ejecución de datos de usuario, seleccione la pestaña correspondiente a su agente de lanzamiento.

------
#### [ EC2Launch v2 ]

A diferencia de EC2Launch v1, EC2Launch v2 evalúa la tarea de datos de usuario en cada arranque. No es necesario programar manualmente la tarea de datos de usuario. Los datos de usuario se ejecutan en función de las opciones de frecuencia o persistencia incluidas.

Para scripts de datos de usuario XML  
Para ejecutar scripts de datos de usuario en cada arranque, añada la `<persist>true</persist>` marca a los datos de usuario. Si no se incluye el indicador de persistencia, el script de datos de usuario solo se ejecuta en el arranque inicial.

Para los datos de usuario YAML  
+ Para ejecutar una tarea en los datos de usuario en el arranque inicial, establezca la tarea `frequency` en `once`.
+ Ejecutar una tarea en los datos de usuario en cada arranque, establezca la tarea `frequency` en `always`.

------
#### [ EC2Launch ]

1. Conéctese a la instancia de Windows.

1. Abra una ventana de comandos de PowerShell y ejecute uno de los siguientes comandos:

**Ejecutar una vez**  
Para ejecutar los datos de usuario una vez en el siguiente arranque, utilice la marca `-Schedule`.

   ```
   C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 -Schedule
   ```

**Ejecutar en todos los arranques siguientes**  
Para ejecutar los datos de usuario en todos los arranques posteriores, utilice la marca `-SchedulePerBoot`.

   ```
   C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 -SchedulePerBoot
   ```

1. Desconéctese de la instancia de Windows. Para ejecutar los scripts actualizados la próxima vez que se inicie la instancia, detén la instancia y actualiza los datos de usuario.

------
#### [ EC2Config ]

1. Conéctese a la instancia de Windows.

1. Abrir `C:\Program Files\Amazon\Ec2ConfigService\Ec2ConfigServiceSetting.exe`.

1. En **User Data (Datos de usuario)**, seleccione **Enable UserData execution for next service start (Habilitar la ejecución de datos de usuario en el siguiente inicio de servicio)**.

1. Desconéctese de la instancia de Windows. Para ejecutar los scripts actualizados la próxima vez que se inicie la instancia, detén la instancia y actualiza los datos de usuario.

------

### Datos de usuario y las Tools for Windows PowerShell
<a name="user-data-powershell"></a>

Puede usar la Tools for Windows PowerShell para especificar, modificar y ver los datos de usuario de la instancia. Para obtener más información acerca de cómo ver los datos de usuario de la instancia usando los metadatos de la instancia, consulte [Acceso a los metadatos de instancia de una instancia de EC2](instancedata-data-retrieval.md). Para obtener más información sobre datos de usuario y AWS CLI, consulte [Datos de usuario y las AWS CLI](#user-data-api-cli).

**Ejemplo: Especificar los datos de usuario de la instancia durante la inicialización**  
Cree un archivo de texto con los datos de usuario de la instancia. Para ejecutar los scripts de datos de usuario cada vez que arrrancas o reinicias la instancia, agrega `<persist>true</persist>`, tal como se muestra en el siguiente ejemplo.

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

Para especificar los datos de usuario de la instancia cuando inicia la instancia, use el comando [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html). Este comando no realiza codificación base64 de los datos de usuario. Para codificar los datos de usuario en un archivo de texto llamado , utilice los siguientes comando `script.txt`.

```
PS C:\> $Script = Get-Content -Raw script.txt
PS C:\> $UserData = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($Script))
```

Utilice el parámetro `-UserData` para pasar los datos de usuario al comando **New-EC2Instance**.

```
PS C:\> New-EC2Instance -ImageId ami-abcd1234 -MinCount 1 -MaxCount 1 -InstanceType m3.medium \
    -KeyName my-key-pair -SubnetId subnet-12345678 -SecurityGroupIds sg-1a2b3c4d \
    -UserData $UserData
```

**Ejemplo: Actualizar los datos de usuario de una instancia detenida**  
Puede modificar los datos de usuario de una instancia detenida utilizando el comando [Edit-EC2InstanceAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceAttribute.html).

Cree un archivo de texto con el nuevo script. Para codificar los datos de usuario en el archivo de texto llamado , utilice los siguientes comando `new-script.txt`.

```
PS C:\> $NewScript = Get-Content -Raw new-script.txt
PS C:\> $NewUserData = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($NewScript))
```

Utilice los parámetros `-UserData` y `-Value` para especificar los datos de usuario.

```
PS C:\> Edit-EC2InstanceAttribute -InstanceId i-1234567890abcdef0 -Attribute userData -Value $NewUserData
```

**Ejemplo: Ver los datos de usuario de la instancia**  
Para recuperar los datos de usuario de una instancia, utilice el comando [Get-EC2InstanceAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceAttribute.html).

```
PS C:\> (Get-EC2InstanceAttribute -InstanceId i-1234567890abcdef0 -Attribute userData).UserData
```

A continuación, se muestra un ejemplo del resultado. Tenga en cuenta que los datos de usuario están codificados.

```
PHBvd2Vyc2hlbGw+DQpSZW5hbWUtQ29tcHV0ZXIgLU5ld05hbWUgdXNlci1kYXRhLXRlc3QNCjwvcG93ZXJzaGVsbD4=
```

Para almacenar los datos de usuario codificados en una variable y luego decodificarlos, utilice los siguientes comandos.

```
PS C:\> $UserData_encoded = (Get-EC2InstanceAttribute -InstanceId i-1234567890abcdef0 -Attribute userData).UserData
PS C:\> [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($UserData_encoded))
```

A continuación, se muestra un ejemplo del resultado.

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

**Ejemplo: Cambiar el nombre a la instancia para que coincida con el valor de la etiqueta**  
Puede utilizar el comando [Get-EC2Tag](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Tag.html) para leer el valor de la etiqueta, cambiar el nombre a la instancia durante el primer arranque para que coincida con el valor de la etiqueta y reiniciar. Para ejecutar este comando correctamente, debe tener un rol con permisos `ec2:DescribeTags` adjunto a la instancia, porque la información de etiquetas se recupera mediante una llamada a la API. Para obtener más información acerca de los permisos de configuración mediante roles de IAM, consulte [Asociar un rol de IAM a una instancia](attach-iam-role.md).

------
#### [ IMDSv2 ]

```
<powershell>
    [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri 'http://169.254.169.254/latest/api/token' -UseBasicParsing
    $instanceId = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri 'http://169.254.169.254/latest/meta-data/instance-id' -UseBasicParsing
	$nameValue = (Get-EC2Tag -Filter @{Name="resource-id";Value=$instanceid},@{Name="key";Value="Name"}).Value
	$pattern = "^(?![0-9]{1,15}$)[a-zA-Z0-9-]{1,15}$"
	#Verify Name Value satisfies best practices for Windows hostnames
	If ($nameValue -match $pattern) 
	    {Try
	        {Rename-Computer -NewName $nameValue -Restart -ErrorAction Stop} 
	    Catch
	        {$ErrorMessage = $_.Exception.Message
	        Write-Output "Rename failed: $ErrorMessage"}}
	Else
	    {Throw "Provided name not a valid hostname. Please ensure Name value is between 1 and 15 characters in length and contains only alphanumeric or hyphen characters"}
</powershell>
```

------
#### [ IMDSv1 ]

```
<powershell>
	$instanceId = (Invoke-WebRequest http://169.254.169.254/latest/meta-data/instance-id -UseBasicParsing).content
	$nameValue = (Get-EC2Tag -Filter @{Name="resource-id";Value=$instanceid},@{Name="key";Value="Name"}).Value
	$pattern = "^(?![0-9]{1,15}$)[a-zA-Z0-9-]{1,15}$"
	#Verify Name Value satisfies best practices for Windows hostnames
	If ($nameValue -match $pattern) 
	    {Try
	        {Rename-Computer -NewName $nameValue -Restart -ErrorAction Stop} 
	    Catch
	        {$ErrorMessage = $_.Exception.Message
	        Write-Output "Rename failed: $ErrorMessage"}}
	Else
	    {Throw "Provided name not a valid hostname. Please ensure Name value is between 1 and 15 characters in length and contains only alphanumeric or hyphen characters"}
</powershell>
```

------

También puede cambiar el nombre de la instancia mediante etiquetas en los metadatos de la instancia, si la instancia está configurada para etiquetas de acceso desde los metadatos de instancia. Para obtener más información, consulte [Visualización de etiquetas para las instancias de EC2 mediante los metadatos de la instancia](work-with-tags-in-IMDS.md).

------
#### [ IMDSv2 ]

```
<powershell>
    [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri 'http://169.254.169.254/latest/api/token' -UseBasicParsing
	$nameValue = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri 'http://169.254.169.254/latest/meta-data/tags/instance/Name' -UseBasicParsing
	$pattern = "^(?![0-9]{1,15}$)[a-zA-Z0-9-]{1,15}$"
	#Verify Name Value satisfies best practices for Windows hostnames
	If ($nameValue -match $pattern) 
	    {Try
	        {Rename-Computer -NewName $nameValue -Restart -ErrorAction Stop} 
	    Catch
	        {$ErrorMessage = $_.Exception.Message
	        Write-Output "Rename failed: $ErrorMessage"}}
	Else
	    {Throw "Provided name not a valid hostname. Please ensure Name value is between 1 and 15 characters in length and contains only alphanumeric or hyphen characters"}
</powershell>
```

------
#### [ IMDSv1 ]

```
<powershell>
	$nameValue = Get-EC2InstanceMetadata -Path /tags/instance/Name
	$pattern = "^(?![0-9]{1,15}$)[a-zA-Z0-9-]{1,15}$"
	#Verify Name Value satisfies best practices for Windows hostnames
	If ($nameValue -match $pattern) 
	    {Try
	        {Rename-Computer -NewName $nameValue -Restart -ErrorAction Stop} 
	    Catch
	        {$ErrorMessage = $_.Exception.Message
	        Write-Output "Rename failed: $ErrorMessage"}}
	Else
	    {Throw "Provided name not a valid hostname. Please ensure Name value is between 1 and 15 characters in length and contains only alphanumeric or hyphen characters"}
</powershell>
```

------

# Identificación de las instancias inicializadas en una sola solicitud
<a name="AMI-launch-index-examples"></a>

En este ejemplo se demuestra cómo se pueden usar los datos de usuario y los metadatos de instancia para configurar las instancias de Amazon EC2.

**nota**  
En los ejemplos de esta sección, se utiliza la dirección IPv4 de IMDS: `169.254.169.254`. Si recupera metadatos de instancia para las instancias de EC2 a través de la dirección IPv6, asegúrese de habilitar y utilizar la dirección IPv6 en su lugar: `[fd00:ec2::254]`. La dirección IPv6 de IMDS es compatible con los comandos de IMDSv2. Solo se puede acceder a la dirección IPv6 con [instancias basadas en Nitro](instance-types.md#instance-hypervisor-type) en [subredes compatibles con IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) (de doble pila o solo IPv6).

Alice desea iniciar cuatro instancias de su AMI de base de datos favorita, de modo que la primera sea la instancia original y las tres restantes actúen como réplicas. Al iniciarlas, desea agregar datos de usuario acerca de la estrategia de replicación para cada réplica. Es consciente de que estos datos estarán disponibles para las cuatro instancias, por lo que debe estructurar los datos de usuario de modo que cada instancia pueda reconocer qué partes se aplican a cada una. Lo puede hacer con el valor de metadato de instancia `ami-launch-index`, que será exclusivo para cada instancia. Si ha iniciado más de una instancia al mismo tiempo, `ami-launch-index` indica el orden en el que se ha iniciado la instancia. El valor de la primera instancia iniciada es `0`.

Estos son los datos de usuario que ha creado Alice.

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

Los datos de `replicate-every=1min` definen la configuración de la primera réplica, `replicate-every=5min` define la configuración de la segunda réplica y así sucesivamente. Alice decide facilitar estos datos como una cadena ASCII con un símbolo de barra vertical (`|`) que delimita los datos de las distintas instancias.

Alice inicia cuatro instancias con el comando [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) y especifica los datos de usuario.

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

Una vez iniciadas, todas las instancias tienen una copia de los datos de usuario y los metadatos comunes se muestran aquí:
+ ID de la AMI: ami-0abcdef1234567890
+ ID de reserva: r-1234567890abcabc0
+ Claves públicas: ninguna 
+ Nombre de grupo de seguridad: predeterminado
+ Tipo de instancia: t2.micro

Sin embargo, cada instancia tiene metadatos únicos, tal como se muestra en las tablas siguientes.


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


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


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


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

Alice puede utilizar el valor `ami-launch-index` para determinar la parte de los datos de usuario que se aplican a una instancia en concreto.

1. Se conecta a una de las instancias y recupera `ami-launch-index` de esa instancia para asegurarse de que es una de las réplicas:

------
#### [ IMDSv2 ]

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

   Para los siguientes pasos, las solicitudes de IMDSv2 usan el token almacenado del comando IMDSv2 precedente, siempre y cuando el token no haya caducado.

------
#### [ IMDSv1 ]

   ```
   [ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/ami-launch-index
   2
   ```

------

1. Guarda `ami-launch-index` como variable.

------
#### [ IMDSv2 ]

   ```
   [ec2-user ~]$ ami_launch_index=`curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/ami-launch-index`
   ```

------
#### [ IMDSv1 ]

   ```
   [ec2-user ~]$ ami_launch_index=`curl http://169.254.169.254/latest/meta-data/ami-launch-index`
   ```

------

1. Guarda los datos de usuario como variable.

------
#### [ IMDSv2 ]

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

------
#### [ IMDSv1 ]

   ```
   [ec2-user ~]$ user_data=`curl http://169.254.169.254/latest/user-data`
   ```

------

1. Por último, Alice utiliza el comando **cut** para extraer la parte de los datos de usuario que se aplican a esa instancia.

------
#### [ IMDSv2 ]

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

------
#### [ IMDSv1 ]

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

------