Veel softwareontwikkelaars hebben weinig ervaring met netwerken, terwijl het een essentieel onderdeel is van cloud native applicaties. In deze blog neem ik je stap voor stap mee door de basis van Azure networking, zodat termen als IP-range, subnet mask en CIDR straks een stuk minder abstract aanvoelen.
IP-ranges, subnet masks en CIDR
Toen ik zelf begon met netwerken, raakte ik snel verstrikt in alle terminologie en methodes om aan te geven welke IP-adressen bij een netwerk horen. De kern is eigenlijk simpel: je begint met een basis-IP-adres (bijvoorbeeld 192.168.0.0) en een subnet mask (bijvoorbeeld 255.255.255.0).
Het subnet mask bepaalt welk deel van het IP-adres vaststaat en welk deel je mag gebruiken voor apparaten of resources. Op bitniveau werkt het zo:
- Een 1 in het mask betekent: dit deel van het basis-IP blijft hetzelfde.
- Een 0 betekent: dit deel mag variëren.
Met ons voorbeeld (192.168.0.0 met 255.255.255.0) krijg je:
| Waarde | Segment 1 | Segment 2 | Segment 3 | Segment 4 | |
| IP | 192.168.0.0 | 11000000 | 10101000 | 00000000 | 00000000 |
| Mask | 255.255.255.0 | 11111111 | 11111111 | 11111111 | 00000000 |
| Resultaat | 192.168.0.0 – 192.168.0.255 | 11000000 | 10101000 | 00000000 | 00000000 – 11111111 |
Het subnet mask verdeelt het netwerk in vaste blokken. Het eerste IP in zo’n blok wordt vaak gebruikt om het netwerk zelf aan te duiden (in Azure is dit verplicht). Het laatste IP wordt meestal gebruikt als broadcast address.
Nu is een subnet mask zoals 255.255.255.192 best lastig in gebruik. Het is namelijk lastig om vanuit dit getal te bepalen hoeveel IP adressen beschikbaar zijn. Daarom gebruiken we in de praktijk vaak CIDR-notatie. Hierbij schrijf je:
{basis-IP}/{aantal 1’en in het mask}
Dus 255.255.255.192 wordt /26, omdat de binaire vorm 11111111.11111111.11111111.11000000 26 keer een 1 bevat.
Het mooie van CIDR is dat je snel kunt berekenen hoeveel IP’s beschikbaar zijn:
- Neem het totaal aantal bits (32)
- Trek het getal na de / eraf
- Reken 2^(overgebleven bits) uit
Voor /26: 32 – 26 = 6 → 2^6 = 64 IP-adressen.
Met deze basis wordt het straks veel makkelijker om VNETs en subnets in Azure goed op te zetten.
Wat zijn Azure VNETs en Subnets?
Een Azure Virtual Network (VNET) is jouw afgebakende stuk netwerk in Azure. Je kunt het zien als een virtuele variant van het bedrijfsnetwerk dat je misschien on-premise hebt. Binnen een VNET plaats je resources zoals VM’s, App Services (met VNET-integratie), databases en private endpoints.
Je bepaalt zelf:
- Het IP-bereik (address space)
- Hoe de onderlinge communicatie verloopt
- Welke verbindingen naar buiten toe zijn toegestaan (internet, on-premises, andere VNETs)
Subnets zijn logische verdelingen binnen een VNET. Elk subnet krijgt een eigen IP-bereik (binnen de address space van het VNET) en kan eigen beveiligingsregels hebben via Network Security Groups (NSG’s). Subnets helpen om resources te scheiden, bijvoorbeeld een frontend-subnet voor webservers en een backend-subnet voor databases.
Hoe maak je een VNET en subnet aan in Azure Portal?
- Ga naar Azure Portal → Create a resource → zoek naar Virtual Network en klik op Create.
- Kies de resource group, naam en regio.
- Stel het IP address space in, bijvoorbeeld
10.0.0.0/16.
- Voeg een Subnet toe, bijvoorbeeld:
- Naam:
frontend
- Subnet range:
10.0.1.0/24
- (Optioneel) Voeg extra subnets toe voor verschillende lagen of applicaties.
- Klik op Create.
Dit vertaalt zich naar het volgende in bicep:
resource vnet 'Microsoft.Network/virtualNetworks@2023-05-01' = {
name: 'myVnet'
location: resourceGroup().location
properties: {
addressSpace: {
addressPrefixes: [
'10.0.0.0/16'
]
}
subnets: [
{
name: 'frontend'
properties: {
addressPrefix: '10.0.1.0/24'
}
}
]
}
}
Met deze setup heb je direct een VNET met een subnet klaarstaan voor gebruik.
Subnet delegations
Een subnet delegation in Azure betekent dat je een subnet toewijst aan een specifieke Azure-dienst. Dat subnet mag dan alleen gebruikt worden door die dienst, en Azure geeft die dienst extra rechten om netwerkinterfaces in dat subnet te beheren. Dit is bijvoorbeeld verplicht voor diensten als:
- Azure App Service Environment
- Azure Container Instances
- Azure SQL Managed Instance
Onderstaand voorbeeld maakt een VNET en subnet met een delegation voor Microsoft.Web/serverFarms (App Service) en een Web App die gebruik maakt van dit subnet.
resource vnet 'Microsoft.Network/virtualNetworks@2023-05-01' = {
name: 'myVnet'
location: resourceGroup().location
properties: {
addressSpace: {
addressPrefixes: [ '10.0.0.0/16' ]
}
subnets: [
{
name: 'appservice-subnet'
properties: {
addressPrefix: '10.0.1.0/24'
delegations: [
{
name: 'appServiceDelegation'
properties: {
serviceName: 'Microsoft.Web/serverFarms'
}
}
]
}
}
]
}
}
resource plan 'Microsoft.Web/serverfarms@2023-12-01' = {
name: 'myAppServicePlan'
location: resourceGroup().location
sku: {
name: 'P0v3'
capacity: 1
tier: 'PremiumV3'
}
}
resource webapp 'Microsoft.Web/sites@2023-12-01' = {
name: 'myWebApp'
location: resourceGroup().location
properties: {
serverFarmId: plan.id
virtualNetworkSubnetId: vnet.properties.subnets[0].id
httpsOnly: true
}
}
Met deze configuratie draait de backend van een webapp in het vNET en kan het dus ook alle resources binnen het vNET benaderen. Denk hierbij aan databases, storage accounts of andere web apps.
Belangrijk is dat de voorkant, het webadres van de webapp, nog steeds publiek staat en dus door iedereen kan worden benaderd. Om dit ook in het vNET te krijgen moeten we een private endpoint toevoegen.
Paas diensten in je Vnet met Private Endpoints
Een Private Endpoint is een netwerkinterface die een Azure PaaS-dienst (zoals een Storage Account, Azure SQL Database of Web App) via een privé-IP-adres in jouw VNET beschikbaar maakt. Verkeer naar die dienst verloopt dan volledig via het private netwerk, zonder over het publieke internet te gaan.
Met een private endpoint:
- Verhoog je de beveiliging doordat de dienst niet meer publiek bereikbaar is.
- Verminder je latency en vergroot je betrouwbaarheid door verkeer intern te houden.
- Kun je via NSG’s en route tables bepalen wie er toegang heeft.
Private Endpoint aanmaken in Azure Portal
- Ga naar de resource waarvoor je een private endpoint wilt maken (bijvoorbeeld een Web App).
- Ga naar Networking → Private endpoint connections → + Add.
- Geef een naam, resource group en regio op.
- Selecteer het VNET en subnet waar het private endpoint in moet komen.
- Bevestig en maak de resource aan.
Private Endpoint toevoegen via Bicep
Onderstaand voorbeeld maakt een private endpoint voor een Web App in een eerder aangemaakt VNET en subnet.
resource privateEndpoint 'Microsoft.Network/privateEndpoints@2023-05-01' = {
name: 'myWebAppPrivateEndpoint'
location: resourceGroup().location
properties: {
subnet: {
id: vnet.properties.subnets[0].id
}
privateLinkServiceConnections: [
{
name: 'myWebAppConnection'
properties: {
privateLinkServiceId: webapp.id
groupIds: [ 'sites' ]
}
}
]
}
}
resource privateDnsZone 'Microsoft.Network/privateDnsZones@2020-06-01' = {
name: 'privatelink.azurewebsites.net'
location: 'global'
}
resource vnetLink 'Microsoft.Network/privateDnsZones/virtualNetworkLinks@2020-06-01' = {
name: 'myDnsZoneLink'
parent: privateDnsZone
location: 'global'
properties: {
virtualNetwork: {
id: vnet.id
}
registrationEnabled: false
}
}
Met deze configuratie is de Web App alleen via het private IP in het VNET bereikbaar en niet meer via het publieke internet.
DNS resolution met Private DNS Zones
Wanneer je een private endpoint maakt, krijgt deze een privé-IP-adres in je VNET. Standaard blijft de publieke DNS-resolutie echter naar het publieke IP van de service verwijzen. Om ervoor te zorgen dat clients binnen het VNET automatisch het private IP gebruiken, maak je gebruik van Private DNS Zones.
Met een private DNS zone kun je domeinnamen van Azure PaaS-diensten (zoals *.privatelink.azurewebsites.net of *.privatelink.database.windows.net) vertalen naar de juiste private IP’s die bij jouw private endpoints horen.
Hierdoor kunnen Azure resources zoals een Web App automatisch jouw Azure resources via het vnet benaderen, zonder dat je hiervoor iets handmatig hoeft te configureren
Stappen in Azure Portal:
- Ga naar Create a resource → zoek naar Private DNS Zone.
- Geef als naam bijvoorbeeld
privatelink.azurewebsites.net.
- Koppel de DNS zone aan je VNET via een Virtual Network Link.
- Controleer of de A-record voor jouw private endpoint aanwezig is (dit gebeurt vaak automatisch bij het aanmaken van de verbinding).
Of via bicep:
resource privateDnsZone 'Microsoft.Network/privateDnsZones@2020-06-01' = {
name: 'privatelink.azurewebsites.net'
location: 'global'
}
resource vnetLink 'Microsoft.Network/privateDnsZones/virtualNetworkLinks@2020-06-01' = {
name: 'myDnsZoneLink'
parent: privateDnsZone
location: 'global'
properties: {
virtualNetwork: {
id: vnet.id
}
registrationEnabled: false
}
}
Door de private DNS zone en VNET te koppelen, wordt naamresolutie voor je private endpoints automatisch en correct afgehandeld voor alle resources in dat VNET.
NSGs, de verkeersregelaars in je VNET
Een Network Security Group (NSG) is in Azure de manier om netwerkverkeer te filteren. Het werkt vergelijkbaar met een firewall: je maakt regels die bepalen welk verkeer is toegestaan of geblokkeerd, gebaseerd op criteria zoals bron-IP, doel-IP, poort en protocol.
Een NSG kan je toepassen open een subnet of een individuele Netwerkinterface.
In de praktijk wil je meestal een NSG op subnetniveau toepassen, omdat dit centraal beheer mogelijk maakt en consistentie bewaart voor alle resources in dat subnet.
Om dit te doen kun je het volgende stukje bicep gebruiken.
resource nsg 'Microsoft.Network/networkSecurityGroups@2023-05-01' = {
name: 'mySubnetNsg'
location: resourceGroup().location
properties: {
securityRules: [
{
name: 'AllowHTTPS'
properties: {
priority: 100
direction: 'Inbound'
access: 'Allow'
protocol: 'Tcp'
sourcePortRange: '*'
destinationPortRange: '443'
sourceAddressPrefix: '*'
destinationAddressPrefix: '*'
}
}
]
}
}
resource subnetNsgAssoc 'Microsoft.Network/virtualNetworks/subnets/networkSecurityGroups@2023-05-01' = {
name: '${vnet.name}/mySubnet/networkSecurityGroups'
properties: {
id: nsg.id
}
}
Een belangrijke valkuil is dat een NSG niet standaard wordt toegepast op een private endpoint, zelfs niet als deze op het subnet is toegepast. Dit komt omdat private endpoints het verkeer via het Microsoft backbone-netwerk afhandelen. Wil je toch NSG-regels toepassen op verkeer van en naar een private endpoint, dan moet je Private Endpoint Network Policies inschakelen voor dat subnet.
Wil je dat deze NSG ook geldt voor private endpoints, zet dan in het subnet de eigenschap privateEndpointNetworkPolicies op Enabled. Dit kan via de portal of als extra property in je Bicep-subnetdefinitie.
Conclusie
Soms lijkt iets lastig, maar met een baar basisbegrippen valt alles al snel op zijn plek. Voor mij was dit zeker het geval met Azure networking, en ik hoop voor jou ook.