Připojení cílové zóny dat v jedné oblasti
V nastavení jedné oblasti se cílová zóna správy dat, cílové zóny dat a všechny přidružené služby vytvoří ve stejné oblasti. Všechny cílové zóny se nacházejí ve stejném předplatném uzlu připojení. Toto předplatné hostuje sdílené síťové prostředky, které můžou zahrnovat síťové virtuální zařízení (například Azure Firewall), bránu ExpressRoute, bránu virtuální privátní sítě (VPN), centrální virtuální síť nebo virtuální síť WAN (centrum virtuální sítě WAN).
Obrázek 1: Připojení k jedné oblasti
Na základě aktuálních možností síťových služeb Azure doporučujeme použít síťovou architekturu typu mesh. Měli byste nastavit propojení virtuálních sítí mezi:
- Centrum připojení a zóna Správa dat
- Centrum připojení a každá cílová zóna dat
- Zóna Správa dat a každá cílová zóna dat
- Každá cílová zóna dat
Tento článek popisuje výhody a nevýhody jednotlivých možností síťové architektury, které se považují za analýzy v cloudovém měřítku.
První část tohoto článku se zaměřuje na model s jednou oblastí, kde jsou Správa dat zóna a všechny cílové zóny dat hostované ve stejné oblasti.
Každý vzor návrhu se vyhodnocuje pomocí následujících kritérií:
- Náklady
- Správa uživatelských přístupů
- Správa služeb
- Šířka pásma
- Latence
Jednotlivé možnosti návrhu analyzujeme s následujícím případem použití přistávací zóny napříč datovými soubory:
Poznámka:
virtuální počítač B hostovaný v cílové zóně dat B načte datovou sadu z účtu úložiště A hostovaného v cílové zóně A dat. Potom virtuální počítač B tuto datovou sadu zpracuje a uloží ji do účtu úložiště B, který je hostovaný v cílové zóně dat B.
Důležité
Tento článek a další články v části Sítě popisují organizační jednotky, které sdílejí data. Nemusí to ale být vaše počáteční strategie a že musíte začít nejprve na základní úrovni.
Navrhněte sítě tak, abyste mohli nakonec implementovat naše doporučené nastavení mezi cílovými zónami dat. Ujistěte se, že cílové zóny správy dat jsou přímo připojené k cílovým zóně zásad správného řízení.
Propojená síťová architektura (doporučeno)
Doporučujeme použít síťovou mesh architekturu při přijímání analýz v cloudovém měřítku. Kromě existujícího návrhu hvězdicové a paprskové sítě nastaveného v rámci vašeho tenanta, je potřeba provést dvě věci k implementaci architektury síťového oka:
- Přidejte partnerské vztahy virtuálních sítí mezi všechny virtuální sítě cílové zóny dat.
- Přidejte spojení virtuálních sítí mezi vaší přistávací zónou správy dat a všemi přistávacími zónami dat.
V našem ukázkovém scénáři data načtená z účtu úložiště A přecházejí přes partnerské připojení virtuální sítě (2) nastavené mezi dvěma virtuálními sítěmi datových zón přistání. Načte a zpracuje ho virtuální počítač B (3) a (4) a pak se odešle přes místní privátní koncový bod (5), který se uloží do účtu úložiště B.
V tomto scénáři data neprocházejí centrem připojení. Zůstává v datové platformě, která se skládá z cílové zóny správy dat a jedné nebo více cílových zón dat.
Obrázek 2: Síťová architektura v mřížce
Správa uživatelských přístupů v architektuře sítě meshed
V návrhu architektury sítě vyžadují týmy datových aplikací pouze dvě věci k vytvoření nových služeb (včetně privátních koncových bodů):
- Zápis přístupu ke své vyhrazené skupině prostředků v cílové zóně dat
- Připojení přístupu k určené podsíti
V tomto návrhu můžou týmy datových aplikací nasazovat vlastní privátní koncové body. Pokud mají potřebná přístupová práva pro připojení privátních koncových bodů k podsíti v daném vybavení (hub-spoke, pokud je použit tento model), vaše týmy nepotřebují podporu při nastavování potřebného připojení.
Souhrn: 
Správa služeb v architektuře sítě meshed
V návrhu síťové architektury sítě nedochází k žádnému síťovému virtuálnímu zařízení jako jediný bod selhání nebo omezování. Nedostatek datových sad, které se odesílají přes centrum připojení, snižuje režii vašeho centrálního týmu platformy Azure za předpokladu, že virtuální zařízení nemusíte škálovat na více instancí.
To znamená, že centrální tým platformy Azure už nemůže kontrolovat a protokolovat veškerý provoz odesílaný mezi cílovými zónami dat. Analýza na úrovni cloudu je ale koherentní platforma, která obsahuje několik předplatných, což umožňuje škálování a překonat omezení na úrovni platformy, takže to není nevýhodou.
Se všemi prostředky hostovanými v rámci jednoho předplatného už centrální tým platformy Azure nekontroluje všechna data v centru centrálního připojení. Síťové protokoly můžete stále zaznamenávat pomocí protokolů toku skupiny zabezpečení sítě. Pomocí nastavení diagnostiky specifické pro službu můžete konsolidovat a ukládat další protokoly na úrovni aplikací a služeb.
Všechny tyto protokoly můžete zachytit ve velkém měřítku pomocí definic Azure Policy pro nastavení diagnostiky.
Tento návrh také umožňuje vytvořit nativní řešení DNS Azure založené na Privátní DNS zónách. Životní cyklus záznamů DNS A můžete automatizovat prostřednictvím definic Azure Policy pro privátní skupiny DNS.
Souhrn:
Náklady na síťovou architekturu typu mesh
Poznámka:
Při přístupu k privátnímu koncovému bodu v rámci partnerské sítě se vám budou účtovat pouze samotné privátní koncové body, ne za partnerský vztah virtuálních sítí. Oficiální prohlášení si můžete přečíst v nejčastějších dotazech: Jak bude fakturace fungovat při přístupu k privátnímu koncovému bodu z partnerské sítě?
V tomto návrhu sítě platíte pouze za:
- Vaše privátní koncové body (za hodinu)
- Příchozí a výchozí provoz odeslaný přes privátní koncové body za účelem načtení nezpracované datové sady (1) a uložení zpracované datové sady (6)
Párování virtuálních sítí nebude zpoplatněno (2), což je důvod, proč má tato možnost minimální náklady.
Souhrn:
Šířka pásma a latence v mřížové síťové architektuře
Tento návrh nemá žádná známá omezení šířky pásma nebo latence, protože žádná síťová virtuální zařízení neomezí propustnost pro výměnu dat cílové zóny napříč daty. Jediným mezním faktorem návrhu je fyzický limit našich datacenter (rychlost kabelů optických vláken).
Souhrn:
Souhrn architektury propojené sítě
Pokud plánujete přijmout analýzy na úrovni cloudu, doporučujeme použít návrh sítě se sítí. Propojená síť nabízí maximální šířku pásma a nízkou latenci s minimálními náklady, a přitom nedělá žádné kompromisy ohledně správy přístupu uživatelů nebo vrstvy DNS.
Pokud potřebujete vynutit další zásady sítě v rámci datové platformy, použijte skupiny zabezpečení sítě místo centrálních síťových virtuálních zařízení.
Tradiční architektura "Hub a Spoke" (nedoporučovaná)
Návrh hvězdicové architektury sítě je nejobraznější možností a ten, který mnoho podniků přijalo. V Centru konektivity je nastavena tranzitivita sítě pro přístup k datům v Účtu úložiště A z virtuálního počítače B. Data procházejí dvěma propojeními virtuálních sítí ((2) a (5)) a síťovým virtuálním zařízením hostovaným v Centru konektivity ((3) a (4)). Potom se data načtou virtuálním počítačem (6) a uloží se zpět do účtu úložiště B (8).
obrázek 3: Architektura hub a paprsek
Správa přístupu uživatelů v tradiční architektuře Hub and Spoke
V tradičním hvězdicovém návrhu vyžadují týmy datových aplikací pouze dvě věci k vytvoření nových služeb (včetně privátních koncových bodů):
- Zápis přístupu ke skupině prostředků v cílové zóně dat
- Připojení přístupu k určené podsíti
V tomto návrhu můžou týmy datových aplikací nasazovat vlastní privátní koncové body. Pokud mají potřebná přístupová práva pro připojení soukromých koncových bodů k podsíti v konkrétním paprsku, vaše týmy nepotřebují podporu při nastavování potřebného připojení.
Souhrn:
Správa služeb v tradiční hvězdicovité architektuře
Tento návrh sítě je dobře známý a konzistentní s existujícím nastavením sítě ve většině organizací. Díky tomu je návrh snadno vysvětlit a implementovat. K zajištění překladu plně kvalifikovaného názvu domény v rámci tenanta Azure můžete použít také centralizované řešení DNS nativní pro Azure s Privátní DNS zónami. Použití Privátní DNS Zón umožňuje automatizovat životní cyklus záznamů DNS A prostřednictvím zásad Azure.
Další výhodou tohoto návrhu je to, že provoz je směrován přes centrální síťové virtuální zařízení, takže je možné protokolovat a kontrolovat síťový provoz odeslaný z jednoho paprsku sítě do druhého.
Jednou z nevýhod tohoto návrhu je, že centrální tým platformy Azure musí spravovat směrovací tabulky ručně. To je nezbytné k zajištění tranzitivity mezi paprsky, což umožňuje sdílení datových prostředků napříč několika cílovými zónami dat. Správa tras může být postupem času složitá a náchylná k chybám, a proto musí být zvážena předem.
Další nevýhodou tohoto nastavení sítě je způsob nastavení centrálního síťového virtuálního zařízení. Síťové virtuální zařízení funguje jako jediný bod selhání a může způsobit vážné výpadky v datové platformě, pokud dojde k selhání. S rostoucí velikostí datových sad v rámci datové platformy a nárůstem počtu případů použití cílové zóny napříč daty se prostřednictvím centrálního síťového virtuálního zařízení odesílá více provozu.
V průběhu času to může mít za následek gigabajty nebo dokonce terabajty dat odesílaných prostřednictvím centrální instance. Vzhledem k tomu, že šířka pásma stávajících síťových virtuálních zařízení je často omezená jenom na propustnost jednoho nebo dvoumístného gigabajtu, může se stát kritickým bodem, který kriticky omezuje tok provozu mezi cílovými zónami dat a omezuje sdílení datových prostředků.
Jediným způsobem, jak se tomuto problému vyhnout, je horizontální navýšení kapacity centrálního síťového virtuálního zařízení napříč několika instancemi, což má pro tento návrh velký dopad na náklady.
Souhrn: 
Náklady na tradiční architekturu soustřednou a paprskovou
Poznámka:
Při přístupu k privátnímu koncovému bodu v rámci partnerské sítě se vám budou účtovat pouze samotné privátní koncové body, a ne za partnerský vztah virtuálních sítí. Oficiální prohlášení si můžete přečíst v nejčastějších dotazech: Jak bude fakturace fungovat při přístupu k privátnímu koncovému bodu z partnerské sítě?
Pro tuto síť se účtují každou hodinu za privátní koncové body účtů úložiště. Také se vám účtuje příchozí a výchozí provoz odesílaný prostřednictvím privátních koncových bodů, aby se načetla nezpracovaná datová sada (1) a uložila se zpracovaná datová sada (8).
Za příchozí a odchozí přenosy jednoho propojení virtuálních sítí (5) je zákazník účtován. Jak už bylo zmíněno dříve, první propojení virtuálních sítí není zpoplatněno (2).
Pokud použijete tento návrh sítě (3) a (4), skončíte s vysokými náklady na centrální virtuální síťová zařízení. Musíte buď zakoupit dodatečné licence a škálovat virtuální zařízení centrální sítě na základě poptávky, nebo platit poplatky zpracovávané za gigabajt, jak to funguje se službou Azure Firewall.
Souhrn:
Šířka pásma a latence v tradiční hub a spoke architektuře
Tento návrh sítě má závažná omezení šířky pásma. Virtuální zařízení centrální sítě se stává kritickým kritickým bodem, protože vaše platforma roste, což omezuje případy použití cílové zóny napříč daty a sdílení datových sad. V průběhu času také pravděpodobně vytvoří více kopií datových sad.
Tento návrh má také vliv na latenci, což je zvláště důležité ve scénářích analýzy v reálném čase.
Souhrn:
Souhrn tradiční architektury hub a paprsků
Tento hvězdicový návrh sítě má správu přístupu a některé výhody správy služeb, ale kvůli kritickým omezením správy služeb a šířky pásma a latence nemůžeme tento návrh sítě doporučit pro případy použití cílové zóny napříč daty.
Architektura projekce privátních koncových bodů (nedoporučuje se)
Další možností návrhu je projekce privátních koncových bodů v každé cílové zóně a každé cílové zóně. V tomto návrhu se v každé cílové zóně vytvoří privátní koncový bod pro účet úložiště A. To vede k prvnímu privátnímu koncovému bodu v cílové zóně dat A připojené k virtuální síti v cílové zóně dat A, druhému privátnímu koncovému bodu připojenému k virtuální síti v cílové zóně dat B atd.
Totéž platí pro účet úložiště B a potenciálně i pro jiné služby v cílových zónách dat. Pokud definujeme počet cílových zón dat jako n, skončíme s n privátními koncovými body pro alespoň všechny účty úložiště a potenciálně další služby v rámci cílových zón dat. To vede k exponenciálnímu zvýšení počtu privátních koncových bodů.
Obrázek 4. Architektura projekce privátního koncového bodu
Vzhledem k tomu, že všechny privátní koncové body konkrétní služby (například účet úložiště A) mají stejný plně kvalifikovaný název domény (napříkladstorageaccounta.privatelink.blob.core.windows.net), toto řešení vytváří problémy ve vrstvě DNS, která se nedá vyřešit pomocí Privátní DNS zón. Místo toho potřebujete vlastní řešení DNS, které dokáže přeložit názvy DNS na základě původu nebo IP adresy odesílatele dotazu. Díky tomu se virtuální počítač A připojí k privátním koncovým bodům připojeným k virtuální síti v cílové zóně dat A a aby se virtuální počítač B připojil k privátním koncovým bodům připojeným k virtuální síti v cílové zóně dat B. Můžete to provést pomocí nastavení založeného na Windows Serveru, zatímco životní cyklus záznamů DNS A můžete automatizovat pomocí kombinace protokolu aktivit a Azure Functions.
V tomto nastavení můžete načíst nezpracovanou datovou sadu v účtu úložiště A do virtuálního počítače B tak, že k datové sadě přistupujete přes místní privátní koncový bod (1). Po načtení a zpracování datové sady ((2) a (3)) ji můžete uložit do účtu úložiště B přímým přístupem k místnímu privátnímu koncovému bodu (4). V tomto scénáři nesmí data procházet žádnými napojeními virtuálních sítí.
Správa uživatelských přístupů v architektuře projekce privátních koncových bodů
Přístup tohoto návrhu ke správě uživatelských přístupů je podobný přístupu k síťové architektuře v síti. V tomto návrhu ale můžete vyžadovat přístupová práva pro jiné cílové zóny dat, abyste mohli vytvářet privátní koncové body nejen v rámci určené cílové zóny dat a virtuální sítě, ale také v jiných cílových zónách dat a jejich příslušných virtuálních sítích.
Z tohoto důvodu vyžadují týmy datových aplikací tři věci, ne dvě, aby mohly vytvářet nové služby sami:
- Zápis přístupu ke skupině prostředků v určené cílové zóně dat
- Připojení přístupu k určené podsíti
- Přístup ke skupině prostředků a podsíti ve všech ostatních cílových zónách dat za účelem vytvoření příslušných místních privátních koncových bodů
Tento návrh sítě zvyšuje složitost vrstvy správy přístupu, protože týmy datových aplikací vyžadují oprávnění v každé cílové zóně dat. Návrh může být také matoucí a vést k nekonzistentnímu řízení přístupu na základě role v průběhu času.
Pokud týmům cílové zóny dat a týmům datových aplikací nejsou udělena potřebná přístupová práva, dojde k problémům popsaným v tradiční hvězdicové architektuře (nedoporučuje se).
Souhrn:
Správa služeb v architektuře projekce privátních koncových bodů
I když se tento návrh sítě podobá návrhu síťové architektury sítě, má tento návrh sítě výhodu, že žádné síťové virtuální zařízení nefunguje jako jediný bod selhání nebo omezování propustnosti. Snižuje také režii na správu centrálního týmu platformy Azure tím, že neodesílá datové sady prostřednictvím centra připojení, protože není potřeba škálovat virtuální zařízení na více instancí. To znamená, že centrální tým platformy Azure už nemůže kontrolovat a protokolovat veškerý provoz odesílaný mezi cílovými zónami dat. Analýza na úrovni cloudu je ale koherentní platforma, která obsahuje několik předplatných, což umožňuje škálování a překonat omezení na úrovni platformy, takže to není nevýhodou.
Se všemi prostředky hostovanými v rámci jednoho předplatného se provoz nekontroluje v centru centrálního připojení. Protokoly sítě můžete stále zaznamenávat pomocí protokolů toku skupiny zabezpečení sítě a pomocí nastavení diagnostiky specifické pro službu můžete konsolidovat a ukládat další protokoly na úrovni aplikací a služeb. Všechny tyto protokoly můžete zachytit ve velkém měřítku pomocí zásad Azure. Na druhou stranu se adresní prostor sítě vyžadovaný vaší datovou platformou zvyšuje kvůli exponenciálnímu nárůstu požadovaných privátních koncových bodů, což není optimální.
Hlavními obavami týkajícími se této síťové architektury jsou dříve uvedené výzvy DNS. Nemůžete použít nativní řešení Azure ve formě privátních zón DNS, takže tato architektura vyžaduje řešení třetí strany schopné přeložit plně kvalifikované názvy domén na základě původu nebo IP adresy žadatele. Musíte také vyvíjet a udržovat nástroje a pracovní postupy pro automatizaci záznamů A-private DNS, které výrazně zvyšují režijní náklady na správu v porovnání s navrhovaným řešením řízeným Azure Policy.
Pomocí Privátní DNS zón můžete vytvořit distribuovanou infrastrukturu DNS, ale tím se vytvoří ostrovy DNS, které nakonec způsobují problémy při pokusu o přístup ke službám privátního propojení hostovaným v jiných cílových zónách ve vašem tenantovi. Tento návrh proto není proveditelnou možností.
Souhrn:
Náklady na architekturu projekce privátních koncových bodů
Poznámka:
Při přístupu k privátnímu koncovému bodu v rámci partnerské sítě se vám budou účtovat pouze samotné privátní koncové body, a ne za partnerský vztah virtuálních sítí. Oficiální prohlášení si můžete přečíst v nejčastějších dotazech: Jak bude fakturace fungovat při přístupu k privátnímu koncovému bodu z partnerské sítě?
V tomto návrhu sítě se vám účtují jenom privátní koncové body (za hodinu) a příchozí a výchozí provoz odesílaný těmito privátními koncovými body za načtení nezpracovaných datových sad (1) a ukládání zpracovaných datových sad (4). Kvůli exponenciálnímu zvýšení počtu privátních koncových bodů datové platformy se ale musí očekávat další náklady. Vzhledem k tomu, že se vám účtují poplatky za hodinu, množství dodatečných nákladů závisí na tom, kolik privátních koncových bodů se vytvoří.
Souhrn:
Šířka pásma a latence v architektuře projekce privátních koncových bodů
Tento návrh nemá žádná známá omezení šířky pásma a latence, protože nemá žádná síťová virtuální zařízení omezující propustnost pro výměnu dat cílové zóny mezi daty. Jediným mezním faktorem návrhu je fyzický limit našich datacenter (rychlost kabelů optických vláken).
Souhrn:
Souhrn architektury projekce privátního koncového bodu
Exponenciální růst privátních koncových bodů v této síťové architektuře může způsobit ztrátu toho, které privátní koncové body se používají k jakému účelu v jakém umístění. Jste také omezeni problémy se správou přístupu a složitostí vrstvy DNS. Kvůli těmto problémům nemůžeme tento návrh sítě doporučit pro případy použití cílové zóny napříč daty.
Privátní koncové body v architektuře centra připojení (nedoporučuje se)
Další možností sítě je hostování privátních koncových bodů ve vašem centru připojení a jejich připojení k virtuální síti centra. V tomto řešení hostujete jeden privátní koncový bod pro každou službu ve vaší podnikové virtuální síti. Vzhledem k existující hvězdicové síťové architektuře ve většině společností a faktu, že vaše centrum připojení hostuje vaše privátní koncové body v tomto řešení, není potřeba průchodnost. Propojení virtuální sítě mezi Centrem konektivity a zónami příjmu dat umožňuje přímý přístup.
Data procházejí jedním partnerským vztahem virtuální sítě mezi centrem připojení a cílovou zónou dat, aby se načetla datová sada uložená v účtu úložiště A ve virtuálním počítači B. Po načtení a zpracování datové sady (3) a (4)) prochází stejným partnerským vztahem virtuální sítě podruhé (5), než se nakonec uloží do účtu úložiště B prostřednictvím privátního koncového bodu připojeného k virtuální síti centra (6).
obrázek 5: Privátní koncové body v architektuře centra připojení
Správa uživatelských přístupů v architektuře centra připojení
V tomto návrhu sítě potřebují týmy cílové zóny dat a týmy datových aplikací dvě věci, aby bylo možné připojit privátní koncové body k virtuální síti centra:
- Zápis oprávnění ke skupině prostředků v předplatném centra připojení
- Přidání oprávnění k virtuální síti hubu
Vaše centrum připojení je určené pro tým vaší organizace odpovědný za platformu Azure a je vyhrazené pro hostování nezbytné a sdílené síťové infrastruktury vaší organizace (včetně firewallů, brán a nástrojů pro správu sítě). Tato síťová možnost činí návrh nekonzistentním, protože nenásleduje principy správy přístupu ze základních principů přistávací zóny Enterprise-Scale. Většina týmů platformy Azure proto tuto možnost návrhu neschválí.
Souhrn:
Správa služeb v architektuře centra připojení
I když se podobá návrhu síťové architektury se sítí, nemá tento návrh žádné síťové virtuální zařízení, které funguje jako jediný bod selhání nebo omezování propustnosti. Snižuje také režii na správu centrálního týmu platformy Azure tím, že neodesílá datové sady prostřednictvím centra připojení, protože není potřeba škálovat virtuální zařízení na více instancí. To znamená, že centrální tým platformy Azure už nemůže kontrolovat a protokolovat veškerý provoz odesílaný mezi cílovými zónami dat. Analýza na úrovni cloudu je ale koherentní platforma, která obsahuje několik předplatných, což umožňuje škálování a překonat omezení na úrovni platformy, takže to není nevýhodou.
Se všemi prostředky hostovanými v rámci jednoho předplatného se provoz nekontroluje v centru centrálního připojení. Protokoly sítě můžete stále zaznamenávat pomocí protokolů toku skupiny zabezpečení sítě a pomocí nastavení diagnostiky specifické pro službu můžete konsolidovat a ukládat další protokoly na úrovni aplikací a služeb. Všechny tyto protokoly můžete zachytit ve velkém měřítku pomocí zásad Azure.
Tento návrh také umožňuje vytvořit nativní řešení DNS Azure založené na Privátní DNS zónách a umožňuje automatizovat životní cyklus záznamu DNS A prostřednictvím zásad Azure.
Souhrn:
Náklady na architekturu centra připojení
Poznámka:
Při přístupu k privátnímu koncovému bodu v rámci partnerské sítě se vám budou účtovat pouze samotné privátní koncové body, a ne za partnerský vztah virtuálních sítí. Oficiální prohlášení si můžete přečíst v nejčastějších dotazech: Jak bude fakturace fungovat při přístupu k privátnímu koncovému bodu z partnerské sítě?
V tomto návrhu sítě se vám účtují jenom vaše privátní koncové body (za hodinu) a příchozí a odchozí provoz odesílaný těmito privátními koncovými body za načtení nezpracované datové sady (1) a uložení zpracované datové sady (6).
Souhrn:
Šířka pásma a latence v architektuře centra připojení
Tento návrh nemá žádná známá omezení šířky pásma a latence, protože nemá žádná síťová virtuální zařízení omezující propustnost pro výměnu dat cílové zóny mezi daty. Jediným mezním faktorem návrhu je fyzický limit našich datacenter (rychlost kabelů optických vláken).
Souhrn:
Souhrn privátních koncových bodů v architektuře centra připojení
I když tento návrh architektury sítě má několik výhod, jeho dříve zmíněná správa přístupu je nekonzistencí, což je podparovat. Tento přístup k návrhu proto nemůžeme doporučit.
Závěr o připojení cílové zóny dat v jedné oblasti
Ze všech kontrolovaných možností síťové architektury a jejich výhod a nevýhod je jasná síťová architektura . Má obrovské výhody pro propustnost a správu, což je důvod, proč ho doporučujeme použít při nasazování analýz v cloudovém měřítku. Virtuální sítě peeringové paprsky nebyly dříve běžné a to vedlo k problémům se sdílením datových sad mezi doménami a obchodními jednotkami.
Analýzy v cloudovém měřítku můžete zobrazit jako ucelené řešení, které zahrnuje více předplatných. V nastavení jednoho předplatného se tok síťového provozu rovná toku v síťové architektuře se sítí. V rámci jednoho nastavení předplatného se uživatelé s největší pravděpodobností dostanou k limitům a kvótám na úrovni předplatného platformy, kterým se má analýza na úrovni cloudu vyhnout.