To create a WSFC properly in Azure, you cannot use the Wizard in Failover Cluster Manager for FCIs or AGs deployed using Windows Server 2016 and earlier. Due to the DHCP issue mentioned earlier, currently the only way to create the WSFC is to use PowerShell and specify the IP address.

For a configuration that has shared storage, use the following syntax:

1. PowerShell
2. New-Cluster -Name MyWSFC -Node Node1,Node2,…,NodeN -StaticAddress w.x.y.z

where MyWSFC is the name of the WSFC you want, Node1, Node2,…, NodeN are the names of the nodes that will participate in the WSFC, and w.x.y.z is the IP address of the WSFC (for example: 10.252.1.100.) If you are creating a WSFC that spans multiple subnets, you can specify more than one IP address for -StaticAddress separated by commas.

1. PowerShell
2. New-Cluster -Name MyWSFC -Node Node1,Node2,…,NodeN -StaticAddress w.x.y.z -NoStorage

For a Workgroup Cluster that will only use DNS, the syntax is also slightly different.

1. PowerShell
2. New-Cluster -Name MyWSFC -Node Node1,Node2,…,NodeN -StaticAddress w.x.y.z -NoStorage -AdministrativeAccessPoint DNS

Windows Server 2019 by default will use a distributed network name for IaaS. A distributed network name is one that creates just a network name, but the IP address is tied to the underlying nodes. You no longer need to specify an IP address as shown above if it is not needed or necessary. A distributed network name is for the WSFC’s name only; it cannot be used with the name of an AG or FCI.

The WSFC creation mechanism in Windows Server 2019 detects if it is running in Azure or not and will create the cluster using a distributed network name unless you tell it to do something else. Currently, distributed network names are incompatible with FCIs and while they do work with AGs, if you encounter an issue, you may want to consider deploying a WSFC traditionally using PowerShell. You need to add one more option: -ManagementPointNetwork with a value of Singleton. An example would look like this:

1. PowerShell
2. New-Cluster -Name MyWSFC -Node Node1,Node2,…,NodeN -StaticAddress w.x.y.z -NoStorage -ManagementPointNetwork Singleton

For a Workgroup Cluster, you will need to ensure the name and IP address(es) are in DNS for any name or IP address created in the context of the WSFC such as the WSFC itself, an FCI name and IP address, and an AG listener name and IP address.

With Windows Server 2019, Microsoft changed how WSFCs are created by default in Azure. Instead of creating a network name and an IP address, it uses a distributed network name. This is not yet supported with either of the Always On features, so it is still required to create the WSFC using the method described above.

https://docs.microsoft.com/en-us/windows-server/failover-clustering/create-failover-cluster

Purchasing model

The Azure SQL purchasing model provides two options:

• Based on virtual cores (vCore-based)

• Based on database transaction units (DTU- based)

The DTU model isn't available in Azure SQL Managed Instance.

Microsoft recommends the vCore-based model because it allows you to independently select compute and storage resources. The DTU-based model is a bundled measure of compute, storage, and I/O resources.

In the vCore model, you pay for:

• Compute resources. (The service tier + the number of vCores and the amount of memory + the generation of hardware.)

• The type and amount of data and log storage.

• Backup storage location. (Read-access geo-redundant storage (RA-GRS), Zone-redundant storage (ZRS), or locally-redundant storage (LRS)).

The vCore model also allows you to use Azure Hybrid Benefit for SQL Server and/or reserved capacity (pay in advance) to save money. Neither of these options is available in the DTU model.

https://docs.microsoft.com/en-us/azure/azure-sql/database/purchasing-models