Una empresa ejecuta una aplicación de ingesta de datos sensibles en varias cuentas de AWS (en AWS Organizations). Las instancias EC2 en grupos de Auto Scaling utilizan una AMI personalizada y no tienen acceso a Internet; los VPC endpoints necesarios están implementados. Los administradores necesitan acceso automatizado y controlado centralmente para iniciar sesión en las instancias para mantenimiento y resolución de problemas, y el equipo de seguridad debe ser notificado cada vez que se accede a las instancias. ¿Qué solución satisface estos requisitos?

La opción correcta cumple todos los requisitos. EC2 Image Builder permite reconstruir la AMI con el SSM Agent, esencial para Session Manager. Adjuntar el rol AmazonSSMManagedInstanceCore al grupo de Auto Scaling otorga los permisos necesarios para que Session Manager funcione. Session Manager proporciona acceso seguro y controlado sin acceso a Internet. Habilitar el registro de sesiones en S3 y configurar una notificación de evento de S3 a un tema de SNS asegura que el equipo de seguridad sea notificado sobre los accesos. Las opciones incorrectas fallan por varias razones: La primera opción usa EC2 Instance Connect, que requiere acceso de red SSH, y cfn-init para rutas de VPC, lo cual es innecesario con Session Manager y los VPC endpoints ya establecidos. La segunda opción introduce un NAT gateway y un bastion host, lo cual es una solución más compleja y menos segura que Session Manager para entornos sin acceso a Internet, y los hooks del ciclo de vida de Auto Scaling no son el mecanismo principal para auditoría de sesiones. La cuarta opción propone integrar SSM Agent con Systems Manager Automation, lo cual es menos directo que Image Builder para reconstruir la AMI, y usar AWS Config para adjuntar un SCP a la cuenta raíz para permitir que las instancias lleguen a Systems Manager es incorrecto; los permisos se otorgan a través de roles de IAM.