Los recursos cloud que más dinero desperdician en AWS, Azure y Google Cloud, y cómo encontrarlos con Hallazgos activos

El desperdicio en la nube es sorprendentemente repetitivo. Da igual el proveedor o el tamaño de la factura: casi siempre aparecen los mismos recursos olvidados, que cobran cada hora sin que nadie los use. Encontrarlos a mano exige recorrer cada consola, región por región. En este artículo repasamos esos patrones, te decimos qué regla de AAA Sentinel detecta cada uno en AWS, Azure y Google Cloud, y te enseñamos a trabajar la lista de Hallazgos activos hasta convertirla en ahorro.

Por qué el desperdicio se repite

Casi todo el gasto inútil nace del mismo gesto: se borra o se para lo principal y lo accesorio sobrevive. Al eliminar una máquina virtual, su disco puede quedarse. Al retirar un entorno, la IP pública reservada, el balanceador o el NAT siguen en pie. Y lo que sí se usa suele estar dimensionado para un pico que nunca llegó. Ninguno de estos recursos avisa: no fallan, no generan incidencias y su coste aparece diluido en una línea de la factura.

Qué ganas con ello

Detectar estos recursos de forma sistemática cambia la manera de trabajar el ahorro:

• Una sola lista para las tres nubes, ordenada por severidad y por ahorro estimado al mes.
• Criterios fijos y conocidos: cada hallazgo sale de una regla con un umbral concreto, no de una opinión.
• Decisiones que no se pierden: lo que descartas o das por resuelto sigue así en los siguientes escaneos.
• Un camino claro desde el hallazgo hasta la acción, a mano, con un ticket o con el agente.

Cómo lo resuelve AAA Sentinel: escaneo, reglas y hallazgos

Cada escaneo lee los recursos y las métricas de tus cuentas conectadas con permisos de solo lectura y les aplica las reglas de análisis. Hoy son 51 reglas de coste: 19 para AWS, 16 para Azure y 16 para Google Cloud. Cada regla que se cumple genera un hallazgo con su severidad, una recomendación y un ahorro mensual estimado. Tres pantallas cubren el circuito:

• Reglas de análisis: el catálogo completo, con el plan que incluye cada regla, la etiqueta «Automatizable» cuando el agente puede ejecutar la corrección y un interruptor para activarla o desactivarla.
• Historial de escaneos: cada escaneo con su coste, sus hallazgos y la comparación con el anterior (nuevos, desaparecidos, sin cambios).
• Hallazgos activos: la lista de trabajo con todos los hallazgos del último escaneo de cada cuenta.

Cada patrón, su regla

Estos son los patrones de desperdicio y las reglas que los detectan, con sus umbrales reales. Free incluye las reglas básicas; Pro añade las que necesitan métricas de uso más detalladas.

• Discos sin montar (Free): STORAGE_UNATTACHED_VOLUME en AWS (volumen EBS en estado available), AZURE_DISK_UNATTACHED y GCP_DISK_UNATTACHED.
• IPs públicas sin asociar (Free): NETWORK_UNASSOCIATED_EIP en AWS, AZURE_IP_UNASSOCIATED y GCP_STATIC_IP_UNUSED.
• Máquinas paradas que siguen pagando disco (Free): COMPUTE_STOPPED_WITH_VOLUME en AWS, AZURE_VM_STOPPED en Azure y GCP_VM_STOPPED en Google Cloud (parada desde hace al menos una semana).
• Máquinas casi ociosas (Free): CPU media por debajo del 5 % en 7 días, con COMPUTE_LOW_CPU, AZURE_COMPUTE_LOW_CPU y GCP_COMPUTE_LOW_CPU.
• Máquinas sobredimensionadas (Pro): con la CPU media de 7 días por debajo del 20 %, AWS_COMPUTE_RIGHTSIZE, AZURE_COMPUTE_RIGHTSIZE y GCP_COMPUTE_RIGHTSIZE proponen bajar exactamente un tamaño.
• Balanceadores sin tráfico (Pro): NETWORK_IDLE_LB en AWS (ALB con menos de 10 peticiones al día de media en 7 días, o NLB y GWLB con menos de 1 MiB procesado al día) y AZURE_LB_IDLE (balanceador Standard sin tráfico en 7 días) y GCP_LB_IDLE (forwarding rule sin tráfico en 7 días, cuando borrarla baja la cuota de forwarding rules).
• Bases de datos sin conexiones (Pro): cero conexiones en 7 días (en Cloud SQL, como mucho conexiones sueltas y breves), con DATABASE_ZERO_CONN_RDS, AZURE_SQL_ZERO_CONN y GCP_SQL_ZERO_CONNECTIONS.
• NAT huérfanos o infrautilizados (Pro): NETWORK_ORPHAN_NAT, AZURE_NETWORK_ORPHAN_NAT y GCP_NETWORK_ORPHAN_NAT señalan el NAT con menos de 1 GB al día que no tiene rutas ni subredes que dependan de él. En AWS, NETWORK_UNDERUSED_NAT avisa además del NAT con menos de 1 GB al día aunque todavía tenga rutas.
• Almacenamiento en una clase cara (Pro): buckets de más de 100 GB en clase Standard, con STORAGE_S3_WRONG_CLASS y GCP_GCS_WRONG_CLASS, y en Azure AZURE_STORAGE_WRONG_TIER, para cuentas con más de 100 GB en Hot sin política de ciclo de vida que baje de nivel toda la cuenta y con pocas lecturas en 30 días.
• Snapshots huérfanos (Free): STORAGE_ORPHAN_SNAPSHOT en AWS, para snapshots EBS cuyo volumen de origen ya no existe, y AZURE_SNAPSHOT_ORPHAN y GCP_SNAPSHOT_ORPHAN, para snapshots de más de 30 días cuyo disco de origen ya no existe.
• Bases de datos NoSQL con capacidad de sobra (Pro): DATABASE_DYNAMO_OVERPROV en AWS y AZURE_COSMOS_OVERPROV en Azure, cuando en 7 días usan menos del 20 % de lo reservado.
• Discos de generación anterior (Pro, solo AWS): STORAGE_EBS_GP2_TO_GP3, para volúmenes gp2 montados que costarían menos en gp3 con el mismo rendimiento.
• Versiones en soporte extendido de pago (Pro): COMPUTE_EKS_EXTENDED_SUPPORT y DATABASE_RDS_EXTENDED_SUPPORT en AWS (EKS, RDS y Aurora), GCP_GKE_EXTENDED_SUPPORT y GCP_SQL_EXTENDED_SUPPORT en Google Cloud (GKE en el canal Extended y Cloud SQL) y AZURE_DB_EXTENDED_SUPPORT en Azure (MySQL y PostgreSQL), también 60 días antes de que empiece a cobrarse, y AZURE_AKS_LTS para clústeres AKS en el tier Premium con soporte a largo plazo.
• Endpoints de ML sin uso (Pro): COMPUTE_SAGEMAKER_ENDPOINT_IDLE, AZURE_ML_ENDPOINT_IDLE y GCP_VERTEX_ENDPOINT_IDLE, para endpoints de SageMaker, Azure Machine Learning y Vertex AI con instancias o réplicas en marcha y ninguna petición en 14 días.
• Además, en AWS (Pro): recursos con más de 30 días sin actividad que no están etiquetados como producción.

Caso práctico: ACME en tres nubes

ACME es una empresa ficticia con la tienda en AWS, la plataforma de datos en Azure y la analítica en Google Cloud, en el plan Pro. Tras el primer escaneo de sus tres cuentas, estos son los hallazgos que nos interesan, con el ahorro estimado que calcula cada regla y lo que el equipo decide:

Paso 1: lanzar un escaneo

En Mis cuentas cloud, cada cuenta tiene el botón «Escanear». En Free puedes lanzar hasta 3 escaneos por semana; en Pro y Business las cuentas se escanean automáticamente cada día y también puedes lanzarlos a mano. Al terminar, el escaneo aparece en Historial de escaneos: con «Ver detalle» ves el coste, el ahorro potencial y la comparación con el escaneo anterior, que separa los hallazgos nuevos, los desaparecidos y los que siguen sin cambios.

Paso 2: revisar las reglas de análisis

Antes de trabajar la lista, conviene echar un vistazo a Reglas de análisis. Puedes filtrar por proveedor y por categoría, y cada tarjeta muestra el plan que la incluye y si es «Automatizable». Las reglas fuera de tu plan aparecen con un candado.

• Desactiva una regla con su interruptor si no aplica a tu caso. El cambio vale desde el siguiente escaneo.
• Desactivar una regla no da por resueltos sus hallazgos: la plataforma deja de mirar, y lo distingue de que el problema haya desaparecido.
• Las reglas no tienen umbrales configurables: el 5 % de CPU o los 7 días son los mismos para todos.

Paso 3: filtrar los hallazgos activos

Hallazgos activos reúne los hallazgos del último escaneo de cada cuenta, ordenados por severidad y, dentro de cada una, por ahorro. Arriba tienes los filtros:

• Pestañas de severidad: Todos, Crítico, Alto, Medio y Bajo, cada una con su contador.
• Selector de cuenta, con «Todas las cuentas» para ver las tres nubes juntas.
• «Solo automatizables», para quedarte con lo que el agente puede corregir.
• «Ver descartados», que vuelve a mostrar lo que marcaste como descartado o resuelto.
• El buscador «Buscar hallazgo...», que busca en el título, el nombre del recurso y la descripción.

Paso 4: abrir el detalle

Al pulsar un hallazgo se abre el panel «Detalle del hallazgo». Ahí tienes la severidad, la descripción, la «Recomendación», el recurso, la cuenta, la región y el «Ahorro estimado» al mes. El enlace «Ver recurso» lleva a la ficha del recurso. Si el hallazgo tiene una corrección automática, verás también el botón para automatizarla, que explicamos en el paso 7.

Paso 5: decidir el estado

En el mismo panel, el bloque «Estado» tiene cuatro botones. La decisión se guarda a nivel de organización y se mantiene en los escaneos siguientes:

• Abierto: sin decisión. Es el estado de partida, y volver a él borra la decisión anterior.
• Aceptado: reconoces el problema y lo vas a arreglar. Sigue contando en los indicadores, porque el gasto sigue ahí.
• Descartado: has decidido no actuar (en ACME, el balanceador de staging). Deja de contar en los indicadores y en los informes.
• Resuelto: ya lo has corregido. Tampoco cuenta en los indicadores.

Paso 6: llevarlo a Jira o Linear

Si tu equipo trabaja con tickets, conecta Jira Cloud (con un token de API) o Linear en Alertas → Integraciones (plan Pro). En cada integración eliges «Crear ticket para alertas de severidad», que por defecto es alta. A partir de ahí:

• Cuando un escaneo detecta hallazgos nuevos de severidad alta y tienes activado el aviso «Nuevos hallazgos de alta prioridad» en Canales de alerta, se crea un ticket con el resumen de esa alerta. Es un ticket por alerta, que agrupa los hallazgos del escaneo, no uno por hallazgo.
• Para un ticket de un hallazgo concreto, el botón «Crear ticket» aparece en las acciones del Agente IA que nacen de un hallazgo (plan Business).

Paso 7: proponer la corrección (Business)

En Business, los hallazgos con corrección automática muestran el botón «Automatizar» en la lista y en el detalle. Abre una ventana con «Qué se va a hacer», «Por qué», «Impacto», «Antes de continuar», «Cómo revertirlo» y una etiqueta «Reversible» o «No reversible». Con «Crear automatización» la acción queda propuesta en Agente IA → Panel, en «Pendientes de aprobación». Nada se ejecuta sin que la apruebe alguien con permiso de aprobación, y tras aprobarla hay un período de gracia antes de ejecutarse (48 horas para borrar un volumen, por ejemplo) durante el que puedes cancelarla.

• El agente necesita un rol de escritura aparte, que se crea en el paso «Habilitar agente autónomo (opcional)» al conectar la cuenta.
• En AWS, parar, cambiar de tamaño o terminar una instancia EC2 exige que tenga la etiqueta FinOpsSentinelManaged=true.
• Al borrar un volumen EBS, el agente crea antes un snapshot de respaldo. Liberar una IP elástica, en cambio, la pierde: puedes reservar otra, pero no la misma dirección.
• Con «Convertir en playbook», la misma corrección se propone sola tras cada escaneo para los hallazgos de esa regla, siempre pendiente de aprobación.

El resultado en ACME

ACME actúa sobre todo menos el balanceador de staging, que marca como «Descartado». La Lambda se borra por higiene y no suma nada. El ahorro estimado queda así: 70 + 50 + 45 + 38 + 33 + 10,80 + 7,30 = 254,10 US$ al mes, unos 3.050 US$ al año, a precios de lista. A medida que cada recurso desaparece, sus hallazgos pasan a «Desaparecido» en los escaneos siguientes. En Business, el panel del agente muestra aparte el «Ahorro verificado», que se mide contra el coste real de la cuenta al menos 7 días después de cada acción.

Lo que no hace todavía

Para que sepas qué esperar:

• No hay reglas para Kubernetes ni para el coste de dentro de los clústeres.
• No hay regla de antigüedad de snapshots: las reglas de snapshots huérfanos buscan snapshots sin disco de origen, no snapshots viejos.
• Google Cloud no tiene regla de balanceadores sin tráfico, y Azure no tiene regla de almacenamiento en una clase cara.
• Los umbrales de las reglas no se pueden ajustar: solo activar o desactivar cada regla.
• En Hallazgos activos no hay botón de ticket por hallazgo: los tickets llegan por las alertas o desde el Agente IA.
• El ahorro estimado se calcula con el coste que la regla atribuye al recurso, no con tu factura. Tómalo como orden de magnitud.

Checklist para empezar

Con esto en orden, el desperdicio deja de acumularse en silencio:

• Tus cuentas de AWS, Azure y Google Cloud conectadas en Mis cuentas cloud.
• Un primer escaneo lanzado y revisado en Historial de escaneos.
• Las reglas que no aplican desactivadas en Reglas de análisis.
• Cada hallazgo de severidad alta con un estado: aceptado, descartado o resuelto.
• Jira o Linear conectados en Alertas → Integraciones, si trabajas con tickets.
• En Business, el rol del agente creado y las primeras correcciones propuestas desde el hallazgo.