Habilitar tags en metadatos a nivel cuenta en AWS

Mientras trabajaba con una instancia EC2 gestionada por Elastic Beanstalk necesitaba consultar algunos de sus tags desde la propia máquina utilizando EC2 Instance Metadata Service (IMDS). Para ser sincero de esta no me acordaba, por algún motivo pensaba que era algo que venía activado de serie. Por eso he pensado que está bie hablar sobre como Habilitar tags en metadatos a nivel cuenta en AWS.

La idea era evitar una llamada como:

aws ec2 describe-instances ...

y poder consultar localmente los tags de la instancia a través de:

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

Esto tiene varias ventajas:

• No necesito ec2:DescribeInstances.
• No tengo que averiguar qué instancia EC2 corresponde a la máquina actual.
• La consulta se hace localmente contra IMDS.
• El script queda desacoplado de la API de EC2.

El problema

Aunque la instancia EC2 tenía sus tags correctamente configurados, inicialmente estos no estaban disponibles mediante IMDS.

Además, habilitar manualmente Instance metadata tags en una instancia concreta no era suficiente.

En un entorno como por ejemplo, Elastic Beanstalk, las instancias pueden ser reemplazadas en cualquier momento. La siguiente instancia podría volver a arrancar con esta opción deshabilitada.

Necesitaba que fuese el comportamiento por defecto para las nuevas instancias.

Comprobar la configuración actual

AWS permite consultar los valores por defecto de Instance Metadata a nivel de cuenta y región:

aws ec2 get-instance-metadata-defaults \
  --region eu-west-1 \
  --profile aws-profile

Inicialmente obtenía:

{
    "AccountLevel": {
        "ManagedBy": "account"
    }
}

No había ningún valor explícito configurado para InstanceMetadataTags.

Habilitar los tags de metadata a nivel de cuenta

Podemos establecer el comportamiento por defecto para las nuevas instancias de una región:

aws ec2 modify-instance-metadata-defaults \
  --region eu-west-1 \
  --instance-metadata-tags enabled \
  --profile aws-profile

La respuesta:

{
    "Return": true
}

Después podemos volver a comprobar la configuración:

aws ec2 get-instance-metadata-defaults \
  --region eu-west-1 \
  --profile <aws-profile>

Ahora aparece:

{
    "AccountLevel": {
        "InstanceMetadataTags": "enabled",
        "ManagedBy": "account"
    }
}

¿Qué conseguimos con esto?

A partir de ahora, las nuevas instancias EC2 creadas en esa región podrán tener habilitado por defecto el acceso a sus tags mediante IMDS, siempre que una configuración con mayor prioridad, como un Launch Template, no establezca otra cosa.

Desde la instancia podemos obtener primero un token de IMDSv2:

TOKEN=$(curl -sS -X PUT \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" \
  http://169.254.169.254/latest/api/token)

Y listar las claves de los tags disponibles:

curl -sS \
  -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/tags/instance/

Por ejemplo, para obtener el tag Name:

INSTANCE_NAME=$(curl -sS \
  -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/tags/instance/Name)

Todo esto ocurre sin realizar una llamada a la API de EC2.

Aplicación práctica con Elastic Beanstalk

En mi caso concreto esto forma parte de una mejora del proceso de despliegue de WordPress.

Después de cada deployment, un hook postdeploy de Elastic Beanstalk podrá:

Deployment EB
↓
postdeploy
↓
leer metadata de la propia EC2
↓
identificar el entorno
↓
obtener la versión de WordPress realmente desplegada
↓
guardar esa versión en AWS Systems Manager Parameter Store

El objetivo es que Parameter Store represente el estado real del último despliegue exitoso, en lugar de intentar inferirlo mediante ramas, commits o comparaciones en GitHub.

Esto permitirá que futuros workflows comparen:

versión realmente desplegada (SSM) vs versión que queremos desplegar

y tomen decisiones a partir del estado real de la infraestructura.

Un detalle importante

Cambiar los defaults de la cuenta/región está pensado para nuevas instancias. Las instancias EC2 que ya están ejecutándose pueden necesitar que la opción se habilite explícitamente.

También hay que tener en cuenta la precedencia de configuración: si un Launch Template establece explícitamente otra configuración de Instance Metadata, esta puede prevalecer sobre el default configurado a nivel de cuenta.

En entornos gestionados y con reemplazo frecuente de instancias, como Elastic Beanstalk, definir correctamente estos defaults evita depender de cambios manuales sobre EC2 individuales.

Links

• https://www.rubenortiz.es/category/cloud/
• https://repost.aws/knowledge-center/ec2-configure-instance-metadata-tags