Cloud cost anomaly detection

Cloud cost anomaly detection es un pipeline que cierra el gap entre la facturación en la nube y la reacción operativa del equipo.

Cost Explorer y los dashboards del proveedor muestran el panorama solo cuando el ingeniero entra y lo revisa. En dos o tres semanas, un recurso olvidado se convierte en una factura de miles de dólares, y a fin de mes el departamento de finanzas hace preguntas a las que ya es tarde para responder.

Qué hace la automatización

1. Extrae datos de gastos del proveedor en la nube (AWS Cost and Usage Report, GCP Billing Export, Azure Cost Management) con daily granularity.
2. Desglosa los gastos por segmentos: servicio, región, etiqueta, equipo, environment, según la política de tagging establecida.
3. Construye un baseline de consumo a partir de datos históricos de 7–30 días, teniendo en cuenta la estacionalidad y los patrones weekday/weekend.
4. Detecta anomalías en cada segmento mediante un modelo estadístico (z-score, IQR o Prophet; la elección depende de la naturaleza de los datos).
5. Genera un mensaje legible por humanos del tipo «EC2 en us-east-1 está significativamente por encima del baseline: revisa el grupo de autoscaling prod-api».
6. Envía una alerta en Slack, Microsoft Teams o por email al ingeniero responsable con un enlace directo a la sección correspondiente de Cost Explorer.
7. Mantiene un hilo de comentarios: quién tomó la tarea, cuál fue la causa, si se trató de un aumento real de carga o de una fuga de configuración.
8. Guarda el historial de incidentes para el análisis posterior y para el entrenamiento del modelo con false positive y true positive reales.

Para los equipos SaaS con 10–200 ingenieros, la automatización reemplaza el informe manual semanal y el rol del ingeniero de FinOps de guardia que «casualmente detectó» la anomalía.

Qué NO hace la automatización

• No bloquea ni desactiva recursos automáticamente. La decisión de reducir gastos la toma una persona: la automatización da una señal, no una acción.
• No reemplaza la estrategia de FinOps: no gestiona presupuestos, no distribuye gastos entre proyectos, no pronostica gastos anuales ni prepara materiales para el CFO.
• No busca oportunidades de optimización (reserved instances, spot, rightsizing) ni emite recomendaciones de arquitectura. Es una tarea relacionada para una automatización separada o consultoría.

La automatización está construida como un ETL-pipeline con alerting. Los proveedores de nube no tienen una API unificada para gastos en real-time, por lo que la solución funciona según el esquema daily batch: el billing se actualiza una vez al día, y esta frecuencia es suficiente para la mayoría de los casos de uso.

Arquitectura del pipeline

1. Fuente de datos. AWS Cost and Usage Report se exporta a S3; GCP Billing, a BigQuery; Azure, a Storage Account. Grow2.ai se conecta al almacenamiento correspondiente mediante un rol read-only.
2. Ingestion. El script (Python o TypeScript) lee las filas recientes del billing, normaliza el esquema y carga en el almacenamiento intermedio (DuckDB, ClickHouse, BigQuery o Postgres, según la infraestructura del cliente).
3. Enriquecimiento con contexto. A los registros se añaden datos del observability-stack: métricas de carga de Prometheus / Datadog, etiquetas de recursos de la nube, información de releases de CI/CD. Esto es necesario para que la alerta contenga no solo «aumentó», sino también «por qué aumentó».
4. Modelo de anomalías. Para cada segmento (servicio × región × etiqueta) se construye un baseline. Para los servicios estables, z-score en rolling window de 14–30 días. Para los servicios con tendencia y estacionalidad, Prophet o equivalente. El umbral de sensibilidad se configura por equipo: porcentaje de desviación respecto al valor esperado más incremento absoluto mínimo, para no generar ruido con importes pequeños.
5. Generación del narrativo.El modelo de IA o LLM local recibe la raw-anomalía y el contexto y genera un mensaje de texto. El prompt incluye: cifras de desviación, top-3 causas candidatas en base al contexto (release, evento de autoscaling, nueva región), próximos pasos recomendados.
6. Entrega. El mensaje se envía al canal de Slack del equipo o por email. Para anomalías críticas, llamada adicional a PagerDuty u Opsgenie.
7. Feedback loop. En el hilo de Slack el ingeniero marca la alerta como true positive, false positive o known issue. Las etiquetas se guardan y se utilizan para el tuning de los umbrales.

Pasos de implantación

1. Discovery (3–5 días). Grow2.ai realiza una auditoría del billing actual, de las políticas de tagging y de los canales de comunicación. El resultado es una lista de segmentos para monitorización y la definición de los owners.
2. Ingestion setup (2–3 días). Se configura la exportación del billing, se crean las credenciales read-only, se despliega el pipeline de carga.
3. Baseline y modelo (3–4 días). Se entrena el modelo con datos históricos, se ajustan los umbrales. La primera semana, shadow mode: las alertas van únicamente al ingeniero integrador.
4. LLM-narrativo e integración con Slack (1–2 días). Se configura el prompt, se conecta el bot de Slack, se prueban los escenarios.
5. Staging y ajuste para el equipo (2–3 días). Se ajustan los umbrales, se acuerda el canal de entrega, se asignan los responsables.
6. Handoff (1 día). Documentación, runbook, formación del responsable de guardia de la automatización.

Componentes principales

La solución es custom-code: no existe un producto off-the-shelf que funcione de igual manera con distintas políticas de tagging y convenciones internas. El código se despliega en la infraestructura del cliente (Kubernetes, Lambda, Cloud Run, a elección), los datos de billing no salen del perímetro.

Para poner en marcha el cloud cost anomaly detection, el equipo necesita un nivel básico de madurez en FinOps y observability. Sin esto, la automatización se ejecutará igualmente, pero la calidad de las alertas será baja: muchos falsos positivos y poco contexto.

Datos y accesos

• La exportación de facturación está configurada y operativa: AWS Cost and Usage Report en S3, GCP Billing Export en BigQuery o Azure Cost Management export. Sin datos históricos de 14+ días, el modelo no construirá un baseline.
• Acceso Read-only al almacén de facturación mediante un rol IAM o service account.
• Política de tagging mínima en los recursos: al menos una etiqueta que diferencie entornos (prod / staging / dev) y equipos o productos. Sin etiquetas, la automatización funciona solo a nivel de servicios.
• Acceso a Slack, Microsoft Teams o al correo corporativo para la entrega de alertas.
• Opcional: exportación de métricas desde Prometheus, Datadog o CloudWatch para enriquecer el contexto.

Equipo y procesos

• Un ingeniero DevOps o SRE como technical owner de la automatización, responsable del mantenimiento y el ajuste de umbrales.
• Debe quedar claro quién responde a las alertas: el responsable de guardia, un ingeniero concreto o el canal del equipo.
• Disposición para revisar los false positive y ajustar el modelo cada 1–2 semanas durante el primer mes o dos tras el lanzamiento.

Plazos orientativos

La implantación lleva 2–4 semanas según la calidad de los datos de origen. Si la exportación de facturación y las etiquetas ya están configuradas, se acerca a las dos semanas. Si la política de tagging hay que diseñarla desde cero, se acerca a las cuatro.