• El panel de AWS Systems Manager CloudWatch dejará de estar disponible después del 30 de abril de 2026. Los clientes pueden seguir utilizando la consola de Amazon CloudWatch para ver, crear y administrar sus paneles de Amazon CloudWatch, tal y como lo hacen actualmente. Para obtener más información, consulte la [documentación del panel de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
# Administrador de nodos en entornos híbridos y multinube con Systems Manager
Se puede utilizar AWS Systems Manager para gestionar tanto las instancias de Amazon Elastic Compute Cloud (EC2) como varios tipos de máquinas que no son de EC2. En esta sección se describen las tareas de configuración que la cuenta y los administradores de sistemas realizan para administrar máquinas que no son de EC2 mediante Systems Manager en un entorno *[híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types)*. Una vez que se hayan completado estos pasos, los usuarios que hayan recibido permisos del administrador de la Cuenta de AWS pueden utilizar Systems Manager para configurar y administrar las máquinas que no son de EC2 de la organización.
Cualquier máquina que se haya configurado para su uso con Systems Manager se denomina *nodo administrado*.
**nota**
Puede registrar dispositivos de periferia como nodos administrados mediante los mismos pasos de activación híbrida que se utilizan para otras máquinas que no son de EC2. Estos tipos de dispositivos periféricos incluyen tanto dispositivos de AWS IoT como dispositivos distintos de los dispositivos de AWS IoT. Use el proceso descrito en esta sección para configurar estos tipos de dispositivos periféricos.
Systems Manager también admite dispositivos de borde que utilizan el software AWS IoT Greengrass Core. El proceso de configuración y los requisitos para los dispositivos de núcleo de AWS IoT Greengrass son diferentes de aquellos para los dispositivos AWS IoT y periféricos que no son dispositivos de periferia de AWS. Para obtener información sobre el registro de dispositivos AWS IoT Greengrass para usarlos con Systems Manager, consulte [Administración de dispositivos periféricos con Systems Manager](systems-manager-setting-up-edge-devices.md).
Las máquinas macOS que no son de EC2 no son compatibles con entornos de híbridos y multinube de Systems Manager.
Si tiene previsto utilizar Systems Manager para administrar instancias de Amazon Elastic Compute Cloud (Amazon EC2) o desea utilizar tanto instancias de Amazon EC2 como máquinas que no son de EC2 en un entorno híbrido y multinube, en primer lugar, siga los pasos indicados en [Administrar instancias de EC2 con Systems Manager](systems-manager-setting-up-ec2.md).
Luego de configurar el entorno híbrido y multinube para Systems Manager, puede realizar lo siguiente:
+ Cree una manera uniforme y segura de administrar de forma remota las cargas de trabajo híbridas y multinube de una ubicación con las mismas herramientas o scripts.
+ Centralizar el control de acceso para las acciones que se pueden llevar a cabo en las máquinas mediante AWS Identity and Access Management (IAM).
+ Para centralizar la auditoría de las operaciones realizadas en sus máquinas, consulte la actividad de la API registrada en AWS CloudTrail.
Para obtener información acerca de cómo utilizar CloudTrail para monitorear las acciones de Systems Manager, consulte [Registro de llamadas a la API de AWS Systems Manager con AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ centralizar el monitoreo mediante la configuración de Amazon EventBridge y Amazon Simple Notification Service (Amazon SNS) para que envíen notificaciones sobre la correcta ejecución de los servicios
Para obtener información acerca de cómo utilizar EventBridge para monitorear los eventos de Systems Manager, consulte [Cómo monitorear eventos de Systems Manager con Amazon EventBridge](monitoring-eventbridge-events.md).
**Acerca de los nodos administrados**
Una vez que haya terminado de configurar las máquinas que no son de EC2 para Systems Manager, tal y como se ha indicado en esta sección, las máquinas activadas de manera híbrida se enumerarán en la Consola de administración de AWS y se describirán como *nodos administrados*. En la consola, los ID de los nodos administrados activados de manera híbrida se diferencian de las instancias de Amazon EC2 por el prefijo “mi-”. Los ID de las instancias de Amazon EC2 utilizan el prefijo “i-”.
Un nodo administrado es cualquier máquina configurada para Systems Manager. Anteriormente, todos los nodos administrados se denominaban instancias administradas. El término *instancia* ahora refiere únicamente a las instancias de EC2. El comando [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html) se nombró antes de este cambio de terminología.
Para obtener más información, consulte [Trabajo con nodos administrados](fleet-manager-managed-nodes.md).
**importante**
Le recomendamos encarecidamente que evite utilizar versiones del sistema operativo que hayan llegado al final de su vida útil (EOL). Los proveedores de sistemas operativos, incluso AWS, no suelen proporcionar revisiones de seguridad ni otras actualizaciones para las versiones que han llegado al final de su vida útil. Seguir utilizando un sistema EOL aumenta considerablemente el riesgo de no poder aplicar las actualizaciones, incluidas las correcciones de seguridad, y otros problemas operativos. AWS no prueba la funcionalidad de Systems Manager en las versiones del sistema operativo que han alcanzado el final de su vida.
**Acerca de las capas de instancia**
Systems Manager ofrece un nivel de instancias estándar y un nivel de instancias avanzadas para los nodos administrados que no son de EC2 en el entorno híbrido y multinube. El nivel de instancias estándar le permite registrar un máximo de 1000 máquinas activadas de manera híbrida por Cuenta de AWS por Región de AWS. Si tiene que registrar más de 1000 máquinas que no son de EC2 en una única cuenta y región, utilice el nivel de instancias avanzadas. Las instancias avanzadas también le permiten conectarse a las máquinas que no son de EC2 mediante AWS Systems Manager Session Manager. Session Manager proporciona acceso mediante el intérprete de comandos interactivo de los nodos administrados.
Para obtener más información, consulte [Configuración de los niveles de instancias](fleet-manager-configure-instance-tiers.md).
**Topics**
+ [Creación del rol de servicio de IAM requerido para Systems Manager en entornos híbridos y multinube](hybrid-multicloud-service-role.md)
+ [Creación de una activación híbrida para registrar nodos con Systems Manager](hybrid-activation-managed-nodes.md)
+ [Instalar SSM Agent en nodos de Linux híbridos](hybrid-multicloud-ssm-agent-install-linux.md)
+ [Instalación de SSM Agent en nodos híbridos de Windows Server](hybrid-multicloud-ssm-agent-install-windows.md)
# Creación del rol de servicio de IAM requerido para Systems Manager en entornos híbridos y multinube
Los equipos que no son de EC2 (Amazon Elastic Compute Cloud) que se encuentran en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types) necesitan un rol de servicio de AWS Identity and Access Management (IAM) para comunicarse con el servicio AWS Systems Manager. El rol concede AWS Security Token Service (AWS STS) [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) confianza en el servicio de Systems Manager. Solo tiene que crear un rol de servicio para un entorno híbrido y multinube una vez para cada Cuenta de AWS. Sin embargo, puede elegir crear varios roles de servicio para distintas activaciones híbridas si los equipos del entorno híbrido y multinube requieren permisos distintos.
Los siguientes procedimientos describen cómo crear el rol de servicio necesario mediante la consola de Systems Manager o la herramienta de la línea de comandos que prefiera.
## Uso de Consola de administración de AWS para crear un rol de servicio de IAM para activaciones híbridas de Systems Manager
Utilice el siguiente procedimiento para crear un rol de servicio para activación híbrida. Este procedimiento utiliza la política `AmazonSSMManagedInstanceCore` para la funcionalidad principal de Systems Manager. En función del caso de uso, es posible que tenga que agregar políticas adicionales al rol de servicio para las máquinas en las instalaciones para poder acceder a otras herramientas de Systems Manager o Servicios de AWS. Por ejemplo, sin acceso a los buckets de Amazon Simple Storage Service (Amazon S3) requeridos administrados por AWS, las operaciones de aplicación de revisiones de Patch Manager fallan.
**Para crear un rol de servicio de (consola)**
1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En el panel de navegación, seleccione **Roles** y luego seleccione **Crear rol**.
1. En **Select trusted entity** (Seleccionar entidad de confianza), realice las siguientes elecciones:
1. En **Tipo de entidad de confianza**, elija **Servicio de AWS**.
1. En **Casos de uso de otros Servicios de AWS**, elija **Systems Manager**.
1. Elija **Systems Manager**.
La siguiente imagen resalta la ubicación de la opción Systems Manager.
![\[Systems Manager es una de las opciones de Caso de uso.\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/iam_use_cases_for_MWs.png)
1. Elija **Siguiente**.
1. En la página **Agregar permisos**, haga lo siguiente:
+ Utilice el campo **Search** (Buscar) para localizar la política **AmazonSSMManagedInstanceCore**. Seleccione la casilla de verificación situada junto a su nombre, como se muestra en la siguiente ilustración.
![\[La casilla de verificación está seleccionada en la fila AmazonSSMManagedInstanceCore.\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/setup-instance-profile-2.png)
**nota**
La consola conserva la selección aunque busque otras políticas.
+ Si ha creado una política de bucket de S3 personalizada en el procedimiento [(Opcional) Crear una política personalizada para el acceso al bucket de S3](setup-instance-permissions.md#instance-profile-custom-s3-policy), búsquela y seleccione la casilla de verificación situada junto a su nombre.
+ Si tiene previsto unir equipos que no sean de EC2 a una instancia de Active Directory administrada por Directory Service, busque **AmazonSSMDirectoryServiceAccess** y seleccione la casilla de verificación situada junto a su nombre.
+ Si tiene previsto utilizar EventBridge o los Registros de CloudWatch para administrar o supervisar el nodo administrado, busque **CloudWatchAgentServerPolicy** y seleccione la casilla de verificación situada junto a su nombre.
1. Elija **Siguiente**.
1. En **Nombre del rol**, ingrese un nombre para el rol de servidor de IAM nuevo, por ejemplo, **SSMServerRole**.
**nota**
Anote el nombre del rol. Elegirá este rol cuando registre equipos nuevos que desee administrar mediante Systems Manager.
1. (Opcional) En **Descripción**, actualice la descripción de este rol de servidor de IAM.
1. (Opcional) En **Tags** (Etiquetas), agregue uno o varios pares de valor etiqueta-clave para organizar, realizar un seguimiento o controlar el acceso a este rol.
1. Elija **Create role**. El sistema le devuelve a la página **Roles**.
## Uso de AWS CLI para crear un rol de servicio de IAM para activaciones híbridas de Systems Manager
Utilice el siguiente procedimiento para crear un rol de servicio para activación híbrida. Este procedimiento utiliza la política `AmazonSSMManagedInstanceCore` de la funcionalidad principal de Systems Manager. En función del caso de uso, es posible que tenga que agregar políticas adicionales al rol de servicio para las máquinas que no sean de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types) para poder acceder a otras herramientas u otros Servicios de AWS.
**Requisito de política de bucket de S3**
Si cualquiera de los siguientes casos es correcto, debe crear una política de permiso de IAM personalizada para los buckets de Amazon Simple Storage Service (Amazon S3) antes de completar este procedimiento:
+ **Caso 1**: está utilizando un punto de conexión de VPC para conectar de forma privada su VPC a Servicios de AWS y servicios de punto de conexión de VPC con tecnología de AWS PrivateLink.
+ **Caso 2**: tiene previsto utilizar un bucket de Amazon S3 que ha creado como parte de sus operaciones de Systems Manager para, por ejemplo, almacenar salidas de comandos de Run Command o sesiones de Session Manager en un bucket de S3. Antes de continuar, siga los pasos en [Creación de una política de bucket de S3 personalizada para un perfil de instancias](setup-instance-permissions.md#instance-profile-custom-s3-policy). La información acerca de las políticas del bucket de S3 que aparece en este tema también se aplica a su rol de servicio.
------
#### [ AWS CLI ]
**Para crear un rol de servicio de IAM para un entorno híbrido y multinube (AWS CLI)**
1. Si aún no lo ha hecho, instale y configure la AWS Command Line Interface (AWS CLI).
Para obtener más información, consulte [Instalación o actualización de la última versión de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. En el equipo local, cree un archivo de texto con un nombre como `SSMService-Trust.json` con la siguiente política de confianza. Asegúrese de guardar el archivo con la extensión `.json`. Asegúrese de especificar la Cuenta de AWS y la Región de AWS en el ARN en el que creó la activación híbrida. Reemplace los *valores del marcador de posición* de los campos de ID de cuenta y región con su propia información.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"",
"Effect":"Allow",
"Principal":{
"Service":"ssm.amazonaws.com"
},
"Action":"sts:AssumeRole",
"Condition":{
"StringEquals":{
"aws:SourceAccount":"123456789012"
},
"ArnEquals":{
"aws:SourceArn":"arn:aws:ssm:us-east-1:111122223333:*"
}
}
}
]
}
```
------
1. Abra la AWS CLI, y en el directorio en el que creó el archivo JSON, ejecute el comando [create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) para crear el rol de servicio. Este ejemplo crea un rol llamado `SSMServiceRole`. Puede elegir otro nombre si lo prefiere.
------
#### [ Linux & macOS ]
```
aws iam create-role \
--role-name SSMServiceRole \
--assume-role-policy-document file://SSMService-Trust.json
```
------
#### [ Windows ]
```
aws iam create-role ^
--role-name SSMServiceRole ^
--assume-role-policy-document file://SSMService-Trust.json
```
------
1. Ejecute el comando [attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) de la siguiente forma para permitir que la función de servicio que acaba de crear genere un token de sesión. El token de sesión concede permiso al nodo administrado para ejecutar comandos mediante Systems Manager.
**nota**
Las políticas que agrega a un perfil de servicio para nodos administrados en un entorno híbrido y multinube son las mismas políticas utilizadas para crear un perfil de instancia para instancias de Amazon Elastic Compute Cloud (Amazon EC2). Para obtener más información sobre las políticas de AWS utilizadas en los siguientes comandos, consulte [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md).
(Obligatorio) Ejecute el siguiente comando para permitir que un nodo administrado utilice la funcionalidad principal del servicio de AWS Systems Manager.
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
------
Si ha creado una política de bucket de S3 personalizada para su rol de servicio, ejecute el siguiente comando para permitir el acceso de AWS Systems Manager Agent (SSM Agent) a los buckets que especificó en la política. Sustituya el *account-id* y el *amzn-s3-demo-bucket* con el ID de su Cuenta de AWS y el nombre de su bucket.
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::account-id:policy/amzn-s3-demo-bucket
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::account-id:policy/amzn-s3-demo-bucket
```
------
(Opcional) Ejecute el siguiente comando para permitir a SSM Agent el acceso a Directory Service en su nombre para las solicitudes de unión al dominio por parte del nodo administrado. El rol de servicio solo necesita esta política si une los nodos a un directorio de Microsoft AD.
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
------
(Opcional) Ejecute el siguiente comando para permitir que el agente de CloudWatch se ejecute en los nodos administrados. Este comando permite la lectura de información en un nodo y su escritura en CloudWatch. Su perfil de servicio solo precisa de esta política si hace uso de servicios, como Amazon EventBridge o Registros de Amazon CloudWatch.
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
------
#### [ Tools for PowerShell ]
**Para crear un rol de servicio de IAM para un entorno híbrido y multinube (AWS Tools for Windows PowerShell)**
1. Instale y configure Herramientas de AWS para PowerShell (Herramientas para Windows PowerShell), si aún no lo ha hecho.
Para obtener más información, consulte [Instalación de Herramientas de AWS para PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. En el equipo local, cree un archivo de texto con un nombre como `SSMService-Trust.json` con la siguiente política de confianza. Asegúrese de guardar el archivo con la extensión `.json`. Asegúrese de especificar la Cuenta de AWS y la Región de AWS en el ARN en el que creó la activación híbrida.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:ssm:us-east-1:123456789012:*"
}
}
}
]
}
```
------
1. Abra PowerShell en modo administrativo y, en el directorio en el que creó el archivo JSON, ejecute [New-IAMRole](https://docs.aws.amazon.com//powershell/latest/reference/items/Register-IAMRolePolicy.html) como se indica a continuación para crear una función de servicio. Este ejemplo crea un rol llamado `SSMServiceRole`. Puede elegir otro nombre si lo prefiere.
```
New-IAMRole `
-RoleName SSMServiceRole `
-AssumeRolePolicyDocument (Get-Content -raw SSMService-Trust.json)
```
1. Utilice [Register-IAMRolePolicy](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-IAMRolePolicy.html) de la siguiente forma para permitir que el rol de servicio que ha creado genere un token de sesión. El token de sesión concede permiso al nodo administrado para ejecutar comandos mediante Systems Manager.
**nota**
Las políticas que agrega a un perfil de servicio para los nodos administrados en un entorno híbrido y multinube son las mismas políticas utilizadas para crear un perfil de instancia para instancias de EC2. Para obtener más información sobre las políticas de AWS utilizadas en los siguientes comandos, consulte [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md).
(Obligatorio) Ejecute el siguiente comando para permitir que un nodo administrado utilice la funcionalidad principal del servicio de AWS Systems Manager.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
Si ha creado una política de bucket de S3 personalizada para su rol de servicio, ejecute el siguiente comando para permitir el acceso de SSM Agent a los buckets que especificó en la política. Sustituya el *account-id* y el *my-bucket-policy-name* con el ID de su Cuenta de AWS y el nombre de su bucket.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::account-id:policy/my-bucket-policy-name
```
(Opcional) Ejecute el siguiente comando para permitir a SSM Agent el acceso a Directory Service en su nombre para las solicitudes de unión al dominio por parte del nodo administrado. El rol de servidor solo necesita esta política si une los nodos a un directorio de Microsoft AD.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
(Opcional) Ejecute el siguiente comando para permitir que el agente de CloudWatch se ejecute en los nodos administrados. Este comando permite la lectura de información en un nodo y su escritura en CloudWatch. Su perfil de servicio solo precisa de esta política si hace uso de servicios, como Amazon EventBridge o Registros de Amazon CloudWatch.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
------
Continuar con [Creación de una activación híbrida para registrar nodos con Systems Manager](hybrid-activation-managed-nodes.md).
# Creación de una activación híbrida para registrar nodos con Systems Manager
Para configurar equipos distintos a las instancias de Amazon Elastic Compute Cloud (EC2) como nodos administrados para un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types), cree y aplique una *activación híbrida*. Después de completar correctamente la activación, recibirá *inmediatamente* un código y un ID de activación en la parte superior de la página de la consola. Puede especificar esta combinación de código e ID cuando instale AWS Systems Manager SSM Agent en equipos que no sean de EC2 para su entorno híbrido y multinube. La combinación de código e ID proporciona un acceso seguro al servicio de Systems Manager desde sus nodos administrados.
**importante**
Systems Manager regresa inmediatamente el código e ID de activación a la consola o la ventana de comandos, en función de cómo haya creado la activación. Copie esta información y guárdela en un lugar seguro. Si sale de la consola o cierra la ventana de comandos, podría perder esta información. Si la pierde, debe crear una nueva activación.
**Acerca del vencimiento de la activación**
Un *vencimiento de la activación* es un intervalo de tiempo en el que se pueden registrar máquinas locales en Systems Manager. Una activación que ha vencido no tiene ningún impacto en los servidores ni en las máquinas virtuales que haya registrado en Systems Manager. Si una activación ha vencido, no se podrán registrar más servidores ni máquinas virtuales en Systems Manager mediante esa activación específica. Solo es necesario crear una nueva.
Cada servidor y máquina virtual en las instalaciones que ya haya registrado permanecen registrados como un nodo administrado de Systems Manager hasta que anule el registro explícitamente. Puede anular el registro de un nodo administrado que no sea de EC2 de las siguientes maneras:
+ Utilice la pestaña **Nodos administrados** en Fleet Manager en la consola de Systems Manager.
+ Utilice el comando de la AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html).
+ Utilice la acción de la API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html).
Para obtener más información, consulte los temas siguientes:
+ [Anulación del registro y nuevo registro de un nodo administrado (Linux)](hybrid-multicloud-ssm-agent-install-linux.md#systems-manager-install-managed-linux-deregister-reregister)
+ [Anulación del registro y nuevo registro de un nodo administrado (Windows Server)](hybrid-multicloud-ssm-agent-install-windows.md#systems-manager-install-managed-win-deregister-reregister)
**Acerca de los nodos administrados**
Un nodo administrado es cualquier máquina configurada para AWS Systems Manager. AWS Systems Manager admite instancias de Amazon Elastic Compute Cloud (Amazon EC2), dispositivos periféricos y servidores o VM en las instalaciones, incluidas VM de otros entornos en la nube. Anteriormente, todos los nodos administrados se denominaban instancias administradas. El término *instancia* ahora refiere únicamente a las instancias de EC2. El comando [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html) se nombró antes de este cambio de terminología.
**Acerca de las etiquetas de activación**
Si crea una activación mediante la AWS Command Line Interface (AWS CLI) o las AWS Tools for Windows PowerShell, puede especificar etiquetas. Las etiquetas son metadatos opcionales que usted asigna a un recurso. Las etiquetas permiten clasificar los recursos de diversas maneras, por ejemplo, según la finalidad, el propietario o el entorno. Este es un ejemplo de un comando de la AWS CLI que se puede ejecutar en el este de EE. UU. (Ohio) en un equipo Linux local que incluye etiquetas opcionales.
```
aws ssm create-activation \
--default-instance-name MyWebServers \
--description "Activation for Finance department webservers" \
--iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances \
--registration-limit 10 \
--region us-east-2 \
--tags "Key=Department,Value=Finance"
```
Si especifica etiquetas al crear una activación, esas etiquetas se asignarán automáticamente a sus nodos administrados cuando los active.
No se pueden añadir ni eliminar etiquetas de una activación existente. Si no desea asignar etiquetas automáticamente a sus servidores y máquinas virtuales locales mediante una activación, puede añadirles etiquetas más adelante. En concreto, puede etiquetar los servidores locales y las máquinas virtuales después de que se conecten a Systems Manager por primera vez. Después de conectarse, se les asigna un ID de nodo administrado que se muestra en la consola de Systems Manager con un ID que lleva el prefijo “mi-”.
**nota**
No puede asignar etiquetas a una activación si se crea mediante la consola de Systems Manager. Para crearla, utilice la AWS CLI o Tools for Windows PowerShell.
Si ya no desea administrar un servidor local o una máquina virtual mediante Systems Manager, puede anular el registro. Para obtener más información, consulte [Anulación del registro de nodos administrados en un entorno híbrido y multinube](fleet-manager-deregister-hybrid-nodes.md).
**Topics**
+ [Uso de la Consola de administración de AWS para crear una activación para registrar nodos administrados con Systems Manager](#create-managed-node-activation-console)
+ [Uso de la línea de comandos para crear una activación para registrar nodos administrados con Systems Manager](#create-managed-node-activation-command-line)
## Uso de la Consola de administración de AWS para crear una activación para registrar nodos administrados con Systems Manager
**Para crear una activación de nodo administrado**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Hybrid Activations** (Activaciones híbridas).
1. Elija **Create activation (Crear activación)**.
-o bien-
Si va a acceder a **Hybrid Activations** (Activaciones híbridas) por primera vez en la Región de AWS actual, elija**Create an Activation** (Crear una activación).
1. (Opcional) En el campo **Activation description** (Descripción de la activación), ingrese una descripción para esta activación. Le recomendamos que ingrese una descripción si tiene previsto activar un gran número de servidores y máquinas virtuales.
1. En **Instance limit** (Límite de instancias), especifique el número total de nodos que desea registrar con AWS como parte de esta activación. El valor predeterminado es 1 instancia.
1. En **IAM role** (Rol de IAM), elija una opción de rol de servicio que permita que los servidores y las máquinas virtuales se comuniquen con AWS Systems Manager en la nube:
+ **Opción 1**: elija **Use the default role created by the system** (Utilizar el rol predeterminado creado por el sistema) para utilizar un rol y una política administrada proporcionada por AWS.
+ **Opción 2**: elija **Select an existing custom IAM role that has the required permissions** (Seleccionar un rol de IAM personalizado existente que tenga los permisos requeridos) para utilizar el rol personalizado opcional que ha creado anteriormente. Este rol debe tener una política de relación de confianza que especifique `"Service": "ssm.amazonaws.com"`. Si su rol de IAM no especifica este principio en una política de relación de confianza, recibirá el siguiente error:
```
An error occurred (ValidationException) when calling the CreateActivation
operation: Not existing role: arn:aws:iam:::role/SSMRole
```
Para obtener más información sobre la creación de este rol, consulte [Creación del rol de servicio de IAM requerido para Systems Manager en entornos híbridos y multinube](hybrid-multicloud-service-role.md).
1. En **Activation expiry date** (Fecha de vencimiento de la activación), especifique una fecha de vencimiento para la activación. La fecha de vencimiento debe ser en el futuro y no más de 30 días en el futuro. El valor de predeterminado es 24 horas.
**nota**
Si desea registrar nodos administrados adicionales después de la fecha de vencimiento, debe crear una nueva activación. La fecha de vencimiento no afecta los nodos registrados y en ejecución.
1. (Opcional) En el campo **Default instance name** (Nombre de instancia predeterminado), especifique un valor de nombre identificativo para mostrarlo en todos los nodos administrados asociados a esta activación.
1. Elija **Create activation (Crear activación)**. Systems Manager regresa inmediatamente el ID y el código de activación a la consola.
## Uso de la línea de comandos para crear una activación para registrar nodos administrados con Systems Manager
En el siguiente procedimiento se describe cómo utilizar la AWS Command Line Interface (AWS CLI) (en Linux o Windows Server) o Herramientas de AWS para PowerShell para crear una activación de nodo administrado.
**Para crear una activación**
1. Si aún no lo ha hecho, instale y configure la AWS CLI o las Herramientas de AWS para PowerShell.
Para obtener información, consulte [Instalación o actualización de la última versión de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e [Instalación de Herramientas de AWS para PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Ejecute el siguiente comando para crear una activación.
**nota**
En el siguiente comando, reemplace *region* con su propia información. Para ver una lista de los valores de *regiones* admitidos, consulte la columna **Región** en [Puntos de conexión de servicio de Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) en la *Referencia general de Amazon Web Services*.
El rol que especifique para el parámetro *iam-role* debe tener una política de relación de confianza que especifique `"Service": "ssm.amazonaws.com"`. Si su rol de AWS Identity and Access Management (IAM) no especifica este principio en una política de relación de confianza, recibirá el siguiente error:
```
An error occurred (ValidationException) when calling the CreateActivation
operation: Not existing role: arn:aws:iam:::role/SSMRole
```
Para obtener más información sobre la creación de este rol, consulte [Creación del rol de servicio de IAM requerido para Systems Manager en entornos híbridos y multinube](hybrid-multicloud-service-role.md).
Para `--expiration-date`, proporcione una fecha en formato de marca temporal, como `"2021-07-07T00:00:00"`, para cuando el código de activación llegue a su vencimiento. Puede especificar una fecha con hasta 30 días de antelación. Si no proporciona una fecha de vencimiento, el código de activación se vencerá en 24 horas.
------
#### [ Linux & macOS ]
```
aws ssm create-activation \
--default-instance-name name \
--iam-role iam-service-role-name \
--registration-limit number-of-managed-instances \
--region region \
--expiration-date "timestamp" \\
--tags "Key=key-name-1,Value=key-value-1" "Key=key-name-2,Value=key-value-2"
```
------
#### [ Windows ]
```
aws ssm create-activation ^
--default-instance-name name ^
--iam-role iam-service-role-name ^
--registration-limit number-of-managed-instances ^
--region region ^
--expiration-date "timestamp" ^
--tags "Key=key-name-1,Value=key-value-1" "Key=key-name-2,Value=key-value-2"
```
------
#### [ PowerShell ]
```
New-SSMActivation -DefaultInstanceName name `
-IamRole iam-service-role-name `
-RegistrationLimit number-of-managed-instances `
–Region region `
-ExpirationDate "timestamp" `
-Tag @{"Key"="key-name-1";"Value"="key-value-1"},@{"Key"="key-name-2";"Value"="key-value-2"}
```
------
A continuación se muestra un ejemplo.
------
#### [ Linux & macOS ]
```
aws ssm create-activation \
--default-instance-name MyWebServers \
--iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances \
--registration-limit 10 \
--region us-east-2 \
--expiration-date "2021-07-07T00:00:00" \
--tags "Key=Environment,Value=Production" "Key=Department,Value=Finance"
```
------
#### [ Windows ]
```
aws ssm create-activation ^
--default-instance-name MyWebServers ^
--iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances ^
--registration-limit 10 ^
--region us-east-2 ^
--expiration-date "2021-07-07T00:00:00" ^
--tags "Key=Environment,Value=Production" "Key=Department,Value=Finance"
```
------
#### [ PowerShell ]
```
New-SSMActivation -DefaultInstanceName MyWebServers `
-IamRole service-role/AmazonEC2RunCommandRoleForManagedInstances `
-RegistrationLimit 10 `
–Region us-east-2 `
-ExpirationDate "2021-07-07T00:00:00" `
-Tag @{"Key"="Environment";"Value"="Production"},@{"Key"="Department";"Value"="Finance"}
```
------
Si la activación se crea correctamente, el sistema devuelve inmediatamente un código y un ID de activación.
# Instalar SSM Agent en nodos de Linux híbridos
En este tema se describe cómo instalar AWS Systems Manager SSM Agent en máquinas Linux que no son EC2 (Amazon Elastic Compute Cloud) en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types). Para obtener información acerca de la instalación de SSM Agent en instancias de EC2 para Linux, consulte [Instalación y desinstalación manual de SSM Agent en instancias de EC2 para Linux](manually-install-ssm-agent-linux.md).
Antes de comenzar, localice el código y el ID de activación que se generaron durante el proceso de activación híbrida, tal y como se describe en [Creación de una activación híbrida para registrar nodos con Systems Manager](hybrid-activation-managed-nodes.md). Deberá especificar el código y el ID en el siguiente procedimiento.
**Instalación de SSM Agent en máquinas que no son EC2 en un entorno híbrido y multinube**
1. Inicie sesión en un servidor o una máquina virtual del entorno híbrido y multinube.
1. Si utiliza un proxy HTTP o HTTPS, debe establecer las variables de entorno `http_proxy` o `https_proxy` en la sesión de shell actual. Si no utiliza un proxy, puede omitir este paso.
Ingrese los siguientes comandos en la línea de comandos en el caso de un servidor proxy HTTP:
```
export http_proxy=http://hostname:port
export https_proxy=http://hostname:port
```
Ingrese los siguientes comandos en la línea de comandos en el caso de un servidor proxy HTTPS:
```
export http_proxy=http://hostname:port
export https_proxy=https://hostname:port
```
1. Copie y pegue uno de los siguientes bloques de comandos en SSH. Reemplace los valores de marcador por el código y el ID de activación que se generaron durante el proceso de activación híbrido y por el identificador de la Región de AWS que desea descargar SSM Agent, y luego presione `Enter`.
**importante**
Tenga en cuenta los siguientes detalles importantes:
El uso de `ssm-setup-cli` en instalaciones que no son de EC2 maximiza la seguridad de la instalación y la configuración de Systems Manager.
`sudo` no es necesario si es un usuario raíz.
Descarga `ssm-setup-cli` desde Región de AWS en el mismo lugar donde se creó la activación híbrida.
`ssm-setup-cli` admite una opción `manifest-url` que determina la fuente desde la que se descarga el agente. No especifique un valor para esta opción a menos que la organización lo requiera.
Utilice únicamente el enlace de descarga proporcionado para `ssm-setup-cli` cuando registre instancias. No debe almacenar `ssm-setup-cli` por separado para su uso futuro.
Puede utilizar el script que se proporciona [aquí](https://github.com/aws/amazon-ssm-agent/blob/mainline/Tools/src/setupcli_data_integrity_linux.sh) para validar la firma de `ssm-setup-cli`.
*region* representa el identificador de Región de AWS compatible con AWS Systems Manager, como `us-east-2` para la región EE. UU. Este (Ohio). Para ver una lista de los valores de *regiones* admitidos, consulte la columna **Región** en [Puntos de conexión de servicio de Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) en la *Referencia general de Amazon Web Services*.
Además, `ssm-setup-cli` incluye las siguientes opciones:
+ `version`: los valores válidos son `latest` y `stable`.
+ `downgrade`: permite el cambio del SSM Agent a una versión anterior. Especifique `true` si desea instalar una versión anterior del agente.
+ `skip-signature-validation`: omite la validación de la firma durante la descarga e instalación del agente.
## Amazon Linux 2, RHEL 7.x y Oracle Linux
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
## RHEL 8.x
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
## Debian Server
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
## Ubuntu Server
+ **Uso de paquetes .deb**
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
+ **Uso de paquetes Snap**
No es necesario especificar una URL para la descarga, ya que el comando `snap` descarga automáticamente el agente en la [tienda de aplicaciones de Snap](https://snapcraft.io/amazon-ssm-agent) en [https://snapcraft.io](https://snapcraft.io).
En Ubuntu Server 20.04, 18.04 y 16.04 LTS, los archivos del instalador de SSM Agent, incluidos los archivos binarios y de configuración del agente, se almacenan en el siguiente directorio: `/snap/amazon-ssm-agent/current/`. Si realiza cambios en cualquiera de los archivos de configuración de este directorio, debe copiar estos archivos desde el directorio `/snap` al directorio `/etc/amazon/ssm/`. Los archivos de registros y bibliotecas no han cambiado (`/var/lib/amazon/ssm`, `/var/log/amazon/ssm`).
```
sudo snap install amazon-ssm-agent --classic
sudo systemctl stop snap.amazon-ssm-agent.amazon-ssm-agent.service
sudo /snap/amazon-ssm-agent/current/amazon-ssm-agent -register -code "activation-code" -id "activation-id" -region "region"
sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service
```
**importante**
El canal *candidato* en el almacén de Snap contiene la versión más reciente de SSM Agent; no el canal estable. Si desea realizar un seguimiento de información de la versión de SSM Agent en el canal candidato, ejecute el siguiente comando en los nodos administrados de 64 bits de Ubuntu Server 18.04 y 16.04 LTS.
```
sudo snap switch --channel=candidate amazon-ssm-agent
```
El comando se descarga e instala SSM Agent en la máquina activada de manera híbrida en su entorno híbrido y multinube. El comando detiene SSM Agent y, a continuación, registra la máquina virtual en el servicio de Systems Manager. El equipo ahora es un nodo administrado. Las instancias de Amazon EC2 configuradas para Systems Manager también son nodos administrados. Sin embargo, en la consola de Systems Manager, sus nodos activados de manera híbrida se distinguen de las instancias de Amazon EC2 con el prefijo “mi-”.
Continuar con [Instalación de SSM Agent en nodos híbridos de Windows Server](hybrid-multicloud-ssm-agent-install-windows.md).
## Configuración de la rotación automática de clave privada
Para reforzar su posición de seguridad, puede configurar AWS Systems Manager Agent (SSM Agent) para rotar automáticamente la clave privada del entorno híbrido y multinube. Puede acceder a esta característica mediante la versión 3.0.1031.0 o posterior de SSM Agent. Active esta característica siguiendo el procedimiento que se describe a continuación.
**Para configurar SSM Agent para rotar la clave privada del entorno híbrido y multinube**
1. Vaya a `/etc/amazon/ssm/` en un equipo Linux o a `C:\Program Files\Amazon\SSM` para un equipo Windows.
1. Copie los contenidos de `amazon-ssm-agent.json.template` en un archivo nuevo denominado `amazon-ssm-agent.json`. Guarde `amazon-ssm-agent.json` en el mismo directorio donde se encuentra `amazon-ssm-agent.json.template`.
1. Encuentre`Profile`, `KeyAutoRotateDays`. Ingrese el número de días que desea entre las rotaciones automáticas de clave privada.
1. Reinicie SSM Agent.
Cada vez que cambie la configuración, reinicie SSM Agent.
Puede personalizar otras características de SSM Agent mediante el mismo procedimiento. Para ver la lista actualizada de las propiedades de configuración disponibles y sus valores predeterminados, consulte [Definiciones de propiedades de configuración](https://github.com/aws/amazon-ssm-agent#config-property-definitions).
## Anulación del registro y nuevo registro de un nodo administrado (Linux)
Puede anular el registro de un nodo administrado activado de manera híbrida mediante una llamada a la operación de la API [DeregisterManagedInstance](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html) desde la AWS CLI o desde Herramientas para Windows PowerShell. A continuación, se muestra un ejemplo de comando de la CLI:
`aws ssm deregister-managed-instance --instance-id "mi-1234567890"`
Para eliminar el resto de la información de registro del agente, elimine la clave `IdentityConsumptionOrder` del archivo `amazon-ssm-agent.json`. A continuación, en función del tipo de instalación, ejecute uno de los siguientes comandos.
En nodos de Ubuntu Server en los que se instaló SSM Agent mediante paquetes de Snap:
```
sudo /snap/amazon-ssm-agent/current/amazon-ssm-agent -register -clear
```
En todas las demás instalaciones de Linux:
```
amazon-ssm-agent -register -clear
```
**nota**
Puede volver a registrar un servidor en las instalaciones, un dispositivo periférico o una máquina virtual con el mismo código e ID de activación siempre que no haya alcanzado el límite de instancias para el código e ID de activación designados. Para comprobar el límite de instancias de un código y un ID de activación, llame a la API [describe-activations](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-activations.html) mediante la AWS CLI. Tras ejecutar el comando, compruebe que el valor de `RegistrationCount` no sea superior a `RegistrationLimit`. Si es así, debe utilizar un código de activación y un ID diferentes.
**Para volver a registrar un nodo administrado en una máquina que no es de EC2 Linux**
1. Conéctese a su máquina.
1. Ejecute el siguiente comando. Asegúrese de sustituir los valores de marcador por el código y el ID de activación que se generan cuando crea una activación de nodo administrado y por el identificador de la región de la que desea descargar el SSM Agent.
```
echo "yes" | sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region
```
## Solución de problemas de instalación de SSM Agent en máquinas Linux que no son de EC2
Utilice la siguiente información como ayuda para solucionar problemas de instalación de SSM Agent en máquinas Linux activadas de manera híbrida en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types).
### Recibe el error DeliveryTimedOut
**Problema**: cuando se configura una máquina en una Cuenta de AWS como un nodo administrado para una Cuenta de AWS separada, recibe `DeliveryTimedOut` después de ejecutar los comandos para instalar SSM Agent en la máquina de destino.
**Solución**: `DeliveryTimedOut` es el código de respuesta esperado para este escenario. El comando para instalar SSM Agent en el nodo de destino cambia el ID de nodo del nodo de origen. Debido a que el ID de nodo ha cambiado, el nodo de origen no puede responder al nodo de destino que el comando falló, se completó o agotó el tiempo de espera durante la ejecución.
### No se pueden cargar las asociaciones de nodos
**Problema**: después de ejecutar los comandos de instalación, verá el siguiente error en los registros de errores de SSM Agent:
`Unable to load instance associations, unable to retrieve associations unable to retrieve associations error occurred in RequestManagedInstanceRoleToken: MachineFingerprintDoesNotMatch: Fingerprint doesn't match`
Se muestra este error cuando el ID del equipo no persiste después de su reinicio.
**Solución**: para solucionar este problema, ejecute el siguiente comando. Este comando obliga a que el ID del equipo persista después de su reinicio.
```
umount /etc/machine-id
systemd-machine-id-setup
```
# Instalación de SSM Agent en nodos híbridos de Windows Server
En este tema se describe cómo instalar AWS Systems Manager SSM Agent en equipos Windows Server para un [entorno híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types). Para obtener información acerca de la instalación de SSM Agent en instancias de EC2 para Windows Server, consulte [Cómo instalar y desinstalar de forma manual SSM Agent en instancias de EC2 para Windows Server](manually-install-ssm-agent-windows.md).
Antes de comenzar, localice el código y el ID de activación que se generaron durante el proceso de activación híbrida, tal y como se describe en [Creación de una activación híbrida para registrar nodos con Systems Manager](hybrid-activation-managed-nodes.md). Deberá especificar el código y el ID en el siguiente procedimiento.
**Instalación de SSM Agent en equipos Windows Server que no sean de EC2 en un entorno híbrido y multinube**
1. Inicie sesión en un servidor o una máquina virtual del entorno híbrido y multinube.
1. Si utiliza un proxy HTTP o HTTPS, debe establecer las variables de entorno `http_proxy` o `https_proxy` en la sesión de shell actual. Si no utiliza un proxy, puede omitir este paso.
Para un servidor proxy HTTP, configure esta variable:
```
http_proxy=http://hostname:port
https_proxy=http://hostname:port
```
Para un servidor proxy HTTPS, configure esta variable:
```
http_proxy=http://hostname:port
https_proxy=https://hostname:port
```
Para PowerShell, configure los ajustes del proxy de WinInet:
```
[System.Net.WebRequest]::DefaultWebProxy
$proxyServer = "http://hostname:port"
$proxyBypass = "169.254.169.254"
$WebProxy = New-Object System.Net.WebProxy($proxyServer,$true,$proxyBypass)
[System.Net.WebRequest]::DefaultWebProxy = $WebProxy
```
**nota**
Se requiere la configuración de proxy de WinInet para las operaciones de PowerShell. Para obtener más información, consulte [SSM AgentConfiguración del proxy de y servicios de Systems Manager](configure-proxy-ssm-agent-windows.md#ssm-agent-proxy-services).
1. Abra Windows PowerShell en modo (administrativo) con permisos elevados.
1. Copie y pegue el siguiente bloque de comandos en Windows PowerShell. Reemplace cada *example resource placeholder* con su propia información. Por ejemplo, el código de activación y el ID de activación generados cuando se crea una activación híbrida y con el identificador de la Región de AWS desde la que desea descargar SSM Agent.
**importante**
Tenga en cuenta los siguientes detalles importantes:
El uso de `ssm-setup-cli` en instalaciones que no son de EC2 maximiza la seguridad de la instalación y la configuración de Systems Manager.
`ssm-setup-cli` admite una opción `manifest-url` que determina la fuente desde la que se descarga el agente. No especifique un valor para esta opción a menos que la organización lo requiera.
Puede utilizar el script que se proporciona [aquí](https://github.com/aws/amazon-ssm-agent/blob/mainline/Tools/src/setupcli_data_integrity_windows.ps1) para validar la firma de `ssm-setup-cli`.
Utilice únicamente el enlace de descarga proporcionado para `ssm-setup-cli` cuando registre instancias. No debe almacenar `ssm-setup-cli` por separado para su uso futuro.
*region* representa el identificador de Región de AWS compatible con AWS Systems Manager, como `us-east-2` para la región EE. UU. Este (Ohio). Para ver una lista de los valores de *regiones* admitidos, consulte la columna **Región** en [Puntos de conexión de servicio de Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) en la *Referencia general de Amazon Web Services*.
Además, `ssm-setup-cli` incluye las siguientes opciones:
+ `version`: los valores válidos son `latest` y `stable`.
+ `downgrade`: revierte el agente a una versión anterior.
+ `skip-signature-validation`: omite la validación de la firma durante la descarga e instalación del agente.
------
#### [ 64-bit ]
```
[System.Net.ServicePointManager]::SecurityProtocol = 'TLS12'
$code = "activation-code"
$id = "activation-id"
$region = "us-east-1"
$dir = $env:TEMP + "\ssm"
New-Item -ItemType directory -Path $dir -Force
cd $dir
(New-Object System.Net.WebClient).DownloadFile("https://amazon-ssm-$region.s3.$region.amazonaws.com/latest/windows_amd64/ssm-setup-cli.exe", $dir + "\ssm-setup-cli.exe")
./ssm-setup-cli.exe -register -activation-code="$code" -activation-id="$id" -region="$region"
Get-Content ($env:ProgramData + "\Amazon\SSM\InstanceData\registration")
Get-Service -Name "AmazonSSMAgent"
```
------
1. Pulse `Enter`.
**nota**
Si el comando falla, verifique que está ejecutando la última versión de Herramientas de AWS para PowerShell.
El comando hace lo siguiente:
+ Descarga e instala SSM Agent en el equipo.
+ Registra la máquina en el servicio de Systems Manager.
+ Devuelve una respuesta a la solicitud similar a la siguiente:
```
Directory: C:\Users\ADMINI~1\AppData\Local\Temp\2
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 07/07/2018 8:07 PM ssm
{"ManagedInstanceID":"mi-008d36be46EXAMPLE","Region":"us-east-2"}
Status : Running
Name : AmazonSSMAgent
DisplayName : Amazon SSM Agent
```
El equipo ahora es un *nodo administrado*. Ahora, estos nodos administrados están identificados con el prefijo "mi-". Puede ver los nodos administrados en la página **Nodos administrados** en Fleet Manager, con el comando de la AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html) o con el comando de la API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceInformation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceInformation.html).
## Configuración de la rotación automática de clave privada
Para reforzar su posición de seguridad, puede configurar AWS Systems Manager Agent (SSM Agent) para rotar de forma automática la clave privada de un entorno híbrido y multinube. Puede acceder a esta característica mediante la versión 3.0.1031.0 o posterior de SSM Agent. Active esta característica siguiendo el procedimiento que se describe a continuación.
**Para configurar SSM Agent para rotar la clave privada del entorno híbrido y multinube**
1. Vaya a `/etc/amazon/ssm/` en un equipo Linux o a `C:\Program Files\Amazon\SSM` para un equipo Windows Server.
1. Copie los contenidos de `amazon-ssm-agent.json.template` en un archivo nuevo denominado `amazon-ssm-agent.json`. Guarde `amazon-ssm-agent.json` en el mismo directorio donde se encuentra `amazon-ssm-agent.json.template`.
1. Encuentre`Profile`, `KeyAutoRotateDays`. Ingrese el número de días que desea entre las rotaciones automáticas de clave privada.
1. Reinicie SSM Agent.
Cada vez que cambie la configuración, reinicie SSM Agent.
Puede personalizar otras características de SSM Agent mediante el mismo procedimiento. Para ver la lista actualizada de las propiedades de configuración disponibles y sus valores predeterminados, consulte [Definiciones de propiedades de configuración](https://github.com/aws/amazon-ssm-agent#config-property-definitions).
## Anulación del registro y nuevo registro de un nodo administrado (Windows Server)
Puede anular el registro de un nodo administrado mediante una llamada a la operación de la API [DeregisterManagedInstance](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html) desde la AWS CLI o desde Tools for Windows PowerShell. A continuación, se muestra un ejemplo de comando de la CLI:
`aws ssm deregister-managed-instance --instance-id "mi-1234567890"`
Para eliminar el resto de la información de registro del agente, elimine la clave `IdentityConsumptionOrder` del archivo `amazon-ssm-agent.json`. A continuación, ejecute el siguiente comando:
`amazon-ssm-agent -register -clear`
**nota**
Puede volver a registrar un servidor en las instalaciones, un dispositivo periférico o una máquina virtual con el mismo código e ID de activación siempre que no haya alcanzado el límite de instancias para el código e ID de activación designados. Para comprobar el límite de instancias de un código y un ID de activación, llame a la API [describe-activations](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-activations.html) mediante la AWS CLI. Tras ejecutar el comando, compruebe que el valor de `RegistrationCount` no sea superior a `RegistrationLimit`. Si es así, debe utilizar un código de activación y un ID diferentes.
**Para volver a registrar un nodo administrado en un equipo híbrido Windows Server**
1. Conéctese a su máquina.
1. Ejecute el siguiente comando. Asegúrese de sustituir los valores de marcador por el código y el ID de activación que se generan cuando crea una activación híbrida y por el identificador de la región desde la que desea descargar el SSM Agent.
```
$dir = $env:TEMP + "\ssm"
cd $dir
Start-Process ./ssm-setup-cli.exe -ArgumentList @(
"-register",
"-activation-code=$code",
"-activation-id=$id",
"-region=$region"
) -Wait -NoNewWindow
```