Tu Arquitectura en AWS Cambió. ¿Sabrías Qué Cambió?
Un entorno de AWS puede cambiar sin que su diagrama de arquitectura cambie junto con él. Una nueva ruta pública, un security group modificado, una dead-letter queue eliminada o un cambio en la configuración de una base de datos pueden ser perfectamente intencionales, pero de todos modos necesitas saber que ocurrió y decidir si importa.
La pregunta útil no es simplemente “¿quién cambió algo?”. Es: ¿en qué se diferencia la arquitectura del estado que previamente entendimos y aceptamos?
El historial de cambios no es lo mismo que un cambio de arquitectura
AWS CloudTrail registra la actividad de la API y es útil para responder preguntas como quién llamó a una API, qué acción intentó y cuándo. El historial de infrastructure as code puede decirte qué pretendía modificar un cambio de CloudFormation, CDK, Terraform o de despliegue.
Ninguno de los dos, por sí solo, te da una comparación arquitectónica limpia.
Una revisión de arquitectura se preocupa por el estado efectivo: recursos, configuración importante, relaciones, exposición, controles de resiliencia y otras propiedades que afectan cómo se comporta el sistema. Eso significa que necesitas una línea base de ese estado y una instantánea posterior para compararla.
Piensa en esto como dos tareas separadas:
- Detectar el delta: ¿Qué recursos, relaciones y configuraciones relevantes son diferentes?
- Explicar el delta: ¿Qué despliegue, actividad de API o decisión operativa causó el cambio?
Mantener esas tareas separadas hace que las investigaciones sean mucho más fáciles.
Un flujo de trabajo práctico para cambios de arquitectura
No necesitas comparar cada propiedad de AWS. Empieza con las partes que pueden cambiar materialmente la seguridad, la confiabilidad, la disponibilidad, el costo o el comportamiento del sistema.
- Captura una línea base conocida. Inventaría los recursos soportados y normaliza los campos de configuración y relaciones que te importan. Registra cuándo se tomó la instantánea.
- Toma una nueva instantánea. Usa el mismo proceso de descubrimiento para que los dos estados sean comparables.
- Calcula diferencias significativas. Clasifica adiciones, eliminaciones, cambios de configuración y cambios de relaciones. Ignora campos transitorios como timestamps a menos que importen para la regla que se está evaluando.
- Evalúa el nuevo estado. Un delta no es automáticamente un problema. Ejecuta verificaciones deterministas sobre la arquitectura actual e identifica si el cambio introdujo o resolvió un hallazgo.
- Correlaciona con el historial. Para un delta interesante, usa CloudTrail, el historial de despliegues y tus registros de gestión de cambios para determinar cómo ocurrió.
- Acepta o remedia. Los cambios intencionales pueden convertirse en la nueva línea base después de la revisión. Los cambios no deseados vuelven al proceso normal de ingeniería.
Esto se parece más a revisar el diff de un pull request que a redibujar periódicamente un diagrama de arquitectura.
Ejemplo: un cambio pequeño con consecuencias arquitectónicas
Supongamos que la instantánea del lunes muestra una aplicación detrás de un load balancer, recursos de cómputo en subredes privadas, una cola con una dead-letter queue (DLQ) y una base de datos que no es accesible públicamente.
El jueves, la siguiente instantánea muestra tres diferencias: una ruta de cómputo ahora es accesible desde internet, la cola ya no tiene su asociación con la DLQ, y una configuración de la base de datos cambió.
Eso es suficiente para activar una revisión, pero no suficiente para asignar culpas o siquiera declarar que cada cambio está mal. La ruta pública pudo haber sido una solución temporal, la cola pudo haber sido reemplazada, y el cambio en la base de datos puede ser deliberado.
Ahora correlaciona el delta con el historial de despliegues y CloudTrail. Puedes distinguir la arquitectura observada de la evidencia que explica cómo llegó ahí. Si la exposición pública viola tus reglas de arquitectura, el hallazgo sigue siendo válido sin importar si el cambio fue intencional.
Qué suele salir mal
El error más grande es tratar cada diferencia de configuración como igualmente importante. Los recursos de AWS contienen mucha metadata operativa; un diff sin filtrar rápidamente se convierte en ruido.
El error opuesto es observar solo el infrastructure as code. Los cambios por consola, scripts, automatización de servicios y recursos fuera de un stack particular pueden hacer que el estado real diverja de lo que sugiere el repositorio.
También existe un trade-off de almacenamiento. Las instantáneas ricas mejoran la comparación histórica y la investigación, pero cuestan más mantener y requieren un manejo cuidadoso de metadata potencialmente sensible. Una implementación práctica almacena solo los campos necesarios para las verificaciones y comparaciones arquitectónicas soportadas.
Finalmente, la detección de cambios no es prevención en tiempo real. Si un requisito nunca debe violarse, usa controles preventivos y guardrails de despliegue. La comparación de instantáneas se usa mejor para hacer visible y revisable el drift.
Haz que el estado de la arquitectura sea algo que puedas comparar
Una imagen de arquitectura confiable debe tener una fecha y una forma repetible de reconstruirse. Captura el estado, compáralo con el estado previamente aceptado, evalúa el delta y luego usa el historial para explicar los cambios importantes.
Si quieres una vista actual e inspeccionable de los recursos de AWS soportados y hallazgos de arquitectura explicables, ArchNube.com está construido alrededor de este problema. Archnube Assess se conecta a través de un rol IAM de solo lectura, estrecho y controlado por el cliente, descubre los recursos soportados y los evalúa con reglas deterministas, sin acceso de escritura a tu cuenta de AWS ni juicio de IA de caja negra.