Arquiteturas monolíticas multirregionais dependem inerentemente de planos de controle globais específicos de cada fornecedor. Quando uma degradação catastrófica atinge um serviço de identidade ou uma infraestrutura de rede subjacente em um único provedor de nuvem, todas as partições regionais falham simultaneamente. Depender exclusivamente da Amazon Web Services (AWS) ou do Microsoft Azure limita a disponibilidade teórica máxima de uma plataforma à integridade operacional desse único fornecedor. A implementação de uma arquitetura celular multicloud federada resolve esse risco existencial. Ao orquestrar partições isoladas do Kubernetes no Amazon EKS e no Azure AKS utilizando uma malha de serviços entre nuvens, as equipes de engenharia constroem uma matriz de roteamento que sobrevive a interrupções globais de fornecedores. Essa topologia isola domínios de falha no nível do hipervisor, aproveitando o roteamento BGP dinâmico e o TLS mútuo baseado em proxy para estabelecer uma infraestrutura resiliente e independente de fornecedores. Isso garante a continuidade da execução para cargas de trabalho de alto desempenho quando as zonas de disponibilidade de uma única nuvem desaparecem.

Pré-requisitos

A implantação de uma malha multicloud federada exige profundo conhecimento em redes avançadas e orquestração de contêineres. A infraestrutura requer o Terraform versão 1.7.0 ou superior, inicializado com a hashicorp/awsversão 5.40.0 e a hashicorp/azurermversão 3.90.0 do provedor. Para automatizar a injeção do plano de identidade, é necessário o Python 3.12, juntamente com o kubernetescliente Python versão 29.0.0. A arquitetura depende do Istio versão 1.21.0 ou superior, configurado para implantações com múltiplas redes e servidores primários. É obrigatório o acesso administrativo para provisionar AWS Transit Gateways, Azure Virtual Network Gateways e Números de Sistema Autônomo (ASNs) BGP.

Implementação passo a passo

Estabelecendo a espinha dorsal BGP entre nuvens

Construímos a ponte de rede física entre os provedores de nuvem provisionando uma VPN IPsec Site-to-Site que conecta um AWS Transit Gateway diretamente a um Azure Virtual Network Gateway. A justificativa arquitetônica para essa rede sobreposta é o determinismo absoluto de roteamento. Depender do roteamento público da internet para comunicação celular entre nuvens introduz uma variação de latência inaceitável e expõe a telemetria interna à interceptação externa. Um túnel IPsec dedicado, protegido por chaves pré-compartilhadas, garante a entrega de pacotes criptografados e previsíveis. Ao habilitar o roteamento BGP dinâmico sobre essa conexão, a rede torna-se auto-recuperável. Se uma Zona de Disponibilidade da AWS sofrer uma partição total da rede, o daemon BGP retira automaticamente as rotas comprometidas. As células do Azure AKS reconhecem instantaneamente a mudança de topologia e redirecionam o tráfego para as sub-redes da AWS sobreviventes sem intervenção manual do operador.

resource "aws_customer_gateway" "azure_gateway" {
  bgp_asn    = 65515
  ip_address = azurerm_public_ip.azure_vpn_ip.ip_address
  type       = "ipsec.1"
  tags = {
    Name = "Azure-AKS-Boundary"
  }
}

resource "aws_vpn_connection" "multicloud_mesh_vpn" {
  customer_gateway_id = aws_customer_gateway.azure_gateway.id
  transit_gateway_id  = aws_ec2_transit_gateway.mesh_tgw.id
  type                = aws_customer_gateway.azure_gateway.type
  static_routes_only  = false

  tunnel1_preshared_key = var.high_entropy_ipsec_key
  tunnel2_preshared_key = var.high_entropy_ipsec_key
}

resource "azurerm_local_network_gateway" "aws_tgw_local" {
  name                = "aws-tgw-boundary"
  resource_group_name = azurerm_resource_group.multicloud.name
  location            = azurerm_resource_group.multicloud.location
  gateway_address     = aws_vpn_connection.multicloud_mesh_vpn.tunnel1_address

  bgp_settings {
    asn                 = 64512
    bgp_peering_address = aws_vpn_connection.multicloud_mesh_vpn.tunnel1_cgw_inside_address
  }
}

Como podemos estabelecer confiança criptográfica entre microsserviços que operam no AWS EKS e no Azure AKS quando cada fornecedor utiliza autoridades de certificação mutuamente exclusivas para suas identidades gerenciadas internamente?

Identidade Federada via Autoridade Certificadora Raiz Unificada

Estabelecemos confiança criptográfica abstraindo completamente o plano de identidade dos fornecedores de nuvem, implementando uma malha de serviço Istio com múltiplas primárias, ancorada por uma Autoridade de Certificação (CA) raiz unificada e offline. A necessidade arquitetônica absoluta aqui é desacoplar a autenticação de confiança zero do IAM e do Azure AD. Uma função do AWS IAM não pode autenticar nativamente em uma identidade de carga de trabalho do Azure. Ao provisionar uma CA raiz compartilhada, geramos certificados intermediários especificamente para os planos de controle do Istio que operam tanto no EKS quanto no AKS. Quando o proxy sidecar do Envoy no AWS EKS inicia uma conexão com o proxy do Envoy no Azure AKS, ambos os proxies apresentam certificados TLS assinados por seus respectivos intermediários. Como ambos os intermediários se conectam à mesma CA raiz offline, os proxies validam com sucesso o handshake TLS mútuo (mTLS). Isso isola estritamente a execução do domínio dos silos de identidade específicos do fornecedor.

import base64
import os
from kubernetes import client, config
from kubernetes.client.rest import ApiException

def inject_intermediate_ca(cluster_context: str, cert_path: str, key_path: str, root_cert_path: str) -> None:
    config.load_kube_config(context=cluster_context)
    v1 = client.CoreV1Api()

    with open(cert_path, 'rb') as cert_file, open(key_path, 'rb') as key_file, open(root_cert_path, 'rb') as root_file:
        cert_data = base64.b64encode(cert_file.read()).decode('utf-8')
        key_data = base64.b64encode(key_file.read()).decode('utf-8')
        root_data = base64.b64encode(root_file.read()).decode('utf-8')

    secret_manifest = client.V1Secret(
        metadata=client.V1ObjectMeta(
            name="cacerts",
            namespace="istio-system"
        ),
        type="Opaque",
        data={
            "ca-cert.pem": cert_data,
            "ca-key.pem": key_data,
            "root-cert.pem": root_data,
            "cert-chain.pem": cert_data
        }
    )

    try:
        v1.create_namespaced_secret(namespace="istio-system", body=secret_manifest)
        print(f"Successfully injected intermediate CA into {cluster_context}")
    except ApiException as e:
        if e.status == 409:
            v1.replace_namespaced_secret(name="cacerts", namespace="istio-system", body=secret_manifest)
            print(f"Updated existing intermediate CA in {cluster_context}")
        else:
            raise RuntimeError(f"Failed to inject CA: {e.reason}")

if __name__ == "__main__":
    inject_intermediate_ca("aws-eks-admin", "certs/aws-ca-cert.pem", "certs/aws-ca-key.pem", "certs/root-cert.pem")
    inject_intermediate_ca("azure-aks-admin", "certs/azure-ca-cert.pem", "certs/azure-ca-key.pem", "certs/root-cert.pem")

Quando uma célula do EKS sofre com a falta de recursos da CPU e começa a descartar solicitações, como o service mesh redireciona automaticamente a carga útil da solicitação ativa para uma célula do AKS em bom funcionamento, sem exibir o erro HTTP 503 para o usuário final?

Balanceamento de carga local e fallback entre nuvens

A malha redireciona autonomamente as solicitações com falha utilizando balanceamento de carga por localidade do Istio, combinado com disjuntores de detecção de outliers. A arquitetura celular exige que o tráfego de rede permaneça dentro de sua célula de origem para minimizar o raio de impacto e reduzir os custos de transferência de dados de saída entre redes. No entanto, quando a célula primária do AWS EKS apresenta degradação, a malha deve atuar como um mecanismo de failover altamente responsivo. Configuramos uma localidade DestinationRuleque define a implantação do Azure AKS como uma localidade de failover secundária. Simultaneamente, configuramos a detecção de outliers para verificar erros HTTP 5xx consecutivos. Se um pod da AWS começar a falhar, o proxy Envoy local remove esse pod específico do pool de balanceamento de carga. Se toda a localidade do EKS esgotar seus endpoints íntegros, o Envoy redireciona de forma transparente a carga HTTP pendente pela rede backbone BGP IPsec para a localidade íntegra do Azure AKS. O aplicativo cliente experimenta um pequeno aumento de latência, mas recebe uma resposta HTTP 200 bem-sucedida, mascarando completamente a falha da infraestrutura da AWS.

resource "kubernetes_manifest" "multicloud_failover_policy" {
  manifest = {
    "apiVersion" = "networking.istio.io/v1beta1"
    "kind"       = "DestinationRule"
    "metadata" = {
      "name"      = "transaction-service-routing"
      "namespace" = "enterprise-core"
    }
    "spec" = {
      "host" = "transaction-service.enterprise-core.svc.cluster.local"
      "trafficPolicy" = {
        "outlierDetection" = {
          "consecutive5xxErrors" = 3
          "interval"             = "10s"
          "baseEjectionTime"     = "30s"
          "maxEjectionPercent"   = 100
        }
        "loadBalancer" = {
          "localityLbSetting" = {
            "enabled" = true
            "failover" = [
              {
                "from" = "us-east-1"
                "to"   = "eastus"
              }
            ]
          }
        }
      }
    }
  }
}

Quando o failover automatizado mascara com sucesso um redirecionamento entre nuvens, como os operadores de plataforma identificam a degradação silenciosa da rede primária da AWS antes que a partição de fallback do Azure atinja a capacidade máxima?

Solução de problemas comuns

Os operadores de plataforma identificam a degradação silenciosa monitorando anomalias específicas na telemetria do proxy, embora configurações incorretas frequentemente mascarem esses sinais. Ao estabelecer a infraestrutura BGP entre nuvens, o estado da VPN Site-to-Site da AWS pode permanecer em Activeestado inicial em vez de transitar para o estado final Established. Isso indica especificamente uma falha na negociação da proposta IKE fase 1 ou fase 2. Verifique se os algoritmos de criptografia e os grupos Diffie-Hellman configurados no AWS Transit Gateway correspondem exatamente à política IPsec personalizada aplicada ao Azure Virtual Network Gateway.

Se a infraestrutura BGP estiver íntegra, mas as requisições entre nuvens retornarem HTTP 503 Service Unavailablecom o URXsinalizador “(Upstream Retry Limit Exceeded)” nos logs do proxy Istio, o handshake mTLS está falhando. Isso ocorre frequentemente quando os certificados de CA intermediários injetados no istio-systemnamespace expiram ou quando os IDs SPIFFE das cargas de trabalho não correspondem ao domínio de confiança esperado. Inspecione os logs do sidecar Envoy TLS error: Secret is not supplied by SDSe verifique se o cacertssegredo foi lido corretamente pelo plano de controle do Istiod durante a inicialização do pod.

Conclusão

A federação de clusters Kubernetes na AWS e no Azure utilizando uma malha de serviços Istio proporciona um ambiente de execução impenetrável. Ao interligar o EKS e o AKS com uma rede BGP dinâmica e impor a identidade por meio de uma Autoridade Certificadora Raiz independente de fornecedor, as arquiteturas podem sobreviver perfeitamente à perda total do plano de controle regional de um provedor de nuvem. Organizações que adotam esse modelo celular avançado devem implementar metodologias GitOps utilizando ferramentas como o ArgoCD. Isso garante que os estados de implantação dos aplicativos sejam sincronizados instantaneamente em toda a matriz multicloud, evitando que a deriva de configuração comprometa os caminhos de fallback do Azure durante eventos críticos de failover.