El problema: una máquina crítica e irreproducible

El bastión —la puerta de entrada a la infraestructura de producción— había crecido como un snowflake: volumen root sobredimensionado, crons editados a mano, scripts que no coincidían con los del repositorio, secretos en disco y servicios cuya necesidad real nadie había confirmado. Reconstruirlo o reducir su coste sin entender ese estado era un riesgo directo sobre producción.

El objetivo no fue "apagar y clonar más pequeño", sino convertir esa máquina en algo reproducible desde código, sacando antes lo que no debía perpetuarse.

Inventario del estado real (vía SSM)

Usé SSM para capturar el runtime sin abrir accesos extra, y documenté lo que de verdad estaba pasando en la instancia:

• Almacenamiento: volumen root muy por encima del uso real (uso efectivo de un solo dígito de decenas de GiB), con los datos mutables concentrados en el home del usuario.
• Servicios: qué corría y estaba habilitado de verdad (runner de CI, Docker, cron, agente SSM…) frente a lo que se asumía necesario — Supervisor, por ejemplo, no gestionaba ningún proceso.
• Crons: tareas reales de backup y sincronización a S3, incluyendo referencias a scripts que ya no existían en la máquina.
• Scripts: catálogo con propietario, permisos y hash de cada script operativo, para poder compararlos con el repositorio.

Hallazgos de seguridad y drift

• Secretos en disco: credenciales de AWS, claves SSH privadas, config del runner de CI y config de sincronización. Nada de eso puede acabar horneado en una AMI ni commiteado en Terraform.
• Drift de scripts: los scripts versionados en el repositorio no coincidían (por hash) con los que de verdad corrían en la máquina, y algunas versiones del repo aún tenían credenciales y endpoints hardcodeados.
• Datos vs configuración: directorios de backups y dumps eran payload operativo, no estado inmutable del bastión — no debían tratarse como parte de la imagen.

Conclusión inmediata: no recrear el bastión desde el repo actual todavía, porque el repositorio aún no era la fuente de verdad.

Estrategia de reconstrucción segura

El trade-off importante: encoger clonando el volumen actual a uno menor es lo más rápido y seguro de revertir, pero perpetúa el drift, los secretos locales y los scripts manuales. Reconstruir directo desde Terraform sin capturar antes las piezas reales es demasiado arriesgado. La secuencia adoptada usa el bastión actual solo como fuente de evidencia:

1. Inventariar y aprobar el estado runtime real (diff redactado de scripts contra el repo).
2. Llevar scripts, crons y setup de servicios a Terraform / bootstrap.
3. Mover secretos a Secrets Manager o SSM Parameter Store (runner de CI, credenciales AWS, config de sincronización, claves SSH → preferir SSM Session Manager).
4. Construir un bastión nuevo con volumen gp3 de tamaño validado.
5. Copiar solo el mínimo estado runtime que se quiera preservar de forma intencionada.
6. Reasignar la IP elástica / actualizar el endpoint y validar acceso, cron, backups, runner y SSM.
7. Mantener la instancia/AMI antigua para rollback durante la ventana de validación.

Resultado e impacto

• Estado real del bastión inventariado y auditado: servicios, crons, scripts críticos, secretos y drift respecto al repositorio.
• Baseline reproducible definido (AMI/bootstrap + Terraform): SSM online, IAM con Session Manager, volumen correcto, scripts instalados desde fuente versionada y crons gestionados por IaC.
• Plan de reconstrucción segura que elimina credenciales embebidas y deriva manual, en vez de clonar para siempre una máquina única.

Es trabajo de fiabilidad y gobernanza: seguridad operativa, gestión de secretos, AMI/bootstrap y deuda técnica real en un entorno vivo.