Automatización operativa con Systems Manager
Operaciones de día 2 a escala: llegar a una flota por Systems Manager en lugar de SSH, mantener los nodos parchados y su configuración sin deriva, centralizar la configuración en Parameter Store, y conectar el trabajo rutinario a eventos y cronogramas.
Los temas anteriores construyeron y desplegaron infraestructura. Este trata de los servidores que ya están corriendo y del trabajo que nunca termina: llegar a ellos, parcharlos, sostener su configuración en su lugar, y automatizar las partes de la semana que se repiten. También es el tema donde una sola base sostiene todo lo demás, porque ninguna herramienta de Systems Manager funciona hasta que una instance es un managed node, y la mayoría de las fallas de esta área son esa condición sin cumplir.
Qué cubre este tema
- Las 3 condiciones que convierten una instance EC2 en managed node, y el orden de diagnóstico que encuentra la rota más rápido
- Instance profiles contra Default Host Management Configuration, incluido el permiso que hace que uno anule al otro en silencio
- Session Manager como reemplazo de las llaves SSH y los bastion hosts, y las sesiones a las que su logging no llega
- Targeting de Run Command por ID, tag y resource group, con los defaults de concurrencia y umbral de errores que deciden cómo se comporta un comando de toda la flota
- Fleet Manager e Inventory, y el resource data sync que hace consultable el inventario entre cuentas
- Patch Manager: Scan contra Install, las reglas de aprobación de un baseline y su demora de 7 días, cómo un patch group resuelve a un baseline, y los estados de compliance con la opción de reinicio detrás
- Maintenance windows con duración y cutoff, patch policies para una organización, y associations de State Manager para configuración que se vuelve a poner sola
- Parameter Store: los 3 tipos, jerarquías y la trampa de los paths en IAM, tiers, policies, versiones y labels, el techo de 40 TPS, y las dynamic references de CloudFormation
- S3 Event Notifications, EventBridge Scheduler, y dónde debería vivir un cronograma operativo
- Change Calendar como el guardarraíl que le dice a la automatización en curso que se quede quieta
Por qué importa
El dominio 3 pesa 22% del SOA-C03, y este tema aporta las preguntas que se leen como un caso de soporte y no como un ejercicio de diseño: una instance que no aparece en la consola, un patch publicado ayer que no se instaló, un nodo que reporta compliant mientras le falta un patch crítico, una aplicación con throttling en las lecturas de configuración justo cuando escala. Cada una tiene un setting concreto detrás.
La presión del trabajo tiene la misma forma. La diferencia entre un equipo de operaciones que escala y uno que no es si el trabajo rutinario se describe una vez y lo aplica un servicio, o lo ejecuta una persona que tiene que acordarse.