Escrito por
Joaquín Colombo
Publicado
15 de octubre de 2025
Última actualización
Cuando construimos la infraestructura de HPC para la división de investigación en IA de una empresa FAANG, gestionábamos más de 6.000 GPUs distribuidas en 20 clusters de forma simultánea. La escala dejó una cosa muy clara: en infraestructura cloud, la diferencia entre un ambiente bien gestionado y uno mal gestionado no se mide en porcentajes — se mide en órdenes de magnitud.
Los clientes que más sufren con los costos cloud no son los que eligieron el proveedor equivocado o los servicios equivocados. Son los que provisionaron para un peor escenario teórico y nunca lo revisaron, o los que optimizaron por performance sin que nadie tuviera asignada la tarea de mirar la factura.
Después de años construyendo y gestionando infraestructura cloud para clientes de servicios financieros, real estate, medios e investigación en IA, esto es lo que realmente encontré que importa.
La fuente más común de desperdicio cloud que veo es el sobre-provisioning al lanzar, combinado con la falta de optimización con el paso del tiempo. Un equipo levanta infraestructura para un producto nuevo, la dimensiona para el pico de carga esperado, y pasa a la siguiente tarea. Seis meses después, la infraestructura está corriendo al 30% de utilización y nadie la tocó.
Los proveedores cloud hacen que provisionar no tenga fricción. Ese es justamente el punto. Pero eso significa que la disciplina de ajustar el tamaño tiene que venir del equipo, no de la plataforma. AWS no te va a avisar que tu instancia de RDS es el doble de grande de lo que necesitás. Simplemente te va a seguir cobrando.
La solución es estructural: asignarle a alguien la responsabilidad explícita de revisar la utilización de recursos con una cadencia regular — mensual como mínimo, semanal en ambientes de alto gasto. No como una auditoría puntual, sino como una función operativa continua.
La mayoría de los equipos usa pricing on-demand por default porque es el camino de menor resistencia. On-demand es la opción correcta para cargas de trabajo variables o impredecibles — pero para cualquier cosa con una base predecible, es la opción más cara.
Las instancias reservadas en AWS suelen generar entre 30% y 60% de ahorro comparadas con on-demand para el mismo compute. La contrapartida es un compromiso de 1 o 3 años. Para cargas de trabajo que claramente van a estar corriendo durante ese plazo — bases de datos de producción, servidores de aplicación core, infraestructura de analítica siempre activa — la cuenta es directa.
Las instancias spot llevan esto más lejos: hasta 90% de descuento sobre el precio on-demand para cargas de trabajo que toleran interrupciones. Entrenamientos de IA, procesamiento batch de datos, tareas de background no críticas — son candidatos naturales. En el proyecto de HPC, usamos instancias spot para capacidad de compute en ráfaga durante los ciclos de entrenamiento, con capacidad reservada on-demand como base. Esa combinación redujo los costos de compute de forma significativa sin afectar la velocidad de la investigación.
El framework de decisión es simple: on-demand para lo impredecible, reservado para bases predecibles, spot para cargas de trabajo que toleran interrupciones.
Los costos de compute reciben atención porque son visibles y variables. Los costos de storage se acumulan en silencio y son fáciles de ignorar hasta que se vuelven significativos.
El principio clave es la tiering. No todos los datos necesitan vivir en storage de alto rendimiento. Los datos accedidos a diario van en S3 Standard o equivalente. Los datos accedidos mensualmente van en un nivel de menor costo. Los datos retenidos por compliance pero rara vez accedidos van en cold storage o Glacier. La mayoría de las organizaciones pagan precio de S3 Standard para datos de las tres categorías porque nadie configuró políticas de lifecycle.
En proyectos intensivos en datos, implementamos políticas de lifecycle desde el día uno — transiciones automáticas entre niveles de storage según los patrones de acceso. Es una configuración que se hace una sola vez y que se potencia con el tiempo. Cuanto más viejo es un dataset, más se acumula el ahorro.
No podés optimizar lo que no podés medir, y la mayoría de los equipos no puede medir su gasto cloud con el nivel de granularidad que hace que optimizar sea accionable.
Los tags de asignación de costos — aplicados a cada recurso al crearlo — te permiten atribuir el gasto a equipos, proyectos, productos o clientes específicos. Sin ellos, tu factura de AWS es un solo número que te dice cuánto gastaste pero no dónde ni por qué.
En todos los proyectos que entregamos, el tagging es parte de la configuración inicial de infraestructura, no una ocurrencia tardía. Un equipo que puede ver que el Proyecto A consumió 60% del presupuesto de compute el mes pasado, mientras que el Proyecto B consumió 15% y tenía el triple de tamaño, tiene la información que necesita para tomar decisiones. Un equipo que mira un solo total, no.
Las organizaciones que gestionan bien sus costos cloud suelen tener algo en común: tratan el gasto en infraestructura como una decisión de producto, no solo como un costo de IT. Los ingenieros entienden las implicancias de costo de las decisiones de arquitectura. Los product managers incluyen los costos de infraestructura en los cálculos de ROI. Finanzas tiene visibilidad del gasto cloud a nivel de proyecto.
Esto no es cuestión de tacañería — es tomar trade-offs informados. Gastar más en managed services para reducir la sobrecarga de ingeniería suele ser la decisión correcta. Gastar más en instancias reservadas para reducir el costo de compute por unidad suele ser la decisión correcta. Tomar esas decisiones de forma consciente, con datos que las respalden, es lo que separa a los equipos que controlan su gasto cloud de los que solo reaccionan a él.
¿Tu gasto cloud crece más rápido que tu negocio? Hablemos sobre qué lo está impulsando →
© 2026 - Renaiss, hecho con cariño