La pregunta “AWS o Azure” suele plantearse como una decisión binaria y definitiva. En la práctica, la mayoría de las organizaciones termina operando cargas en ambos — y el verdadero riesgo no es elegir mal un proveedor, es diseñar la arquitectura de forma que después no se pueda salir de él.
El costo real del vendor lock-in
El lock-in casi nunca aparece en el contrato inicial. Aparece meses después, en los costos de egress para mover datos hacia fuera, en servicios administrados propietarios que no tienen equivalente directo en otro proveedor, o en un modelo de identidad y networking que no se traduce sin rediseñar buena parte de la arquitectura.
Cuanto más se apoya una solución en servicios exclusivos de un hyperscaler, más cara —en dinero y en tiempo de ingeniería— se vuelve la salida. Eso no es necesariamente un error: a veces vale la pena. El error es no decidirlo a propósito.
Tres decisiones que determinan qué tan atado queda
“La pregunta no es qué nube es mejor. Es qué tan caro sería, en dinero y en tiempo, salir de la que elija hoy.”
Cómo decidir sin comprometerse de más
La decisión no es “AWS o Azure” a nivel de organización, sino carga por carga: qué tan crítica es, qué tan sensible es a los servicios propietarios de un proveedor, y qué tanto pesa la portabilidad futura frente a la velocidad de desarrollo hoy.
Un marco de decisión explícito — documentado, no implícito en las preferencias del equipo que implementó primero — evita que la elección de hoy se convierta en la dependencia forzada de mañana.