← Casos
Logística transfronteriza · 2025

Diseño de un framework de auditoría recurrente para infraestructura AWS

Diseño de un sistema de revisión recurrente que cubre costo, seguridad, confiabilidad, base de datos e higiene sobre una infraestructura AWS, con ejecución estructurada y reporte basado en evidencia.

Rol Senior DevOps Engineer & AWS Solutions Architect
5 (costos, seguridad, confiabilidad, DB, higiene)
Pilares de auditoría
On-demand + programada
Cadencia
Hallazgos respaldados por API
Modelo de evidencia
AWSAWS CLIBashPythonCloudWatchClaude Code

El problema

Una infraestructura AWS en evolución continua genera preguntas operativas recurrentes que se benefician de una revisión periódica:

  • ¿Los servicios siguen right-sized después de los últimos cambios de carga?
  • ¿Hay alguna política IAM más permisiva de lo necesario?
  • ¿Los backups se están tomando y probando como se espera?
  • ¿Hay algún dato almacenado sin encriptar por accidente?
  • ¿Hay funciones Lambda fuera de la VPC que no deberían estarlo?
  • ¿Hay log groups de CloudWatch acumulando storage sin políticas de retención?

Cada una se puede responder con la consola AWS, pero hacerlo consistentemente entre múltiples entornos requiere esfuerzo sostenido. Las preguntas tienden a des-priorizarse hasta que algún problema sale a la luz.

El framework

Diseñé el framework alrededor de cinco pilares del Well-Architected Framework, cada uno con alcance definido y enfoque de verificación:

  • Costos — EC2, ECS/Fargate, RDS, Lambda, S3, networking y storage. Cruzado con utilización de CloudWatch para identificar oportunidades de right-sizing.
  • Seguridad — IAM, RDS, S3, Lambda, networking, encryption y postura de servicios de seguridad.
  • Base de datos — métricas RDS CloudWatch en la fase remota, con revisión detallada opcional (SSH + MySQL) para slow queries, deadlocks y eventos problemáticos.
  • Confiabilidad — backups, alarmas, estabilidad de servicios, ENI limits, health checks y configuración de failover.
  • Higiene — recursos huérfanos, malas configuraciones, lifecycle policies faltantes y acumulación innecesaria de storage.

El framework requiere que cada hallazgo esté respaldado por una llamada API real como evidencia. Ningún hallazgo se acepta en el reporte sin una fuente verificable. Esta regla se aplica de forma consistente sin importar la herramienta que ejecuta el check.

Implementación

El framework se ejecuta mediante una combinación del AWS CLI, scripts en Bash y Python, y un set de comandos de Claude Code que automatizan la recolección de datos sobre el alcance definido. La decisión de usar ejecución asistida por IA fue deliberada: elimina la fricción de correr los checks manualmente cada vez, manteniendo el contrato (hallazgos basados en evidencia) impuesto por el framework mismo, no por la herramienta.

El loop de juicio se mantiene humano en todo momento:

  • Yo diseño y actualizo el framework, incluyendo qué checks pertenecen a qué pilar y cómo se asigna la severidad.
  • La capa de ejecución (cualquier herramienta) solo recolecta y reporta contra las reglas del framework.
  • Yo reviso cada reporte, priorizo según contexto, y decido qué se implementa.
01 · trigger on-demand · programada /aws-audit agente orchestrator 02 · agentes especializados · iam read-only costos ec2 · ecs · rds s3 · lambda seguridad iam · encryption net · acceso público database rds metrics · slow queries · deadlocks confiabilidad backups · alarmas eni · failover higiene huérfanos · lifecycle log retention contrato :: verificar cada hallazgo contra una llamada API real antes de reportar 03 · síntesis ~20 min · markdown reporte de auditoría · por severidad critical · high · medium · low — ARN del recurso API call de verificación — — estado actual API call para aplicar —

Cómo funciona un audit run

Un run usa acceso IAM read-only y produce un reporte Markdown agrupado por severidad:

  • Critical — requiere atención inmediata
  • High — debería atenderse durante la semana
  • Medium — item de backlog
  • Low — oportunidad de mejora

Cada hallazgo incluye:

  • ARN exacto del recurso AWS
  • Estado actual, con la llamada API para verificarlo
  • Fix recomendado, con la llamada API para aplicarlo
  • Breve explicación de por qué importa

Restricciones operativas

  • La ejecución opera con permisos IAM read-only. Cualquier paso de apply es una acción manual explícita.
  • Cada hallazgo referencia una llamada API real como evidencia. Es un requerimiento del framework, no una opción a nivel herramienta.
  • Todo output se revisa manualmente antes de actuar. La ejecución automatizada acelera la recolección de datos; la priorización e implementación las decide el operador.

Resultado

El ciclo de auditoría que antes era inconsistente ahora corre de forma confiable entre todos los entornos. Los hallazgos están documentados con pasos de verificación reproducibles, lo cual hace el proceso de revisión auditable y los fixes trazables. El framework define qué se revisa, cómo se asigna severidad y qué evidencia se requiere. La velocidad de ejecución es un beneficio de la implementación; la integridad de la auditoría viene de la estructura del framework.