Conectividade entre regiões e multinuvem

Este artigo ajuda você a conectar cargas de trabalho Azure em várias regiões e estender a conectividade a outros provedores de nuvem, como o Amazon Web Services (AWS) e o Google Cloud.

O que este artigo aborda

Este artigo aborda as decisões de design para conectar Azure redes virtuais (VNets) entre regiões e estabelecer caminhos de rede para cargas de trabalho em execução em outras nuvens. Você aprenderá quando usar o Peering de VNet Global, o WAN Virtual, o ExpressRoute Global Reach, a VPN de site a site e o Servidor de Rota do Azure em cenários entre regiões e multinuvem.

Quem precisa deste artigo

Leia este artigo se uma ou mais dessas condições se aplicarem:

  • Sua arquitetura abrange várias regiões Azure e precisa de conectividade privada entre elas.
  • Você precisa conectar as cargas de trabalho do Azure à AWS, ao Google Cloud ou a outra rede externa.
  • Você precisa comparar o Emparelhamento de Rede Virtual Global (VNet), a WAN Virtual, o Alcance Global do ExpressRoute, a VPN site a site ou o Servidor de Rotas do Azure.
  • Você precisa projetar conectividade resiliente para recuperação de desastre, expansão global ou operações multinuvem.

Tip

Seguindo um cenário específico? Selecione seu cenário na parte superior da página para obter diretrizes personalizadas. As diretrizes principais a seguir se aplicam a todos os leitores.

Foco em migração direta: inclua este artigo em sua lista de leitura somente se sua migração abranger várias regiões do Azure ou se conectar a outra nuvem. A maioria dos projetos lift-and-shift começa com uma única região e adiciona conectividade entre regiões mais tarde, quando a recuperação de desastre ou expansão geográfica se torna uma prioridade.

Foco da modernização: Inclua este artigo se sua modernização exigir conectividade privada explícita entre regiões além do que o artigo sobre múltiplas regiões cobre. Você precisa deste guia quando os nós em diferentes regiões exigem caminhos de comunicação diretos ou quando sua implantação ativa-ativa precisa de emparelhamento privado entre hubs regionais.

Foco em nuvem cruzada: este artigo é fundamental para sua decisão de design. Leia-o antes de escolher entre hub-spoke e WAN Virtual para sua arquitetura de trânsito entre nuvens. Use este artigo para descobrir sua topologia multinuvem existente, mapear serviços entre a AWS ou o Google Cloud e Azure e definir como Azure se conecta a cargas de trabalho que permanecem em outras nuvens durante a migração.

Azure serviços e recursos

Azure fornece vários serviços para conectividade entre regiões e multinuvem. Cada serviço aborda diferentes requisitos de escala, largura de banda e gerenciamento.

Service O que ele fornece Quando usar isso
Emparelhamento VNet global Conectividade privada de baixa latência entre VNets em diferentes regiões de Azure. O tráfego permanece na infraestrutura da Microsoft. A largura de banda é limitada apenas pela SKU da VM (máquina virtual), não por um gateway. Comunicação direta entre duas VNets em regiões diferentes sem um dispositivo de gateway.
WAN Virtual do Azure (nível Standard) hub de trânsito global gerenciado pela Microsoft que conecta VNets, filiais e usuários remotos em todas as regiões. Fornece roteamento transitivo entre todas as redes conectadas. Organizações com muitas regiões e filiais que precisam de conectividade ponto a ponto sem gerenciar conexões de emparelhamento individuais.
ExpressRoute via Cloud Exchange Conexão entre nuvens dedicada por meio de um provedor de troca de terceiros (como Equinix ou Megaport). Fornece conectividade privada de alta largura de banda com o AWS ou o Google Cloud. Arquiteturas multinuvem com requisitos de SLA de largura de banda em que o tráfego não deve atravessar a Internet pública.
VPN site a site para outras nuvens Túnel IPsec criptografado entre Gateway de VPN do Azure e o gateway de VPN de outro provedor de nuvem (Gateway Virtual Privado da AWS ou VPN do Google Cloud). Conectividade multinuvem para cenários de teste, desenvolvimento ou produção em que circuitos dedicados não são justificados.
Servidor de Rota do Azure Habilita a troca dinâmica de rotas BGP entre sua VNet e NVAs (dispositivos virtuais de rede). Injeta rotas aprendidas pela NVA na malha de roteamento do Azure SDN. Roteamento personalizado com NVAs de terceiros em uma VNet de hub, ou roteamento multinuvem complexo que requer propagação de BGP para redes conectadas ao Azure.

Como funciona o emparelhamento global de VNets

O emparelhamento VNet global cria um vínculo direto entre duas redes virtuais em regiões de Azure diferentes. O link trafega inteiramente pela rede de backbone da Microsoft e nunca passa pela internet pública. Depois de configurar uma relação de emparelhamento, os recursos em cada VNet poderão se comunicar usando endereços IP privados como se estivessem na mesma rede.

Ao contrário das abordagens baseadas em gateways, o emparelhamento não introduz um único ponto de estrangulamento. A largura de banda entre VNets emparelhadas escala com a SKU da VM em cada lado. Não há nenhum dispositivo de gateway dedicado limitando a taxa de transferência. Este design torna o emparelhamento VNet global a opção de menor latência para comunicação entre regiões com um pequeno número de VNets.

No entanto, o emparelhamento não é transitivo por design. Se a VNet A tiver emparelhamento com a VNet B, e a VNet B tiver emparelhamento com a VNet C, o tráfego da VNet A não poderá alcançar a VNet C por meio da VNet B. Cada par de VNets que precisa de comunicação direta requer seu próprio link de emparelhamento. Em um modelo hub-and-spoke, isso significa que você normalmente emparelha as VNets hub regionais entre si e usa rotas definidas pelo usuário (UDRs) ou NVAs para encaminhar o tráfego spoke-to-spoke entre regiões através dos hubs.

WAN Virtual trânsito global

O WAN Virtual do Azure (camada Standard) elimina a necessidade de configurar manualmente o emparelhamento entre hubs regionais. Quando você implanta WAN Virtual hubs em várias regiões, Microsoft estabelece automaticamente conexões hub a hub pelo backbone. As rotas aprendidas em um hub são propagadas para todos os outros hubs, criando uma malha de trânsito de qualquer ponto para qualquer outro ponto.

Esse roteamento automático significa que uma VNet spoke conectada a um hub no Leste dos EUA pode alcançar uma VNet spoke conectada a um hub na Europa Ocidental sem qualquer configuração adicional de emparelhamento ou tabela de roteamento. WAN Virtual também estende essa transitividade para filiais (conectadas por meio de VPN site a site ou ExpressRoute) e usuários remotos (conectados por meio de VPN ponto a site). O resultado é uma rede global em malha completa gerenciada pela Microsoft.

Para inspeção de tráfego entre regiões, habilite Routing Intent em hubs virtuais seguros. O Routing Intent força o tráfego entre hubs a passar pelo Firewall do Azure, proporcionando visibilidade centralizada e aplicação de políticas em todas as regiões, sem a necessidade de implantar e gerenciar NVAs individuais em cada hub.

Como escolher

Use as tabelas de decisão a seguir para selecionar a abordagem de conectividade certa para seu cenário.

Opções de conectividade entre regiões

Diagrama mostrando padrões de conectividade entre regiões, incluindo emparelhamento VNet global, trânsito hub-to-hub de WAN Virtual e caminhos VPN entre nuvens.

O seu cenário Abordagem recomendada Por que
Duas VNets em regiões diferentes precisam de comunicação direta Emparelhamento VNet global Latência mais baixa em relação aos caminhos da Internet, sem gargalo de gateway, simples de configurar. A largura de banda varia de acordo com a SKU da VM.
Muitas regiões, muitas filiais, necessidade de trânsito gerenciado WAN Virtual do Azure (nível Standard) Fornece roteamento transitivo de qualquer origem para qualquer destino entre todos os hubs conectados. Microsoft gerencia a infraestrutura de roteamento.
Conectar sites locais uns aos outros por meio de Azure Alcance Global do ExpressRoute Global Vincula dois circuitos do ExpressRoute para que o tráfego local percorra o backbone Microsoft. Não é necessário fazer conexões em loop através de VNets do Azure.
Roteamento personalizado ou NVAs de terceiros em um hub regional Servidor de Rota do Azure Permite o emparelhamento BGP dinâmico entre NVAs e o Azure. As rotas aprendidas pelo NVA são injetadas automaticamente nas VNets spoke.

Opções de conectividade multinuvem

O seu cenário Abordagem recomendada Por que
Alta largura de banda e SLA necessárias para o tráfego entre nuvens ExpressRoute via provedor de Exchange de nuvem Fornece capacidade dedicada com latência previsível. O provedor de troca conecta o circuito do ExpressRoute ao serviço de conexão direta da outra nuvem.
Cargas de trabalho com orçamento limitado, testes ou baixa taxa de transferência. VPN de site para site Usa a conectividade de Internet existente sem custos de circuito. Adequado quando os requisitos de largura de banda são modestos.
Híbrido e multinuvem (local, Azure e outra nuvem) Alcance Global do ExpressRoute + Exchange de Nuvem Combina o Global Reach para o tráfego entre o ambiente local e o Azure com uma interconexão em nuvem para conectividade entre o Azure e outras nuvens, criando um backbone privado unificado.

Considerações sobre o design

Para a maioria das migrações lift-and-shift, a conectividade entre regiões é uma consideração para expansão futura, em vez de um requisito inicial. Sua implantação inicial provavelmente tem como alvo uma única região Azure.

Quando você planeja uma expansão futura:

  • Emparelhamento Global de VNet: Use o Emparelhamento Global de VNet entre VNets de hub regionais ao adicionar uma segunda região do Azure. Essa abordagem oferece conectividade privada de baixa latência sem implantar um dispositivo de gateway. O tráfego permanece no backbone da Microsoft e escala de acordo com a SKU da sua VM.
  • Complexidade adiada: Evite implantar WAN Virtual ou o Alcance Global do ExpressRoute até que sua propriedade cresça além de duas regiões ou adicione requisitos de conectividade de ramificação.
  • Preparação para DR: Mesmo que a conectividade entre regiões não seja necessária hoje, documente quais cargas de trabalho exigem recuperação de desastre e planeje previamente a topologia de emparelhamento para que você possa implantá-la rapidamente quando necessário.

Sua arquitetura modernizada usa implantações ativo-ativo entre regiões. O emparelhamento entre regiões permite a comunicação direta spoke-to-spoke quando suas camadas de aplicativos abrangem limites regionais.

Principais decisões de design para modernização:

  • Emparelhamento entre regiões para ativo-ativo: emparelhe suas VNets hub de região primária e de backup para permitir o fluxo de tráfego bidirecional. As equipes de aplicativos nos spokes da ContosoBiz e da ContosoCare podem acessar recursos em qualquer região por meio do caminho de emparelhamento do hub.
  • Roteamento por meio de hubs: como o emparelhamento de VNet global não é transitivo, direcione o tráfego de spokes entre regiões por meio do hub regional NVA ou do Firewall do Azure. Use rotas definidas pelo usuário (UDRs) para direcionar o tráfego entre regiões de spoke para spoke por meio do firewall do hub para inspeção.
  • Emparelhamento seletivo: nem todos os spokes precisam de conectividade entre regiões. Estabeleça emparelhamento apenas com as VNets do hub e use a propagação de rotas para alcançar VNets de spoke específicos que participam de cargas de trabalho ativo-ativo.

Este artigo é onde você projeta sua arquitetura de conectividade multinuvem. Antes de planejar Azure infraestrutura, você deve descobrir sua topologia de nuvem existente e mapear serviços entre provedores.

Fluxo de trabalho de descoberta multinuvem

  1. Descubra sua topologia existente: Use a Descoberta de Carga de Trabalho no AWS e no Google Cloud Network Intelligence Center para mapear sua topologia, relações de emparelhamento e padrões de fluxo de tráfego da VPC (Nuvem Virtual Privada) atual.
  2. Identifique os fluxos de tráfego: Documente a comunicação entre VPCs, os caminhos de entrada da internet e de saída para a internet, e as conexões entre filiais e a nuvem no seu ambiente da AWS ou do Google Cloud.
  3. Mapeie os serviços para os equivalentes no Azure: Os principais mapeamentos para o design de conectividade são:
Serviço AWS/Google Cloud Equivalente do Azure
Transit Gateway WAN Virtual do Azure
VPC / Rede VPC Rede Virtual do Azure
Grupos de Segurança/Regras de Firewall Grupos de segurança de rede (NSG)

Para obter mapeamentos completos de serviços da AWS para o Azure e do Google Cloud para o Azure, consulte o checklist de descoberta entre nuvens.

Decisões de arquitetura de conectividade

Depois de concluir a descoberta e o mapeamento de serviço, decida:

  • Modelo de trânsito: Escolha WAN Virtual se você tiver várias VPCs, filiais, regiões ou bordas de nuvem. O WAN Virtual oferece o equivalente do Azure ao AWS Transit Gateway, com roteamento gerenciado de qualquer origem para qualquer destino.
  • VPN entre nuvens: implante conexões de Gateway de VPN do seu hub WAN Virtual (ou VNet do hub) para o AWS Virtual Private Gateway e o Google Cloud VPN. Use túneis IPsec para comunicação criptografada entre nuvens.
  • Aplicativos que permanecem: Identifique as cargas de trabalho que permanecem na AWS ou no Google Cloud durante a migração. Essas cargas de trabalho precisam de conectividade persistente por meio dos túneis VPN entre nuvens até que a migração seja concluída.

Pré-requisitos

Antes de implementar a conectividade entre regiões ou várias nuvens, confirme os seguintes requisitos:

  • Duas ou mais regiões Azure com VNets implantadas: suas cargas de trabalho já devem existir (ou ser planejadas) em várias regiões. Consulte o artigo sobre VNets e sub-redes para obter orientações sobre o planejamento de VNets.
  • Topologia hub-spoke ou WAN Virtual: Os designs entre regiões baseiam-se em uma topologia estabelecida em cada região. Consulte o artigo hub-spoke ou o artigo WAN Virtual.
  • Circuitos do ExpressRoute (para Alcance Global): Se você planeja conectar sites locais, precisará de circuitos existentes do ExpressRoute em cada local. Consulte o artigo de conectividade híbrida.
  • Acesso à conta entre nuvens: para conectividade VPN ou Exchange em várias nuvens, você precisa de acesso administrativo ao console de rede do outro provedor de nuvem para configurar o lado remoto da conexão.

Considerações de segurança

A conectividade entre regiões e multinuvem apresenta preocupações de segurança específicas que não existem em implantações de região única.

Inspeção de tráfego entre regiões

O emparelhamento de VNet global não é transitivo. O tráfego entre VNets emparelhadas flui diretamente sem passar por um firewall ou ponto de inspeção. Se você precisar inspecionar o tráfego entre regiões, encaminhe-o por meio de uma NVA (solução de virtualização de rede) ou Firewall do Azure em cada hub regional.

No WAN Virtual, habilite Routing Intent com políticas de tráfego privado em hubs virtuais seguros. A intenção de roteamento força o tráfego entre hubs por meio de firewalls gerenciados pelo Gerenciador de Firewall do Azure, que fornece inspeção centralizada de tráfego entre regiões. Essa configuração requer a camada standard WAN Virtual.

Criptografar conexões entre nuvens

Túneis VPN site a site para outras nuvens são criptografados por padrão (IPsec/IKE). No entanto, as conexões do ExpressRoute por meio de uma troca de nuvem são privadas, mas não criptografadas na camada de rede. Se você precisar de criptografia no ExpressRoute, implante o MACsec em circuitos do ExpressRoute Direct ou use a criptografia TLS da camada de aplicativo.

Para o tráfego entre nuvens que atravessa uma interconexão de nuvem sem sobreposição de VPN, considere implementar um túnel IPsec baseado em NVA no caminho do ExpressRoute. Essa abordagem adiciona criptografia sem abrir mão dos benefícios de largura de banda e latência de um circuito dedicado. Como alternativa, use o TLS mútuo (mTLS) na camada do aplicativo para que cada ponto de extremidade de serviço valide a identidade e criptografe os dados, independentemente do transporte subjacente. A escolha depende se você precisa de criptografia de camada de rede (todo o tráfego) ou pode impor a criptografia na camada do aplicativo.

Considerações de custo

Toda a conectividade entre regiões incorre em encargos de transferência de dados. O emparelhamento de VNet global, o tráfego entre hubs da WAN Virtual e os túneis entre regiões do Gateway de VPN usam preços baseados em saída. As taxas variam de acordo com o par de zonas:

  • Intracontinental (por exemplo, Leste dos EUA para Oeste dos EUA): taxa mais baixa por GB, normalmente no intervalo de preços de saída padrão para a região.
  • Intercontinental (por exemplo, Leste dos EUA até a Europa Ocidental): Tarifa mais alta por GB devido a maiores distâncias de backbone e à capacidade entre continentes.

A WAN Virtual adiciona uma taxa por unidade de conexão para cada VNet spoke ou filial conectada a um hub, além de uma taxa de processamento de dados para o tráfego que transita por um hub seguro executando o Firewall do Azure. Essa precificação em camadas significa que a WAN Virtual pode custar mais do que o emparelhamento de VNet Global simples para arquiteturas com apenas algumas regiões e poucos spokes, mas oferece melhor economia de escala quando dezenas de filiais e regiões se conectam.

Para conectividade multicloud, o ExpressRoute por meio de um ponto de troca na nuvem incorre em custos de porta e taxas de interconexão do provedor do ponto de troca, além dos custos de circuito do Azure ExpressRoute e dos custos de conexão direta da outra nuvem. Uma VPN de site a site evita custos de circuito, mas ainda gera cobranças padrão de saída para dados que saem do Azure.

Orientação: Coloque cargas de trabalho de alto tráfego na mesma região quando possível. Reserve caminhos entre regiões para sincronização do plano de controle, replicação assíncrona e failover de recuperação de desastres, que normalmente são fluxos de menor volume.

Padrões de recuperação de desastre

A conectividade entre regiões é fundamental para a recuperação de desastres (DR). O padrão escolhido determina o RTO (objetivo de tempo de recuperação) e o RPO (objetivo do ponto de recuperação).

Active-active

Ambas as regiões atendem ao tráfego de produção simultaneamente. Um balanceador de carga global (como Azure Front Door ou Gerenciador de Tráfego do Azure) distribui solicitações entre regiões. Se uma região falhar, o tráfego mudará para a região sobrevivente com interrupção mínima. Esse padrão fornece o RTO mais baixo (segundos a minutos), mas requer infraestrutura completa em ambas as regiões e sincronização bidirecional de dados, o que aumenta o custo e a complexidade.

Active-passive

Uma região atende ao tráfego de produção enquanto a segunda região permanece em espera com infraestrutura pré-implantada (mas potencialmente reduzida). A replicação mantém os dados da região passiva atuais. Em caso de falha, você promove a região passiva e redireciona o tráfego. O RTO depende da rapidez com que você escala os recursos passivos e conclui o failover de DNS ou Load Balancer, normalmente de minutos a dezenas de minutos.

Luz piloto

Uma presença mínima na região secundária (bancos de dados em replicação, infraestrutura de rede principal implantada), sem computação ativa. Em caso de failover, você implanta ou escala os recursos computacionais do aplicativo e redireciona o tráfego. Esse padrão minimiza o custo em estado estável, mas aumenta o RTO porque os recursos de computação precisam ser inicializados antes que a região possa receber tráfego.

Em todos os padrões, a conectividade entre regiões (VNet Emparelhamento Global ou WAN Virtual inter-hub) fornece o caminho de dados privado para o tráfego de replicação. Certifique-se de que seus runbooks de DR levem em conta quaisquer atrasos de propagação de rotas e valide se as regras do Grupo de Segurança de Rede (NSG) na região secundária permitem o tráfego de failover.

Restrições de chave

Constraint Impacto
O emparelhamento VNet global não é transitivo O fato de a VNet A estar emparelhada com a VNet B e de a VNet B estar emparelhada com a VNet C não significa, por si só, que a VNet A possa se comunicar com a VNet C. Você deve emparelhar a VNet A diretamente com a VNet C ou usar uma solução de trânsito, como a WAN Virtual.
WAN Virtual camada Básica não tem transitividade O WAN Virtual básico não dá suporte à conectividade transitiva VNet para VNet. Use a camada Standard para o trânsito entre regiões.
O ExpressRoute Global Reach requer a SKU Premium para conexões entre regiões geopolíticas Circuitos em diferentes regiões geopolíticas (por exemplo, EUA e Europa) exigem o complemento Premium. Os circuitos de SKU padrão só se conectam dentro do mesmo limite geopolítico.
Gateway de VPN ativo-ativo recomendado para a AWS O Gateway Virtual Privado da AWS cria dois túneis por conexão VPN. Configure Gateway de VPN do Azure no modo ativo-ativo para usar todos os túneis disponíveis e evitar o roteamento assimétrico.

Saiba mais

Próximas Etapas 

Tip

Explorando por conta própria? Retorne ao navegador de visão geral para encontrar seu próximo artigo por funcionalidade.

Próximo passo na sua jornada de migração:

Rede de várias regiões: planeje a conectividade e o failover de várias regiões se a migração for além de uma região.

A seguir, em sua jornada de modernização:

Monitoramento de rede e observabilidade: habilite a observabilidade entre regiões para preparação para produção.

A seguir, em sua jornada multinuvem:

Topologia da WAN Virtual: Use a WAN Virtual como o hub de trânsito para sua conectividade multinuvem e multifilial.

  • Last updated on