Multi-Cloud en la Practica: AWS + Azure + GCP

La pregunta equivocada y la correcta

“Cual cloud es mejor?” es la pregunta que todo CTO formula y ninguna respuesta util puede contestar. La pregunta correcta es: “Que combinacion de servicios cloud resuelve mis problemas concretos al menor coste operativo?” Y la respuesta, casi siempre, implica mas de un proveedor.

El multi-cloud no es una estrategia que se elige. Es una realidad que se gestiona. En nuestra experiencia con empresas medianas españolas, la mayoria ya opera en multi-cloud sin saberlo: el CRM esta en la nube de un vendor, el ERP en otro, la web en un tercero, el correo en Google Workspace y los archivos en OneDrive. El paso de multi-cloud accidental a multi-cloud deliberado es donde se captura el valor.

Este whitepaper documenta patrones reales de implementacion multi-cloud, con numeros, herramientas concretas y las lecciones que hemos aprendido desplegando cargas de trabajo entre AWS, Azure y GCP para clientes en logistica, legal y retail.

Cuando usar cada nube (y por que)

La decision de donde ejecutar cada carga de trabajo deberia basarse en tres factores: capacidad diferencial del proveedor, coste total y afinidad con el ecosistema existente.

AWS: la navaja suiza

AWS tiene el catalogo mas amplio: mas de 200 servicios. Es la eleccion por defecto cuando no hay una razon fuerte para ir a otro sitio, y la mejor opcion para:

Compute general: EC2 ofrece la mayor variedad de tipos de instancia. Para workloads con patrones de uso irregulares, Spot Instances recortan costes un 60-90% frente a On-Demand.
Serverless maduro: Lambda, Step Functions, API Gateway y DynamoDB forman un stack serverless que lleva años en produccion a escala. El ecosistema de herramientas y documentacion no tiene rival.
Data lakes: S3 + Glue + Athena + Lake Formation es el stack de data lake mas probado del mercado. El coste de almacenamiento en S3 (0.023 $/GB/mes en us-east-1) sigue siendo el benchmark.
Networking avanzado: Transit Gateway, PrivateLink y Global Accelerator resuelven topologias complejas que en otros proveedores requieren workarounds.

Donde AWS no brilla: developer experience en servicios de alto nivel (comparar SageMaker con Vertex AI), integracion con el stack de Microsoft, y precio de egreso de datos (uno de los costes ocultos mas dolorosos del multi-cloud).

Azure: el puente al enterprise

Azure es la eleccion natural cuando la organizacion ya vive en el ecosistema Microsoft. Pero tiene meritos propios:

Identidad: Azure Active Directory (ahora Entra ID) es el directorio de identidad mas completo del mercado. Si necesitas SSO, MFA, Conditional Access y gestion de dispositivos, no hay nada comparable. Y funciona como proveedor de identidad para AWS y GCP.
Hybrid cloud: Azure Arc permite gestionar servidores on-premise, edge y multi-cloud desde un unico plano de control. Para empresas con infraestructura legacy que no puede migrar, es un diferenciador real.
AI/ML enterprise: Azure OpenAI Service da acceso a modelos GPT-4 con las garantias de compliance, residencia de datos y SLA que las grandes empresas necesitan. La integracion con Cognitive Services cubre vision, lenguaje y voz.
Bases de datos gestionadas: Cosmos DB ofrece multi-model y distribucion global con consistencia configurable. SQL Database es el SQL Server gestionado mas maduro del mercado.

Donde Azure no brilla: la consola de administracion (Azure Portal es notoriamente lenta y confusa), la documentacion (fragmentada entre versiones y rebrandings constantes), y el pricing de algunos servicios premium.

GCP: el ingeniero silencioso

GCP tiene la menor cuota de mercado de los tres (11% frente al 31% de AWS y 25% de Azure segun Synergy Research Q4 2024), pero sus servicios diferenciales son genuinamente superiores:

Data y analytics: BigQuery es, en nuestra experiencia, el data warehouse mas potente y el mas facil de operar. No hay clusters que gestionar, escala automaticamente, y el modelo de pricing por query procesada alinea coste con uso real. Un cliente nuestro procesa 40 TB/mes por menos de 800 EUR.
Kubernetes: GKE es el servicio de Kubernetes gestionado mas maduro. Dado que Google creo Kubernetes, esto no sorprende. Autopilot mode elimina la gestion de nodos por completo. Para organizaciones que estandarizan en Kubernetes, GKE reduce el overhead operativo significativamente.
Networking: la red global de Google (uno de los backbones privados mas grandes del mundo) proporciona latencias consistentemente menores para trafico inter-region. Premium Tier routing esta incluido por defecto.
AI/ML: Vertex AI unifica el ciclo completo de ML. TPUs ofrecen rendimiento por dolar superior a GPUs para training de modelos grandes.

Donde GCP no brilla: el ecosistema de partners y consultores es menor, el soporte enterprise ha mejorado pero sigue detras de AWS y Azure, y la percepcion (justificada o no) de que Google abandona productos genera dudas en decisores conservadores.

El patron multi-cloud que funciona

No todos los patrones multi-cloud son iguales. Hemos visto tres:

Multi-cloud por servicio diferencial (recomendado): usar el mejor servicio de cada proveedor. BigQuery para analytics, Azure AD para identidad, AWS para compute general. Cada carga de trabajo vive en un solo proveedor. La complejidad esta en la conectividad y la identidad, no en la portabilidad.

Multi-cloud por redundancia (caro, rara vez justificado): ejecutar la misma carga de trabajo en dos proveedores para evitar dependencia. Suena bien en una presentacion de estrategia. En la practica, duplica costes, multiplica la complejidad operativa y rara vez funciona cuando se necesita (el failover entre clouds es mas complejo de lo que parece). Solo se justifica para servicios absolutamente criticos donde el SLA de un solo proveedor no es suficiente.

Multi-cloud por politica (inevitable en regulados): sectores como banca, salud o administracion publica pueden exigir multi-cloud por regulacion o por politica de gestion de riesgo del proveedor. Aqui no hay eleccion. Hay que implementarlo bien.

El primer patron es el que recomendamos para el 90% de las organizaciones. Captura los beneficios diferenciales de cada nube sin la explosion de complejidad de los otros dos.

Networking entre nubes

La conectividad entre proveedores cloud es el primer problema tecnico serio del multi-cloud. Las opciones, de menor a mayor complejidad:

VPN site-to-site

La opcion mas sencilla. Un tunel IPsec entre la VPC de AWS y la VNet de Azure (o la VPC de GCP). Cada par de proveedores requiere su propia configuracion.

AWS: Virtual Private Gateway o Transit Gateway
Azure: VPN Gateway
GCP: Cloud VPN

Ancho de banda tipico: 1.25 Gbps por tunel. Suficiente para la mayoria de cargas inter-cloud. Coste: desde 35 $/mes por gateway + coste de datos transferidos. El problema: la latencia añade 5-15 ms dependiendo de regiones, y gestionar multiples tuneles se convierte en un ejercicio de paciencia.

Interconexion dedicada

Para volumen alto y latencia baja, la interconexion fisica es la opcion correcta:

AWS Direct Connect: conexion dedicada desde 50 Mbps a 100 Gbps
Azure ExpressRoute: conexion dedicada con alcance global
GCP Cloud Interconnect: Dedicated (10-100 Gbps) o Partner (50 Mbps - 50 Gbps)

El truco para multi-cloud: usar un punto de interconexion comun. Proveedores como Equinix, Megaport o PacketFabric operan fabrics de interconexion donde puedes conectar AWS, Azure y GCP en el mismo datacenter de colocacion, con latencias sub-milisegundo entre proveedores. Megaport Cloud Router, por ejemplo, permite crear una topologia mesh entre los tres proveedores con un unico contrato.

Coste: desde 300-500 EUR/mes para conexiones de 1 Gbps. Se justifica cuando el trafico inter-cloud supera los 5 TB/mes (punto en el que el coste de egreso por internet supera el de la interconexion dedicada).

Network mesh con service mesh

Para organizaciones con Kubernetes en multiples nubes, un service mesh como Istio con multi-cluster o Cilium Cluster Mesh proporciona conectividad a nivel de servicio. Los servicios en GKE pueden comunicarse directamente con servicios en EKS como si estuvieran en el mismo cluster.

Es la opcion mas elegante pero tambien la mas compleja de operar. Solo la recomendamos para equipos con experiencia solida en Kubernetes y service mesh.

Egreso de datos: el impuesto invisible

El coste mas subestimado del multi-cloud es el egreso de datos. Los tres proveedores cobran por los datos que salen de su red:

Proveedor	Egreso a internet	Egreso a otra cloud
AWS	0.09 $/GB	0.09 $/GB (via internet) / 0.02 $/GB (Direct Connect)
Azure	0.087 $/GB	0.087 $/GB (via internet) / 0.02 $/GB (ExpressRoute)
GCP	0.12 $/GB (Premium)	0.12 $/GB (via internet) / 0.02 $/GB (Interconnect)

Para un flujo de datos de 10 TB/mes entre AWS y GCP por internet, el coste de egreso es aproximadamente 900 $/mes solo en transferencia. Con interconexion dedicada, cae a 200 $/mes, pero hay que sumar el coste del circuito.

La leccion practica: diseña la arquitectura para minimizar el movimiento de datos entre nubes. Los datos deben vivir cerca del compute que los procesa. Si BigQuery es tu data warehouse, los datos de analytics deben fluir hacia GCP una vez (ETL batch nocturno, por ejemplo), no consultarse en tiempo real desde AWS.

Federacion de identidad

Gestionar identidades separadas en cada proveedor es un infierno operativo y un riesgo de seguridad. La solucion es federacion: un unico proveedor de identidad (IdP) que autentique usuarios en todas las nubes.

Azure AD como IdP central

La configuracion mas comun (y la que mejor funciona en nuestra experiencia) usa Azure AD (Entra ID) como fuente de verdad:

AWS: Configurar SAML 2.0 federation entre Azure AD y AWS IAM Identity Center (antes SSO). Cada grupo de Azure AD se mapea a un Permission Set en AWS. Los usuarios acceden a la consola de AWS y obtienen credenciales temporales via AssumeRoleWithSAML.

GCP: Configurar Workforce Identity Federation. GCP acepta tokens de Azure AD directamente para acceder a la consola y APIs. Para cuentas de servicio (workloads automatizados), Workload Identity Federation permite que un pod en AKS obtenga credenciales de GCP sin secretos estaticos.

Beneficios tangibles: un unico punto de gestion de usuarios, desprovisioning inmediato (desactivas al usuario en Azure AD y pierde acceso a las tres nubes), MFA unificado, y logs de acceso centralizados.

Workload Identity Federation

Para comunicacion entre servicios (machine-to-machine), la federacion de identidad de workload elimina la necesidad de secretos estaticos:

Un servicio en AWS que necesita acceder a BigQuery obtiene un token de GCP usando sus credenciales de AWS (via STS y Workload Identity Federation)
Un pod en GKE que necesita acceder a S3 obtiene credenciales temporales de AWS via Web Identity Federation
El resultado: cero secretos de larga duracion, rotacion automatica, auditoria completa

Configurarlo requiere entender las relaciones de confianza entre proveedores, pero una vez establecido, elimina una clase entera de vulnerabilidades.

Gobernanza de costes

El multi-cloud multiplica la complejidad del FinOps. Tres facturas, tres modelos de pricing, tres consolas de coste. Sin una estrategia de gobernanza, los costes se descontrolan en semanas.

Herramientas de visibilidad

Nativas: AWS Cost Explorer, Azure Cost Management, GCP Billing. Cada una excelente para su proveedor, inutil para visibilidad consolidada.

Multi-cloud: Apptio Cloudability, Flexera One, o la opcion open-source Opencost (para entornos Kubernetes). Varian en una plataforma que agrega costes de los tres proveedores, normaliza categorias y permite alertas unificadas.

En nuestra experiencia, la herramienta importa menos que el proceso. Lo critico es:

Etiquetado consistente: definir un esquema de tags (environment, team, service, cost-center) y aplicarlo en los tres proveedores. Sin tags, no hay forma de atribuir costes a equipos o proyectos.
Presupuestos por equipo: cada equipo tiene un budget mensual. Las alertas saltan al 80% y al 100%. El equipo es responsable de su gasto.
Revision mensual: 30 minutos revisando las 10 lineas de coste mas altas de cada proveedor. El 80% de la optimizacion viene de corregir los 3-4 recursos mas caros.

Committed Use Discounts

Cada proveedor ofrece descuentos por compromiso de uso:

AWS: Reserved Instances (1 o 3 años) y Savings Plans (compute flexible)
Azure: Reserved Instances y Azure Savings Plan
GCP: Committed Use Discounts (1 o 3 años) y Sustained Use Discounts (automaticos)

La estrategia multi-cloud: comprometer en cada proveedor solo las cargas de trabajo que sabes que permanecen ahi. El compute base estable de cada nube se reserva; los picos se cubren con on-demand o spot.

Un error comun: reservar capacidad antes de haber optimizado. Primero right-size, luego reserva. Hemos visto empresas pagar reservas de instancias m5.4xlarge que deberian ser m5.xlarge.

Coste de la complejidad

El multi-cloud tiene un coste operativo que rara vez se contabiliza: el equipo necesita expertise en tres proveedores (¿cuantos ingenieros dominan AWS y Azure y GCP?), las herramientas de IaC deben soportar multiples proveedores, el testing se multiplica, y el debugging de problemas inter-cloud es significativamente mas complejo.

Nuestro consejo: contabiliza 1.5-2x el coste de ingenieria cuando planifiques multi-cloud. Si el equipo es de 5 ingenieros gestionando una sola nube, necesitaras 7-8 para gestionar tres con el mismo nivel de calidad. O, mas realista, aceptar que el nivel de profundidad en cada nube sera menor.

CI/CD multi-cloud

El pipeline de CI/CD es donde la complejidad del multi-cloud se materializa diariamente. Cada despliegue toca potencialmente multiples proveedores, y la cadena de permisos, artefactos y validaciones se multiplica.

Arquitectura de pipeline

La estructura que mejor funciona es un sistema de CI centralizado con CD distribuido:

CI centralizado: GitHub Actions o GitLab CI como fuente unica. El build, los tests y la generacion de artefactos ocurren en un solo lugar. Los artefactos (container images, binarios, paquetes IaC) se publican en un registro comun.

CD distribuido: cada proveedor tiene su propio mecanismo de despliegue. ArgoCD para Kubernetes (funciona igual en EKS, AKS y GKE). AWS CodeDeploy para Lambda y ECS. Azure Pipelines para Azure-specifics. El punto clave: el artefacto es el mismo, solo cambia el destino.

Registro de artefactos: un unico container registry (ECR, Artifact Registry o un registry neutral como Harbor) que todos los clusters de todos los proveedores pueden acceder. Evita duplicar imagenes en registros de cada proveedor.

Terraform como lingua franca

La gestion de infraestructura multi-cloud es mas eficaz cuando se combina con practicas de infraestructura como codigo. Terraform es la herramienta de IaC que mejor soporta multi-cloud, y en la practica es donde la mayoria de las organizaciones convergen. El provider model permite definir recursos de AWS, Azure y GCP en el mismo lenguaje.

La estructura que recomendamos:

infrastructure/
├── modules/
│   ├── aws-vpc/
│   ├── azure-vnet/
│   ├── gcp-vpc/
│   └── shared/
│       ├── dns/
│       └── monitoring/
├── environments/
│   ├── staging/
│   │   ├── aws.tf
│   │   ├── azure.tf
│   │   └── gcp.tf
│   └── production/
│       ├── aws.tf
│       ├── azure.tf
│       └── gcp.tf
└── terragrunt.hcl

Terragrunt encima de Terraform gestiona la configuracion DRY entre entornos y proveedores. El estado de Terraform se almacena en un backend remoto (S3, GCS o Terraform Cloud) con locking.

Un consejo practico: no intentes crear abstracciones que unifiquen los tres proveedores. Un modulo “generic-compute” que funcione en AWS, Azure y GCP es una quimera que reduce la calidad en los tres. Acepta que cada proveedor tiene su API y sus idioms. La unificacion ocurre en el pipeline y en la estructura del repositorio, no en el codigo de infraestructura.

Gestion de secretos

Los secretos (API keys, certificados, contraseñas) necesitan un unico punto de gestion:

HashiCorp Vault es la opcion mas completa: almacena secretos, genera credenciales dinamicas para cada proveedor, rota automaticamente, y audita todo acceso. La complejidad de operarlo se justifica en entornos multi-cloud serios.

Alternativa pragmatica: usar el gestor de secretos de un proveedor como fuente primaria (AWS Secrets Manager o GCP Secret Manager) y sincronizar a los otros mediante External Secrets Operator en Kubernetes. Menos elegante, pero mas facil de operar.

Observabilidad multi-cloud

Monitorizar tres nubes con tres herramientas nativas es una receta para puntos ciegos. La observabilidad multi-cloud necesita un plano unificado.

Stack recomendado

Metricas: Grafana Cloud con Prometheus remoto o Grafana Mimir como backend. Los agentes de OpenTelemetry o Prometheus en cada proveedor exportan metricas a un unico Mimir. Dashboards unificados en Grafana que muestran el estado de servicios independientemente de donde corren.

Logs: Grafana Loki como almacen centralizado. Cada proveedor tiene un agente (Promtail, Fluentd o el OTel collector) que envia logs a Loki. Alternativa: Datadog o Elastic Cloud si el presupuesto lo permite.

Trazas: OpenTelemetry Collector en cada entorno exportando a Grafana Tempo o Jaeger centralizado. Las trazas distribuidas son especialmente criticas en multi-cloud, porque una peticion puede cruzar dos o tres proveedores.

Alertas: Grafana Alerting con rutas a PagerDuty u OpsGenie. Una unica politica de alertas para toda la infraestructura.

Metricas de coste como metricas de observabilidad

Un patron que funciona muy bien: tratar el coste como una metrica mas de observabilidad. Exportar datos de billing de cada proveedor a Prometheus (existen exporters para los tres) y crear dashboards que muestren coste por servicio, por equipo y por entorno junto a las metricas tecnicas. Cuando el equipo ve que un servicio cuesta 400 $/dia en un panel que tambien muestra que procesa 200 peticiones/minuto, el coste por peticion se hace visible y accionable.

Errores que hemos cometido

Transparencia total: no todo ha ido bien en nuestras implementaciones multi-cloud.

Subestimar el egreso de datos. En un proyecto de logistica, diseñamos un pipeline donde los datos de tracking (AWS) alimentaban un modelo de prediccion (GCP Vertex AI) en tiempo real. El coste de egreso era 3x lo estimado. La solucion fue cambiar a batch processing nocturno: los datos se exportan una vez al dia a GCS y el modelo se reentrena con datos de las ultimas 24 horas. La latencia de prediccion aumento de minutos a horas, pero el coste cayo un 70%.

Ignorar las diferencias de IAM. AWS IAM, Azure RBAC y GCP IAM usan modelos diferentes. Un “administrador” en AWS no tiene los mismos permisos que un “Owner” en GCP. La primera vez que configuramos federacion de identidad, los permisos estaban mal mapeados durante dos semanas. Ahora documentamos el mapeo de roles explicitamente antes de implementar.

Demasiada abstraccion demasiado pronto. Intentamos crear un framework interno que abstrajera las diferencias entre proveedores. Seis meses despues, el framework era el mayor generador de bugs del proyecto. Ahora aceptamos las diferencias y las gestionamos con convenciones claras en lugar de abstracciones magicas.

Plan de accion: de la teoria a la implementacion

Para la organizacion que esta considerando multi-cloud deliberado, este es el orden que recomendamos:

Mes 1-2: Inventario y decision

Mapear todas las cargas de trabajo existentes (incluyendo SaaS)
Identificar candidatos para cada proveedor basandose en capacidades diferenciales
Estimar costes de networking y egreso
Definir el esquema de etiquetado

Mes 3-4: Identidad y networking

Configurar Azure AD como IdP central (o el IdP que ya uses)
Establecer federacion SAML/OIDC con AWS y GCP
Desplegar VPN site-to-site entre los proveedores necesarios
Implementar Workload Identity Federation para machine-to-machine

Mes 5-6: CI/CD y IaC

Estandarizar Terraform con Terragrunt
Configurar pipeline de CI centralizado
Establecer registros de artefactos accesibles desde todos los proveedores
Desplegar gestion de secretos centralizada

Mes 7-8: Observabilidad y FinOps

Desplegar stack de observabilidad unificado (Grafana + Prometheus + Loki + Tempo)
Configurar alertas consolidadas
Implementar dashboards de coste
Establecer proceso mensual de revision de costes

Mes 9-12: Migracion y optimizacion

Migrar cargas de trabajo segun prioridad
Right-sizing basado en datos reales
Committed use discounts para cargas estables
Iterar sobre la arquitectura basandose en metricas reales

El multi-cloud no es un destino

El multi-cloud no es un destino al que se llega. Es un estado que se gestiona continuamente. Los proveedores lanzan servicios nuevos, los precios cambian, las necesidades del negocio evolucionan. La arquitectura multi-cloud que es optima hoy no lo sera dentro de 18 meses.

Lo que permanece constante son los fundamentos: identidad federada, networking predecible, observabilidad unificada, costes visibles. Con esos pilares en su sitio, añadir o cambiar proveedores es una decision tactica, no una crisis estrategica.

Y si despues de evaluar todo esto decides que una sola nube es suficiente para tu caso, eso tambien es una decision perfectamente valida. El peor multi-cloud es el que se implementa por moda en lugar de por necesidad.

Para evaluar si multi-cloud tiene sentido en tu organizacion, podemos realizar un diagnostico tecnologico que mapee tus cargas de trabajo actuales y recomiende la arquitectura cloud optima. Tambien ofrecemos servicios de cloud y DevOps para implementar y gestionar entornos multi-cloud en produccion. Si tu desafio principal es la ingenieria de datos entre nubes, tenemos experiencia especifica en pipelines multi-cloud con BigQuery, Redshift y Synapse.

Multi-cloud en la practica: AWS + Azure + GCP en la misma empresa