Multi-cloud es el argumento favorito de los proveedores de nube — curiosamente, de todos ellos al mismo tiempo. AWS, Azure y GCP tienen documentación detallada sobre cómo ejecutar arquitectura multi-cloud con cada uno de ellos como proveedor principal. La lógica suena sólida: no depender de un único proveedor, mantener opciones de salida, negociar mejores contratos. El problema es que la premisa rara vez sobrevive al contacto con la operación real.
La mayoría de las empresas que se declaran multi-cloud están describiendo un accidente, no una arquitectura. Salesforce corre en AWS, Google Analytics está en GCP, Active Directory vive en Azure AD. Eso es SaaS en nubes diferentes — no es multi-cloud de infraestructura.
Qué es multi-cloud de verdad — y qué no lo es
Multi-cloud técnico significa distribuir cargas de trabajo de infraestructura entre dos o más proveedores de forma intencional, con un criterio definido para cada asignación. La carga A corre en AWS porque el equipo tiene experiencia comprobada y los datos de producción ya están allí. La carga B corre en GCP porque el volumen de ML justifica TPUs. Ambos se comunican con latencia y seguridad definidas, monitoreados con herramientas unificadas.
Eso requiere:
- Dos conjuntos completos de habilidades operativas — certificaciones distintas, modelos de seguridad diferentes, estructuras de billing y pricing separadas.
- Herramientas de orquestación cross-cloud — Terraform multi-proveedor, observabilidad unificada (Datadog, Grafana Cloud), gestión de identidad e IAM cross-cloud.
- Contabilización del costo de egress — el tráfico que cruza fronteras de nube tiene precio real. Las cargas que se comunican entre AWS y GCP agregan 20–100ms de latencia y costos de egress reales por GB transferido.
Lo que aparece en la práctica con mucha más frecuencia no es esto. Es una empresa con ERP en Azure (legado de licenciamiento Microsoft), warehouse en Snowflake corriendo en AWS, y un proyecto de ML en GCP que empezó como PoC y nunca migró. Tres proveedores por accidente, no por diseño.
Por qué el argumento de lock-in no cierra como parece
El argumento central para multi-cloud es: "usa dos proveedores para no quedar atrapado en ninguno." El problema es que el lock-in que multi-cloud resuelve — compute y networking — no es el lock-in que realmente duele.
El lock-in que duele es de datos y servicios propietarios. Mover 1 PB de S3 a otro storage cuesta egress fees del orden de US$ 20.000–90.000 según la región. Mover cargas de Kubernetes de una nube a otra es una operación de semanas — costosa pero factible. El lock-in más profundo vive en los servicios propietarios — Redshift, BigQuery, Synapse — que acumulan dependencia de SQL dialect e integraciones específicas. Ese es el lock-in que multi-cloud no resuelve, porque resolverlo significaría renunciar exactamente a lo que diferencia a cada proveedor.
La ironía: para extraer el máximo de cada nube se usan sus servicios propietarios. Cuanto más se usan, más se queda atrapado. Multi-cloud como estrategia para evitar lock-in obliga a usar solo los denominadores comunes entre proveedores — que son, por definición, los menores diferenciales técnicos de cada uno.
Multi-cloud como estrategia para evitar lock-in es una contradicción: solo funciona si no se usa lo que hace valiosa a cada nube.
Cinco situaciones en que multi-cloud tiene sentido
Existen escenarios donde multi-cloud es la respuesta correcta. Son cinco, y todos tienen un criterio técnico o regulatorio específico — no sesgo de proveedor.
Soberanía de datos y regulación. Datos de clientes sujetos a restricciones territoriales contractuales, o datos europeos bajo GDPR con requisito de data residency en la UE. Si el proveedor principal no tiene una región local adecuada, un segundo proveedor puede ser una obligación legal, no una opción arquitectónica.
Best of breed con capacidad operativa real. GPU compute en GCP (TPUs son genuinamente más baratos para ciertos workloads de ML) + AWS para cargas de trabajo empresariales establecidas. Solo tiene sentido cuando el equipo tiene experiencia operativa real en ambos proveedores — no como legado de una PoC que quedó en producción por inercia.
Disaster recovery con SLA contractual. Primary en AWS São Paulo, failover en Azure East US. Costo justificado cuando el SLA de disponibilidad requerido por contrato no se alcanza con una sola región de un único proveedor — escenario que existe en sectores financiero y de salud.
Herencia de adquisición. Se adquirió una empresa que corre en GCP; la organización corre en AWS. Multi-cloud por herencia, no por diseño. La decisión real es consolidar o coexistir — no fingir que la situación es estratégica. Si la decisión es coexistir, operacionalícelo con rigor en lugar de dejar que crezca en silos paralelos sin gobernanza.
Negociación de contrato con piloto real. Tener un segundo proveedor en uso activo — aunque en menor escala — cambia la posición negociadora con el proveedor principal. Funciona cuando el piloto es genuinamente operacional, no un ejercicio de demostración.
Fuera de estos cinco, la respuesta correcta casi siempre es una sola nube bien operada y bien gobernada.
El overhead que el slide no muestra
Estimaciones de equipos que operaron multi-cloud real durante dos o más años apuntan a 30–40% de overhead operativo en comparación con una configuración single-cloud equivalente bien configurada. Costo medible en horas de ingeniería, tickets de soporte cruzado, incidentes de permisos en fronteras de IAM distintas, y onboarding de nuevos ingenieros que deben aprender dos mundos operativos.
La elección de warehouse en la práctica casi siempre depende del contexto organizacional, no de benchmarks técnicos aislados. El mismo principio aplica a la elección de nube: el mejor proveedor es el que el equipo puede operar bien — no el que tiene el mayor conjunto de funciones en el slide comparativo.
Multi-cloud agrega complejidad estructural permanente. Antes de decidir, el número relevante es el overhead proyectado para cinco años de operación — no el costo de setup del primer mes.
La pregunta que simplifica la decisión
Una pregunta resuelve el 80% de los casos: ¿por qué no es una sola nube?
Si la respuesta es "porque nuestro proveedor principal no tiene X que necesitamos" — esa es la única razón técnica que cierra por sí misma. Verificar si X existe o si es una cuestión de madurez de uso antes de asumir que un segundo proveedor lo resuelve.
Si la respuesta es "para evitar el lock-in" — calcular el costo de lock-in hipotético (egress + migración eventual) versus el overhead de multi-cloud durante los próximos cinco años. En el 80% de los casos, el overhead real supera el costo estimado de lock-in.
Si la respuesta es "porque el directorio lo pidió" o "porque el competidor lo hace" — hay un problema de comunicación estratégica, no de arquitectura.
Quien está definiendo arquitectura de datos en 2026 enfrenta presión para adoptar lo que suena moderno. Multi-cloud suena moderno — y esa es, con frecuencia, la única razón real detrás de la decisión.
Multi-cloud no es incorrecto. Es costoso — y el costo solo se justifica cuando la ganancia específica (regulación, capacidad técnica comprobada, DR con SLA contractual, o apalancamiento real en negociación de contrato) supera el overhead permanente de operar dos proveedores con calidad. La pregunta correcta no es "¿deberíamos ser multi-cloud?" sino "¿qué problema específico estamos resolviendo que una sola nube bien operada no resuelve?"