Microsoft AZ-700: Azure Virtual WAN en Hub-Spoke — Studiegids
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.
Virtual WAN versus klassieke hub-and-spoke: kies het juiste transitmodel
Voor het ontwerpen van wereldwijde transit moet u kiezen tussen Azure Virtual WAN (vWAN) en een traditionele hub-and-spoke-architectuur opgebouwd uit VNets, NVA’s en peering. Virtual WAN biedt een door Microsoft beheerde wereldwijde backbone met vHubs die native VPN-, ExpressRoute- en P2S-connectiviteit hosten en geautomatiseerde route-propagatie, site-to-site-schaling en integraties met SD-WAN-partners ondersteunen. Voor organisaties die veel filiaalverbindingen, wereldwijde routering en een eenvoudig operationeel model nodig hebben, vermindert vWAN het orkestratiewerk en verbetert het de veerkracht. Een handmatige hub-and-spoke (een VNet met een Azure Firewall of een NVA van derden in een centrale hub en gekoppelde spokes) biedt daarentegen maximale controle over de pakketstroom, aangepaste NVA-functies en vaak lagere ‘steady-state’-kosten voor kleine implementaties. De belangrijkste afwegingen zijn doorvoersnelheid en voorspelbaarheid versus granulaire controle: vWAN-hubs abstraheren veel details en bieden een bijna wereldwijde schaal, maar brengen beheerde servicekosten met zich mee en bieden minder flexibele aanpassingen van het pakketpad. Veelvoorkomende valkuilen zijn de aanname dat vWAN automatisch transitieve peering biedt naar VNets die niet expliciet zijn verbonden; elke spoke of VNet moet verbonden zijn en geassocieerd worden met de route-tabellen van de hub. Een andere veelgemaakte fout is het negeren van de governance- en subnetnaamgevingsbeperkingen (bijvoorbeeld de vereiste AzureFirewallSubnet voor Azure Firewall) die geautomatiseerde implementaties kunnen breken als ze niet worden gevolgd.
Beveiligde virtuele hub, Azure Firewall en NVA-integratie
Het ‘secured virtual hub’-model voegt inspectie en beleid toe aan vWAN door Azure Firewall (of een NVA van derden) en Firewall Manager te integreren om beveiliging, NAT en routering voor spokes en on-premise locaties te centraliseren. Azure Firewall moet worden geïmplementeerd in het speciale AzureFirewallSubnet en u moet een keuze maken tussen de Azure Firewall SKU’s op basis van de functies. Plan de route-tabellen zorgvuldig: de route-tabellen van de hub regelen de verkeersstromen naar spokes, VPN-sites, P2S en het internet. Om verkeer via ‘force-tunneling’ naar een NVA te sturen, associeert u de spoke-verbinding met een route-tabel van de hub die 0.0.0.0/0 naar de NVA/Firewall leidt. Houd rekening met hoge beschikbaarheid en doorvoersnelheid: Azure Firewall is zonaal en ondersteunt autoscaling met de Standard en Premium SKU’s, maar Premium is vereist voor TLS-inspectie en IDPS. Vermijd het plaatsen van Application Gateway- of Private Link-eindpunten in subnets die worden gedeeld met de firewall-infrastructuur; deze hebben hun eigen subnets nodig. Let op uitputting van NAT- en SNAT-poorten bij grootschalige uitgaande verkeersstromen; implementeer SNAT-pooling, Azure Firewall met DNAT-regels, of gebruik NAT Gateway waar van toepassing.
- Azure Firewall Standard vs Premium: Standard ondersteunt stateful F/W, FQDN-filtering, basis SNAT/DNAT; Premium voegt TLS-inspectie, IDPS, URL-filtering en uitsluitingen voor ‘fully qualified domain name’ (FQDN) tags toe.
- Load Balancer Basic vs Standard: Standard ondersteunt zone-redundantie, backend health probes en is vereist voor Private Link service ILB; Basic mist zonale veerkracht en heeft minder strikte beveiligingsregels.
- VPN Gateway SKU’s: VpnGw1/2/3 (toenemende doorvoersnelheid en gelijktijdige tunnels); gebruik hogere tiers voor meer S2S-tunnels of een hogere totale doorvoersnelheid.
Patronen voor privéconnectiviteit: Private Link, Private Endpoints en service-eindpunten
Private Link en private endpoints bieden eersteklas toegang tot PaaS zonder verkeer over het internet te routeren; service-eindpunten beveiligen de toegang tot services, maar laten uitgaand verkeer via de publieke service-backbone lopen. Gebruik een private endpoint wanneer u per resource privé-IP’s en DNS-integratie nodig heeft; gebruik service-eindpunten wanneer u eenvoudigere toegangscontrole op subnetniveau nodig heeft en het acceptabel vindt dat uitgaand verkeer via de service-backbone wordt blootgesteld. Belangrijke operationele details omvatten DNS-resolutie: private endpoints vereisen het bijwerken van on-premise DNS of Azure DNS Private Zones zodat clients het privé-IP-adres kunnen resolven; ‘conditional forwarders’ naar on-premise DNS-servers zijn gebruikelijk voor S2S-verbonden netwerken. Scenario’s met Private Link service over meerdere abonnementen worden ondersteund als de resources zich in dezelfde Azure AD-tenant bevinden; implementeer de Private Link service achter een Standard internal Load Balancer (ILB) voor schaalbaarheid en zone-redundantie. Een veelvoorkomende valkuil is het gebruik van een Basic ILB of een onjuiste SKU, wat de backend-health en schaalbaarheid beperkt. Gebruik voor een Private Link service die een hoog verbindingsvolume ondersteunt een Standard ILB, scale-set backends en overweeg meerdere endpoint-NIC’s per backend-instantie. Overweeg ook DDoS-bescherming: schakel DDoS Protection Standard in voor publiek toegankelijke NIC’s en plan voor schaling van SNAT-poorten en NAT Gateway waar veel uitgaande verbindingen ontstaan.
vWAN hub-routetabellen en praktisch routeontwerp
vWAN gebruikt hub-routetabellen om verkeer te sturen tussen verbonden spokes, on-premise locaties en het internet. Elke verbinding (site, VNet, P2S) kan worden gekoppeld aan een hub-routetabel; routeprioriteiten en propagatieregels bepalen de uiteindelijke forwarding. Een goed ontwerp begint met een standaard hub-routetabel die internetverkeer doorstuurt naar Azure Firewall of een NVA, en gespecialiseerde routetabellen voor vestigingen die een on-premise breakout vereisen. BGP vanaf on-premise VPN-apparaten propageert prefixes naar de hub, en u kunt deze herdistribueren naar spokes of filteren met routetabellen. Een veelvoorkomende valkuil zijn conflicterende user-defined routes (UDR’s) in spoke VNets die proberen de hub-propagatie te overschrijven; in vWAN hebben hub-routetabellen voorrang voor interconnecties, maar UDR’s op spokes beïnvloeden nog steeds de lokale egress. Voor forced tunneling koppelt u spoke-verbindingen aan een hub-routetabel die 0.0.0.0/0 naar het door u gekozen inspectieapparaat leidt. Monitor en plan voor routelimieten: vWAN-hubs hebben een maximaal aantal geleerde en geadverteerde prefixes — ontwerp prefix-summarization en BGP-communities of filters om binnen de limieten te blijven. Test altijd DNS-resolutie en split-DNS voor private endpoints, en documenteer het failover-gedrag voor multi-hub active/active ontwerpen om te voldoen aan de resilience-SLA’s.
Praktisch Probleem: Use-Case Scenario
Scenario: Contoso Manufacturing beheert een wereldwijde Azure-omgeving met een bestaande hub-and-spoke VNet-architectuur in twee regio’s, meerdere on-premise locaties verbonden via SD-WAN, en de eis om beveiliging te centraliseren en private PaaS-connectiviteit over abonnementen heen te bieden.
Uitdaging: Ze hebben een schaalbare, beheerde wereldwijde transit nodig die inspectie centraliseert (TLS-inspectie, IDPS), veel vestigingsverbindingen via SD-WAN ondersteunt, en verschillende storage- en database-PaaS-resources privé beschikbaar stelt aan spokes en on-premise, zonder deze publiekelijk bloot te stellen.
Aanbevolen Aanpak:
- Implementeer Azure Virtual WAN (vWAN) en maak beveiligde virtuele hubs in elke regio. Schakel in elke hub Azure Firewall Premium in (voor TLS-inspectie en IDPS) en integreer met Firewall Manager. Koppel de hub aan de vWAN-partner SD-WAN-verbindingen voor een directe on-ramp voor vestigingen.
- Configureer hub-routetabellen om internetverkeer en cross-region verkeer naar Azure Firewall Premium te leiden; maak gespecialiseerde routetabellen voor vestigingen die on-premise egress moeten gebruiken. Gebruik BGP vanaf SD-WAN om on-premise prefixes te adverteren in vWAN en pas prefix-filters toe om ‘route bloat’ te voorkomen.
- Voor PaaS-diensten, provisioneer Private Link-services in een speciaal VNet per regio achter een Standard Internal Load Balancer, en stel Private Endpoints beschikbaar in spoke VNets en on-premise via vWAN-connectiviteit. Gebruik Azure DNS Private Zones en conditional forwarders om on-premise resolutie te garanderen.
- Schakel DDoS Protection Standard in op publieke endpoints, implementeer NAT Gateway voor grote uitgaande SNAT-behoeften op spokes, en monitor SNAT/DNAT-statistieken. Gebruik Firewall Manager-beleidsregels voor gecentraliseerde distributie van regels en configureer logging naar een centrale Log Analytics-werkruimte.
Rationale: Deze aanpak maakt gebruik van vWAN voor schaalbare connectiviteit van vestigingen en wereldwijde transit, gebruikt Azure Firewall Premium voor de gecentraliseerde, geavanceerde inspectie die vereist is door het beveiligingsbeleid, en Private Link voor veilige PaaS-toegang zonder publieke blootstelling — een balans tussen beheerbaarheid, beveiliging en operationele schaal.
← Netwerkmonitoring en probleemoplossing · Alle domeinen
Oefen deze vragen → · Getimede oefening op ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Slaag voor je examen →