Securing Postgres on Azure with a Private Endpoint

Here's a quick guide to setting up secure access to Azure Database for PostgreSQL flexible server, AKA Postgres on Azure, using a private endpoint, so the PostgreSQL server is only accessible from a specified subnet, which connects privately over the Microsoft backbone network. In this example a Linux VM will be created in the subnet to act as a database client.

Basic steps

1. Create an Azure Virtual Network (VNET) with a default subnet.
2. Create an Azure Database for PostgreSQL flexible server instance (with a private endpoint and private DNS integration).
3. Create a VM with a PostgreSQL client in the subnet.
4. Install psql on the VM.
5. Connect to the Postgres instance from the VM.

BTW if you want to do steps 1-3 purely in Azure CLI, see Setting up Postgres on Azure private endpoints using CLI.

1. Create a VNET
Create an Azure Resource Group and a VNET in the Azure portal or using Azure CLI.

E.g., with CLI:
az group create --name myPrivateRG --location westus3
az network vnet create --resource-group myPrivateRG --name myPrivateVNet --subnet-name myPrivateSubnet --subnet-prefixes 10.0.0.0/24

2. Create an Azure Database for PostgreSQL flexible server instance
The Microsoft docs also has a tutorial for this part. See: Create and manage virtual networks with Private Link for Azure Database for PostgreSQL - Flexible Server by using the Azure portal. In this article I'll go into a little more detail on the networking options.

In the Azure portal, create a new Azure Database for PostgreSQL flexible server instance, picking the default settings for Development workload type (Burstable compute SKU):

In the Networking panel select Public access as the connectivity method, but uncheck the "Public access" checkbox. This means only private endpoint connections will be allowed.

Then on the same panel click "Add private endpoint". In the "Create private endpoint" panel create a new private endpoint which points to the virtual network and subnet created earlier, and select "Enable Private DNS integration" to enable private host resolution from the client.

When you create the PostgreSQL server you'll get a warning saying that no firewall rule has been added so you won't be able to connect to it over the internet, which is good, because you only want to connect via private endpoint over the Azure backbone.

3. Create a VM with a PostgreSQL client in the subnet
Create a VM in the subnet referenced by the private endpoint, which will be the only client resource allowed to connect to the PostgreSQL server.

Here's an example of creating an Ubuntu VM in the Azure Portal, choosing the default settings, in the VNET created in step 1.

Use an SSH key to connect, and if you're generating a new key pair you'll have the option to save the PEM file (which contains your private key) locally when creating the VM.

In the Networking panel confirm the VNET and Subnet match the one created earlier for the private endpoint:

4. Install psql on the VM
Once the VM is running, SSH to the VM using the locally saved key. In this case I ran ssh from a Debian instance running in WSL (Windows Subsystem for Linux). I saved the PEM file in a .ssh directory and set the file permissions to 600 (chmod 600 .ssl/myPrivateVM_key.pem):

ssh -i .ssh/myPrivateVM_key.pem azureuser@nn.nn.nn.nnn

Use the Ubuntu package manager to install the Postgres client tool psql on the vM:

sudo apt-get update
sudo apt-get upgrade
sudo apt install postgresql-client

5. Connect to the Postgres instance from the VM

With the postgresql-client package installed you can use the psql tool to connect to the database server via the private endpoint. Note "myuser" is the name of the admin user you specified when you created the PostgreSQL server (this example assumes you specified a regular user/password, not an Entra ID).

psql -h my-private-pg-server.postgres.database.azure.com -U myuser -d postgres

Any resource you create in this subnet, for example a web app, will be able to connect to the PostgreSQL server via the private endpoint using Azure's private backbone network. No resources outside this subnet will be able to connect.