In one sentence, how does a Failover Cluster Instance (FCI) differ from an Always On availability group (AG) in terms of data placement?
An FCI is shared-storage clustering — one copy of database files on shared disks visible to whichever node runs the instance. An AG is shared-nothing replication — one copy per replica on independent storage, kept in sync by the AG fabric.
What fails over in an FCI vs an AG?
FCI: the SQL Server instance (service + instance) comes online on another node using the same shared storage. AG: the primary role (and databases in the group) moves to a secondary that already holds its own copy of the data via log shipping/redo.
What client endpoint do you typically use for an FCI vs an AG, and what does each resolve to?
FCI: virtual network name (VNN) / cluster network name — IP/DNS moves with the instance. AG: optional listener (DNS name) pointing at the current primary, with read-only routing to secondaries when configured.
Do Always On AGs on Windows use WSFC? What underlies AG on Linux?
On Windows, yes — every replica sits on a WSFC node; quorum still governs which partition stays online. On Linux, AG uses Pacemaker (and related stack), not WSFC.
Can you build a customer SQL Server FCI on Amazon RDS for SQL Server? Where does FCI on AWS run?
RDS does not expose your WSFC + shared cluster disks for a custom FCI. FCI on AWS means EC2 Windows nodes plus shared storage AWS supports for that pattern (e.g. FSx for Windows, EBS Multi-Attach where applicable), with proper quorum/witness design.
Is FCI limited to Enterprise Edition? State the rule of thumb.
No — Standard and Enterprise both support FCI on Windows when prerequisites are met. Edition still caps instance-level limits (memory, features, etc.); the cluster pattern is not Enterprise-only.
Contrast full / advanced Always On AG with Basic Availability Groups on Standard Edition — replicas, databases, and read scale.
Enterprise (and Developer non-prod): full AG — multiple DBs per group, more replicas, readable secondaries, read-only routing, distributed AG, etc. Standard (2016+): WITH BASIC — typically two replicas, one user database per AG, no Enterprise-style readable secondary (secondaries for failover, not reporting offload), no distributed AG; cannot convert Basic to advanced in place — drop and recreate to upgrade path.
Why does WSFC need quorum, and what failure mode does it prevent?
The cluster must agree which nodes may own resources. Without quorum math, a network partition could let two sides both think they should run SQL → split-brain (e.g. two writers to same storage in an FCI, or conflicting primaries in some designs). Quorum ensures only one partition can stay online.
When is node majority quorum appropriate vs node and file share majority?
Node majority: odd number of voting nodes, no witness — good when connectivity among nodes is solid. Node + file share majority (FSW): common for even node counts (often two nodes) — each node votes plus one vote on an SMB file share witness so ties are broken by whichever side can reach the witness.
What is cloud witness, and what do teams on AWS often use instead?
Cloud witness stores arbitration in Azure Blob (Microsoft’s cloud tie-breaker). On AWS / without Azure, orgs commonly use file share witness (FSW) on highly available SMB (e.g. third AZ, FSx for Windows, or a small dedicated file server) — confirm org standards.
For a file share witness, what does SMB mean here, and what is not stored on that share?
SMB is the Windows file-sharing protocol (UNC paths like \\server\share). The witness holds a small arbitration file — not your database files or backups. You’re using SMB as witness transport, unless you separately place SQL data on SMB (e.g. some FCI designs — different concern).
Where should the FSW host live, and why not on a cluster node or “same fault domain” as both SQL nodes?
Host the share on a separate, stable Windows file role — often a small VM in a third AZ/rack — so the witness survives failure of one or both SQL nodes. Putting the FSW on a cluster member or laptop-class host defeats independence and quorum safety.
What do dynamic quorum and dynamic witness accomplish at a high level?
Dynamic quorum: Windows can adjust which nodes carry votes as nodes fail, reducing the chance the last node loses quorum (details version-specific). Dynamic witness: the cluster toggles the witness vote so total votes stay odd when possible, limiting unnecessary witness dependency.
Can a single FCI span two AWS Regions? What do people do for cross-Region SQL instead?
Effectively no — FCI needs shared storage and tight cluster networking; cross-Region latency makes one WSFC+FCI across Regions impractical as a standard pattern. Cross-Region DR is usually AG (async), log shipping, backup/restore, replication where allowed, or a separate footprint — not one FCI straddling Regions.
How do async vs sync secondaries and Distributed Availability Groups (DAG) fit multi-Region designs?
Async replica(s) in another Region are common for DR (higher RPO, tolerates latency). Sync across Regions is usually avoided — round-trip latency hurts throughput unless you have unusually low latency. DAG links two separate WSFC clusters (e.g. per Region) for geo DR — “two clusters, AG between them,” not one stretched cluster.
For RDS for SQL Server, what does Multi-AZ imply about Regions?
Multi-AZ is within one Region (primary + standby in different AZs). Cross-Region “Multi-AZ” for that pair is not the model — treat Region-level DR as read replicas, backup copies, or a second deployment per current AWS docs.
