Qu'est-ce qu'un réseau virtuel Azure ? La plupart des gens entendent ce terme et pensent qu'il s'agit simplement d'un paramètre à activer lors du déploiement, d'une machine virtuelle, une case à cocher que l'on oublie aussitôt. Voici la vérité. Un réseau virtuel Azure n'est pas qu'un simple paramètre. C'est le socle de tout ce que vous construisez dans Azure. Chaque machine virtuelle, chaque base de données, chaque service d'application, chaque fonction que vous déployez, tout cela réside à l'intérieur. Et si vous ne comprenez pas leur fonctionnement, vous avancez à l'aveugle. A la fin de cet épisode, vous comprendrez ce qu'est réellement un VINET, comment il fonctionne et pourquoi chaque ressource que vous déployez en dépend. Nous aborderons la définition d'un VINET, le fonctionnement des adresses IP, les sous-réseaux, la sécurité, le routage, la sécurité, le routage, la façon de connecter les VINET entre eux.

Prenez votre carré et plongeons dans le sujet. Qu'est-ce qu'un VINET ? Le réseau cloud privé. Commençons par la définition la plus simple. Un réseau virtuel Azure, ou VINET pour faire court, est votre propre réseau privé au sein d'Azure. Imaginez cela comme un immeuble de bureau privé. Seules les personnes que vous autorisez peuvent entrer. Vous contrôlez qui franchit la porte, qui accède à quel étage et qui est totalement exclu. Aïl. Avant l'existence des VINET, les choses étaient différentes. Vous déployez une machine virtuelle dans le cloud et elle était pratiquement exposée à Internet par défaut. Aucun réseau privé ne l'entourait. Quiconque connaissait l'adresse IP pouvait tenter de s'y connecter. C'est un cauchemar en matière de sécurité. Qu'est-ce qui a changé ? Azure vous a donné la possibilité de créer des espaces réseau privés isolés. Vous définissez une frontière. Vous décidez de ce qui se trouve à l'intérieur.

Rien à l'extérieur de cette frontière ne peut entrer sauf si vous l'autorisez explicitement. Une chose à savoir dès le départ, votre VINET réside dans une région Azure spécifique. Il n'est pas global. Si vous créez un VINET en Europe de l'Ouest, il y restera. Les ressources situées dans une autre région ne peuvent pas simplement s'y intégrer. Elles auraient besoin de leur propre VINET. Vous devriez les connecter ultérieurement. Lorsque vous créez un VINET, vous définissez vous-même l'espace d'adressage IP. Azure ne le choisit pas pour vous. Vous décidez de la plage d'adresse IP que vos ressources utiliseront. C'est une our de responsabilité et nous verrons comment bien le faire dans la section suivante. Voici le point essentiel. Les VINET sont la fondation. Chaque machine virtuelle, chaque base de données, chaque fonction Azure que vous déployez réside à l'intérieur. A. Sans VINET, vos ressources n'ont aucun contexte de réseau privé.

Elles flottent simplement dans le cloud. Sans frontières, sans isolation, sans sécurité. Alors qu'est-ce que cela signifie pour ça ? Si vous construisez quoi que ce soit dans Azure, commencez d'abord par un VINET. Pas après avoir déployé vos ressources, mais avant. Votre VINET est le terrain sur lequel vous construisez. Vous ne construyez pas une maison sans avoir acheté le terrain avant, n'est-ce pas ? C'est la même idée. Adressage IP et CIDR, choisir votre espace d'adressage. Alors plongeons dans le vif du sujet. Lorsque vous créez un VINET, la première grande décision est de choisir une plage IP. Vous le faites en utilisant la notation CIDR ? CIDR signifie Classless Interdomain Routing, mais cela signifie simplement que vous dites « gars, j'ai besoin de tant d'adresses IP ». Pourquoi est-ce important ? Parce que la plage que vous choisissez détermine le nombre de ressources que vous pouvez intégrer dans votre réseau virtuel.

Voici comment cela fonctionne. CIDR utilise une barre oblique et un nombre, comme 16 ou 24. Ce nombre vous indique la taille de l'espace d'adressage. 1.16 vous donne environ 65 000 adresses IP. C'est beaucoup. 1.24 vous en donne environ 250, ce qui est parfait pour une petite équipe ou un niveau d'application unique. Donc lors de la conception de votre VINET, vous devez réfléchir au nombre de ressources que vous aurez et à la façon dont vous souhaitez les regrouper. Maintenant, vous ne pouvez pas choisir n'importe quelle plage IP. Azure suit la norme RFC 918 qui réserve des plages d'adresses IP privées pour les réseaux internes. Vous avez trois options. La plage 10.x.x.x est la plus grande, vous offrant beaucoup d'espace pour vous développer. La plage 172.16.x.x est un peu plus petite mais reste utile. Et la plage 192.168.x.x est celle que vous avez probablement chez vous sur votre routeur.

Voici le point crucial. L'espace d'adressage de votre VINET ne doit chevaucher aucun autre réseau auquel vous prévoyez de vous connecter. C'est une erreur courante. Beaucoup de gens choisissent une plage qui semble familière pour découvrir plus tard qu'elle entre en conflit avec leur réseau d'entreprise. Donc si le réseau de bureau de votre entreprise utilise 10.0.0.0.16, n'utilisez pas cette même plage dans Azure. Si vous essayez de les connecter plus tard, ils entreront en conflit et le trafic ne saura pas où aller. Laissez-moi vous donner un exemple concret. Imaginez que vous construisiez une configuration hybride où Azure se connecte à votre centre de données sur site et votre centre de données utilise 10.0.0.0.0.1.0.0.0.0.0.0.0.0.0.1.6. Si vous créez un VINET avec la même plage, vous aurez deux réseaux se disputant les mêmes adresses IP. Réfléchissez-y. Deux réseaux utilisant la même plage IP ne peuvent pas communiquer correctement.

C'est comme deux maisons avec la même adresse. Le courrier est confondu. C'est un problème que vous ne voulez pas avoir à résoudre après coup. Alors planifiez à l'avance et choisissez une plage unique. Et voici un conseil de planification. Choisissez une plage plus grande que cette dont vous pensez avoir besoin. Vous pensez peut-être n'avoir besoin que d'un C24 maintenant, mais à mesure que votre application grandit, vous regretterez de ne pas avoir pris un C16. Vous ne pourrez pas le changer facilement plus tard. Une fois votre VNet créé et vos ressources déployées, modifiez l'espace d'adressage et complexe. C'est possible, mais ce n'est pas quelque chose que vous voulez faire sur un système en production. Alors prévoyez de la marge pour évoluer. Qu'est-ce que cela signifie pour vous ? Voyez l'espace d'adressage de votre VNet comme un achat de terrain. Prévoyez suffisamment d'espace pour la croissance.

Si vous pensez avoir besoin d'une petite parcelle, achetez-en une moyenne. Vous remercierez plus tard. C'est-ce qu'il est essentiel à retenir ? Planifiez votre espace d'adressage en pensant à la croissance future. Les sous-réseaux pour diviser votre réseau. Vous avez donc votre VNet et vous avez choisi votre espace d'adressage. Mais maintenant, il ne faut pas simplement tout mettre dans un seul grand groupe. C'est là que les sous-réseaux interviennent. Les sous-réseaux sont l'un des éléments fondamentaux de votre VNet. Ils vous permettent d'organiser et de sécuriser vos ressources. Le sous-réseau est une section plus petite de l'espace d'adressage de votre VNet. Si votre VNet est le bâtiment, les sous-réseaux en sont les différentes pièces. Vous ne mettriez pas votre salle serveur, votre réception et votre salle de pose dans le même espace ouvert, n'est-ce pas ? C'est la même idée ici. C'est un concept simple mais qui change tout dans la gestion de votre réseau.

Des ressources différentes vont dans des sous-réseaux différents. Vos serveurs web dans un sous-réseau, vos bases de données dans un autre et votre logique applicative dans un troisième. Pourquoi ? Pour deux raisons. La sécurité et l'organisation. Parlons d'abord de la sécurité car c'est généralement le plus important. La sécurité avant tout. Si quelqu'un s'introduit dans votre serveur web, vous ne voulez pas qu'il ait un accès direct à votre base de données. Des sous-réseaux séparés créent une barrière naturelle. L'attaqueur devrait franchir cette frontière et vous pouvez contrôler précisément ce qui la traverse. Vous pouvez également utiliser des groupes de sécurité réseau pour contrôler le trafic entre les sous-réseaux. C'est un sujet pour une autre vidéo, mais il est utile de savoir que les sous-réseaux sont la base de cette sécurité. L'organisation ensuite. Quand tout a sa place, la gestion est plus facile.

Vous savez quel sous-réseau contient vos ressources front-end et lequel contient vos données back-end. Vous pouvez appliquer des politiques et des règles à tout le sous-réseau d'un coup, plutôt que de configurer chaque ressource individuellement. Cela permet de gagner du temps et de réduire les erreurs. Voici maintenant un détail qui surprend souvent les utilisateurs. Azure réserve 5 adresses IP dans chaque sous-réseau pour ses besoins internes comme le routage et le DNS. Donc si vous créez un sous-réseau, avec une plage C24 offrant 256 adresses, vous n'en obtenez. En réalité que 251 utilisables, c'est un piège classique. Vous prévoyez 256 adresses mais vous n'en obtenez que 200. Alors prévoyez toujours un peu plus de marge pour vos sous-réseaux. La bonne nouvelle, c'est que vous pouvez ajouter des sous-réseaux après la création du VNet. Vous n'êtes pas limité à ceux configurés lors de la création initiale.

Si vous réalisez que vous avez besoin d'un sous-réseau séparé pour des outils de gestion ou de monitoring, ajoutez-le plus tard. Ajoutez-le plus tard. Aucun problème. Mais il est tout de même préférable de les planifier dès le début. Ajoutez des sous-réseaux après-coups et possibles, mais vous pourriez devoir déplacer des ressources qui peuvent être perturbantes. Voici toutefois la meilleure pratique. Utilisez des sous-réseaux séparés pour les différents niveaux de votre application dès le départ. Pensez à l'architecture de votre application. Typiquement, vous avez un niveau frontal pour les requêtes utilisateurs, un niveau logique pour le traitement et un niveau de données pour le stockage. Chacun de ces éléments devrait avoir son propre soi. N'attendez pas d'être en production pour réaliser que vous devez tout séparer. C'est beaucoup plus complexe une fois que les ressources sont déployées.

Qu'est-ce que cela signifie pour vous ? Les sous-réseaux permettent de garder votre réseau organisé et sécurisé. Ce sont les pièces de votre bâtiment. Planifiez les taux et donnez à chaque niveau de votre application son propre espace. C'est ainsi que vous gardez votre réseau propre et sécurisé. IP publique contre privé. Qui peut voir quoi ? Parlons des adresses IP, car elles ne sont pas toutes identiques. Lorsque vous déployez une ressource dans un VNet, elle reçoit une adresse IP privée par défaut. C'est l'adresse utilisée pour communiquer avec les autres ressources au sein du VNet. Voyez cela comme une ligne téléphonique interne. Seules les personnes dans le bâtiment peuvent l'atteindre. Les IP privées ne sont accessibles que depuis l'intérieur du VNet ou des réseaux connectés. Si vous êtes chez vous sur votre ordinateur, vous ne pouvez pas joindre une IP privée dans Azure. Elle n'est pas sur Internet.

Elle est à l'intérieur de votre réseau privé. Alors comment rendre une ressource accessible depuis Internet ? Lui attribuer une adresse IP publique. C'est l'adresse visible du monde extérieur, comme un numéro de téléphone public, plutôt qu'une ligne interne. Interne. Voici le point crucial. Les IP publics sont facultatifs. Vous les assigner explicitement, car Azure ne donne jamais d'IP publics à vos ressources sans votre demande. C'est voulu par conception. Le défaut doit être privé et le public doit être un choix délibéré. Et c'est là que beaucoup de débutants font une erreur. Ils attribuent des IP publics à tout. Leur serveur web, leur base de données et leur API backend en reçoivent tous une. C'est un risque pour la sécurité. Votre base de données n'a pas besoin d'être accessible depuis Internet comme votre API backend. Seules les ressources frontales avec lesquelles les utilisateurs interagissent réellement devraient avoir des IP publics.

Les IP publics se déclinent sous deux formes, statique et dynamique. Une IP public statique reste identique même si vous arrêtez et redémarrez la ressource. Une IP public dynamique peut changer. Si vous existez une application en production, vous voudrez probablement des IP statiques pour que vos utilisateurs puissent toujours vous trouver. Si vous testez quelque chose, une IP dynamique peut suffire. Vous pouvez également utiliser un préfixe d'IP public qui vous permet de réserver un bloc d'adresse. Au lieu de les créer une par une, vous réservez une plage et assignez ensuite des adresses individuelles issues de cette plage. C'est utile si vous savez que vous aurez besoin de plusieurs IP publics pour un projet. Qu'est-ce que cela signifie pour vous ? Les IP privées constituent l'option par défaut la plus sûre. C'est comme un numéro de poste interne. Les IP publics sont un choix délibéré fait uniquement lorsque vous avez besoin d'une ressource accessible de l'extérieur.

Et quand vous en avez besoin, réfléchissez au choix entre statique ou dynamique et si un préfixe est pertinent. Les groupes de sécurité réseau contrôlant le trafic. Vous avez donc configuré votre VNet, vos sous-réseaux et vos adresses IP. Mais comment contrôler réellement le trafic entrant et sortant ? C'est là qu'interviennent les groupes de sécurité réseau. Un NSG est le gardien qui contrôle le trafic entrant et sortant et sortant de vos ressources. Imaginez un videur à l'entrée d'un club, il vérifie les identités, consulte la liste des invités et refuse l'accès aux personnes non autorisées. Chaque flux de trafic essayant d'atteindre votre ressource doit d'abord passer par ce videur. Les NSG fonctionnent avec des règles. Chaque règle autorise ou refuse le trafic en se basant sur 4 éléments, l'IP source, l'IP de destination, le numéro de port et le protocole. Ainsi, vous pouvez autoriser le trafic depuis l'IP de votre bureau sur le port 443 ou refuser tout trafic venant d'Internet sur le port 22.

C'est ce niveau de contrôle. Voici maintenant une fonctionnalité puissante. Vous pouvez attacher un NSG à un sous-réseau ou directement à l'interface réseau d'une machine virtuelle. Si vous l'attachez à un sous-réseau, ce NSG s'applique à tout ce qu'il contient, chaque VM, chaque base de données, chaque ressource. C'est une politique globale. Si vous l'attachez à l'interface réseau d'une machine spécifique, il ne s'applique qu'à cette machine. Vous pouvez même faire les deux. NSG au niveau du sous-réseau pour les règles générales et NSG au niveau de la carte réseau pour les exceptions. Les règles par défaut créées par Azure sont plutôt judicieuses. Ils autorisent tout le trafic au sein du VNet pour que vos ressources puissent communiquer et ils refusent tout trafic provenant d'Internet de sorte que rien de l'extérieur ne puisse atteindre vos ressources sans une autorisation explicite. C'est un bon point de départ.

Laissez-moi vous donner un exemple courant. Disons que vous gérez une machine virtuelle Linux et que vous devez vous y connecter en SSH. Vous créeriez une règle NSG autorisant le trafic entrant sur le port 22, mais vous ne voulez pas autoriser le SSH depuis n'importe où. Ce serait chercher les ennuis. Vous le restreignez donc à votre propre adresse IP afin que vous seul puissiez vous connecter en SSH et que tout le monde soit bloqué. Même principe pour le RDP sur le port 310389 pour les machines Windows. Qu'est-ce que cela signifie pour vous ? Les NSG sont votre première ligne de défense et le meilleur dans tout ça c'est qu'ils sont gratuits. Il n'y a aucun coût supplémentaire pour les utiliser donc aucune excuse pour ne pas les configurer. Chaque sous-réseau et chaque ressource devrait avoir un NSG associé. Commencez par tout refuser et n'ouvrez que ce dont vous avez besoin. Table de routage et routage, diriger le trafic.

Parlons maintenant du routage, car une fois que vous avez décidé quel trafic est autorisé, vous devez décider où il va réellement. Voici le point important, Azure crée automatiquement des itinéraires système pour chaque sous-réseau. Vous n'avez rien à faire, considérez cela comme un GPS par défaut qui connaît les routes principales. Trafic au sein du VNet, trafic vers les VNet appairés, trafic vers Internet. Tout fonctionne immédiatement, mais parfois le GPS par défaut ne vous emmène pas là où vous voulez aller. C'est là que vous avez besoin d'itinéraires définis par l'utilisateur ou UDR. Ils vous permettent de remplacer les itinéraires système d'Azure et de prendre le contrôle du chemin suivi par le trafic. Comment cela fonctionne-t-il ? Créez une table de routage. Vous ajoutez vos itinéraires Personnets. Ensuite, vous associez cette table de routage à un sous-réseau. A partir de ce moment, le trafic qui tend ce sous-réseau suit vos règles au lieu des valeurs par défaut.

Laissez-moi vous donner un exemple concret. Disons que vous voulez que tout le trafic Internet de votre VNet passe d'abord par un pare-feu. Peut-être devez-vous l'inspecter, l'enregistrer ou bloquer des sites malveillants. L'itinéraire système par défaut envoie le trafic Internet directement vers l'extérieur. Ce n'est pas ce que vous voulez. Alors vous créez un itinéraire indiquant que tout trafic vers 0.0.0.0, ce qui signifie n'importe où sur Internet, doit aller vers le pare-feu à la place à... C'est un itinéraire défini par l'utilisateur. L'étape de routage utilise ce qu'on appelle le tronçon suivant. C'est la destination vers laquelle le trafic est envoyé ensuite. Vous avez quelques options. Vous pouvez l'envoyer vers une appliance virtuelle comme un pare-feu. Vous pouvez l'envoyer vers une passerelle de réseau virtuel qui permet de se connecter aux réseaux locaux. Vous pouvez l'envoyer directement vers Internet ou vers aucun UGA, ce qui abandonne essentiellement le trafic.

L'essentiel à comprendre est que le routage est le moyen de contrôler le chemin que le trafic emprunte sur votre réseau, réseau. Les itinéraires système sont une bonne base, mais ils ne sont pas toujours adaptés à votre situation. Si vous devez faire passer le trafic par un point d'inspection, une passerelle spécifique ou le bloquer totalement, vous avez besoin d'itinéraires définis par l'utilisateur. Qu'est-ce que cela signifie pour vous ? Le routage vous permet d'indiquer au trafic où aller. Vous avez le pouvoir de remplacer les valeurs par défaut d'Azure quand vous le souhaitez. Commencez par les itinéraires système, comprenez leur fonctionnement, puis ajoutez des itinéraires personnalisés lorsque votre architecture l'exige. Le peering VNet pour connecter les réseaux Jusqu'à présent, nous avons parlé d'un seul VNet. Un bâtiment, un réseau privé. Mais que se passe-t-il lorsque vous avez plusieurs VNet ?

Peut-être en avez-vous un pour votre environnement de production et un autre pour les tests, ou peut-être exécutez-vous des applications dans différentes régions Azure. Par défaut, ces VNet sont totalement isolées, ils ne peuvent pas communiquer entre eux. C'est comme des bâtiments séparés sans route entre eux. C'est là qu'intervient le peering VNet. Il vous permet de connecter deux VNet de manière privée, et je dis bien privée. Le trafic entre les VNet appérées reste sur le réseau dorsal de Microsoft. Il ne touche jamais l'Internet public. Cela signifie une faible latence, une bande passante élevée et aucune exposition aux menaces extérieures. Voici quelque chose qui surprend souvent les gens. Le peering fonctionne aussi entre les régions, ce qu'on appelle le peering mondial. Vous pouvez avoir un VNet en Europe de l'Ouest appellé avec un VNet en Asie du Sud-Est, et le trafic entre eux reste sur le réseau privé de Microsoft.

Pas de passerelle VPN, pas d'IP public, juste une connexion privée directe. Mais il y a une règle à ne jamais enfreindre. Les VNet appérées doivent avoir des espaces d'adressage qui ne se chevauchent pas. Si deux VNet tentent d'utiliser la plage 10.0.0.0.0.16, ils ne peuvent pas être appérés. Les adresses IP entreraient en conflit, et Azure ne saurait pas à quel réseau appartient un paquet. Alors vous souvenez-vous de ce conseil de planification précédent sur le choix minutieux de votre espace d'adressage ? C'est la raison. Si vous pensez devoir appairer des VNet plus tard, assurez-vous que leur plage ne se chevauche pas dès le départ. Voici maintenant un détail qui en piège plus d'un. Le pairing n'est pas transitif. Qu'est-ce que cela signifie ? Disons que le VNet A est appairé avec le VNet B, et que le VNet B est appairé avec le VNet C. Le VNet A ne peut pas atteindre automatiquement le VNet C via B. Ils ne sont pas connectés.

Chaque pairing est un lien direct entre exactement deux VNet. Si vous voulez que A communique avec C, vous avez besoin d'un pairing distinct entre A et C. Alors comment gérer cela à grande échelle ? Vous utilisez une architecture en étoile. Un VNet central, le Hub, est appairé avec de nombreux autres VNet, l'ESPO. Le Hub peut contenir des services partagés comme un pare-feu, une passerelle VPN ou des outils de surveillance. L'ESPO contiennent vos charges de travail individuelles. Chaque SPOC s'appair directement avec le Hub, mais les SPOC ne s'appairent pas entre eux. Si un SPOC doit atteindre un autre SPOC, le trafic passe par le Hub. Cela maintient l'organisation et offre un point central pour appliquer vos politiques de sécurité. Qu'est-ce que cela signifie pour vous ? Le pairing est le moyen de construire des réseaux couvrant plusieurs VNet et régions. C'est le pont entre vos bâtiments.

Planifiez vos espaces d'adressage pour qu'ils ne se chevauchent pas. N'oubliez pas que le pairing n'est pas transitif. Et envisagez une conception Hub & SPOC lorsque vous dépassez un seul VNet. Comment tout cela se connecte, la vue d'ensemble ? Prenons du recul pour voir comment ces éléments s'assemblent réellement. C'est là que rétablis puissance. Comment c'est qu'un VNet ? C'est votre espace privé dans Azure ? Considérez-le comme votre terrain. A l'intérieur de ce terrain, vous créez des sous-réseaux. Ce sont vos pièces. Une pour les serveurs web, une pour les bases de données, une pour les outils de gestion. Chaque sous-réseau obtient son propre bloc d'adresse extrait de l'espace d'adressage du VNet. Ensuite, vous ajoutez la sécurité. Des groupes de sécurité réseau sont attachés à vos sous-réseaux. Ils contrôlent le trafic autorisé à entrer et sortir. Votre sous-réseau web autorise le trafic depuis Internet sur le port 440 ?

Votre sous-réseau de bases de données n'autorise que le trafic venant du sous-réseau web sur le port 1430 ? Le videur à chaque porte sait exactement qui est autorisé ? Ensuite, vous configurez le routage. Peut-être voulez-vous que tout le trafic Internet sortant passe par un pare-feu pour inspection ? Vous créez une table de routage, ajoutez une route personnalisée et la liez à vos sous-réseaux. Désormais, le trafic suit le chemin que vous avez conçu plutôt que celui par défaut d'Azure. Et enfin, vous connectez tout ensemble. Vous appelez votre VNet avec d'autres VNet, peut-être un VNet Hub qui contient votre pare-feu et vos services partagés. Désormais, votre application couvre plusieurs réseaux, mais tout fonctionne comme un système connecté. Voici le déclic. Aucun de ces éléments ne fonctionne de manière résolée. Un VNet sans sous-réseau n'est qu'un espace vide. Les sous-réseaux sans NG sont totalement exposés.

Le routage sans conception claire envoie le trafic au mauvais endroit. Le peering sans planification crée des conflits d'adresses. Il forme un système. Chaque élément dépend des autres. Laissez-moi vous donner un exemple concret. Imaginez une application web. Vos serveurs web se trouvent dans un sous-réseau public avec un NSG qui autorise le trafic HTTPS depuis Internet. Vos serveurs d'application se trouvent dans un sous-réseau privé qui n'accepte que le trafic provenant du sous-réseau web. Votre base de données se trouve dans un autre sous-réseau privé qui n'accepte que le trafic provenant du sous-réseau applicatif. Une table de routage force tout le trafic sortant à passer par un pare-feu dans le VNet Hub pour journalisation et inspection. Et l'ensemble est appairé avec votre réseau d'entreprise afin que votre équipe interne puisse le gérer. C'est là la vraie valeur, pas dans une fonctionnalité isolée.

C'est la façon dont ils fonctionnent tous ensemble. Il y a 20 ans, vous achetez des serveurs séparés, configurez des routeurs physiques et gérez des pare-feu par appareil et… Tout était manuel, lent et coûteux. Azure vous offre tout cela en tant que service. Vous le définissez en quelques clics ou par script et cela fonctionne tout simplement. Qu'est-ce que cela signifie pour vous ? Une fois que vous comprenez comment ces éléments s'assemblent, le réseau Azure devient prévisible. Vous ne devinez pas, vous concevez. Si quelque chose casse, vous savez exactement où regarder car vous comprenez le système. Voici donc ce que je veux que vous reteniez de cet épisode. Premièrement, l'étape la plus importante que vous puissiez franchir. Créer un VNet avec un espace d'adressage bien planifié avant de déployer quoi que ce soit. Cette seule décision affecte tout le reste en aval. Deuxièmement, utiliser des sous-réseaux pour séparer vos niveaux d'application.

Serveurs web, serveurs d'application, bases de données, donner à chacun son propre espace. Et troisièmement, commencez avec les NAG. Ils sont gratuits, ils sont puissants et améliorent considérablement votre sécurité dès le premier jour. Votre VNet est la fondation de tout ce que vous construisez dans Azure. Réussissez-le et tout le reste deviendra plus facile. Si vous échouez, vous passerez tout votre temps à vous battre avec votre réseau. Abonnez-vous sur votre plateforme de podcast préférée et partagez ceci avec quelqu'un qui débute son parcours Azure. Laissez un commentaire si quelque chose vous a semblé clé. Je vous donne rendez-vous dans le prochain épisode.