Hace poco revisé la factura mensual de AWS de un cliente fintech de 40 personas que había saltado de $8,400 a $19,000 en noventa días. Nadie había lanzado una función importante. La base de clientes no se había duplicado. Cuando entré al Cost Explorer, la respuesta fue casi vergonzosa: tres entornos de staging corriendo las 24 horas, una instancia de base de datos dimensionada para una prueba de carga que nunca se hizo, y cuarenta volúmenes EBS sin adjuntar que nadie recordaba haber creado.
Esta es la conversación que tengo con clientes pymes y de mercado medio más que casi cualquier otra últimamente: la factura de la nube pasó de "razonable" a "por favor explíquenme esto" en cuestión de meses, y nadie sabe muy bien por qué. La optimización de costos en la nube — la disciplina que la industria hoy llama FinOps — no se trata de migrar fuera de la nube ni de negociar una vez al año con el vendedor de su proveedor. Es una práctica operativa continua, y la mayoría de las empresas nunca la construyen.
Los datos de la industria respaldan lo que veo en los entornos de mis clientes. El informe State of the Cloud 2026 de Flexera ubica el gasto desperdiciado en la nube en aproximadamente el 29% del presupuesto total de IaaS/PaaS a nivel industria, y esa cifra subió el último año en lugar de bajar, en gran parte porque las cargas de trabajo de IA hacen que pronosticar costos sea más difícil. Las organizaciones sin una práctica de FinOps desperdician cerca de un tercio de lo que gastan; las maduras logran bajar eso al 15-20%. Esa diferencia, sobre un presupuesto anual de $250,000 en la nube, es dinero real — entre $30,000 y $50,000 al año que podrían financiar a otro ingeniero.
Así es como lo resuelvo con mis clientes, paso a paso.
Dónde se Fuga Realmente el Dinero
Antes de optimizar nada, hago un inventario de dónde se concentra el desperdicio. En casi todos los entornos de pymes que he auditado, se agrupa en los mismos cinco lugares:
- Entornos de no producción inactivos. Staging, QA y entornos de demostración corriendo 24/7 cuando solo se usan en horario laboral.
- Instancias sobredimensionadas. Cómputo aprovisionado para el pico "por las dudas", funcionando la mayor parte del tiempo al 8-12% de uso de CPU.
- Almacenamiento huérfano. Volúmenes sin adjuntar, snapshots olvidados e imágenes AMI viejas que nadie limpió desde la última migración.
- Reservas sin usar. Capacidad reservada comprada para una carga de trabajo que cambió de forma hace seis meses.
- Sorpresas en transferencia de datos. Tráfico entre regiones o zonas de disponibilidad que nadie contempló en la arquitectura original.
Ninguno de estos requiere ingeniería heroica para resolverse. Requieren que alguien realmente mire.
Rightsizing: La Corrección de Mayor Impacto que la Mayoría se Salta
El rightsizing, o ajuste de tamaño, no es glamoroso, y por eso se salta. Consiste en comparar el uso real de CPU, memoria y E/S contra lo aprovisionado, y hacer que coincidan.
Mi regla general: cualquier instancia funcionando por debajo del 40% de utilización promedio durante una ventana de dos semanas es candidata a rightsizing. En la práctica, este único ejercicio suele recuperar entre el 20% y el 30% del gasto en cómputo sin ningún cambio arquitectónico. No se reescribe nada — simplemente se hace coincidir el tamaño del recurso con el tamaño del trabajo.
La trampa es que el rightsizing no es un proyecto de una sola vez. Los patrones de tráfico cambian, se agregan funciones, y los equipos aprovisionan recursos nuevos sin revisar los viejos. Debe ser una revisión trimestral recurrente, no un propósito de año nuevo.
Comprométase con lo que Realmente Usa — con Cuidado
Una vez que su uso base es preciso —solo después del rightsizing, no antes— los descuentos por compromiso son la siguiente palanca. Los Savings Plans de AWS ofrecen hasta un 72% de descuento sobre el precio on-demand, y las Reserved Instances pueden llegar al 75% en cargas de trabajo genuinamente estables. Las Reserved VM Instances de Azure y los Committed Use Discounts de Google Cloud funcionan bajo la misma lógica.
La decisión entre uno y otro no pasa por cuál descuento es mayor, sino por cuánto cambia su infraestructura. Si su equipo redimensiona o cambia de familia de instancias más de una vez por trimestre —cierto para la mayoría de las pymes en crecimiento—, la flexibilidad de los Savings Plans suele superar el descuento marginal de las Reserved Instances, que lo atan a atributos específicos. Recomiendo cubrir el 60-70% de una base estable con compromisos y dejar el resto en on-demand o spot.
Aquí es también donde veo las consecuencias de migraciones que se saltaron una estrategia de costos desde el primer día. Si todavía está trabajando en las decisiones que cubro en mi guía para liderar una migración a la nube, incorpore la estrategia de compromisos desde el año uno en lugar de aplicarla después de la primera factura sorpresiva.
El Almacenamiento No Es "Configurar y Olvidar"
Los costos de almacenamiento crecen en silencio porque nadie los trata como urgentes, hasta que la factura muestra una línea más grande que la de cómputo. Tácticas concretas que consistentemente mueven la aguja:
- Políticas de ciclo de vida. Mover datos poco accedidos de S3 Standard a Infrequent Access o Glacier automáticamente después de 30-90 días. Los ahorros del 40-60% sobre datos archivados son típicos.
- Higiene de snapshots. Automatizar la eliminación de snapshots de EBS y backups de RDS que superen su requisito real de retención, no "por las dudas".
- Eliminar volúmenes huérfanos. Los volúmenes EBS sin adjuntar y las AMI viejas son desperdicio puro; una revisión mensual programada los detecta antes de que se acumulen.
Trabajé con un cliente que operaba una aplicación .NET heredada cuyos backups de base de datos por sí solos representaban el 18% de su factura de AWS. El mismo proyecto de modernización que describo en la migración de una aplicación .NET a AWS Elastic Beanstalk incluyó una limpieza del ciclo de vida de almacenamiento que redujo esa línea a más de la mitad en el primer mes.
Elimine el Cómputo Inactivo con Programación y Autoescalado
Los entornos de no producción son la ganancia más fácil de toda esta lista, y la más ignorada. Si su staging solo necesita correr de lunes a viernes, de 8 a.m. a 8 p.m., programar su apagado fuera de ese horario reduce su costo en cerca de un 65%, con casi ningún esfuerzo de ingeniería — una función Lambda o un programador nativo hace el trabajo.
Para cargas de producción con demanda variable, los grupos de autoescalado atados a métricas reales de utilización, no a un número fijo de instancias, le permiten pagar por la capacidad que coincide con el tráfico real en vez de con su hora más ocupada del mes. Combinado con el rightsizing, suele ser el segundo costo recuperable más grande después de la limpieza de almacenamiento y de entornos inactivos.
Convertir FinOps en una Práctica, No en un Proyecto
El trabajo de optimización anterior ahorrará dinero una vez. Lo que mantiene ese ahorro es tratar el costo como una responsabilidad de ingeniería continua, no como un ejercicio financiero anual. Tres cosas en las que insisto con cada cliente:
- Etiquetar todo. Las etiquetas de asignación de costos por equipo, entorno y proyecto convierten "la factura de AWS está alta" en "el entorno de QA del Proyecto X cuesta $4,000 al mes" — un problema que alguien puede realmente hacerse cargo.
- Realizar una revisión mensual de costos. Treinta minutos, un dashboard, las mismas tres preguntas: qué cambió, qué está inactivo, qué está sobredimensionado.
- Configurar alertas de presupuesto antes de la factura, no después. Alertas basadas en umbrales al 50%, 80% y 100% del gasto proyectado detectan costos descontrolados mientras todavía son pequeños.
Por Dónde Empezar Esta Semana
Si solo tiene tiempo para una cosa, ejecute un informe de rightsizing esta semana. Cada proveedor de nube importante tiene una herramienta integrada — AWS Compute Optimizer, Azure Advisor, GCP Recommender — que identificará gratis a los peores infractores. No va a resolver todo, pero generalmente paga el resto del trabajo de FinOps dentro del primer mes.
La optimización de costos en la nube no es una limpieza de una sola vez. Es una disciplina, y las pymes que la tratan así operan de forma consistentemente más eficiente que competidores que todavía pagan por infraestructura que aprovisionaron hace dos pivots de producto.