SQL Server Azure Arc brings inventory, security and ESU billing together

In many of the organizations I work with, nobody really knows how many SQL Server instances they run. They are spread across data centers, test labs and several clouds, and versions or patch levels are rarely documented. Every time we start looking, more forgotten SQL Servers turn up than anyone expected. This is where SQL Server Azure Arc earns its place. It gives you one inventory of all your SQL instances, wherever they run, and adds security insights, Defender and even ESU billing for SQL Server 2014 on top.

SQL Server Azure Arc finally shows every instance in one inventory

Inventory is the foundation of Arc-enabled SQL Server. As soon as you deploy the SQL Server extension on an Arc-enabled server, each SQL instance reports to the Azure portal with its version, edition, patch state and other details. In practice you finally get to see the sprawl: old development VMs, departmental SQL boxes nobody remembers, and servers that run outside your normal IT processes. In the Azure Arc blade you can filter and sort the list and spot outdated or unsupported versions within minutes. Patch management and lifecycle planning get a lot easier that way, and it is often the first real step towards retiring legacy systems.

Before I go into more detail, here is a quick flow diagram of how on-prem and cloud SQL Server instances connect to the Azure portal through Arc:

flowchart TD
    OnPremSQL["On-premises SQL Server"] --> ArcAgent["Arc Agent"]
    OtherCloudSQL["SQL Server other cloud"] --> ArcAgent
    ArcAgent --> AzureArc["Azure Arc Server"]
    AzureArc --> SQLExt["SQL Server extension"]
    SQLExt --> AzurePortal["Azure Portal: Inventory, Security, Billing"]

Figure: SQL Server instances report to the Azure portal through Arc.

Best practices assessments and Defender for SQL expose weak configurations

The inventory is only the beginning. The SQL Server Azure Arc integration also runs regular best practices assessments on every instance and checks for missing patches, risky authentication settings, vulnerable configurations and similar issues. The recommendations follow Microsoft's security baseline, and in many tenants I see they come as a shock, because insecure logins and unpatched servers suddenly become visible. If you want to go further, enable Defender for SQL. You then get threat detection and vulnerability scanning built in, plus continuous compliance reporting.

Pro tip: The assessment runs continuously. For proper monitoring or alerting, send the results to a central Log Analytics workspace and work with custom KQL queries or workbooks. That scales far better than checking things by hand.

For the technical details, have a look at Microsoft's SQL Server Azure Arc overview and the assessment documentation.

Entra authentication brings SSO and MFA to on-premises SQL Server

Starting with SQL Server 2022, Entra authentication (formerly Azure AD Auth) is supported not only in Azure but on any Arc-enabled SQL Server, on-premises included. You get real SSO, modern MFA and much better identity management, which matters most when on-prem SQL has to talk to cloud apps or Microsoft 365 services. The requirements are SQL Server 2022 or later, with Arc and the extension in place. In my projects, this usually leads straight to Conditional Access policies and centralized identity governance, so even legacy SQL workloads can be brought up to current compliance standards. If you want to read more about workload identities, see Workload identities in Entra ID: Managed identities, app registrations and securing your applications.

The licence type decides how SQL Server 2014 ESU gets billed

Extended support for SQL Server 2014 ended in July 2024, so many organizations now depend on Extended Security Updates (ESU) to keep receiving patches. SQL Server Azure Arc lets you register on-prem or cloud SQL instances for ESU directly. The part you have to get right is the licence type for each instance, which is either PAYG (pay-as-you-go) or 'licence with Software Assurance'. With PAYG, Azure bills your SQL usage by the hour, while SA-licensed instances keep their existing terms. I have seen wrongly set licence types lead to unpleasant billing surprises, particularly in large SQL estates. Keep an eye on this and document your licence settings carefully.

The setup takes three steps from Arc server to licence type

As long as the networking and firewall requirements are met, the technical setup is simple. You onboard the server to Azure Arc, deploy the SQL Server extension and then set the licence type (PAYG or Licence with SA). All of these settings can be checked and changed per instance in the Azure Portal. A typical onboarding command looks like this:

# PowerShell 7, Azure CLI installed, Contributor role on resource group
az connectedmachine sql enable --resource-group <RG> --machine-name <ServerName> --license-type PAYG

The command connects your SQL instance and configures it for PAYG licensing. If you need ESU, you enable it in the Azure portal under "SQL Server – Arc enabled".

Arc is how I bring order to sprawling SQL estates

In my view, SQL Server Azure Arc is now the only realistic way to get inventory, assessment and governance in place for large, scattered SQL landscapes. The inventory view, the built-in assessment and the Defender integration add a lot of value, above all in environments where hybrid and multicloud SQL is normal. Take the licence type setting seriously, because that is where ESU and Defender costs are decided. If you still have SQL Servers running "in the wild", Arc is the best way I know to get them organized and compliant, and it lays the groundwork for modern authentication. It also opens a clear path to Entra-based identity, MFA and better security for your most business-critical data.