Monitorización10 de octubre de 2026 10 min de lectura

Alertas de coste en la nube: cómo configurarlas en AAA Sentinel para no llevarte sorpresas en la factura

Enterarse de un pico de gasto a fin de mes es enterarse tarde. Te contamos cómo combinar los presupuestos nativos de AWS, Azure y Google Cloud con las alertas de AAA Sentinel: canales, umbrales, resumen periódico, anomalías y tickets, con un ejemplo completo.

Este artículo también está disponible en:enfrpt

La sorpresa en la factura cloud sigue siempre el mismo guion: se cierra el mes, llega la factura, la cifra es más alta de lo esperado y empieza la investigación. Para entonces, el recurso que se disparó lleva semanas facturando. Las alertas existen para acortar ese tiempo, pero sólo funcionan si avisan pronto, a la persona adecuada y con algo concreto que hacer. En este artículo te contamos cómo montarlas con AAA Sentinel y con los presupuestos nativos de cada nube, que se complementan.

El problema: una sola alerta, y tarde

Muchos equipos tienen, como mucho, un aviso cuando el gasto del mes alcanza el presupuesto. Cuando llega, el mes ya está gastado y sólo queda explicar qué pasó. Otros tienen alertas que llegan a un buzón que nadie mira, o tantas que el equipo ha aprendido a ignorarlas.

Una única alerta al 100 % del presupuesto es como una alarma que sólo suena cuando el robo ya ha terminado.

Qué ganas con ello

Con las alertas bien repartidas por capas:

  • Ves un pico de gasto en el escaneo siguiente, no en la factura.
  • Cada aviso llega al canal donde el equipo trabaja: correo, Slack o un sistema propio.
  • Lo que hay que arreglar acaba como ticket en Jira o Linear, con dueño y prioridad.
  • Quien no necesita el detalle recibe un resumen diario o semanal en lugar de cada alerta.

Lo primero: AAA Sentinel no sustituye a los presupuestos de tu nube

Conviene decirlo claro: AAA Sentinel no tiene presupuestos de nube. No fija un techo mensual por cuenta ni avisa al 80 % de un importe. Los presupuestos que gestiona son los de IA, que es otra historia. Para el techo mensual, usa el presupuesto nativo de cada proveedor, que tiene sus datos de facturación de primera mano. AAA Sentinel aporta lo que el presupuesto no ve: subidas entre escaneos, hallazgos nuevos que explican la subida, anomalías por servicio y un único sitio para avisar de las tres nubes.

La estrategia en tres capas

Esta es la combinación que recomendamos:

  • Capa 1 · El techo del mes: un presupuesto nativo en cada nube, con avisos sobre el gasto previsto y el real (por ejemplo, al 80 % previsto y al 100 % real). Te dice si el mes va camino de pasarse.
  • Capa 2 · Las desviaciones: la alerta de picos de gasto de AAA Sentinel, que compara cada escaneo con el anterior, y el informe de anomalías, que baja al detalle de cada servicio.
  • Capa 3 · Las causas: las alertas de hallazgos nuevos críticos o de prioridad alta, que llegan con el recurso concreto y pueden abrir un ticket solas.

Capa 1: los presupuestos nativos en cada nube

Los tres proveedores lo resuelven de forma parecida:

  • AWS: AWS Budgets, en Billing and Cost Management. Presupuestos de coste por cuenta, servicio o etiqueta, con avisos sobre el gasto real o el previsto por correo o Amazon SNS. Para picos inesperados, AWS Cost Anomaly Detection usa aprendizaje automático y avisa por los mismos medios.
  • Azure: Cost Management → Presupuestos. Por suscripción o grupo de recursos, con condiciones de alerta sobre el coste real o el previsto, que avisan por correo o disparan un grupo de acciones. Cost Management ofrece además alertas de anomalías por suscripción.
  • Google Cloud: Facturación → Presupuestos y alertas. Reglas de umbral sobre el gasto real o el previsto (por defecto al 50, 90 y 100 %), con correo a los administradores de facturación y Pub/Sub si quieres automatizar algo.

Un presupuesto avisa, no corta el gasto. Si quieres una reacción automática, AWS Budgets tiene acciones de presupuesto, Azure puede lanzar un grupo de acciones y en Google Cloud se programa a partir del mensaje de Pub/Sub.

Cómo funcionan las alertas de AAA Sentinel

Las alertas se generan en los planes Pro y Business, al terminar cada escaneo de cada cuenta. En esos planes el escaneo es automático y diario, así que, en la práctica, la plataforma revisa cada cuenta una vez al día. Esto es lo que puede disparar un aviso:

AAA Sentinel · qué dispara cada alerta

Picos de gasto
El coste que registra el escaneo sube respecto al escaneo anterior al menos el umbral fijado, y supera el gasto mínimo. Severidad alta, o crítica si la subida llega al 50 %
Nuevos hallazgos críticos
El escaneo trae algún hallazgo nuevo (o es el primero de la cuenta): un aviso con los hallazgos críticos
Nuevos hallazgos de alta prioridad
Igual, con los de prioridad alta y el ahorro que suman
Coste unitario al alza
Aviso mensual si sube el coste por unidad de negocio (plan Business, requiere métricas de negocio)
Hallazgos de seguridad nuevos y Bajada del Security Score
Avisos del escaneo de postura de seguridad
  • Cada alerta se guarda en Alertas durante 90 días, se haya enviado o no a algún canal.
  • Las conexiones de IA usan los mismos interruptores: un pico de gasto o un presupuesto de IA a punto de agotarse también llega como alerta.

Caso práctico: ACME

ACME, una empresa ficticia con el plan Pro, tiene tres cuentas conectadas: su tienda en AWS, una suscripción de Azure y un proyecto de Google Cloud. Quiere enterarse en el día de cualquier subida seria y que lo accionable acabe en Jira. Esta es su configuración:

ACME · configuración de alertas

Email
Activado: llega al correo de quien guarda la configuración
Slack
Webhook del canal #finops-alertas
Umbral de pico de gasto
25 %
Gasto mínimo para alertar
100 USD/mes
Resumen periódico
Semanal, los lunes a las 07:00 UTC
Jira
Proyecto FINOPS, alertas de severidad Alta o superior
AWS Budgets (en AWS)
6.000 USD/mes, aviso al 80 % previsto y al 100 % real

Paso 1: conectar los canales

Todo se configura en Alertas → Canales de alerta, que sólo pueden cambiar el propietario y los administradores. Cada canal tiene su botón de prueba: úsalo antes de dar nada por bueno.

  • Email: se activa con un interruptor y envía al correo con el que accede a AAA Sentinel la persona que guarda la configuración.
  • Slack: en api.slack.com/apps crea una app, activa Incoming Webhooks, pulsa «Add New Webhook to Workspace», elige el canal y copia la URL, que empieza por hooks.slack.com. Pégala en «Webhook URL de Slack» y pulsa «Probar webhook».
  • Microsoft Teams: en el canal, abre Más opciones → Workflows, elige la plantilla «Enviar alertas de webhook a un canal», confirma equipo y canal, guarda y copia la URL. Lleva una firma dentro: trátala como una contraseña. Las URL de los antiguos connectors de Office 365 (webhook.office.com) se rechazan, porque Microsoft los apagó en mayo de 2026.
  • Webhook genérico: una URL HTTPS pública (las direcciones de red interna se rechazan) que recibe un POST JSON con el tipo, la severidad, el título, el mensaje, la cuenta y el escaneo. Si necesitas que vaya firmado, los webhooks de Developer → Aplicaciones OAuth2 emiten el evento alert.triggered con la cabecera X-Sentinel-Signature.

Paso 2: ajustar los umbrales de detección

En la misma página, el bloque Umbrales de detección decide cuándo merece la pena avisar:

  • Umbral de pico de gasto: entre el 5 y el 100 %, en pasos de 5; por defecto, 20 %.
  • Gasto mínimo para alertar: de 0 a 1.000 USD/mes; por defecto, 5. Evita avisos en cuentas casi vacías.
  • Subida del coste unitario: entre el 5 y el 100 %; por defecto, 20 %. Sólo aplica si usas coste unitario.
  • Notificar cuando se detecten: un interruptor por tipo (Nuevos hallazgos críticos, Nuevos hallazgos de alta prioridad, Picos de gasto, Hallazgos de seguridad nuevos, Bajada del Security Score y Coste unitario al alza). Todos vienen activados.

En AWS, en Azure y en Google Cloud con exportación de facturación, el coste que lee cada escaneo es el acumulado del mes en curso. Para que ese crecimiento natural no parezca un pico, AAA Sentinel compara el ritmo diario de gasto de cada escaneo, proyectado al mes completo, y así el cambio de mes tampoco parece una caída. Durante los tres primeros días del mes no hay base suficiente y no se evalúan picos, igual que cuando uno de los dos escaneos usa costes estimados y el otro reales.

Paso 3: el resumen periódico

No todo el mundo necesita cada alerta. El Resumen periódico es un correo diario o semanal (eliges el día de la semana y la hora de envío, en UTC) con el coste del último escaneo, los hallazgos, el ahorro potencial y cuántas alertas críticas y altas hubo en el periodo. Se envía por cuenta y sólo si hubo algún escaneo completado en ese periodo. ACME lo programa los lunes a las 07:00 UTC para dirección, y deja las alertas en tiempo real para el equipo de plataforma.

Paso 4: de la alerta al ticket

El día 14, el escaneo de la cuenta de AWS de ACME registra 3.100 USD frente a los 2.400 USD del escaneo anterior: una subida del 29 %. Como supera el 25 % y el mínimo de 100 USD, salta un pico de gasto de severidad alta. Esto es lo que pasa a continuación:

  • Llega el aviso al correo y a #finops-alertas, con un enlace a la plataforma.
  • Como Jira está configurado para severidad Alta o superior, se crea un ticket en el proyecto FINOPS con la prioridad correspondiente y la etiqueta finops-sentinel. Linear funciona igual. Ambos se configuran en Alertas → Integraciones, con su botón «Probar conexión».
  • En la página Alertas, el equipo ve el aviso junto al resto, puede filtrar por severidad o por cuenta y lo marca como leído cuando lo ha revisado.
  • Desde un hallazgo concreto también se puede abrir el ticket a mano, sin esperar a ninguna alerta.

Paso 5: Anomalías, para saber qué servicio ha sido

Una subida del 29 % dice que algo ha cambiado, pero no qué. Con el plan Business, Informes → Anomalías compara los dos últimos escaneos de cada cuenta, servicio a servicio, y detecta cuatro tipos de anomalía:

  • Pico de gasto o caída de gasto de la cuenta: más de un 15 % y más de 5 USD de diferencia.
  • Servicio nuevo: un servicio que no estaba y aparece con más de 10 USD.
  • Pico en un servicio existente: más de un 25 % y más de 5 USD de subida.
  • Cada anomalía se puede marcar como revisada, descartar o reabrir. Las descartadas no cuentan en el Impacto total.

Son reglas fijas sobre la comparación entre escaneos, no un modelo de aprendizaje automático, y el informe se calcula cuando lo abres: no envía alertas. En el caso de ACME, habría señalado que la subida venía casi entera de Amazon EC2.

Qué no hace todavía

Para que sepas dónde están los límites:

  • No tiene presupuestos de nube ni avisos por porcentaje del presupuesto: para eso están AWS Budgets, los presupuestos de Azure Cost Management y los de Google Cloud.
  • No detecta picos dentro del día: compara escaneo con escaneo, normalmente una vez al día.
  • La configuración de canales y umbrales es común a toda la organización; si gestionas clientes con el plan Business, cada cliente puede tener la suya.
  • Los umbrales del informe de anomalías son fijos; los que configuras en Umbrales de detección sólo afectan a las alertas.

Checklist para empezar

Con estas piezas en su sitio, la factura de fin de mes deja de ser el primer aviso.

  • Un presupuesto nativo en cada nube, con aviso sobre el gasto previsto y sobre el real.
  • Plan Pro o Business, y las cuentas conectadas con su escaneo diario.
  • Al menos un canal probado en Canales de alerta: correo, Slack o webhook.
  • Umbral de pico y gasto mínimo ajustados a tu gasto, para que cada aviso signifique algo.
  • El resumen periódico para quien no necesita cada alerta.
  • Jira o Linear conectados en Integraciones para que lo importante acabe en un ticket.
  • Con Business, el informe de Anomalías revisado después de cada pico.