En un servidor propio, sobredimensionar es capital dormido: molesto, pero ya pagado. En la nube es otra cosa —una máquina más grande de lo necesario quema dinero cada hora que está encendida, mes tras mes—. Por eso el hábito de "la hago grande por si acaso", inofensivo en el datacenter, es carísimo en la nube.
El error más común de costos
Elegir mal la VM es la fuga número uno. Se hereda la costumbre del servidor físico —pedir de más para no quedarse corto— y se traslada a un modelo donde cada gigabyte de RAM y cada vCPU de más se cobran continuamente. La nube no perdona el sobredimensionamiento; lo factura.
Familia y tamaño: dos decisiones, no una
Dimensionar bien es dos cosas. La familia: los proveedores ofrecen instancias optimizadas para propósito general, cómputo, memoria, etc.; poner una carga que necesita CPU en una familia de memoria alta es pagar por lo que no usas. Y el tamaño: la capacidad dentro de esa familia. Igual que al dimensionar para virtualizar, se parte del consumo real, no de la etiqueta.
La ventaja de la nube: corregir es fácil
Lo bueno es que aquí el error se arregla rápido. Redimensionar una VM en la nube es sencillo, así que la estrategia sana es empezar modesto, medir y ajustar —y apagar lo que no necesita estar 24/7—. Es lo contrario del hardware físico, donde equivocarte te ata por años. Ese ajuste continuo es la base del rightsizing.
La pregunta que conviene hacerse
Antes de lanzar una VM, la pregunta no es "¿qué tan grande la hago para no quedarme corto?", sino ¿qué consume realmente esta carga, y estoy pagando por eso o por un margen que nadie usa? Vigilar eso es parte de nuestra optimización de costos (FinOps).