The pitch is clean: run SQL Server on the factory floor, in the retail back room, on the ship, and manage it from the same Azure Resource Manager blade as the VMs in your production subscription. Patch it, back it up, scan it for threats — all from the control plane you already know. What nobody puts on the architecture slide is the corollary. You just extended that control plane into a building with a loading dock and a switch nobody has patched since 2021.
On 28 September 2026, Microsoft moved SQL Server on Azure Local to general availability. The feature is real, the integration is deeper than the previous previews, and the security model is worth reading before you turn it on everywhere. Here is what the numbers actually mean.
28 September 2026: GA, not preview
GA matters for one reason that preview never gives you — a support contract and a stated servicing commitment. Up to this point, Arc-managed SQL on Azure Stack HCI (the product’s old name) was a thing you could demo but not defend in a change advisory board. Now you can. The announcement covers deployment, patching, backup, and Defender integration as supported paths rather than best-effort.
The architecture to keep straight: SQL Server runs inside VMs on your Azure Local cluster, and the Azure extension for SQL Server — layered on top of the Azure Connected Machine agent — is what projects each instance into ARM as an Arc resource. This is not a PaaS service running magically on your hardware. It is your SQL Server, your Windows Server, your patch responsibility, with an Azure management skin stretched over it.
Two versions in scope: 2022 and 2025
GA targets SQL Server 2022 and SQL Server 2025 on supported Azure Local builds. If you are still running SQL Server 2019 or older on your HCI clusters, the Arc management story does not fully apply — you can Arc-enable the host, but the SQL-specific capabilities (least-privilege Defender for SQL, automated patching, PAYG metering) are built against the newer engines. Pin the exact minimum Azure Local release from the GA release notes before you plan a rollout; Microsoft ties this to a recent build, and I am not going to invent a number that your deployment will contradict in six months.
The practical read: this is a reason to finish your SQL 2019 migrations, not a reason to defer them.
Port 443, outbound — and that’s the whole attack surface conversation
The Connected Machine agent needs outbound HTTPS to Azure. That is the headline requirement and the one that gets hand-waved. In theory, 443 outbound to a well-scoped set of Azure endpoints is modest. In practice, every Arc-enabled edge box becomes a node that initiates connections to Microsoft’s control plane and executes instructions that come back down that pipe — extension installs, run-command payloads, patch jobs.
That is not a criticism of Arc; it is the deal. But treat the agent as a privileged software supply-chain component, not a monitoring agent. Lock the outbound endpoints with Private Link or an Arc gateway where you can, restrict who holds Microsoft.HybridCompute and Microsoft.AzureArcData write permissions, and alert on extension installation. A run-command extension pushed to an edge SQL host is a remote code execution primitive with a legitimate business justification. Both halves of that sentence are true.
One managed identity per server, and that’s your blast radius
Every Arc-enabled machine gets a system-assigned managed identity in your Entra tenant. For SQL on Azure Local, that identity is how the box authenticates to Azure for metering, backup, and Defender telemetry. It is also the thing an attacker who lands on the host wants most.
If someone pops the SQL VM and can reach the agent’s identity endpoint, they inherit whatever that identity has been granted in Azure. The default grants are narrow — don’t widen them. Resist the temptation to hand the Arc identity a broad role “to make backup work.” Scope role assignments to the specific resource group and resource type, and audit them the same way you’d audit a service principal with a client secret, because functionally that is what you have on every edge node.
Find every Arc SQL instance and its license posture in one query before you assume you know what’s out there:
Run that across every subscription in scope. The row count is almost always higher than the inventory spreadsheet claims.
Three ways to pay — and one of them meters when you least expect it
Licensing comes in three flavors: Azure Hybrid Benefit (bring your existing SQL core licenses with Software Assurance), pay-as-you-go through Arc metering (billed to your Azure subscription by the hour), and traditional SQL Server subscription licensing. The one to watch is PAYG. Once an instance is metered through Arc, it bills until you change its licenseType — stopping the SQL service does not stop the clock the way shutting down an Azure VM deallocates it. For the exact rates, go to the Azure pricing calculator; I’m not quoting per-core numbers that drift quarterly.
The licenseType field in the query above is where this bites. Audit it. A lab instance someone spun up PAYG and forgot is a line item, not a crisis — but it compounds across fifty edge sites.
Zero PaaS guarantees: this is not SQL Managed Instance
Here is the distinction the marketing softens. Azure SQL Managed Instance is PaaS — Microsoft owns the OS, the patching cadence, the high-availability plumbing, and the failover SLA. SQL Server on Azure Local owns none of that for you. You get the Azure management surface — ARM, Azure Policy, Defender for Cloud, Azure Backup integration, automated patching orchestration — wrapped around a database engine you are still fundamentally responsible for.
Which means the availability features you reach for are the on-premises ones. Always On Availability Groups, failover clustering, and log shipping work because this is real SQL Server on real Windows Server. Geographic DR is yours to build — stretch an AG across clusters, ship logs to a second site, back up to Azure Blob. There is no “enable zone redundancy” checkbox. Arc gives you a consistent place to see and govern these workloads; it does not make them highly available on your behalf.
Compared to SQL on a standalone Windows Server you Arc-enabled by hand, the Azure Local path buys you cluster-integrated deployment and a tighter extension lifecycle. The security obligations are identical. The engine is the same engine, with the same CVEs and the same need for you to actually apply the patches Arc now makes it easy to schedule.
Turn on Defender for SQL before, not after
The single highest-value control here is Defender for SQL, which now covers these Arc instances with the same vulnerability assessment and behavioral detections it runs on Azure VMs. Enable it as part of onboarding, not as a Q3 project. Enforce it with policy so a new edge site can’t go live without it:
Drop the --what-if only after you’ve read the preview and confirmed it won’t flag every existing instance into non-compliance on a Friday afternoon.
The capability is genuinely good. One control plane for SQL that lives in places Azure never reached is worth having. Just remember what you actually deployed: not a managed service, but a privileged agent and a managed identity on every edge box, reporting home over 443. Govern it like the standing access it is.