Best practice network topology for SQL DB, MI, and SQL on Azure VM

Question

I'm a MSSQL DBA who is a noobie on Azure network design. My organization does have an Azure architect but the DBAs need to drive the SQL solution and topology, while the architect will implement the network pieces. Currently, the DBA's have only one vnet and one subnet at our disposal. We will need to deploy different types of SQL Server resources in Azure to meet different internal customer requirements: single SQL DB, Managed Instance, and stand-alone SQL VM. In addition, we will have a 3-node AlwaysOn AG cluster. I do see the various multi-tier solution reference architecture diagrams. I'm trying to understand not HOW but WHY to separate different SQL services into their own vnets and subnets. Bottom line is can all the deployment types be hosted together in one subnet in one given vnet, or do the different deployments each require there own boundaries for security and connectivity dependencies for example? Thanks.

Answer 1

Why you need to separate SQL Services into their own vnets and subnets? Let's take a look at why with Azure Managed Instances you may need to put them on a separate subnet. Each managed instance requires 32 IP addresses. Take a look at all the network requirements for Azure Managed Instance here. That requirement of the number of IP addresses for managed instance will influence the number of managed instances you can have on a subnet. Take a look here at the network connectivity architecture and other network requirements of managed instance to understand why to have them separate.

Azure SQL Database and Elastic Pools have also another set of issues related to VNETs like this one related to VPNs.

Best practice, create a separate subnet for Internet-facing servers, a separate subnet for middle tier, a "core” subnet for services such as domain controllers and SQL VMs. You may want to have servers that need to communicate between them on the same subnet to avoid the need to create Site to site or Express Route or VNET peering to communicate between them.

If you will have geographically distributed AlwaysOn Availability Groups then consider using different VNETs per region and connecting them using Azure VPN Gateways. Make sure you choose the correct one based on the bandwidth and number of connections.

Other reasons to create multiple VNETs:

• VMs that need to be placed in different Azure locations
• Workloads that need to be completely isolated from one another.
• Limits: You can have 2048 VMs on a VNET

Consider creating multiple subnets when:

• Not enough private IP addresses for all NICs in a subnet
• Foe security reasons, to apply different network security groups
• Hybrid connectivity. You can use VPN gateways and ExpressRoute circuits to connect your VNets to one another, and to your on-premises data center(s). VPN gateways and ExpressRoute circuits require a subnet of their own to be created.
• Virtual appliances. You can use a virtual appliance, such as a firewall, WAN accelerator, or VPN gateway in an Azure VNet. When you do so, you need to route traffic to those appliances and isolate them in their own subnet.

Answer 2

Good day David,

My organization does have an Azure architect but the DBAs need to drive the SQL solution and topology, while the architect will implement the network pieces.

This sound a bit problematic to me in first glance. A system should be designed by an architect who familiar with all the aspects of the system and the entities participate in the system or he probably cannot get the best decisions. This is the main point of taking an architect who see "the big picture". He is not necessarily the best expert in each part of the system but he should design the whole system including the parts that he should be familiar well but not his expertise (together with the experts).

This discussion should have being done with the architect!

I'm trying to understand not HOW but WHY to separate different SQL services into their own vnets and subnets.

Don't you need to asked if this is a good idea before you ask why this is a good idea. Maybe this does not fit your specific system?!?

There are multiple reasons to separate parts of a system into separate isolated environments. I have no idea which relevant to you but here are some reasons

~ logical isolation
~ separate Virtual Private Networks (VPNs) for clients
~ Enhance security: permissions and authentication depending on the network (probably main reasons for most uses)
~ Management: Managerial responsibility and responsibility for finances. In many cases you want different people or groups to be in charge on specific sub-system. Even if the same person have full permissions and authentication on all the system, it does not means that he should be managing the entire system directly. In big companies different departments manage expenses separately and each has their expenses account. It might help a lot to have separate environments.
~ and more...

Bottom line is can all the deployment types be hosted together in one subnet in one given vnet

Why... this is so wrong (at least in my opinion). The bottom line is not what can be done, but what best to your specific case and this is exactly why you need an architect. This is exactly the type of questions which Azure architect should answer for you, and unfortunately with the information that you can provide in the forum, we cannot answer it, since we are not fully familiar with your companies needs and system.

do the different deployments each require there own boundaries

require by whom? This depend on your system design. from Microsoft side this is not required in the vNet level but yes in the subnet level.

Note! Azure SQL Managed Instance must be deployed within an Azure virtual network and the subnet dedicated for managed instances only. In order to create the VM which connect it and use the same vNet you will need to create a new subnet in the SQL Managed Instance VNet.

Therefore, if you plan to have single SQL DB, Managed Instance, and stand-alone SQL VM using the same vNet, then it is probably the easier road to first start with creating the Managed instance and configure the vNet using the build in options while creating the managed instance (you can use an existing vNet but it is more complex and since in your case you start from scratch so this can solve you a lot of work and potential issues), next create a VM inside the same vNet and then you can create Azure SQL databases and configure their firewall.

Note! For most cases you will probably need to deploy multiple virtual networks in time