如何使用Azure ARM Template将现有虚拟网络接入Azure SQL Database？

Got it, let's walk through how to adjust your ARM template to get your Azure SQL Database connected to your existing virtual network. The core piece here is adding a Virtual Network Rule to your SQL Server, and making sure your target subnet is set up correctly for SQL service endpoints.

Here's how to modify your existing azuredeploy.json:

1. Add Parameters for Your Existing VNet/Subnet #

First, add parameters to reference your existing virtual network and subnet (including the resource group if it's not the same as your SQL deployment group):

"parameters": {
    // Keep your existing parameters (sqlServerName, databaseName, collation, etc.)
    "virtualNetworkName": {
        "type": "string",
        "metadata": {
            "description": "Name of your existing virtual network"
        }
    },
    "virtualNetworkResourceGroup": {
        "type": "string",
        "defaultValue": "[resourceGroup().name]",
        "metadata": {
            "description": "Resource group where your VNet lives (defaults to current deployment group)"
        }
    },
    "subnetName": {
        "type": "string",
        "metadata": {
            "description": "Name of the subnet in your VNet that should access SQL"
        }
    }
}

2. Add the Virtual Network Rule Resource #

Next, add a Microsoft.Sql/servers/virtualNetworkRules resource under your SQL Server's resources. This rule links your SQL Server to your existing subnet:

"resources": [
    // Your existing SQL Server and Database resources go here
    {
        "type": "Microsoft.Sql/servers",
        "apiVersion": "2021-11-01",
        "name": "[parameters('sqlServerName')]",
        "location": "[resourceGroup().location]",
        "properties": {
            // Your existing SQL Server properties (admin login, etc.)
            "publicNetworkAccess": "Enabled" // Leave this enabled if you still need occasional public access, or set to "Disabled" to restrict to VNet only
        },
        "resources": [
            // Your existing Database resource here
            {
                "type": "databases",
                "apiVersion": "2021-11-01",
                "name": "[parameters('databaseName')]",
                "location": "[resourceGroup().location]",
                "dependsOn": ["[resourceId('Microsoft.Sql/servers', parameters('sqlServerName'))]"],
                "properties": {
                    "collation": "[parameters('collation')]"
                    // Add your DB SKU/properties here
                }
            },
            // Add this Virtual Network Rule
            {
                "type": "virtualNetworkRules",
                "apiVersion": "2021-11-01",
                "name": "AllowExistingVNetSubnet",
                "dependsOn": ["[resourceId('Microsoft.Sql/servers', parameters('sqlServerName'))]"],
                "properties": {
                    "virtualNetworkSubnetId": "[resourceId(parameters('virtualNetworkResourceGroup'), 'Microsoft.Network/virtualNetworks/subnets', parameters('virtualNetworkName'), parameters('subnetName'))]",
                    "ignoreMissingVnetServiceEndpoint": false
                }
            }
        ]
    }
]

Quick Notes on Key Settings: #

• virtualNetworkSubnetId: Uses the resourceId() function to pull the full ID of your existing subnet. If your VNet is in a different resource group, make sure to specify that in the parameter.
• ignoreMissingVnetServiceEndpoint: Set to false (recommended) to enforce that your subnet has the Microsoft.Sql service endpoint enabled. If your subnet doesn't have this yet, you can temporarily set this to true but you must enable the service endpoint afterward—otherwise the rule won't work.

3. (Optional) Enable SQL Service Endpoint on Your Subnet (If Not Already Done) #

If your existing subnet doesn't have the Microsoft.Sql service endpoint enabled, you can add this resource to your template to enable it (just make sure you have permissions to modify the VNet):

{
    "type": "Microsoft.Network/virtualNetworks/subnets",
    "apiVersion": "2023-04-01",
    "name": "[concat(parameters('virtualNetworkName'), '/', parameters('subnetName'))]",
    "resourceGroup": "[parameters('virtualNetworkResourceGroup')]",
    "properties": {
        "addressPrefix": "[reference(resourceId(parameters('virtualNetworkResourceGroup'), 'Microsoft.Network/virtualNetworks/subnets', parameters('virtualNetworkName'), parameters('subnetName')), '2023-04-01').addressPrefix]",
        "serviceEndpoints": [
            {
                "service": "Microsoft.Sql"
            }
        ]
    }
}

Important: This updates your existing subnet—we use reference() to keep the original address prefix so we don't overwrite any existing subnet config.

Deployment Tips #

• Permissions: Make sure your deployment account has permissions to manage SQL Server and (if modifying the subnet) virtual networks.
• Test the Rule: After deployment, verify that resources in your subnet can connect to the SQL Database, and that public access is restricted if you set publicNetworkAccess to Disabled.
• API Versions: I used recent API versions (2021-11-01 for SQL, 2023-04-01 for networking) but you can adjust to match your existing template's versions if needed.

内容的提问来源于stack exchange，提问作者Pradeep