Create and manage VNet service endpoints for Azure Database for PostgreSQL - Single Server using Azure CLI

APPLIES TO: Azure Database for PostgreSQL - Single Server


Azure Database for PostgreSQL - Single Server is on the retirement path. We strongly recommend that you upgrade to Azure Database for PostgreSQL - Flexible Server. For more information about migrating to Azure Database for PostgreSQL - Flexible Server, see What's happening to Azure Database for PostgreSQL Single Server?.

Virtual Network (VNet) services endpoints and rules extend the private address space of a Virtual Network to your Azure Database for PostgreSQL server. Using convenient Azure CLI commands, you can create, update, delete, list, and show VNet service endpoints and rules to manage your server. For an overview of Azure Database for PostgreSQL VNet service endpoints, including limitations, see Azure Database for PostgreSQL Server VNet service endpoints. VNet service endpoints are available in all supported regions for Azure Database for PostgreSQL.

If you don't have an Azure subscription, create an Azure free account before you begin.



Support for VNet service endpoints is only for General Purpose and Memory Optimized servers. In case of VNet peering, if traffic is flowing through a common VNet Gateway with service endpoints and is supposed to flow to the peer, please create an ACL/VNet rule to allow Azure Virtual Machines in the Gateway VNet to access the Azure Database for PostgreSQL server.

Configure Vnet service endpoints

The az network vnet commands are used to configure virtual networks. Service endpoints can be configured on virtual networks independently, by a user with write access to the virtual network.

To secure Azure service resources to a VNet, the user must have permission to "Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/" for the subnets being added. This permission is included in the built-in service administrator roles, by default and can be modified by creating custom roles.

Learn more about built-in roles and assigning specific permissions to custom roles.

VNets and Azure service resources can be in the same or different subscriptions. If the VNet and Azure service resources are in different subscriptions, the resources should be under the same Active Directory (AD) tenant. Ensure that both the subscriptions have the Microsoft.Sql resource provider registered. For more information, see resource-manager-registration.


It is highly recommended to read this article about service endpoint configurations and considerations before running the sample script below, or configuring service endpoints. Virtual Network service endpoint: A Virtual Network service endpoint is a subnet whose property values include one or more formal Azure service type names. VNet services endpoints use the service type name Microsoft.Sql, which refers to the Azure service named SQL Database. This service tag also applies to the Azure SQL Database, Azure Database for PostgreSQL and MySQL services. It is important to note when applying the Microsoft.Sql service tag to a VNet service endpoint it configures service endpoint traffic for all Azure Database services, including Azure SQL Database, Azure Database for PostgreSQL and Azure Database for MySQL servers on the subnet.

Sample script

Launch Azure Cloud Shell

The Azure Cloud Shell is a free interactive shell that you can use to run the steps in this article. It has common Azure tools preinstalled and configured to use with your account.

To open the Cloud Shell, just select Try it from the upper right corner of a code block. You can also launch Cloud Shell in a separate browser tab by going to

When Cloud Shell opens, verify that Bash is selected for your environment. Subsequent sessions will use Azure CLI in a Bash environment, Select Copy to copy the blocks of code, paste it into the Cloud Shell, and press Enter to run it.

Sign in to Azure

Cloud Shell is automatically authenticated under the initial account signed-in with. Use the following script to sign in using a different subscription, replacing <Subscription ID> with your Azure Subscription ID. If you don't have an Azure subscription, create an Azure free account before you begin.

subscription="<subscriptionId>" # add subscription here

az account set -s $subscription # ...or use 'az login'

For more information, see set active subscription or log in interactively

Run the script

# Create a PostgreSQL server and configure a vNet rule

# Variable block
let "randomIdentifier=$RANDOM*$RANDOM"
location="East US"

echo "Using resource group $resourceGroup with login: $login, password: $password..."

# Create a resource group
echo "Creating $resourceGroup in $location..."
az group create --name $resourceGroup --location "$location" --tags $tag

# Create a PostgreSQL server in the resource group
# Name of a server maps to DNS name and is thus required to be globally unique in Azure.
echo "Creating $server in $location..."
az postgres server create --name $server --resource-group $resourceGroup --location "$location" --admin-user $login --admin-password $password --sku-name $sku

# Get available service endpoints for Azure region output is JSON
echo "List of available service endpoints for $location"
az network vnet list-endpoint-services --location "$location"

# Add Azure SQL service endpoint to a subnet while creating the virtual network
echo "Adding service endpoint to $subnet in $vNet"
az network vnet create --resource-group $resourceGroup --name $vNet --address-prefixes $vNetAddressPrefix --location "$location"

# Creates the service endpoint
echo "Creating a service endpoint to $subnet in $vNet"
az network vnet subnet create --resource-group $resourceGroup --name $subnet --vnet-name $vNet --address-prefix $subnetAddressPrefix --service-endpoints Microsoft.SQL

# View service endpoints configured on a subnet
echo "Viewing the service endpoint to $subnet in $vNet"
az network vnet subnet show --resource-group $resourceGroup --name $subnet --vnet-name $vNet

# Create a VNet rule on the server to secure it to the subnet
# Note: resource group (-g) parameter is where the database exists.
# VNet resource group if different should be specified using subnet id (URI) instead of subnet, VNet pair.
echo "Creating a VNet rule on $server to secure it to $subnet in $vNet"
az postgres server vnet-rule create --name $rule --resource-group $resourceGroup --server $server --vnet-name $vNet --subnet $subnet

Clean up deployment

Use the following command to remove the resource group and all resources associated with it using the az group delete command - unless you have an ongoing need for these resources. Some of these resources may take a while to create, as well as to delete.

echo "Cleaning up resources by removing the resource group..."
az group delete --name $resourceGroup -y