SQL Server AHUB compliance — does deallocating a VM before enabling AHUB on a new VM avoid over-allocation with a single license?

Question

I have a scenario I can't find documented anywhere and want to confirm before I assume either way.

Setup:

• I have one SQL Server core license with active Software Assurance.
• VM1: created, SQL Server AHUB enabled → later deallocated (not deleted, still exists as a resource).
• VM2: created afterward, SQL Server AHUB enabled and currently running.

At no point did I explicitly untick AHUB on VM1 before deallocating it — it's still flagged as AHUB license type, just deallocated.

What I already found:

For Windows Server AHUB, Microsoft's own docs list deallocating a VM as one of three valid remediation options when you don't have enough licenses for your deployed VMs (alongside purchasing more licenses or disabling AHUB) — see "Explore Azure Hybrid Benefit for Windows VMs" on Microsoft Learn. That implies a deallocated Windows VM drops out of the "deployed VMs needing licenses" count.

What I can't find:

Nothing equivalent for SQL Server AHUB specifically. SQL AHUB is tracked per-core via the SQL IaaS Agent extension / SqlVirtualMachine resource, not a simple flag, so I don't want to assume the Windows precedent applies the same way.

My question:

1. Does a deallocated SQL VM with AHUB still enabled count against my SQL Server core license entitlement, or does deallocation remove it from the compliance calculation the same way it apparently does for Windows Server AHUB?
2. Is having AHUB flagged "on" simultaneously on two SQL VMs (one deallocated, one running) with only one license a compliance violation, or is deallocation an accepted way to free up that entitlement for reassignment?
3. Should I explicitly disable AHUB on the deallocated VM regardless, as a best practice, even if deallocation alone technically resolves the entitlement math?

Any citation to official Microsoft Product Terms or Licensing docs specifically covering SQL Server AHUB + deallocated VMs would be appreciated — I want something citable, not just general guidance. I have a scenario I can't find documented anywhere and want to confirm before I assume either way.

Setup:

• I have one SQL Server core license with active Software Assurance.
• VM1: created, SQL Server AHUB enabled → later deallocated (not deleted, still exists as a resource).
• VM2: created afterward, SQL Server AHUB enabled and currently running.

At no point did I explicitly untick AHUB on VM1 before deallocating it — it's still flagged as AHUB license type, just deallocated.

What I already found:

For Windows Server AHUB, Microsoft's own docs list deallocating a VM as one of three valid remediation options when you don't have enough licenses for your deployed VMs (alongside purchasing more licenses or disabling AHUB) — see "Explore Azure Hybrid Benefit for Windows VMs" on Microsoft Learn. That implies a deallocated Windows VM drops out of the "deployed VMs needing licenses" count.

What I can't find:

Nothing equivalent for SQL Server AHUB specifically. SQL AHUB is tracked per-core via the SQL IaaS Agent extension / SqlVirtualMachine resource, not a simple flag, so I don't want to assume the Windows precedent applies the same way.

My question:

1. Does a deallocated SQL VM with AHUB still enabled count against my SQL Server core license entitlement, or does deallocation remove it from the compliance calculation the same way it apparently does for Windows Server AHUB?
2. Is having AHUB flagged "on" simultaneously on two SQL VMs (one deallocated, one running) with only one license a compliance violation, or is deallocation an accepted way to free up that entitlement for reassignment?
3. Should I explicitly disable AHUB on the deallocated VM regardless, as a best practice, even if deallocation alone technically resolves the entitlement math?

Any citation to official Microsoft Product Terms or Licensing docs specifically covering SQL Server AHUB + deallocated VMs would be appreciated — I want something citable, not just general guidance.

Answer 1

Hi Saurabh Rana,

Thank you for reaching out to the Q&A forum.

The safest approach is to disable SQL Server AHUB on VM1 after deallocating it.

Microsoft clearly mentions deallocation for Windows Server AHUB, but there is no clear SQL Server AHUB documentation confirming that deallocation automatically releases the SQL license.

So, to avoid any licensing risk, remove AHUB from VM1 and then use the license for VM2.

We hope this helps. Thank you for using the Q&A forum.

Answer 2

Hello @Saurabh Rana

Your caution about applying the Windows Server AHUB behavior to SQL Server AHUB is justified. For SQL Server, I would not treat VM deallocation by itself as a license reassignment mechanism.

The controlling language is in the Microsoft Product Terms for Azure Hybrid Benefit for SQL Server:

Once licenses are allocated to Azure, they may not be used elsewhere, and only after at least 90 days may the customer stop using them for Azure Hybrid Benefit.

That distinction is important in your scenario.

You currently have:

VM1, SQL license type: AHUB, VM state: Deallocated

VM2, SQL license type: AHUB, VM state: Running

Deallocating VM1 stops its compute consumption, but it doesn't itself change the SQL VM's configured licensing model. Microsoft documents AHUB as an allocation of your eligible SQL Server licenses to the SQL Server VM, and the SQL VM's license model remains an explicit property that can be changed between PAYG, AHUB, and applicable HA/DR licensing.

So I would separate billing behavior from licensing compliance.

A deallocated VM isn't generating normal running compute/SQL usage, but that doesn't establish that the SQL licenses previously allocated to it have automatically become available for reassignment to another VM.

For your three questions:

1. Does deallocation automatically free the SQL AHUB entitlement?

I can't find Microsoft Product Terms language saying that deallocation of a SQL VM constitutes deallocation/reassignment of the underlying SQL Server licenses.

The Product Terms instead govern the license allocation itself, including the 90-day rule.

Therefore, I wouldn't rely on deallocation alone for licensing compliance.

2. Can VM1 remain AHUB while VM2 is also AHUB with only enough licenses for one?

Not merely because VM1 is deallocated.

If the same SQL Server core licenses are still allocated to VM1 and you haven't satisfied the applicable reassignment/allocation requirements before allocating them to VM2, the fact that VM1 isn't currently running doesn't by itself establish compliance.

Also keep in mind that SQL Server on Azure VMs generally has a 1:1 relationship between VM vCores and SQL core licenses, subject to the applicable licensing minimums and edition rights. Microsoft confirms the 1:1 vCore/core relationship in the SQL VM licensing FAQ.

3. Should AHUB be explicitly removed from VM1?

Yes, I would consider that the cleaner operational practice once you're legally entitled to reassign/stop using those licenses there.

You can explicitly change the SQL VM license type rather than leaving an unused VM permanently marked AHUB. Microsoft documents changing the SQL VM licensing model through the Azure portal, PowerShell, or Azure CLI.

The 90-day rule is the critical part

For example, if your SQL licenses were allocated to VM1 on May 1, deallocating VM1 on May 20, doesn't mean those licenses automatically become freely reassignable to VM2 on May 21.

The Microsoft Product Terms state that the customer may elect to stop using licenses for Azure Hybrid Benefit after at least 90 days have passed.

There are separate rights such as Microsoft's 180-day Azure migration allowance, but that shouldn't be confused with the 90-day allocation rule. Microsoft documents the migration allowance separately.

One more distinction: if your organization uses centrally managed Azure Hybrid Benefit, the mechanics are different. Azure evaluates eligible SQL resource usage at the subscription/billing scope and applies centrally assigned normalized cores against hourly consumption. In that case, the individual VM's AHUB setting isn't the entire licensing picture.

Bottom line

I would not use “deallocated VM = SQL license automatically available elsewhere” as the compliance rule.

For SQL Server AHUB, treat these as separate events:

VM deallocation ≠ SQL license deallocation/reassignment

Follow the SQL Server license-allocation rights in the Product Terms, including the 90-day requirement, and explicitly update the licensing configuration when the entitlement is legitimately moved.

For an audit/compliance determination, the Microsoft Product Terms applicable to your specific licensing agreement take precedence, and Microsoft also recommends involving your Microsoft licensing contact/account manager for agreement-specific interpretations.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.