virtuele netwerken en subnetten Azure

Azure virtuele netwerken (VNets) en subnetten zijn de basisbouwstenen van elk Azure netwerk. In dit artikel wordt uitgelegd hoe VNets isolatie bieden, hoe subnetten resources ordenen en hoe u uw netwerk kunt aanpassen en structuren voor productieworkloads.

Wat in dit artikel wordt behandeld

In dit artikel worden de isolatiegrenzen van VNets, subnetgrootte en gereserveerde adressen, toegewezen platformsubnetten voor services zoals Azure Firewall en Application Gateway, VNet-peering en algemene netwerkindelingspatronen behandeld.

Wie heeft dit artikel nodig

Lees dit artikel als u:

  • Implementeert u uw eerste workload in Azure en moet u begrijpen hoe netwerken werkt voordat u resources gaat maken.
  • Plant u een omgeving met meerdere workloads en moet u beslissen hoeveel VNets en subnetten u wilt maken.
  • Migreert u on-premises-workloads naar Azure en moet u begrijpen hoe netwerken in Azure verschillen van fysieke netwerken.
  • De grootte van subnetten moet correct zijn voor Azure platformservices, zoals Azure Firewall, VPN Gateway of Azure Kubernetes Service (AKS).
  • Wilt u weten wanneer u workloads in verschillende VNet's wilt scheiden in plaats van ze in hetzelfde VNet te houden.

Lift-and-shiftfocus: Hanteer in Azure dezelfde subnetsegmentatie als on-premises. Wijs bestaande VLAN's en beveiligingszones toe aan subnetten, houd adresruimten uitgelijnd met bereiken die uw team al gebruikt en pas subnetten uitgebreid toe, zodat u tijdens de migratie niet opnieuw hoeft te adresseren.

Focus moderniseren: Subnetten ontwerpen rond platformservices en automatisering. Stem subnetten qua grootte af voor AKS, privé-eindpunten en toegewezen platformservices, en plan het gebruik van Azure Virtual Network Manager zodat consistente configuratie in veel VNets kan worden toegepast.

Focus op meerdere clouds: Plan niet-overlappende adresruimte in Azure, AWS en Google Cloud voordat u een VNet maakt. Reserveer CIDR-bereiken die niet botsen met bestaande VPN's, zodat u clouds kunt peeren of VPN-verbinden zonder NAT.

Azure services en functies

De volgende services en functies vormen de basis voor virtuele netwerken in Azure:

Dienst of functie Wat het biedt Wanneer gebruikt u het?
Azure Virtual Network (VNet) Een geïsoleerd particulier netwerk in Azure. Alle Azure netwerken beginnen hier. Resources in hetzelfde VNet kunnen standaard communiceren; resources in verschillende VNets kunnen alleen communiceren als u ze expliciet verbindt. Altijd: elke workload die netwerkconnectiviteit nodig heeft, vereist een VNet.
Subnet Een partitie van de VNet-adresruimte. Subnetten vormen het toepassingsbereik van de koppeling van een netwerkbeveiligingsgroep (NSG) en een routetabel. Altijd: organiseer workloadcomponenten in subnetten op basis van functie of beveiligingsgrenzen.
VNet-peering Lage latentie, privéconnectiviteit tussen twee VNets in dezelfde regio of tussen regio's. Verkeer blijft op de Microsoft backbone. Peering is niet transitief; elke peering is een directe koppeling. Wanneer bronnen in afzonderlijke VNets moeten communiceren. Zie Connectiviteit tussen regio's voor peering tussen regio's.
Peering van subnetten (previewversie) Peering tussen specifieke subnetten in plaats van volledige VNets. Biedt gedetailleerde controle over welke subnetten deelnemen aan peeringrelaties. Wanneer u fijnmazige peeringbeheer tussen specifieke subnetten in verschillende VNets nodig hebt. Zie de sectie Beperkingen .
Routetabel/door de gebruiker gedefinieerde routes (UDR's) Overschrijf standaardsysteemroutes in Azure om te bepalen waar verkeer wordt verzonden. Toegepast op subnetniveau. Wanneer u verkeer wilt afdwingen via een firewall of virtueel netwerkapparaat (NVA). Vereist voor hub-and-spoke-egressbeheer. Zie het ontwerp van Azure Firewall en Hub-and-spoke-topologie.
Azure Virtual Network Manager (AVNM) Netwerkconfiguraties centraal maken, beheren en toepassen op VNets tussen abonnementen. Bij het beheren van veel VNets in meerdere abonnementen. Zie Gecentraliseerd netwerkbeheer.

Diagram van VNet met workloadsubnetten voor web-, app- en gegevenslagen, naast toegewezen platformsubnetten voor gateway, firewall en Bastion

Hoe te kiezen

Wat is een virtueel netwerk?

Een virtueel netwerk (VNet) is een softwaregedefinieerd, geïsoleerd netwerk in Azure. U kunt het beschouwen als uw privénetwerk in Azure. In tegenstelling tot een fysiek netwerk dat gebruikmaakt van kabels, switches en routers, is een VNet volledig softwaregedefinieerde. U maakt deze, wijst deze een adresruimte toe en implementeert er resources in.

Belangrijkste kenmerken:

  • Regiobereik: een VNet bestaat in één Azure regio. Alle resources in dat VNet moeten zich in dezelfde regio bevinden. Een VNet beslaat beschikbaarheidszones binnen die regio.
  • Isolatie standaard: resources in het ene VNet kunnen niet communiceren met resources in een ander VNet, tenzij u expliciet een verbinding maakt (peering of VPN).
  • Standaard interne connectiviteit: resources binnen hetzelfde VNet kunnen standaard met elkaar communiceren via systeemroutes die Azure biedt.

Wat is een subnet?

Een subnet is een bereik van IP-adressen binnen uw VNet. Met subnetten kunt u het volgende doen:

  • Segmenteer uw netwerk op workloadonderdeel (bijvoorbeeld weblaag, toepassingslaag, gegevenslaag).
  • Beveiligingsregels toepassen: NSG's worden gekoppeld op subnetniveau om verkeer te filteren.
  • Routering beheren: routetabellen worden op subnetniveau gekoppeld om verkeer te sturen.

Azure reserveert vijf IP-adressen in elk subnet: de eerste vier adressen en het laatste adres. In een /24-subnet (256 adressen) zijn bijvoorbeeld slechts 251 bruikbaar. Neem deze reserve mee in uw capaciteitsberekeningen.

Voorbeeld: Toepassing met drie lagen

Een typische webtoepassing met drie lagen maakt gebruik van drie subnetten om problemen te scheiden en afzonderlijke beveiligingsregels toe te passen:

Subnet CIDR-bereik Purpose Voorbeeldbronnen
web-subnet 10.0.1.0/24 Front-endwebservers die binnenkomend HTTP-/HTTPS-verkeer van internet of Application Gateway accepteren Azure App Service Environment, Virtual Machine Scale Sets waarop NGINX wordt uitgevoerd
app-subnet 10.0.2.0/24 Toepassingslogica in de middelste laag. Accepteert alleen verkeer van het websubnet. Azure Functions (VNet-geïntegreerd), VM's met bedrijfslogica
data-subnet 10.0.3.0/24 Gegevensarchieven. Accepteert alleen verkeer van het app-subnet. Geen directe internettoegang. Azure SQL Managed Instance, privé-eindpunten voor Azure SQL Database of Cosmos DB

Met deze indeling kunt u een NSG toepassen op elk subnet dat verkeer beperkt tot alleen wat die laag nodig heeft. Het websubnet staat binnenkomende HTTPS (poort 443) toe. Het app-subnet staat alleen inkomend verkeer toe vanuit het IP-bereik van het websubnet. Het gegevenssubnet staat alleen inkomend verkeer toe vanuit het IP-bereik van het app-subnet.

Voor een modernisatiepatroon op basis van AKS kunt u een aks-nodes subnet gebruiken, zoals 10.0.4.0/24 voor de clusterknooppuntgroepen wanneer u Azure CNI-overlay implementeert. In dat model verbruiken alleen de knooppunten VNet-IP-adressen uit het subnet. Pods gebruiken een afzonderlijke overlay-CIDR, waarmee u het subnet van het knooppunt kleiner kunt houden dan een AKS-ontwerp met plat netwerk.

Algemene patronen

De volgende subnetindelingen hebben betrekking op de meest voorkomende Azure implementatiescenario's:

Patroon Subnetten Wanneer gebruiken
Eenvoudige web-app web + data Toepassingen met twee lagen met een front-end en -database. Minimale complexiteit.
Enterprise met drie lagen web + app + data + management Traditionele bedrijfsworkloads met verschillende lagen en een jump box of Bastion-subnet voor beheerdoeleinden.
AKS met gedeelde services aks-nodes + aks-ingress + appgw + shared Kubernetes-workloads met een toegewezen ingangscontrollersubnet en Application Gateway voor WAF.
Hub-and-spoke uitgaand netwerkverkeer AzureFirewallSubnet + GatewaySubnet + AzureBastionSubnet + management Het hub-VNet in een hub-and-spoke-topologie. Gedeelde services waar spoke-VNets verkeer doorheen routeren. Zie hub-and-spoke-topologie.
Gegevensbelasting compute + data + private-endpoints + management Analyse- en gegevensplatformworkloads waarbij privé-eindpunten voor opslag en databases hun eigen subnet nodig hebben voor de duidelijkheid van IP-planning.

Hoeveel VNets en subnetten?

Het leidende principe is eenvoudig: gebruik één virtueel netwerk per toepassing en één subnet per onderdeel (laag). Deze standaardinstelling houdt elke workload geïsoleerd, maakt verkeer tussen lagen eenvoudig te beheren met netwerkbeveiligingsgroepen en laat ruimte over om te groeien. Pas van daaruit aan op basis van gedeelde services, isolatievereisten en schaal.

Gebruik deze beslissingstabel om uw VNet- en subnetstrategie te bepalen:

Uw situatie Aanbevolen aanpak
Eén workload, één team, geen gedeelde services nodig Eén VNet met subnetten per toepassingsonderdeel (web, toepassingslogica, gegevens). Zie topologie met één workload.
Meerdere onafhankelijke workloads die een gateway of firewall delen hub-VNet voor gedeelde services + één spoke-VNet per werkbelasting. Zie hub-and-spoke-topologie.
Strikte isolatie tussen workloads (impactbereik, compliancevereisten) Eén VNet per workload, zonder onderlinge peering.
Zeer grote omgeving met veel abonnementen en regio's Azure Virtual WAN met geautomatiseerd hubbeheer. Zie Virtual WAN topologie.

Referentie voor specifieke subnetgrootte

Veel Azure platformservices vereisen hun eigen toegewezen subnet met een specifieke naam en minimale grootte. In het volgende diagram ziet u de naamgevingsvereisten en minimale grootten voor toegewezen platformsubnetten:

Diagram met minimale subnetgrootten voor vijf toegewezen platformsubnetten, waaronder gateway, firewall, Bastion en Route Server

Gebruik deze tabel bij het plannen van uw adresruimte:

Azure-dienst Minimale subnetgrootte Vereiste subnetnaam Aantekeningen
Azure Firewall /26 (59 bruikbare IP's) AzureFirewallSubnet Vereist voor alle firewall-SKU's. Zie Azure Firewall ontwerp.
VPN Gateway /27 (27 bruikbare IP's) GatewaySubnet Microsoft raadt /27 of groter aan om ruimte te houden voor opschaling.
Azure Bastion /26 (59 bruikbare IP's) AzureBastionSubnet Minimaal /26 voor alle implementaties die na november 2021 zijn gemaakt.
Application Gateway v2 /24 aanbevolen (251 bruikbare IP's) Geen vereiste naam Sterk aanbevolen /24 voor automatische schaalaanpassing. Het minimum wordt berekend volgens een formule (instanties + 5 gereserveerde + 1 privé-frontend-IP).
App-Dienstenomgeving /24 (productie), /23 (maximale schaal) Geen vereiste naam Bij het schalen worden IP-adressen uit het subnet gebruikt. Gebruik /23 als u verwacht dicht bij het maximum van 200 instanties te komen.
Azure Route Server /26 (59 bruikbare IP's) RouteServerSubnet Vereist voor BGP-routeuitwisseling met NVA's.
Azure DNS Private Resolver (privé-resolver voor DNS) /28 minimaal per subnet voor eindpunten Specifieke inkomende en uitgaande subnetten Hiervoor zijn afzonderlijke subnetten vereist voor binnenkomende en uitgaande eindpunten. Kan niet worden gedeeld met andere resources.
AKS (Azure Kubernetes Service) Op formules gebaseerd (CNI-afhankelijk) Geen vereiste naam Zie de richtlijnen voor het aanpassen van de grootte van AKS.

Note

Privé-eindpunten gebruiken IP-adressen van bestaande subnetten. Ze hebben geen toegewezen subnet nodig. Factor dit IP-verbruik in de grootte van uw subnet. Zie IP-adresplanning voor gedetailleerde IP-planning.

Grootte van AKS-subnet

De grootte van AKS-subnetten is afhankelijk van de keuze van de CNI-invoegtoepassing (Container Networking Interface). Er is geen enkele minimale grootte:

  • Azure CNI-overlay: het subnet hoeft alleen ruimte te bieden aan knooppunten omdat pods een afzonderlijk cidr-blok (classless Inter-Domain routing) gebruiken. Een aanzienlijk kleiner subnet is acceptabel vergeleken met platte netwerken.
  • Azure CNI (plat netwerk):het subnet moet zowel knooppunten als pods bevatten. Formule: (nodes + surge) × (max_pods + 1). Een /21 of groter is gebruikelijk voor clusters met 50 of meer knooppunten.
  • Kubenet: alleen knooppunten verbruiken VNet-subnet-IP's. Pods krijgen cluster-interne IP-adressen.

Zie IP-adressering voor uw AKS-cluster plannen voor formules voor groottebepaling per CNI-optie.

Beperkingen voor subnetpeering

Subnetpeering verbindt specifieke subnetten tussen VNets in plaats van volledige adresruimten. Deze benadering biedt gedetailleerde controle over welke subnetten deelnemen aan peeringrelaties.

Important

Subnetpeering is momenteel in preview en heeft de volgende beperkingen:

  • Vereist dat een abonnement wordt toegevoegd aan een goedgekeurde lijst (geen selfservice-inschrijving)
  • CLI, ARM-sjabloon, Terraform of PowerShell alleen (geen ondersteuning via de portal)
  • Intel-gebaseerde V5-SKU's (of AMD Genua/Cobalt 100-SKU's) zijn vereist voor productiegebruik om een bekende fout op oudere generatie-SKU's te voorkomen: zie Subnetpeering configureren voor huidige hardwarevereisten
  • Maximaal 200 subnetten per zijde per peeringkoppeling
  • Maximum van 1000 totale subnetten voor alle peeringkoppelingen per VNet
  • Subnetten moeten behoren tot unieke, niet-overlappende adresruimten

Zie Subnetpeering configureren voor huidige beperkingen en inschrijving.

Note

Azure Virtual Network Manager (AVNM) kan subnetpeering niet onderscheiden van VNet-peering. Als u AVNM gebruikt om peeringconfiguraties te beheren, moet u er rekening mee houden dat peeringrelaties op subnetniveau worden weergegeven als standaard-VNet-peering in AVNM.

Ontwerpoverwegingen

Focus op lift-and-shift-VNet- en subnetontwerp

  • Maak uw on-premises segmentatie opnieuw: wijs elke VLAN of beveiligingszone toe aan een subnet, zodat bestaande firewallgrenzen en operationeel eigendom worden overgedragen met minimaal herontwerp.
  • Dimensioneer subnetten met ruimte voor groei. Het opnieuw adresseren na migratie is verstorend, dus wijs grotere CIDR-bereiken toe dan uw huidige aantal hosts vereist, zodat u groei en de vijf door Azure gereserveerde adressen per subnet kunt opvangen.
  • Houd waar mogelijk de Azure-adresruimten afgestemd op on-premises-adresbereiken om routering te vereenvoudigen en overlap te voorkomen wanneer u verbinding maakt via VPN Gateway of ExpressRoute.
  • Standaard 1 VNet per gemigreerde toepassing met een subnet per laag. Dit ontwerp weerspiegelt typische on-premises indelingen met drie lagen en houdt de verplaatsing voorspelbaar.

Focus op VNet- en subnetontwerp moderniseren

  • Ontwerp eerst subnetten rond platformservices: toegewezen subnetten voor Azure Firewall, Application Gateway en Bastion, plus subnetten met de juiste grootte voor AKS op basis van uw CNI-keuze.
  • Gebruik Azure CNI-overlay voor AKS om subnetten van knooppunten klein te houden, omdat pods afkomstig zijn van een afzonderlijke overlay-CIDR in plaats van de VNet-adresruimte.
  • Reserveer een toegewezen subnet voor privé-eindpunten, zodat HET IP-verbruik voorspelbaar blijft naarmate u meer Azure PaaS-services gebruikt.
  • Pas Azure Virtual Network Manager vroeg toe om netwerkgroepen, connectiviteit en beveiligingsconfiguraties consistent toe te passen naarmate het aantal VNet's toeneemt tussen abonnementen.

Aandachtspunten voor cloudoverschrijdend VNet- en subnetontwerp

  • Stel een globaal adresplan in voordat u een VNet maakt. Reserveer niet-overlappende CIDR-blokken voor Azure die niet botsen met bestaande AWS-VPN's of Google Cloud VPC-netwerken. Deze reservering is verplicht voor een gerouteerde VPN of een interconnectie.
  • Wijs de netwerkprimitief van elke cloud toe aan Azure: een AWS VPC- of Google Cloud VPC-netwerk komt overeen met een Azure VNet en beveiligingsgroepen komen overeen met NSG's.
  • Reserveer subnetruimte voor onderdelen voor connectiviteit tussen de cloud, zoals een GatewaySubnet voor VPN Gateway of de hub die door Azure Virtual WAN wordt gebruikt, zodat de doorvoerinfrastructuur ruimte heeft om te schalen.
  • Standaardiseer naamgeving en taggen van subnetten in clouds, zodat operations-teams equivalente lagen kunnen correleren wanneer ze problemen met multicloudverkeer oplossen.

Prerequisites

Voordat u de indeling van uw virtuele netwerk en subnet ontwerpt, moet u het volgende doen:

  • Azure-abonnement: een actief Azure-abonnement met machtigingen voor het maken van netwerkresources (rol netwerkbijdrager of hoger).
  • Resourcegroep: een resourcegroep in uw doelregio die VNet-resources bevat.
  • Regiobeslissing: kies uw primaire Azure regio op basis van nabijheid van gebruikers, nalevingsvereisten en beschikbaarheid van services.
  • Adresruimteplanning: Bepaal een IP-adresbereik (CIDR-blok) dat niet overlapt met uw on-premises netwerken of andere VNets die u wilt peeren. Zie de planning van IP-adressen voor hulp.

Beveiligingsoverwegingen

Virtuele netwerken en subnetten zijn uw eerste laag netwerksegmentatie. Pas de volgende beveiligingsprocedures toe:

  • Netwerkbeveiligingsgroepen (NSG's): koppel NSG's aan elk subnet om inkomend en uitgaand verkeer te filteren. Definieer regels die specifiek zijn voor de rol van elk subnet en weiger standaard alle andere regels. Zie Netwerkbeveiligingsgroepen en toepassingsbeveiligingsgroepen voor gedetailleerde richtlijnen.
  • Geforceerde tunneling met UDR's: als uw nalevingsvereisten vereisen dat al het internetverkeer via een on-premises inspectieapparaat of een cloudfirewall wordt doorgegeven, gebruikt u routetabellen met door de gebruiker gedefinieerde routes om de standaardroutering van internet te overschrijven. Zie uitgaande en egress-connectiviteit.
  • Subnetisolatie: plaats resources met verschillende vertrouwensniveaus in afzonderlijke subnetten. Bewaar bijvoorbeeld databases in een subnet dat alleen inkomend verkeer vanaf het subnet van de toepassingslaag toestaat. Deze scheiding beperkt laterale verplaatsing als een aanvaller een onderdeel in gevaar heeft.
  • Toegewezen subnetten voor platformservices: Veel Azure platformservices (Azure Firewall, Application Gateway, Bastion) worden geïmplementeerd in toegewezen subnetten. Deze isolatie zorgt ervoor dat routering en beveiligingsregels van de platformservice uw workloadsubnetten niet verstoren.

Interactie tussen NSG en subnet

Wanneer u een NSG koppelt aan een subnet, zijn de NSG-regels van toepassing op alle resources in dat subnet. Deze interactiegedragen begrijpen:

  • Cumulatieve evaluatie: als de NIC van een VIRTUELE machine ook een NSG heeft, Azure zowel de NSG op subnetniveau als de NSG op NIC-niveau evalueert. Voor inkomend verkeer evalueert Azure eerst de subnet-NSG en vervolgens de NIC-NSG. Voor uitgaand verkeer evalueert Azure eerst de NIC-NSG en vervolgens de NSG van het subnet.
  • Standaard weigeren: Azure bevat standaardregels waarmee intra-VNet-verkeer en uitgaande internettoegang zijn toegestaan. Nadat u aangepaste regels voor weigeren hebt toegevoegd, controleert u of legitiem verkeer (zoals Azure Load Balancer statustests van IP-adres 168.63.129.16) niet per ongeluk wordt geblokkeerd.
  • Servicetags en ASG's: gebruik servicetags (zoals AzureLoadBalancer, Internet, VirtualNetwork) en toepassingsbeveiligingsgroepen (ASG's) in NSG-regels in plaats van onbewerkte IP-adressen. Deze aanpak vereenvoudigt het beheer van regels en past zich automatisch aan wanneer Azure IP-bereiken veranderen.
  • Stroomlogboeken voor zichtbaarheid: Schakel NSG-stroomlogboeken in op elke NSG op subnetniveau om geaccepteerd en geweigerd verkeer vast te leggen. Met stroomlogboeken kunt u controleren of beveiligingsregels naar behoren werken en bewijs leveren voor nalevingscontroles. Zie NSG-stroomlogboeken voor installatie-instructies.

In deze artikelen in de handleiding voor het ontwerpen van Azure netwerken worden verwante onderwerpen behandeld:

Meer informatie

Zie de volgende bronnen voor meer informatie over Azure virtuele netwerken:

Volgende stappen 

Tip

Zelf verkennen? Ga terug naar de overzichtsnavigator om uw volgende artikel per mogelijkheid te vinden.

De volgende stap in uw lift-and-shift-traject:

Plan uw IP-adresruimte: wijs een /16 CIDR-pool toe die overlap met uw on-premises adresbereiken vermijdt.

Vervolgens in uw moderniseringstraject:

Plan uw IP-adresruimte: Wijs IP-adresgroepen met dubbele regio's toe met niet-overlappende bereiken voor actief-actieve peering.

De volgende stap in uw cross-cloudtraject:

Plan uw IP-adresruimte: ontwerp niet-overlappende adressering in Azure, Amazon Web Services (AWS) en Google Cloud.

  • Last updated on