El costo de salir de la nube: por qué se decide el día que entras

Los proveedores de nube hicieron la entrada deliciosamente fácil: subir tus datos no cuesta nada, crear recursos es un clic, y el primer año hasta hay créditos. La salida es otra historia —y esa asimetría no es casualidad—. El costo de salir de la nube es real, y lo curioso es que se decide el día que entras, no el día que te quieres ir.

De qué se compone el costo de salida

• Egress: sacar datos de la nube se cobra (meterlos, normalmente no). Para cargas con mucho dato saliente, se acumula.
• Lock-in de arquitectura: si construiste sobre servicios propietarios del proveedor, moverte implica rediseñar, no solo copiar.
• Esfuerzo de reconstrucción: levantar todo en otro lado cuesta tiempo y riesgo.

Por eso complementa lo que ya escribimos sobre cómo elegir entre AWS y Azure: la decisión no es solo cuál entrar, sino con qué grado de atadura.

Se decide al entrar

El punto clave: casi todo el costo de salida se determina en el diseño inicial. Si usaste formatos y servicios estándar donde era razonable, salir es incómodo pero factible; si te ataste a lo propietario en todo, salir es un proyecto entero. Nadie piensa en la salida cuando entra entusiasmado —y ahí está la trampa—.

Ni parálisis ni ceguera

La lección no es "no uses la nube" ni "no uses servicios gestionados" —eso sería renunciar a sus ventajas por miedo—. Es entrar con los ojos abiertos: conocer tus dependencias, preferir lo estándar donde no pierdes nada, y no cerrarte puertas gratis. La portabilidad es un criterio de diseño más, junto al costo y el rendimiento.

Dos partes de la misma plataforma, dos salidas

Una empresa construyó su plataforma sobre un solo proveedor y, un par de años después, quiso mover parte de la operación por razones de costo y consolidación. Ahí descubrió que su plataforma tenía, en realidad, dos mitades con destinos muy distintos. Una se había construido sobre piezas estándar —contenedores y una base de datos común—; esa parte se movió con incomodidad pero sin drama, porque era portable por diseño. La otra se había apoyado de lleno en servicios propietarios del proveedor: una base de datos exclusiva de la nube y funciones sin servidor atadas a su ecosistema. Mover esa mitad no era copiar: era rediseñar y reescribir, un proyecto entero con su propio riesgo. A eso se sumó el costo de egress —sacar un volumen grande de datos acumulados sí se cobra, aunque meterlos hubiera sido gratis—. Al final se movió lo portable y se dejó lo atado donde estaba, no porque conviniera, sino porque salir costaba demasiado. La moraleja es incómoda y clara: casi todo el costo de salida se había decidido años antes, en el diseño inicial, cuando nadie estaba pensando en salir. Preferir lo estándar donde no se pierde nada no es paranoia; es no cerrarse puertas gratis.

La pregunta que conviene hacerse

Al diseñar tu nube, la pregunta no es solo "¿cuánto me cuesta operar esto?", sino ¿cuánto me costaría salir —y estoy aceptando esa atadura a propósito o sin darme cuenta? Contemplarlo desde el inicio es parte de cómo diseñamos infraestructura cloud.