Does a passive SQL Server failover cluster node require licensing?

For a normal two-node SQL Server FCI, you can usually license the primary workload and use the other node for failover. The same failover rights can cover a passive Always On Availability Group secondary. In both cases, the primary license needs current Software Assurance or a subscription that includes equivalent rights.

If you bought perpetual SQL Server licenses without Software Assurance, Microsoft's current commercial licensing guidance says the high-availability and disaster-recovery failover rights are not included. You should expect to license both environments unless the agreement attached to your purchase grants a different right.

An AG secondary stops being passive when it serves user queries, reports, ETL, or another production workload. An FCI node is easier to classify because the clustered SQL service runs on only one owner node at a time.

Microsoft grants failover rights for each properly licensed primary workload with active Software Assurance or equivalent subscription rights. The legal unit is a failover operating system environment, or OSE. It is broader than the name of one replica, but every SQL workload inside that OSE must stay within the passive-use conditions.

Current Product Terms provide one failover OSE for any purpose, including high availability. They also provide two failover OSEs specifically for disaster recovery: one on a server and one in Azure, subject to the Azure Hybrid Benefit ratio.

The disaster-recovery environments have tighter rules. They must use asynchronous replication and manual failover. They cannot serve SQL Server data to users or run active SQL workloads. The Product Terms allow the primary and DR failover OSEs to run together briefly for a DR test every 90 days.

The number of licenses that would be required for a failover OSE cannot exceed the licenses required for its primary workload. These rights also have outsourcing and License Mobility conditions, so shared hosting needs a separate check.

Always On is Microsoft's name for SQL Server high-availability features that include Failover Cluster Instances and Availability Groups. On Windows, both normally use Windows Server Failover Clustering, but they protect different things.

An FCI protects the whole SQL Server instance. The instance name, IP address, SQL services, and storage belong to one WSFC resource group. Only one node owns that group and runs its SQL services. During failover, WSFC moves the group and starts the same instance on another node.

An Availability Group protects a set of user databases. Every replica has its own SQL Server instance, local system databases, and copy of the availability databases. SQL Server sends log records from the primary to the secondary. During failover, another replica becomes primary. The underlying SQL Server instance does not move.

A normal high-availability AG on Windows requires Windows Server Failover Clustering. Every replica for that AG must run on a different node in the same WSFC, apart from a temporary cross-cluster migration case documented by Microsoft. The AG does not require an FCI or shared storage.

There are narrower exceptions to the WSFC rule. A read-scale AG with CLUSTER_TYPE = NONE has no cluster manager and does not provide high availability. SQL Server on Linux uses Pacemaker for clustered HA instead of WSFC. This article focuses on Windows HA deployments unless a section says otherwise.

An FCI can also host an AG replica in a more complex design, but that does not merge the FCI and AG licensing questions. The Always On setup guide covers the design and infrastructure differences in more detail.

Most licensing mistakes start by calling an entire server passive. Microsoft evaluates the SQL workloads and instances inside the operating system environment, not only the node label in a diagram.

One FCI, one active node, one idle node. Node A runs the clustered SQL instance. The same instance is installed as a cluster role that can move to node B, but its service is stopped there. If the SQL license on node A has Software Assurance or qualifying subscription rights, node B can use the included high-availability failover right.

One primary and one unused AG secondary. Node A hosts the primary replica. Node B hosts a synchronized secondary with no user connections, no standalone user databases, and no associated-service instances. The primary licenses can cover node B as a passive failover OSE when the Software Assurance or subscription conditions are met. An HA secondary may be synchronous and use automatic failover. A DR secondary covered by the separate DR right must be asynchronous and manual.

An AG secondary used for reporting. The secondary accepts read-intent connections so reports do not load the primary. That is useful work, which makes node B active. Both replicas need licensing.

Two AGs split across the nodes. AG1 is primary on node A and AG2 is primary on node B. Both nodes run primary workloads, so both require licensing. A secondary copy of the other AG does not make either node passive.

An FCI used as an AG replica. The FCI protects one replica at the instance level, while the AG protects databases between replica instances. Count the active primary workloads and examine every possible FCI owner. A passive FCI node can qualify only when it has no disqualifying SQL service or workload running.

One FCI plus a standalone reporting instance. The FCI waits on node B, but a separate SQL instance runs reports there. The reporting instance is active. The FCI failover right does not cover unrelated work on the server.

Microsoft's SQL Server enabled by Azure Arc documentation provides the clearest current technical test for passive AG replicas. Arc uses these rules to decide whether it can emit a zero-dollar passive meter. Your Product Terms still control the license right, but the Arc checks are useful when reviewing a real server.

Every replica in the OSE must be a secondary AG replica or an eligible distributed AG forwarder. The OSE cannot contain a standalone user database outside an AG, regardless of that database's state. Microsoft's passive criteria also require that no associated-service instances exist in the same OSE.

A readable secondary can remain eligible while nobody uses it. Microsoft checks for active and sleeping user sessions connected to user databases. Once a report, application, ETL process, or administrator connects to a user database for normal work, the replica no longer qualifies as passive.

Administrative access is narrower. Microsoft allows DMV queries and DATABASE BACKUP commands when the connection stays in master, msdb, tempdb, or model. Current Product Terms also permit CHECKDB, log backups, full backups, and resource monitoring on permitted failover OSEs.

Azure Arc's automatic detector does not recognize every permitted maintenance connection. Microsoft specifically warns that its detection logic does not support monitoring connections such as database consistency checks, backups, or resource monitoring. A permitted operation can therefore require manual review even when the license terms allow it.

Microsoft's current failover right applies to all SQL Server editions. A passive FCI node or qualifying AG secondary can therefore be covered for Standard or Enterprise when the primary license has Software Assurance or comes from a qualifying subscription.

Edition still matters for the original license calculation. Standard can be bought per core or through Server + CAL licensing. New Enterprise purchases use per-core licensing. Enterprise with active Software Assurance can also provide unlimited virtualization when the physical server is licensed correctly.

Standard edition uses Basic Availability Groups. A Basic AG has two replicas, contains one database, and does not support a readable secondary or backups on the secondary. Enterprise supports the fuller AG feature set, including multiple databases per AG, more replicas, readable secondaries, and backup offload where the design supports it.

Those feature limits affect what the secondary can do. They do not change the underlying rule that active work requires licensing and the no-cost passive entitlement depends on Software Assurance or subscription rights.

The failover benefit starts with a correctly licensed primary workload. If you license physical cores, calculate the required cores on the active server under the rules for your edition. If you license a virtual machine, license its virtual cores, with Microsoft's four-core minimum for each virtual operating system environment.

Standard edition can also use Server + CAL licensing. In that model, users or devices accessing SQL Server need CALs. The current Product Terms require active Software Assurance on both the server license and the CALs before you use the included failover rights.

The failover environment cannot require more licenses than the primary workload. A four-vCPU SQL VM cannot provide a free failover entitlement for a sixteen-vCPU FCI node or AG secondary. Keep the two sides equal or size the passive environment below the licensed primary.

Failing an FCI between nodes is also different from moving a VM freely between virtualization hosts. Shared hosting, third-party hardware, and frequent VM movement can bring License Mobility and Flexible Virtualization rules into the calculation. The SQL Server sizing guide helps with the technical inventory, but the license agreement decides how that inventory is counted.

SQL Server licensing answers age badly. A forum post about SQL Server 2012 or 2016 may describe rights that came from a different product release, agreement, or Software Assurance status. Applying that answer to a current SQL Server 2025 purchase can produce an expensive mistake.

Microsoft's current guidance is clear: licenses without Software Assurance or subscription benefits do not include the current high-availability and disaster-recovery failover rights. SQL Server 2019 licensing material also describes the passive failover benefit through active Software Assurance.

If your company owns older perpetual licenses, find the original purchase agreement and the Product Terms that applied to it. Downgrade rights let you run an older SQL Server version, but they do not mean an old blog post defines the license rights. Ask Microsoft or the reseller to confirm the answer against the licenses you actually own.

You do not need a large licensing workbook for a basic HA design. You do need an accurate picture of what runs in each OSE and what rights came with the SQL Server purchase.

Use the Always On setup guide to map the design. For the failover test itself, use the SQL Server failover guide to check cluster ownership, replica health, connections, jobs, backups, and monitoring after the role moves.

Microsoft's licensing guide is useful for understanding the model. The Product Terms and your company's agreement define the rights you can use.

• Microsoft Product Terms: SQL Server, including current failover rights and Software Assurance conditions.
• SQL Server 2025 licensing guidance, including the HA and DR overview.
• Manage licensing and billing for SQL Server enabled by Azure Arc, including passive FCI and AG detection rules.
• Windows Server Failover Clustering with SQL Server, including the FCI and AG architecture.
• Always On Failover Cluster Instances, including resource ownership and SQL service behavior.
• Availability Group prerequisites and restrictions, including WSFC and replica requirements.
• Always On Availability Groups overview, including the Windows HA cluster requirement and read-scale exception.
• Availability Groups on Linux, including Pacemaker and CLUSTER_TYPE = NONE.
• Microsoft SQL Server licensing documents for version-specific guides and datasheets.