¡Hola Devs! Vamos a hablar del impuesto multicloud
Si alguna vez intentaste conectar una VNet de Azure con una VPC de AWS de forma privada, ya sabes el calvario. ExpressRoute de un lado, Direct Connect del otro, un cage en Equinix en medio, sesiones BGP que nadie del equipo entiende, dos NOCs distintos para coordinar cambios. Ese es el impuesto multicloud: pagas en ancho de banda, pero pagas mucho más en dolor operativo.
Ahora Microsoft y AWS se sentaron a estandarizar esto. Azure Multicloud Interconnect (lanzado junto con AWS Interconnect-multicloud) usa una spec Open API común a los dos proveedores. Traducción: provisionas la conexión privada de forma programática, sin armar el Frankenstein de ruteo a mano.
Robert Kennedy, VP de Network Services de AWS, fue directo: el método viejo era "clunky" (torpe). El nuevo modelo trae MACsec activado por default, SLA de 99.99% (cuatro nueves) y hasta 100 Gbps por interconnect ya en GA.
Ojo: esto no es un rebranding de ExpressRoute. Es un contrato operativo distinto entre dos hyperscalers.
Para quien arma pipelines de entrenamiento de IA que cruzan nubes (datos en Azure Data Lake, GPUs en AWS, o al revés), es la primera vez que la capa de red deja de ser el cuello de botella del diagrama.
Qué cambia de verdad en tu arquitectura
Antes, un camino privado Azure↔AWS se veía más o menos así:
[VNet Azure] -- [ExpressRoute Gateway] -- [MSEE] -- [NNI del carrier] -- [Equinix Fabric] -- [DX Location AWS] -- [DX Gateway] -- [VPC AWS]
Cada salto es un ticket, una ventana de cambio y un proveedor que gestionar. Con Multicloud Interconnect, el modelo mental se encoge:
[VNet Azure] -- [Azure Multicloud Interconnect] == [AWS Interconnect-multicloud] -- [VPC AWS]
Propiedades técnicas clave
| Propiedad | Valor |
|---|---|
| Ancho de banda máximo en GA | 100 Gbps por interconnect |
| Cifrado | MACsec, activado por default |
| SLA de disponibilidad | 99.99% (cuatro nueves) |
| Aprovisionamiento | Spec Open API en ambos lados |
| Integración Azure | Nativa con Azure Private Link |
| Escalado | Expansión dinámica sin rediseño |
La integración con Azure Private Link es la joya escondida. En la práctica, un consumidor del lado AWS puede llegar a un servicio PaaS de Azure (Storage, SQL, Key Vault) vía private endpoint sin exponer IP pública y sin tener que armar una hub VNet solo para intermediar. Eso reduce muchísimo el blast radius en revisiones de seguridad.
Un esbozo de Terraform (conceptual)
# Lado Azure: provisiona el endpoint del interconnect
resource "azurerm_multicloud_interconnect" "hacia_aws" {
name = "mci-hacia-aws-prod"
resource_group_name = azurerm_resource_group.net.name
location = "mexicocentral"
bandwidth_gbps = 100
peer_provider = "AWS"
# MACsec ya viene activado; no lo desactives en prod
}
# Lado AWS: espeja el recurso vía Open API
resource "aws_interconnect_multicloud" "hacia_azure" {
name = "mci-hacia-azure-prod"
bandwidth_gbps = 100
peer_provider = "AZURE"
peer_id = azurerm_multicloud_interconnect.hacia_aws.id
}
Los nombres de recurso de arriba son ilustrativos — checa la doc actual del provider, porque esto es feature de día de GA y la nomenclatura todavía se está asentando.
El punto arquitectónico importante: tienes un control plane por nube, no un control plane unificado. No hay dashboard único. Hay un contrato común. Esa distinción vale oro cuando escribes runbooks.
Si te late este patrón de "estandariza la interfaz, mantén lo interno separado", checa cómo aparece en retrieval unificado con SilverTorch. Misma filosofía, capa distinta del stack.
Los límites que el anuncio no te cuenta
Antes de salir cortando tus circuitos de ExpressRoute, sé honesto sobre lo que esto no resuelve.
1. Siguen siendo dos nubes. Ganas un tubo rápido, no un IAM unificado. Entra ID e IAM siguen siendo universos separados. La federación de identidad cross-cloud sigue siendo tu problema.
2. El costo de egress no cambia. Egress de AWS hacia Azure sigue siendo tarifado. El interconnect simplifica el camino, no la cuenta. Para workloads de entrenamiento de IA que mueven terabytes al día, haz las cuentas antes de firmar.
3. Pareo por región en el lanzamiento. El GA habla de conexión punto-a-punto. Si necesitas mesh en tres regiones y dos nubes, vas a componer varios interconnects y regresaste a diseñar topología a mano.
4. Open API ≠ open source. La spec se publica, pero la implementación es propietaria en ambos lados. "Open" aquí significa "interoperable", no "inspeccionable".
5. El lock-in se mueve, no desaparece. Ahora apuestas a que el roadmap de interoperabilidad Microsoft-AWS va a seguir alineado. Si un lado desprioriza la spec, te quedas con un circuito técnicamente arriba pero estratégicamente huérfano.
Cuándo sí conviene
- Tienes un pipeline de IA o datos genuinamente cross-cloud con tráfico alto y constante.
- Tu equipo de seguridad bloqueaba multicloud por exposición de endpoint público.
- Ya estás comprometido con las dos hyperscalers por 3+ años.
Cuándo esperar
- Tu tráfico cross-cloud es esporádico y bajo (usa endpoint público + Private Link, sale más barato).
- Todavía estás decidiendo qué nube gana para tu workload principal.
- Necesitas mesh multi-región desde el día uno.
Para ver cómo este tipo de arquitectura "una interfaz, muchas implementaciones" evoluciona en producción, el breakdown de la arquitectura de retrieval de SilverTorch es un paralelo útil — los mismos trade-offs entre abstracción y control aparecen ahí.
Qué hacer en la práctica ahora
Si eres Azure-first con presencia creciendo en AWS (o al revés), la secuencia pragmática es:
- Inventaria tu tráfico cross-cloud. Si es menos de unos cientos de GB/mes, esto es overkill. Si es TB/día, sigue leyendo.
- Prototipa un interconnect entre una subscription Azure non-prod y una cuenta AWS non-prod. Valida el flujo de aprovisionamiento vía Open API de punta a punta antes de confiar.
- Prueba la integración con Private Link específicamente. Es la feature que más cambia tu postura de seguridad y la que más tiende a tener aristas en GA.
- Modela el costo de egress a 12 meses con tu crecimiento proyectado. El interconnect no cambia el medidor.
- Escribe el runbook de "qué pasa si AWS desprioriza esto". Ten fallback de ExpressRoute documentado, aunque nunca lo uses.
Para ir más a fondo
- El texto oficial de Microsoft sobre el lanzamiento: Introducing Azure Multicloud Interconnect for AWS — fuente primaria de este artículo.
- Módulo de Microsoft Learn para aprovisionamiento hands-on.
- Anuncio paralelo de AWS sobre el Interconnect-multicloud.
La historia grande aquí no es el número de 100 Gbps. Es que dos hyperscalers acordaron una spec de API compartida para una primitiva de red. Si ese patrón pega — y Microsoft está señalando claramente que quiere extenderlo a carriers y redes metro — los próximos cinco años de arquitectura multicloud van a verse estructuralmente distintos a los últimos cinco. Vale la pena seguirlo, vale la pena prototiparlo, pero no vale la pena apostar toda tu estrategia de red en el mes uno.