Private Network Access for Azure Database for MySQL - Flexible Server (Preview)
APPLIES TO: Azure Database for MySQL - Flexible Server
This article describes the private connectivity option for Azure MySQL Flexible Server. You will learn in detail the Virtual network concepts for Azure Database for MySQL Flexible server to create a server securely in Azure.
Azure Database for MySQL - Flexible Server is in preview.
Private access (VNet Integration)
Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure. Virtual Network (VNet) integration with Azure Database for MySQL - Flexible Server brings the Azure's benefits of network security and isolation.
Virtual Network (VNet) integration for an Azure Database for MySQL - Flexible Server enables you to lock down access to the server to only your virtual network infrastructure. Your virtual network(VNet) can include all your application and database resources in a single virtual network or may stretch across different VNets in the same or different regions. Seamless connectivity between various Virtual networks can be established by peering, which uses Microsoft's low latency, high-bandwidth private backbone infrastructure backbone infrastructure. The virtual networks appear as one for connectivity purposes.
Azure Database for MySQL - Flexible Server supports client connectivity from:
- Virtual networks within the same Azure region. (locally peered VNets)
- Virtual networks across Azure regions. (Global peered VNets)
Subnets enable you to segment the virtual network into one or more sub-networks and allocate a portion of the virtual network's address space to which you can then deploy Azure resources. Azure Database for MySQL - Flexible Server requires a delegated subnet. A delegated subnet is an explicit identifier that a subnet can host a only Azure Database for MySQL - Flexible Servers. By delegating the subnet, the service gets explicit permissions to create service-specific resources in the subnet to seamlessly manage your Azure Database for MySQL - Flexible Server.
Azure Database for MySQL - Flexible Server integrates with Azure Private DNS zones to provide a reliable, secure DNS service to manage and resolve domain names in a virtual network without the need to add a custom DNS solution. Private DNS zone can be linked to one or more virtual networks by creating virtual network links
In the above diagram,
- Flexible servers are injected into a delegated subnet - 10.0.1.0/24 of VNET VNet-1.
- Applications that are deployed on different subnets within the same vnet can access the Flexible servers directly.
- Applications that are deployed on a different VNET VNet-2 do not have direct access to flexible servers. You have to perform private DNS zone VNET peering before they can access the flexible server.
Virtual network concepts
Here are some concepts to be familiar with when using virtual networks with MySQL flexible servers.
Virtual network -
An Azure Virtual Network (VNet) contains a private IP address space that is configured for your use. Visit the Azure Virtual Network overview to learn more about Azure virtual networking.
Your virtual network must be in the same Azure region as your flexible server.
Delegated subnet -
A virtual network contains subnets (sub-networks). Subnets enable you to segment your virtual network into smaller address spaces. Azure resources are deployed into specific subnets within a virtual network.
Your MySQL flexible server must be in a subnet that is delegated for MySQL flexible server use only. This delegation means that only Azure Database for MySQL Flexible Servers can use that subnet. No other Azure resource types can be in the delegated subnet. You delegate a subnet by assigning its delegation property as Microsoft.DBforMySQL/flexibleServers.
Network security groups (NSG)
Security rules in network security groups enable you to filter the type of network traffic that can flow in and out of virtual network subnets and network interfaces. Review the network security group overview for more information.
Private DNS zone integration -
Azure private DNS zone integration allows you to resolve the private DNS within the current VNET or any in-region peered VNET where the private DNS Zone is linked.
Virtual network peering
Virtual network peering enables you to seamlessly connect two or more Virtual Networks in Azure. The peered virtual networks appear as one for connectivity purposes. The traffic between virtual machines in peered virtual networks uses the Microsoft backbone infrastructure. The traffic between client application and flexible server in peered VNets is routed through Microsoft's private network only and is isolated to that network only.
Using Private DNS Zone
If you use the Azure portal or the Azure CLI to create flexible servers with VNET, a new private DNS zone is auto-provisioned per server in your subscription using the server name provided. Alternatively, if you want to setup your own private DNS zone to use with the flexible server, please see the private DNS overview documentation.
If you use Azure API, an Azure Resource Manager template (ARM template), or Terraform, please create private DNS zones that end with
mysql.database.azure.comand use them while configuring flexible servers with private access. For more information, see the private DNS zone overview.
Private DNS zone names must end with
Integration with custom DNS server
If you are using the custom DNS server then you must use a DNS forwarder to resolve the FQDN of Azure Database for MySQL - Flexible Server. The forwarder IP address should be 220.127.116.11. The custom DNS server should be inside the VNet or reachable via the VNET's DNS Server setting. Refer to name resolution that uses your own DNS server to learn more.
Private DNS zone and VNET peering
Private DNS zone settings and VNET peering are independent of each other. Please refer to the Using Private DNS Zone section above for more details on creating and using Private DNS zones.
If you want to connect to the flexible server from a client that is provisioned in another VNET from the same region or a different region, you have to link the private DNS zone with the VNET. See how to link the virtual network documentation.
Private DNS zone names that end with
mysql.database.azure.com can only be linked.
Connecting from on-premises to flexible server in Virtual Network using ExpressRoute or VPN
For workloads requiring access to flexible server in virtual network from on-premises network, you will require ExpressRoute or VPN and virtual network connected to on-premises. With this setup in place, you will require a DNS forwarder to resolve the flexible servername if you would like to connect from client application (like MySQL Workbench) running on on-premises virtual network. This DNS forwarder is responsible for resolving all the DNS queries via a server-level forwarder to the Azure-provided DNS service 18.104.22.168.
To configure properly, you need the following resources:
- On-premises network
- MySQL Flexible Server provisioned with private access (VNet integration)
- Virtual network connected to on-premises
- Use DNS forwarder 22.214.171.124 deployed in Azure
You can then use the flexible servername (FQDN) to connect from the client application in peered virtual network or on-premises network to flexible server.
Unsupported virtual network scenarios
- Public endpoint (or public IP or DNS) - A flexible server deployed to a virtual network cannot have a public endpoint
- After the flexible server is deployed to a virtual network and subnet, you cannot move it to another virtual network or subnet. You cannot move the virtual network into another resource group or subscription.
- Subnet size (address spaces) cannot be increased once resources exist in the subnet
- Flexible server doesn't support Private Link. Instead, it uses VNet injection to make flexible server available within a VNet.
If you are using the custom DNS server then you must use a DNS forwarder to resolve the FQDN of Azure Database for MySQL - Flexible Server. Refer to name resolution that uses your own DNS server to learn more.