Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Een plat netwerk is de eenvoudigste Azure netwerktopologie: één virtueel netwerk met meerdere subnetten die als host fungeren voor één workload. In dit artikel wordt uitgelegd wanneer u dit patroon gebruikt en hoe u dit implementeert.
Wat in dit artikel wordt behandeld
In dit artikel wordt de eenvoudigste Azure netwerktopologie beschreven: één virtueel netwerk met meerdere subnetten die als host fungeren voor één workload. Gebruik dit patroon wanneer u één toepassing hebt die wordt beheerd door één team en u geen gedeelde services nodig hebt, zoals een centrale firewall of VPN-gateway.
Wie heeft dit artikel nodig
Lees dit artikel als:
- U implementeert uw eerste workload in Azure.
- Eén team is eigenaar van en beheert alle resources.
- U hebt geen gedeelde netwerkservices (firewall, Bastion, gateway) nodig voor meerdere workloads.
- U wilt het eenvoudigste netwerk dat nog steeds isolatie en beveiliging op subnetniveau biedt.
Lift-and-shiftfocus: Eén flat VNet met een subnet per component is vaak de juiste eerste stap voor het herhosten van één workload in één regio.
Moderniseringsfocus: Gebruik een plat netwerk voor een vroege PaaS-pilot of één gemoderniseerde workload, en ontwerp de subnetten zodanig dat het netwerk later probleemloos kan doorgroeien naar een hub-and-spoke-architectuur wanneer u gedeelde services of een tweede regio toevoegt.
Focus op meerdere clouds: Gebruik een plat VNet als één Azure voet aan de grond tijdens migratie tussen clouds: land eerst de workload en plan vervolgens de adresruimte en segmentatie, zodat deze kan worden gekoppeld aan een hub of Virtual WAN naarmate het ontwerp volwassen wordt.
Azure services en functies
De platte netwerktopologie maakt gebruik van deze kern-Azure-services:
| Dienst | Rol in deze topologie |
|---|---|
| Azure Virtual Network | Biedt een privé-, geïsoleerde adresruimte voor uw workload. Een virtueel netwerk is gericht op één Azure regio. |
| Subnetten + netwerkbeveiligingsgroepen (NSG's) | Subnetten scheiden applicatielagen van elkaar. NSG's filteren inkomend en uitgaand verkeer bij elke subnetgrens. NSG’s zijn statusbehoudend: antwoordverkeer voor toegestane verbindingen is automatisch toegestaan. |
| Azure Privé-DNS zone | Biedt interne naamomzetting voor resources binnen het virtuele netwerk. Koppel de zone waarvoor automatische registratie is ingeschakeld, zodat VM's automatisch DNS-records krijgen. |
| Gatewaysubnet(optioneel) | Host een VPN- of ExpressRoute-gateway als u één verbinding met een on-premises netwerk nodig hebt. |
Hoe kies je: plat blijven of overstappen op een hub-and-spoke-model?
Gebruik de volgende beslissingstabel om te bepalen of de platte topologie geschikt is voor uw omgeving of dat u in plaats daarvan een hub-and-spoke-topologie moet gebruiken.
| Condition | Recommendation |
|---|---|
| Eén workload, één team, geen gedeelde services | Blijf plat: dit artikel is van toepassing |
| Een tweede onafhankelijke workload heeft een eigen netwerkisolatie nodig | Afgestudeerd aan hub-and-spoke-topologie |
| U hebt een gedeelde firewall, VPN-gateway of Azure Bastion tussen workloads nodig | Afgestudeerd aan hub-and-spoke-topologie |
| Beveiligingsbeleid moet centraal worden beheerd voor meerdere workloads | Afgestudeerd aan hub-and-spoke-topologie |
Tip
Als u verwacht dat u binnen 6 tot 12 maanden een tweede workload toevoegt, overweeg dan om vanaf het begin hub-and-spoke te gebruiken. De overhead is minimaal omdat u slechts één extra virtueel netwerk en een peeringverbinding toevoegt. Deze aanpak voorkomt later een verstorende migratie.
Ontwerpoverwegingen
Focus op lift-and-shift en plat netwerkontwerp
- Gebruik één VNet met een subnet voor elk toepassingsonderdeel (web, app, gegevens) om een typische indeling van on-premises drie lagen te spiegelen met minimaal herontwerp.
- Pas NSG’s toe tussen subnetten om uw bestaande segmentatie na te bootsen, en stem de adresruimte af op on-premises-adresbereiken om overlap te voorkomen.
- Houd het plat als één team verantwoordelijk is voor de workload en je geen gedeelde firewall-, gateway- of Bastion-services nodig hebt.
- Plan de migratie naar een hub-and-spoke-architectuur voordat u een tweede workload toevoegt, zodat gedeelde services in een hub worden ondergebracht in plaats van later achteraf te moeten worden ingepast.
Focus op plat netwerkontwerp moderniseren
- Gebruik een plat netwerk voor een vroege PaaS-pilot of één gemoderniseerde workload: plaats de app-lagen in subnetten en bereik Azure PaaS via privé-eindpunten in een toegewezen subnet.
- Reserveer van tevoren toegewezen subnetten voor de platformservices die u later toevoegt, zoals Application Gateway en privé-eindpunten, zodat het netwerk kan groeien zonder heradressering.
- Pas NSG's en toepassingsbeveiligingsgroepen toe op laag, zodat uw segmentatie al aanwezig is als de workload later een spoke wordt in een hub-and-spoke-ontwerp.
- Zorg ervoor dat de adresruimte niet overlapt met die van uw andere regio's en VNets, zodat u later een peering kunt opzetten of naar een hub kunt migreren zonder opnieuw te hoeven nummeren.
Ontwerpfocus voor platte netwerken in meerdere clouds
- Gebruik een plat VNet als één Azure voet aan de grond tijdens migratie tussen clouds: land eerst de workload en koppel vervolgens connectiviteit vanuit een hub als het ontwerp volwassen wordt.
- Plan de adresruimte van het platte VNet zo dat deze niet overlapt met AWS-VPC’s en Google Cloud-netwerken, zodat het later zonder adresvertaling kan deelnemen aan IPsec- of interconnectroutering.
- Behoud tiersegmentatie met NSG's, zodat het beveiligingsniveau van de workload behouden blijft wanneer de workload een spoke achter een beveiligde Virtual WAN-hub wordt.
- Standaardiseer naamgeving en taggen van subnetten zodat deze overeenkomen met uw andere clouds, zodat de workload gemakkelijk te correleren blijft tijdens en na de migratie.
Prerequisites
Voordat u deze topologie implementeert:
- Een Azure-abonnement met machtigingen voor het maken van virtuele netwerken en NSG's.
- Een geplande IP-adresruimte. Een /16-adresruimte biedt 65.536 adressen. Dit is een gemeenschappelijk uitgangspunt voor één workload. Azure reserveert 5 adressen per subnet voor intern gebruik. Zie IP-adressering plannen voor gedetailleerde richtlijnen.
- Een goed begrip van uw toepassingslagen (bijvoorbeeld web, toepassing en gegevens), zodat u deze kunt toewijzen aan subnetten. Zie Virtuele netwerken en subnetten ontwerpen voor richtlijnen voor het ontwerpen van subnetten.
Netwerkindeling
Een platte netwerktopologie volgt deze structuur:
- Eén virtueel netwerk met één adresruimte (bijvoorbeeld 10.0.0.0/16).
-
Meerdere subnetten: één per toepassingslaag of -onderdeel:
- Subnet van weblaag (bijvoorbeeld 10.0.1.0/24).
- Subnet van toepassingslaag (bijvoorbeeld 10.0.2.0/24).
- Subnet van gegevenslaag (bijvoorbeeld 10.0.3.0/24).
- Gatewaysubnet (optioneel, bijvoorbeeld 10.0.255.0/27).
- NSG's die zijn gekoppeld aan elk subnet met regels die alleen het verkeer toestaan dat elke laag nodig heeft.
- Eén Privé-DNS zone gekoppeld aan het virtuele netwerk waarvoor automatische registratie is ingeschakeld.
Note
Plan uw IP-adresbereiken zorgvuldig. Als u later migreert naar een hub-and-spoke-topologie, moeten de virtuele spoke-netwerken niet-overlappende CIDR-bereiken hebben met de hub. Als u een goed gestructureerd adresschema kiest, voorkomt u nu conflicten tijdens de migratie.
Beveiligingsoverwegingen
Pas deze beveiligingsprocedures toe op uw platte netwerk:
- NSG's op elk subnet. Begin met een basislijn voor weigeren van alle inkomende verbindingen en voeg specifieke regels voor toestaan toe voor legitiem verkeer tussen lagen. U kunt bijvoorbeeld HTTPS van de weblaag naar de toepassingslaag toestaan en SQL van de toepassingslaag naar de gegevenslaag toestaan.
- Geen openbare IP-adressen rechtstreeks op VM's. Services beschikbaar maken via een load balancer of Application Gateway. Gebruik Azure Bastion voor beheerderstoegang.
- Privé-DNS voor interne resolutie. Privé-DNS zones voorkomen dat interne hostnamen worden blootgesteld via openbare DNS-query's.
- Gateway-subnetisolatie. Als u een VPN- of ExpressRoute-gateway toevoegt, plaatst u deze in een toegewezen subnet (met de naam
GatewaySubnet). NSGs in het gateway-subnet worden niet ondersteund. Als u een NSG aan dit subnet koppelt, werkt uw virtuele netwerkgateway mogelijk niet meer zoals verwacht.
Important
Wanneer u een NSG-regel verwijdert die een verbinding toestaat, blijven bestaande actieve verbindingen ononderbroken. Alleen nieuwe verbindingen die overeenkomen met de verwijderde regel, worden geblokkeerd.
Verwante artikelen
De volgende artikelen bieden meer informatie over verwante onderwerpen:
- Virtuele netwerken en subnetten ontwerpen: de grootte en plaatsing van subnetten voor uw workloadlagen
- IP-adressering plannen: planning van adresruimte en CIDR-selectie
- Netwerkbeveiligingsgroepen ontwerpen: NSG-regelontwerp en toepassingsbeveiligingsgroepen
- Hub-and-spoke-topologie: de volgende topologie die moet worden gebruikt wanneer uw netwerk groeit
- DDoS-beveiliging: als uw workload openbare eindpunten beschikbaar maakt
Meer informatie
Zie voor meer informatie over de Azure services die in deze topologie worden gebruikt:
- Wat is Azure Virtual Network?
- Overzicht van netwerkbeveiligingsgroepen
- Wat is Azure Privé-DNS?
- Planning van virtueel netwerk
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:
Ontwerp uw hub-and-spoke-topologie: De meeste lift-and-shift-migraties ontgroeien snel een plat netwerk. Plan gecentraliseerde gedeelde services vanaf het begin.
Vervolgens in uw moderniseringstraject:
Ontwerp uw hub-and-spoke-topologie: gemoderniseerde workloads met meerdere services, beveiligingscontroles en teams hebben hub-and-spoke nodig vanaf de eerste dag.
De volgende stap in uw cross-cloudtraject:
Plan uw architectuur voor connectiviteit tussen clouds: cross-cloudomgevingen hebben transitarchitectuur nodig, niet platte netwerken. Ontwerp uw multicloudconnectiviteitsmodel.