Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Applies to: 
SQL Server
This article describes how to deploy SQL Server on Azure Local in connected mode. SQL Server runs on Windows Server or Linux virtual machines (VMs) in an Azure Local cluster that maintains connectivity to Azure. This configuration combines local execution and data residency with Azure-based management, monitoring, billing, and hybrid services.
For environments without ongoing connectivity to Azure, see Deploy SQL Server on Azure Local with disconnected operations.
Prerequisites
Before you begin, confirm that you have:
- Supported hardware for Azure Local. Validate your environment with the Azure Local environment checker.
- An Azure subscription for management and hybrid services.
- Network connectivity between Azure Local and Azure that meets the Azure Local firewall requirements.
- Supported Windows Server or Linux images to create VMs on Azure Local and host SQL Server.
- Appropriate SQL Server licensing. Review SQL Server licensing and billing through Azure Arc.
- The permissions and connectivity required to connect SQL Server to Azure Arc when you reach the onboarding stage.
The following workflow covers deploying Azure Local and creating the SQL Server VMs.
Plan the SQL Server workload
Before sizing the VMs, capture the workload's requirements:
- Select the SQL Server version and edition based on database size, availability features, online operations, virtualization rights, and support lifecycle.
- Record peak CPU utilization, working-set memory, input/output operations per second (IOPS), throughput, latency, database growth,
tempdbdemand, log-generation rate, and concurrency. - Define recovery point objectives (RPOs) and recovery time objectives (RTOs).
- Identify application dependencies, authentication methods, Transport Layer Security (TLS) requirements, ports, service accounts, maintenance windows, backup retention, and offline software dependencies.
Design the SQL Server VMs
Use the following considerations when designing each VM:
| Design area | SQL Server guidance |
|---|---|
| Compute | Size virtual CPUs for sustained utilization and licensing efficiency. Avoid oversubscription that creates unpredictable query latency. |
| Memory | Reserve memory for the operating system, agents, drivers, and failover activity. Configure max server memory so SQL Server doesn't consume memory needed by other processes. |
| Storage | Use separate volumes for the operating system, data, transaction logs, tempdb, and backups. Validate latency, throughput, queue depth, capacity, resiliency, and free-space thresholds. |
| Network | Provide stable client, management, backup, and replica paths as required. Validate DNS, maximum transmission unit (MTU), firewall rules, TLS trust, and listener connectivity. |
| Placement | Place high-availability replicas on different Azure Local nodes or failure domains. Use anti-affinity where available. |
Deployment workflow
The following stages take you from infrastructure deployment to connected SQL Server management.
| Stage | Outcome |
|---|---|
| Acquire hardware and deploy Azure Local | A supported Azure Local environment. |
| Create VMs and install SQL Server | SQL Server running on Windows Server or Linux. |
| Monitor and tune SQL Server | A baseline for SQL Server performance and health. |
| Configure high availability | A workload-specific availability design, such as availability groups or failover cluster instances. |
| Connect SQL Server to Azure Arc | Centralized inventory, governance, security, and licensing. |
Deploy Azure Local
Deploy Azure Local by following the Azure Local deployment overview. Complete the applicable deployment prerequisites and deployment process before you create VMs for your SQL Server workloads.
Create VMs and install SQL Server
Create Windows Server or Linux VMs on Azure Local for your SQL Server workloads.
Install SQL Server by following the instructions for your operating system:
Review the SQL Server licensing and billing requirements and configure the appropriate licensing model.
Monitor and tune SQL Server
Monitor SQL Server with dynamic management views, Extended Events, error logs, and a monitoring solution supported by the guest operating system. On Windows, you can also use SQL Server Agent alerts and Windows performance counters. SQL Server Agent alerts aren't supported on Linux; review the SQL Server on Linux feature support for your version.
Establish a baseline for CPU utilization, memory pressure, storage latency, blocking, database growth, and backup health before tuning the workload. After connecting SQL Server to Azure Arc, you can also run a best practices assessment, subject to its prerequisites.
Configure high availability
Azure Local provides host-level resilience for VMs. Configure SQL Server high availability separately to meet your workload's database or instance availability requirements:
- Always On availability groups provide database-level protection. For Windows deployments, review Windows Server Failover Clustering with SQL Server.
- On Windows, Always On failover cluster instances provide instance-level protection and require a supported shared-storage design. Review the Storage Spaces Direct overview when planning storage.
- Use cluster affinity rules to place SQL Server replicas on different physical nodes. This placement helps maintain availability if a host fails.
- For connected Windows clusters, review Cloud Witness as a quorum option.
For Linux, an availability group without a cluster manager provides read-scale replicas, not high availability. High-availability deployments require a supported cluster manager, such as Pacemaker, and production deployments require fencing. See Configure availability groups on Linux. Validate the Linux distribution, cluster manager, fencing mechanism, and storage support for your Azure Local configuration; the Windows procedures don't apply unchanged to Linux.
Plan workload protection separately from infrastructure resilience. For Azure Backup and Azure Site Recovery options, review Azure Local workload resiliency and disaster recovery and the support requirements for your workload.
Connect SQL Server to Azure Arc
Connect SQL Server instances running on Azure Local to Azure Arc to create Azure resources for centralized management.
- Validate the Azure Arc prerequisites.
- Follow Connect SQL Server to Azure Arc to generate and run the onboarding script.
- Confirm that the SQL Server resources appear in the Azure portal.
After onboarding, you can use the following capabilities, subject to their version and configuration requirements:
| Capability | Guidance |
|---|---|
| Inventory and reporting | View instances, databases, versions, editions, and host operating systems. Use Azure Resource Graph to query across your SQL Server estate. See SQL Server enabled by Azure Arc. |
| Best practices assessment | Receive recommendations for performance and security. See Best practices assessment. |
| Identity | Use Microsoft Entra authentication, subject to its version and operating-system requirements. The managed identity setup for Microsoft Entra authentication requires Arc-enabled SQL Server 2025 on Windows Server and uses the Arc-enabled server's system-assigned identity. Microsoft Entra authentication isn't supported with failover cluster instances. |
| Security and governance | Configure Microsoft Defender for Cloud, or register and scan SQL Server with Microsoft Purview. |
| Operations | Manage configuration and run approved scripts across onboarded servers. See SQL Server enabled by Azure Arc and Manage configuration. |
Configure licensing through Azure Arc
Use SQL Server enabled by Azure Arc to declare and manage the licensing and billing model for your SQL Server instances:
- Pay-as-you-go: Subscribe through Azure and pay for the licensed cores reported by Azure Arc. This model can suit variable, temporary, or incremental workloads.
- License with Software Assurance or subscription: Declare an existing SQL Server license covered by active Software Assurance or a SQL Server subscription. Azure Arc records the license type and enables applicable management benefits.
- Core scope: Evaluate virtual-core licensing for individual VMs and eligible Enterprise physical-core licensing with unlimited virtualization. Validate eligibility before selecting a licensing model.
- Configuration: Set and review the license type through the Azure portal, Azure PowerShell, or Azure CLI. Apply changes at scale when required.
- Reporting: Keep the Azure Connected Machine agent and SQL Server extension healthy so inventory, usage reporting, and billing remain accurate.
On Linux, pay-as-you-go billing doesn't automatically detect passive availability-group replicas or failover cluster instances. All SQL Server instances are billed as active, regardless of their high-availability or disaster-recovery role. Account for this difference when planning Linux deployments. See Pay-as-you-go considerations.
For requirements and procedures, see Manage licensing and billing, Manage configuration, and Manage the transition to pay-as-you-go.
Build local AI applications
SQL Server 2025 can use sp_invoke_external_rest_endpoint to call a compatible HTTPS chat-completion endpoint. Applications can combine SQL data with locally hosted models while keeping inference within your environment.
Before calling a local model endpoint:
- Enable the
external rest endpoint enabledserver configuration option. The procedure is disabled by default in SQL Server 2025. - Grant the calling database principal
EXECUTE ANY EXTERNAL ENDPOINTpermission, and configure the authentication and credentials required by the endpoint. - Deploy the model and make its HTTPS endpoint reachable from the SQL Server VM. Configure TLS certificates and certificate trust for production use; a test that bypasses certificate validation doesn't establish that SQL Server can connect securely.
For details, see the REST endpoint permissions and prerequisites and Foundry Local inference guidance.
- SQL Server integration: Send authorized REST requests from SQL Server 2025 to a compatible chat-completion endpoint and process the response in your application workflow.
- Local model inference: Foundry Local on Azure Local is in preview. Use supported chat-capable catalog models or bring-your-own models, and complete the offering's deployment and access prerequisites.
- Developer tools: Review GitHub Copilot bring your own key for supported model endpoints and client requirements before connecting Visual Studio Code to a local endpoint.
For more information, see the Foundry Local documentation and the endpoint requirements in sp_invoke_external_rest_endpoint.
Use Trusted launch VMs
Trusted launch for Azure Local VMs supports Secure Boot and a virtual Trusted Platform Module (vTPM). If your SQL Server VMs use TPM-backed protection, review automatic state transfer to understand how vTPM state is handled when VMs migrate or fail over between nodes.
SQL Server doesn't require a vTPM. If you use a vTPM for guest operating system protection or encryption, validate those requirements separately from your SQL Server availability design.
For requirements and limitations, see Trusted launch for Azure Local VMs.