Olha só o que a gente fazia até ontem
Se você já tentou ligar uma VNet do Azure com uma VPC da AWS de forma privada, sabe o perrengue. ExpressRoute de um lado, Direct Connect do outro, um cage na Equinix no meio, sessões BGP que ninguém do time entende direito, dois NOCs diferentes para coordenar mudança. É o famoso imposto multicloud: você paga em banda, mas paga muito mais em dor de cabeça operacional.
Agora a Microsoft e a AWS resolveram sentar na mesa e padronizar isso. O Azure Multicloud Interconnect (lançado junto com o AWS Interconnect-multicloud) usa uma spec Open API comum aos dois provedores. Traduzindo: você provisiona a conexão privada de forma programática, sem montar o Frankenstein de roteamento na mão.
O Robert Kennedy, VP de Network Services da AWS, foi direto: o jeito antigo era "clunky" (desengonçado). O novo modelo entrega MACsec ligado por padrão, SLA de 99,99% (quatro noves) e até 100 Gbps por interconnect já no GA.
Isso não é rebranding de ExpressRoute, não. É um contrato operacional diferente entre duas hyperscalers.
Para quem monta pipeline de treino de IA que atravessa nuvens (dados no Azure Data Lake, GPUs na AWS, ou o contrário), é a primeira vez que a camada de rede para de ser o gargalo do diagrama.
O que muda de verdade na sua arquitetura
Antes, um caminho privado Azure↔AWS era mais ou menos assim:
[VNet Azure] -- [ExpressRoute Gateway] -- [MSEE] -- [NNI da operadora] -- [Equinix Fabric] -- [DX Location AWS] -- [DX Gateway] -- [VPC AWS]
Cada salto é um ticket, uma janela de mudança e um fornecedor para gerenciar. Com o Multicloud Interconnect, o modelo mental encolhe:
[VNet Azure] -- [Azure Multicloud Interconnect] == [AWS Interconnect-multicloud] -- [VPC AWS]
Propriedades técnicas principais
| Propriedade | Valor |
|---|---|
| Banda máxima no GA | 100 Gbps por interconnect |
| Criptografia | MACsec, ligado por padrão |
| SLA de disponibilidade | 99,99% (quatro noves) |
| Provisionamento | Spec Open API nos dois lados |
| Integração Azure | Nativa com Azure Private Link |
| Escala | Expansão dinâmica sem redesenho |
A integração com Azure Private Link é o recurso mais subestimado. Na prática, um consumidor na AWS consegue acessar um serviço PaaS do Azure (Storage, SQL, Key Vault) via private endpoint sem expor IP público e sem ter que montar uma hub VNet só para intermediar. Isso reduz muito o raio de explosão em revisão de segurança.
Um esboço de Terraform (conceitual)
# Lado Azure: provisiona o endpoint do interconnect
resource "azurerm_multicloud_interconnect" "para_aws" {
name = "mci-para-aws-prod"
resource_group_name = azurerm_resource_group.net.name
location = "brazilsouth"
bandwidth_gbps = 100
peer_provider = "AWS"
# MACsec já vem ligado; não desligue em produção
}
# Lado AWS: espelha o recurso via Open API
resource "aws_interconnect_multicloud" "para_azure" {
name = "mci-para-azure-prod"
bandwidth_gbps = 100
peer_provider = "AZURE"
peer_id = azurerm_multicloud_interconnect.para_aws.id
}
Os nomes de recurso acima são ilustrativos — confira a doc atual do provider, porque isso é feature de dia de GA e a nomenclatura ainda está assentando.
O ponto arquitetural importante: você tem um control plane por nuvem, não um control plane unificado. Não existe dashboard único. Existe um contrato comum. Essa distinção é ouro na hora de escrever runbook.
Se você curte esse padrão de "padroniza a interface, mantém o interno separado", vale dar uma olhada em como isso aparece em retrieval unificado com SilverTorch. Mesma filosofia, camada diferente da stack.
Os limites que o anúncio não conta
Antes de sair cortando seus circuitos de ExpressRoute, seja honesto sobre o que isso não resolve.
1. Continuam sendo duas nuvens. Você ganha um cano rápido, não um IAM unificado. Entra ID e IAM continuam universos separados. Federação de identidade cross-cloud ainda é problema seu.
2. Custo de egress não muda. Egress da AWS para Azure continua sendo tarifado. O interconnect simplifica o caminho, não a conta. Para workload de treino de IA que move terabytes por dia, faz a matemática antes de assinar.
3. Pareamento por região no lançamento. O GA fala em conexão ponto-a-ponto. Se você precisa de mesh em três regiões e duas nuvens, vai compor vários interconnects e voltou a desenhar topologia na mão.
4. Open API ≠ open source. A spec é publicada, mas a implementação é proprietária nos dois lados. "Open" aqui significa "interoperável", não "inspecionável".
5. Lock-in muda de lugar, não desaparece. Você agora aposta que o roadmap de interoperabilidade Microsoft-AWS vai continuar alinhado. Se um lado despriorizar a spec, você fica com um circuito tecnicamente no ar, mas estrategicamente órfão.
Quando faz sentido
- Você tem pipeline de IA ou dados genuinamente cross-cloud com tráfego alto e constante.
- Seu time de segurança bloqueava multicloud por causa de endpoint público.
- Você já está comprometido com as duas hyperscalers por 3+ anos.
Quando esperar
- Tráfego cross-cloud é esporádico e baixo (usa endpoint público + Private Link, sai mais barato).
- Você ainda está decidindo qual nuvem vence para seu workload principal.
- Precisa de mesh multi-região desde o dia zero.
Para ver como esse tipo de arquitetura "uma interface, várias implementações" evolui em produção, o breakdown da arquitetura de retrieval do SilverTorch é um paralelo útil — os mesmos trade-offs entre abstração e controle aparecem lá.
O que fazer na prática agora
Se você é Azure-first com pegada crescendo na AWS (ou o contrário), a sequência pragmática é:
- Inventaria seu tráfego cross-cloud. Se for menos de algumas centenas de GB/mês, isso é overkill. Se for TB/dia, continua lendo.
- Prototipa um interconnect entre uma subscription Azure non-prod e uma conta AWS non-prod. Valida o fluxo de provisionamento via Open API de ponta a ponta antes de confiar.
- Testa a integração com Private Link especificamente. É o recurso que mais muda sua postura de segurança e o que mais tende a ter arestas no GA.
- Modela custo de egress por 12 meses no seu crescimento projetado. O interconnect não muda o medidor.
- Escreve o runbook de "e se a AWS despriorizar isso". Tenha fallback de ExpressRoute documentado, mesmo que nunca use.
Para ir mais fundo
- O texto oficial da Microsoft sobre o lançamento: Introducing Azure Multicloud Interconnect for AWS — fonte primária deste artigo.
- Módulo do Microsoft Learn para provisionamento hands-on.
- Anúncio paralelo da AWS sobre o Interconnect-multicloud.
A história maior aqui não é o número de 100 Gbps. É que duas hyperscalers concordaram numa spec de API compartilhada para uma primitiva de rede. Se esse padrão pegar — e a Microsoft está sinalizando claramente que quer estender para operadoras e redes metro — os próximos cinco anos de arquitetura multicloud vão parecer estruturalmente diferentes dos últimos cinco. Vale acompanhar, vale prototipar, mas não vale apostar toda a estratégia de rede no mês um.