Trilha de design de rede multicloud

Este guia fornece uma sequência de leitura pelo Guia de Design de Rede do Azure para clientes que conectam o Azure à Amazon Web Services (AWS), ao Google Cloud ou que migram cargas de trabalho de outro provedor de nuvem. Siga as etapas numeradas para criar conectividade segura e monitorada entre Azure e sua infraestrutura de nuvem existente.

Por que a descoberta vem primeiro

A conectividade entre nuvens conecta o Azure a um ou mais ambientes de nuvem externos. Você pode executar cargas de trabalho no AWS ou no Google Cloud que precisam de conectividade privada para Azure serviços ou pode migrar aplicativos de outra nuvem para Azure mantendo a conectividade com aplicativos que permanecem para trás. De qualquer forma, sua rede Azure deve se integrar à infraestrutura que você não controla totalmente do outro lado.

Esse caminho de leitura começa com a fase de descoberta, em vez do design da infraestrutura do Azure. Você mapeia sua topologia multinuvem existente primeiro (entendendo o que é executado onde, como ele se conecta e qual tráfego flui entre nuvens) antes de projetar o lado Azure. Essa abordagem que prioriza a descoberta evita retrabalho: se você projetar a rede no Azure sem entender a topologia da AWS ou do Google Cloud, corre o risco de enfrentar conflitos de endereços IP, falhas de conectividade e pontos cegos de segurança.

Sua arquitetura de destino usa o Azure Virtual Wide Area Network (WAN) como hub de trânsito (o equivalente no Azure ao AWS Transit Gateway), com túneis VPN IPSec para o AWS Virtual Private Gateway e o Google Cloud VPN. Firewall do Azure em um hub virtual seguro inspeciona todo o tráfego entre nuvens e ramificações. O DNS requer um planejamento cuidadoso da transição para manter o funcionamento da resolução de nomes entre os limites da nuvem 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 de Azure disponíveis.
• Descoberta completa de topologia dos ambientes do AWS e do Google Cloud:
  • AWS: execute o Hub de Migração do AWS ou a Descoberta de Carga de Trabalho no AWS para inventariar VPCs (Nuvens Virtuais Privadas), Gateways de Trânsito e conectividade entre VPC.
  • Google Cloud: use a Central de Inteligência de Rede para mapear redes VPC, anexos de interconexão de nuvem e regras de firewall.
• Documente fluxos de tráfego entre nuvens: quais aplicativos se comunicam entre nuvens, largura de banda necessária, sensibilidade de latência e requisitos de criptografia.
• Crie um inventário de intervalos de endereços IP em todas as três nuvens para identificar sobreposições.

Seu caminho de leitura

As fases a seguir orientam você pelo design de rede entre nuvens em sequência.

Fase 1: Descoberta

Comece com a descoberta. Entenda seu cenário multinuvem antes de projetar Azure infraestrutura.

1. Conectividade entre regiões e várias nuvens

Este artigo é seu ponto central para decisões de projeto. Mapeie sua topologia multinuvem: quais VPCs do AWS e VPCs do Google Cloud precisam de conectividade para Azure, quais fluxos de tráfego entre nuvens e qual padrão de arquitetura se ajusta à sua escala. Use o mapeamento de serviços entre provedores de nuvem (Gateway de Trânsito para WAN Virtual, Grupos de Segurança para Grupos de Segurança de Rede, Emparelhamento VPC para Emparelhamento VNet) para traduzir seu design existente para os termos do Azure.

2. WAN Virtual do Azure

WAN Virtual é o modelo de trânsito recomendado quando há várias VPCs, filiais, regiões ou bordas da nuvem. O WAN Virtual fornece o equivalente no Azure ao AWS Transit Gateway: roteamento automatizado, segurança centralizada e escalabilidade multifilial e multirregional. Avalie se a sua propriedade entre nuvens justifica o uso da WAN Virtual ou se um hub e spoke mais simples com o Gateway de VPN é suficiente.

Fase 2: Fundações

3. Redes virtuais e sub-redes

Projete sua VNet Azure como a zona de destino para cargas de trabalho migradas ou conectadas. Mapeie os conceitos de AWS VPC e Google Cloud VPC da seguinte forma: as sub-redes de VPC se tornam sub-redes do Azure, as zonas de disponibilidade correspondem às zonas de disponibilidade do Azure e as tabelas de rotas seguem padrões semelhantes. Concentre-se no dimensionamento de sub-rede para as cargas de trabalho que chegam ao Azure.

4. Planejamento de endereço IP

Planeje o espaço de endereço não sobreposto entre as três nuvens. Esta etapa é essencial para conectividade entre nuvens: se seus intervalos de VNet Azure se sobrepõem com intervalos de VPC do AWS ou intervalos de VPC do Google Cloud, você não poderá estabelecer túneis VPN entre eles. Documente cada bloco CIDR em uso em todos os ambientes antes de alocar espaço de endereços do Azure.

5. Grupos de segurança de rede e grupos de segurança de aplicativos

Espelhe os Grupos de Segurança da AWS e as regras de firewall do Google Cloud como Grupos de Segurança de Rede (NSGs) do Azure. Traduza as regras de permissão e negação existentes no formato NSG. Use os ASGs (Grupos de Segurança de Aplicativo) para replicar o agrupamento baseado em tags que as referências dos Grupos de Segurança da AWS oferecem.

Fase 3: Conectividade

6. Conectividade híbrida

Configure túneis VPN IPSec entre Azure e a AWS ou o Google Cloud para o trânsito criptografado entre nuvens. Conecte o Gateway de VPN do Azure (ou as conexões VPN do WAN Virtual) ao AWS Virtual Private Gateway e ao Google Cloud VPN. Escolha a largura de banda do túnel com base nas suas necessidades de tráfego entre nuvens. Planeje túneis redundantes para evitar pontos únicos de falha.

Fase 4: Segurança

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

Planeje sua estratégia de substituição de DNS antes de migrar cargas de trabalho. Os aplicativos na AWS ou no Google Cloud resolvem nomes de host que podem precisar apontar para o Azure após a migração. Configure o Resolvedor Privado de DNS do Azure com pontos de extremidade de saída para resolução de nomes entre nuvens. Consulte a lista de verificação de substituição de DNS mais adiante neste artigo para obter diretrizes de migração passo a passo.

8. Firewall do Azure

Implante Firewall do Azure em um hub virtual seguro para inspecionar todo o tráfego entre nuvens e ramificações. Cada pacote que atravessa entre Azure e a AWS ou o Google Cloud passa pelo firewall para registro em log e imposição de políticas. Use regras de rede para padrões de tráfego entre nuvens e filtragem de inteligência contra ameaças para bloquear destinos mal-intencionados conhecidos.

Fase 5: Operações

9. Monitoramento de rede e observabilidade

Ambientes multinuvem são mais difíceis de diagnosticar porque você não controla as duas pontas de cada conexão. Habilite Observador de Rede do Azure para teste de conectividade, diagnóstico de túnel VPN e captura de pacotes. Monitore o tempo de atividade do túnel, a latência entre nuvens e a taxa de transferência em relação aos requisitos de capacidade. Defina alertas para desconexões de túnel que afetam a disponibilidade de aplicativos entre nuvens.

Artigos condicionais

Inclua estes artigos com base em seus requisitos específicos:

Lista de verificação de descoberta entre nuvens

Antes de projetar Azure rede, mapeie seus serviços de nuvem existentes para Azure equivalentes. Esse mapeamento acelera as decisões de design e impede expectativas incompatíveis.

Mapeamento de serviços da AWS para o Azure

Mapeamento de serviços do Google Cloud para o Azure

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

A substituição de DNS é a etapa de maior risco na migração entre nuvens. Siga esta lista de verificação para minimizar falhas de resolução durante a transição.

Antes da migração

1. Valores de Vida Útil (TTL) mais baixos em todos os registros DNS que forem alterados. Defina o TTL como 60–300 segundos pelo menos 48 horas antes da transição. Esta etapa garante que os caches expirem rapidamente quando você atualiza os registros.
2. Documente todos os registros DNS que apontam para a infraestrutura que você está migrando: um registro para servidores, registros CNAME para serviços, registros MX para email e registros SRV para descoberta de serviço.
3. Configure o Resolvedor Privado de DNS do Azure com pontos de extremidade de saída na sua VNet do Azure. Esse resolvedor encaminha consultas para zonas hospedadas no AWS/Google Cloud para os servidores DNS upstream apropriados durante o período de coexistência.
4. Teste a resolução direta e reversa das VNets do Azure para nomes hospedados na AWS/no Google Cloud antes de migrar quaisquer cargas de trabalho.

Durante a migração

5. Atualize os registros CNAME para serviços que passam para Azure. Aponte os CNAMEs para pontos de extremidade do Azure Front Door, do Gerenciador de Tráfego do Azure ou do Gateway de Aplicativo do Azure, conforme cada serviço migra.
6. Atualize os registros do host A para servidores individuais que migram. Substitua os endereços IP da AWS ou do Google Cloud por endereços IP privados do Azure em suas zonas DNS.
7. Mantenha o encaminhamento condicional ativo para que nomes em zonas que você não migrou ainda continuem sendo resolvidos por meio dos servidores DNS da nuvem original.

Depois da migração

8. Verifique a resolução de todos os locais: clientes locais, Azure VNets e quaisquer cargas de trabalho restantes do AWS ou do Google Cloud devem resolver os nomes migrados corretamente.
9. Aumente os valores de TTL de volta aos níveis de produção (3.600 segundos ou mais) depois de confirmar a resolução estável.
10. Remova os encaminhadores condicionais para zonas que são totalmente migradas para DNS do Azure. Mantenha os encaminhadores apenas para zonas que permanecem na AWS ou no Google Cloud.

O que você criou

Seguindo este caminho de leitura, você conectou Azure ao ambiente existente do AWS ou do Google Cloud com trânsito criptografado, inspeção centralizada de firewall e conectividade monitorada. Seu design inclui:

• Descoberta de topologia multinuvem e mapeamento de serviço
• Arquitetura de trânsito com WAN Virtual ou hub e spoke
• Túneis DE VPN IPSec para a AWS e o Google Cloud
• Firewall do Azure para inspeção de tráfego entre nuvens
• Transição do DNS com Resolvedor Privado para resolução de nomes entre nuvens
• Monitoramento da integridade e do desempenho do túnel no Observador de Rede

Próximas Etapas 

• Caminho de rede lift-and-shift: se você também tiver cargas de trabalho locais migrando diretamente para a IaaS do Azure
• Abordagem de rede para migração e modernização: se sua implantação no Azure adota serviços PaaS e contêineres
• Fases do projeto em visão geral: Para o resumo genérico baseado em fases do projeto de rede do Azure
• Visão geral do planejamento e design de rede do Azure: para exploração baseada em recursos de todos os serviços disponíveis