que é uma rede virtual do Azure. A maioria das pessoas ouve esse termo e pensa que é apenas mais uma configuração que você ativa ao implantar uma máquina virtual, algo que você marca em uma caixa e depois esquece. Mas aqui está a verdade. Uma rede virtual do Azure não é apenas uma configuração. Ela é a base de tudo que você constrói no Azure. Cada máquina virtual, cada banco de dados, cada serviço de aplicativo, cada função que você implanta, todos eles ficam dentro de um. E se você não entender como elas funcionam, estará voando às cegas. Ao final deste episódio, você entenderá o que é realmente uma VNet, como ela funciona e por quê. Cada recurso que você implanta depende dela. Abordaremos o que é uma VNet, como funcionam os endereços IP, subredes, segurança, roteamento e como conectar VNets entre si. Pegue seu café e vamos começar. O que é uma VNet? A rede de nuvem privada. Vamos começar com a definição mais simples.

Uma rede virtual do Azure, ou VNet para abreviar, é só a própria rede privada dentro do Azure. Pense nela como um prédio de escritórios privados. Somente as pessoas se permitem por dentro. Você controla quem passa pela porta, quem chega a qual andar e quem fica totalmente de fora. Antes de as VNets existirem, as coisas eram diferentes. Implante uma máquina virtual na nuvem. Ela ficava basicamente exposta à internet por padrão. Sem rede privada ao redor dela. Qualquer pessoa que soubesse o endereço IP poderia tentar se conectar. Isso era um pesadelo de segurança. O que mudou? O Azure deu a você a capacidade de criar espaços de rede privados isolados. Você define um limite. Você decide o que entra nele. Nada fora desse limite pode entrar, menos que você permita explicitamente. Uma coisa para saber de antemão, sua VNet reside em uma região específica do Azure. Ela não é global. Crie uma VNet no oeste da Europa e é lá que ela permanece.

Recursos em uma região diferente não podem simplesmente entrar nele. Eles precisariam de sua própria VNet ou você precisaria conectá-los mais tarde. Ao criar uma VNet, você mesmo define o espaço de endereçamento IP. O Azure não escolhe por você. Você decide o intervalo de endereços IP que seus recursos usarão. Essa é uma grande responsabilidade e falaremos sobre como fazer isso corretamente na próxima sessão. Aqui está o ponto principal. As VNets são a base. Cada máquina virtual, cada banco de dados, cada função do Azure que você implanta fica dentro de uma. Sem uma VNet, seus recursos não têm contexto de rede privada. Eles ficam apenas flutuando na nuvem, sem limite, sem isolamento, sem segurança. Então, o que isso significa para você? Se você está criando algo no Azure, comece primeiro com uma VNet. Não depois de implantar seus recursos, mas antes. Sua VNet é o terreno onde você está construindo.

Você não construiu uma casa sem comprar o terreno antes, certo? Uma ideia. Endereçamento IP e CDR escolhendo seu espaço de endereço. Então, vamos começar. Ao criar uma VNet, a primeira grande decisão é escolher um intervalo de IP. Você faz isso usando a anotação CDR. CDR é a sigla para Classless Inter-Domain Routing, mas tudo que isso realmente significa que você está dizendo, eu preciso desta quantidade de endereços IP. Por que isso importa? Porque o intervalo que você escolhe determina quantos recursos você pode comportar na sua rede virtual. Veja como funciona. O CDR usa uma barra e um número como 16 ou 24. Esse número indica o tamanho do espaço de endereço. Um 16 oferece cerca de 65 mil endereços IP. Isso é muito. Um 24 oferece cerca de 250, o que é perfeito para uma pequena equipe ou uma única camada de aplicativo. Portanto, ao projetar sua VNet, você precisa pensar em quantos recursos terá e como deseja aglopá-los.

Agora, você não pode simplesmente escolher qual intervalo de IP. O Azure segue o padrão RFC 1918, que reserva intervalos de IP privados para redes internas. Eu tenho três opções. O intervalo 10.6.x é maior, dando a você bastante espaço para crescer. O intervalo 172.6.1.x é um pouco menor, mas ainda útil. E o intervalo 192.1.x é 700.6.x, o que você provavelmente tem em casa no seu roteador. Aqui estão. O espaço de endereço da sua VNet não pode se sobrepor a nenhuma outra rede a qual você planeja se conectar. Este é um erro comum. Muitas pessoas escolhem um intervalo que parece familiar apenas para descobrir mais tarde que ele entra em conflito com a rede cooperativa. Portanto, se a rede do escritório da sua empresa usa 10.0.0.0.0.6, não use esse mesmo intervalo no Azure. Se você tentar conectá-los mais tarde, eles entrarão em conflito e o tráfego não saberá para onde ir. Deixe-me dar um exemplo concreto.

Imagine que você está criando uma configuração híbrida, onde o Azure se conecta ao seu datacenter local e seu datacenter usa 10.0.0.0.0.0.1.6. Se você criar uma VNet com o mesmo intervalo, terá duas redes disputando os mesmos IPs. Pense nisso. Duas redes usando o mesmo intervalo de IP não conseguem se comunicar adequadamente. É como duas casas com o mesmo endereço. A correspondência fica confusa. Esse é um problema que você não quer resolver depois do fato. Portanto, planeje com antecedência exclusiva. E aqui vai uma dica de planejamento. Escolha um intervalo maior do que você acha que precisa. Você pode achar que só precisará de um B4 agora, mas conforme sua aplicação cresce, desejará ter um B16. Não é fácil alterar isso depois. Depois que sua venete é criada e você implanta recursos, mudar o espaço de endereçamento é complicado. É possível, mas não é algo que você queira fazer em um sistema em produção.

Tanto desse mesmo espara crescer. Isso significa para você. Pense no espaço de endereçamento da sua venete como comprar um terreno. Obtenha o suficiente para o crescimento futuro. Se você acha que precisa de um lote pequeno, compre um médio. Agradecerá a si mesmo mais tempo. Essa é a principal lição. Planeje seu espaço de endereçamento com o crescimento futuro em mente. Subredes dividindo sua rede. Então você tem sua venete e escolheu seu espaço de endereçamento. E agora? Você não pode simplesmente jogar tudo em um único grande público. É aí que entram as subredes. Subredes são um dos blocos de construção fundamentais da sua venete. Elas permitem que você organize e proteja seus recursos. Uma subrede é uma seção menor do espaço de endereçamento da sua venete. Se sua venete é o prédio, as subredes são as salas individuais. Você não colocaria sua sala de servidores, recepção e copa no mesmo espaço aberto, certo?

A mesma ideia é se aplicar. É um conceito simples, mas faz uma enorme diferença em como você gerencia sua rede. Recursos diferentes ficam em subredes diferentes. Seus servidores web ficam em uma subrede. Seus bancos de dados em outra e a lógica da aplicação em uma terceira. Dois motivos. Segurança e organização. Vamos falar de segurança primeiro, porque geralmente é o mais importante. Segurança em primeiro lugar. Se alguém invadir seu servidor web, você não quer que eles tenham acesso direto ao seu banco de dados. Subredes separadas criam uma barreira natural. Invasor teria que cruzar essa fronteira e você pode controlar exatamente o que atravessa. Você também pode usar grupos de segurança de rede para controlar o tráfego entre subredes. Esse é um tópico para outro vídeo, mas é bom saber que as subredes são a base dessa segurança. Organização em segundo. Quando tudo tem seu lugar, o gerenciamento fica mais fácil.

Você sabe qual subrede contém seus recursos de front-end e qual mantém seus dados de back-end? Você pode aplicar políticas e regras a toda a subrede de uma vez, em vez de configurar cada recurso individualmente. Você economiza tempo e reduz erros. Agora aqui está um detalhe que pega as pessoas surpresas. O Azure reserva 5 endereços IP em cada subrede para seus propósitos internos, como roteamento e DNS. Portanto, se você criar uma subrede com um intervalo B24 dando 256 endereços, você na verdade só obtém 251 utilizáveis. Normadia comum. Você planeja 256, mas só obtém 201. Portanto, sempre adicione uma margem a dimensionar sua subrede. Boa notícia é que você pode adicionar subredes após criar a VNet. Você não fica limitado às que configurou durante a criação. Então, se perceber que precisa de uma subrede separada para ferramentas de gestão ou monitoramento, adicione depois. Sem problemas.

Mas ainda é melhor planejá-la de antemão. Adicionar subredes depois é possível, mas talvez precise mover recursos que podem causar interrupções. Mas aqui está a melhor prática. Deide separados para diferentes camadas da sua aplicação desde o início. Pense na arquitetura da sua aplicação. Normalmente, você tem uma camada front-end que lida com requisições, uma back-end que processa a lógica e uma de dados. Cada uma delas deve ter sua própria subrede. Não espere até estar em produção para perceber que precisa separar as coisas. Isso é muito mais difícil quando os recursos já estão implantados. O que isso significa para você? Subredes são a forma de manter sua rede organizada e segura. Elas são como os cômodos do seu prédio. Planeja cedo e dê a cada camada da sua aplicação o seu próprio espaço. É assim que você mantém sua rede limpa e segura. IPs públicos versus privados. Quem pode ver o quê?

Vamos falar sobre endereços IP. Porque nem todos são iguais. Ao implantar um recurso dentro de uma venete, ele recebe um IP privado por padrão. Esse é o endereço que ele usa para falar com outros recursos dentro da venete. Pense nisso como um ramal telefônico interno. Apenas pessoas dentro do prédio conseguem alcançá-lo. IPs privados só são acessíveis de dentro da venete ou de redes conectadas a ela. Se você estiver em casa no seu notebook e não consegue acessar um IP privado no Azure, ele está dentro da sua rede privada. Então, como tornar um recurso alcançável pela internet? Ele atribui um endereço IP público. Esse é o endereço visível para o mundo externo, como ter um número de telefone público em vez de um ramal interno. Aqui está o ponto principal. IPs públicos são opções. Você os atribui explicitamente, pois o Azure nunca dá um IP público aos recursos sem que você peça. Isso é ensinado.

O padrão deve ser privado e o público deve ser uma escolha deliberada. E é aqui que muitos iniciantes cometem um erro. Eles dão IPs públicos para tudo. Seu servidor web, seu banco de dados e sua API de back-end recebem um. Isso é um risco de segurança. Seu banco de dados não precisa ser acessível pela internet e nem sua API de back-end. Somente os recursos de front-end com os quais os usuários interagem devem ter IPs públicos. Bem, os IPs públicos vêm em dois tipos, estático e dinâmico. O IP público estático permanece o mesmo, mesmo que você pare e reinicie o recurso. O IP público dinâmico pode mudar. Se você está executando aplicação de produção, provavelmente quer IPs estáticos para que seus usuários sempre encontrem você. Se você está testando algo, o dinâmico pode ser suficiente. Você também pode usar algo chamado prefixo de IP público, que permite reservar um bloco de endereços. Em vez de criá-los um por um, você reserva uma faixa e atribui endereços individuais a partir dela.

Útil se você sabe que precisará de vários IPs públicos para um projeto. Isso significa para você, IPs privados são um padrão seguro. Eles são como um ramal telefônico interno. IPs públicos são uma escolha deliberada que você faz apenas quando precisa de algo acessível externamente. Quando precisar deles, pense se você precisa de estático ou dinâmico e se um prefixo faz sentido. Grupos de segurança de rede controlando o tráfego. Então você já organizou sua VNET, suas subredes e seus endereços IP. Mas como você controla de fato o tráfego que entra e sai, é aí que entram os grupos de segurança de redes. Um NSG é o porteiro que controla qual tráfego entra e sai dos seus recursos. Pense nele como um segurança na porta de um clube, verificando identidades, olhando a lista de convidados e barrando quem não deveria estar lá. Todo tráfego que tenta alcançar seu recurso precisa passar por esse segurança primeiro.

Os NSGs funcionam com regra. Cada regra diz permitir ou negar, com base em quatro coisas, endereço IP de origem, endereço IP de destino, número da porta, protocolo. Se pode permitir tráfego do IP do meu escritório na porta 4443 ou negar todo o tráfego da internet na porta 22. Esse tipo de controle. Agora aqui está um recurso poderoso. Você pode anexar um NSG a uma subrede ou diretamente a interface de rede de uma única VM. Se você anexá-la a uma subrede, esse NSG se aplica a tudo que estiver dentro dela. Cada VM, cada banco de dados, cada recurso. É uma política geral. Se você anexar a interface de rede de uma VM específica, ele se aplica apenas àquela máquina. Pode até fazer os dois. Um NSG de nível de subrede para regras amplas e um NSG de nível de NIC para exceções. As regras padrão que o Azure cria são bastante sensatas. Eles permitem todo o tráfego dentro da VNet para que seus recursos possam se comunicar.

E negam todo o tráfego da internet para que nada de fora possa acessar seus recursos a menos que você permita explicitamente. Esse é um bom ponto de partida. Deixa eu me dar um exemplo comum. Digamos que você esteja gerenciando uma máquina virtual Linux que você precisa acessá-la via SSH. Você criaria uma regra de NSG que permite tráfego de entrada na porta 22, mas você não quer permitir SSH de qualquer lugar. Isso é pedido para o problema. Então você restringe ao seu próprio endereço IP para que apenas você possa acessar via SSH e todos os outros sejam bloqueados. A mesma ideia vale para RDP na porta 3389 para máquinas Windows. Isso significa para você. Os NSGs são sua primeira linha de defesa, a melhor parte deles são gratuitos. Não há custo extra por usá-los, então não há desculpa para não configurá-los. Cada subrede, cada recurso deve ter um NSG associado. Comece com negar tudo. E abre apenas o que você precisa.

Tabelas de rotas e roteamento direcionando o tráfego. Agora vamos falar sobre roteamento, porque depois de decidir qual tráfego é permitido, você precisa decidir para onde ele realmente vai. O ponto é, o Azure cria rotas de sistema automaticamente para cada subrede. Você não precisa fazer nada. Pense nisso como um GPS padrão que conhece as estradas básicas. Tráfego dentro da VNet, tráfego para VNet espareadas, tráfego para a internet. Tudo funciona nativamente, mas às vezes o GPS padrão não o leva para onde você deseja ir. É aí que você precisa de rotas definidas pelo usuário ou DRs. Elas permitem que você substitua as rotas de sistema do Azure e assuma o controle do caminho que o tráfego segue. Como isso funciona? Você criou uma tabela de rotas. Você adiciona suas rotas, personaliza. Então você associa essa tabela de rotas a uma subrede. A partir desse momento, o tráfego sai dessa subrede e segue suas regras em vez das padrão.

Deixe-me dar um exemplo concreto. Digamos que você queira que todo o tráfego de internet da sua VNet passe primeiro por um firewall. Talvez você precise inspecioná-lo, registrá-lo ou bloquear sites mais de seu. A rota de sistema padrão envia o tráfego de internet diretamente para fora. Não é isso que você quer. Então você cria uma rota que diz que qualquer tráfego indo para 0.0.0.0, que significa qualquer lugar na internet, deve ir para o firewall. Isso é uma rota definida pelo usuário. As tabelas de rotas usam algo chamado próximo salvo. Esse é o destino para onde o tráfego é enviado em seguida. E tem algumas opções. Você pode enviá-lo para um dispositivo virtual como um firewall. Você pode enviá-lo para um gateway de rede virtual, que é como você se conecta a redes locais. Você pode enviá-lo diretamente para a internet, ou pode enviá-lo para nenhum, o que basicamente descarta o tráfego.

O ponto principal a entender é que o roteamento é como você controla o caminho que o tráfego faz pela sua rede. As rotas de sistema são um bom padrão, mas nem sempre são adequadas para a sua situação. Se você precisa que o tráfego passe por um ponto de inspeção ou por um gateway específico, ou que seja bloqueado totalmente, você precisa de rotas definidas pelo usuário. O que isso significa para você? Roteamento é como você diz ao tráfego para onde ir. E você tem o poder de substituir os padrões do Azure sempre que precisar. Comece com as rotas de sistema entendo o que elas fazem, e depois adicione rotas personalizadas quando sua arquitetura exigir. VNet Peering, conectando rede. Até agora falamos sobre uma única VNet, um edifício e uma rede privada. Mas o que acontece quando você tem várias VNets? Talvez você tenha uma para seu ambiente de produção e outra para testes, ou talvez esteja executando aplicações em diferentes regiões do Azure.

Por padrão, essas VNets são completamente isoladas. Elas não conseguem se comunicar. São como edifícios separados entre eles. É aí que o VNet Peering entra. Ele permite conectar duas VNets de forma privada, e quero dizer privada mesmo. O tráfego entre VNets com Peering permanece na rede Backbone da Microsoft. Ele nunca toca a internet pública. Isso significa baixa latência, alta largura de banda e nenhuma exposição a ameaças externa. Aqui está algo que surpreende as pessoas. O Peering funciona entre regiões também. Isso é chamado de Peering global. Você pode ter uma VNet na Europa Ocidental com Peering com uma VNet no Sudeste Asiático, e o tráfego entre elas permanece na rede privada da Microsoft. Sem Gateways VPN, sem IPs públicos, apenas uma conexão privada direta. Mas há uma regra que você não pode quebrar de jeito nenhum. VNets com Peering devem ter espaço de endereço que não suba. Se ambas as VNets tentarem usar a faixa 10.0.0.16, elas não poderão ter Peering.

Os endereços IP entrariam em conflito e o Azure não saberia a qual rede um pacote pertence. Então lembra daquela dica de planejamento inicial sobre escolher seu espaço de endereço com cuidado. É por isso. Se você acha que pode precisar de Peering entre VNets no futuro, certifique-se de que seus intervalos não se sobrepõem ao desvinho. Agora aqui está um detalhe que confunde as pessoas. Peering não é transitivo. O que isso significa? Digamos que a VNet A esteja com Peering com a VNet B e a VNet B com a VNet C. A VNet A não alcança automaticamente a VNet C através da B. Elas não estão conectadas. Cada Peering é um link direto entre exatamente duas VNets. Se você quer que a A fale com a C, você precisa de um Peering separado entre A e C. Então como lidar com isso em escala? Você usa uma arquitetura Hub & Spoke. Uma VNet central, o Hub, é conectada via Peering a várias outras VNets dos Spokes.

O Hub pode conter serviços compartilhados como Firewall, Gateway, VPN e ferramentas de monitoramento. Os Spokes contêm suas caras individuais. Cada Spoke conecta-se diretamente ao Hub, mas os Spokes não se conectam entre si. Se um Spoke precisar acessar outro, o tráfego passa pelo Hub. Isso mantém tudo organizado e oferece um local central para aplicar políticas de segurança. O que isso significa para você? O Peering é como você constrói redes que abrangem múltiplas VNets e regiões. É a ponte de seus edifícios. Planeje seus espaços de endereço para que não se sobreponha. Lembre-se de que o Peering não é transitivo e considere um design Hub & Spoke ao crescer além de uma única VNet. Como tudo se conecta, é a visão geral. Então vamos dar um passo atrás e ver como essas peças realmente se encaixam. É aí que resídua o poder. Você começa com uma VNet. Esse é seu espaço privado no Azul. Pense nisso em terreno.

Dentro desse terreno você cria subredes. Esses são os seus cômodos. Um para servidores web, um para bancos de dados, um para ferramentas de gerenciamento. Cada subrede obtém seu próprio bloco de endereço extraído do espaço de internet. Então você adiciona segurança. Grupos de segurança de rede são conectados à sua subrede. Eles controlam qual tráfego é permitido entrar e sair. Sua subrede web permite tráfego da internet na porta 443. Sua subrede de banco de dados só permite tráfego da subrede web na porta 1433. O segurança em cada porta sabe exatamente quem tem permissão. Em seguida você configura o roteamento. Talvez você queira que todo o tráfego de saída da internet passe por um firewall para a inspeção. E a uma tabela de rotas adiciona uma rota personalizada e a vincula a sua subir. Agora o tráfego segue o caminho que você projetou em vez do padrão do Azul. E finalmente você conecta tudo.

Até faz o peering da sua VNet com outras VNets. Talvez uma VNet Hub que contenha seu firewall e serviço compartilhado. Agora a sua aplicação abrange múltiplas redes. Mas tudo funciona como um sistema conectado. Aqui está o momento de revelação. Nenhuma dessas peças funciona isoladamente. Uma VNet sem subredes é apenas um espaço fácil. Subredes sem ESG ficam totalmente abertas. O roteamento sem o design claro envia tráfego para o lugar errado. O pire em sem planejamento cria conflitos de endereçamento. Elas formam um sistema. Cada peça depende das outras. Deixe-me dar um exemplo concreto. Imagine uma aplicação web. Seus servidores web ficam em uma subrede pública com NSG que permite tráfego HTTPS da internet. Seus servidores de aplicação ficam em uma subrede privada que só aceita tráfego da subrede web. Seu banco de dados fica em outra subrede privada que só aceita tráfego da subrede aplicativos.

Uma tabela de rotas força todo o tráfego de saída através de um firewall no Hub VNet para registro e inspeção. Tudo isso é pareado com sua rede corporativa para que sua equipe interna possa gerenciar. Esse é o valor real, não qualquer recurso isolado. É como tudo isso funciona em conjunto. Há 20 anos você comprava servidores separados, configurava roteadores físicos e gerenciava firewalls por dispositivo. Tudo era manual, lento e caro. O Azure oferece tudo isso como serviço. Você define com alguns cliques ou um script e simplesmente funciona. O que isso significa para você? Assim que você entende como essas peças se encaixam, a rede do Azure se torna previsível. Você não está chutando, você está projetando. Quando algo quebra, você sabe exatamente onde procurar porque entende o sistema. Então aqui está o que eu quero que você leve deste episódio. Primeiro passo mais importante que você pode dar.

Crie uma VNet com um espaço de endereçamento bem planejado antes de implantar qualquer coisa. Essa única decisão afeta tudo o que vier depois. Segundo, use subredes para separar suas camadas de aplicação. Servidores web, servidores de aplicativos, bancos de dados, dê a cada um seu próprio espaço. E terceiro, comece com os NSGs. Eles são gratuitos. Eles são poderosos e melhoram drasticamente sua segurança desde o primeiro dia. Sua VNet é a base de tudo o que você constrói no Azure. Acerte nela e todo o resto se torna mais fácil. R nela e você passará todo o seu tempo lutando contra a sua rede. Inscreva-se em sua plataforma de podcast favorita e compartilhe isso com alguém que está começando sua jornada no Azure. Deixe um comentário se algo fez sentido para você. Vejo você no próximo episódio. Tchau.