Percurso de conceção de redes entre clouds

Este guia fornece um percurso de leitura sequencial através do Azure Networking Design Guide para clientes que ligam Azure à Amazon Web Services (AWS), Google Cloud ou migram cargas de trabalho de outro fornecedor cloud. Siga os passos numerados para projetar uma conectividade segura e monitorizada entre o Azure e a sua infraestrutura cloud existente.

Porque é que a descoberta vem primeiro

A rede cross-cloud liga o Azure a um ou mais ambientes cloud externos. Podes executar cargas de trabalho na AWS ou Google Cloud que precisam de conectividade privada aos serviços Azure, ou podes migrar aplicações de outra cloud para o Azure mantendo a conectividade às aplicações que ficam para trás. De qualquer forma, a tua rede Azure tem de se integrar com uma infraestrutura que não controlas totalmente do outro lado.

Este caminho de leitura começa com a descoberta em vez do design da infraestrutura Azure. Primeiro mapeias a tua topologia multicloud existente (percebendo o que corre onde, como se liga e que tráfego flui entre as clouds) antes de desenhares o lado do Azure. Esta abordagem centrada na descoberta impede reestruturações: se projetar redes Azure sem compreender a topologia da AWS ou Google Cloud, corre o risco de conflitos de endereços IP, lacunas de conectividade e pontos cegos de segurança.

A sua arquitetura de destino utiliza a Azure Virtual Wide Area Network (WAN) como hub de trânsito (o equivalente em Azure ao AWS Transit Gateway), com túneis VPN IPSec para o AWS Virtual Private Gateway e Google Cloud VPN. O Azure Firewall, num hub virtual seguro, inspeciona todo o tráfego cross-cloud e branch. O DNS requer um planeamento cuidadoso da transição para manter a resolução de nomes a funcionar entre ambientes de cloud durante a migração.

Pré-requisitos

  • Leia o plano de rede Azure e a visão geral do design para orientação sobre os serviços de rede Azure disponíveis.
  • Descoberta completa da topologia dos seus ambientes AWS e Google Cloud:
    • AWS: Execute o AWS Migration Hub ou Workload Discovery na AWS para inventariar Virtual Private Clouds (VPCs), Transit Gateways e conectividade inter-VPC.
    • Google Cloud: Use o Network Intelligence Center para mapear redes VPC, anexos de Cloud Interconnect e regras de firewall.
  • Fluxos de tráfego entre nuvens de documentos: que aplicações comunicam entre nuvens, largura de banda necessária, sensibilidade à latência e requisitos de encriptação.
  • Crie um inventário dos intervalos de endereços IP em todas as três clouds para identificar sobreposições.

O teu percurso de leitura

As fases seguintes guiam-no no design de redes cross-cloud em sequência.

Fase 1: Descoberta

Comece pela descoberta. Compreenda o seu panorama multicloud antes de desenhar a infraestrutura Azure.

1. Conectividade entre regiões e multicloud

Este artigo é o seu ponto central de decisão de design. Mapeie a sua topologia multicloud: que VPCs AWS e Google Cloud precisam de ligação ao Azure, que tráfego flui entre as clouds e que padrão de arquitetura se adequa à sua escala. Utilize o mapeamento de serviços entre fornecedores de cloud (Transit Gateway para WAN Virtual, Security Groups para Network Security Groups, VPC Peering para VNet peering) para converter o seu design existente para a terminologia do Azure.

2. WAN Virtual do Azure

WAN Virtual é o modelo de trânsito recomendado quando existem múltiplas VPCs, filiais, regiões ou extremidades da cloud. A WAN Virtual fornece o equivalente em Azure ao AWS Transit Gateway: roteamento automatizado, segurança centralizada e escala multirregional. Avalie se a sua infraestrutura multi-cloud justifica uma WAN Virtual ou se uma topologia hub-and-spoke mais simples com um Gateway de VPN é suficiente.

Fase 2: Fundações

3. Redes virtuais e sub-redes

Desenhe o seu VNet Azure como a zona de aterragem para cargas de trabalho migradas ou ligadas. Mapeamento entre os conceitos de VPC da AWS e do Google Cloud VPC: as sub-redes da VPC passam a sub-redes do Azure, as zonas de disponibilidade correspondem às zonas de disponibilidade do Azure e as tabelas de encaminhamento seguem um padrão semelhante. Foca-te no dimensionamento das subredes para as cargas de trabalho que caem no Azure.

4. Planeamento de endereços IP

Planeie espaços de endereçamento não sobrepostos entre as três clouds. Este passo é fundamental para a conectividade entre cloud: se os seus intervalos Azure VNet se sobrepõem aos intervalos AWS VPC ou Google Cloud VPC, não pode estabelecer túneis VPN entre eles. Documente cada bloco CIDR em uso em todos os ambientes antes de alocar o espaço de endereçamento do Azure.

5. Grupos de segurança de rede e grupos de segurança de aplicações

Espelhe os seus Grupos de Segurança da AWS e as regras de firewall do Google Cloud como Grupos de Segurança de Rede do Azure (NSGs). Traduza as regras existentes de permitir e recusar para o formato NSG. Use Grupos de Segurança de Aplicações (ASGs) para replicar o agrupamento baseado em tags que as referências AWS Security Group fornecem.

Fase 3: Conectividade

6. Conectividade híbrida

Configure túneis VPN IPSec entre Azure e AWS ou Google Cloud para trânsito encriptado entre cloud. Ligue o Gateway de VPN do Azure (ou ligações WAN Virtual VPN) ao AWS Virtual Private Gateway e Google Cloud VPN. Escolha a largura de banda do túnel de acordo com as suas necessidades de tráfego entre clouds. Planeie túneis redundantes para evitar pontos únicos de falha.

Fase 4: Segurança

7. Segurança DNS e resolução privada de nomes

Planeie a sua estratégia de transição de DNS antes de migrar cargas de trabalho. As aplicações na AWS ou na Google Cloud resolvem nomes de host que possam ter de apontar para o Azure após a migração. Configurar o DNS do Azure Private Resolver com pontos finais de saída para resolução de nomes entre clouds. Consulte a lista de verificação da transição de DNS mais adiante neste artigo para obter orientações passo a passo para a migração.

8. Azure Firewall

Implemente o Azure Firewall num hub virtual seguro para inspecionar todo o tráfego cross-cloud e branch. Cada pacote que passa entre o Azure e a AWS ou o Google Cloud passa pelo firewall para registo e aplicação de políticas. Use regras de rede para padrões de tráfego entre clouds e filtragem de informações sobre ameaças para bloquear destinos maliciosos conhecidos.

Fase 5: Operações

9. Monitorização e observabilidade da rede

Os ambientes multicloud são mais difíceis de diagnosticar e corrigir problemas porque não se controlam os dois extremos de cada ligação. Ative o Observador de Rede do Azure para testes de conectividade, diagnóstico de túnel VPN e captura de pacotes. Monitoriza o tempo de funcionamento do túnel, a latência entre as nuvens e o débito de acordo com os requisitos de capacidade. Defina alertas para desconexões de túneis que afetem a disponibilidade de aplicações cross-cloud.

Artigos condicionais

Inclua estes artigos com base nas suas necessidades específicas:

Condição Artigo Quando incluir
Aplicação voltada para o público Entrada na Internet A sua aplicação migrada está virada para a internet (é necessário acesso público direto)
Aplicação HTTP/HTTPS Firewall de aplicativos Web O WAF da Camada 7 é necessário para aplicações web públicas
É necessária distribuição de camada 7 Entrega e desempenho da aplicação É necessário uma distribuição global ou regional de tráfego após a migração
Pontos finais públicos Proteção DDoS Tem requisitos de disponibilidade para serviços acessíveis ao público
Hub-and-spoke preferencial Topologia de cubo e raio O seu ambiente multicloud é suficientemente pequeno para não justificar a WAN Virtual
Azure multirregião Rede multi-região O seu destino no Azure abrange várias regiões e vai além da conectividade entre clouds
Acesso de administrador de VM Acesso para programadores e administradores Precisa de acesso seguro RDP/SSH às VMs alojadas no Azure
Saída centralizada Acesso de saída à Internet A política centralizada de saída da internet faz parte do seu design-alvo
Ambiente de VNets de grande dimensão Gestão centralizada da rede O ambiente Azure evolui para um ambiente com múltiplas subscrições e sujeito a governação
endpoints privados de PaaS Acesso privado PaaS A sua arquitetura de destino inclui serviços Azure PaaS com endpoints privados

Lista de verificação de descoberta entre nuvens

Antes de desenhar redes Azure, mapeie os seus serviços cloud existentes para equivalentes no Azure. Este mapeamento acelera as decisões de design e previne expectativas desajustadas.

Mapeamento de serviços de AWS para Azure

Serviço do AWS Azure equivalente Notes
Porta de Entrada de Trânsito WAN Virtual do Azure Hub centralizado de encaminhamento para multi-VPC, multirregião e multinuvem
VPC Rede Virtual do Azure Fronteira isolada da rede com sub-redes e tabelas de roteamento
Peering de VPC Emparelhamento VNet Conectividade direta entre duas redes virtuais
Grupos de Segurança Grupos de Segurança de Rede (NSGs) Filtragem de tráfego com estado ao nível da sub-rede ou da interface de rede
ACLs de rede NSGs (nível de sub-rede) Os NSGs do Azure combinam funções tanto do Security Group como das funções NACL
Gateway Privado Virtual Gateway de VPN Ponto de terminação VPN IPSec
Conexão direta Azure ExpressRoute Conectividade privada dedicada (não via internet pública)
Zonas alojadas privadas do Route 53 Zonas de DNS Privado do Azure Resolução de nomes DNS privados em redes virtuais
Tabelas de Rotas Rotas Definidas pelo Utilizador (UDRs) Roteamento personalizado para sobrepor rotas do sistema Azure ou rotas implícitas AWS
Elastic Balanceador de Carga (ALB/NLB) Balanceador de Carga do Azure / Application Gateway Balanceamento de carga L4 e L7; o Application Gateway oferece funcionalidades de WAF semelhantes às do AWS ALB com AWS WAF
AWS WAF Firewall de Aplicações Web do Azure Proteção HTTP/HTTPS da Camada 7
Firewall de Rede Azure Firewall Firewall de rede com monitorização de estado e informações sobre ameaças

Mapeamento de serviços do Google Cloud para Azure

Serviço Google Cloud Azure equivalente Notes
Rede VPC Rede Virtual do Azure Recurso global no Google Cloud; regional no Azure (utilize emparelhamento de VNet entre regiões)
Interligação na Nuvem Azure ExpressRoute Conectividade privada dedicada
Cloud VPN Gateway de VPN Túneis VPN IPSec
Cloud NAT Azure NAT Gateway Acesso de saída à Internet para recursos privados
Cloud Router Azure Route Server Troca dinâmica de rotas BGP com dispositivos virtuais de rede
Armadura de Nuvens Firewall de Aplicações Web do Azure DDoS da Camada 7 e proteção de aplicações
Regras de firewall Grupos de Segurança de Rede Filtragem de tráfego (as regras do Google Cloud são globais; Os NSGs do Azure são por sub-rede ou por NIC)
Zonas Privadas DNS na Cloud Zonas de DNS Privado do Azure Resolução de nomes privados dentro de redes
Centro de Inteligência de Redes Observador de Rede do Azure Monitorização da rede, diagnóstico e visualização de topologia

Lista de verificação da transição de DNS

O DNS cutover é o passo de maior risco na migração entre cloud. Siga esta lista de verificação para minimizar falhas de resolução durante a transição.

Antes da migração

  1. Valores TTL (Time to Live) mais baixos em todos os registos DNS que mudam. Defina o TTL para 60–300 segundos pelo menos 48 horas antes do corte. Este passo garante que os caches expiram rapidamente quando atualiza os registos.
  2. Documente todos os registos DNS que apontem para a infraestrutura que está a migrar: registos A para servidores, registos CNAME para serviços, registos MX para correio e registos SRV para descoberta de serviços.
  3. Configure o DNS do Azure Private Resolver com endpoints de saída no seu Azure VNet. Este resolvedor encaminha as consultas das zonas alojadas na AWS ou Google Cloud para os servidores DNS a montante apropriados durante o período de coexistência.
  4. Teste a resolução direta e reversa dos VNets do Azure para nomes alojados na AWS/Google Cloud antes de migrar qualquer carga de trabalho.

Durante a migração

  1. Atualize os registos CNAME para serviços que migram para o Azure. Apontar CNAMEs para os endpoints do Azure Front Door, Gestor de Tráfego do Azure ou Gateway de Aplicação do Azure à medida que cada serviço migra.
  2. Atualize os registos do host A dos servidores individuais que migram. Substitua os endereços IP da AWS ou Google Cloud por endereços IP privados do Azure nas suas zonas DNS.
  3. Mantenha o reencaminhamento condicional ativo para que os nomes nas zonas que ainda não migrou continuem a ser resolvidos através dos servidores DNS da nuvem original.

Após a migração

  1. Verifique a resolução a partir de todas as localizações: clientes locais, VNets Azure e quaisquer cargas de trabalho restantes da AWS ou Google Cloud devem resolver corretamente os nomes migrados.
  2. Eleve os valores TTL de volta para níveis de produção (3.600 segundos ou mais) depois de confirmar a resolução estável.
  3. Remover os encaminhadores condicionais para zonas que foram totalmente migradas para DNS do Azure. Mantenha os forwarders apenas para zonas que permanecem na AWS ou Google Cloud.

O que construíste

Ao seguir este percurso de leitura, estabeleceu a ligação do Azure ao seu ambiente AWS ou Google Cloud existente com tráfego encriptado, inspeção centralizada por firewall e conectividade monitorizada. O seu design inclui:

  • Descoberta de topologia multicloud e mapeamento de serviços
  • WAN Virtual ou arquitetura de trânsito hub-and-spoke
  • Túneis VPN IPSec para AWS e Google Cloud
  • Azure Firewall para inspeção de tráfego entre clouds
  • Migração de DNS com o Private Resolver para resolução de nomes entre clouds
  • Monitorização do Observador de Rede para o estado de funcionamento e desempenho do túnel

Passos seguintes

  • Last updated on