Topologia de rede hub-and-spoke

Este artigo explica como conceber uma rede hub-and-spoke no Azure. Uma rede virtual de hub central acolhe serviços partilhados, enquanto redes virtuais satélite isoladas acolhem cargas de trabalho individuais.

O que este artigo aborda

Este artigo aborda os serviços partilhados da rede virtual de hub, o isolamento das spokes e os padrões de encaminhamento (padrão, peering direto e baseados em stamps). Também abrange o trânsito de gateway para conectividade híbrida e a expansão de topologias hub-and-spoke com o Azure Virtual Network Manager.

Quem precisa deste artigo

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

  • Precisas de serviços de rede partilhados como firewall, DNS, Bastion, Gateway de VPN ou ExpressRoute para múltiplas cargas de trabalho.
  • Queres centralizar a inspeção de tráfego, o controlo de roteamento ou a administração em vez de repetir esses serviços em cada VNet.
  • Precisas de uma topologia repetível para separar serviços de plataforma partilhada dos VNets de carga de trabalho.
  • Deves comparar o hub-and-spoke com outros modelos de transporte antes de padronizar a tua topologia.

Se tiver uma única carga de trabalho sem requisitos de serviço partilhado, comece com uma topologia de rede plana .

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: Leia este artigo se estiver a transferir cargas de trabalho on-premises para o Azure e precisar de serviços partilhados centralizados (DNS, firewall, Gateway de VPN) entre vários VNets de raios. Hub-and-spoke é a topologia padrão para migrações de levantamento e deslocamento com múltiplas cargas de trabalho que requerem infraestrutura partilhada num único hub.

Foco na modernização: Leia este artigo se estiver a implementar serviços PaaS em várias regiões e precisar de uma topologia de hub duplo, com hubs pertencentes à TI e spokes pertencentes à equipa de aplicações. O modelo hub-and-spoke dimensiona-se para suportar limites separados entre subscrições para serviços de plataforma e cargas de trabalho aplicacionais.

Foco entre clouds: Leia este artigo se estiver a avaliar hub-and-spoke versus WAN Virtual para trânsito entre clouds. Se o seu ambiente multicloud for suficientemente pequeno para não justificar a WAN Virtual, uma arquitetura hub-and-spoke tradicional com ligações do Gateway de VPN a outras clouds proporciona um ponto de partida mais simples.

Serviços e funcionalidades do Azure

A tabela seguinte lista os serviços e funcionalidades do Azure que suportam uma topologia hub-and-spoke:

Serviço ou funcionalidade Papel no modelo hub-spoke Saiba mais
Rede Virtual do Azure Fornece redes virtuais em topologia hub-and-spoke Visão geral da rede virtual
Emparelhamento VNet Liga cada raio ao cubo Emparelhamento de rede virtual
Azure Firewall Inspeção e filtragem do tráfego central no hub Descrição geral do Azure Firewall
Gateway de VPN ou ExpressRoute Gateway Conectividade híbrida partilhada entre todas as ramificações Visão geral do Gateway de VPN
Azure Bastion Acesso remoto seguro a VMs entre spokes emparelhados Visão geral Azure Bastion
Azure DNS Privado Resolver Encaminhamento DNS entre Azure e on-premises Visão geral do DNS Privado Resolver
Azure DDoS Protection Plano DDoS partilhado que abrange os IPs públicos dos spokes Visão geral da Proteção contra DDoS
Azure Virtual Network Manager (AVNM) Peering automatizado de spokes, gestão de UDR e grupos de rede à escala Visão geral do AVNM

Como funciona

Diagrama que mostra uma topologia hub-and-spoke com redes no local ligadas através de ExpressRoute e de VPN site a site a uma VNet hub que contém as sub-redes do gateway, do Azure Firewall e do Azure Bastion, emparelhada com três VNets spoke com diferentes cargas de trabalho em execução.

Numa topologia de hub-and-spoke:

  1. Uma rede virtual hub atua como o ponto central de conectividade. Contém serviços de rede partilhados, como firewall, gateway e host Bastion.
  2. Redes virtuais de raio estabelecem emparelhamento com o hub. Cada spoke aloja uma carga de trabalho: uma aplicação, um ambiente de equipa ou um serviço isolado.
  3. O peering de VNet é não transitivo. As redes spoke podem ligar-se ao hub, mas não podem comunicar diretamente entre si através do hub, a menos que configure o encaminhamento ou o emparelhamento direto entre elas.

O que está incluído na rede virtual do hub

Use a tabela seguinte para determinar que serviços colocar no seu hub:

Serviço Incluir? Notes
Azure Firewall Recomendado Proporciona inspeção centralizada de tráfego para todo o tráfego este-oeste e norte-sul. Requer uma sub-rede com o nome exato AzureFirewallSubnet.
VPN ou gateway do ExpressRoute Se for necessária conectividade híbrida Todos os spokes partilham um único gateway através do trânsito de gateway. Requer uma sub-rede com o nome exato GatewaySubnet (mínimo /27).
Azure Bastion Recomendado Um anfitrião Bastion no hub permite aceder a VMs em todas as redes virtuais periféricas emparelhadas. Requer o SKU Básico ou superior: o SKU de Desenvolvedor não suporta acesso de peering entre VNets.
Resolvedor de DNS privado Se for necessário DNS personalizado Encaminha consultas DNS entre zonas DNS privadas alojadas no Azure e servidores DNS locais.
plano do Azure DDoS Protection Se a proteção DDoS estiver ativada Um único plano pode proteger endereços IP públicos em todas as redes virtuais spoke ligadas à subscrição do hub.

Important

Mantenha as cargas de trabalho das aplicações fora do hub. O hub aloja apenas serviços de infraestrutura partilhada: firewall, gateways, Bastion e DNS. As VMs de aplicação, os contentores e os recursos PaaS pertencem a redes virtuais spoke. Esta separação mantém o hub limpo, simplifica o peering e permite à equipa da plataforma gerir serviços partilhados independentemente das equipas de aplicação.

Estrutura da sub-rede hub

Uma rede virtual hub bem desenhada normalmente inclui estas sub-redes:

Nome da sub-rede Purpose Tamanho mínimo
AzureFirewallSubnet Implementação do Azure Firewall /26
AzureFirewallManagementSubnet NIC de gestão para tunelamento forçado (apenas Standard/Premium) /26
GatewaySubnet Gateways de VPN e de ExpressRoute /27
AzureBastionSubnet Azure Bastion /26
Sub-rede de entrada do resolvedor DNS Endpoint de entrada do DNS Privado Resolver /28
Subrede de saída do resolvedor de DNS endpoint de saída do DNS Privado Resolver /28

Para orientações detalhadas sobre dimensionamento de sub-redes, consulte VNets e sub-redes.

Como escolher uma variante

O modelo hub-and-spoke tem três variantes comuns. Escolha com base nos seus requisitos de isolamento e comunicação:

Diagrama mostrando três variantes de topologia: carimbos isolados, hub-spoke com peering direto, e hub-spoke padrão através do firewall

Variant Percurso de trânsito Quando utilizar
Cubo e raio padrão Todo o tráfego entre spokes passa pelo firewall do hub Precisas de uma inspeção centralizada do trânsito. As ramificações não exigem comunicação direta ponto a ponto.
Hub-and-spoke com peering direto Pares específicos de spokes também estabelecem peering direto entre si Cargas de trabalho fortemente acopladas necessitam de comunicação spoke to-spoke de baixa latência sem atravessarem o firewall.
Selos (totalmente isolados) Sem hub. Cada rede virtual é completamente independente. Isolamento rigoroso do raio de explosão, separação orientada pela conformidade ou SaaS multitenant com pilhas independentes.

Cubo e raio padrão

Esta variante é a mais comum. Todo o tráfego entre spokes passa pela firewall do hub para inspeção. As ramificações comunicam apenas por intermédio do hub, nunca diretamente.

Padrão de roteamento: Aplique uma rota definida pelo utilizador (UDR) a cada sub-rede spoke, com a rota predefinida (0.0.0.0/0) a apontar para o endereço IP privado da firewall do hub. Isto obriga todo o tráfego de saída, incluindo o spoke-to-spoke, a passar pelo firewall para registo e filtragem.

Limite de peering: Uma rede virtual de hub único suporta até 500 ligações de peering (limite padrão da plataforma). Se usar o Azure Virtual Network Manager (AVNM) com uma configuração de conectividade hub-spoke, o limite aumenta para 1.000 spokes.

Hub-and-spoke com peering direto

Em algumas arquiteturas, pares específicos de spokes necessitam de comunicação de baixa latência sem passar pela firewall do hub. Nesses casos, adicione o emparelhamento direto de VNet entre o par de spokes ou utilize os grupos conectados do AVNM.

Utilize o emparelhamento direto do spoke quando:

  • Duas cargas de trabalho trocam dados de alto débito (por exemplo, replicação de base de dados entre raios).
  • A latência no salto no firewall é inaceitável num determinado percurso de dados.
  • Aceita que o tráfego em peering direto contorna a inspeção do firewall central.

Note

O emparelhamento direto entre as ramificações não dispensa a necessidade do hub. O tráfego no hub (saída, conectividade híbrida, serviços partilhados) continua a passar pelo firewall do hub.

Padrão de carimbos (completamente isolado)

O padrão Stamps é uma alternativa para cenários que exigem isolamento rigoroso do raio de explosão. Cada carga de trabalho é implantada numa rede virtual totalmente independente, sem hub e sem peering para outras cargas de trabalho.

Quando usar Selos:

  • A conformidade regulamentar não exige um caminho de rede entre cargas de trabalho.
  • SaaS multitenant onde cada tenant tem uma stack independente.
  • Isolamento máximo de falhas: uma falha num carimbo não pode propagar-se para outros.

Exemplo: Isolamento SaaS multitenant

Um fornecedor SaaS aloja cada cliente empresarial num carimbo dedicado. Cada stamp contém a sua própria VNet (10.x.0.0/16), gateway de aplicações, escalão de computação e base de dados. Não existe peering VNet entre carimbos, por isso um NSG mal configurado ou uma carga de trabalho comprometida no carimbo do Tenant A não consegue aceder aos recursos do Tenant B através da rede. O fornecedor gere carimbos através de templates do Azure Resource Manager e implementa-os em grupos de recursos separados ou subscrições separadas para grandes locatários. A troca de dados entre inquilinos, quando necessário, utiliza um namespace partilhado do Azure Service Bus. Cada carimbo acede a este namespace através de endpoints privados.

Compensações:

  • Sem serviços partilhados. Cada carimbo precisa do seu próprio firewall, gateway e host Bastion (se necessário), o que aumenta o custo.
  • Sem comunicação entre cargas de trabalho através de redes privadas.
  • A sobrecarga operacional aumenta porque se gerem redes independentes em vez de infraestruturas centralizadas.
  • O custo cresce linearmente com o número de selos porque as poupanças em serviços partilhados não se aplicam.

Se as suas cargas de trabalho precisarem de serviços partilhados ou de comunicação entre diferentes cargas de trabalho, utilize, em vez disso, a variante padrão hub-and-spoke.

Padrões de comunicação radio-a-raio

Como o peering VNet é não transitivo, a comunicação spoke-to-spoke requer encaminhamento explícito. Esta secção explica como o tráfego circula entre as redes spoke através do firewall do hub.

Fluxo de tráfego: Spoke A para Spoke B através do firewall do hub

A sequência seguinte descreve como um pacote viaja de uma VM em Spoke A (10.1.0.4) para uma VM em Spoke B (10.2.0.4):

  1. Spoke Uma VM envia um pacote destinado a 10.2.0.4. A tabela de rotas efetiva da VM contém um UDR com 0.0.0.0/0 → 10.0.1.4 (o IP privado do Azure Firewall).
  2. O pacote atravessa a ligação de peering VNet do Spoke A para o hub VNet. O peering permite que o tráfego chegue à sub-rede do firewall.
  3. O Azure Firewall recebe o pacote na sua interface interna. Avalia o pacote em relação às regras de rede e às regras de aplicação por ordem de prioridade.
  4. Se uma regra permitir o fluxo, o firewall encaminha o pacote para 10.2.0.4. O pacote passa pela ligação de emparelhamento hub-to-Spoke-B.
  5. A VM Spoke B recebe o pacote. O tráfego de retorno segue o mesmo caminho em sentido inverso. O UDR do Spoke B envia a resposta de volta através do firewall.

Configuração das tabelas de roteamento

Aplique estas tabelas de rota para permitir o padrão anterior:

  1. Crie uma tabela de rotas para sub-redes spoke. Desligue a propagação de rotas BGP se quiser evitar que as rotas locais se sobreponham às suas UDRs.
  2. Adicione uma rota padrão (0.0.0.0/0) com o próximo tipo VirtualAppliance de salto e o endereço do próximo salto definido para o IP privado do Azure Firewall.
  3. Associe a tabela de encaminhamento a cada sub-rede spoke que precise de aceder a outros spokes ou à Internet.
  4. Crie regras de firewall de rede que permitam o tráfego específico entre spokes. Por exemplo, permitir 10.1.0.0/16 → 10.2.0.0/16 nas portas 443 e 1433.

Dica

Utilize Grupos de IP no Azure Firewall para organizar intervalos de endereços dos spokes. Isto simplifica a gestão de regras à medida que adiciona spokes.

Alternativa: grupos AVNM ligados para spoke-to-spoke direto

Se não precisar de inspeção de firewall entre spokes específicos, os grupos conectados do AVNM oferecem um modelo de conectividade em malha. Os spokes no mesmo grupo conectado comunicam diretamente sem passar pelo hub. Isto reduz a latência e os requisitos de rendimento do firewall, mas evita a inspeção centralizada.

Important

Se ativares o tunneling forçado no Azure Firewall (para encaminhar tráfego ligado à internet para um appliance local), precisas do nível Standard ou Premium. O tunelamento forçado também requer uma sub-rede de gestão (AzureFirewallManagementSubnet) e desativa as regras DNAT.

Trânsito de gateway

O trânsito de gateway permite que todos os spokes partilhem um único gateway de VPN ou de ExpressRoute implementado no hub. Sem trânsito através do gateway, cada spoke necessita do seu próprio gateway para aceder às redes locais.

Passos de configuração

  1. Implemente um gateway de VPN ou de ExpressRoute no GatewaySubnet do hub.
  2. Na ligação de emparelhamento no lado do hub (hub → spoke): ativar Permitir trânsito de gateway.
  3. Na ligação de peering do lado do spoke (spoke → hub): ative Usar gateways remotos.
  4. Verifique a propagação da rota. Após a configuração, verifique as rotas efetivas na NIC de uma VM spoke. A tabela de encaminhamento mostra prefixos on-premises aprendidos através do gateway do hub com um tipo de próximo salto de VNetGlobalPeering ou VNetPeering.

Quando configurado, as rotas aprendidas pelo gateway do hub (por exemplo, prefixos no local do ExpressRoute) propagam-se automaticamente para as tabelas de encaminhamento dos spokes.

Limitações de trânsito de gateways

  • O trânsito de gateway funciona com todos os níveis do Gateway de VPN exceto o escalão Básico. Se utilizar o Basic Gateway de VPN, não o pode partilhar com redes virtuais em emparelhamento.
  • Uma rede virtual spoke pode usar apenas um gateway remoto. Não podes ativar Use remote gateways num spoke que tenha emparelhamento com vários hubs.
  • Se usar UDRs para forçar o tráfego através do firewall, certifique-se de que o UDR não sobrepõe involuntariamente as rotas on-premises propagadas pelo gateway. Defina rotas mais específicas para prefixos locais, se necessário.

Note

Quando utiliza o ExpressRoute com trânsito de gateway, ative Permitir trânsito de gateway antes de estabelecer os emparelhamentos spoke. O gateway deve primeiro existir e ser configurado.

Azure Virtual Network Manager em grande escala

Quando o seu ambiente cresce para além de um punhado de spokes, gerir manualmente ligações de peering e tabelas de encaminhamento torna-se complexo. O AVNM fornece automação para topologias hub-and-spoke:

Capacidade AVNM O que faz
Configuração da conectividade por raios hub Cria e mantém automaticamente peering entre o hub e todos os spokes num grupo de rede. Suporta até 1.000 ramificações por hub.
Grupos conexos Permite conetividade direta spoke-to-spoke sem necessidade de peering manual. Limite padrão: 250 redes virtuais por grupo (expandível para 1.000 mediante pedido).
Grupos de rede com membros dinâmicos Utiliza as condições do Azure Policy para adicionar automaticamente redes virtuais a grupos com base em tags, nomes ou subscrições.
Gestão do UDR Automatiza a implementação de tabelas de rotas em várias topologias hub-and-spoke.

O AVNM é especialmente valioso quando gere topologias hub-spoke em várias regiões ou quando necessita de associação dinâmica à medida que novas redes virtuais spoke ficam disponíveis.

Considerações sobre o dimensionamento

À medida que a sua topologia hub-and-spoke cresce, planeie os seguintes limites da plataforma e modelos organizacionais:

Limites de interligação e conectividade

Dimensão Limite padrão Com AVNM Notes
Emparelhamentos de VNet por rede virtual 500 1.000 (configuração hub-and-spoke) Cada peering de raios para hub consome um slot em ambos os lados
Redes virtuais por grupo conectado AVNM 250 (padrão) Até 1.000 (a pedido) Aumento de pedidos através do suporte do Azure
Subscrições por âmbito de AVNM N/A 1,000 O âmbito pode abranger múltiplas subscrições num grupo de gestão

Organização de subscrição

  • Separe os spokes em subscrições específicas por carga de trabalho para ambientes com mais de 10 spokes. Isto isola a faturação, o RBAC e os limites de quotas por cada equipa de cargas de trabalho.
  • Utilize uma subscrição dedicada de conectividade para a VNet do hub, os gateways e a firewall. Este é o padrão recomendado pelas zonas de aterragem do Azure (subscrição da plataforma).
  • Agrupe as subscrições num grupo de gestão para que o AVNM possa descobrir e gerir dinamicamente redes virtuais spoke em várias subscrições através de condições da Política do Azure.

Impor a topologia através do Azure Policy

Use Azure Policy para evitar desvios de configuração:

  • Negar peering para VNets não-hub. Atribuir uma política ao nível do grupo de gestão que bloqueie a criação de peering VNet, a menos que o destino seja o VNet do hub designado.
  • Exigir associação com UDR. Atribua uma política que audita (ou nega) sub-redes satélite que não tenham uma tabela de rotas que inclua a rota 0.0.0.0/0 → Firewall.
  • Impor a pertença ao grupo AVNM. Use regras dinâmicas de adesão no AVNM baseadas em tags (por exemplo, NetworkRole:Spoke) para que novos VNets sejam automaticamente inscritos.

Caminho de migração do plano para o hub-spoke

Se começou com uma topologia de rede plana e o seu ambiente cresceu para exigir serviços partilhados ou segmentação entre cargas de trabalho, siga este caminho de migração:

Passo 1: Planeia o hub VNet

  1. Aloque um novo espaço de endereçamento para o hub (por exemplo, 10.0.0.0/16) que não se sobreponha ao seu VNet plano existente.
  2. Determine que serviços partilhados implementar: firewall, gateway, Bastion, resolvedor DNS.
  3. Dimensione as sub-redes do hub de acordo com a tabela de disposição das sub-redes do hub.

Passo 2: Implementar serviços partilhados no hub

  1. Cria o hub VNet e implementa o Azure Firewall (ou o NVA que escolheres).
  2. Implementa o gateway VPN/ExpressRoute se precisares de conectividade híbrida.
  3. Implemente o Azure Bastion para acesso seguro a VMs.
  4. Configure o DNS Privado Resolver se estiver a usar DNS personalizado.

Passo 3: Migrar cargas de trabalho para os spokes

  1. Crie VNets spoke com novos espaços de endereçamento para cada carga de trabalho. Se não conseguires reatribuir os endereços IP, podes manter os intervalos existentes, desde que não se sobreponham ao hub.
  2. Cada um dos pares falou com o hub. Ative o trânsito de gateway do lado do hub e utilize gateways remotos do lado do spoke.
  3. Aplique UDRs às sub-redes spoke, com a rota predefinida a apontar para a firewall do hub.
  4. Mover ou reimplantar VMs e serviços do VNet plano para o spok apropriado. Utilize o Azure Resource Mover ou efetue uma nova implementação, consoante a complexidade da carga de trabalho.
  5. Crie regras de firewall para permitir os padrões de tráfego interspoke e spoke-to-internet que anteriormente permitiu dentro do VNet plano.

Passo 4: Descomissionar o VNet plano

  1. Verifique se todas as cargas de trabalho estão acessíveis através da nova topologia hub-and-spoke.
  2. Atualize os registos DNS se os endereços IP privados mudaram.
  3. Remova a VNet plana antiga depois de migrar e validar todo o tráfego.

Dica

Migra as cargas de trabalho em fases. Comece com uma carga de trabalho não crítica para validar as regras de roteamento e firewall, depois avance com cargas de trabalho em produção.

Quando considerar o WAN Virtual em vez disso

Se a sua topologia hub-spoke está a crescer em complexidade, avalie se a WAN Virtual do Azure oferece uma melhor adaptação:

Fator Hub-and-spoke (tradicional) WAN Virtual do Azure
Management Infraestrutura de hub gerida pelo cliente Encaminhamento e conectividade do hub gerido pela Microsoft
Melhor para Menos de 30 conexões de ramal VPN, necessário controlo total Mais de 30 filiais VPN, várias regiões do Azure
Routing O cliente configura os UDRs manualmente Roteamento automático no hub
SD-WAN integração Implementação manual do NVA Integração nativa de parceiros SD-WAN
Trânsito global Requer encaminhamento inter-hub gerido pelo cliente Integrado: todos os hubs interligam-se automaticamente

Para uma comparação detalhada, veja WAN Virtual do Azure topology.

Considerações de design

Para uma migração lift-and-shift, implemente um único hub com serviços partilhados que são utilizados por todas as cargas de trabalho migradas:

  • Hub único com Gateway de VPN. Implemente o Gateway de VPN (ou gateway ExpressRoute) no GatewaySubnet do hub. Todas as cargas de trabalho spoke partilham este gateway através do trânsito de gateway para conectividade no local durante e após a migração.
  • Azure Bastion no hub. Uma única implementação do Bastion no hub fornece acesso RDP/SSH seguro às VMs em todos os spokes emparelhados, sem expor IPs públicos nos servidores migrados.
  • Firewall centralizado para tráfego de saída. Implementa o Azure Firewall no hub. Configure UDRs em cada sub-rede spoke, com a rota predefinida a apontar para a firewall. Todo o tráfego de saída e o tráfego spoke-to-spoke passa por este único ponto de inspeção.
  • Comece com um núcleo e adicione ramificações gradualmente. Emparelhe a VNet spoke de cada carga de trabalho ao hub à medida que a migra. Um único hub suporta até 500 ligações de peering (1.000 com AVNM).

Para um cenário de migração e modernização, planeie uma topologia de duplo hub que separe a infraestrutura da plataforma das cargas de trabalho da aplicação:

  • Implementação de hub duplo. Implementa um hub na tua região principal e um segundo hub na tua região de backup. Cada hub contém o seu próprio firewall, gateway e Bastion. Isto é compatível com arquiteturas de tipo ativo-ativo para cargas de trabalho PaaS.
  • Hubs geridos por TI, spokes geridos pela equipa de aplicações. A equipa da plataforma gere as subscrições dos hubs (padrão de subscrição de conectividade, uma subscrição dedicada do Azure para recursos de rede partilhados, separada das subscrições de carga de trabalho). As equipas de aplicação são responsáveis pelas suas subscrições spoke, com controlo delegado das respetivas sub-redes de Private Link e dos recursos da carga de trabalho.
  • Sub-redes de Private Link por ramo. Cada VNet spoke inclui uma sub-rede dedicada para Private Endpoints. As equipas de aplicações criam ligações do Private Link para os seus serviços PaaS (SQL do Azure, Storage, Key Vault) nos seus próprios spokes.
  • Firewall de hub como SNAT/DNAT. O firewall central em cada hub fornece NAT de origem para tráfego de saída e NAT de destino para padrões de tráfego de entrada. As equipas de aplicação não conseguem contornar a inspeção centralizada.

Para conectividade cross-cloud, avalie se o hub-spoke tradicional ou a WAN Virtual fornecem o modelo de trânsito adequado:

  • Decisão entre hub-spoke vs WAN Virtual. Se tiver menos de 30 ligações a filiais, um pequeno número de túneis VPN entre clouds e operar em uma ou duas regiões do Azure, a topologia hub-and-spoke tradicional com o Gateway de VPN é mais simples. Se tiver muitas VPCs, filiais, regiões ou extremidades na cloud, a WAN Virtual fornece encaminhamento automatizado com melhor escalabilidade.
  • Gateway de VPN para túneis entre nuvens. Num modelo hub-spoke, implemente o Gateway de VPN no hub e crie ligações site-to-site para AWS Virtual Private Gateways e endpoints Google Cloud VPN. Cada ligação utiliza encriptação IPSec/IKE.
  • Avaliar o crescimento da complexidade. Se o seu ambiente multicloud aumentar (mais contas AWS, projetos Google Cloud ou regiões do Azure), reavalie a decisão entre hub-spoke e WAN Virtual. A WAN Virtual torna-se mais económica ao gerir muitos túneis em grande escala.

Para uma comparação completa, veja WAN Virtual do Azure topology.

Pré-requisitos

Antes de desenhar uma rede hub-and-spoke:

  • Complete o seu plano de rede virtual e sub-rede. Saiba quantos spokes são necessários e de que sub-redes cada spoke precisa.
  • Defina o seu esquema de endereços IP. Os espaços de endereços do hub e spoke não se devem sobrepor entre si.
  • Tenha em atenção que o emparelhamento de VNets não é transitivo: os spokes não herdam conectividade para outros spokes através do hub.

Considerações de segurança

Uma topologia de hub e raios centraliza a aplicação da segurança no hub. Aplique estes princípios:

  • Encaminhe todo o tráfego dos spokes pelo firewall do hub. Utilize UDRs com a rota predefinida apontada para o firewall. Esta configuração garante que a firewall inspecione e registe todos os fluxos entre spokes e entre spokes e a Internet.
  • Utilize NSGs em sub-redes spoke como defesa em profundidade. Mesmo com um firewall central, os grupos de segurança de rede das sub-redes spoke proporcionam uma camada adicional de segmentação. Negar tráfego lateral inesperado ao nível da sub-rede. Para orientações de design de NSG, consulte grupos de segurança de rede e grupos de segurança de aplicações.
  • Ativar o trânsito de gateway com cuidado. O Gateway transit expõe as rotas locais a todos os raios. Certifique-se de que as regras de firewall têm em conta a conectividade expandida.
  • Remova os IPs públicos das VMs spoke. O Azure Bastion no hub proporciona acesso seguro à gestão sem expor VMs à internet.
  • Trate cada spoke como uma barreira de segurança. As cargas de trabalho em diferentes spokes mantêm-se isoladas por predefinição. A conectividade entre spokes requer regras explícitas de encaminhamento e de firewall.

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:

Ligue-se à sua rede local: Configure o Gateway de VPN ou ExpressRoute no seu hub VNet para estabelecer a dependência crítica de migração.

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

Planeie a sua implementação multirregional: Implemente em modo ativo-ativo nas regiões primária e de contingência para as suas aplicações destinadas ao cliente.

A seguir na sua jornada através da cloud:

Avalie o WAN Virtual do Azure como o seu modelo de trânsito de rede: Avalie se o WAN Virtual do Azure ou a topologia hub-and-spoke é mais adequada ao seu ambiente multicloud com várias VPCs, filiais e regiões.

  • Last updated on