Conectividade entre regiões e multicloud

Este artigo ajuda-o a ligar cargas de trabalho Azure em várias regiões e a estender a conectividade a outros fornecedores de cloud, como a Amazon Web Services (AWS) e a Google Cloud.

O que este artigo aborda

Este artigo aborda as decisões de design para ligar redes virtuais Azure (VNets) entre regiões e estabelecer caminhos de rede para cargas de trabalho a correr noutras clouds. Aprende quando usar Global VNet Peering, WAN Virtual, ExpressRoute Global Reach, site-to-site VPN e Azure Route Server para cenários interregionais e multicloud.

Quem precisa deste artigo

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

  • A tua arquitetura abrange várias regiões do Azure e precisa de conectividade privada entre elas.
  • Precisas de ligar cargas de trabalho do Azure à AWS, Google Cloud ou outra rede externa.
  • Tem de comparar o Global VNet Peering, a WAN Virtual, o ExpressRoute Global Reach, a VPN site-to-site ou o Azure Route Server.
  • Precisa de projetar conectividade resiliente para recuperação de desastres, expansão global ou operações multicloud.

Dica

Seguir um percurso do cenário? Selecione o seu cenário no topo da página para obter orientação personalizada. As orientações principais que se seguem aplicam-se a todos os leitores.

Foco em levantar e deslocar: Inclua este artigo no seu percurso de leitura apenas se a sua migração abranger várias regiões do Azure ou se ligar 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 desastres ou a expansão geográfica se tornam prioridade.

Foco na modernização: Inclua este artigo se a sua modernização exigir conectividade privada explícita entre regiões, para além do que é abordado no artigo sobre várias regiões. Necessita desta orientação quando os spokes em diferentes regiões requerem caminhos de comunicação diretos ou quando a sua implementação ativa-ativa necessita de peering privado entre hubs regionais.

Foco multinuvem: Este artigo orienta a sua decisão central de conceção. Leia isto antes de escolher entre hub-spoke e WAN Virtual para a sua arquitetura de trânsito entre clouds. Utiliza este artigo para descobrir a sua topologia multicloud existente, mapear serviços entre AWS ou Google Cloud e Azure, e definir como o Azure se liga a cargas de trabalho que permanecem noutras clouds durante a migração.

Serviços e funcionalidades do Azure

O Azure oferece vários serviços para conectividade entre regiões e multicloud. Cada serviço responde a diferentes requisitos de escala, largura de banda e gestão.

Serviço O que oferece Quando usar
Global VNet Peering Conectividade privada de baixa latência entre VNets em diferentes regiões do Azure. O tráfego permanece na rede principal da Microsoft. A largura de banda é limitada apenas pelo SKU da máquina virtual (VM), não por um gateway. Comunicação direta entre dois VNets em diferentes regiões sem um dispositivo gateway.
WAN Virtual do Azure (Standard tier) Hub global de transporte gerido pela Microsoft que liga VNets, agências e utilizadores remotos em todas as regiões. Fornece encaminhamento transitivo entre todas as redes ligadas. Organizações com muitas regiões e filiais que necessitam de conectividade entre quaisquer pontos sem gerir ligações de peering individuais.
ExpressRoute via Cloud Exchange Ligação dedicada entre clouds através de um fornecedor de interligação de terceiros (como a Equinix ou a Megaport). Fornece conectividade privada e de alta largura de banda à AWS ou Google Cloud. Arquiteturas multicloud com requisitos de SLA de largura de banda, onde o tráfego não pode atravessar a internet pública.
VPN Site-to-Site para outras clouds Túnel IPsec encriptado entre o Gateway de VPN do Azure e o gateway VPN de outro fornecedor de cloud (AWS Virtual Private Gateway ou Google Cloud VPN). Conectividade multicloud para testes, desenvolvimento ou cenários de produção onde circuitos dedicados não são justificados.
Azure Route Server Permite a troca dinâmica de rotas BGP entre a sua VNet e os dispositivos virtuais de rede (NVAs). Injeta rotas aprendidas pela NVA na malha de encaminhamento do Azure SDN. Encaminhamento personalizado com NVAs de terceiros num hub VNet, ou encaminhamento complexo multicloud que requer propagação BGP para redes ligadas ao Azure.

Como funciona o Global VNet Peering

O Peering Global VNet cria uma ligação direta entre duas redes virtuais em diferentes regiões do Azure. A ligação corre inteiramente sobre a espinha dorsal da Microsoft e nunca atravessa a internet pública. Depois de configurar uma relação de peering, os recursos em cada VNet podem comunicar usando endereços IP privados como se estivessem na mesma rede.

Ao contrário das abordagens baseadas em gateways, o peering não introduz um único ponto de estrangulamento. A largura de banda entre VNets emparelhadas depende do SKU da VM em cada lado. Não existe um gateway dedicado que limite o débito. Este design torna o Global VNet Peering a opção de menor latência para comunicação entre regiões entre um pequeno número de VNets.

No entanto, o peering não é transitivo por definição. Se a VNet A estiver emparelhada com a VNet B e a VNet B estiver emparelhada com a VNet C, o tráfego da VNet A não pode alcançar a VNet C através da VNet B. Cada par de VNets que necessite de comunicação direta requer a sua própria ligação de emparelhamento. Num modelo hub-spoke, isto significa que, normalmente, se estabelece o peering entre as VNets de hub regionais e utilizam-se rotas definidas pelo utilizador (UDRs) ou NVAs para encaminhar o tráfego spoke-to-spoke entre regiões através dos hubs.

Trânsito global WAN Virtual

WAN Virtual do Azure (Standard tier) elimina a necessidade de configurar manualmente o peering entre hubs regionais. Quando implementa hubs WAN Virtual em múltiplas regiões, a Microsoft estabelece automaticamente ligações hub-to-hub através da backbone. As rotas aprendidas num dos hubs propagam-se para todos os outros hubs, criando uma malha de trânsito de qualquer origem para qualquer destino.

Este encaminhamento automático significa que uma VNet spoke ligada a um hub em EUA Leste pode aceder a uma VNet spoke ligada a um hub na Europa Ocidental sem qualquer configuração adicional de peering nem de tabela de rotas. A WAN Virtual também estende esta transitividade a filiais (ligadas via VPN site-to-site ou ExpressRoute) e a utilizadores remotos (ligados por VPNs point-to-site). O resultado é uma rede global totalmente integrada gerida pela Microsoft.

Para inspeção de tráfego entre regiões, ative Routing Intent em hubs virtuais protegidos. O Routing Intent força o tráfego inter-hub através do Azure Firewall, dando-lhe visibilidade centralizada e aplicação de políticas em todas as regiões sem ter de implementar e gerir NVAs individuais em cada hub.

Como escolher

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

Opções de conectividade entre regiões

Diagrama que mostra padrões de conectividade entre regiões, incluindo Global VNet Peering, trânsito entre hubs da WAN Virtual e caminhos VPN entre clouds.

O teu cenário Abordagem recomendada Porquê
Dois VNets em regiões diferentes necessitam de comunicação direta Global VNet Peering Menor latência em relação aos caminhos da internet, sem gargalo de gateway, simples de configurar. A largura de banda varia consoante o SKU da VM.
Muitas regiões, muitas sucursais, necessidade de trânsito gerido WAN Virtual do Azure (Standard tier) Fornece roteamento transitivo de qualquer origem para qualquer destino através de todos os hubs ligados. A Microsoft gere a infraestrutura de encaminhamento.
Ligue sites on-premises entre si através do Azure Alcance Global do ExpressRoute Liga dois circuitos ExpressRoute para que o tráfego local atravesse a espinha dorsal da Microsoft. Não é necessário encaminhar o tráfego em loop através das VNets do Azure.
Roteamento personalizado ou NVAs de terceiros num hub regional Azure Route Server Permite peering BGP dinâmico entre NVAs e Azure. As rotas aprendidas pelo NVA são automaticamente inseridas nas VNets spoke.

Opções de conectividade multicloud

O teu cenário Abordagem recomendada Porquê
Elevada largura de banda e SLA necessários para o tráfego entre clouds ExpressRoute via fornecedor de Cloud Exchange Fornece capacidade dedicada com latência previsível. O fornecedor de intercâmbio liga o seu circuito ExpressRoute ao serviço de ligação direta da outra cloud.
Cargas de trabalho com orçamento limitado, de teste ou de baixo rendimento VPN entre sites Utiliza a conectividade à internet existente sem custos de circuito. Adequado quando os requisitos de largura de banda são modestos.
Híbrido e multicloud (on-premises, Azure e outra nuvem) ExpressRoute Global Reach + Cloud Exchange Combina o Global Reach para o tráfego entre infraestruturas no local e o Azure com um ponto de troca na cloud para conectividade entre o Azure e outras clouds, criando um backbone privado unificado.

Considerações de design

Para a maioria das migrações “lift-and-shift”, a conectividade entre regiões é algo a considerar numa fase de expansão futura, e não um requisito inicial. A sua implementação inicial provavelmente visa uma única região do Azure.

Quando planeia uma expansão futura:

  • Emparelhamento global de VNet: Utilize o emparelhamento global de VNet entre VNets de hub regionais quando adicionar uma segunda região do Azure. Esta abordagem dá-lhe uma conectividade privada de baixa latência sem necessidade de implementar um dispositivo gateway. O tráfego permanece na rede principal da Microsoft e escala de acordo com o SKU da sua VM.
  • Complexidade diferida: Evite implementar o WAN Virtual ou o ExpressRoute Global Reach até que a sua infraestrutura se expanda para mais de duas regiões ou venha a adicionar requisitos de conectividade de filiais.
  • Preparação para DR: Mesmo que a conectividade entre regiões não seja necessária hoje, documente quais as cargas de trabalho que necessitam de recuperação de desastres e planeie previamente a topologia de peering para a poder implementar rapidamente quando necessário.

A sua arquitetura modernizada utiliza implementações em modo ativo-ativo em várias regiões. O peering entre regiões permite a comunicação direta spoke-to-spoke quando os seus níveis de aplicação atravessam fronteiras regionais.

Decisões-chave de design para modernização:

  • Emparelhamento entre regiões para configuração ativo-ativo: Emparelhe as VNets de hub da região primária e da região de backup para permitir o fluxo de tráfego bidirecional. As equipas de aplicações nos spokes ContosoBiz e ContosoCare podem aceder a recursos em qualquer uma das regiões através do caminho de peering do hub.
  • Encaminhamento através de hubs: Como o Global VNet Peering não é transitivo, encaminhe o tráfego entre spokes de regiões diferentes através da NVA do hub regional ou do Azure Firewall. Utilize rotas definidas pelo utilizador (UDRs) para direcionar o tráfego spoke-to-spoke entre regiões através do firewall do hub para inspeção.
  • Peering seletivo: Nem todas as ramificações precisam de conectividade entre regiões. Estabeleça emparelhamento apenas entre as VNets de hub e utilize a propagação de rotas para alcançar VNets spoke específicas que participam em cargas de trabalho ativo-ativo.

Este artigo é onde desenha a sua arquitetura de conectividade multicloud. Antes de planear a infraestrutura do Azure, deve identificar a sua topologia atual da cloud e mapear os serviços entre fornecedores.

Fluxo de trabalho de descoberta entre nuvens

  1. Descubra a sua topologia existente: Use a Descoberta de Cargas de Trabalho no AWS e no Google Cloud Network Intelligence Center para mapear a sua topologia atual de Virtual Private Cloud (VPC), as relações de peering e os padrões de fluxo de tráfego.
  2. Identificar fluxos de tráfego: Documente a comunicação VPC-a-VPC, os caminhos de entrada e saída da internet, e as ligações branch-to-cloud no seu ambiente AWS ou Google Cloud.
  3. Serviços de mapeamento para equivalentes ao Azure: Os mapeamentos chave para o design da conectividade são:
Serviço AWS / Google Cloud Azure equivalente
Porta de Entrada de Trânsito WAN Virtual do Azure
VPC / Rede VPC Rede Virtual do Azure
Grupos de Segurança / Regras de Firewall Grupos de Segurança de Rede (NSGs)

Para consultar mapeamentos completos de serviços entre AWS e Azure e entre o Google Cloud e o Azure, veja Cross-cloud discovery checklist.

Decisões sobre arquitetura de conectividade

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

  • Modelo de trânsito: Escolha WAN Virtual se tiver várias VPCs, filiais, regiões ou extremidades da cloud. A WAN Virtual oferece o equivalente do Azure ao AWS Transit Gateway com encaminhamento gerido de qualquer ponto para qualquer outro.
  • VPN entre clouds: Implemente as ligações do Gateway de VPN a partir do seu hub WAN Virtual (ou hub VNet) para o AWS Virtual Private Gateway e o Google Cloud VPN. Use túneis IPsec para comunicação encriptada entre cloud.
  • Aplicações que permanecem: Identifique cargas de trabalho que permanecem na AWS ou na Google Cloud durante a migração. Estas cargas de trabalho necessitam de conectividade persistente através dos túneis VPN cross-cloud até que a migração seja concluída.

Pré-requisitos

Antes de implementar conectividade multi-região ou multicloud, confirme os seguintes requisitos:

  • Duas ou mais regiões Azure com VNets implementados: As suas cargas de trabalho devem já existir (ou estar planeadas) em várias regiões. Consulte o artigo sobre VNets e sub-redes para orientações sobre planeamento VNet.
  • Topologia de hub-spoke ou de WAN Virtual: As arquiteturas entre regiões assentam numa topologia já estabelecida em cada região. Veja o artigo sobre hub-spoke ou o artigo sobre a WAN Virtual.
  • Circuitos ExpressRoute (para alcance global): Se planeia ligar locais locais, precisa de circuitos ExpressRoute existentes em cada local. Consulte o artigo sobre conectividade híbrida.
  • Acesso à conta cross-cloud: Para conectividade multicloud VPN ou exchange, precisa de acesso administrativo à consola de rede do outro fornecedor de cloud para configurar o lado remoto da ligação.

Considerações de segurança

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

Inspeção de tráfego interregional

O peering global de VNet é não transitivo. O tráfego entre VNets peered flui diretamente sem passar por um firewall ou ponto de inspeção. Se precisar de inspecionar o tráfego entre regiões, encaminhe-o através de um dispositivo virtual de rede (NVA) ou do Azure Firewall em cada hub regional.

No WAN Virtual, ative Routing Intent utilizando políticas de tráfego privado em hubs virtuais protegidos. Routing Intent força o tráfego inter-hub através de firewalls geridos no Azure Firewall Manager, o que proporciona uma inspeção centralizada do tráfego entre regiões. Esta configuração requer o nível WAN Virtual Standard.

Encriptar ligações entre nuvens

Os túneis VPN site-to-site para outras nuvens são cifrados por defeito (IPsec/IKE). No entanto, as ligações ExpressRoute através de uma central na nuvem são privadas, mas não encriptadas na camada de rede. Se precisar de encriptação via ExpressRoute, implemente MACsec em circuitos ExpressRoute Direct ou use encriptação TLS na camada de aplicação.

Para o tráfego entre nuvens que atravessa um ponto de troca de cloud sem sobreposição VPN, considere implementar um túnel IPsec com base em NVA no percurso do ExpressRoute. Esta abordagem adiciona encriptação sem abdicar dos benefícios de largura de banda e latência de um circuito dedicado. Em alternativa, use TLS mútuo (mTLS) na camada da aplicação para que cada endpoint de serviço valide a identidade e encripte os dados independentemente do transporte subjacente. A escolha depende se precisa de encriptação na camada de rede (todo o tráfego) ou se pode impor encriptação na camada da aplicação.

Considerações de custos

Toda a conectividade inter-regional implica custos de transferência de dados. O Global VNet Peering, o tráfego inter-hub da WAN Virtual e os túneis entre regiões do Gateway de VPN utilizam todos preços baseados no tráfego de saída. As taxas variam consoante o par de zonas:

  • Intra-continental (por exemplo, Leste dos EUA para Oeste dos EUA): Taxa por GB mais baixa, tipicamente dentro do intervalo dos preços padrão de saída da região.
  • Intercontinental (por exemplo, do Leste dos EUA para a Europa Ocidental): Taxa por GB mais elevada devido a distâncias mais longas da espinha dorsal e capacidade transcontinental.

A WAN Virtual adiciona um encargo por unidade de ligação por cada VNet spoke ou filial ligada a um hub, além de um encargo de processamento de dados para o tráfego que transita por um hub seguro com o Azure Firewall em execução. Este modelo de preços por níveis significa que a WAN Virtual pode custar mais do que o Global VNet Peering simples em arquiteturas com apenas algumas regiões e poucos spokes, mas oferece melhores custos unitários à escala quando se ligam dezenas de filiais e regiões.

Para conectividade multicloud, o ExpressRoute, através de uma exchange cloud, incorre em taxas de porta e de ligação cruzada do fornecedor da exchange, além das taxas do circuito Azure ExpressRoute e das taxas de ligação direta da outra cloud. A VPN site-to-site evita custos de circuito, mas ainda assim incorre em custos padrão de saída por dados que saem do Azure.

Orientação: Coloque cargas de trabalho de alto tráfego na mesma região sempre que possível. Reserve ligações entre regiões para a sincronização do plano de controlo, a replicação assíncrona e a comutação pós-falha para recuperação após desastre, que são normalmente fluxos de menor volume.

Padrões de recuperação de desastres

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

Active-active

Ambas as regiões servem simultaneamente o tráfego de produção. Um balanceador de carga global (como o Azure Front Door ou o Gestor de Tráfego do Azure) distribui pedidos entre regiões. Se uma região falhar, o tráfego desloca-se para a região sobrevivente com interrupções mínimas. Este padrão oferece 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 custos e complexidade.

Active-passive

Uma região processa o tráfego de produção, enquanto a segunda região permanece em modo de espera com infraestrutura pré-implantada (mas potencialmente dimensionada em menor escala). A replicação mantém os dados passivos da região atualizados. Em caso de falha, promove-se a região passiva e redireciona-se o tráfego. O RTO depende da rapidez com que se aumentam os recursos passivos e se conclui a comutação pós-falha do DNS ou do balanceador de carga, normalmente, de alguns minutos a dezenas de minutos.

Luz piloto

Uma pegada mínima na região secundária (bases de dados a replicar, redes centrais implementadas) sem computação ativa. Em caso de failover, implementa ou dimensiona a capacidade de computação da aplicação e comuta o tráfego. Este padrão minimiza o custo em regime estacionário, mas aumenta a RTO, pois os recursos de computação têm de começar antes de a região poder servir o tráfego.

Em todas as arquiteturas, a conectividade entre regiões (Global VNet Peering ou WAN Virtual inter-hub) assegura o percurso privado dos dados para o tráfego de replicação. Certifique-se de que os seus runbooks de DR têm em conta quaisquer atrasos na propagação de rotas e validem que as regras do Network Security Group (NSG) na região secundária permitem tráfego de failover.

Principais restrições

Restrição Impact
O peering global de VNet é não transitivo A VNet A emparelhada com a VNet B, e a VNet B emparelhada com a VNet C, não significa que a A consiga comunicar com a C. Tem de emparelhar a A diretamente com a C ou utilizar uma solução de trânsito, como a WAN Virtual.
O nível básico da WAN Virtual carece de transitividade A WAN Virtual básica não suporta conectividade transitiva VNet-para-VNet. Use o nível Standard para transporte interregional.
O ExpressRoute Global Reach requer SKU Premium para ligações trans-geopolíticas Circuitos em diferentes regiões geopolíticas (por exemplo, EUA e Europa) exigem o adicional Premium. Circuitos SKU padrão só se ligam dentro do mesmo limite geopolítico.
Active-active Gateway de VPN recomendado para AWS O AWS Virtual Private Gateway cria dois túneis por ligação VPN. Configure o Gateway de VPN do Azure em modo ativo-ativo para utilizar todos os túneis disponíveis e evitar o roteamento assimétrico.

Saiba mais

Passos seguintes

Dica

Explorar sozinho? Volte ao navegador de visão geral para encontrar o seu próximo artigo por capacidade.

A seguir na sua jornada de levantar e deslocar:

Rede multirregional: Planeie a conectividade multirregional e a ativação pós-falha se a sua migração se expandir para além de uma região.

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

Monitorização e observabilidade de rede: Ative a observabilidade em várias regiões para a preparação para produção.

A seguir na sua jornada através da cloud:

Topologia da WAN Virtual: Utilize a WAN Virtual como hub de trânsito para a sua conectividade multicloud e multifilial.

  • Last updated on