Determine required subnet size and range for Azure SQL Managed Instance

APPLIES TO: Azure SQL Managed Instance

Azure SQL Managed Instance must be deployed within an Azure virtual network. The number of managed instances that can be deployed in the subnet of a virtual network depends on the size of the subnet (subnet range).

When you create a managed instance, Azure allocates a number of virtual machines that depend on the tier you selected during provisioning. Because these virtual machines are associated with your subnet, they require IP addresses. To ensure high availability during regular operations and service maintenance, Azure might allocate more virtual machines. The number of required IP addresses in a subnet then becomes larger than the number of managed instances in that subnet.

By design, a managed instance needs a minimum of 32 IP addresses in a subnet. As a result, you can use a minimum subnet mask of /27 when defining your subnet IP ranges. We recommend careful planning of subnet size for your managed instance deployments. Consider the following inputs during planning:

  • Number of managed instances, including the following instance parameters:
  • Plans to scale up/down or change the service tier, hardware configuration, or maintenance window

Important

A subnet size of 16 IP addresses (subnet mask /28) allows the deployment of a single managed instance inside it. It should be used only for evaluation or for dev/test scenarios where scaling operations won't be performed.

Determine subnet size

Size your subnet according to your future needs for instance deployment and scaling. The following parameters can help you in forming a calculation:

  • Azure uses five IP addresses in the subnet for its own needs.
  • Each virtual cluster allocates an additional number of addresses.
  • Each managed instance uses a number of addresses that depend on pricing tier and hardware configuration.
  • Each scaling request temporarily allocates an additional number of addresses.

Important

It's not possible to change the subnet address range if any resource exists in the subnet. Consider using bigger subnets rather than smaller ones to prevent issues in the future.

GP = general purpose; BC = business critical; VC = virtual cluster

Pricing tier Azure usage VC usage Instance usage Total
GP 5 6 3 14
BC 5 6 5 16

In the preceding table:

  • The Total column displays the total number of addresses that are used by a single-deployed instance to the subnet.
  • When you add more instances to the subnet, the number of addresses used by the instance increases. The total number of addresses then also increases.
  • Addresses represented in the Azure usage column are shared across multiple virtual clusters.
  • Addresses represented in the VC usage column are shared across instances placed in that virtual cluster.

Also consider the maintenance window feature when you're determining the subnet size, especially when multiple instances will be deployed inside the same subnet. Specifying a maintenance window for a managed instance during its creation or afterward means that it must be placed in a virtual cluster with the corresponding maintenance window. If there is no such virtual cluster in the subnet, a new one must be created first to accommodate the instance.

The same scenario as for the maintenance window applies for changing the hardware configuration as a virtual cluster always uses the same hardware. In case of new instance creation or changing the hardware of the existing instance, if there is no such virtual cluster in the subnet, a new one must be created first to accommodate the instance.

An update operation typically requires resizing the virtual cluster. When a new create or update request comes, the SQL Managed Instance service communicates with the compute platform with a request for new nodes that need to be added. Based on the compute response, the deployment system either expands the existing virtual cluster or creates a new one. Even if in most cases the operation will be completed within same virtual cluster, a new one might be created on the compute side.

Update scenarios

During a scaling operation, instances temporarily require additional IP capacity that depends on pricing tier:

Pricing tier Scenario Additional addresses
GP Scaling vCores 3
GP Scaling storage 0
GP Switching to BC 5
BC Scaling vCores 5
BC Scaling storage 5
BC Switching to GP 3

Calculate the number of IP addresses

We recommend the following formula for calculating the total number of IP addresses. This formula takes into account the potential creation of a new virtual cluster during a later create request or instance update. It also takes into account the maintenance window and hardware requirements of virtual clusters.

Formula: 5 + (a * 12) + (b * 16) + (c * 16)

  • a = number of GP instances
  • b = number of BC instances
  • c = number of different maintenance window configurations and hardware configurations

Explanation:

  • 5 = number of IP addresses reserved by Azure
  • 12 addresses per GP instance = 6 for virtual cluster, 3 for managed instance, 3 more for scaling operation
  • 16 addresses per BC instance = 6 for virtual cluster, 5 for managed instance, 5 more for scaling operation
  • 16 addresses as a backup = scenario where new virtual cluster is created

Example:

  • You plan to have three general-purpose and two business-critical managed instances deployed in the same subnet. All instances will have same maintenance window configured. That means you need 5 + (3 * 12) + (2 * 16) + (1 * 16) = 89 IP addresses.

    Because IP ranges are defined in powers of 2, your subnet requires a minimum IP range of 128 (2^7) for this deployment. You need to reserve the subnet with a subnet mask of /25.

Note

Though it's possible to deploy managed instances to a subnet with a number of IP addresses that's less than the output of the subnet formula, always consider using bigger subnets instead. Using a bigger subnet can help avoid future issues stemming from a lack of IP addresses, such as the inability to create additional instances within the subnet or scale existing instances.

Next steps