Bastión reproducible y sin claves

Audité el bastión de una plataforma en AWS y definí cómo reconstruirlo desde código, en lugar de seguir clonando una máquina única e indocumentada.

El punto de partida

El bastión es la puerta de entrada a la infraestructura, y había crecido como un snowflake. Tenía un volumen sobredimensionado, crons editados a mano y scripts que no coincidían con los del repositorio. También servicios cuya necesidad real nadie había confirmado.

Reconstruirlo o reducir su coste sin entender ese estado era un riesgo directo.

Qué hice

El objetivo no era apagarlo y clonarlo más pequeño. Era convertirlo en algo reproducible desde código, y sacar antes lo que no debía perpetuarse.

Inventarié su estado real, detecté el drift respecto al repositorio y diseñé una reconstrucción con bootstrap y Terraform.

Cómo lo hice

Inventario por SSM

Capturé el runtime con SSM, sin abrir accesos extra. Revisé el uso real del disco, los servicios habilitados, los crons de backup y sincronización a S3, y un catálogo de scripts con propietario, permisos y hash.

Drift contra el repo

Comparé por hash los scripts de la máquina con los versionados, y no coincidían. Algunos servicios que se daban por necesarios no hacían nada, y había crons que apuntaban a scripts inexistentes. Conclusión: aún no se podía recrear desde el repositorio, porque no era la fuente de verdad.

Datos y secretos

Separé el payload operativo (backups, dumps) del estado del bastión. Los secretos no podían acabar en una AMI ni en Terraform, así que el plan los lleva a Secrets Manager o SSM Parameter Store, y el acceso a SSM Session Manager.

Reconstrucción por pasos

El bastión actual queda solo como fuente de evidencia:

1. Aprobar el estado real con un diff redactado contra el repo.
2. Llevar scripts, crons y servicios a Terraform y bootstrap.
3. Construir un bastión nuevo con volumen gp3 de tamaño validado.
4. Copiar solo el estado que se quiera conservar a propósito.
5. Mover el endpoint y validar acceso, crons, backups, runner y SSM.
6. Mantener la instancia antigua para rollback durante la validación.

Resultado

El estado real del bastión quedó inventariado y auditado, con un baseline reproducible y un plan de reconstrucción segura.

El baseline incluye AMI y bootstrap, SSM online, IAM con Session Manager, volumen correcto, scripts instalados desde fuente versionada y crons gestionados por IaC.

Qué me llevo

Clonar el volumen a uno menor era lo más rápido y lo más fácil de revertir, pero habría perpetuado el drift y los scripts manuales. Usar la máquina vieja como evidencia, y no como plantilla, es lo que permite llegar a una infraestructura reproducible.

Arquitectura

bastión actual (evidencia) → inventario SSM → Terraform + bootstrap + gestor de secretos → bastión nuevo → validación → rollback disponible