Distributed availability groups
A distributed availability group spans two separate availability groups. You can think of it as an availability group of availability groups. The underlying availability groups are configured on two different WSFC clusters. The availability groups that participate in a distributed availability group do not need to share the same location. They can be physical or virtual, on premises or in the public cloud. The availability groups in a distributed availability group don’t have to run the same version of SQL Server. The target DB instance can run a later version of SQL Server than the source DB instance.
A distributed availability group architecture gives you a flexible way to rehost a mission-critical SQL Server instance or database on AWS. It provides a hybrid solution for lifting and shifting (or lifting and transforming) your critical SQL Server databases on AWS.
Using a distributed availability group architecture is more efficient than extending existing on-premises WFSC clusters to AWS. Data is transferred only from the on-premises primary to one of the AWS replicas (the forwarder). The forwarder is responsible for sending data to other secondary read replicas in AWS.
In the following diagram, the first WSFC cluster (WSFC 1) is hosted on premises and has an
on-premises availability group (AG 1). The second WSFC cluster (WSFC 2) is hosted on AWS and
has an AWS availability group (AG 2). AWS Direct Connect
Note
At any given point of time, there is only one database that is available for write operations. You can use the remaining secondary replicas for read operations. To scale out your read workloads, you can add more read replicas in multiple Availability Zones on AWS.
For more information about distributed availability groups, see:
-
How to architect a hybrid Microsoft SQL Server solution using distributed availability groups
on the AWS Database blog -
Migrate SQL Server to AWS using distributed availability groups on the AWS Prescriptive Guidance website