Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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
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.
Artigos relacionados
Os artigos a seguir fornecem diretrizes mais profundas sobre tópicos relacionados:
- Criar redes virtuais e sub-redes: dimensionamento e posicionamento de sub-rede para suas camadas de carga de trabalho
- Planejamento do endereçamento IP: planejamento do espaço de endereços e seleção de CIDR
- Projetando grupos de segurança de rede: design de regras de NSG e grupos de segurança de aplicativo
- Topologia em estrela: a próxima topologia a ser adotada quando sua rede crescer
- Proteção contra DDoS: se sua carga de trabalho expõe endpoints públicos
Saiba mais
Para obter mais informações sobre os serviços de Azure usados nesta topologia, consulte:
- O que é uma rede virtual Azure?
- Visão geral de grupos de segurança de rede
- O que é Azure DNS privado?
- Planejamento de rede virtual
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.