Diseño de solución de parches para múltiples AWS cuentas y regiones

Puede ampliar la solución de parches automatizados para que sea compatible con servidores que abarquen varias AWS cuentas y varias regiones. AWS La solución ampliada implica configurar la solución de automatización de parches en cada AWS cuenta a través AWS CloudFormation StackSets de una cuenta de servicios compartidos y configurar una sincronización de datos de recursos entre las cuentas con la cuenta de servicios compartidos.

Proceso automatizado

En el siguiente diagrama se ilustra la arquitectura de este escenario. Esta arquitectura incluye AWS CloudFormation StackSets una cuenta de servicio AWS compartida.

El flujo de trabajo es similar al proceso descrito en la sección anterior, pero incluye los siguientes pasos adicionales, en los que los números de los pasos coinciden con los rótulos del diagrama:

1. En la cuenta de servicios compartidos, se utiliza un conjunto de AWS CloudFormation pilas para configurar el depósito de S3 para la sincronización de los datos de los recursos a través de Systems Manager Inventory.

2. El conjunto de CloudFormation pilas crea la pila con la función automate-patch Lambda, configura las líneas base de los parches y configura la sincronización de datos de recursos de inventario de Systems Manager en las cuentas de la aplicación para sincronizar los recursos de la cuenta de servicios compartidos.

3. La información de recursos de las cuentas de la aplicación se sincroniza con la información de recursos de la cuenta de servicios compartidos.

4. QuickSight genera informes de conformidad con los parches utilizando el conjunto de datos de Amazon Athena para la información de recursos sincronizada.

Condiciones y limitaciones de la arquitectura

Tiempos de mantenimiento por cuenta

La arquitectura ilustrada y descrita en la sección anterior crea una ventana de mantenimiento para cada grupo de revisiones. Sin embargo, la cuota de períodos de mantenimiento por cuenta de AWS es de 50 (suponiendo que no haya solicitado un aumento de la cuota de servicio). Si espera que el número de grupos de parches supere los 50 grupos en una sola AWS cuenta, esta arquitectura no se adaptará a sus necesidades.

Si un aumento de la cuota de servicio no es suficiente para sus necesidades, existen dos opciones para gestionar este desafío: utilizar períodos de mantenimiento predefinidos y utilizar CloudWatch Events. Aquí están las ventajas y desventajas de cada enfoque.

Opción 1. Utilice ventanas de mantenimiento predefinidas

• Defina una lista de períodos de mantenimiento con varios intervalos de tiempo (por ejemplo, de 15 a 20 períodos de mantenimiento por cuenta).

• Los equipos de aplicaciones eligen los períodos de mantenimiento que más les convengan de la lista predefinida y etiquetan las instancias en consecuencia.

• Actualice la solución de revisiones automatizada para asignar los grupos de revisiones a las ventanas de mantenimiento seleccionadas, en lugar de crear nuevas ventanas de mantenimiento.

Ventajas:

• Administración simplificada.

Desventajas:

• Menor flexibilidad para definir ventanas de mantenimiento personalizadas.

• Cuando varios grupos de revisiones comparten períodos de mantenimiento y tareas de revisiones, cancelar una tarea de revisión específica para un grupo de revisiones específico requiere un esfuerzo manual adicional.

Opción 2. Utilice CloudWatch los eventos para activar las tareas de parches en lugar de utilizar las ventanas de mantenimiento

• En lugar de crear ventanas de mantenimiento, utilice CloudWatch los eventos para activar las tareas de parches en función de la programación y los grupos de parches.

• En este escenario, cada grupo de parches está asociado a un evento de CloudWatch eventos en lugar de a una ventana de mantenimiento.

• Actualice la solución de revisiones automatizada para crear eventos en lugar de ventanas de mantenimiento.

Ventajas:

• Diseño escalable.

• Proporciona flexibilidad para definir ventanas de mantenimiento personalizadas.

Desventajas:

• Los períodos de mantenimiento proporcionan funciones adicionales (como la duración y las horas límite) que no están disponibles en los CloudWatch eventos.

Otras consideraciones

• La solución de parches automatizados que se describe en esta sección no admite EC2 las instancias que están cerradas.

• Este proceso admite EC2 instancias en subredes públicas. Para aplicar revisiones a las instancias en subredes privadas, debe implementar un repositorio de revisiones local, como Windows Server Update Services (WSUS).

• Debe ajustar la frecuencia de ejecución de la función de Lambda para que los grupos de revisiones y las ventanas de mantenimiento se actualicen según la programación requerida.