Multi-Cloud en la Práctica: AWS + Azure + GCP

La pregunta equivocada y la correcta

“Cuál cloud es mejor?” es la pregunta que todo CTO formula y ninguna respuesta útil puede contestar. La pregunta correcta es: “Qué combinación de servicios cloud resuelve mis problemas concretos al menor coste operativo?” Y la respuesta, casi siempre, implica más 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 mayoría ya opera en multi-cloud sin saberlo: el CRM está 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 implementación multi-cloud, con números, herramientas concretas y las lecciones que hemos aprendido desplegando cargas de trabajo entre AWS, Azure y GCP para clientes en logística, legal y retail.

Cuándo usar cada nube (y por qué)

La decisión de dónde ejecutar cada carga de trabajo debería basarse en tres factores: capacidad diferencial del proveedor, coste total y afinidad con el ecosistema existente.

AWS: la navaja suiza

AWS tiene el catálogo más amplio: más de 200 servicios. Es la elección por defecto cuando no hay una razón fuerte para ir a otro sitio, y la mejor opción 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 producción a escala. El ecosistema de herramientas y documentación no tiene rival.
Data lakes: S3 + Glue + Athena + Lake Formation es el stack de data lake más 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 topologías complejas que en otros proveedores requieren workarounds.

Dónde AWS no brilla: developer experience en servicios de alto nivel (comparar SageMaker con Vertex AI), integración con el stack de Microsoft, y precio de egreso de datos (uno de los costes ocultos más dolorosos del multi-cloud).

Azure: el puente al enterprise

Azure es la elección natural cuando la organización ya vive en el ecosistema Microsoft. Pero tiene méritos propios:

Identidad: Azure Active Directory (ahora Entra ID) es el directorio de identidad más completo del mercado. Si necesitas SSO, MFA, Conditional Access y gestión 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 único 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 garantías de compliance, residencia de datos y SLA que las grandes empresas necesitan. La integración con Cognitive Services cubre visión, lenguaje y voz.
Bases de datos gestionadas: Cosmos DB ofrece multi-model y distribución global con consistencia configurable. SQL Database es el SQL Server gestionado más maduro del mercado.

Dónde Azure no brilla: la consola de administración (Azure Portal es notoriamente lenta y confusa), la documentación (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 según Synergy Research Q4 2024), pero sus servicios diferenciales son genuinamente superiores:

Data y analytics: BigQuery es, en nuestra experiencia, el data warehouse más potente y el más fácil de operar. No hay clusters que gestionar, escala automáticamente, 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 más maduro. Dado que Google creó Kubernetes, esto no sorprende. Autopilot mode elimina la gestión 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 más grandes del mundo) proporciona latencias consistentemente menores para tráfico inter-región. Premium Tier routing está incluido por defecto.
AI/ML: Vertex AI unifica el ciclo completo de ML. TPUs ofrecen rendimiento por dólar superior a GPUs para training de modelos grandes.

Dónde GCP no brilla: el ecosistema de partners y consultores es menor, el soporte enterprise ha mejorado pero sigue detrás de AWS y Azure, y la percepción (justificada o no) de que Google abandona productos genera dudas en decisores conservadores.

El patrón 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 está 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 presentación de estrategia. En la práctica, duplica costes, multiplica la complejidad operativa y rara vez funciona cuando se necesita (el failover entre clouds es más complejo de lo que parece). Solo se justifica para servicios absolutamente críticos donde el SLA de un solo proveedor no es suficiente.

Multi-cloud por política (inevitable en regulados): sectores como banca, salud o administración pública pueden exigir multi-cloud por regulación o por política de gestión de riesgo del proveedor. Aquí no hay elección. Hay que implementarlo bien.

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

Networking entre nubes

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

VPN site-to-site

La opción más sencilla. Un túnel IPsec entre la VPC de AWS y la VNet de Azure (o la VPC de GCP). Cada par de proveedores requiere su propia configuración.

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

Ancho de banda típico: 1.25 Gbps por túnel. Suficiente para la mayoría 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 múltiples túneles se convierte en un ejercicio de paciencia.

Interconexión dedicada

Para volumen alto y latencia baja, la interconexión física es la opción correcta:

AWS Direct Connect: conexión dedicada desde 50 Mbps a 100 Gbps
Azure ExpressRoute: conexión 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 interconexión común. Proveedores como Equinix, Megaport o PacketFabric operan fabrics de interconexión donde puedes conectar AWS, Azure y GCP en el mismo datacenter de colocación, con latencias sub-milisegundo entre proveedores. Megaport Cloud Router, por ejemplo, permite crear una topología mesh entre los tres proveedores con un único contrato.

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

Network mesh con service mesh

Para organizaciones con Kubernetes en múltiples 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 opción más elegante pero también la más compleja de operar. Solo la recomendamos para equipos con experiencia sólida en Kubernetes y service mesh.

Egreso de datos: el impuesto invisible

El coste más 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 (vía internet) / 0.02 $/GB (Direct Connect)
Azure	0.087 $/GB	0.087 $/GB (vía internet) / 0.02 $/GB (ExpressRoute)
GCP	0.12 $/GB (Premium)	0.12 $/GB (vía 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 interconexión dedicada, cae a 200 $/mes, pero hay que sumar el coste del circuito.

La lección práctica: 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.

Federación de identidad

Gestionar identidades separadas en cada proveedor es un infierno operativo y un riesgo de seguridad. La solución es federación: un único proveedor de identidad (IdP) que autentique usuarios en todas las nubes.

Azure AD como IdP central

La configuración más común (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 vía 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 estáticos.

Beneficios tangibles: un único punto de gestión 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 comunicación entre servicios (machine-to-machine), la federación de identidad de workload elimina la necesidad de secretos estáticos:

Un servicio en AWS que necesita acceder a BigQuery obtiene un token de GCP usando sus credenciales de AWS (vía STS y Workload Identity Federation)
Un pod en GKE que necesita acceder a S3 obtiene credenciales temporales de AWS vía Web Identity Federation
El resultado: cero secretos de larga duración, rotación automática, auditoría 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, inútil para visibilidad consolidada.

Multi-cloud: Apptio Cloudability, Flexera One, o la opción open-source Opencost (para entornos Kubernetes). Varían en una plataforma que agrega costes de los tres proveedores, normaliza categorías y permite alertas unificadas.

En nuestra experiencia, la herramienta importa menos que el proceso. Lo crítico 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.
Revisión mensual: 30 minutos revisando las 10 líneas de coste más altas de cada proveedor. El 80% de la optimización viene de corregir los 3-4 recursos más 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 (automáticos)

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

Un error común: reservar capacidad antes de haber optimizado. Primero right-size, luego reserva. Hemos visto empresas pagar reservas de instancias m5.4xlarge que deberían 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 (¿cuántos ingenieros dominan AWS y Azure y GCP?), las herramientas de IaC deben soportar múltiples proveedores, el testing se multiplica, y el debugging de problemas inter-cloud es significativamente más complejo.

Nuestro consejo: contabiliza 1.5-2x el coste de ingeniería cuando planifiques multi-cloud. Si el equipo es de 5 ingenieros gestionando una sola nube, necesitarás 7-8 para gestionar tres con el mismo nivel de calidad. O, más realista, aceptar que el nivel de profundidad en cada nube será menor.

CI/CD multi-cloud

El pipeline de CI/CD es donde la complejidad del multi-cloud se materializa diariamente. Cada despliegue toca potencialmente múltiples 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 única. El build, los tests y la generación de artefactos ocurren en un solo lugar. Los artefactos (container images, binarios, paquetes IaC) se publican en un registro común.

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 único container registry (ECR, Artifact Registry o un registry neutral como Harbor) que todos los clusters de todos los proveedores pueden acceder. Evita duplicar imágenes en registros de cada proveedor.

Terraform como lingua franca

La gestión de infraestructura multi-cloud es más eficaz cuando se combina con prácticas de infraestructura como código. Terraform es la herramienta de IaC que mejor soporta multi-cloud, y en la práctica es donde la mayoría 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 configuración DRY entre entornos y proveedores. El estado de Terraform se almacena en un backend remoto (S3, GCS o Terraform Cloud) con locking.

Un consejo práctico: no intentes crear abstracciones que unifiquen los tres proveedores. Un módulo “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 unificación ocurre en el pipeline y en la estructura del repositorio, no en el código de infraestructura.

Gestión de secretos

Los secretos (API keys, certificados, contraseñas) necesitan un único punto de gestión:

HashiCorp Vault es la opción más completa: almacena secretos, genera credenciales dinámicas para cada proveedor, rota automáticamente, y audita todo acceso. La complejidad de operarlo se justifica en entornos multi-cloud serios.

Alternativa pragmática: 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 más fácil 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

Métricas: Grafana Cloud con Prometheus remoto o Grafana Mimir como backend. Los agentes de OpenTelemetry o Prometheus en cada proveedor exportan métricas a un único Mimir. Dashboards unificados en Grafana que muestran el estado de servicios independientemente de dónde corren.

Logs: Grafana Loki como almacén centralizado. Cada proveedor tiene un agente (Promtail, Fluentd o el OTel collector) que envía 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 críticas en multi-cloud, porque una petición puede cruzar dos o tres proveedores.

Alertas: Grafana Alerting con rutas a PagerDuty u OpsGenie. Una única política de alertas para toda la infraestructura.

Métricas de coste como métricas de observabilidad

Un patrón que funciona muy bien: tratar el coste como una métrica más 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 métricas técnicas. Cuando el equipo ve que un servicio cuesta 400 $/día en un panel que también muestra que procesa 200 peticiones/minuto, el coste por petición 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 logística, diseñamos un pipeline donde los datos de tracking (AWS) alimentaban un modelo de predicción (GCP Vertex AI) en tiempo real. El coste de egreso era 3x lo estimado. La solución fue cambiar a batch processing nocturno: los datos se exportan una vez al día a GCS y el modelo se reentrena con datos de las últimas 24 horas. La latencia de predicción aumentó de minutos a horas, pero el coste cayó 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 federación de identidad, los permisos estaban mal mapeados durante dos semanas. Ahora documentamos el mapeo de roles explícitamente antes de implementar.

Demasiada abstracción demasiado pronto. Intentamos crear un framework interno que abstrajera las diferencias entre proveedores. Seis meses después, el framework era el mayor generador de bugs del proyecto. Ahora aceptamos las diferencias y las gestionamos con convenciones claras en lugar de abstracciones mágicas.

Plan de acción: de la teoría a la implementación

Para la organización que está considerando multi-cloud deliberado, este es el orden que recomendamos:

Mes 1-2: Inventario y decisión

Mapear todas las cargas de trabajo existentes (incluyendo SaaS)
Identificar candidatos para cada proveedor basándose 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 federación 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 gestión 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 revisión de costes

Mes 9-12: Migración y optimización

Migrar cargas de trabajo según prioridad
Right-sizing basado en datos reales
Committed use discounts para cargas estables
Iterar sobre la arquitectura basándose en métricas 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 óptima hoy no lo será 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 decisión táctica, no una crisis estratégica.

Y si después de evaluar todo esto decides que una sola nube es suficiente para tu caso, eso también es una decisión perfectamente válida. 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 organización, podemos realizar un diagnóstico tecnológico que mapee tus cargas de trabajo actuales y recomiende la arquitectura cloud óptima. También ofrecemos servicios de cloud y DevOps para implementar y gestionar entornos multi-cloud en producción. Si tu desafío principal es la ingeniería de datos entre nubes, tenemos experiencia específica en pipelines multi-cloud con BigQuery, Redshift y Synapse.

Multi-cloud en la práctica: AWS + Azure + GCP en la misma empresa