A cluster protects the instance. An availability group protects the database.
"We have a SQL Server cluster. Do we still need Always On?" We hear that question often, and it shows the problem: the terms get mixed up. At Microsoft, Always On is the umbrella term for two different technologies. The failover cluster instance (FCI), in everyday speech "the cluster," protects the whole SQL Server instance. The availability group (AG) protects selected databases through separate copies of the data. Both run on a Windows Server Failover Cluster, yet they protect different things, with different consequences for storage, operations, application and edition.
This first part explains the two mechanisms, how a failover works and what the choice means in daily operations. The edition matrix, operating costs, licensing rules and a decision aid follow in the later parts.
In short
- "Always On" is not one product but two. Microsoft uses it as the umbrella term for failover cluster instances and availability groups.
- An FCI makes the instance highly available. One node is active, the others wait; all of them share one storage. Availability groups are not involved.
- An AG protects databases, not the instance. Each replica is its own instance with its own copy of the data; the primary sends its changes as log to the secondaries.
- Storage is both the strength and the limit of an FCI. One copy of the data, no protection against a storage failure, no readable copy.
- With an AG, logins and jobs don't travel along. Whatever belongs to the instance has to be maintained on every replica; the contained availability group (from SQL Server 2022, Enterprise) takes over part of that.
- Standard can do both, but on a small scale: an FCI with two nodes and the basic availability group with one database and two replicas. The full AG is Enterprise.
Two words, two mechanisms
A Windows Server Failover Cluster (WSFC) is the platform: several servers that monitor one another, use a quorum to decide who may still take part, and can move roles between them. SQL Server builds two different roles on top of it:
| Failover cluster instance (FCI) | Availability group (AG) | |
|---|---|---|
| What is protected | the whole SQL Server instance | a group of user databases |
| How many copies of the data | one, on shared storage | one per replica |
| Who runs at the same time | only the active node | all replicas, one of them as primary |
| Connection point | virtual network name of the instance | listener of the group |
| What moves in a failover | the instance with everything in it | the primary role for the group |
| Edition | Standard (2 nodes), Enterprise (up to 16 nodes) | basic AG in Standard, full AG in Enterprise |
In practice, the phrase "SQL Server cluster" means the FCI. Microsoft itself says "cluster" when it means the WSFC. For this article, cluster = FCI, and the most important point is the sentence that ends many misunderstandings: A plain FCI contains no availability groups. Availability groups are a separate technology.
The failover cluster instance: one instance, several nodes, one storage
An FCI is one SQL Server instance installed on several cluster nodes. The binaries are on each node, but the data and the transaction log exist exactly once: on shared storage that all nodes can reach. That can be a SAN, iSCSI or Fibre Channel, Storage Spaces Direct, an SMB file share or a Cluster Shared Volume. Only tempdb may be local, provided the path is valid on all nodes.
In the WSFC, the instance forms a resource group: network name, IP address, the shared disks, the database service and SQL Server Agent. This group always belongs to exactly one node, the owner. The services run only there. The other nodes are installed, but their instance is stopped. That is why you can't read or query anything on them.
Applications connect to the instance's virtual network name, not to a machine. During a failover, this name is registered on the new owner; the application reconnects and ends up at the same instance again. In environments with several subnets, each subnet has its own virtual IP; clients should then set MultiSubnetFailover=True, and Microsoft recommends this even with a single subnet.
What moves along, because it is the same instance: databases, Agent jobs, linked servers, server configuration. There is nothing to synchronize, because there is only one instance. That is the FCI's big operational advantage.
What the FCI doesn't do: It has only one copy of the data. If the shared storage fails or returns errors, the FCI has nothing to switch over to. Microsoft says so explicitly: the FCI relies on the storage solution for data protection. If you want a second copy of the data, you combine the FCI with an AG or with log shipping on physically separate storage, or you use the vendor's storage replication.
The quorum decides whether the cluster may work at all. If the WSFC loses its quorum, the FCI goes offline and an administrator has to step in. Microsoft recommends an odd number of votes and, since Windows Server 2012 R2, always a witness: a disk witness, a file share witness or a cloud witness in Azure.
The availability group: several instances, several copies of the data, one group
An AG is a container for a group of user databases that switch over together. Each replica is an independent SQL Server instance on its own cluster node, with its own copy of the databases on its own storage. Shared storage isn't required. The primary replica accepts writes and sends its transaction log records to the secondary replicas, which replay them. A full AG allows up to nine replicas.
Two modes of operation determine what a failover costs:
- Synchronous-commit: The primary confirms a transaction only once the secondary has hardened the log. No data loss in a failover, but higher commit latency; synchronous replicas therefore belong in the same data center or on a fast link.
- Asynchronous-commit: The primary doesn't wait. The secondary can fall behind, and a failover to it is possible only as a forced failover, with possible data loss. Suitable for long distances and disaster recovery.
Automatic failover exists only with synchronous-commit, a synchronized target, a healthy quorum and a satisfied failover policy. The health check works with default values of 30 seconds for the health check timeout and 20 seconds for the lease timeout; Microsoft advises against lowering them.
The listener is the virtual network name of the group. It always points to the current primary; with ApplicationIntent=ReadOnly, it can redirect readers to a readable secondary. After a failover, it disconnects existing connections, and new ones land on the new primary.
What doesn't move along: Everything that belongs to the instance and doesn't live in the database. Logins, Agent jobs, linked servers, credentials, server configuration and server-level permissions have to be maintained on every replica, logins with identical SIDs, jobs with a check of whether the instance is currently the primary. That is the operational price of the AG. Since SQL Server 2022 (Enterprise), the contained availability group addresses this: it keeps users, logins, permissions and jobs in its own system databases of the group. It has limits: no replication, no SSIS packages, no maintenance plans, and connections only through the listener of the contained AG.
On top of that come ongoing tasks that an FCI doesn't have: when you add a replica, the database has to get there, through backup and restore or through automatic seeding over the log stream. After that, log send and redo must be monitored. While a secondary is suspended, the primary's log is not truncated.
The failover compared
| FCI | AG (synchronous-commit, automatic) | |
|---|---|---|
| What switches | ownership of the resource group: name, IP, disks, services | the primary role within the group |
| What happens then | the instance starts on the new node and runs recovery for each database: committed transactions are rolled forward, open ones rolled back | the secondary takes over the role; it has already replayed the log, the databases are already there |
| Duration determined by | service start and recovery, so above all by the longest open transaction at the time of the failover | detection and role change; Microsoft says usually seconds |
| Data loss | none; there is only one copy of the data | none with synchronous-commit; with an asynchronous-commit replica only forced, with possible loss |
| Application | reconnects to the same name | reconnects to the listener, readers redirected where applicable |
| Who decides | the WSFC, through the instance's failover policy | the AG's flexible failover policy, or manual |
Microsoft compares an FCI failover to switching a server off and on: the instance is briefly gone and comes back with everything in it. How long recovery takes depends on the load and on the open transactions. Accelerated database recovery (ADR) (from SQL Server 2019, also in Standard) makes this phase largely independent of long transactions; that applies to the databases of an FCI just as much as to those of an AG. Microsoft gives no concrete number of seconds, and neither do we: we'll measure that in part 2 in the lab.
What the choice means in daily operations
Operations. With an FCI, you patch the passive node, switch over, then patch the other one; the instance stays one. With an AG, you patch each replica, but you have to keep logins, jobs and configuration identical on all of them. You trigger an AG failover with T-SQL or SSMS, not in Failover Cluster Manager.
Application. Both technologies drop connections during a failover. An application without reconnection logic stops in either case. With an AG, there is the added decision of whether readers may use a secondary through the listener.
Storage and network. The FCI needs shared storage and relies on it. The AG needs its own storage per replica and a network that can carry the log stream; with synchronous-commit, every transaction pays the latency of that network.
Readable copies and backups. Only a full AG (Enterprise) has readable secondaries and can run backups on secondaries; since SQL Server 2025 this includes full and differential backups, before that only log and copy-only backups. An FCI has no second copy on which anything could run.
Testability. A failover nobody has rehearsed is not protection. Both technologies can be switched over on a planned basis; schedule that as a recurring exercise, not as an emergency.
And for everything above: High availability is not a backup. A secondary is not a backup. A user error is replicated immediately. Only a tested backup concept, or log shipping with a delayed restore, catches that. How to compare your goals for data loss and recovery time (RPO and RTO) with what is achievable is shown in our article SQL Server Backup and Restore: Planning for the Real Incident.
Basic AG and editions in one paragraph
Standard Edition offers the FCI with two nodes and, since SQL Server 2016, the basic availability group: one database per group, two replicas, synchronous-commit or asynchronous-commit, automatic failover possible. Not possible are readable secondaries, backups and integrity checks on the secondary, distributed availability groups and later promotion to a full AG; for that, the group has to be created again. Several basic AGs per instance are allowed. The full AG with up to nine replicas, readable secondaries, contained AG and distributed availability group is Enterprise. SQL Server 2025 doesn't change that: Standard gets higher capacity limits (32 cores, 256 GB buffer pool) and Resource Governor, but no extension for availability groups. The complete matrix for 2017 to 2025, what it costs in operation and when Enterprise pays off are part 2 and part 3.
One sentence on licensing, because it helps shape the architecture: passive failover replicas are, from a licensing standpoint, provided for only with Software Assurance or a subscription, and "passive" means that the replica serves no data to users. A readable secondary is therefore not passive. Part 3 covers the rules in detail and their limits; checking your contract remains your responsibility.
Special case: an FCI as an AG replica
You can combine the two: an FCI can host a replica of an AG, for example to add database-level disaster recovery to an existing FCI. Two rules apply: a replica hosted by an FCI supports only manual AG failover, and an FCI provides only one replica per AG. The coupling is therefore unsuitable for automatic high availability, but workable for a second data center. The combination doesn't blend the two basic models; it stacks one on top of the other.
Frequently asked questions
Is "Always On" the same as an availability group? No. At Microsoft, Always On is the umbrella term for FCI and AG. If you say "Always On" and mean the AG, you should say so.
Do I need Enterprise Edition for an FCI? No. Standard allows an FCI with two nodes, Enterprise up to 16.
Does an FCI protect against a storage failure? No. It has only one copy of the data on the shared storage. For a second copy you need an AG, log shipping or storage replication.
Do logins and Agent jobs travel along in an AG? No. They belong to the instance and have to be maintained on every replica. The contained AG (from 2022, Enterprise) keeps them with the group.
Can I turn a basic AG into a full AG later? No. The group has to be removed and created again in an Enterprise environment.
How does log shipping differ from an AG? Log shipping automates log backup, copy and restore; the role change stays manual, and a delayed restore can catch user errors. An AG replicates continuously and can switch over automatically.
What comes next
After that:
- Part 3 · When does Enterprise pay off? Requirements that justify a full AG, and the licensing rules behind them.
- Part 4 · Decision aid: a few questions, reasoned candidates, no decision from three clicks.
If you're facing the decision
Whether an FCI, a basic AG or a full AG fits your application depends on your goals for data loss and recovery, on storage, locations, read requirements and on who operates the whole thing. In the availability review of our SQL Server Health Check, we compare your goals with what your environment achieves today. For planning, build and migration, there is our SQL Server High Availability: Design and Build service. We advise without any interest in selling licenses ourselves.
Sources
All statements in this part rest on Microsoft documentation, checked on Nov 8, 2026: Always On Failover Cluster Instances; What is an Always On Availability Group; Basic Availability Groups; Failover Cluster Instance with Availability Groups; Editions and Supported Features 2017, 2019, 2022 and 2025; What's New in SQL Server 2025; Contained Availability Groups; Availability Modes; Failover and Failover Modes; Listeners and Client Connectivity; Lease and Health Check Timeout; Accelerated Database Recovery; Business Continuity and Database Recovery; Microsoft SQL Server Licensing Guidance and Product Terms (Fail-over rights). Microsoft states the number of synchronous replicas per version differently on different pages; this part therefore gives none.