• 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).
# Configuración de nodos administrados para AWS Systems Manager
Complete las tareas de esta sección para instalar y configurar roles, cuentas de usuario, permisos y recursos iniciales para usar las herramientas de AWS Systems Manager. Las tareas que se describen en esta sección las realizan normalmente los administradores de sistemas y una Cuenta de AWS. Una vez completados estos pasos, los usuarios de la organización pueden utilizar Systems Manager para configurar, administrar y acceder a los *nodos administrados*. Un nodo administrado es cualquier máquina configurada para su uso con Systems Manager en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types).
**nota**
Si tiene previsto utilizar las instancias de Amazon EC2 *y* sus propios recursos informáticos en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types), siga los pasos que se indican en [Administrar instancias de EC2 con Systems Manager](systems-manager-setting-up-ec2.md). En este tema se presentan los pasos en el orden más conveniente para completar la configuración de Systems Manager para instancias de EC2 y equipos que no sean de EC2.
Si ya utiliza otros Servicios de AWS, ya ha completado algunos de estos pasos. Sin embargo, otros pasos son específicos de Systems Manager. Por lo tanto, le recomendamos revisar toda esta sección para asegurarse de que lo tenga todo listo para utilizar todas las herramientas de Systems Manager.
**Topics**
+ [Administrar instancias de EC2 con Systems Manager](systems-manager-setting-up-ec2.md)
+ [Administrador de nodos en entornos híbridos y multinube con Systems Manager](systems-manager-hybrid-multicloud.md)
+ [Administración de dispositivos periféricos con Systems Manager](systems-manager-setting-up-edge-devices.md)
+ [Creación de un administrador delegado de AWS Organizations para Systems Manager](setting_up_delegated_admin.md)
+ [Configuración general para AWS Systems Manager](#setting_up_prerequisites)
# Administrar instancias de EC2 con Systems Manager
Complete las tareas de esta sección para instalar y configurar roles, permisos y recursos iniciales para AWS Systems Manager. Las tareas que se describen en esta sección las realizan normalmente los administradores de sistemas y una Cuenta de AWS. Una vez completados estos pasos, los usuarios de la organización pueden utilizar Systems Manager para configurar, administrar y acceder a las instancias de Amazon Elastic Compute Cloud (Amazon EC2).
**nota**
Si tiene previsto utilizar Systems Manager para administrar y configurar máquinas locales, siga los pasos de configuración en [Administrador de nodos en entornos híbridos y multinube con Systems Manager](systems-manager-hybrid-multicloud.md). Si tiene previsto utilizar tanto instancias de Amazon EC2 *como* máquinas que no sean EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types), siga primero los pasos que se indican a continuación. En esta sección, se presentan los pasos en el orden recomendado para configurar los roles, los usuarios, los permisos y los recursos iniciales que se van a utilizar en sus operaciones de Systems Manager.
Si ya utiliza otros Servicios de AWS, ya ha completado algunos de estos pasos. Sin embargo, otros pasos son específicos de Systems Manager. Por lo tanto, le recomendamos revisar toda esta sección para asegurarse de que lo tenga todo listo para utilizar todas las herramientas de Systems Manager.
**Topics**
+ [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md)
+ [Mejora de la seguridad de las instancias de EC2 mediante puntos de conexión de VPC para Systems Manager](setup-create-vpc.md)
# Configuración de permisos de instancia requeridos para Systems Manager
De forma predeterminada, AWS Systems Manager no tiene permiso para realizar acciones en sus instancias. Puede proporcionar permisos de instancia a nivel de cuenta mediante un rol de AWS Identity and Access Management (IAM) o a nivel de instancia mediante un perfil de instancia. Si su caso de uso lo permite, le recomendamos que conceda el acceso a nivel de cuenta mediante la configuración de administración de host predeterminada.
**nota**
Puede omitir este paso y permitir que Systems Manager aplique por usted los permisos necesarios a las instancias cuando se configure la consola unificada. Para obtener más información, consulte [Configuración de AWS Systems Manager](systems-manager-setting-up-console.md).
## Configuración recomendada para permisos de instancia de EC2
La configuración de administración de host predeterminada permite a Systems Manager administrar sus instancias de Amazon EC2 de forma automática. Tras activar esta configuración, todas las instancias que utilicen la versión 2 del servicio de metadatos de instancias (IMDSv2) en la Región de AWS y en la Cuenta de AWS con la versión 3.2.582.0 de SSM Agent o posterior instalada se convertirán automáticamente en instancias administradas. La configuración de administración de host predeterminada no admite la versión 1 del servicio de metadatos de instancias. Para obtener información sobre la transición a IMDSv2, consulte [Transición al uso de Servicio de metadatos de instancia versión 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) en la *Guía del usuario de Amazon EC2*. Para obtener información sobre cómo comprobar la versión de SSM Agent instalada en la instancia, consulte [Verificación del número de versión de SSM Agent](ssm-agent-get-version.md). Para obtener información sobre cómo actualizar SSM Agent, consulte [Actualización automática de SSM Agent](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console). Entre los beneficios de administrar instancias, se incluyen los siguientes:
+ Conéctese a sus instancias de forma segura mediante Session Manager.
+ Realice escaneos de revisiones automatizados mediante Patch Manager.
+ Consulte información detallada sobre sus instancias mediante Systems Manager Inventory.
+ Realice un seguimiento y administre las instancias mediante Fleet Manager.
+ Mantenga SSM Agent actualizado automáticamente.
Fleet Manager, Inventario, Patch Manager y Session Manager son herramientas de AWS Systems Manager.
La configuración de administración de host predeterminada permite la administración de instancias sin el uso de perfiles de instancia y garantiza que Systems Manager tenga permisos para administrar todas las instancias de la región y la cuenta. Si los permisos proporcionados no son suficientes para su caso de uso, también puede agregar políticas al rol de IAM predeterminado creado en la configuración de administración de host predeterminada. Como alternativa, si no necesita permisos para todas las capacidades proporcionadas por el rol de IAM predeterminado, puede crear sus propias políticas y roles personalizados. Cualquier cambio realizado en el rol de IAM que elija para la configuración de administración de host predeterminada se aplica a todas las instancias de Amazon EC2 administradas en la región y la cuenta. Para obtener más información acerca de la política que usa la configuración de administración de host predeterminada, consulte [Política administrada por AWS: AmazonSSMManagedEC2InstanceDefaultPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonSSMManagedEC2InstanceDefaultPolicy). Para obtener más información sobre la configuración de administración de host predeterminada, consulte [Administración automática de instancias EC2 con la configuración de administración de hosts predeterminada](fleet-manager-default-host-management-configuration.md).
**importante**
Las instancias registradas mediante la Configuración de la administración de hosts predeterminada almacenan la información de registro localmente en los directorios `/lib/amazon/ssm` o `C:\ProgramData\Amazon`. Si se eliminan estos directorios o sus archivos, la instancia no podrá adquirir las credenciales necesarias para conectarse a Systems Manager mediante la Configuración de la administración de hosts predeterminada. En estos casos, debe utilizar un perfil de instancia para proporcionar los permisos necesarios a la instancia, o bien volver a crearla.
**nota**
Este procedimiento está pensado para que solo lo realicen los administradores. Implemente el acceso con privilegios mínimos cuando permita que las personas configuren o modifiquen la configuración de administración de host predeterminada. Debe activar la configuración de administración de host predeterminada en cada Región de AWS en la que desee administrar automáticamente sus instancias de Amazon EC2.
**Para activar la configuración de administración de host predeterminada**
Puede activar la configuración de administración de host predeterminada desde la consola de Fleet Manager. Para completar correctamente este procedimiento con la Consola de administración de AWS o la herramienta de línea de comandos que prefiera, debe tener permisos para las operaciones de las API [GetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetServiceSetting.html), [ResetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ResetServiceSetting.html) y [UpdateServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateServiceSetting.html). Además, debe tener permisos `iam:PassRole` para el rol de IAM `AWSSystemsManagerDefaultEC2InstanceManagementRole`. A continuación, se muestra una política de ejemplo. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting",
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com"
]
}
}
}
]
}
```
------
Antes de empezar, si tiene perfiles de instancia adjuntos a sus instancias de Amazon EC2, elimine todos los permisos que permitan la operación `ssm:UpdateInstanceInformation`. SSM Agent intenta usar los permisos del perfil de instancia antes de usar los permisos de configuración de administración de host predeterminados. Si permite la operación `ssm:UpdateInstanceInformation` en los perfiles de su instancia, la instancia no utilizará los permisos de la configuración de administración de host predeterminada.
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 **Fleet Manager**.
1. Seleccione **Configurar la Configuración de la administración de hosts predeterminada** en el menú desplegable **Administración de la cuenta**.
1. Active **Habilitar configuración de administración de host predeterminada**.
1. Elija el rol de IAM que se utiliza para habilitar las herramientas de Systems Manager en sus instancias. Recomendamos utilizar el rol predeterminado que proporciona la configuración de administración de host predeterminada. Contiene el conjunto mínimo de permisos necesarios para administrar sus instancias de Amazon EC2 mediante Systems Manager. Si prefiere utilizar un rol personalizado, la política de confianza del rol debe permitir que Systems Manager sea una entidad de confianza.
1. Elija **Configurar** para completar la configuración.
Tras activar la configuración de administración de host predeterminada, es posible que las instancias tarden 30 minutos en utilizar las credenciales del rol que ha elegido. Debe activar la configuración de administración de host predeterminada en cada región en la que desee administrar automáticamente sus instancias de Amazon EC2.
## Configuración alternativa para permisos de instancia de EC2
Para otorgar acceso a nivel de instancias individuales, debe utilizar un perfil de instancia de AWS Identity and Access Management (IAM). Un perfil de instancias es un contenedor que pasa información del rol de IAM a una instancia de Amazon Elastic Compute Cloud (Amazon EC2) al momento del lanzamiento. Puede crear un perfil de instancias para Systems Manager, adjuntando una o más políticas de IAM que definan los permisos necesarios para un nuevo rol o para un rol que ya haya creado.
**nota**
Puede utilizar Quick Setup, una herramienta de AWS Systems Manager, para configurar rápidamente un perfil de instancias en todas las instancias de su Cuenta de AWS. Quick Setup también crea un rol de servicio de IAM (o rol de *asunción*), lo que permite a Systems Manager ejecutar comandos de forma segura en las instancias en su nombre. Si utiliza Quick Setup, puede omitir este paso (paso 3) y el paso 4. Para obtener más información, consulte [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md).
Tenga en cuenta los siguientes detalles sobre cómo crear un perfil de instancias de IAM:
+ Si está configurando equipos que no son de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types) para Systems Manager, no es necesario crear un perfil de instancia para ellos. En su lugar, configure los servidores y las máquinas virtuales para que utilicen el rol de servicio de IAM. Para obtener más información, consulte [Creación del rol de servicio de IAM requerido para Systems Manager en entornos híbridos y multinube](hybrid-multicloud-service-role.md).
+ Si cambia el perfil de instancias de IAM, puede pasar un tiempo antes de que las credenciales de la instancia se actualicen. El SSM Agent no procesará solicitudes hasta que esto ocurra. Para acelerar el proceso de actualización, puede reiniciar el SSM Agent o la instancia.
En función de si va a crear un nuevo rol para su perfil de instancias o si va a agregar los permisos necesarios para un rol existente, utilice uno de los siguientes procedimientos.
**Para crear un perfil de instancias para instancias administradas de Systems Manager (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 **Trusted entity type** (Tipo de entidad de confianza), elija **Servicio de AWS**.
1. Inmediatamente debajo de **Use case** (Caso de uso), seleccione **EC2** y, a continuación, **Next** (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)
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 anterior, [(Opcional) Crear una política personalizada para el acceso al bucket de S3](#instance-profile-custom-s3-policy), búsquela y seleccione la casilla de verificación situada junto a su nombre.
+ Si tiene previsto unir instancias 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 la instancia, busque **CloudWatchAgentServerPolicy** y seleccione la casilla de verificación situada junto a su nombre.
1. Elija **Siguiente**.
1. En **Role name** (Nombre del rol), ingrese un nombre para el nuevo perfil de instancias, por ejemplo, **SSMInstanceProfile**.
**nota**
Anote el nombre del rol. Elegirá este rol cuando cree instancias nuevas que desee administrar mediante Systems Manager.
1. (Opcional) En **Description** (Descripción), actualice la descripción de este perfil de instancia.
1. (Opcional) En **Tags** (Etiquetas), agregue uno o varios pares de valores etiqueta-clave para organizar, seguir o controlar el acceso a este rol, y luego elija **Create role** (Crear rol). El sistema le devuelve a la página **Roles**.
**Para agregar permisos de perfil de instancias para Systems Manager a un rol existente (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, elija **Roles** y, a continuación, elija el rol existente que desea asociar con un perfil de instancias para operaciones de Systems Manager.
1. En la pestaña **Permissions** (Permisos), elija **Add permissions, Attach policies** (Agregar permisos, Adjuntar políticas).
1. En la página **Attach policy** (Adjuntar política), lleve a cabo las siguientes operaciones:
+ Utilice el campo **Search** (Buscar) para localizar la política **AmazonSSMManagedInstanceCore**. Seleccione la casilla de verificación situada junto a su nombre.
+ Si ha creado una política de bucket de S3 personalizada, búsquela y seleccione la casilla de verificación situada junto a su nombre. Para obtener más información sobre las políticas personalizadas del bucket de S3 para un perfil de instancia, consulte [(Opcional) Crear una política personalizada para el acceso al bucket de S3](#instance-profile-custom-s3-policy).
+ Si tiene previsto unir instancias 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 la instancia, busque **CloudWatchAgentServerPolicy** y seleccione la casilla de verificación situada junto a su nombre.
1. Seleccione **Asociar políticas**.
Para obtener información acerca de cómo se actualiza un rol para que incluya una entidad de confianza o que restrinja aún más el acceso, consulte [Modificación de un rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_modify.html) en la *Guía del usuario de IAM*.
## (Opcional) Crear una política personalizada para el acceso al bucket de S3
La creación de una política personalizada para el acceso a Amazon S3 solo es necesaria si utiliza un punto de enlace de la VPC o un bucket de S3 de su propiedad en sus operaciones de Systems Manager. Puede adjuntar esta política al rol de IAM predeterminado creado por la configuración de administración de host predeterminada o a un perfil de instancia que haya creado en el procedimiento anterior.
Para obtener más información acerca de los buckets de S3 administrados de AWS a los que proporciona acceso en la siguiente política, consulte [SSM Agent Comunicaciones de AWS con buckets de S3 administrados de](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions).
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 **Policies (Políticas)** y, a continuación, seleccione **Create policy (Crear política)**.
1. Seleccione la pestaña **JSON** y sustituya el texto predeterminado con lo siguiente.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::aws-ssm-us-east-2/*",
"arn:aws:s3:::aws-windows-downloads-us-east-2/*",
"arn:aws:s3:::amazon-ssm-us-east-2/*",
"arn:aws:s3:::amazon-ssm-packages-us-east-2/*",
"arn:aws:s3:::us-east-2-birdwatcher-prod/*",
"arn:aws:s3:::aws-ssm-distributor-file-us-east-2/*",
"arn:aws:s3:::aws-ssm-document-attachments-us-east-2/*",
"arn:aws:s3:::patch-baseline-snapshot-us-east-2/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetEncryptionConfiguration"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*",
"arn:aws:s3:::amzn-s3-demo-bucket"
]
}
]
}
```
------
**nota**
El primer elemento `Statement` solo es necesario si utiliza un punto de conexión de VPC.
El segundo elemento `Statement` solo es necesario si utiliza un bucket de S3 que ya haya creado para usarlo en sus operaciones de Systems Manager.
El permiso de la lista de control de acceso de `PutObjectAcl` solo es necesario si planea permitir el acceso entre cuentas para los buckets de S3 en otras cuentas.
El elemento `GetEncryptionConfiguration` es necesario si el bucket de S3 está configurado para utilizar el cifrado.
Si el bucket de S3 está configurado para utilizar el cifrado, entonces la raíz del bucket de S3 (por ejemplo, `arn:aws:s3:::amzn-s3-demo-bucket`) debe aparecer en la sección **Recurso**. Su usuario, grupo o rol debe estar configurado con acceso al bucket raíz.
1. Si está utilizando un punto de enlace de la VPC en sus operaciones, haga lo siguiente:
En el primer elemento `Statement`, sustituya cada marcador de *región* con el identificador de la Región de AWS en la que se utilizará esta política. Por ejemplo, utilice `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*.
**importante**
Recomendamos que evite el uso de caracteres comodín (\$1) en lugar de regiones específicas en esta política. Por ejemplo, utilice `arn:aws:s3:::aws-ssm-us-east-2/*` y no `arn:aws:s3:::aws-ssm-*/*`. El uso de caracteres comodín podría conceder acceso a buckets de S3 a los que no quiere darlo. Si desea utilizar el perfil de instancia para más de una región, le recomendamos repetir el primer elemento de `Statement` de cada región.
-o bien-
Si no va a utilizar un punto de enlace de la VPC en sus operaciones, puede eliminar el primer elemento `Statement`.
1. Si está utilizando un bucket de S3 de su propiedad en sus operaciones de Systems Manager, haga lo siguiente:
En el segundo elemento de `Statement`, sustituya *amzn-s3-demo-bucket* con el nombre de un bucket de S3 en su cuenta. Utilizará este bucket para sus operaciones de Systems Manager. Otorga permisos para objetos del bucket mediante `"arn:aws:s3:::my-bucket-name/*"` como recurso. Para obtener más información acerca de cómo se proporcionan permisos para buckets u objetos en buckets, consulte el tema [Acciones de políticas para Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html) en la *Guía del usuario de Amazon Simple Storage Service* y en la publicación del blog de AWS [IAM Policies and Bucket Policies and ACLs\$1 Oh, My\$1 (Control del acceso a los recursos de S)](https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/).
**nota**
Si utiliza más de un bucket, facilite el ARN de cada uno. Consulte el siguiente ejemplo sobre los permisos de los buckets.
```
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*",
"arn:aws:s3:::amzn-s3-demo-bucket2/*"
]
```
-o bien-
Si no va a utilizar un bucket de S3 de su propiedad en las operaciones de Systems Manager, puede eliminar el segundo elemento `Statement`.
1. Elija **Siguiente: etiquetas**.
1. (Opcional) Para agregar etiquetas, elija **Add tag** (Agregar etiqueta) e ingrese las etiquetas preferidas para la política.
1. Elija **Siguiente: Revisar**.
1. En **Name** (Nombre), ingrese un nombre para identificar esta política, por ejemplo, **SSMInstanceProfileS3Policy**.
1. Elija **Crear política**.
## Consideraciones sobre políticas adicionales para las instancias administradas
En esta sección, se describen algunas de las políticas que puede agregar al rol de IAM predeterminado creado por la configuración de administración de host predeterminada o a los perfiles de instancia para AWS Systems Manager. Para proporcionar permisos para la comunicación entre las instancias y la API de Systems Manager, le recomendamos que cree políticas personalizadas que reflejen las necesidades del sistema y los requisitos de seguridad. En función de su plan de operaciones, es posible que necesite permisos representados en una o varias de las otras políticas.
**Política: `AmazonSSMDirectoryServiceAccess`**
Solo es necesaria si planea unir instancias de Amazon EC2 para Windows Server a un directorio de Microsoft AD.
Esta política administrada de AWS permite a SSM Agent acceder a AWS Directory Service en su nombre para las solicitudes de unión al dominio por parte de la instancia administrada. Para obtener más información, consulte [Cómo unir fácilmente una instancia de EC2 de Windows](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/launching_instance.html) en la *Guía de administración de AWS Directory Service*.
**Política: `CloudWatchAgentServerPolicy`**
Solo es necesaria si planea instalar y ejecutar el agente de CloudWatch en sus instancias para leer métricas y datos de registro en una instancia y escribirlos en Amazon CloudWatch. Esto sirve para monitorear, analizar y responder rápidamente a problemas o cambios en los recursos de AWS.
Su rol de IAM predeterminado creado por la configuración de administración de host predeterminada o el perfil de instancia necesita esta política solo si utilizará características como Amazon EventBridge o Registros de Amazon CloudWatch. (También puede crear una política más restrictiva que, por ejemplo, limite la escritura de acceso a un flujo de registro específico de los Registros de CloudWatch).
El uso de las características de EventBridge y los Registros de CloudWatch es opcional. No obstante, le recomendamos que las configure al principio de su proceso de configuración de Systems Manager si ha decidido usarlas. Para obtener más información, consulte la *[Guía del usuario de Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/)* y la *[Guía del usuario de Registros de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)*.
Para crear políticas de IAM con permisos para herramientas adicionales de Systems Manager, consulte los siguientes recursos:
+ [Restringir el acceso a los parámetros de Parameter Store mediante políticas de IAM](sysman-paramstore-access.md)
+ [Configuración de Automation](automation-setup.md)
+ [Paso 2: Verificar o agregar permisos de instancia para Session Manager](session-manager-getting-started-instance-profile.md)
## Adjuntar el perfil de instancia de Systems Manager a una instancia (consola)
El siguiente procedimiento describe cómo asociar un perfil de instancia de IAM a una instancia de Amazon EC2 mediante la consola de Amazon EC2.
1. Inicie sesión en la Consola de administración de AWS y 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, bajo **Instances**, elija **Instances**.
1. Diríjase a la instancia de EC2 en la lista y elíjala.
1. En el menú **Actions** (Acciones), elija **Security** (Seguridad), **Modify IAM role** (Modificar rol de IAM).
1. En **IAM role (Rol de IAM)**, seleccione el perfil de instancia creado utilizando el procedimiento que se describe en [Configuración alternativa para permisos de instancia de EC2](#instance-profile-add-permissions).
1. Elija **Update **IAM role**** (Actualizar rol de IAM).
Para obtener más información acerca de cómo adjuntar roles de IAM a instancias, elija una de las siguientes opciones, en función del tipo de sistema operativo seleccionado:
+ [Asociación de un rol de IAM a una instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role) en la *Guía del usuario de Amazon EC2*
+ [Asociación de un rol de IAM a una instancia](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/iam-roles-for-amazon-ec2.html#attach-iam-role) en la *Guía del usuario de Amazon EC2*
Continuar con [Mejora de la seguridad de las instancias de EC2 mediante puntos de conexión de VPC para Systems Manager](setup-create-vpc.md).
# Mejora de la seguridad de las instancias de EC2 mediante puntos de conexión de VPC para Systems Manager
Puede mejorar la posición de seguridad de los nodos administrados (incluidas las máquinas que no son de EC2 en su entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types)) mediante la configuración de AWS Systems Manager para que use un punto de conexión de VPC de interfaz en Amazon Virtual Private Cloud (Amazon VPC). Mediante un punto de conexión de VPC de la interfaz (punto de conexión de la interfaz), puede conectarse a servicios con tecnología de AWS PrivateLink. AWS PrivateLink es una tecnología que permite obtener acceso de forma privada a las API de Amazon Elastic Compute Cloud (Amazon EC2) y Systems Manager mediante direcciones IP privadas.
AWS PrivateLink restringe todo el tráfico de red entre las instancias administradas, Systems Manager y Amazon EC2 y la red de Amazon. Esto significa que las instancias administradas no tienen acceso a Internet. Si utiliza AWS PrivateLink, no necesita una puerta de enlace de Internet, un dispositivo NAT ni una puerta de enlace privada virtual.
No es necesario configurar AWS PrivateLink, pero es recomendable. Para obtener más información sobre AWS PrivateLink y los puntos de conexión de VPC, consulte [AWS PrivateLink y los puntos de conexión de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html).
**nota**
La alternativa a usar un punto de enlace de la VPC es permitir el acceso a Internet saliente en las instancias administradas. En este caso, las instancias administradas también deben permitir el tráfico saliente HTTPS (puerto 443) a los siguientes puntos de enlace:
`ssm.region.amazonaws.com`
`ssmmessages.region.amazonaws.com`
`ec2messages.region.amazonaws.com`
SSM Agent inicia todas las conexiones al servicio de Systems Manager en la nube. Por este motivo, no es necesario configurar el firewall para permitir el tráfico entrante a las instancias de Systems Manager.
Para obtener más información acerca de los puntos de enlace, consulte [Referencia: ec2messages, ssmmessages y otras operaciones de la API](systems-manager-setting-up-messageAPIs.md).
Si utiliza Systems Manager en un entorno que *solo* admite IPv6, también debe permitir el tráfico saliente a los siguientes puntos de conexión:
`ssm.region.api.aws`
`ssmmessages.region.api.aws`
`ec2messages.region.api.aws`
Para obtener más información acerca de los puntos de conexión de doble pila, consulte los puntos de conexión de [doble pila](https://docs.aws.amazon.com/general/latest/gr/rande.html#dual-stack-endpoints) en la *Guía de referencia general de AWS*.
También debe asegurarse de que se pueda acceder a los buckets de operaciones de revisiones desde sus nodos, tal y como se describe en [Referencia: buckets de Amazon S3 para operaciones de aplicación de revisiones](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-operations-s3-buckets.html).
**Acerca de Amazon VPC**
Puede utilizar Amazon Virtual Private Cloud (Amazon VPC) para definir una red virtual en su propia área aislada lógicamente dentro de la Nube de AWS, conocida como una *nube privada virtual (VPC)*. Puede lanzar recursos de AWS, como, por ejemplo, instancias, en su VPC. Una VPC es prácticamente idéntica a una red tradicional que usted puede operar en su propio centro de datos, con los beneficios que supone utilizar la infraestructura escalable de AWS. Puede configurar la VPC, seleccionar su rango de direcciones IP, crear subredes y configurar tablas de enrutamiento, puerta de enlace de red y ajustes de seguridad. Ahora puede conectar sus instancias de la VPC a Internet. Puede conectar la VPC a su propio centro de datos corporativo, lo que convierte la Nube de AWS en una ampliación del centro de datos. Para proteger los recursos de cada subred, puede utilizar varias capas de seguridad, incluidos grupos de seguridad y listas de control de acceso a la red. Para obtener más información, consulte la [Guía del usuario de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).
**Topics**
+ [Restricciones y limitaciones de los puntos de enlace de la VPC](#vpc-requirements-and-limitations)
+ [Creación de puntos de enlace de la VPC para Systems Manager](#create-vpc-endpoints)
+ [Crear una política de punto de enlace de la VPC de tipo interfaz](#create-vpc-interface-endpoint-policies)
## Restricciones y limitaciones de los puntos de enlace de la VPC
Antes de configurar los puntos de enlace de la VPC para Systems Manager debe conocer las siguientes restricciones y limitaciones.
**Interconexiones de VPC**
A los puntos de enlace de la interfaz de VPC se puede acceder a través de una interconexión con VPC *dentro de las regiones* y *entre regiones*. Para obtener más información acerca de las solicitudes de conexión de emparejamiento de VPC para los puntos de conexión de la interfaz de la VPC, consulte [Cuotas de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-peering) en la *Guía del usuario de Amazon Virtual Private Cloud*.
Las conexiones de punto de conexión de puerta de enlace de VCP no se pueden ampliar más allá de una VPC. Los recursos del otro lado de una interconexión de VPC en la VPC no pueden utilizar el punto de enlace de gateway para comunicarse con los recursos del servicio de punto de enlace de gateway. Para obtener más información acerca de las solicitudes de conexión de emparejamiento de VPC para puntos de conexión de puertas de enlace de la VPC, consulte [Cuotas de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-endpoints) en la *Guía del usuario de Amazon Virtual Private Cloud*
**Conexiones entrantes**
El grupo de seguridad asociado al punto de enlace de la VPC debe permitir las conexiones entrantes en el puerto 443 desde la subred privada de la instancia administrada. Si no se permiten las conexiones entrantes, la instancia administrada no podrá conectarse a los puntos de enlace de SSM y EC2.
**Resolución de los DNS**
Si utiliza un servidor DNS personalizado, debe agregar un reenviador condicional para cualquier consulta sobre el dominio `amazonaws.com` al servidor DNS de Amazon de su VPC.
**Buckets de S3**
Su política de punto de conexión de VPC debe permitir al menos el acceso a los siguientes buckets Amazon S3 enumerados en [SSM Agent Comunicaciones de AWS con buckets de S3 administrados de](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions):
**nota**
Si utiliza un firewall local y planea usar Patch Manager, ese firewall también debe permitir el acceso al punto de enlace de línea de base de revisiones correspondiente.
**Registros de Amazon CloudWatch**
Si no permite que las instancias accedan a Internet, cree un punto de enlace de la VPC para que los Registros de CloudWatch utilicen características que envíen Registros a CloudWatch. Para obtener más información acerca de cómo crear un punto de enlace para los Registros de CloudWatch, consulte [Creación de un punto de enlace de la VPC para los Registros de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html#create-VPC-endpoint-for-CloudWatchLogs) en la *Guía del usuario de los Registros de Amazon CloudWatch*.
**DNS en un entorno híbrido y multinube**
Para obtener más información sobre cómo se configura DNS para trabajar con los puntos de conexión de AWS PrivateLink en entornos [híbridos y multinube](operating-systems-and-machine-types.md#supported-machine-types), consulte [DNS privado para puntos de conexión de interfaz](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-private-dns) en la *Guía del usuario de Amazon VPC*. Si desea utilizar su propio DNS, puede utilizar Route 53 Resolver. Para obtener más información, consulte [Resolving DNS queries between VPCs and your network](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html) en la *Guía para desarrolladores de Amazon Route 53*.
## Creación de puntos de enlace de la VPC para Systems Manager
Utilice la siguiente información para crear puntos de conexión de interfaces de VPC para AWS Systems Manager. Este tema se vincula con los procedimientos en la *Guía del usuario de Amazon VPC*.
**nota**
*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*.
Siga los pasos descritos en [Create an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint) (Creación de un punto de enlace de interfaz) para crear los siguientes puntos de enlace de la interfaz:
+ **`com.amazonaws.region.ssm`** – el punto de conexión para el servicio de Systems Manager.
+ **`com.amazonaws.region.ec2messages`**: Systems Manager utiliza este punto de conexión para realizar llamadas desde SSM Agent al servicio de Systems Manager. A partir de la versión 3.3.40.0 de SSM Agent, Systems Manager comenzó a utilizar el punto de conexión `ssmmessages:*` (Amazon Message Gateway Service) siempre que estaba disponible en lugar del punto de conexión de `ec2messages:*` (Amazon Message Delivery Service).
+ **`com.amazonaws.region.ec2`** – si utiliza Systems Manager para crear instantáneas compatibles con VSS, debe asegurarse de que tiene un punto de conexión al servicio de EC2. Si el punto de conexión de EC2 no está definido, se produce un error en una llamada para enumerar los volúmenes de Amazon EBS adjuntos, lo que hace que el comando de Systems Manager no se ejecute correctamente.
+ **`com.amazonaws.region.s3`** – Systems Manager utiliza este punto de conexión para realizar la actualización SSM Agent. Systems Manager también utiliza este punto de conexión, si, de manera opcional, opta por recuperar scripts u otros archivos almacenados en buckets o cargar registros de salida a un bucket. Si el grupo de seguridad asociado a su instancia restringe el tráfico saliente, debe agregar una regla para permitir el tráfico hacia la lista de prefijos para Amazon S3. Para obtener más información, consulte [Modificación del grupo de seguridad](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-gateway.html#vpc-endpoints-security) en la *Guía de AWS PrivateLink*.
+ **`com.amazonaws.region.ssmmessages`**: este punto de conexión es necesario para que SSM Agent se comunique con el servicio de Systems Manager, para Run Command, y si se conecta a sus instancias a través de un canal de datos seguro mediante Session Manager. Para obtener más información, consulte [AWS Systems Manager Session Manager](session-manager.md) y [Referencia: ec2messages, ssmmessages y otras operaciones de la API](systems-manager-setting-up-messageAPIs.md).
+ (Opcional) **`com.amazonaws.region.kms`**: cree este punto de conexión si desea utilizar cifrado de AWS Key Management Service (AWS KMS) para parámetros de Session Manager o Parameter Store.
+ (Opcional) **`com.amazonaws.region.logs`**: crear este punto de conexión si desea utilizar Registros de Amazon CloudWatch (CloudWatch Logs) para registros de Session Manager, Run Command o SSM Agent.
Para obtener información acerca de los buckets de S3 de AWS administrados a los que SSM Agent debe tener acceso, consulte [SSM Agent Comunicaciones de AWS con buckets de S3 administrados de](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions). Si utiliza un punto de conexión de nube privada virtual (VPC) en las operaciones de Systems Manager, necesita conceder permiso explícito en un perfil de instancia de EC2 para Systems Manager o en un rol de servicio para nodos que no son de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types).
## Crear una política de punto de enlace de la VPC de tipo interfaz
Puede crear políticas para los puntos de enlace de la interfaz de VPC de AWS Systems Manager en la que puede especificar:
+ la entidad principal que puede realizar acciones
+ Las acciones que se pueden realizar
+ los recursos en los que se pueden realizar acciones
Para obtener más información, consulte [Control access to services with VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) en la *Guía del usuario de Amazon VPC*.
# 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
```
# Administración de dispositivos periféricos con Systems Manager
En esta sección se describen las tareas de configuración que la cuenta y los administradores de sistemas realizan para habilitar la configuración y la administración de dispositivos de núcleo de AWS IoT Greengrass. Después de completar estas tareas, los usuarios a los que el administrador de Cuenta de AWS les ha concedido permisos pueden utilizar AWS Systems Manager para configurar y administrar los dispositivos de núcleo de AWS IoT Greengrass.
**nota**
SSM Agent para AWS IoT Greengrass no es compatible en macOS ni en Windows 10. No puede utilizar las herramientas de Systems Manager para administrar y configurar dispositivos de periferia que utilizan estos sistemas operativos.
Systems Manager también admite dispositivos de borde que no están configurados como dispositivos de núcleo de AWS IoT Greengrass. Para utilizar Systems Manager para administrar dispositivos de núcleo de AWS IoT y dispositivos de periferia que no sean de AWS, debe configurarlos mediante una activación híbrida Para obtener más información, consulte [Administrador de nodos en entornos híbridos y multinube con Systems Manager](systems-manager-hybrid-multicloud.md).
Para utilizar Session Manager y la aplicación de revisiones de aplicaciones de Microsoft con los dispositivos de borde, debe habilitar el nivel de instancias avanzadas. Para obtener más información, consulte [Activación del nivel de instancias avanzadas](fleet-manager-enable-advanced-instances-tier.md).
**Antes de empezar**
Compruebe que los dispositivos de borde cumplen los siguientes requisitos.
+ Los dispositivos de borde deben cumplir los requisitos para configurarse como dispositivos de núcleo de AWS IoT Greengrass. Para obtener más información, consulte [Configuración de dispositivos de núcleo de AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/v2/developerguide/setting-up.html) en la *Guía para desarrolladores de AWS IoT Greengrass Version 2*.
+ Los dispositivos de borde deben ser compatibles con el agente de AWS Systems Manager (SSM Agent). Para obtener más información, consulte [Sistemas operativos compatibles con Systems Manager](operating-systems-and-machine-types.md#prereqs-operating-systems).
+ Los dispositivos de borde deben poder comunicarse con el servicio de Systems Manager en la nube. Systems Manager no admite dispositivos de borde desconectados.
**Acerca de la configuración de dispositivos de borde**
La configuración de dispositivos de AWS IoT Greengrass para Systems Manager implica los siguientes procesos.
**nota**
Para obtener información sobre cómo desinstalar SSM Agent de un dispositivo perimetral, consulte [Desinstalar AWS Systems Manager Agent](https://docs.aws.amazon.com/greengrass/v2/developerguide/uninstall-systems-manager-agent.html) en la *AWS IoT Greengrass Version 2Guía para desarrolladores*.
## Creación de un rol de servicio de IAM para dispositivos periféricos
Los dispositivos de núcleo de AWS IoT Greengrass requieren un rol de servicio de AWS Identity and Access Management (IAM) para comunicarse con 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 una vez por cada Cuenta de AWS. Especificará este rol para el parámetro `RegistrationRole` cuando configure e implemente el componente de SSM Agent a los dispositivos de AWS IoT Greengrass. Si ya creó este rol mientras configuraba nodos que no son de EC2 para un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types), puede omitir este paso.
**nota**
A los usuarios de la empresa u organización que van a utilizar Systems Manager en los dispositivos de borde se les debe conceder permiso en IAM para llamar a la API de Systems Manager.
**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 compatibles gestionados por AWS PrivateLink.
+ **Caso 2**: planea usar un bucket S3 que crea como parte de sus operaciones de Administrador de sistemas, como para almacenar la salida para comandos Run Command o sesiones Session Manager en un bucket 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.
**nota**
Si los dispositivos están protegidos por un firewall y planea utilizar Patch Manager, el firewall debe permitir el acceso al punto de conexión de la base de referencia de revisiones `arn:aws:s3:::patch-baseline-snapshot-region/*`.
*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*.
------
#### [ AWS CLI ]
**Para crear un rol de servicio de IAM para un entorno AWS IoT Greengrass (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`.
**nota**
Anote el nombre. Lo especificará cuando implemente SSM Agent en los dispositivos de núcleo de AWS IoT Greengrass.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
}
```
------
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. Reemplace cada *example resource placeholder* con su propia información.
**Linux y 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 a los dispositivos de borde para ejecutar comandos mediante Systems Manager.
**nota**
Las políticas que agrega a un perfil de servicio para los dispositivos de borde son las mismas políticas que las utilizadas para crear un perfil de instancias en instancias de Amazon Elastic Compute Cloud (Amazon EC2). Para obtener más información sobre las políticas de IAM 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 dispositivo de borde utilice la funcionalidad principal del servicio de AWS Systems Manager.
**Linux y 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 *account\$1ID* y *my\$1bucket\$1policy\$1name* con el ID de la Cuenta de AWS y el nombre del bucket.
**Linux y macOS**
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::account_ID:policy/my_bucket_policy_name
```
**Windows**
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::account_id:policy/my_bucket_policy_name
```
(Opcional) Ejecute el siguiente comando para permitir que SSM Agent acceda a Directory Service en su nombre para las solicitudes de unión al dominio desde los dispositivos de borde. El rol de servicio solo necesita esta política si une los dispositivos de borde a un directorio de Microsoft AD.
**Linux y 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 dispositivos de borde. Este comando permite la lectura de información en un dispositivo y su escritura en CloudWatch. El rol de servicio solo precisa de esta política si hace uso de servicios, como Amazon EventBridge o los 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 AWS IoT Greengrass (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`.
**nota**
Anote el nombre. Lo especificará cuando implemente SSM Agent en los dispositivos de núcleo de AWS IoT Greengrass.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
}
```
------
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.
```
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 a los dispositivos de borde para ejecutar comandos mediante Systems Manager.
**nota**
Las políticas que agrega a un rol de servicio para los dispositivos de borde en un entorno de AWS IoT Greengrass son las mismas políticas que las utilizadas para crear un perfil de instancias en instancias 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 dispositivo de borde 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 *account\$1ID* y *my\$1bucket\$1policy\$1name* con el ID de la Cuenta de AWS y el nombre del bucket.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::account_ID:policy/my_bucket_policy_name
```
(Opcional) Ejecute el siguiente comando para permitir que SSM Agent acceda a Directory Service en su nombre para las solicitudes de unión al dominio desde los dispositivos de borde. El rol de servicio solo necesita esta política si une los dispositivos de borde 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 dispositivos de borde. Este comando permite la lectura de información en un dispositivo y su escritura en CloudWatch. El rol de servicio solo precisa de esta política si hace uso de servicios, como Amazon EventBridge o los Registros de Amazon CloudWatch.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
------
## Configuración de dispositivos periféricos para AWS IoT Greengrass
Configure los dispositivos de borde como dispositivos de núcleo de AWS IoT Greengrass. El proceso de configuración implica verificar los sistemas operativos compatibles y los requisitos del sistema, así como instalar y configurar el software AWS IoT Greengrass Core en los dispositivos. Para obtener más información, consulte [Configuración de dispositivos de núcleo de AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/v2/developerguide/setting-up.html) en la *Guía para desarrolladores de AWS IoT Greengrass Version 2*.
## Actualización del rol de intercambio de tokens de AWS IoT Greengrass e instalación de SSM Agent en dispositivos periféricos
El último paso para instalar y configurar los dispositivos básicos de AWS IoT Greengrass para Systems Manager consiste en actualizar el rol de servicio del dispositivo de AWS Identity and Access Management (IAM) de AWS IoT Greengrass, también denominado *rol de intercambio de tokens*, e implementar AWS Systems Manager Agent (SSM Agent) en los dispositivos de AWS IoT Greengrass. Para obtener información sobre estos procesos, consulte [Instalación de AWS Systems Manager Agent](https://docs.aws.amazon.com/greengrass/v2/developerguide/install-systems-manager-agent.html) en la *Guía para desarrolladores de AWS IoT Greengrass Version 2*.
Después de implementar SSM Agent en los dispositivos, AWS IoT Greengrass registra automáticamente los dispositivos con Systems Manager. No es necesario un registro adicional. Puede empezar a utilizar las herramientas de Systems Manager para acceder, administrar y configurar los dispositivos de AWS IoT Greengrass.
**nota**
Los dispositivos de borde deben poder comunicarse con el servicio de Systems Manager en la nube. Systems Manager no admite dispositivos de borde desconectados.
# Creación de un administrador delegado de AWS Organizations para Systems Manager
**Cambio en la disponibilidad de Change Manager**
Change Manager de AWS Systems Manager dejará de estar disponible para nuevos clientes a partir del 7 de noviembre de 2025. Si desea utilizar Change Manager, regístrese antes de esa fecha. Los clientes existentes pueden seguir utilizando el servicio con normalidad. Para obtener más información, consulte [Cambio en la disponibilidad de Change Manager de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager-availability-change.html).
Al configurar una organización en AWS Organizations, se asigna una cuenta de administración para realizar todas las tareas administrativas para todos Servicios de AWS. El usuario de la cuenta de administración solo puede asignar una *cuenta de administrador delegado* para que Systems Manager realice tareas administrativas para Change Manager, Explorer y OpsCenter. AWS Organizations es un servicio de administración de cuentas que se puede usar para crear una organización y asignar Cuentas de AWS para administrar estas cuentas de forma centralizada. Para obtener más información sobre AWS Organizations, consulte [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) en la *Guía del usuario de AWS Organizations*.
Change Manager, Explorer, y OpsCenter, herramientas de AWS Systems Manager, funcionan con AWS Organizations para llevar a cabo tareas en todas las cuentas de los miembros de su organización. Solo puede asignar un administrador delegado para todas las herramientas de Systems Manager. La cuenta de administrador delegado debe ser un miembro de la unidad organizativa a la que esté asignada.
**Topics**
+ [Uso de un administrador delegado con Change Manager](#setting_up_delegated_administrator_change_manager)
+ [Uso de un administrador delegado con Explorer](#setting_up_delegated_administrator_explorer)
+ [Uso de un administrador delegado con OpsCenter](#setting_up_delegated_administrator_opscenter)
+ [Uso de un administrador delegado con Quick Setup](#setting_up_delegated_administrator_quick_setup)
## Uso de un administrador delegado con Change Manager
Change Manager es un marco empresarial de administración de cambios con el que se pueden solicitar, aprobar, implementar e informar los cambios operativos de la configuración y la infraestructura de la aplicación.
Si utilizas Change Manager en una organización, asigna una cuenta de administrador delegada para administrar plantillas de cambios, aprobaciones e informes para todas las cuentas de miembros. Mediante Quick Setup, puede configurar Change Manager para usarlo con una organización y seleccionar la cuenta de administrador delegado. La cuenta de administrador delegado no es necesaria si Change Manager se utiliza solo con una única Cuenta de AWS.
De forma predeterminada, Change Manager muestra todas las tareas relacionadas con los cambios en la cuenta de administrador delegado. Para obtener instrucciones sobre cómo configurar un administrador delegado durante la configuración de Change Manager de una organización, consulte [Configuración de Change Manager para una organización (cuenta de administración)](change-manager-organization-setup.md).
**importante**
Si utiliza Change Manager en toda una organización, se recomienda efectuar siempre los cambios desde la cuenta de administrador delegado. Si bien es posible realizar cambios desde otras cuentas de la organización, esos cambios no se notificarán ni se podrán ver desde la cuenta de administrador delegado.
## Uso de un administrador delegado con Explorer
Explorer es un panel de operaciones personalizable que muestra una vista agregada de los datos de operaciones (OpsData) de sus Cuentas de AWS y en todas las Regiones de AWS.
Puede configurar una cuenta de administrador delegado para Systems Manager para agregar datos de Explorer de múltiples regiones y cuentas mediante el uso de la sincronización de datos de recursos con AWS Organizations. Un administrador delegado puede buscar, filtrar y agregar datos de Explorer mediante las teclas Consola de administración de AWS, AWS Command Line Interface (AWS CLI) o AWS Tools for Windows PowerShell.
Un administrador delegado mejora la seguridad de Explorer al limitar el número de administradores que pueden crear o eliminar varias cuentas y sincronizar los datos de recursos de la región en una sola Cuenta de AWS.
Puede sincronizar los datos de las operaciones entre todas las Cuentas de AWS de su organización mediante Explorer. Para obtener información sobre cómo asignar un administrador delegado desde Explorer, consulte [Configurar un administrador delegado para Explorer](Explorer-setup-delegated-administrator.md).
## Uso de un administrador delegado con OpsCenter
OpsCenter proporciona una ubicación central donde los ingenieros de operaciones y los profesionales de TI pueden administrar los elementos de trabajo operativos (OpsItems) relacionados con los recursos de AWS. Si desea utilizar OpsCenter para gestionar, de forma centralizada, todas las cuentas OpsItems, debe configurar la organización en AWS Organizations.
Si usa Quick Setup para OpsCenter, puede asignar una cuenta de administrador delegado y configurar OpsCenter para administrar OpsItems de forma centralizada. Para obtener más información, consulte [(Opcional) Configuración de OpsCenter para administrar OpsItems en todas las cuentas mediante Quick Setup](OpsCenter-quick-setup-cross-account.md).
## Uso de un administrador delegado con Quick Setup
Quick Setup es una herramienta de Systems Manager que lo ayuda a configurar servicios y características de AWS utilizados con frecuencia mediante las prácticas recomendadas. Puede configurar una cuenta de administrador delegado para que Quick Setup lo ayude a implementar y administrar las configuraciones en todas las cuentas y regiones mediante AWS Organizations. Un administrador delegado de Quick Setup puede crear, actualizar, ver y eliminar los recursos del administrador de configuración de la organización. Systems Manager registra un administrador delegado de Quick Setup como parte del proceso de configuración de la experiencia de consola integrada. Para obtener más información, consulte [Cómo configurar la consola unificada de Systems Manager para una organización](systems-manager-setting-up-organizations.md).
## Configuración general para AWS Systems Manager
Si aún no lo ha hecho, regístrese para obtener una Cuenta de AWS y cree un usuario administrativo.
### Cómo crear una Cuenta de AWS
Si no dispone de una Cuenta de AWS, siga estos pasos para crear una.
**Cómo registrarse en Cuenta de AWS**
1. Abra [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup).
1. Siga las instrucciones que se le indiquen.
Parte del procedimiento de registro consiste en recibir una llamada telefónica o mensaje de texto e indicar un código de verificación en el teclado del teléfono.
Al registrarse en una Cuenta de AWS, se crea un *Usuario raíz de la cuenta de AWS*. El usuario raíz tendrá acceso a todos los Servicios de AWS y recursos de esa cuenta. Como práctica recomendada de seguridad, asigne acceso administrativo a un usuario y utilice únicamente el usuario raíz para realizar [Tareas que requieren acceso de usuario raíz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).
AWS le enviará un correo electrónico de confirmación cuando complete el proceso de registro. Se puede ver la actividad de la cuenta y administrarla en cualquier momento entrando en [https://aws.amazon.com/](https://aws.amazon.com/) y seleccionando **Mi cuenta**.
### Creación de un usuario con acceso administrativo
Después de registrarse para obtener una Cuenta de AWS, proteja su Usuario raíz de la cuenta de AWS, habilite AWS IAM Identity Center y cree un usuario administrativo para no usar el usuario raíz en las tareas cotidianas.
**Protección de Usuario raíz de la cuenta de AWS**
1. Inicie sesión en [Consola de administración de AWS](https://console.aws.amazon.com/) como propietario de la cuenta; para ello, elija **Usuario raíz** e introduzca el correo electrónico de su Cuenta de AWS. En la siguiente página, escriba su contraseña.
Para obtener ayuda para iniciar sesión con el usuario raíz, consulte [Iniciar sesión como usuario raíz](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) en la *Guía del usuario de AWS Sign-In*.
1. Active la autenticación multifactor (MFA) para el usuario raíz.
Para obtener instrucciones, consulte [Habilitación de un dispositivo MFA virtual para su usuario raíz de la Cuenta de AWS (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) en la *Guía del usuario de IAM*.
**Creación de un usuario con acceso administrativo**
1. Activar IAM Identity Center.
Consulte las instrucciones en [Activar AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) en la *Guía del usuario de AWS IAM Identity Center*.
1. En IAM Identity Center, conceda acceso administrativo a un usuario.
Para ver un tutorial sobre cómo usar Directorio de IAM Identity Center como origen de identidad, consulte [Configuración del acceso de los usuarios con el Directorio de IAM Identity Center predeterminado](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) en la *Guía del usuario de AWS IAM Identity Center*.
**Inicio de sesión como usuario con acceso de administrador**
+ Para iniciar sesión con el usuario de IAM Identity Center, use la URL de inicio de sesión que se envió a la dirección de correo electrónico cuando creó el usuario de IAM Identity Center.
Para obtener ayuda para iniciar sesión con un usuario de IAM Identity Center, consulte [Inicio de sesión en el portal de acceso de AWS](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) en la *Guía del usuario de AWS Sign-In*.
**Concesión de acceso a usuarios adicionales**
1. En IAM Identity Center, cree un conjunto de permisos que siga la práctica recomendada de aplicar permisos de privilegios mínimos.
Para conocer las instrucciones, consulte [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) en la *Guía del usuario de AWS IAM Identity Center*.
1. Asigne usuarios a un grupo y, a continuación, asigne el acceso de inicio de sesión único al grupo.
Para conocer las instrucciones, consulte [Add groups](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) en la *Guía del usuario de AWS IAM Identity Center*.