Datalandningszonanslutning för en region
I en konfiguration med en region upprättas landningszonen för datahantering, datalandningszoner och alla associerade tjänster inom samma 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 Firewall), en ExpressRoute-gateway, en vpn-gateway (virtuellt privat nätverk), ett virtuellt navnätverk eller ett virtuellt WAN (vWAN-hubb).
Bild 1: Anslutning till en region.
Baserat på de aktuella funktionerna i Azure Networking Services rekommenderar vi att du använder en mesh-nätverksarkitektur. Du bör konfigurera peering för virtuella nätverk mellan:
- Anslutningshubben och Datahantering-zonen
- Anslutningshubben och varje datalandningszon
- Datahantering-zonen och varje datalandningszon
- Varje datalandningszon
I den här artikeln beskrivs för- och nackdelar med varje alternativ för nätverksarkitektur som beaktas 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
virtuell dator B (VM B) som finns i datalandningszon B läser in en datauppsättning från lagringskonto A som finns i datalandningszon A. Sedan bearbetar den virtuella datorn B den 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ätverksarkitektur i mesh (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 klientorganisationen måste du göra två saker för att implementera en nätverksnätarkitektur:
- Lägg till peerings för virtuella nätverk mellan alla virtuella datalandningszoner.
- Lägg till virtuella nätverkssammankopplingar mellan din landningszon för datahantering och alla datalandningszoner.
I vårt exemplscenario laddas data in från lagringskonto A och överförs via en peeringanslutning (2) som har konfigurerats mellan de två virtuella nätverken i 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 via anslutningshubben. Den finns kvar i dataplattformen som består av en landningszon för datahantering och en eller flera datalandningszoner.
Bild 2: Mesh-nätverksarkitektur.
Hantering av användaråtkomst i nätverksarkitektur i mesh
I en nätverksarkitekturdesign med mesh kräver dataprogramteam bara två saker för att skapa nya tjänster (inklusive privata slutpunkter):
- Skrivå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 behörigheter 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 anslutningshubben 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 anslutningshubben heller. 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 diagnostikinstä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:
Kostnader för nätverksarkitektur i mesh
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)
Peering för virtuella nätverk debiteras inte (2), vilket är anledningen till att det här alternativet har minimal kostnad.
Sammanfattning:
Bandbredd och svarstid i en meshnätverksarkitektur
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 mesh-nätverk erbjuder maximal bandbredd och låg latens till minimal kostnad, men gör inga kompromisser när det gäller hantering av användaråtkomst eller DNS-lagret.
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 navarkitektur (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 anslutningshubben för att komma åt data i lagringskonto A från virtuell dator B. Data passerar två peerings för virtuella nätverk ((2) och (5)) och en virtuell nätverksinstallation som finns i anslutningshubben ((3) och (4)). Sedan läses data in av den virtuella datorn (6) och lagras tillbaka till lagringskonto 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 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 nödvändiga behörigheter för att ansluta privata slutpunkter till ett undernät i en given spoke, behöver dina team inget stöd när de konfigurerar den nödvändiga anslutningen.
Sammanfattning:
Tjänsthantering i traditionell nav- och ekermodelarkitektur
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 genom en central virtuell nätverksapplikation, vilket gör det möjligt att logga och inspektera nätverkstrafik som skickas från en spoke till en annan.
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 beaktas från början.
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 trafik av en peering för ett virtuellt nätverk (5). Som tidigare nämnts debiteras inte den första peeringen för virtuella nätverk (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 privat slutpunktsprojektering (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 privata ändpunkter.
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 få VM A att ansluta till de privata slutpunkterna som är anslutna till det virtuella nätverket i datalandningszon A och få VM B att ansluta till de privata slutpunkterna som är anslutna till det virtuella nätverket i datalandningszon B. Du kan göra detta med en Windows Server-baserad konfiguration. Du kan också 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 peerings för virtuella nätverk.
Hantering av användaråtkomst 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 anslutningshubben, 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 anslutningshubben. 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 diagnostikinstä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 privata DNS-zoner, så den här arkitekturen kräver en tredjepartslösning som kan matcha FQDN baserat på begärandes ursprungs-/IP-adress. Du måste också utveckla och underhålla verktyg och arbetsflöden för att automatisera privata 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 privat slutpunktsprojektering
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 privat slutpunkt
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 arkitektur 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 anslutningshubbens arkitektur (rekommenderas inte)
Ett annat nätverksalternativ är att vara värd för privata slutpunkter i anslutningshubben 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 i företagets virtuella nätverk. På grund av den befintliga hubb- och ekernätverksarkitekturen på de flesta företag, och det faktum att din anslutningshubb är värd för dina privata slutpunkter i den här lösningen, krävs inte transitivitet. Peering av virtuella nätverk mellan anslutningshubben och datalandningszoner möjliggör direkt åtkomst.
Data passerar en enda virtuell nätverkspeering mellan anslutningshubben och datalandningszonen för att läsa in en datauppsättning som lagras i lagringskonto A i vm B. Efter att datauppsättningen har lästs in och bearbetats ((3) och (4)) passerar den samma virtuella nätverkspeering 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 anslutningshubbens arkitektur.
Hantering av användaråtkomst i anslutningshubbens arkitektur
I den här nätverksdesignen behöver dina team för datalandningszoner och dataprogramteam två saker för att kunna ansluta privata slutpunkter till det virtuella hubbnätverket:
- Skriva behörigheter till en resursgrupp i din anslutningshubbprenumeration
- Ansluta behörigheter till det virtuella hubbnätverket
Din anslutningshubb är avsedd för organisationens Azure-plattformsteam och är dedikerad till att vara 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 designen inkonsekvent eftersom den inte följer principerna för åtkomsthantering från grundprinciperna för Enterprise-Scale landningszon. Därför godkänner de flesta Azure-plattformsteam inte det här designalternativet.
Sammanfattning:
Tjänsthantering i anslutningshubbens arkitektur
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 anslutningshubben, 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 anslutningshubben. 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 diagnostikinstä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 anslutningshubben
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 anslutningshubbens arkitektur
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 privata slutpunkter i Anslutningshubben
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.
Sammanfattning av anslutning för datalandningszon i 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.