Cada mes miras la factura de AWS, Azure o tu proveedor cloud. La pagas. Tus devs te dicen que "así funciona". Tus vendors te dicen que "escalar cuesta". Y el ciclo se repite.
Pero si hicieras una auditoría de 4 horas sobre esa factura, encontrarías algo incómodo: entre un 20% y un 40% de lo que pagas son recursos que no necesitas, instancias que nadie apagó después de una prueba, y arquitecturas que se diseñaron para un pico de tráfico que nunca llegó.
El overbilling en cloud no es un accidente. Es el modelo de negocio de la nube funcionando exactamente como fue diseñado: hacerse invisible.
Las tres fugas que están vaciando tu presupuesto
1. Recursos idle — la fuga silenciosa
Toda empresa tiene entornos de staging, development y testing. La mayoría corren 24/7. Nadie los usa de noche. Nadie los usa los fines de semana. Pero la factura llega igual.
Una instancia EC2 t3.medium que solo se usa 40 horas semanales cuesta lo mismo que una que corre 168 horas. Estás pagando 128 horas semanales de electricidad que nadie consume. Multiplica por tres entornos. Multiplica por doce meses.
En Kubernetes esto es peor: los clústeres de desarrollo suelen tener nodos sobredimensionados porque "es más fácil pedir una máquina grande que andar ajustando requests y limits". El resultado: clústeres que corren al 15% de utilización de CPU y al 30% de memoria, pero facturan al 100%.
2. Overprovisioning — la fuga por miedo
"Mejor que sobre a que falte." Esa frase, repetida en mil reuniones de planificación, ha costado más dinero que cualquier bug en producción.
El overprovisioning ocurre cuando dimensionas tu infraestructura para el peor escenario posible y la dejas así permanentemente. Black Friday, el lanzamiento del año, la campaña de marketing masiva. Tres días al año de pico, 362 días pagando recursos ociosos.
Una base de datos RDS con 8 vCPUs y 64 GB de RAM "por si acaso" cuando el 95% del tiempo usa 2 vCPUs y 12 GB te está costando el triple cada mes. Y lo peor: el equipo lo justifica con "es lo que recomienda AWS" sin preguntarse quién gana con esa recomendación.
3. Transferencia de datos mal ruteada — la fuga que ni ves
Mueves datos entre regiones porque la app se diseñó cuando todo estaba en us-east-1 y luego abriste clientes en Europa. Cada gigabyte que cruza regiones tiene un costo. Cada consulta a una API que está en la nube equivocada suma.
Peor: usas NAT Gateway para darle internet a tus instancias privadas. El tráfico pasa por el NAT Gateway, que cobra por hora y por gigabyte procesado. Si tus pods bajan imágenes de Docker Hub 20 veces al día, cada descarga pasa por ese peaje. Una VPC Gateway Endpoint para S3 y un cache de imágenes de contenedores te ahorrarían cientos de dólares al mes. Pero nadie te lo dijo al hacer el setup.
La paradoja de la nube: más fácil gastar que ahorrar
AWS, Azure y GCP han hecho un trabajo brillante facilitando el gasto. Un junior recién contratado puede provisionar un clúster de Kubernetes en 15 minutos. Pero ese mismo junior no sabe qué es una Reserved Instance, un Savings Plan, un spot instance o un auto-scaling group con escala a cero.
La nube democratizó el gasto. La optimización sigue siendo territorio de especialistas. Y en ese gap vive el overbilling.
El caso real: 40% de ahorro sin tocar el producto
Hace unos meses trabajamos con una empresa de e-commerce que tenía una factura cloud de $12,000/mes. Su stack: Kubernetes en EKS, RDS para PostgreSQL, ElastiCache para Redis, CloudFront para CDN.
La auditoría de 4 horas encontró:
- 3 clústeres de Kubernetes: producción, staging y desarrollo. Staging y desarrollo tenían la misma cantidad de nodos que producción. Redujimos staging a 2 nodos con auto-scaling y desarrollo a 1 nodo spot.
-
RDS: instancia
db.r5.4xlarge(16 vCPU, 128 GB RAM). El monitoreo mostraba que nunca pasaba de 25% de uso. Migramos adb.r5.xlargecon storage auto-scaling. Ahorro inmediato del 60% en base de datos. - NAT Gateway: 3 NAT Gateways, uno por zona de disponibilidad "por alta disponibilidad". Uno era suficiente con rutas bien configuradas. Dos NAT Gateways apagados.
-
ElastiCache: un clúster
cache.m5.largeque nadie usaba porque la app se migró a Redis local en los pods hacía 4 meses y nadie apagó el clúster. $90/mes a la basura.
Resultado: factura de $12,000 a $7,200. Mismo producto. Mismo rendimiento. Cero downtime. Cuarenta por ciento de ahorro detectado en una sola tarde.
Kubernetes no es un gasto — es una herramienta de ahorro, si sabes usarla
Hay una creencia peligrosa entre decisores técnicos: "Kubernetes es caro, mejor seguimos con VPS". Es como decir que un auto es caro porque consume gasolina, ignorando que puedes elegir entre un sedán eficiente y un camión minero.
Kubernetes bien configurado —con auto-scaling, spot instances, bin packing, y límites de recursos correctos— te da más carga de trabajo por dólar que cualquier alternativa artesanal. El problema no es Kubernetes. El problema es Kubernetes mal dimensionado, que es lo que obtienes cuando levantas un clúster sin arquitectura previa.
La diferencia entre un clúster que sangra plata y uno eficiente no está en la tecnología. Está en las decisiones de dimensionamiento que nadie tomó porque "había que sacar el feature".
5 cosas que puedes auditar esta misma semana
Sin contratar a nadie, sin mover producción. Abre tu consola de AWS/Azure/GCP ahora mismo y revisa:
- Instancias EC2/VMs: ordena por utilización de CPU. Si hay alguna corriendo a menos del 10% en el último mes, pregúntale al dueño si todavía la necesita.
- Load Balancers: ¿cuántos tienes? Si hay más de uno por entorno, probablemente sobra alguno.
- NAT Gateways: ¿tienes más de uno por VPC? Si no tienes tráfico multi-AZ crítico, uno basta.
- Volúmenes EBS/discos sin atachar: búscalos. Siempre hay. Son de instancias que se borraron y el disco quedó huérfano.
- IPs elásticas sin asociar: cuestan dinero si no están atachadas a una instancia running. Búscalas.
Si encuentras aunque sea uno de estos, ya te pagaste el café de la semana. Si encuentras tres, acabas de ahorrar cientos de dólares al mes sin tocar una línea de código.
Cada mes que pasa sin auditar tu infraestructura es un mes de overbilling que se acumula. En Guayoyo Tech hacemos auditorías de arquitectura cloud en horas, no en semanas, y te decimos exactamente cuánto estás filtrando y cómo cerrar cada fuga. Sin compromiso, sin relleno, sin vendor lock-in.
Top comments (0)