High availability sounds like an architecture question, and it is. But for SQL Server it is also, and first, a licensing question. The HA options open to you, and what they cost, are shaped by your SQL Server edition and by whether you carry active Software Assurance. Pick the topology before you understand those two levers and you can design something elegant that you are not entitled to run, or that doubles your licence bill without anyone noticing until the true-up.
This piece walks the three mainstream HA patterns for SQL Server on AWS, RDS Multi-AZ, Always On Availability Groups on EC2, and Failover Cluster Instances, and the licensing rule that sits underneath all of them. SQL Server licensing terms are contract-specific and change over time, so treat everything here as general guidance to confirm against your own agreement and current Microsoft and AWS terms.
HA is a licensing question as much as an architecture one
Two factors govern what you can build. The first is edition. Enterprise edition unlocks the full Always On feature set; Standard edition gives you a deliberately reduced subset. The second is Software Assurance, the Microsoft maintenance programme that, among other things, carries the benefit that makes a standby replica affordable. Change either and the economics of HA move with it.
So the honest order of work is: confirm your edition, confirm your Software Assurance status, and only then choose a topology. The architecture follows the entitlement, not the other way around.
RDS Multi-AZ: the managed default
The simplest HA you can have is Amazon RDS for SQL Server with Multi-AZ enabled. RDS provisions a synchronous standby in a second Availability Zone and keeps it current; if the primary instance or its AZ fails, RDS fails over automatically and the database endpoint moves to the standby. You do not build, patch, or babysit the replication, AWS runs it.
The defining trait is that the standby is invisible to you. There is no readable secondary to query, no cluster to administer, and no operating-system access. That is the point: Multi-AZ trades control for operational simplicity. For a great many workloads that is exactly the right trade. When your requirement is “survive the loss of an Availability Zone with automatic failover, and don’t make me run it,” RDS Multi-AZ is the default answer.
Always On Availability Groups on EC2: you own the topology
When you need more than a managed standby, you run SQL Server yourself on Amazon EC2 and build Always On Availability Groups (AGs). Here you control everything: how many replicas, which Availability Zones, whether any secondaries are readable, and you can stretch an AG across regions for cross-region protection. That control is the reason to choose EC2 over RDS, and the reason it is more work.
Edition decides how far AGs can go:
- Enterprise edition supports the full feature: multiple secondary replicas, readable secondaries you can offload reporting and backups to, and therefore read-scale across replicas.
- Standard edition supports only Basic Availability Groups, a deliberately limited form: a single database per AG, exactly one secondary replica, and that secondary is not readable and not backup-able while it is a secondary.
The practical takeaway is sharp: if your goal is to spread read traffic across several secondaries, or to read from the standby at all, you are in Enterprise territory. Standard edition’s Basic AGs give you failover for one database and nothing more. Read-scale is an Enterprise capability, full stop, and that single fact often decides the edition before the workload does.
Failover Cluster Instances: shared-storage clustering on EC2
The third pattern is the Failover Cluster Instance (FCI). Where an AG replicates databases between independent instances, an FCI clusters at the instance level over shared storage: two or more nodes see the same storage, and on a node failure the whole instance fails over to a surviving node. The classic obstacle on AWS was that EC2 instances do not naturally share a disk.
Amazon FSx for Windows File Server solves this. It provides fully managed, highly available shared Windows storage over SMB that the cluster nodes mount as their shared volume, giving you a supported way to run a SQL Server FCI on EC2 without bolting together your own storage layer. FCI suits estates with an existing investment in instance-level clustering, or where you want failover of the entire instance and its system databases rather than per-database AG replication.
The passive-replica licensing rule
This is the rule that quietly drives HA cost, and the one most worth getting right.
Read what that does to the three patterns. A two-node HA design, primary plus one passive standby, costs roughly one set of licences if you hold Software Assurance, and roughly two sets if you do not. That is not a rounding difference; it is close to a doubling of your SQL Server licence spend on the HA tier. The moment a secondary becomes active, a readable secondary you query, a node you run reports against, the passive benefit no longer applies and it must be licensed regardless. This is exactly why edition (which gates readable secondaries) and Software Assurance (which gates the free passive replica) have to be settled together, and before the topology.
HA versus DR: same region versus another region
It is worth separating two ideas that get blurred. High availability is about surviving a localised failure, an instance or an Availability Zone, within a single region, with fast, ideally automatic, failover. RDS Multi-AZ, a same-region AG, and an FCI are all HA mechanisms.
Disaster recovery is about surviving the loss of an entire region, and it is a different design problem with different latency and cost. On AWS you address DR by reaching across regions: a cross-region Availability Group with an asynchronous secondary in a second region, or cross-region backups (including automated backup copy). A Multi-AZ deployment protects you from an AZ outage; it does not, on its own, protect you from a regional one. Decide your HA and your DR requirements as two separate lines in the brief, because one topology rarely satisfies both well.
Choosing: match the option to RPO, RTO, and read-scale
Work from your requirements to the option, not the reverse. How much data can you afford to lose (RPO)? How quickly must you be back (RTO)? Do you need to read from a secondary or spread read load? How much of the running do you want to own? Those answers point cleanly at one of the three.
| Option | What it gives you | Edition / licence note |
|---|---|---|
| RDS Multi-AZ | Synchronous standby in another AZ, automatic failover, fully managed; no replication for you to run; standby not readable | Standard or Enterprise; managed by RDS. Licence-included folds in the standby; bring-your-own-licence still licenses it |
| Always On AGs (EC2) | You own replicas across AZs and regions; readable secondaries and read-scale on Enterprise | Enterprise for multiple / readable secondaries; Standard = Basic AGs only (one database, one non-readable secondary) |
| FCI (EC2) | Instance-level failover over shared storage via Amazon FSx for Windows File Server; whole instance moves between nodes | Available on Standard and Enterprise; you run and patch the cluster |
| Cross-region AG / backups | DR, not HA: survives loss of a whole region via an async secondary or copied backups | Cross-region AG read/secondary entitlements follow edition and SA as above |
A useful default: if you want HA without operational burden and don’t need a readable secondary, start at RDS Multi-AZ. If you need read-scale, cross-region reach, or full control, move to Always On AGs on EC2 and budget for Enterprise. If your model is instance-level clustering, FCI on EC2 with FSx is the fit. Then, before you commit, re-check edition and Software Assurance, because they decide what that design actually costs.
This is one piece of a larger method
Licensing is one of three threads in the full guide, alongside portability (the open-source off-ramp) and performance on AWS. It maps every route and compares the same workload five ways.
Read: SQL Server on AWS, licensing, portability and performance
