Microsoft AZ-700: Azure Virtual Network-ontwerp — Studiegids

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Onderdeel van de Microsoft Azure Network Engineer AZ-700 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Adresruimte en subnetplanning

Een gedisciplineerd IP-adresplan voorkomt toekomstig herstelwerk en vermijdt conflicten met on-premises netwerken of andere VNets. Gebruik hiërarchische CIDR-blokken (bijvoorbeeld één /16 per belangrijke bedrijfseenheid, /24 per VNet, /26–/22 per subnet afhankelijk van de rol) en reserveer aaneengesloten bereiken voor uitbreiding, peering en VPN/S2S site-toewijzingen. Azure dwingt naam- en subnetvereisten af voor verschillende platformdiensten: GatewaySubnet moet bestaan (en groot genoeg zijn voor de VPN-gateway en diens schaalunits), AzureFirewallSubnet moet toegewezen zijn en de naam AzureFirewallSubnet hebben, en AzureBastionSubnet moet een toegewezen subnet van /27 of groter zijn. Application Gateway en veel network virtual appliances (NVA’s) vereisen ook toegewezen subnets (zonder andere resources). Plan voor niet-overlappende adresruimtes tussen gepeerde VNets en on-premises bereiken; overlappende adresruimtes verbreken peering, VPN en routering. Overweeg subnetdelegatie bij het implementeren van platformdiensten (AKS, Azure Database managed instances) en vermijd het plaatsen van NSG’s of UDR’s die conflicteren met de vereiste platformroutes voor die diensten. Een veelvoorkomende valkuil is het te klein maken van de GatewaySubnet of AzureFirewallSubnet; deze diensten kunnen schalen en hebben na verloop van tijd extra IP’s nodig. Afwegingen: kleinere CIDR’s besparen adresruimte maar verhogen het risico op toekomstige herconfiguratie; grotere CIDR’s kosten niets maar vergroten het beheeroppervlak. Documenteer alle toewijzingen en reserveer blokken voor PaaS private endpoints, jump hosts, monitoring agents en egress NAT-capaciteit.

VNet-peering, gateway-transit en routeprioriteit

VNet-peering biedt connectiviteit met lage latentie en hoge bandbreedte, maar is niet transitief: verkeer van een gepeerde spoke wordt niet automatisch via een tweede gepeerd VNet gerouteerd om on-premises te bereiken. Om on-premise connectiviteit te centraliseren, moet u een hub-VNet implementeren met een VPN Gateway of ExpressRoute-gateway. Configureer de hub-peering met allowGatewayTransit ingeschakeld en configureer de spoke-peering met useRemoteGateways ingeschakeld; de VPN Gateway mag alleen in de hub bestaan. Onthoud dat peering niet-overlappende adresruimtes vereist en zowel regionale als globale peering ondersteunt (globale peering brengt kosten voor gegevensoverdracht en een iets hogere latentie met zich mee). Routeprioriteit is belangrijk: user-defined routes (UDR’s) hebben voorrang op via BGP geleerde routes en systeemroutes; BGP-routes hebben voorrang op systeemroutes. Als u ‘forced tunneling’ nodig heeft voor egress-inspectie, maak dan UDR’s aan die verwijzen naar een Virtual Appliance (NVA) of Azure Firewall, en adverteer vervolgens de juiste routes terug naar on-premise via BGP indien nodig. Veelvoorkomende valkuilen zijn het vergeten in te stellen van allowGatewayTransit op de hub of useRemoteGateways op de spokes, het niet opnieuw downloaden van P2S-clientconfiguraties na het toevoegen van spokes (P2S-clients hebben bijgewerkte routes nodig), en aannemen dat peering transitief is. Kies VPN Gateway SKU’s op basis van doorvoersnelheid en P2S-functies: overweeg VpnGw1/2/3 voor productie-P2S en BGP; de Basic-SKU mist veel functies.

VPN Gateway SKU’s: VpnGw1 — gemiddelde doorvoersnelheid, ondersteunt OpenVPN/IKEv2/P2S; VpnGw2 — hogere doorvoersnelheid en TLS-schaling; VpnGw3 — hoogste doorvoersnelheid en grootste schaal. Basic — beperkte functies en niet aanbevolen voor hub-scenario’s.

Service endpoints vs. private endpoints en DNS-implicaties

Service endpoints breiden de identiteit van uw VNet uit naar Azure PaaS-diensten (Storage, SQL, Cosmos DB), zodat verkeer de backbone van Microsoft gebruikt terwijl het publieke eindpunt van de dienst beveiligd is voor geselecteerde subnets. Private Endpoints plaatsen een netwerkinterface in uw subnet die wordt gekoppeld aan het privé-IP-adres van de PaaS-resource, wat zorgt voor échte privéconnectiviteit. Kies service endpoints als u eenvoudige toegangscontrole op subnetniveau wilt zonder DNS-wijzigingen; kies private endpoints als u toegang per resource, isolatie op VNet-niveau of het volledig uitschakelen van publieke netwerktoegang vereist. Private endpoints creëren een ENI en moeten worden gekoppeld aan een private DNS-zone (privatelink.<service>.azure.com) of vereisen handmatige DNS A-records — een veelvoorkomende valkuil is het negeren van DNS, waardoor clients het publieke IP-adres oplossen in plaats van het private endpoint. Houd er ook rekening mee dat private endpoints een IP-adres uit het doelsubnet verbruiken; plan de IP-capaciteit. Service endpoints verwijderen het publieke eindpunt niet — om een storage account volledig af te sluiten, moet u de publieke netwerktoegang uitschakelen nadat u een private endpoint heeft ingeschakeld. Kosten- en operationele afwegingen: private endpoints verhogen het beheer (DNS per resource en goedkeuringen) en de operationele complexiteit enigszins, maar bieden sterkere isolatie; service endpoints zijn eenvoudiger en goedkoper, maar minder granulair.

NAT-gateway, Azure Firewall en de afwegingen bij route-ontwerp

Voor voorspelbare uitgaande SNAT en vereenvoudigd egress-beheer, implementeer Azure Virtual Network NAT (Standard NAT Gateway) op subnets of NIC’s en koppel er Standard public IP’s of prefixes aan (alleen standard SKU). NAT Gateway neemt het beheer van tijdelijke poorten over; als u veel uitgaande verbindingen verwacht, koppel dan meerdere Public IP-prefixes om het aantal beschikbare SNAT-poorten te vergroten en poortuitputting te voorkomen—iets wat vaak voorkomt bij veel VM’s of container-hosts. Azure Firewall biedt gecentraliseerde, volledig beheerde stateful inspectie, threat intelligence en filtering op applicatie/FQDN-niveau; kies Azure Firewall Standard voor fundamentele filtering en de Premium SKU voor TLS-inspectie, IDPS en uitgebreide threat-mogelijkheden. Network virtual appliances (NVA’s van derden) bieden een rijkere functionaliteit of kostenalternatieven, maar vereisen beheer, HA-configuratie en planning voor schaalbaarheid. UDR’s die verwijzen naar een VirtualAppliance of Internet/NAT moeten worden geëvalueerd ten opzichte van de systeemroutes van Azure, omdat onjuiste UDR’s het verkeer van platformdiensten kunnen verstoren (bijvoorbeeld door service-eindpuntverkeer of door het platform beheerde health probes te blokkeren). Voor hoge beschikbaarheid en prestaties, overweeg zone-redundante SKU’s (Application Gateway v2, Firewall in Availability Zones) en autoscaling-mogelijkheden in plaats van appliances met vaste kosten. Veelvoorkomende valkuilen: een NAT koppelen aan zowel een subnet als een NIC leidt tot onverwachte prioriteit; vergeten dat NAT Standard Public IP(’s) vereist; de AzureFirewallSubnet onjuist benoemen en dimensioneren; en aannemen dat UDR’s worden genegeerd — ze overschrijven namelijk de systeemroutes.

Praktijkprobleem: Gebruiksscenario

Scenario: Contoso Enterprises beheert een hub-and-spoke Azure-netwerk. De hub in West US host een ExpressRoute-gateway en een VpnGw2 (GatewaySubnet). Verschillende spokes bevatten applicatiesubnetten en private endpoints voor PaaS-diensten. Medewerkers op afstand maken verbinding met de hub via een Point-to-Site (P2S) VPN.

Uitdaging: Gebruikers op afstand hebben toegang tot resources in de hub, maar kunnen na recente toevoegingen van spokes geen VNet-resources in de spokes bereiken. Bovendien tonen sommige P2S-clients verouderde route-sets.

Aanbevolen aanpak:

Zorg ervoor dat in het hub-VNet de VPN-gateway een VpnGw2 is, geïmplementeerd in een correct gedimensioneerde GatewaySubnet (minimaal /27); valideer dat dit de enige gateway is in de peered topologie en dat ExpressRoute naast elkaar bestaat via route-uitwisseling.
Stel op de hub-naar-spoke-peering allowGatewayTransit = true in aan de hub-zijde. Stel op elke spoke-peering useRemoteGateways = true in en zorg ervoor dat de adresruimtes niet overlappen.
Genereer en distribueer de bijgewerkte P2S VPN-clientconfiguratie opnieuw vanaf de hub VPN-gateway (inclusief IKEv2/OpenVPN) en verplicht gebruikers op afstand om de client opnieuw te installeren, zodat hun routetabellen de nieuwe spoke-prefixes bevatten.
Als spokes uitgaand verkeer via de hub moeten routeren voor inspectie, voeg dan UDR’s toe aan de routetabellen van de spokes die 0.0.0.0/0 doorsturen naar de virtuele appliance in de hub of naar Azure Firewall (geïmplementeerd in de AzureFirewallSubnet) en adverteer de benodigde routes terug via BGP op ExpressRoute/VPN.

Rationale: Het inschakelen van gateway transit met useRemoteGateways centraliseert on-prem en P2S-routing via de hub-gateway zonder extra gateways te creëren. Het opnieuw uitgeven van P2S-clientconfiguraties werkt de routetabellen van de clients bij zodat nieuwe spoke-prefixes bereikbaar zijn. UDR’s en BGP zorgen voor gecontroleerde egress en zichtbaarheid voor inspectie.

← ExpressRoute en WAN-connectiviteit · Alle domeinen · Hybride netwerken →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →