Auditar recursos ociosos: ahorrar en costos de nube
Los recursos ociosos pueden representar hasta el 30% de la factura de nube de una startup, según un análisis publicado en dev.to en julio de 2026. La forma de recuperar esa plata y ahorrar en costos de nube es una auditoría de recursos ociosos: revisar qué instancias, volúmenes y pods siguen prendidos sin hacer nada, y apagarlos sin tocar producción.
Una auditoría de recursos ociosos (idle-resource audit) es la revisión sistemática de tu infraestructura en la nube para detectar recursos que están activos pero sin generar valor: instancias EC2 con CPU casi en cero, volúmenes EBS desconectados, snapshots viejos o pods de Kubernetes olvidados. El objetivo es eliminarlos o redimensionarlos para bajar la factura de AWS o Google Cloud.
En 30 segundos
- Hasta 30% de la factura se va en recursos ociosos. Instancias, volúmenes y pods prendidos sin uso que nadie apagó.
- El costo es silencioso. Ningún sistema te avisa que una EC2 lleva 30 días al 2% de CPU. Lo ves en la factura del mes siguiente, cuando ya pagaste.
- Arrancás con las herramientas nativas. AWS Cost Explorer y Google Cloud Billing Reports son gratis y ya están en tu cuenta.
- El etiquetado (tagging) resuelve el “¿de quién es esto?”. Sin tags no sabés qué proyecto ni qué persona levantó cada recurso.
- Monitoreo en tiempo real > revisión mensual. Si lo encontrás hoy, dejás de pagarlo hoy.
¿Por qué el 30% de la factura de nube de una startup termina en recursos ociosos?
El patrón se repite. El equipo crece rápido, cada dev o cada squad levanta lo que necesita, y nadie tiene la foto completa de qué está corriendo.
Levantás una instancia para probar una feature, hacés el deploy en staging, la demo sale bien, seguís con otra cosa y esa instancia queda dando vueltas prendida durante tres meses, sumando horas de cómputo que nadie mira hasta que el CFO pregunta por qué la nube subió 40% sin que hayamos escalado nada.
Ese es el problema de fondo: la sobre-provisión. Se aprovisiona de más “por las dudas” y después nadie vuelve a bajarlo. El análisis de dev.to lo llama silent cost overrun, y el adjetivo es preciso. No hay alerta. No hay error. Solo una factura que crece.
¿Y por qué nadie lo agarra antes? Porque revisar recursos ociosos no es tarea de nadie en particular. Hasta que se convierte en tarea de todos, cuando ya duele.
¿Cuáles son los recursos ociosos más comunes en AWS y Google Cloud?
No todos los recursos ociosos son iguales. Algunos gritan (una instancia grande al 2%), otros son invisibles (un volumen desconectado que igual te cobran). Estos son los sospechosos de siempre: Ya lo cubrimos antes en usar APIs de IA de manera eficiente.
- Instancias con CPU casi en cero. Una EC2 o una VM de Compute Engine con menos de 5% de uso de CPU durante 30 días es candidata directa a apagarse o achicarse.
- Volúmenes de disco desconectados. Los EBS en AWS o los persistent disks en Google Cloud siguen facturando aunque no estén asociados a ninguna instancia. Es plata que se va sin que nada corra.
- Snapshots viejos. Backups de máquinas que ya no existen, acumulados por años. Ocupan storage y el storage se paga.
- Pods de Kubernetes olvidados en staging. Ambientes de prueba que quedaron prendidos después de una demo o un test.
- Bases de datos sin conexiones. Una RDS o una Cloud SQL levantada para un proyecto que se canceló, con cero conexiones hace semanas.
El común denominador: todos siguen “prendidos” desde el punto de vista de la facturación, aunque para el negocio ya estén muertos.
¿Cómo auditar recursos sin usar, paso a paso?
La buena noticia: no necesitás comprar nada para empezar. Las dos nubes grandes ya te dan la herramienta gratis dentro de tu cuenta.
- Prendé la herramienta de costos. AWS Cost Explorer o los Billing Reports de Google Cloud. Te muestran en qué se está yendo la plata, por servicio y por período.
- Categorizá por métrica de uso. Filtrá por CPU, memoria y tráfico de red. Buscás lo que consume poco pero cobra igual.
- Fijá un umbral. Por ejemplo: menos de 5% de uso sostenido durante 30 días. Todo lo que caiga ahí, a la lista de revisión.
- Generá el reporte por tipo de recurso. Agrupá por resource type (instancias, volúmenes, snapshots) para atacar de a categorías, no de a uno.
Con eso ya tenés una lista concreta de candidatos. El paso siguiente no es borrar de una (ya vamos a eso), es validar.
AWS vs Google Cloud: dónde ver cada recurso ocioso
| Recurso ocioso | AWS | Google Cloud |
|---|---|---|
| Análisis de costos | Cost Explorer | Billing Reports |
| Métricas de uso | CloudWatch | Cloud Monitoring (Operations Suite) |
| Cómputo ocioso | Instancias EC2 | VMs de Compute Engine |
| Disco desconectado | Volúmenes EBS | Persistent Disks |
| Base de datos sin uso | RDS | Cloud SQL |
¿Por qué el monitoreo en tiempo real le gana a la revisión mensual?
Es una cuestión de timing. Si descubrís un recurso ocioso en la revisión de fin de mes, ya pagaste ese mes entero. Perdiste la plata.
Con monitoreo en tiempo real lo agarrás el día que se vuelve ocioso, no 28 días después. CloudWatch en AWS y Cloud Monitoring en Google Cloud te dejan configurar alertas: “avísame si esta instancia baja de 5% de CPU por 7 días”. Ahí actuás en caliente. Sobre eso hablamos en optimizar tu flujo de CI/CD.
Para Kubernetes hay herramientas de terceros como Kubecost que te muestran el costo por pod y namespace, algo que la consola nativa no te da con esa granularidad. Ojo: sumar más herramientas también suma complejidad, así que empezá con lo nativo y escalá si el volumen lo justifica. Si estás evaluando dónde parar tu infraestructura o buscás hosting y cloud en la Argentina, ese cálculo de costo real por recurso es justamente lo que te conviene tener claro antes de crecer.
¿Cómo implementar etiquetado de recursos para rastrear costos?
El tagging (etiquetado) es lo que separa “tenemos un lío de recursos” de “sabemos exactamente qué es cada cosa”. Según el mismo análisis de dev.to, implementar tags mejora la visibilidad y la accountability, y resuelve dos problemas a la vez.
- Accountability: sabés de quién es cada recurso. Con un tag de owner o de proyecto, cuando aparece una instancia rara sabés a quién preguntarle antes de apagarla.
- Análisis: filtrás costos por lo que quieras. Por ambiente (prod/staging/dev), por equipo o por producto. Así ves qué proyecto se está comiendo la factura.
La estrategia que funciona es hacer los tags obligatorios desde la política de IAM: si no ponés los tags requeridos, no podés crear el recurso. Suena rígido, pero es la única forma de que se cumpla.
El error más común acá son los tags inconsistentes. Uno escribe “produccion”, otro “prod”, otro “Production”, y de golpe tenés tres categorías para lo mismo. Definí un estándar y validalo.
¿Cuánto podés ahorrar en costos de nube eliminando recursos ociosos?
El rango realista es 10% a 30% de la factura, según cuán madura esté tu infraestructura. Una startup que nunca hizo una auditoría suele estar más cerca del 30%; una que ya limpió, más cerca del 10%.
Hagamos la cuenta simple. Ponele que gastás USD 10.000 por mes en AWS. Si un 30% son recursos ociosos, eso es USD 3.000 mensuales, USD 36.000 al año que podrías reasignar a crecer en vez de tirar. Para una startup, ese número es la diferencia entre contratar a alguien o no (que no es poco). Complementá con evaluar tu infraestructura de datos.
El caso típico donde más se recupera es el storage: snapshots viejos y volúmenes desconectados que se acumularon durante años y que nadie mira porque, comparados con el cómputo, “no parecen caros”. Sumados, sí lo son.
¿Cómo automatizar la limpieza sin romper producción?
Acá viene lo delicado. Automatizar la limpieza está bueno, pero borrar a ciegas es la receta para tirar abajo un fallover legítimo que estaba “durmiendo” a propósito.
La diferencia clave es entre “eliminar” y “validar primero”. Algunos recursos con CPU baja son standby reales, no basura. Por eso la automatización necesita guardrails:
- Backup antes de eliminar. Un snapshot del volumen o la instancia antes de matarla. Si te equivocaste, revertís.
- Lista blanca de intocables. Recursos que la automatización nunca puede tocar, aunque parezcan ociosos.
- Notificación previa. Avisar al owner (por eso servían los tags) antes de apagar, dándole un margen para que diga “pará, eso lo necesito”.
- Políticas de TTL en Kubernetes. Que los ambientes de staging se auto-destruyan a las X horas si nadie los renueva.
Con esos frenos puestos, recién ahí tiene sentido una Lambda que termine instancias ociosas o una política de ciclo de vida que borre snapshots viejos. La automatización sin guardrails no ahorra plata, genera incidentes.
Errores comunes al auditar costos de nube
- Asumir que la infraestructura “ya está optimizada”. Es la trampa mental más frecuente. Casi ninguna startup que crece rápido tiene la nube optimizada, y el que asume que sí, no audita nunca. Corregilo: medí antes de opinar.
- Mirar solo el cómputo y olvidar el storage. Las instancias se ven caras y llaman la atención. Los volúmenes desconectados y los snapshots pasan desapercibidos y sumados pesan un montón. Revisá también el almacenamiento.
- Borrar sin backup ni notificación. Apagar un recurso que resultó ser un fallover legítimo te sale más caro que el ahorro. Siempre snapshot y aviso al owner antes.
- Hacer la auditoría una sola vez. Limpiás hoy y en tres meses volvés a estar igual, porque el proceso que genera recursos ociosos sigue activo. La auditoría es recurrente, no un evento único.
Preguntas Frecuentes
¿Cuánto estoy gastando en recursos que no uso en la nube?
Entre 10% y 30% de tu factura mensual, según el análisis de dev.to de julio de 2026. El porcentaje exacto depende de cuán madura esté tu infraestructura: cuanto más rápido creciste sin auditar, más cerca del 30% vas a estar. Tema relacionado: elegir herramientas que ahorren costos.
¿Cómo identificar recursos ociosos en AWS?
Con AWS Cost Explorer para ver el gasto y CloudWatch para las métricas de uso. Filtrá instancias EC2 con menos de 5% de CPU durante 30 días, volúmenes EBS desconectados y snapshots asociados a máquinas que ya no existen.
¿Qué herramienta uso para auditar costos en Google Cloud?
Los Billing Reports de Google Cloud, que ya vienen en tu cuenta sin costo extra. Para las métricas de uso los combinás con Cloud Monitoring (parte de Operations Suite), que te deja configurar alertas cuando un recurso queda ocioso.
¿Por qué mi factura de nube sigue subiendo sin escalar nada?
Casi siempre es acumulación de recursos ociosos: instancias de pruebas que quedaron prendidas, volúmenes desconectados y snapshots viejos que se van sumando mes a mes. No es que escalaste, es que nadie apagó lo que dejó de usarse.
¿Es seguro automatizar la eliminación de recursos ociosos?
Sí, siempre que pongas guardrails: backup antes de borrar, lista blanca de recursos intocables y notificación previa al owner. Sin esos frenos corrés el riesgo de apagar un fallover legítimo, y ese incidente te sale más caro que lo que ahorrás.
Conclusión
El 30% de la factura en recursos ociosos no es un problema de tecnología, es un problema de que nadie mira. La auditoría de recursos ociosos lo resuelve con herramientas que ya tenés gratis: Cost Explorer o Billing Reports para ver el gasto, CloudWatch o Cloud Monitoring para las métricas, y tags para saber de quién es cada cosa.
Empezá esta semana con un umbral simple (menos de 5% de uso en 30 días), validá antes de borrar y convertí la auditoría en un proceso recurrente, no en un evento único. Ese es el camino concreto para ahorrar en costos de nube sin arriesgar producción. La plata que recuperás la reinvertís en crecer, que es para lo que levantaste la startup en primer lugar.
