Topologia de rede simples de carga de trabalho única

Uma rede simples é a topologia de rede Azure mais simples: uma rede virtual com várias sub-redes que hospedam uma única carga de trabalho. Este artigo explica quando usar esse padrão e como implementá-lo.

O que este artigo aborda

Este artigo descreve a topologia de rede Azure mais simples: uma única rede virtual com várias sub-redes que hospeda uma carga de trabalho. Use esse padrão quando você tiver um único aplicativo gerenciado por uma equipe e não precisar de serviços compartilhados, como um firewall central ou um gateway de VPN.

Quem precisa deste artigo

Leia este artigo se:

  • Você está implantando sua primeira carga de trabalho em Azure.
  • Uma única equipe possui e opera todos os recursos.
  • Você não precisa de serviços de rede compartilhados (firewall, Bastion, gateway) em várias cargas de trabalho.
  • Você deseja a rede mais simples que ainda fornece isolamento e segurança no nível da sub-rede.

Foco em migração direta: uma única VNet plana com uma sub-rede por componente costuma ser o primeiro passo certo para realocar uma carga de trabalho em uma região.

Foco na modernização: Use uma rede plana para um piloto inicial de PaaS ou uma única carga de trabalho modernizada e projete suas sub-redes para que ela possa evoluir sem dificuldades para uma arquitetura hub-and-spoke quando você adicionar serviços compartilhados ou uma segunda região.

Foco em nuvem cruzada: use uma VNet plana como um ponto de apoio único no Azure durante a migração entre nuvens: primeiro, implemente a carga de trabalho e, em seguida, planeje seu espaço de endereçamento e segmentação para que ela possa ingressar em um hub ou WAN Virtual à medida que o projeto amadurece.

Azure serviços e recursos

A topologia de rede simples usa estes principais serviços de Azure:

Service Função nessa topologia
Rede Virtual do Azure Fornece um espaço de endereço privado e isolado para sua carga de trabalho. Uma rede virtual está restrita a uma única região do Azure.
Sub-redes + NSGs (Grupos de Segurança de Rede) Sub-redes separam as camadas de aplicativos. Os NSGs filtram o tráfego de entrada e saída em cada limite de sub-rede. Os NSGs são stateful: o tráfego de retorno para conexões permitidas é automaticamente autorizado.
Zona Azure DNS privado Fornece resolução interna de nomes para recursos dentro da rede virtual. Vincule a zona com o registro automático habilitado para que as VMs obtenham automaticamente registros DNS.
Sub-rede de gateway(opcional) Hospeda um gateway VPN ou ExpressRoute se precisar de uma única conexão com uma rede local.

Como escolher: manter a topologia plana ou migrar para uma topologia hub-and-spoke?

Use a tabela de decisão a seguir para determinar se a topologia plana é apropriada para o seu ambiente ou se você deve adotar uma topologia hub-and-spoke.

Condition Recommendation
Carga de trabalho única, equipe única, sem serviços compartilhados Mantenha-se simples: este artigo se aplica
Uma segunda carga de trabalho independente precisa de seu próprio isolamento de rede Migrar para uma topologia hub-and-spoke
Você precisa de um firewall, gateway de VPN ou Azure Bastion compartilhado entre várias cargas de trabalho Migrar para uma topologia hub-and-spoke
As políticas de segurança devem ser gerenciadas centralmente em várias cargas de trabalho Migrar para uma topologia hub-and-spoke

Tip

Se você prevê adicionar uma segunda carga de trabalho nos próximos seis a 12 meses, considere adotar uma arquitetura hub-and-spoke desde o primeiro dia. A sobrecarga é mínima porque você adiciona apenas uma rede virtual extra e uma conexão de emparelhamento. Essa abordagem evita uma migração disruptiva mais tarde.

Considerações sobre o design

Foco no design de rede plana com migração direta

  • Use uma VNet com uma sub-rede para cada componente do aplicativo (web, aplicativo e dados) para espelhar uma arquitetura local típica de três camadas com o mínimo de redesenho.
  • Aplicar Grupos de Segurança de Rede (NSGs) entre sub-redes para recriar sua segmentação existente e manter o espaço de endereços alinhado com os intervalos locais para evitar sobreposição.
  • Mantenha uma arquitetura plana enquanto uma única equipe for responsável pela carga de trabalho e você não precisar de serviços compartilhados de firewall, gateway ou Bastion.
  • Planeje a migração para a arquitetura hub-and-spoke antes de adicionar uma segunda carga de trabalho, para que os serviços compartilhados sejam alocados em um hub, em vez de terem de ser adaptados depois.

Modernize o foco no design de redes planas

  • Use uma rede simples para um piloto de PaaS inicial ou uma única carga de trabalho modernizada: coloque as camadas de aplicativo em sub-redes e alcance Azure PaaS por meio de pontos de extremidade privados em uma sub-rede dedicada.
  • Reservar sub-redes dedicadas antecipadamente para os serviços de plataforma que você adicionará, como Gateway de Aplicativo e pontos de extremidade privados, para que a rede cresça sem a necessidade de reendereçamento.
  • Aplicar NSGs e grupos de segurança de aplicativos por camada para que sua segmentação já esteja implementada caso a carga de trabalho se torne posteriormente um spoke em um design hub-and-spoke.
  • Mantenha o espaço de endereços sem sobreposição com suas outras regiões e VNets para que você possa interconectar ou migrar para um hub posteriormente sem renumerar.

Foco no design de rede plana entre nuvens

  • Use uma VNet plana como um único ponto de apoio no Azure durante a migração entre nuvens: implante primeiro a carga de trabalho e, em seguida, anexe a conectividade de um hub à medida que a arquitetura evolui.
  • Planeje o espaço de endereços da VNet plana para evitar sobreposição com as VPCs da AWS e as redes do Google Cloud, para que ela possa se conectar ao IPsec ou ao roteamento de interconexão posteriormente, sem tradução.
  • Mantenha a segmentação de camadas com NSGs para que a postura de segurança da carga de trabalho seja mantida quando ela se tornar um spoke atrás de um hub WAN Virtual seguro.
  • Padronizar a nomenclatura e a marcação de sub-rede para corresponder às outras nuvens para que a carga de trabalho permaneça fácil de correlacionar durante e após a migração.

Pré-requisitos

Antes de implementar essa topologia:

  • Uma assinatura Azure com permissões para criar redes virtuais e NSGs.
  • Um espaço de endereço IP planejado. Um espaço de endereço /16 fornece 65.536 endereços, que é um ponto de partida comum para uma única carga de trabalho. Azure reserva cinco endereços por sub-rede para uso interno. Para obter diretrizes detalhadas, consulte o endereçamento IP do plano.
  • Uma compreensão das camadas de aplicativo (por exemplo, Web, aplicativo e dados) para que você possa mapeá-las para sub-redes. Para obter orientações para o design de sub-redes, consulte Projetar redes virtuais e sub-redes.

Layout de rede

Diagrama mostrando uma topologia de rede simples com sub-redes web, aplicativo e camada de dados, cada uma protegida por um NSG, em uma única rede virtual.

Uma topologia de rede simples segue esta estrutura:

  • Uma rede virtual com um único espaço de endereço (por exemplo, 10.0.0.0/16).
  • Várias sub-redes: uma por camada de aplicativo ou componente:
    • Sub-rede da camada web (por exemplo, 10.0.1.0/24).
    • Sub-rede da camada de aplicativo (por exemplo, 10.0.2.0/24).
    • Sub-rede da camada de dados (por exemplo, 10.0.3.0/24).
    • Sub-rede do gateway (opcional, por exemplo, 10.0.255.0/27).
  • NSGs anexados a cada sub-rede com regras que permitam apenas o tráfego necessário para cada camada.
  • Uma zona DNS privada vinculada à rede virtual com o registro automático habilitado.

Note

Planeje os intervalos de endereços IP com cuidado. Se você migrar posteriormente para uma topologia hub-and-spoke, as redes virtuais spoke devem ter intervalos CIDR não sobrepostos com o hub. Escolher um esquema de endereço bem estruturado agora impede conflitos durante a migração.

Considerações de segurança

Aplique estas práticas de segurança à sua rede simples:

  • NSGs em cada sub-rede. Comece com uma configuração base que bloqueie todo o tráfego de entrada e adicione regras específicas de permissão para o tráfego legítimo entre as camadas. Por exemplo, permita HTTPS da camada Da Web para a camada de aplicativo e permita o SQL da camada de aplicativo para a camada de dados.
  • Sem IPs públicos diretamente nas VMs. Expor serviços por meio de um balanceador de carga ou Application Gateway. Use Azure Bastion para acesso administrativo.
  • DNS privado para resolução interna. Zonas DNS privadas evitam que nomes de host internos sejam expostos por meio de consultas DNS públicas.
  • Isolamento da sub-rede do gateway. Se você adicionar um gateway VPN ou ExpressRoute, coloque-o em uma sub-rede dedicada (chamada GatewaySubnet). NSGs na sub-rede do gateway não têm suporte. Associar um NSG a essa sub-rede pode fazer com que o gateway de rede virtual pare de funcionar conforme o esperado.

Importante

Quando você remove uma regra NSG que permite uma conexão, as conexões ativas existentes continuam ininterruptas. Somente novas conexões que correspondem à regra removida são bloqueadas.

Os artigos a seguir fornecem diretrizes mais profundas sobre tópicos relacionados:

Saiba mais

Para obter mais informações sobre os serviços de Azure usados nesta topologia, consulte:

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:

Projete sua topologia em estrela: a maioria das migrações de "lift-and-shift" rapidamente ultrapassa a capacidade de uma rede plana. Planeje serviços compartilhados centralizados desde o início.

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

Projete sua topologia em estrela: cargas de trabalho modernizadas com múltiplos serviços, controles de segurança e equipes precisam de uma topologia em estrela desde o primeiro dia.

A seguir, em sua jornada multinuvem:

Planeje sua arquitetura de conectividade multinuvem: ambientes entre nuvens exigem uma arquitetura de trânsito, não redes planas. Crie seu modelo de conectividade multinuvem.

  • Last updated on