Cloud Tip: Azure Service Groups – nový způsob organizace zdrojů v Azure

Úvod: Proč potřebujeme další typ skupin?

Azure poskytuje několik mechanismů pro organizaci cloudových prostředků – nejčastěji Resource Groups (logické skupiny zdrojů v rámci jednoho předplatného) a Management Groups (hierarchické skupiny předplatných pro účely governance). Dále lze zdroje volně označovat tagy (štítky) napříč celým tenantem. Každý z těchto přístupů má však svá omezení. Resource Groups jsou pevně svázané s jedním subscription a každý prostředek může být právě v jedné Resource Group. Management Groups umožňují aplikovat politiky či role na více subscription najednou, ale opět – jedno předplatné může být jen v jedné větvi hierarchie a nelze jimi přímo seskupit jednotlivé zdroje. Tagy jsou sice flexibilní, ale v praxi bývají nekonzistentní (různí lidé volí různé tagy, nejsou povinné) a ne všechny typy zdrojů je podporují. Navíc tagy nepředstavují žádnou hierarchii ani strukturu – jsou to pouze volitelné metadata u jednotlivých položek.

Výsledkem je, že ve větších cloudových prostředích může být obtížné získat ucelený přehled o určitých logických celcích napříč Azure. Například: Jak zobrazit všechny produkční aplikace najednou, když jsou rozloženy do více resource groups a různých subscription? Jak delegovat správu skupiny prostředků pro konkrétní tým, aniž by měl plná práva k celému subscription? Právě takové problémy řeší Azure Service Groups – zcela nová funkce oznámená na jaře 2025 (Build 2025) jako veřejný preview.

Co jsou Azure Service Groups a k čemu slouží

Azure Service Groups (SG) představují novou logickou vrstvu pro seskupování Azure zdrojů napříč různými částmi prostředí. Lze je popsat jako virtuální skupiny zdrojů, které existují paralelně k běžné hierarchii Azure (tj. vedle Resource Groups, Management Groups a předplatných). Na rozdíl od Resource Groups však nevyžadují, aby zdroje byly na jednom místě – Service Group může zahrnovat libovolné prostředky, resource groupy nebo dokonce celá předplatná bez ohledu na to, kde v Azure se fyzicky nacházejí. Uživatel si tak může nadefinovat vlastní kolekce zdrojů, které dávají smysl z pohledu jeho aplikace, týmu či účelu. Service Groups poskytují sjednocený pohled a správu těchto kolekcí, aniž by bylo nutné cokoliv měnit na stávající struktuře cloudového prostředí.

Obr. 1: Koncept Azure Service Groups – vpravo je naznačena paralelní hierarchie vlastních Service Group (SG) nad stávající strukturou tenantu (vlevo). Zdroje z různých resource groups či subscription mohou být propojeny (jako členové) do jedné nebo více Service Group podle potřeby. Resource Group tedy zůstávají primární jednotkou pro správu a životní cyklus zdrojů, Service Group tvoří dodatečné logické „pohledy“.

Azure Service Groups jsou aktuálně ve fázi Public Preview, což znamená, že funkce je dostupná k vyzkoušení, ale může se ještě měnit a nelze ji zatím využít s plnou podporou SLA. Pro zapnutí SG je typicky potřeba přihlásit tenant do preview programu (přes odkaz či nastavení preview ve vašem Azure účtu).

Hlavní vlastnosti a možnosti Service Groups

• Flexibilní seskupování napříč hranicemi: Service Groups umožňují seskupit prostředky napříč různými subscription a resource groups. Jediná Service Group tak může obsahovat například zdroje z více předplatných najednou, případně kombinovat celé resource groupy a individuální prostředky. To přináší zcela nové scénáře, jako je seskupení globálně sdílených prostředků z více projektů do jedné skupiny – něco, co dosud žádný z typů Azure skupin neumožňoval. Členem Service Group se může stát libovolný typ zdroje, ale také celý kontejner (resource group či subscription). Technicky je členství realizováno přes nový resource provider Microsoft.Relationships, který vytváří vazbu typu ServiceGroupMember mezi Service Group a daným zdrojem. Důležité je, že při přidání do SG nedochází k přesunu ani duplikaci zdroje – jde čistě o logické propojení.

• Vícenásobné členství a křížové hierarchie: Stejný prostředek (nebo celá resource group/subscription) může být členem více Service Groups současně. Tím Azure poprvé umožňuje vytvářet více souběžných pohledů na tytéž zdroje – např. jeden pohled dle organizační struktury, jiný dle prostředí provozu, další dle technického typu služby. Z pohledu návrhu SG tedy nevzniká „jedna správná“ hierarchie, ale můžete udržovat několik různých hierarchií podle potřeby různých uživatelských person. Service Groups samotné lze navíc vnořovat (nesting) do stromové struktury. Jedna Service Group může obsahovat jiné Service Group jako podskupiny (podobně jako Management Groups mohou být vnořené). Takto si lze vystavět až 10 úrovní hlubokou hierarchii vlastních skupin. Na vrcholu hierarchie stojí automaticky vytvořená Root Service Group reprezentující celý tenant (její ID odpovídá ID vašeho Azure tenantu). Uživatelé nemají možnost měnit či odstranit root skupinu – slouží jako výchozí rodič pro všechny ostatní SG.

• Nízké nároky na oprávnění: Architektura Service Groups je navržena tak, aby správa SG a jejich členů šla delegovat s minimálními nutnými právy. K vytvoření Service Group vám stačí běžný uživatelský účet v daném tenantovi (není potřeba být Owner předplatného apod.). Azure pro SG zavedlo samostatné built-in role (Service Group Administrator, Contributor, Reader) omezující přístup jen na správu SG, nikoliv nutně k obsahu samotných zdrojů. Díky tomu lze dát například projektovému manažerovi možnost definovat a vidět skupinu „jeho“ zdrojů, aniž by byl rovnou správce všech těchto zdrojů. Role přiřazené na SG se totiž nepřenášejí dolů na členské prostředky jako u Resource Group. To zajišťuje, že Service Group může sloužit čistě organizačnímu účelu a neobchází standardní bezpečnostní model Azure. (Např. udělení role Reader na Service Group dá uživateli přístup číst jen metadata dané SG, ale ne automaticky číst všechny obsažené prostředky, pokud k nim nemá práva i jinak.)

• Integrace s Azure Resource Graph a monitoringem: Service Groups jsou integrované s platformou dotazů Azure Resource Graph (ARG). To znamená, že můžete využívat Resource Graph k vyhledávání napříč prostředími s ohledem na členství v Service Group. ARG umí pracovat s novým typem vztahu (serviceGroupMember), takže lze například dotazem snadno získat seznam všech zdrojů v určité Service Group, nebo naopak zjistit, do jakých Service Groups patří konkrétní zdroj. Service Groups také cílí na lepší agregaci provozních dat a metrik. Umožňují vytvářet centrální pohledy na stav aplikace či služby napříč různými částmi Azure. Microsoft dokonce představil koncept Azure Monitor Health Model, který nad Service Groups poskytuje sjednocené zobrazení zdravotního stavu aplikačních komponent v reálném čase. Díky SG tak lze například sledovat metriky napříč prostředími – třeba mít dashboard zobrazující výkon a dostupnost všech instancí určité aplikace, i když běží v několika různych subscription.

Omezení a srovnání s Resource Groups, Management Groups a tagy

Service Groups nenahrazují stávající skupiny v Azure, ale doplňují je tam, kde byly jejich možnosti omezené. Následuje shrnutí rozdílů oproti tradičním prostředkům pro organizaci zdrojů:

• Žádné zásahy do stávající struktury: Největší předností SG je, že jsou zcela nezávislé na formální hierarchii Azure. Nemusíte měnit umístění zdrojů, přesouvat je do jiných Resource Group ani reorganizovat předplatná – Service Groups „se překryjí“ přes status quo. To minimalizuje riziko – SG lze zavádět postupně a v případě potřeby i snadno odstranit (nejde o destruktivní akci). Naproti tomu změny struktur RG/MG či tagování často znamenají zásah do nastavení zdrojů.

• Omezený vliv na členy (bez politik a inheritu): Service Group funguje čistě jako logický kontejner pro přehled a správu, neslouží jako scope pro nasazování, politiku ani řízení přístupu. Nelze na ni tedy přímo aplikovat Azure Policy či Role Assignment s očekáváním, že se tím ovlivní její členové – na rozdíl od Resource/Management Groups, kde se nastavení dědí na podřízené zdroje. SG také nejde použít jako cíl pro nasazení ARM šablon nebo Bicep (deploy se musí stále provést do konkrétní Resource Group). Pro plošné konfigurace a governance tak zůstávají nadále klíčové Management Groups, subscription a Resource Groups. Service Groups míří spíše na organizační a provozní přehled než na enforcement.

• Unikátní vlastnost – napříč scope a vícenásobně: Oproti Resource Groups a Management Groups, které definují jedno pevné umístění pro prostředek resp. subscription, Service Groups umožňují volné křížové propojování napříč celým tenantem. Prostředek zůstává ve své Resource Group, ale zároveň může být členem třeba tří různých SG (např. podle aplikace, typu i prostředí). Subscription může být členem více Service Groups současně (což s Management Groups nejde). Tagy sice také lze kombinovat (jeden prostředek může mít mnoho tagů), ale tagy postrádají hierarchii a centrální evidenci členství. SG naproti tomu poskytují strukturálnější přístup – členství je entity v Azure (vztahy ServiceGroupMember), které lze auditovat a dotazovat, zatímco tagy jsou jen volný text na zdroji. Service Groups také dovolují hierarchii skupin (vnořené SG), což tagy vůbec nenabízejí.

• Konzistence vs. flexibilita tagů: Tagování zůstává užitečné pro klasifikaci zdrojů (zejména kvůli reportingu nákladů či podmínkám politik). Ale jelikož tagy nejsou striktně řízené, v praxi je často problém udržet jednotné konvence (např. jeden tým používá tag Environment=Prod, jiný Env=Production apod.). Service Groups mohou pomoci zavést pořádek – skupiny i jejich hierarchie jsou spravovány centrálně (typicky cloud architekty), takže se můžete domluvit na jednotném uspořádání a to snadno sdílet napříč organizací. Lze si je představit jako řízený adresář či složky, zatímco tagy jsou volné štítky. Na druhou stranu, SG zatím nelze automaticky aplikovat na nové zdroje (kdežto tagy lze vynucovat přes Policy) – ideální bude oba přístupy kombinovat.

• Limity a názvosloví: Aktuálně (verze Preview) platí několik limitů: v jednom tenantovi může existovat max. 10 000 Service Groups, každá hierarchie SG může mít max. 10 úrovní do hloubky (kořenová úroveň se nepočítá) a v rámci jednoho subscription lze vytvořit nejvýše 2 000 vazeb členství (tj. součet všech členů ze zdrojů v daném subscription). Počet členů v jedné SG není přímo omezen, limit 2 000 se vztahuje na zdroje v jednom subscription zapojené do všech SG – pokud byste tedy měli např. 3000 zdrojů v jednom předplatném, všechny je do SG aktuálně zařadit nelze. Dále platí, že ID (název) Service Group musí být globálně unikátní napříč všemi tenanty (podobně jako ID Management Group). Je tedy vhodné volit jednoznačné názvy (např. zahrnout zkratku firmy). ID nejde po vytvoření změnit, lze však nastavit libovolné Display Name (zobrazované jméno) a to později upravovat. Service Groups také nelze přejmenovat přesunem ve stromě (jako u složek) – změna rodičovské SG vytvoří ve skutečnosti novou vazbu. V neposlední řadě jsou v preview režimu omezené role – nelze definovat vlastní (custom) role pro SG, k dispozici jsou jen zmíněné vestavěné role.

Praktické příklady využití Service Groups

• DevOps (správa prostředí a nasazování): Týmy DevOps mohou využít Service Groups k logickému seskupení všech komponent jedné aplikace či služby napříč celým Azure. Například pro mikroservisovou aplikaci, která má zdroje ve více resource groups a několika předplatných, lze vytvořit SG „Aplikace X“ a do ní připojit všechny relevantní zdroje (databáze, VM, webové aplikace, apod. z dev, test i prod prostředí). Díky tomu získá vývojový a provozní tým jednotný pohled na svou aplikaci – pro monitoring, nasazování i správu. Můžeme využít i vnoření: pod hlavní SG aplikace vytvořit dílčí SG pro prod, test a dev část. To vše bez nutnosti konsolidovat zdroje fyzicky do jedné Resource Group. Tento princip se označuje jako workload-centric management a SG takto umožní strukturovat nasazení do modulárních celků.

• FinOps (sledování nákladů): Finanční a kontrolingové týmy řeší především náklady jednotlivých projektů a oddělení. Service Groups mohou pomoci získat lepší přehled o nákladech – lze je využít k seskupení všech zdrojů spojených s určitým produktem nebo zákazníkem napříč Azure. Například pokud aplikace „Project Alfa“ běží ve více regionech a má několik Resource Groups, můžete vytvořit SG „Project Alfa – All Resources“ a přidat do ní vše, co k projektu patří. Následně lze snadno analyzovat souhrnné metriky a náklady této skupiny (např. pomocí Resource Graph dotazu kombinovaného s cost daty). Jde o nový způsob, jak snáze přiřadit cloudové výdaje ke konkrétnímu projektu či týmu, doplňující zavedené postupy jako tagování nákladových středisek.

• Audit a bezpečnost: Pro bezpečnostní auditory a administrátory představují Service Groups užitečný nástroj, jak zkrotit chaos ve velkém prostředí. Lze si vytvořit specifické skupiny pro kritické nebo rizikové zdroje a těm věnovat zvláštní pozornost. Příklady: SG zahrnující všechny externě přístupné služby (VM s public IP, aplikační brány, apod.) napříč celým Azure – auditor pak může pravidelně kontrolovat konfiguraci této jedné skupiny, místo aby prohledával stovky Resource Groups. Podobně lze mít SG pro zdroje uchovávající citlivá data (databáze s osobními údaji atd.) a tu pak snadno monitorovat z hlediska šifrování, přístupů apod. Také při certifikačních auditech (ISO 27001, GDPR) může být užitečné rychle vypsat všechny zdroje v daném scope – stačí je sdružit do SG a dotazem či skriptem získat kompletní seznam k reportu. Dalším příkladem je SG pro compliance účely: např. centralizovat všechny prostředky, které musí splňovat určitý předpis, a provádět nad nimi cílené kontroly.

• Správa velkých tenantů a cloudové governance: V rozsáhlých organizacích s desítkami předplatných pomohou Service Groups zlepšit přehlednost a řízení. Umožní totiž vytvořit alternativní logické struktury, které lépe odpovídají provozním potřebám firmy. Například: Můžete vytvořit Service Group pro každé oddělení vaší společnosti (HR, Finance, IT, …) a přiřadit do ní všechny Azure prostředky, které to oddělení využívá – bez ohledu na to, v kolika jsou subscription. Nebo naopak sestavit SG napříč organizací pro určitý účel, třeba „Globální síťové služby“, kam zahrnete sdílené VNETy, ExpressRoute a firewall clustery ze všech koutů firmy. Tím získáte jednotný pohled na infrastrukturu, která je jinak rozdělena v různých subscripcích. Cloudoví administrátoři mohou SG použít i k vytvoření dočasných výběrů prostředků – např. připravit skupinu všech zdrojů, které plánují při hromadné údržbě aktualizovat. Možnosti jsou široké a podstatné je, že SG činí governance velkých cloudů pružnější a přehlednější tím, že umožní vytvářet vlastní pohledy podle potřeb dané role či týmu.

Doporučení pro české organizace

Azure Service Groups jsou nový nástroj, který může významně usnadnit správu a provoz větších cloudových prostředí – zejména tam, kde jste dosud naráželi na limity klasických Resource Groups a tagů. Pokud vaše firma v Azure spravuje mnoho předplatných, či potřebujete lepší kontrolu nad náklady a provozem napříč organizačními silo, určitě stojí za to se o SG zajímat. Jelikož jsou aktuálně ve veřejném preview, doporučujeme vyzkoušet Service Groups zatím pilotně na omezeném vzorku prostředí. Můžete si např. zapnout preview ve vašem testovacím tenantovi a vytvořit několik Service Groups pro vybranou aplikaci nebo projekt. Následně zapojte jak technické týmy (cloud adminy, DevOps), tak třeba finanční kontrolory, a získejte od nich zpětnou vazbu – sledujte, zda jim tento nový způsob organizace přináší užitek. Zavedení SG nevyžaduje žádnou změnu existující struktury ani konfigurace zdrojů, takže rizika jsou minimální. Naopak potenciální přínosy jsou velké: lepší pořádek, přehlednost a možnost dívat se na cloud z různých hledisek. Pokud se Azure Service Groups osvědčí, mohou se stát cenným doplňkem vašeho arzenálu pro správu cloudu – po boku stávajících nástrojů jako jsou Management Groups, policy nebo tagy. Vyzkoušení SG nic nestojí, takže směle do toho!