• 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).
# Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineWithHooks`
AWS Systems Manager es compatible con `AWS-RunPatchBaselineWithHooks`, un documento de Systems Manager (documento de SSM) para Patch Manager, una herramienta de AWS Systems Manager. Este documento de SSM realiza operaciones de aplicación de revisiones en los nodos administrados para actualizaciones relacionadas con la seguridad y de otros tipos.
`AWS-RunPatchBaselineWithHooks` se diferencia de `AWS-RunPatchBaseline` en los siguientes aspectos:
+ **Un documento contenedor:** `AWS-RunPatchBaselineWithHooks` es un contenedor de `AWS-RunPatchBaseline` y se basa en `AWS-RunPatchBaseline` para realizar algunas de sus operaciones.
+ **La operación `Install`**: `AWS-RunPatchBaselineWithHooks` admite enlaces de ciclo de vida que se ejecutan en puntos designados durante la aplicación de revisiones en los nodos administrados. Dado que las instalaciones de revisiones en ocasiones requieren que se reinicien los nodos administrados, la operación de aplicación de revisiones se divide en dos eventos, lo que supone un total de tres enlaces que permiten una funcionalidad personalizada. El primer enlace tiene lugar antes de la operación `Install with NoReboot`. El segundo enlace tiene lugar después de la operación `Install with NoReboot`. El tercer enlace está disponible después del reinicio del nodo administrado.
+ **Sin compatibilidad con la lista de parches personalizados:** `AWS-RunPatchBaselineWithHooks` no admite el parámetro `InstallOverrideList`.
+ **Compatibilidad con SSM Agent**: `AWS-RunPatchBaselineWithHooks` requiere que se instale la versión 3.0.502 o una posterior de SSM Agent en el nodo administrado en el que se aplicará la revisión.
Cuando el documento se ejecuta, utiliza la base de referencia de parches que actualmente se encuentra especificada como “predeterminada” para un tipo de sistema operativo en caso de que no se hubiera indicado ningún grupo de parches. En caso contrario, utiliza las bases de referencia de parches que se asocian con el grupo de parches. Para obtener información acerca de los grupos de parches, consulte [Grupos de revisiones](patch-manager-patch-groups.md).
Puede utilizar el documento `AWS-RunPatchBaselineWithHooks` para aplicar revisiones a los sistemas operativos y a las aplicaciones. (En Windows Server, la compatibilidad con las aplicaciones se limita a las actualizaciones de las aplicaciones publicadas por Microsoft).
Este documento es compatible con los nodos administrados de Linux y Windows Server. El documento se encargará de realizar las acciones adecuadas para cada plataforma.
**nota**
`AWS-RunPatchBaselineWithHooks` no es compatible conmacOS.
------
#### [ Linux ]
En nodos administrados de Linux, el documento `AWS-RunPatchBaselineWithHooks` invoca un módulo de Python, que a su vez descarga una instantánea de la línea de base de revisiones que se aplica al nodo administrado. Esta instantánea de la línea de base de revisiones utiliza las reglas definidas y las listas de revisiones aprobadas y bloqueadas con el fin de impulsar el administrador de paquetes adecuado para cada tipo de nodo:
+ Los nodos administrados de Amazon Linux 2, Oracle Linux y RHEL 7 utilizan YUM. Para las operaciones de YUM, Patch Manager requiere `Python 2.6` o una versión posterior compatible (2.6 a 3.12). Amazon Linux 2023 usa DNF. Para las operaciones de DNF, Patch Manager requiere una versión compatible de `Python 2` o `Python 3` (2.6 a 3.12).
+ RHELLos nodos administrados de 8 utilizan DNF. Para las operaciones de DNF, Patch Manager requiere una versión compatible de `Python 2` o `Python 3` (2.6 a 3.12). (Ninguna de las dos versiones viene instalada en RHEL 8 de forma predeterminada. Para ello, deberá instalar una u otra versión manualmente).
+ Las instancias de Debian Server y Ubuntu Server usan APT. Para las operaciones de APT, Patch Manager requiere una versión compatible de `Python 3` (3.0 a 3.12).
------
#### [ Windows Server ]
En nodos administrados de Windows Server, el documento `AWS-RunPatchBaselineWithHooks` descarga e invoca un módulo de PowerShell, que a su vez descarga una instantánea de la línea de base de revisiones que se aplica al nodo administrado. Esta instantánea de la línea de base de revisiones contiene una lista de revisiones aprobadas que se compila al consultar dicha línea de base de revisiones en un servidor de Windows Server Update Services (WSUS). Esta lista se transfiere a la API de Windows Update, que controla la descarga y la instalación de los parches aprobados, según proceda.
------
Cada instantánea se corresponde con una Cuenta de AWS, un grupo de parches, un sistema operativo y un ID de instantánea. La instantánea se entrega a través de una URL prefirmada de Amazon Simple Storage Service (Amazon S3), que se vence transcurridas las 24 horas desde la creación de la instantánea. Sin embargo, si desea aplicar el mismo contenido de la instantánea a otros nodos administrados una vez que la URL se haya vencido, puede generar una nueva dirección de Amazon S3 prefirmada hasta tres días después de la creación de la instantánea. Para ello, utilice el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html).
Cuando se han instalado todas las actualizaciones aprobadas y aplicables, y se han realizado los reinicios necesarios, se genera la información de conformidad de revisiones en un nodo administrado y se notifica a Patch Manager.
Si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaselineWithHooks`, el nodo administrado no se reinicia después de que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
**importante**
Si bien la opción `NoReboot` impide el reinicio del sistema operativo, no impide los reinicios a nivel de servicio que pueden producirse cuando se actualizan determinados paquetes. Por ejemplo, la actualización de paquetes como Docker puede provocar el reinicio automático de los servicios dependientes (como los servicios de orquestación de contenedores) incluso cuando `NoReboot` está especificado.
Para obtener información sobre cómo ver los datos de conformidad de revisiones, consulte [Acerca de la conformidad de parches](compliance-about.md#compliance-monitor-patch).
## `AWS-RunPatchBaselineWithHooks`Pasos operativos de
Cuando se ejecuta `AWS-RunPatchBaselineWithHooks`, se llevan a cabo los siguientes pasos:
1. **Análisis**: se ejecuta una operación `Scan` con `AWS-RunPatchBaseline` en el nodo administrado, y, de este modo, se genera y carga un informe de conformidad.
1. **Verificación de los estados del parche local:** se ejecuta un script para determinar los pasos que se llevarán a cabo en función de la operación seleccionada y el resultado de `Scan` del paso 1.
1. Si la operación seleccionada es `Scan`, esta se marcará como completada. La operación finaliza.
1. Si la operación seleccionada es `Install`, Patch Manager evalúa el resultado de `Scan` del paso 1 para determinar qué ejecutar a continuación:
1. Si no se detectan parches faltantes ni se requieren reinicios pendientes, la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios.
1. Si no se detectan parches faltantes, pero hay reinicios pendientes, y la opción de reinicio seleccionada es `NoReboot`, la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios.
1. De lo contrario, la operación continúa con el siguiente paso.
1. **Operación de enlace previa a la aplicación de revisiones**: el documento de SSM que ha proporcionado para el primer enlace de ciclo de vida, `PreInstallHookDocName`, se ejecuta en el nodo administrado.
1. **Instalación con NoReboot**: se ejecuta una operación `Install` con la opción de reinicio de `NoReboot` mediante `AWS-RunPatchBaseline` en el nodo administrado, y, de este modo, se genera y carga un informe de conformidad.
1. **Operación de enlace posterior a la instalación**: el documento de SSM que ha proporcionado para el segundo enlace de ciclo de vida, `PostInstallHookDocName`, se ejecuta en el nodo administrado.
1. **Verificación del reinicio**: se ejecuta un script para determinar si es necesario reiniciar el nodo administrado y cuáles son los pasos a ejecutar:
1. Si la opción de reinicio seleccionada es `NoReboot`, la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios.
1. Si la opción de reinicio seleccionada es `RebootIfNeeded`, Patch Manager verifica que no haya reinicios pendientes necesarios a partir del inventario recopilado en el paso 4. Esto significa que la operación continúa con el paso 7 y el nodo administrado se reinicia en cualquiera de los siguientes casos:
1. Patch Manager instaló una o más revisiones. (Patch Manager no evalúa si la revisión requiere llevar a cabo un reinicio. El sistema se reinicia aunque la revisión no requiera el reinicio.)
1. Patch Manager detecta una o más revisiones con un estado `INSTALLED_PENDING_REBOOT` durante la operación de instalación. El estado `INSTALLED_PENDING_REBOOT` puede indicar que la opción `NoReboot` se seleccionó la última vez que se ejecutó la operación de instalación o que se instaló un parche por fuera de Patch Manager desde la última vez que se reinició el nodo administrado.
Si no se encuentran revisiones que requieran un reinicio, la operación de aplicación de revisiones en el nodo administrado se completa, de modo que la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios.
1. **Instalación e informe**: se ejecuta una operación de instalación con la opción de reinicio de `RebootIfNeeded` en el nodo administrado mediante `AWS-RunPatchBaseline`, y, de este modo, se genera y carga un informe de conformidad.
1. **Operación de enlace posterior al reinicio**: el documento de SSM que ha proporcionado para el tercer enlace de ciclo de vida, `OnExitHookDocName`, se ejecuta en el nodo administrado.
Para una operación `Scan`, si se produce un error en el paso 1, el proceso de ejecución del documento se detiene y ese paso se notifica como un error, aunque los posteriores se hayan realizado correctamente.
Para una operación `Install`, si se produce un error en alguno de los pasos de `aws:runDocument` durante la operación, esos se notifican como error, de modo que la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios. Este paso se notifica como error, mientras que el último paso notifica el estado del resultado de su operación, y todos los pasos intermedios se notifican como realizados correctamente.
## `AWS-RunPatchBaselineWithHooks`Parámetros
`AWS-RunPatchBaselineWithHooks` admite seis parámetros.
El parámetro `Operation` es obligatorio.
Los parámetros `RebootOption`, `PreInstallHookDocName`, `PostInstallHookDocName` e `OnExitHookDocName` son opcionales.
`Snapshot-ID` es opcional desde el punto de vista técnico, pero se recomienda que proporcione un valor personalizado cuando ejecute `AWS-RunPatchBaselineWithHooks` fuera de un periodo de mantenimiento. Permita que Patch Manager proporcione el valor automáticamente cuando se ejecute el documento como parte de una operación del periodo de mantenimiento.
**Topics**
+ [Nombre del parámetro: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nombre del parámetro: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [Nombre del parámetro: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [Nombre del parámetro: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [Nombre del parámetro: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### Nombre del parámetro: `Operation`
**Usage**: requerido.
**Opciones**: `Scan` \$1 `Install`.
Examen
Cuando elige la opción `Scan`, el sistema utiliza el documento `AWS-RunPatchBaseline` para determinar el estado de conformidad de las revisiones del nodo administrado y notifica esta información a Patch Manager. `Scan` no solicita que se instalen actualizaciones ni que se reinicien los nodos administrados. En lugar de ello, la operación identifica las actualizaciones aprobadas que faltan y que son aplicables al nodo.
Instalación
Al elegir la opción `Install`, `AWS-RunPatchBaselineWithHooks` intenta instalar las actualizaciones aprobadas y aplicables que faltan en el nodo administrado. La información de conformidad de revisiones generada como parte de una operación `Install` no muestra las actualizaciones que faltan, pero podría notificar aquellas que presentan un estado de error si la instalación de la actualización no se ha podido realizar por cualquier motivo. Cuando una actualización se instala en un nodo administrado, este se reinicia para garantizar que la actualización esté instalada y activa. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaselineWithHooks`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)).
Si se instala una revisión especificada por las reglas de la línea de base *antes* de que Patch Manager actualice el nodo administrado, es posible que el sistema no se reinicie como es debido. Esto puede ocurrir cuando un usuario instala manualmente una revisión o cuando la instala automáticamente otro programa, como el `unattended-upgrades` paquete de Ubuntu Server.
### Nombre del parámetro: `Snapshot ID`
**Usage**: opcional.
`Snapshot ID` es un ID exclusivo (GUID) que utiliza Patch Manager para garantizar que un conjunto de nodos administrados en los que se aplican revisiones en una sola operación tenga el mismo conjunto de revisiones aprobadas. Aunque el parámetro se define como opcional, nuestra mejor práctica recomendada depende de si se ejecuta o no `AWS-RunPatchBaselineWithHooks` en un periodo de mantenimiento, tal como se describe en la siguiente tabla.
**`AWS-RunPatchBaselineWithHooks`Prácticas recomendadas de**
| Mode | Práctica recomendada | Details |
| --- | --- | --- |
| Ejecución de AWS-RunPatchBaselineWithHooks dentro de un periodo de mantenimiento | No proporcione un ID de instantánea, sino que Patch Manager lo hará en su lugar. | Si utiliza un periodo de mantenimiento para ejecutar `AWS-RunPatchBaselineWithHooks`, no debe proporcionar su propio ID de instantánea generado. En este caso, Systems Manager proporciona un valor GUID en función del ID de ejecución del periodo de mantenimiento. De este modo, se garantiza que se utilice un ID correcto para todas las invocaciones de `AWS-RunPatchBaselineWithHooks` en dicho periodo de mantenimiento. Si especifica un valor en este caso, tenga en cuenta que la instantánea de la línea de base de revisiones no podría mantenerse durante más de tres días. Después de eso, se generará una nueva instantánea, aunque especifique el mismo ID después de que expire la instantánea. |
| Ejecución de AWS-RunPatchBaselineWithHooks fuera de un periodo de mantenimiento | Genere y especifique un valor GUID personalizado para el ID de instantánea.¹ | Cuando no esté utilizando un periodo de mantenimiento para ejecutar `AWS-RunPatchBaselineWithHooks`, se recomienda generar y especificar un ID de instantánea exclusivo por cada línea de base de revisiones, especialmente si ejecuta el documento `AWS-RunPatchBaselineWithHooks` en varios nodos administrados durante la misma operación. Si no especifica un ID en este caso, Systems Manager genera otro ID de instantánea para cada nodo administrado al que se envía el comando. Esto podría generar diferentes conjuntos de revisiones que se especifican entre los nodos. Por ejemplo, supongamos que se ejecuta el documento `AWS-RunPatchBaselineWithHooks` directamente a través de Run Command, una herramienta de AWS Systems Manager, y selecciona como destino un grupo de 50 nodos administrados. Al especificar un ID de instantánea personalizado, se genera una sola instantánea de la base de referencia que se utiliza para evaluar y aplicar revisiones en todos los nodos administrados, lo que garantiza que tengan un estado coherente. |
| ¹ Puede utilizar cualquier herramienta que genere un GUID con el fin de crear un valor para el parámetro de ID de la instantánea. Por ejemplo, en PowerShell, puede utilizar el cmdlet `New-Guid` para generar un GUID con el formato `12345699-9405-4f69-bc5e-9315aEXAMPLE`. |
### Nombre del parámetro: `RebootOption`
**Usage**: opcional.
**Opciones**: `RebootIfNeeded` \$1 `NoReboot`
**Valor predeterminado**: `RebootIfNeeded`
**aviso**
La opción predeterminada es `RebootIfNeeded`. Asegúrese de seleccionar la opción correcta para su caso de uso. Por ejemplo, si los nodos administrados deben reiniciarse inmediatamente para completar un proceso de configuración, elija `RebootIfNeeded`. O bien, si necesita mantener la disponibilidad de los nodos administrados hasta una hora de reinicio programada, elija `NoReboot`.
**importante**
No recomendamos el uso de Patch Manager para revisar las instancias de clústeres en Amazon EMR (antes denominado Amazon Elastic MapReduce). En concreto, no seleccione la opción `RebootIfNeeded` para el parámetro `RebootOption`. (Esta opción está disponible en los documentos de SSM Command para implementar revisiones `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation`, y `AWS-RunPatchBaselineWithHooks`).
Los comandos subyacentes para implementar revisiones mediante el uso de Patch Manager y los comandos `yum` y `dnf`. Por lo tanto, las operaciones generan incompatibilidades debido a la forma en que se instalan los paquetes. Para obtener información sobre los métodos preferidos para actualizar el software en los clústeres de Amazon EMR, consulte [Uso de la AMI predeterminada para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) en la *Guía de administración de Amazon EMR*.
RebootIfNeeded
Cuando se elige la opción `RebootIfNeeded`, el nodo administrado se reinicia en cualquiera de los siguientes casos:
+ Patch Manager instaló una o más revisiones.
Patch Manager no evalúa si la revisión *requiere* llevar a cabo un reinicio. El sistema se reinicia aunque la revisión no requiera el reinicio.
+ Patch Manager detecta uno o más revisiones con un estado de `INSTALLED_PENDING_REBOOT` durante la operación `Install`.
El estado `INSTALLED_PENDING_REBOOT` puede indicar que la opción `NoReboot` se seleccionó la última vez que se ejecutó la operación `Install` o que se instaló un parche por fuera de Patch Manager desde la última vez que se reinició el nodo administrado.
El reinicio de los nodos administrados en estos dos casos garantiza que los paquetes actualizados se eliminen de la memoria y mantiene un comportamiento de aplicación de revisiones y reinicio consistente en todos los sistemas operativos.
NoReboot
Cuando elige la opción `NoReboot`, Patch Manager no reinicia un nodo administrado aunque haya instalado revisiones durante la operación `Install`. Esta opción es útil si sabe que los nodos administrados no requieren reinicio después de aplicar las revisiones, o si dispone de aplicaciones o procesos que se ejecutan en un nodo que no deberían verse interrumpidos como consecuencia del reinicio de una operación de aplicación de revisiones. También es útil cuando se desea tener más control sobre el tiempo de los reinicios del nodo administrado, por ejemplo, mediante un periodo de mantenimiento.
Si elige la opción `NoReboot` y se ha instalado una revisión, se asigna a la revisión un estado de `InstalledPendingReboot`. Sin embargo, el nodo administrado en sí mismo está marcado como `Non-Compliant`. Una vez que se produce un reinicio y se ejecuta una operación `Scan`, el estado del nodo se actualiza a `Compliant`.
**Archivo de seguimiento de instalación de revisiones**: para realizar un seguimiento de la instalación de revisiones, especialmente las instaladas desde el último reinicio del sistema, Systems Manager mantiene un archivo en el nodo administrado.
**importante**
No elimine ni modifique el archivo de seguimiento. Si este archivo se elimina o está dañado, el informe de conformidad de revisiones para el nodo administrado es inexacto. Si esto sucede, reinicie el nodo y ejecute una operación de análisis de revisiones para restaurar el archivo.
Este archivo de seguimiento se almacena en las siguientes ubicaciones de los nodos administrados:
+ Sistemas operativos Linux:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows ServerSistema operativo :
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### Nombre del parámetro: `PreInstallHookDocName`
**Usage**: opcional.
**Valor predeterminado**: `AWS-Noop`.
El valor que se debe proporcionar para el parámetro `PreInstallHookDocName` es el nombre o el nombre de recurso de Amazon (ARN) de un documento de SSM de su elección. Puede proporcionar el nombre de un documento administrado por AWS o el nombre o ARN de un documento de SSM personalizado que haya creado o que le hayan compartido. (En el caso de un documento de SSM que le hayan compartido desde una Cuenta de AWS diferente, deberá especificar el ARN completo del recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
El documento de SSM que se especifica se ejecuta antes de la operación `Install` y lleva a cabo cualquier acción admitida por SSM Agent, como un script de shell que verifique la comprobación de estado de la aplicación antes de implementar revisiones en el nodo administrado. (Para ver la lista de acciones, consulte [Referencia de complementos del documento de comandos](documents-command-ssm-plugin-reference.md)). El nombre del documento de SSM predeterminado es `AWS-Noop`, el cual no realiza ninguna operación en el nodo administrado.
Para obtener información acerca de cómo crear un documento de SSM personalizado, consulte [Crear contenido en el documento de SSM](documents-creating-content.md).
### Nombre del parámetro: `PostInstallHookDocName`
**Usage**: opcional.
**Valor predeterminado**: `AWS-Noop`.
El valor que se debe proporcionar para el parámetro `PostInstallHookDocName` es el nombre o el nombre de recurso de Amazon (ARN) de un documento de SSM de su elección. Puede proporcionar el nombre de un documento administrado por AWS o el nombre o ARN de un documento de SSM personalizado que haya creado o que le hayan compartido. (En el caso de un documento de SSM que le hayan compartido desde una Cuenta de AWS diferente, deberá especificar el ARN completo del recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
El documento de SSM que se especifica se ejecuta después de la operación `Install with NoReboot` y realiza cualquier acción admitida por SSM Agent, como un script de shell que permite instalar actualizaciones de terceros antes de proceder al reinicio. (Para ver la lista de acciones, consulte [Referencia de complementos del documento de comandos](documents-command-ssm-plugin-reference.md)). El nombre del documento de SSM predeterminado es `AWS-Noop`, el cual no realiza ninguna operación en el nodo administrado.
Para obtener información acerca de cómo crear un documento de SSM personalizado, consulte [Crear contenido en el documento de SSM](documents-creating-content.md).
### Nombre del parámetro: `OnExitHookDocName`
**Usage**: opcional.
**Valor predeterminado**: `AWS-Noop`.
El valor que se debe proporcionar para el parámetro `OnExitHookDocName` es el nombre o el nombre de recurso de Amazon (ARN) de un documento de SSM de su elección. Puede proporcionar el nombre de un documento administrado por AWS o el nombre o ARN de un documento de SSM personalizado que haya creado o que le hayan compartido. (En el caso de un documento de SSM que le hayan compartido desde una Cuenta de AWS diferente, deberá especificar el ARN completo del recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
El documento de SSM que se especifica se ejecuta después de la operación de reinicio del nodo administrado y lleva a cabo cualquier acción admitida por SSM Agent, como un script de shell que compruebe el estado del nodo una vez completada la operación de aplicación de revisiones. (Para ver la lista de acciones, consulte [Referencia de complementos del documento de comandos](documents-command-ssm-plugin-reference.md)). El nombre del documento de SSM predeterminado es `AWS-Noop`, el cual no realiza ninguna operación en el nodo administrado.
Para obtener información acerca de cómo crear un documento de SSM personalizado, consulte [Crear contenido en el documento de SSM](documents-creating-content.md).