O domínio de redes do AZ-104 corresponde a 15–20% do exame completo. Os tópicos centrais são configuração de VNet, segurança, DNS e balanceamento de carga. A terminologia pode parecer estranha no início, mas, uma vez que você entende cada conceito por meio de analogias do mundo real, se torna muito mais simples do que imagina.
VNet e Sub-redes
O que é uma VNet?
Uma VNet (Virtual Network) permite criar sua própria rede privada dentro do Azure. Em termos simples, é como construir um prédio de escritórios exclusivo para a sua empresa dentro da vasta nuvem Azure. Dentro do prédio, os funcionários internos podem se comunicar livremente entre si, mas pessoas de fora não podem entrar como quiserem.
Ao criar uma VNet, você define um espaço de endereçamento (CIDR). Especificar , por exemplo, define o intervalo de endereços internos que aquele prédio pode usar — semelhante a definir o esquema de numeração dos quartos do prédio inteiro.
As sub-redes são o conceito de dividir esse prédio andar por andar. Você pode zonear por finalidade: o 1º andar para servidores web, o 2º para bancos de dados e o 3º para sistemas de gerenciamento. Dividir assim permite aplicar regras de segurança diferentes por andar e isolar uma zona específica quando surge um problema, tornando o gerenciamento muito mais conveniente.
VNet Peering: Um Corredor Dedicado Conectando Dois Prédios
À medida que o negócio cresce, pode haver um prédio em Seul e outro em Busan. Como eles se comunicam? Usar a internet pública é lento e expõe a riscos de segurança. O VNet Peering cria um corredor dedicado entre duas VNets pela rede backbone interna do Azure — sem internet, portanto rápido e seguro.
Existem dois tipos de VNet Peering:
Peering local: Conecta duas VNets dentro da mesma região do Azure (ex.: Coreia Central). Como conectar dois escritórios na mesma cidade com uma linha dedicada. Peering global: Conecta VNets em regiões diferentes (ex.: Coreia Central e Leste dos EUA). Como conectar uma sede em Seul com uma filial em Nova York por meio de uma linha dedicada internacional.
Característica fundamental: Não transitividade
Há uma regra sobre VNet Peering que você deve lembrar: ele é não transitivo. Veja um exemplo para explicar o que isso significa.
Suponha que o Prédio A e o Prédio B estão conectados por um corredor dedicado, e que o Prédio B e o Prédio C também estão conectados por um corredor dedicado. Você consegue ir do Prédio A, passando pelo Prédio B, até chegar ao Prédio C? Não. O VNet Peering representa apenas uma conexão direta entre duas VNets. Para que A e C se comuniquem, você deve configurar um Peering A↔C separado. Essa regra é cobrada com frequência no exame.
UDR (Rota Definida pelo Usuário): Você Decide o Caminho do Tráfego
Por padrão, o Azure determina automaticamente o caminho ideal para que o tráfego chegue ao seu destino. No entanto, por razões de segurança, você pode precisar forçar todo o tráfego a passar por um ponto de verificação específico. Por exemplo, se quiser que todo o tráfego externo passe por uma NVA (Network Virtual Appliance) atuando como firewall, você usa uma UDR.
Uma UDR (User Defined Route) substitui as regras de roteamento padrão do Azure e permite especificar exatamente qual caminho o tráfego deve seguir. É como exigir que os veículos em uma rodovia passem por um pedágio (NVA) em um trecho específico. Isso permite inspecionar todo o tráfego e bloquear pacotes suspeitos.
Segurança de Rede
NSG (Network Security Group): O Segurança do Prédio
Um NSG é como um segurança para a sua rede. Ele define regras sobre quem pode entrar (entrada) e quem pode sair (saída). Essas regras podem ser aplicadas a uma sub-rede inteira ou à interface de rede (NIC) de uma VM individual.
Por exemplo, na sub-rede que hospeda servidores web você poderia criar uma regra que diz: "permitir apenas tráfego na porta 80 (HTTP) e na porta 443 (HTTPS) vindo de fora; bloquear todo o resto."
Entendendo as Regras de Prioridade
As regras do NSG têm números de prioridade. Quanto menor o número, mais cedo ela é avaliada. Se uma regra com prioridade 100 e uma regra com prioridade 1000 conflitam, a regra com prioridade 100 é aplicada primeiro.
É como um segurança lendo um manual de instruções de trabalho onde o item 1 é verificado antes do item 10. Ao colocar regras de permissão em alta prioridade (números baixos) e regras de negação em baixa prioridade (números altos) — ou vice-versa — você pode exercer um controle granular sobre o tráfego.
Regras Padrão (Não Podem Ser Alteradas)
O Azure inclui automaticamente regras padrão em todos os NSGs: A comunicação dentro do VNet é permitida O tráfego de saída para a internet é permitido Todo o restante do tráfego de entrada é bloqueado
Essas regras padrão não podem ser excluídas, mas você pode substituí-las adicionando regras com número mais baixo (maior prioridade).
ASG (Application Security Group): Gerencie por Função, Não por IP
O que acontece quando você tem 10 ou 20 servidores? Especificar o endereço IP de cada servidor individualmente nas regras do NSG torna-se muito complexo. Quando o IP de um servidor muda, é preciso atualizar todas as regras também.
O ASG (Application Security Group) resolve esse problema. Ele agrupa VMs em grupos lógicos por função, de modo que as regras do NSG podem referenciar o nome do grupo em vez de endereços IP.
Por exemplo, agrupe 10 servidores web em um ASG chamado 'WebServers' e 5 servidores de banco de dados em um ASG chamado 'DatabaseServers'. Em seguida, defina a regra do NSG como "permitir a porta 1433 de WebServers para DatabaseServers." Assim, quando um servidor é adicionado ou seu IP muda, basta adicioná-lo ao ASG — não é necessário modificar as regras do NSG em si. É como gerenciar permissões de acesso pelo nome do departamento ('Equipe de Vendas', 'Equipe de Desenvolvimento') em vez de por listas individuais de funcionários.
!NSG vs ASG
Azure Bastion: Acesse VMs com Segurança Sem um IP Público
Normalmente, para se conectar a um servidor remotamente ele precisa de um IP público, e é preciso abrir RDP (porta 3389) ou SSH (porta 22) para a internet. Fazer isso dá aos hackers um alvo persistente para atacar.
O Azure Bastion resolve esse problema por completo. Mesmo sem atribuir um IP público à VM, você pode acessá-la com segurança por meio de um navegador web no portal do Azure. Não é necessário expor portas RDP ou SSH à internet.
Por analogia: em vez de divulgar publicamente o número do seu escritório na entrada do prédio, todos os visitantes são escoltados para o interior apenas por meio de uma recepção com segurança rígida (Bastion). Pessoas de fora nunca descobrem um número de sala específico — elas sempre precisam passar pela recepção.
Service Endpoint vs. Private Endpoint: Duas Formas de Conectar-se Privadamente
Ao acessar serviços do Azure como Azure Storage ou SQL Database, os recursos dentro de um VNet podem se conectar de forma mais segura e eficiente de duas maneiras.
Um Service Endpoint otimiza o caminho de um VNet até um serviço do Azure. O tráfego se move pela rede interna do Azure em vez da internet. No entanto, o serviço do Azure ainda possui um endereço IP público. Por analogia: em vez de pegar uma estrada comum até o aeroporto, você usa uma rodovia expressa exclusiva. Mais rápido e com menos tráfego, mas o aeroporto em si continua sendo um lugar público.
Um Private Endpoint vai um passo além. Ele atribui um endereço IP privado de dentro do seu VNet diretamente ao serviço do Azure. O serviço agora se comporta como se fosse um recurso dentro do seu VNet. Não é possível acessá-lo pela internet — apenas de dentro do VNet. Por analogia: uma sala VIP específica do aeroporto se mudou fisicamente para dentro do prédio da sua empresa. É acessível apenas a partir do interior.
Em resumo: Service Endpoint: Usa endereço IP público, mas o caminho é otimizado (rápido e simples) Private Endpoint: Atribui um IP privado, completamente isolado (mais seguro, mais complexo)
!Service Endpoint vs Private Endpoint
DNS
Por que Precisamos de DNS?
O DNS (Domain Name System) é como a lista telefônica da internet. Quando digitamos um endereço como , ele é convertido para um endereço IP numérico como para a comunicação. O DNS cuida dessa conversão.
Azure Public DNS: Gerencie Seu Domínio no Azure
O Azure Public DNS permite gerenciar registros DNS de um domínio que sua empresa possui (ex.: ) no Azure. Ele suporta vários tipos de registros DNS: registros A (domínio → endereço IP), registros CNAME (alias de domínio), registros MX (servidor de e-mail), registros TXT (verificação de titularidade do domínio) e outros.
Por exemplo, para apontar para o IP público de uma VM específica do Azure, crie um registro A. Para apontar para , crie um registro CNAME.
Azure Private DNS: Uma Lista Telefônica Interna Usada Somente Dentro do VNet
As VMs dentro de um VNet se comunicam usando IPs internos. Mas memorizar endereços IP é inconveniente, e gerenciá-los torna-se difícil quando VMs são adicionadas ou IPs mudam. Uma Azure Private DNS Zone é um sistema DNS interno utilizado exclusivamente dentro de um VNet.
Por exemplo, crie uma Private DNS Zone e vincule-a a um VNet. As VMs nesse VNet poderão encontrar umas às outras usando nomes como . Esse nome DNS não resolve nada na internet pública — funciona apenas dentro do VNet.
O recurso de registro automático é especialmente prático. Quando uma VM é criada no VNet, seu nome e IP são registrados automaticamente no Private DNS. Não é necessário criar registros DNS manualmente. É como um novo funcionário ser registrado automaticamente na lista telefônica da empresa no primeiro dia.
Você também pode vincular múltiplos VNets a uma única Private DNS Zone, mantendo um esquema de nomenclatura DNS interno consistente em vários VNets.
Azure Load Balancer: Um Diretor de Tráfego que Distribui o Trabalho de Forma Equitativa
À medida que um serviço cresce, uma única VM não consegue lidar com toda