Una aplicación que se ejecuta en instancias EC2 en un grupo de Auto Scaling detrás de un Application Load Balancer dejó de estar disponible después de un cambio en el security group. Un ingeniero de redes debe implementar un mecanismo que corrija automáticamente los cambios no conformes en el security group para evitar que este tiempo de inactividad se repita. ¿Qué solución satisface este requisito?

La respuesta correcta es crear una regla de AWS Config para detectar cambios no conformes en los security groups y usar un runbook de AWS Systems Manager Automation para corregirlos. AWS Config monitorea continuamente los recursos de AWS y puede evaluar su conformidad con las configuraciones deseadas, lo que lo hace ideal para detectar cambios en los security groups. Una vez que AWS Config detecta una no conformidad, puede activar un runbook de Systems Manager Automation para aplicar automáticamente la configuración correcta, restaurando la disponibilidad de la aplicación. Las opciones incorrectas son: Habilitar Amazon GuardDuty para detectar diferencias y usar un runbook de AWS Systems Manager Automation: GuardDuty es un servicio de detección de amenazas que monitorea actividades maliciosas y comportamientos no autorizados, no está diseñado para detectar desviaciones de configuración de security groups. Crear una regla de AWS Config y usar AWS OpsWorks for Chef: Aunque AWS Config es correcto para la detección, OpsWorks for Chef se utiliza para la automatización de la configuración de servidores y aplicaciones, no para la corrección automática de security groups. Habilitar Amazon GuardDuty y usar AWS OpsWorks for Chef: Ninguno de estos servicios es adecuado para la detección de cambios en la configuración de security groups o su corrección automática.