Azure Hybrid Benefit: kolik jader potřebujete

V Azure stačí u Windows VM zapnout přepínač pro existující licenci. Účet se potom změní, ale portál neví, kolik způsobilých Windows Server licencí firma vlastní, do kdy platí jejich Software Assurance ani zda je zároveň používá jinde. Když se k inventuře přistoupí až po zapnutí benefitu, bývá obtížné rekonstruovat původní přiřazení.

Pro běžné Windows Server VM uvádějí aktuální Product Terms pro MCA pokrytí všech virtuálních jader, nejméně osm core licencí na každou běžící VM. Způsobilost a souběžné využití licencí musíte posoudit zvlášť. Datacenter nepřináší neomezený počet běžných Azure VM jen tím, že její název vidíte na operačním systému.

Článek řeší Azure Hybrid Benefit pro Windows Server na běžných Azure VM. SQL Server, Azure Dedicated Host, Azure Local a AKS mají odlišné podmínky. Pracujeme s Product Terms Microsoft Azure Services pro MCA a aktuálními návody, ověřenými 14. října 2026. U jiného smluvního programu nejdřív vyberte jeho vlastní podmínky.

Co přepínač skutečně změní

Azure Hybrid Benefit umožní využít způsobilá existující práva Windows Serveru a platit základní výpočetní sazbu VM namísto sazby zahrnující Windows Server. Neodstraní úhradu disků, sítí ani dalších používaných služeb. Úsporu počítejte nad shodnou velikostí VM, regionem a dobou provozu; neporovnávejte součet celého Azure účtu s cenou samotné licence.

Microsoft v návodu k použití benefitu uvádí, že změna licenčního typu běžící VM mění metadata a nevyvolává restart. Právě proto není úspěšné zapnutí licenčním testem. Technická operace nevyžaduje, abyste připojili doklad ke každé přidělené core licenci.

V evidenci od sebe oddělte konfiguraci benefitu, spotřebu způsobilých práv a účtovanou spotřebu Azure. Každý z těchto údajů odpovídá na jinou otázku. Rozdíl mezi nimi je důvod k prověření, ne automatický důkaz chyby fakturace.

Licence musí být způsobilé i dnes

Microsoft pro Windows Server Standard a Datacenter požaduje odpovídající komerční program a aktivní Software Assurance nebo způsobilé předplatné. Samotné vlastnictví trvalé licence bez platného požadovaného pokrytí nestačí. Oprávnění trvá jen po dobu příslušné SA či předplatného, jak uvádí přehled Azure Hybrid Benefit.

Pokud pokrytí končí, předem rozhodněte o obnovení, vypnutí benefitu nebo ukončení dotčeného provozu. Nečekejte, zda VM sama přestane fungovat. Do změnového kalendáře patří datum expirace licenčních dokladů stejně jako expirace rezervace či certifikátu.

Jde o navrženou redakční evidenci, nikoli povinný formulář Microsoftu. Má spojit licenční doklady s technickým provozem tak, aby bylo možné výsledek zopakovat při další inventuře.

Počítejte každou VM zvlášť

Aktuální Azure Product Terms pro MCA stanoví minimum osm core licencí na VM. Návody Microsoftu výslovně potvrzují, že čtyřjádrová instance stále potřebuje osm a dvanáctijádrová potřebuje dvanáct. Není správné nejdřív sečíst všechna vCPU a teprve na celkový součet uplatnit jediné minimum.

Modelový příklad: jeden tým chce benefit pro čtyři běžné VM se dvěma, čtyřmi, osmi a dvanácti virtuálními jádry. Všechny jsou současně v provozu a fond obsahuje 32 způsobilých core licencí stejného posuzovaného druhu. Neřešíme zde dostupnost, výkon ani skutečnou cenovou nabídku.

Výsledek je 36 core licencí, nikoli 26 nebo 32. Fond 32 tedy nestačí pro popsané zapnutí benefitu na všech čtyřech VM. Lze doplnit způsobilá práva nebo část VM provozovat bez benefitu; rozhodnutí musí odpovídat plánovanému provozu, ne jen právě otevřenému seznamu v portálu.

Pokud benefit použijete pouze pro A, C a D, požadavek modelu je 28 core licencí a B zůstává účtovaná bez něj. To je jedna přípustná matematická varianta při splnění ostatních podmínek. Není tím prokázáno, že jde o nejlevnější variantu: hodinový rozdíl sazeb závisí na konkrétní VM a regionu.

Také dvě malé VM po čtyřech jádrech spotřebují v tomto modelu 16 core licencí, zatímco jedna osmijádrová osm. To je důsledek minima, nikoli doporučení služby automaticky sloučit. Konsolidace může změnit dostupnost, bezpečnostní oddělení, nároky aplikací a výkon; nákladový přínos má smysl teprve po těchto kontrolách.

Proč starší výpočet po šestnácti může zavést

Windows Server licensing FAQ stále popisuje sadu 16 core licencí pro nejvýše dvě Azure Base Instances s dohromady až 16 virtuálními jádry. Aktuální Product Terms pro zde zvolený MCA program a aktuální Azure návody formulují minimum osm na VM. Tyto formulace proto nepoužívejte současně jako jeden univerzální vzorec.

Při kontrole starší kalkulace zaznamenejte, z jakého dokumentu, programu a znění vycházela. Z rozdílu dokumentace nelze bez dalšího vyhlásit datum změny všech smluv nebo změnit práva historické objednávky. Pro současný návrh použijte odpovídající smluvní podmínky a zachovejte důkaz jejich ověření.

Další zdroj zmatku je balení licence. Položka zahrnující dvě core licence není jedna licence na dvě VM; 16jádrový balíček není automaticky 16 samostatných virtuálních serverů. Inventuru sjednoťte na počet způsobilých core licencí a jednotku balení nechte jen jako údaj objednávky.

Standard a Datacenter mají jiný souběh

Přehled Microsoftu u Standardu rozlišuje použití on-premises nebo v Azure. Jednorázový souběh až 180 dnů umožňuje migraci stejné pracovní zátěže. Není to opakující se půlroční výjimka pro trvalý paralelní provoz dvou nezávislých prostředí.

U Datacenter dokumentace pro licencování jednotlivých Azure VM uvádí možnost souběžného použití on-premises a v Azure bez tohoto časového omezení. Pravidlo nepřenášejte na Dedicated Host: pro něj tentýž přehled popisuje jiné podmínky a 180denní migrační souběh. Pořád musíte přidělit dostatek práv pro zvolený model a udržovat jejich způsobilost.

Ani skutečnost, že Azure image používá Windows Server Datacenter, nedokazuje pořízení on-premises Datacenter licence. Product Terms dovolují pod benefitem použít Standard nebo Datacenter software; souběžná práva posuzujte podle způsobilých licencí, které jste skutečně přiřadili.

Audit konfigurace není audit oprávnění

Pro technickou inventuru Microsoft popisuje kontrolu hodnoty licenseType, například Windows_Server, a seznam VM i virtual machine scale sets. Implementační návod však také ukazuje, že změna licenčního typu je pouze konfigurační příznak. Hodnota sama nerozlišuje, jaký doklad Standard či Datacenter používáte.

Zahrňte všechny relevantní subscriptions, scale sets a změny počtu instancí. U skupiny, která roste podle zátěže, není jednorázový ranní snímek dokladem pokrytí odpoledního maxima. Připravte vazbu mezi technickou změnou a dostatečným fondem licencí; případný limit škálování musí být skutečně dodržovaný.

1. Vymezte prostředí. Běžné Windows Server VM oddělte od Dedicated Host, Azure Local, klientských Windows a SQL benefitu.
2. Exportujte technickou inventuru. ID prostředku, subscription, velikost, počet jader, licenční příznak a škálování; nezaměňujte počet objektů scale set za počet VM.
3. Spočítejte spotřebu po VM. Minimum a skutečná virtuální jádra použijte na každou jednotku zvlášť. Model založte na provozu, který může nastat.
4. Přiřaďte licenční doklady. Edice, core počet, smluvní program, SA či předplatné a jejich konec platnosti. Zkontrolujte využití týchž práv mimo Azure.
5. Doložte případnou migraci. Zátěž, začátek přiřazení, plán ukončení původního provozu a odpovědnou osobu.
6. Porovnejte následné účtování. Příznak benefitu a skutečný účet kontrolujte odděleně; přehled Microsoftu upozorňuje na zpoždění fakturačních údajů.
7. Navazujte na změny. Resize, nový tým, autoscaling a obnova SA vyžadují novou kontrolu evidence, ne pouze potvrzení původního nastavení.

Pro fyzické hosty a cluster pokračujte samostatným výpočtem licencí Windows Serveru. Azure fond a fyzickou virtualizaci neslučujte do jediného čísla bez rozlišení jejich pravidel.