In this demonstration, I'll set up SQL Server Always On functionality that utilizes Windows Failover Cluster to provide a Windows-based high availability database solution. While this technology predates Azure, the cloud implementation, in my opinion, is substantially easier to implement. My starting point is two Windows Server 2016 virtual machines running SQL Server 2017. They are deployed in an availability set and joined to an Azure Active Directory domain. You can also deploy the servers in an Availability Zone configuration, but you'll need to ensure the machines are running the IaaS SQL Agent extension in full management mode. 

To configure the IaaS SQL Agent, go into your subscription and then Resource Providers and check Microsoft.SqlVirtualMachines is registered. If not, register it. If the extension isn't installed, there'll be a message on the overview page of the SQL virtual machine asking if you want to install it. You can view the extension status through the SQL configuration link or go to the Repair page and check on the agent's provisioning state. To check the extension's mode, you can query the SQL VM's management type via PowerShell.

I've also created a storage account in the same resource group to be used as a cluster witness. I don't have a load balancer in place, as I'll create it when I create the always-on availability group.

First off, we need to create the Windows Server Failover Cluster. I'll do that through the SQL virtual machine sqlsvr1 under High Availability. Add a new windows server failover cluster, giving it a name of 14 characters or less. Select a witness storage account or create one. The SQL service account for the cluster credentials must be a domain account with admin permissions, or at least sufficient permissions. The user must belong to the local machines' administrator group. When you create the SQL Service Account user, make sure the password you give them is at least 12 characters long, or you won't pass the validation here. I'll use the same account for everything. Next, select the machines to be in the cluster, click apply, and yes to proceed.

With the failover cluster in play, we can add the always-on availability group. Give the group a name and configure the listener. Select the subnet with the VMs and enter a private IP address within the subnet. The address doesn't automatically update when you change the subnet. Here I'll create a new load balancer and click apply. Next, add the replicas. SqlSvr1 is already selected as the primary, and I'll add sqlsvr2 in a secondary role and check automatic failover, sync commit set both to readable secondaries, and click apply. Then click apply again to create the availability group.

In SQL Server management studio on sqlsvr1, I'll create a new database and back it up. This is required before adding a DB to an Availability group. Once backed up, I can add it to the availability group via the add database to availability group wizard. Logging on to sqlsvr2, we can see the database has replicated to the server and is synchronized. In the portal, after refreshing, the synchronization health is good. Stopping the SQL server instance on sqlsvr1 will cause a failover, and sqlsvr2, the secondary, becomes the primary.