¿Cuánto te cuesta cada mes un recurso cloud que no hace nada?
"Estamos pagando por cosas que están corriendo y no hacen nada." Es la queja más común sobre costos en la nube, y también la más vaga. Decirle eso a tu CFO no mueve nada. Decirle que once recursos específicos en tu cuenta de AWS están quemando $1,016 al mes — unos $12,000 al año — sin procesar una sola petición útil, eso sí mueve conversaciones.
Un artículo publicado hoy, 20 de agosto de 2026, en Dev.to por Muskan _zop detalla con precisión quirúrgica cuánto cuesta cada tipo de recurso idle en AWS, qué umbrales hacen que la clasificación de "idle" sea técnicamente defendible, y cuáles recursos parecen problemáticos pero en realidad no cuestan casi nada. Es el tipo de análisis que separa los equipos que optimizan cloud con datos de los que discuten con intuiciones.
En este artículo desmenuzamos los hallazgos más importantes y los conectamos con la realidad de empresas medianas en Perú y América Latina que están creciendo en la nube — muchas veces sin un proceso sistemático para auditar lo que tienen encendido.
El catálogo de recursos idle con precio incluido
El primer error al hablar de recursos ociosos es tratarlos como una categoría homogénea. No lo son. Cada tipo tiene su propio costo fijo, su propio umbral técnico y su propio nivel de riesgo al eliminarlo.
Las instancias EC2 con CPU promedio bajo 5% y tráfico de red despreciable, sostenidos durante 14 días continuos, califican como idle. El costo no se descuenta por la inutilidad: una m5.large cuesta aproximadamente $70 al mes, una m5.2xlarge unos $280, y una c5.4xlarge cerca de $500 — corriendo al 96% de vacío. Los 14 días importan porque una semana tranquila puede ser normal; dos semanas consecutivas son una señal real.
Los NAT Gateways olvidados son un clásico. Cuestan $32.85 al mes cada uno antes de procesar un solo gigabyte. El umbral defensible es cero BytesOutToDestination durante 7 días. Aparecen frecuentemente en VPCs cuyos workloads migraron o se dieron de baja, pero el gateway sobrevivió a todo. Hay además una trampa adyacente: si un NAT Gateway sí tiene tráfico pero ese tráfico es hacia S3 o DynamoDB, estás pagando $0.045 por GB por una ruta que un VPC Endpoint Gateway te daría gratis.
Los Load Balancers sin peticiones cuestan $16.43 al mes para ALB o NLB, y $18.25 para un Classic ELB. Cero requests durante 7 días es el test. El origen más común: servicios dados de baja cuyo Load Balancer y registro DNS sobrevivieron al servicio mismo. Son recreables en minutos, pero antes de eliminarlos vale verificar si algo todavía resuelve hacia ellos.
Las bases de datos RDS sin conexiones son el caso más costoso. Una db.t3.medium cuesta unos $50 al mes, una db.m5.large unos $125, y Multi-AZ duplica ambas cifras. El umbral aquí es más conservador: cero DatabaseConnections durante 14 días, no 7, porque los jobs batch semanales existen. Una base de datos a la que nadie se conectó en dos semanas no tiene justificación operativa.
Finalmente, un cluster EKS sin nodos activos igual cobra su control plane: $73 al mes. Son residuos de experimentos y migraciones. Cero nodos durante 7 días es la señal de que es seguro eliminarlo.
Los dos que parecen problema pero casi no cuestan nada
Este punto del artículo original merece destacarse porque habla de honestidad técnica. Las funciones Lambda con cero invocaciones prácticamente no generan cargos de cómputo. Cero invocaciones equivale a cero cobro. Deben limpiarse por higiene — código muerto, permisos IAM obsoletos, superficie de ataque sin monitoreo — pero no pertenecen a una lista de ahorro de costos. Cualquier reporte que infle sus números con "savings de Lambdas idle" está siendo deshonesto.
Las instancias detenidas tampoco son un problema de cómputo idle: son un problema de almacenamiento. Sus volúmenes EBS y Elastic IPs siguen facturando aunque la instancia esté apagada. Es una categoría distinta con una solución distinta.
Separar estos casos mantiene el análisis creíble. El gasto idle real está dominado por cómputo siempre encendido y bases de datos, seguido por la infraestructura de red de precio fijo que nadie recuerda que existe.
¿Cómo aplica esto en empresas peruanas y latinoamericanas?
En Perú y América Latina, muchas empresas medianas llegaron a AWS de forma incremental: un servidor aquí, una base de datos allá, un ambiente de pruebas que "después limpiamos". El resultado es una cuenta que creció orgánicamente sin una estrategia de gobernanza de costos.
El patrón más frecuente que vemos en proyectos de infraestructura cloud es exactamente este: recursos de etapas anteriores del negocio que siguen facturando porque nadie tuvo la tarea formal de apagarlos. No es negligencia — es que el foco siempre estuvo en construir, no en auditar lo construido.
El análisis del artículo muestra que una cuenta mediana típica con once recursos idle suma $1,016 al mes, aproximadamente $12,000 al año, identificables con dos horas de revisión de métricas en CloudWatch. Para una empresa que factura en soles y tiene presupuesto de tecnología ajustado, ese número tiene un peso muy concreto.
La clave no es solo encontrar los recursos, sino documentar el umbral junto a cada hallazgo. "Esta instancia tiene CPU promedio de 3.2% durante los últimos 14 días" cierra la discusión sobre si está en uso. "Este NAT Gateway tiene cero bytes de salida en los últimos 7 días" convierte una opinión en evidencia. Y adjuntar el costo mensual a cada línea transforma una lista de IDs de instancias en una decisión de negocio.
¿Cómo aplica esto en tu empresa?
Si tu empresa usa AWS y no tiene un proceso sistemático de revisión de recursos idle, este es el punto de partida más concreto y de menor riesgo para empezar a optimizar costos cloud:
- Semana 1: Revisa métricas de CPU y red de todas tus instancias EC2 en los últimos 14 días usando CloudWatch. Documenta las que estén bajo 5% de CPU promedio con tráfico despreciable.
- Semana 1: Lista todos tus NAT Gateways y revisa BytesOutToDestination en los últimos 7 días. Identifica los que marcan cero.
- Semana 2: Audita Load Balancers con RequestCount en cero durante 7 días. Verifica resolución DNS antes de eliminar.
- Semana 2: Revisa DatabaseConnections de tus instancias RDS en los últimos 14 días. Las que marquen cero son candidatas claras.
- Al finalizar: Presenta cada hallazgo con su umbral documentado y su costo mensual. Eso convierte el análisis en una decisión, no en un debate.
El objetivo no es eliminar todo lo que parece ocioso — es poder defender técnicamente cada eliminación con datos, no con intuiciones. Esa diferencia es la que separa una optimización exitosa de un incidente en producción.
Conclusión
Los recursos cloud idle no son un problema de tecnología — son un problema de visibilidad y proceso. AWS no te avisa que tienes un NAT Gateway cobrando $32 al mes sin mover un byte. Esa responsabilidad es tuya, y el primer paso es tener umbrales técnicos claros y precios por recurso documentados.
Si tu empresa está en ese punto donde la factura de cloud sube pero no hay claridad sobre qué la está generando, en Consultoría-Ti podemos ayudarte a hacer ese análisis con metodología y criterio técnico — antes de tocar nada en producción.
Contáctanos en consultoria-ti.com.pe/contactus y conversamos sobre cómo aplicar esto en tu infraestructura actual.
Fuentes y Referencias
✨ Contenido generado con ContentFlow — Consultoría-Ti