Platt nätverkstopologi för en enda arbetslast

Ett platt nätverk är den enklaste Azure nätverkstopologi: ett virtuellt nätverk med flera undernät som är värdar för en enda arbetsbelastning. Den här artikeln förklarar när du ska använda det här mönstret och hur du implementerar det.

Vad den här artikeln beskriver

Den här artikeln beskriver den enklaste Azure nätverkstopologin: ett enda virtuellt nätverk med flera undernät som är värdar för en arbetsbelastning. Använd det här mönstret när du har ett enda program som hanteras av ett team och du inte behöver delade tjänster som en central brandvägg eller VPN-gateway.

Vem behöver den här artikeln

Läs den här artikeln om:

  • Du driftsätter din första arbetsbelastning i Azure.
  • Ett enda team äger och driver alla resurser.
  • Du behöver inte delade nätverkstjänster (brandvägg, Bastion, gateway) för flera arbetsbelastningar.
  • Du vill ha det enklaste nätverket som fortfarande tillhandahåller isolering och säkerhet på undernätsnivå.

Lift-and-shift-fokus: Ett enda platt VNet med ett undernät per komponent är ofta rätt första steg för att flytta en arbetsbelastning till en enda region.

Modernisera fokus: Använd ett platt nätverk för en tidig PaaS-pilot eller en enda moderniserad arbetsbelastning och utforma dess undernät så att de kan uppgraderas rent till hub-and-spoke när du lägger till delade tjänster eller en andra region.

Fokus mellan moln: Använd ett platt virtuellt nätverk som ett enda Azure fotfäste under migreringen mellan moln: landa arbetsbelastningen först och planera sedan dess adressutrymme och segmentering så att den kan ansluta till en hubb eller Virtual WAN allt eftersom designen mognar.

Azure tjänster och funktioner

Topologin för platt nätverk använder dessa grundläggande Azure tjänster:

Service Roll i den här topologin
Virtuellt Azure-nätverk Tillhandahåller ett privat, isolerat adressutrymme för din arbetsbelastning. Ett virtuellt nätverk är begränsat till en enda Azure region.
Undernät + nätverkssäkerhetsgrupper (NSG:er) Undernät separerar programnivåer. NSG:er filtrerar inkommande och utgående trafik vid varje undernätsgräns. NSG:er är tillståndskänsliga: returtrafik för tillåtna anslutningar tillåts automatiskt.
Azure Private DNS Zon Tillhandahåller intern namnmatchning för resurser i det virtuella nätverket. Länka zonen med automatisk registrering aktiverad så att virtuella datorer automatiskt hämtar DNS-poster.
Gateway-undernät(valfritt) Är värd för en VPN- eller ExpressRoute-gateway om du behöver en enda anslutning till ett lokalt nätverk.

Så väljer du: behålla en platt struktur eller gå vidare till en hub-and-spoke-modell?

Använd följande beslutstabell för att avgöra om den platta topologin är lämplig för din miljö eller om du ska använda en topologi med nav och eker i stället.

Tillstånd Recommendation
Enskild arbetsbelastning, enskilt team, inga delade tjänster Håll dig platt: den här artikeln gäller
En andra oberoende arbetsbelastning behöver en egen nätverksisolering Gå över till hub-and-spoke-topologi
Du behöver en delad brandvägg, VPN-gateway eller Azure Bastion mellan arbetsbelastningar Uppgradera till hub-and-spoke-topologi
Säkerhetsprinciper måste hanteras centralt över flera arbetsbelastningar Uppgradera till hub-and-spoke-topologi

Tip

Om du förväntar dig att lägga till en andra arbetsbelastning inom sex till tolv månader, bör du överväga att börja med hub-and-spoke från dag ett. Omkostnaderna är minimala eftersom du bara lägger till ett extra virtuellt nätverk och en peering-anslutning. Den här metoden undviker en störande migrering senare.

Designöverväganden

Designfokus för platta lift-and-shift-nätverk

  • Använd ett virtuellt nätverk med ett undernät för varje programkomponent (webb, app, data) för att spegla en typisk lokal trenivålayout med minimal omdesign.
  • Använd NSG:er mellan undernät för att återskapa din befintliga segmentering och hålla adressutrymmet justerat med lokala intervall för att undvika överlappning.
  • Behåll en platt struktur när ett enda team ansvarar för arbetsbelastningen och du inte behöver delade brandväggs-, gatewaytjänster eller Bastion-tjänster.
  • Planera för övergången till en hub-and-spoke-arkitektur innan du lägger till en andra arbetsbelastning, så att delade tjänster placeras i en hubb i stället för att behöva anpassas i efterhand.

Modernisera designfokus för platt nätverk

  • Använd ett platt nätverk för en tidig PaaS-pilot eller en enda moderniserad arbetsbelastning: placera appnivåerna i undernät och nå Azure PaaS via privata slutpunkter i ett dedikerat undernät.
  • Reservera dedikerade subnät i förväg för de plattformstjänster som du kommer att lägga till, till exempel Application Gateway och privata slutpunkter, så att nätverket kan växa utan att adresseras om.
  • Använd NSG:er och säkerhetsgrupper för program per nivå så att segmenteringen redan finns på plats om arbetslasten senare blir en spoke i en hub-and-spoke-arkitektur.
  • Se till att adressutrymmet inte överlappar dina andra regioner och VNets så att du senare kan peer-koppla eller övergå till en hubbarkitektur utan omnumrering.

Designfokus för platt nätverk mellan moln

  • Använd ett platt virtuellt nätverk som ett enda Azure fotfäste under migrering mellan moln: landa arbetsbelastningen först och anslut sedan anslutningen från en hubb när designen mognar.
  • Planera det platta virtuella nätverkets adressutrymme för att undvika överlappning med virtuella AWS-datorer och Google Cloud-nätverk så att det kan ansluta till IPsec eller koppla samman routning senare utan översättning.
  • Behåll segmentering i nivåer med NSG:er så att arbetsbelastningens säkerhetsprofil bevaras när den blir en spoke bakom en säkrad Virtual WAN-hubb.
  • Standardisera namngivning och taggning av undernät så att de matchar dina andra moln så att arbetsbelastningen är enkel att korrelera under och efter migreringen.

Förutsättningar

Innan du implementerar den här topologin:

  • En Azure prenumeration med behörighet att skapa virtuella nätverk och NSG:er.
  • Ett planerat IP-adressutrymme. Ett /16-adressutrymme innehåller 65 536 adresser, vilket är en vanlig startpunkt för en enskild arbetsbelastning. Azure reserverar 5 adresser per undernät för internt bruk. Detaljerad vägledning finns i Planera IP-adressering.
  • En förståelse för dina programnivåer (till exempel webb, program och data) så att du kan mappa dem till undernät. Designvägledning för undernät finns i Designa virtuella nätverk och undernät.

Nätverkslayout

Diagram som visar en platt nätverkstopologi med undernät på webb-, program- och datanivå, som var och en skyddas av en NSG, i ett enda virtuellt nätverk.

En platt nätverkstopologi följer den här strukturen:

  • Ett virtuellt nätverk med ett enda adressutrymme (till exempel 10.0.0.0/16).
  • Flera undernät: ett per programnivå eller komponent:
    • Undernät på webbnivå (till exempel 10.0.1.0/24).
    • Undernät på programnivå (till exempel 10.0.2.0/24).
    • Undernät på datanivå (till exempel 10.0.3.0/24).
    • Gateway-undernät (valfritt, till exempel 10.0.255.0/27).
  • NSG:er som är kopplade till varje undernät med regler som endast tillåter den trafik som varje nivå behöver.
  • En Private DNS zon som är länkad till det virtuella nätverket med automatisk registrering aktiverad.

Note

Planera dina IP-adressintervall noggrant. Om du senare migrerar till en hub-and-spoke-topologi måste de virtuella ekernätverken ha CIDR-intervall som inte överlappar hubbens. Att välja ett välstrukturerat adressschema förhindrar nu konflikter under migreringen.

Säkerhetsfrågor

Tillämpa dessa säkerhetsrutiner på ditt platta nätverk:

  • NSG:er för varje undernät. Börja med en grundkonfiguration som blockerar all inkommande trafik och lägg till specifika tillåt-regler för behörig trafik mellan nivåer. Du kan till exempel tillåta HTTPS från webbnivån till programnivån och tillåta SQL från programnivån till datanivån.
  • Inga offentliga IP-adresser direkt på virtuella datorer. Exponera tjänster via en lastbalanserare eller Application Gateway. Använd Azure Bastion för administrativ åtkomst.
  • Private DNS för intern lösning. Private DNS zoner förhindrar att interna värdnamn exponeras via offentliga DNS-frågor.
  • Gateway-undernätsisolering. Om du lägger till en VPN- eller ExpressRoute-gateway placerar du den i ett dedikerat undernät (med namnet GatewaySubnet). NSG:erna i gateway-undernätet stöds inte. Om du kopplar en NSG till det här undernätet kan det leda till att den virtuella nätverksgatewayen slutar fungera som förväntat.

Important

När du tar bort en NSG-regel som tillåter en anslutning fortsätter befintliga aktiva anslutningar oavbrutet. Endast nya anslutningar som matchar den borttagna regeln blockeras.

Följande artiklar ger djupare vägledning om relaterade ämnen:

Learn more

Mer information om de Azure tjänster som används i den här topologin finns i:

Nästa steg

Tip

Utforska på egen hand? Gå tillbaka till översiktsnavigatorn för att hitta nästa artikel efter funktion.

Nästa steg i din lift-and-shift-resa:

Utforma din hub-and-spoke-topologi: De flesta lift-and-shift-migreringar växer snabbt ur ett platt nätverk. Planera centraliserade delade tjänster från början.

Nästa steg i moderniseringsresan:

Utforma din hub-and-spoke-topologi: Moderniserade arbetsbelastningar med flera tjänster, säkerhetskontroller och team behöver en hub-and-spoke-arkitektur från dag ett.

Nästa steg i din molnöverskridande resa:

Planera anslutningsarkitekturen mellan moln: Molnöverskridande egendomar behöver transitarkitektur, inte platta nätverk. Utforma din anslutningsmodell för flera moln.

  • Last updated on