Datalandningszonanslutning för en region

Landningszonen för datahantering, datalandningszonerna och alla tjänster i dem konfigureras i samma region i en enda region. Alla landningszoner finns i samma prenumeration på anslutningshubben. Den här prenumerationen är värd för delade nätverksresurser, som kan innehålla en virtuell nätverksinstallation (till exempel Azure-brandväggen), en ExpressRoute-gateway, en vpn-gateway (virtuellt privat nätverk), ett virtuellt navnätverk eller ett virtuellt WAN (vWAN-hubb).

Bild 1: En region Anslut ivitet.

Baserat på De aktuella funktionerna i Azure Networking Services rekommenderar vi att du använder en nätverksarkitektur med nät. Du bör konfigurera Vnet-peering mellan:

• Anslut ivity Hub och Datahantering Zone
• Anslut ivity Hub och varje datalandningszon
• Datahantering-zonen och varje datalandningszon
• Varje datalandningszon

Den här artikeln beskriver för- och nackdelarna med varje alternativ för nätverksarkitektur som vi övervägde för analys i molnskala.

Det första avsnittet i den här artikeln fokuserar på ett mönster för en region, där Datahantering-zonen och alla datalandningszoner finns i samma region.

Varje designmönster utvärderas med hjälp av följande kriterier:

• Kostnad
• Hantering av användaråtkomst
• Servicehantering
• Bandbredd
• Svarstid

Vi analyserar varje designalternativ med följande användningsfall för landningszoner för flera data i åtanke:

Kommentar

Den virtuella datorn B (VM B) som finns i datalandningszonen B läser in en datauppsättning från lagringskontoT som finns i datalandningszon A. Sedan bearbetar den virtuella datorn B datauppsättningen och lagrar den i lagringskonto B, som finns i datalandningszon B.

Viktigt!

Den här artikeln och andra artiklar i nätverksavsnittet beskriver affärsöverskridande enheter som delar data. Detta kanske dock inte är din ursprungliga strategi och att du först måste börja på basnivå.

Utforma ditt nätverk så att du så småningom kan implementera vår rekommenderade konfiguration mellan datalandningszoner. Se till att datahanteringslandningszonerna är direkt anslutna till landningszonerna för styrning.

Nätnätverksarkitektur (rekommenderas)

Vi rekommenderar att du använder en nätverksnätarkitektur när du använder analys i molnskala. Förutom den befintliga nätverksdesignen för hubbar och ekrar som har konfigurerats i din klientorganisation måste du göra två saker för att implementera en nätverksnätarkitektur:

• Lägg till Vnet-peerings mellan alla virtuella datalandningszoner.
• Lägg till Vnet-parkopplingar mellan din landningszon för datahantering och alla datalandningszoner.

I vårt exempelscenario överförs data som läses in från lagringskonto A en Vnet-peeringanslutning (2) som konfigurerats mellan de två virtuella datalandningszonerna. Den läses in och bearbetas av den virtuella datorn B ((3) och (4)) och skickas sedan via den lokala privata slutpunkten (5) som ska lagras i lagringskonto B.

I det här scenariot passerar inte data Anslut ivity Hub. Den finns kvar i dataplattformen som består av en landningszon för datahantering och en eller flera datalandningszoner.

Bild 2: Nätverksarkitektur med nät.

Hantering av användaråtkomst i nätverksarkitektur med mesh

I en nätbaserad nätverksarkitektursdesign kräver dataprogramteam bara två saker för att kunna skapa nya tjänster (inklusive privata slutpunkter):

• Skriva åtkomst till deras dedikerade resursgrupp i datalandningszonen
• Anslut åtkomst till deras avsedda undernät

I den här designen kan dataprogramteam distribuera privata slutpunkter själva. Så länge de har de åtkomsträttigheter som krävs för att ansluta privata slutpunkter till ett undernät i en viss eker behöver dina team inget stöd när de konfigurerar den nödvändiga anslutningen.

Sammanfattning:

Tjänsthantering i nätnätverksarkitektur

I en nätverksarkitekturdesign med nät fungerar ingen virtuell nätverksinstallation som en enda fel- eller begränsningspunkt. Bristen på datauppsättningar som skickas via Anslut ivity Hub minskar ditt centrala Azure-plattformsteams omkostnader, förutsatt att du inte behöver skala ut den virtuella installationen.

Detta innebär att det centrala Azure-plattformsteamet inte längre kan inspektera och logga all trafik som skickas mellan datalandningszoner. Molnskalningsanalys är dock en sammanhängande plattform som omfattar flera prenumerationer, vilket möjliggör skalning och övervinner begränsningar på plattformsnivå, så det är inte en nackdel.

Med alla resurser som finns i en enda prenumeration inspekterar ditt centrala Azure-plattformsteam inte längre alla data i den centrala Anslut ivity Hub. Du kan fortfarande samla in nätverksloggar med hjälp av flödesloggar för nätverkssäkerhetsgrupp. Du kan konsolidera och lagra andra loggar på program- och tjänstnivå med hjälp av tjänstspecifika diagnostik Inställningar.

Du kan samla in alla dessa loggar i stor skala med hjälp av Azure Policy-definitioner för diagnostikinställningar.

Med den här designen kan du också skapa en intern DNS-lösning i Azure baserat på Privat DNS zoner. Du kan automatisera DNS A-postens livscykel via Azure Policy-definitioner för privata DNS-grupper.

Sammanfattning:

Nätnätverksarkitekturkostnad

Kommentar

När du kommer åt en privat slutpunkt i ett peer-kopplat nätverk debiteras du bara för själva den privata slutpunkten, inte för VNet-peering. Du kan läsa den officiella instruktionen i Vanliga frågor och svar: Hur fungerar fakturering när du kommer åt en privat slutpunkt från ett peer-kopplat nätverk?.

I den här nätverksdesignen betalar du bara för:

• Dina privata slutpunkter (per timme)
• Inkommande och utgående trafik som skickas via dina privata slutpunkter för att läsa in din rådatauppsättning (1) och lagra din bearbetade datamängd (6)

Vnet-peering debiteras inte (2), vilket är anledningen till att det här alternativet har minimal kostnad.

Sammanfattning:

Bandbredd och svarstid i en nätverksarkitektur med nät

Den här designen har inga kända begränsningar för bandbredd eller svarstid eftersom inga virtuella nätverksinstallationer begränsar dataflödet för datautbytet mellan datazoner. Designens enda begränsande faktor är den fysiska gränsen för våra datacenter (hastigheten på fiberoptiska kablar).

Sammanfattning:

Sammanfattning av nätverksarkitektur i mesh

Om du planerar att använda analys i molnskala rekommenderar vi att du använder nätnätverksdesignen. Ett nätnätverk erbjuder maximal bandbredd och låg svarstid till minimal kostnad, men gör inga kompromisser när det gäller hantering av användaråtkomst eller PÅ DNS-nivå.

Om du behöver tillämpa andra nätverksprinciper inom dataplattformen använder du nätverkssäkerhetsgrupper i stället för virtuella nätverksinstallationer.

Traditionell hubb- och ekerarkitektur (rekommenderas inte)

Design av nav- och ekernätverksarkitektur är det mest uppenbara alternativet, och ett som många företag har antagit. I den konfigureras nätverkstransitivitet i Anslut ivity Hub för att komma åt data i lagringskonto A från virtuell dator B. Data passerar två Vnet-peerings ((2) och (5)) och en virtuell nätverksinstallation som finns i Anslut ivity Hub ((3) och (4)). Sedan läses data in av den virtuella datorn (6) och lagras tillbaka till lagringskontoT B (8).

Bild 3: Hubb- och ekerarkitektur.

Hantering av användaråtkomst i traditionell hubb- och ekerarkitektur

I en traditionell hubb- och ekerdesign kräver dataprogramteam bara två saker för att de ska kunna skapa nya tjänster (inklusive privata slutpunkter):

• Skriva åtkomst till resursgruppen i datalandningszonen
• Anslut åtkomst till deras avsedda undernät

I den här designen kan dataprogramteam distribuera privata slutpunkter själva. Så länge de har de åtkomsträttigheter som krävs för att ansluta privata slutpunkter till ett undernät i en viss eker behöver dina team inget stöd när de konfigurerar den nödvändiga anslutningen.

Sammanfattning:

Tjänsthantering i traditionell hubb- och ekerarkitektur

Den här nätverksdesignen är välkänd och överensstämmer med de flesta organisationers befintliga nätverkskonfiguration. Detta gör designen enkel att förklara och implementera. Du kan också använda en centraliserad Azure-intern DNS-lösning med Privat DNS-zoner för att ge FQDN-lösning i din Azure-klientorganisation. Med hjälp av Privat DNS-zoner kan du automatisera DNS A-postlivscykeln via Azure-principer.

En annan fördel med den här designen är att trafiken dirigeras via en virtuell central nätverksinstallation, så att nätverkstrafik som skickas från en Eker till en annan kan loggas och inspekteras.

En nackdel med den här designen är att ditt centrala Azure Platform-team måste hantera routningstabeller manuellt. Detta är nödvändigt för att säkerställa transitivitet mellan ekrar, vilket möjliggör delning av datatillgång över flera datalandningszoner. Routningshantering kan bli komplex och felbenägen över tid och måste betraktas i förväg.

En annan nackdel med den här nätverkskonfigurationen är hur den centrala virtuella nätverksinstallationen konfigureras. Den virtuella nätverksinstallationen fungerar som en enskild felpunkt och kan orsaka allvarliga avbrott i dataplattformen om ett fel inträffar. I takt med att datamängdsstorlekarna ökar inom en dataplattform och antalet användningsfall för landningszoner mellan data ökar, skickas mer trafik via den centrala virtuella nätverksinstallationen.

Med tiden kan detta leda till att gigabyte eller terabyte data skickas via den centrala instansen. Eftersom bandbredden för befintliga virtuella nätverksinstallationer ofta begränsas till bara ett en- eller tvåsiffrigt gigabyte-dataflöde kan den centrala virtuella nätverksinstallationen bli en flaskhals som kritiskt begränsar trafikflödet mellan datalandningszoner och begränsar datatillgångens delningsbarhet.

Det enda sättet att undvika det här problemet är att skala ut den centrala virtuella nätverksinstallationen över flera instanser, vilket har stora kostnadskonsekvenser för den här designen.

Sammanfattning:

Traditionell hubb- och ekerarkitekturkostnad

Kommentar

När du kommer åt en privat slutpunkt i ett peer-kopplat nätverk debiteras du bara för själva den privata slutpunkten och inte för VNet-peering. Du kan läsa den officiella instruktionen i Vanliga frågor och svar: Hur fungerar fakturering när du kommer åt en privat slutpunkt från ett peer-kopplat nätverk?.

För det här nätverket debiteras du per timme för dina lagringskontons privata slutpunkter. Du debiteras också för inkommande och utgående trafik som skickas via de privata slutpunkterna för att läsa in en rådatauppsättning (1) och lagra den bearbetade datamängden (8).

Kunden debiteras för ingress och utgående av en Vnet-peering (5). Som tidigare nämnts debiteras inte den första Vnet-peeringen (2).

Du får en hög kostnad för den virtuella nätverksinstallationen om du använder den här nätverksdesignen ((3) och (4)). Du måste antingen köpa extra licenser och skala ut den virtuella nätverksinstallationen baserat på efterfrågan eller betala den avgift som bearbetas per gigabyte som den görs med Azure Firewall.

Sammanfattning:

Bandbredd och svarstid i traditionell hubb- och ekerarkitektur

Den här nätverksdesignen har allvarliga bandbreddsbegränsningar. Den centrala virtuella nätverksinstallationen blir en kritisk flaskhals när din plattform växer, vilket begränsar användningsfall för datalandningszoner och delning av datamängder. Det skapar sannolikt också flera kopior av datauppsättningar över tid.

Den här designen påverkar också svarstiden, vilket blir särskilt viktigt i realtidsanalysscenarier.

Sammanfattning:

Sammanfattning av traditionell hubb- och ekerarkitektur

Den här hubb- och ekernätverksdesignen har åtkomsthantering och vissa fördelar med tjänsthantering, men på grund av kritiska begränsningar för tjänsthantering och bandbredd och svarstid kan vi inte rekommendera den här nätverksdesignen för användning av landningszoner för flera data.

Arkitektur för projektion av privat slutpunkt (rekommenderas inte)

Ett annat designalternativ är projektionen av privata slutpunkter i varje landningszon. I den här designen skapas en privat slutpunkt för lagringskonto A i varje landningszon. Detta leder till en första privat slutpunkt i datalandningszonen A som är ansluten till det virtuella nätverket i datalandningszon A, en andra privat slutpunkt som är ansluten till det virtuella nätverket i datalandningszon B och så vidare.

Detsamma gäller för lagringskonto B och eventuellt för andra tjänster i datalandningszonerna. Om vi definierar antalet datalandningszoner som n får vi n privata slutpunkter för åtminstone alla lagringskonton och potentiellt andra tjänster i datalandningszonerna. Detta leder till en exponentiell ökning av antalet privata slutpunkter.

Bild 4: Arkitektur för projektion av privat slutpunkt.

Eftersom alla privata slutpunkter för en viss tjänst (till exempel lagringskonto A) har samma FQDN (till exempel storageaccounta.privatelink.blob.core.windows.net) skapar den här lösningen utmaningar i DNS-lagret som inte kan lösas med hjälp av Privat DNS zoner. Du behöver i stället en anpassad DNS-lösning som kan matcha DNS-namn baserat på beställarens ursprung/IP-adress. På så sätt kan du göra VMA ansluta till de privata slutpunkter som är anslutna till det virtuella nätverket i datalandningszon A och göra så att virtuell dator B ansluter till de privata slutpunkter som är anslutna till det virtuella nätverket i datalandningszon B. Du kan göra detta med en Windows Server-baserad konfiguration, medan du kan automatisera LIVSCYKELN för DNS A-poster genom en kombination av aktivitetsloggen och Azure Functions.

I den här konfigurationen kan du läsa in rådatauppsättningen i Lagringskonto A till virtuell dator B genom att komma åt datauppsättningen via den lokala privata slutpunkten (1). När du har läst in och bearbetat datamängden ((2) och (3)) kan du lagra den på lagringskonto B genom att direkt komma åt den lokala privata slutpunkten (4). I det här scenariot får data inte passera några Vnet-peerings.

Användaråtkomsthantering i arkitektur för projektion av privata slutpunkter

Den här designens metod för hantering av användaråtkomst liknar den i nätverksarkitekturen med nät. I den här designen kan du dock kräva åtkomsträttigheter för andra datalandningszoner för att skapa privata slutpunkter, inte bara inom en angiven datalandningszon och ett virtuellt nätverk utan även i andra datalandningszoner och deras respektive virtuella nätverk.

På grund av detta kräver dina dataprogramteam tre saker, inte två, för att kunna skapa nya tjänster själva:

• Skriva åtkomst till en resursgrupp i en angiven datalandningszon
• Anslut åtkomst till deras avsedda undernät
• Åtkomst till en resursgrupp och ett undernät i alla andra datalandningszoner för att skapa sina respektive lokala privata slutpunkter

Den här nätverksdesignen ökar komplexiteten i ditt åtkomsthanteringslager eftersom dina dataprogramteam kräver behörigheter i varje enskild datalandningszon. Designen kan också vara förvirrande och leda till inkonsekvent RBAC över tid.

Om datalandningszonteam och dataprogramteam inte får nödvändiga åtkomsträttigheter uppstår problem som beskrivs i traditionell hubb- och ekerarkitektur (rekommenderas inte).

Sammanfattning:

Tjänsthantering i arkitektur för projektion av privata slutpunkter

Även om den här nätverksdesignen återigen liknar nätverksarkitekturens design har den här nätverksdesignen fördelen att ingen virtuell nätverksinstallation fungerar som en enda fel- eller begränsningsdataflöde. Det minskar också hanteringskostnaderna för ditt centrala Azure-plattformsteam genom att inte skicka datauppsättningar via Anslut ivity Hub, eftersom det inte finns något behov av att skala ut den virtuella installationen. Detta innebär att det centrala Azure-plattformsteamet inte längre kan inspektera och logga all trafik som skickas mellan datalandningszoner. Molnskalningsanalys är dock en sammanhängande plattform som omfattar flera prenumerationer, vilket möjliggör skalning och övervinner begränsningar på plattformsnivå, så det är inte en nackdel.

Med alla resurser som finns i en enda prenumeration inspekteras inte trafiken i den centrala Anslut ivity Hub. Du kan fortfarande samla in nätverksloggar med hjälp av flödesloggar för nätverkssäkerhetsgrupp, och du kan konsolidera och lagra andra loggar på program- och tjänstnivå med hjälp av tjänstspecifika diagnostik- Inställningar. Du kan samla in alla dessa loggar i stor skala med hjälp av Azure-principer. Å andra sidan ökar det nätverksadressutrymme som krävs av dataplattformen på grund av den exponentiella ökningen av nödvändiga privata slutpunkter, vilket inte är optimalt.

De största problemen med den här nätverksarkitekturen är tidigare nämnda DNS-utmaningar. Du kan inte använda en inbyggd Azure-lösning i form av Privat DNS-zoner, så den här arkitekturen kräver en tredjepartslösning som kan matcha FQDNS baserat på beställarens ursprung/IP-adress. Du måste också utveckla och underhålla verktyg och arbetsflöden för att automatisera Privat DNS A-poster, vilket drastiskt ökar hanteringskostnaderna jämfört med den föreslagna Azure Policy-drivna lösningen.

Du kan skapa en distribuerad DNS-infrastruktur med hjälp av Privat DNS zoner, men detta skapar DNS-öar, vilket i slutändan orsakar problem när du försöker komma åt privata länktjänster som finns i andra landningszoner i din klientorganisation. Därför är den här designen inte ett genomförbart alternativ.

Sammanfattning:

Arkitekturkostnad för projektion av privat slutpunkt

Kommentar

När du kommer åt en privat slutpunkt i ett peer-kopplat nätverk debiteras du bara för själva den privata slutpunkten och inte för VNet-peering. Du kan läsa den officiella instruktionen i Vanliga frågor och svar: Hur fungerar fakturering när du kommer åt en privat slutpunkt från ett peer-kopplat nätverk?.

I den här nätverksdesignen debiteras du bara för de privata slutpunkterna (per timme) och inkommande och utgående trafik som skickas via dessa privata slutpunkter för att läsa in rådatamängder (1) och lagra bearbetade datamängder (4). Extra kostnader måste dock förväntas på grund av den exponentiella ökningen av antalet privata slutpunkter för dataplattformen. Eftersom du debiteras per timme beror mängden extra kostnad mycket på hur många privata slutpunkter som skapas.

Sammanfattning:

Bandbredd och svarstid i arkitekturen för projektion av privata slutpunkter

Den här designen har inga kända begränsningar för bandbredd och svarstid eftersom den inte har några virtuella nätverksinstallationer som begränsar dataflödet för datautbyte mellan data i landningszonen. Designens enda begränsande faktor är den fysiska gränsen för våra datacenter (hastigheten på fiberoptiska kablar).

Sammanfattning:

Arkitektursammanfattning för projektion av privat slutpunkt

Den exponentiella tillväxten av privata slutpunkter i den här nätverksarkitekturen kan leda till att du förlorar reda på vilka privata slutpunkter som används för vilket syfte på vilken plats. Du begränsas också av problem med åtkomsthantering och DNS-lagerkomplexiteter. På grund av dessa problem kan vi inte rekommendera den här nätverksdesignen för användningsfall för landningszoner mellan data.

Privata slutpunkter i arkitekturen för Anslut ivity Hub (rekommenderas inte)

Ett annat nätverksalternativ är att vara värd för privata slutpunkter i din Anslut ivity Hub och ansluta dem till det virtuella hubbnätverket. I den här lösningen är du värd för en enskild privat slutpunkt för varje tjänst på företagets virtuella nätverk. På grund av den befintliga hubb- och ekernätverksarkitekturen på de flesta företag, och det faktum att din Anslut ivity Hub är värd för dina privata slutpunkter i den här lösningen, krävs inte transitivitet. Vnet-peering mellan din Anslut ivity Hub och datalandningszoner möjliggör direkt åtkomst.

Data passerar en enda Vnet-peering mellan Anslut ivity Hub och datalandningszonen för att läsa in en datauppsättning som lagras i lagringskonto A i vm B. När datauppsättningen har lästs in och bearbetats ((3) och (4)) passerar den samma Vnet-peering en andra gång (5) innan den slutligen lagras i lagringskonto B via den privata slutpunkten som är ansluten till det virtuella hubbnätverket (6).

Bild 5: Privata slutpunkter i arkitekturen Anslut ivity Hub.

Hantering av användaråtkomst i arkitekturen för Anslut ivity Hub

I den här nätverksdesignen behöver dina team och dataprogramteam för datalandningszoner två saker för att kunna ansluta privata slutpunkter till det virtuella hubbnätverket:

• Skriva behörigheter till en resursgrupp i din Anslut ivity Hub-prenumeration
• Ansluta behörigheter till det virtuella hubbnätverket

Din Anslut ivity Hub är avsedd för organisationens Azure-plattformsteam och är dedikerad för värd för organisationens nödvändiga och delade nätverksinfrastruktur (inklusive brandväggar, gatewayer och verktyg för nätverkshantering). Det här nätverksalternativet gör den designen inkonsekvent eftersom den inte följer principerna för åtkomsthantering från grundprinciperna för landningszoner i företagsskala. Därför godkänner de flesta Azure-plattformsteam inte det här designalternativet.

Sammanfattning:

Tjänsthantering i arkitekturen för Anslut ivity Hub

Den här designen liknar designen för nätnätverksarkitekturen, men den har ingen virtuell nätverksinstallation som fungerar som en enda fel- eller begränsningsdataflöde. Det minskar också hanteringskostnaderna för ditt centrala Azure-plattformsteam genom att inte skicka datauppsättningar via Anslut ivity Hub, eftersom det inte finns något behov av att skala ut den virtuella installationen. Detta innebär att det centrala Azure-plattformsteamet inte längre kan inspektera och logga all trafik som skickas mellan datalandningszoner. Molnskalningsanalys är dock en sammanhängande plattform som omfattar flera prenumerationer, vilket möjliggör skalning och övervinner begränsningar på plattformsnivå, så det är inte en nackdel.

Med alla resurser som finns i en enda prenumeration inspekteras inte trafiken i den centrala Anslut ivity Hub. Du kan fortfarande samla in nätverksloggar med hjälp av flödesloggar för nätverkssäkerhetsgrupp, och du kan konsolidera och lagra andra loggar på program- och tjänstnivå med hjälp av tjänstspecifika diagnostik- Inställningar. Du kan samla in alla dessa loggar i stor skala med hjälp av Azure-principer.

Med den här designen kan du också skapa en intern DNS-lösning i Azure baserat på Privat DNS-zoner, och du kan automatisera DNS A-postlivscykeln via Azure-principer.

Sammanfattning:

arkitekturkostnad för Anslut ivity Hub

Kommentar

När du kommer åt en privat slutpunkt i ett peer-kopplat nätverk debiteras du bara för själva den privata slutpunkten och inte för VNet-peering. Du kan läsa den officiella instruktionen i Vanliga frågor och svar: Hur fungerar fakturering när du kommer åt en privat slutpunkt från ett peer-kopplat nätverk?.

I den här nätverksdesignen debiteras du bara för dina privata slutpunkter (per timme) och inkommande och utgående trafik som skickas via dessa privata slutpunkter för att läsa in en rådatauppsättning (1) och lagra den bearbetade datamängden (6).

Sammanfattning:

Bandbredd och svarstid i arkitekturen för Anslut ivity Hub

Den här designen har inga kända begränsningar för bandbredd och svarstid eftersom den inte har några virtuella nätverksinstallationer som begränsar dataflödet för datautbyte mellan data i landningszonen. Designens enda begränsande faktor är den fysiska gränsen för våra datacenter (hastigheten på fiberoptiska kablar).

Sammanfattning:

Sammanfattning av arkitekturen för privata slutpunkter i Anslut ivity Hub

Den här nätverksarkitekturdesignen har flera fördelar, men dess tidigare nämnda inkonsekvenser i åtkomsthantering gör den till underpar. Därför kan vi inte rekommendera den här designmetoden.

Anslutningsavslutning för datalandningszon för en region

Av alla granskade alternativ för nätverksarkitektur och deras för- och nackdelar är nätad nätverksarkitektur den tydliga vinnaren. Det har enorma fördelar för dataflödet och för kostnader och hantering, vilket är anledningen till att vi rekommenderar att du använder det när du distribuerar analys i molnskala. Virtuella peering-ekernätverk har inte tidigare varit vanliga, och detta har lett till problem med att dela datauppsättningar mellan domäner och affärsenheter.

Du kan visa analys i molnskala som en sammanhängande lösning som omfattar flera prenumerationer. I en enda prenumerationskonfiguration är nätverkstrafikflödet lika med flödet i nätverksarkitekturen med nät. I en enda prenumerationskonfiguration kommer användarna sannolikt att nå plattformens prenumerationsnivågränser och kvoter, vilket analys i molnskala syftar till att undvika.

Nästa steg

• Datalandningszon mellan regioner Anslut ivitet