La factura alta del primer mes en la nube casi nunca viene de haber migrado: viene de haber migrado con el tamaño que el servidor tenía, no con el que la carga necesita. En el centro de datos sobredimensionar era prudente; en la nube se paga cada mes.
A continuación: por qué el tamaño heredado sale caro, qué conviene medir, qué exige criterio y cómo se ordena el ejercicio.
En infraestructura propia el dimensionamiento se hacía una vez, para tres o cinco años, y con margen. Comprar de más era la decisión conservadora porque ampliar después significaba otra compra.
En la nube ese mismo margen se convierte en un costo recurrente que nadie vuelve a revisar, y se arrastra en cada renovación.
Por qué el tamaño heredado sale caro
La práctica habitual al migrar es replicar: si el servidor tenía dieciséis núcleos, se aprovisiona una instancia de dieciséis núcleos. Es rápido, reduce el riesgo del cambio y es exactamente donde se origina el sobrecosto.
El problema es que ese dieciséis no describía la carga: describía la compra que se hizo años atrás, cuando se proyectaba un crecimiento que puede no haber ocurrido.
A eso se añade el margen de seguridad que cada capa fue agregando —el proveedor, el arquitecto, el administrador— hasta que el tamaño final no corresponde a ninguna medición.
Qué conviene medir
Uso real en un período representativo. Procesador, memoria, disco y red durante varias semanas, incluyendo el cierre de mes y cualquier pico estacional conocido. Una semana tranquila produce un dimensionamiento que falla el primer día ocupado.
El percentil, no el promedio. El promedio esconde los picos y el máximo los sobrerrepresenta. Dimensionar contra un percentil alto captura la carga real sin pagar por el pico irrepetible de una sola noche.
El patrón horario. Una carga que trabaja ocho horas y duerme dieciséis es candidata a apagado programado, y eso cambia el cálculo más que elegir bien el tamaño.
La dependencia entre componentes. Medir un servidor aislado lleva a moverlo solo y descubrir después que hablaba constantemente con otro que se quedó, con la latencia y el costo de tráfico que eso implica.
Lo que exige criterio
Hay cargas donde el margen es una decisión deliberada, no un descuido. Un sistema con picos impredecibles y alto costo de indisponibilidad se dimensiona con holgura a propósito, y conviene que quede escrito para que nadie lo optimice más tarde por desconocimiento.
También hay que decidir qué hacer con lo que no debería migrar tal cual. Una aplicación que sólo funciona sobre una versión que ya no recibe soporte plantea una elección —actualizar, sustituir o mantener— que no es de infraestructura.
Y la elección entre capacidad reservada y bajo demanda depende de cuánta certeza haya sobre la permanencia de la carga. Comprometer capacidad a un año sobre algo que quizá se sustituya en seis meses ahorra en la tarifa y pierde en la flexibilidad.
Qué cambia según el tipo de carga
Las cargas estables y predecibles —bases de datos de sistemas centrales, servicios internos de uso constante— se benefician de compromisos de capacidad y de un dimensionamiento ajustado.
Las cargas variables —campañas, cierres, procesamiento por lotes— aprovechan la elasticidad, y ahí el error caro es el contrario: dimensionar para el pico permanente en lugar de crecer y decrecer.
Los ambientes que no son de producción merecen su propio criterio, porque suelen replicar el tamaño de producción sin necesitarlo y representan una porción de la factura mayor de lo que se supone.
Cómo se ordena el ejercicio
Instrumente antes de decidir. Si no hay histórico de uso, el primer paso no es elegir instancias sino recoger datos durante un período que incluya un ciclo completo de negocio.
Agrupe por patrón, no por aplicación. Cargas de comportamiento similar admiten la misma decisión, y eso reduce un inventario largo a unas pocas categorías manejables.
Y planifique la revisión desde el inicio. El dimensionamiento correcto en la migración deja de serlo cuando el uso cambia; sin una revisión periódica el ahorro conseguido se erosiona en unos meses.
Qué se necesita antes
Un inventario de cargas con responsable, monitoreo capaz de entregar histórico y un acuerdo sobre quién autoriza un cambio de tamaño. Sin lo último, el ajuste se propone y no se ejecuta.
Conviene también fijar el indicador con el que se juzgará el resultado. El costo total no basta, porque crece con el negocio; el costo por unidad de trabajo —por transacción, por usuario, por pedido— dice si la eficiencia mejoró.
El error que se repite en la segunda ola
La primera ola de migración suele hacerse con cuidado porque es visible y hay atención de la dirección. La segunda se hace por inercia, replicando las decisiones de la primera sin repetir la medición.
Ahí se cuela el sobrecosto estructural: se adoptan como estándar los tamaños que se eligieron para otras cargas, y la organización termina con un catálogo interno de instancias que nadie justificó.
Conviene tratar cada ola como un ejercicio nuevo, aunque sea más corto, y reservar el estándar sólo para lo que ya se midió y se comportó como se esperaba.
¿Cuánto tiempo hay que medir antes de migrar?
El suficiente para cubrir un ciclo completo de negocio, incluido el cierre de mes y cualquier estacionalidad conocida. Medir una semana tranquila produce un dimensionamiento que falla el primer día ocupado.
¿Conviene migrar con el mismo tamaño y ajustar después?
Es una opción defendible cuando el riesgo del cambio es alto, siempre que el ajuste quede agendado con responsable y fecha. Sin eso, el tamaño provisional se vuelve permanente.
¿Qué indicador conviene seguir?
El costo por unidad de trabajo, no el costo total. El total crece con el negocio; el unitario dice si la eficiencia mejoró o empeoró.
¿Y los ambientes de desarrollo y pruebas?
Merecen criterio propio. Suelen replicar el tamaño de producción sin necesitarlo y pesan en la factura más de lo que se supone.
