Network with private access (virtual network integration) for Azure Database for PostgreSQL - Flexible Server

APPLIES TO: Azure Database for PostgreSQL - Flexible Server

This article describes connectivity and networking concepts for Azure Database for PostgreSQL - Flexible Server.

When you create an Azure Database for PostgreSQL flexible server, you must choose one of the following networking options:

• Private access (virtual network integration)
• Public access (allowed IP addresses) and private endpoint

This document describes the private access (virtual network integration) networking option.

Private access (virtual network integration)

You can deploy an Azure Database for PostgreSQL flexible server into your Azure virtual network by using virtual network injection. Azure virtual networks provide private and secure network communication. Resources in a virtual network can communicate through private IP addresses that were assigned on this network.

Choose this networking option if you want the following capabilities:

• Connect from Azure resources in the same virtual network to your Azure Database for PostgreSQL flexible server by using private IP addresses.
• Use a VPN or Azure ExpressRoute to connect from non-Azure resources to your Azure Database for PostgreSQL flexible server.
• Ensure that the Azure Database for PostgreSQL flexible server has no public endpoint that's accessible through the internet.

In the preceding diagram:

• Azure Database for PostgreSQL flexible servers are injected into subnet 10.0.1.0/24 of the VNet-1 virtual network.
• Applications that are deployed on different subnets within the same virtual network can access Azure Database for PostgreSQL flexible servers directly.
• Applications that are deployed on a different virtual network (VNet-2) don't have direct access to Azure Database for PostgreSQL flexible servers. You have to perform virtual network peering for a Private DNS zone before they can access the flexible server.

Virtual network concepts

An Azure virtual network contains a private IP address space that's configured for your use. Your virtual network must be in the same Azure region as your Azure Database for PostgreSQL flexible server. To learn more about virtual networks, see the Azure Virtual Network overview.

Here are some concepts to be familiar with when you're using virtual networks where resources are integrated into a virtual network with Azure Database for PostgreSQL flexible servers:

• Delegated subnet: A virtual network contains subnets (subnetworks). Subnets enable you to segment your virtual network into smaller address spaces. Azure resources are deployed into specific subnets within a virtual network.

  Your Azure Database for PostgreSQL flexible server that's integrated in a virtual network must be in a subnet that's delegated. That is, only Azure Database for PostgreSQL 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.DBforPostgreSQL/flexibleServers.

  The smallest CIDR range you can specify for the subnet is /28, which provides 16 IP addresses. The first and last address in any network or subnet can't be assigned to any individual host. Azure reserves five IPs to be used internally by Azure networking, which includes two IPs that can't be assigned to the host, as mentioned. This leaves you 11 available IP addresses for a /28 CIDR range. A single Azure Database for PostgreSQL flexible server with high-availability features uses four addresses.

  For replication and Microsoft Entra connections, make sure route tables don't affect traffic. A common pattern is to route all outbound traffic via an Azure Firewall or a custom on-premises network filtering appliance.

  If the subnet has a route table associated with the rule to route all traffic to a virtual appliance:

  • Add a rule with the destination service tag AzureActiveDirectory and the next hop Internet.
  • Add a rule with the destination IP range the same as the Azure Database for PostgreSQL - Flexible Server subnet range and the next hop Virtual Network.

  Important

  The names AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet, and GatewaySubnet are reserved within Azure. Don't use any of these names as your subnet name. Additionally, virtual networks should not have overlapping address space for creating cross-region replicas.

• Network security group (NSG): Security rules in NSGs enable you to filter the type of network traffic that can flow in and out of virtual network subnets and network interfaces. For more information, see the NSG overview.

  Application security groups (ASGs) make it easy to control Layer-4 security by using NSGs for flat networks. You can quickly:

  • Join virtual machines to an ASG or remove virtual machines from an ASG.
  • Dynamically apply rules to those virtual machines or remove rules from those virtual machines.

  For more information, see the ASG overview.

  At this time, we don't support NSGs where an ASG is part of the rule with Azure Database for PostgreSQL - Flexible Server. We currently advise using IP-based source or destination filtering in an NSG.

  High availability and other features of Azure Database for PostgreSQL - Flexible Server require the ability to send/receive traffic to destination port 5432 within the Azure virtual network subnet where Azure Database for PostgreSQL - Flexible Server is deployed and to Azure Storage for log archival. If you create NSGs to deny traffic flow to or from your Azure Database for PostgreSQL flexible server within the subnet where it's deployed, make sure to allow traffic to destination port 5432 within the subnet, and also to Storage, by using the service tag Storage as a destination.

  You can further filter this exception rule by adding your Azure region to the label like china-east.storage. Also, if you elect to use Microsoft Entra authentication to authenticate sign-ins to your Azure Database for PostgreSQL flexible server, allow outbound traffic to Microsoft Entra ID by using a Microsoft Entra service tag.

  When you set up Read Replicas across Azure regions, Azure Database for PostgreSQL - Flexible Server requires the ability to send or receive traffic to destination port 5432 for both primary and replica and to Azure Storage in primary and replica regions from both primary and replica servers. The required destination TCP port for Storage is 443.

• Private DNS zone integration: Azure Private DNS zone integration allows you to resolve the private DNS within the current virtual network or any in-region peered virtual network where the Private DNS zone is linked.

Use a Private DNS zone

Azure Private DNS provides a reliable and secure DNS service for your virtual network. Azure Private DNS manages and resolves domain names in the virtual network without the need to configure a custom DNS solution.

When you use private network access with an Azure virtual network, providing the Private DNS zone information is mandatory to be able to do DNS resolution. For new Azure Database for PostgreSQL flexible server creation by using private network access, Private DNS zones need to be used while you configure Azure Database for PostgreSQL flexible servers with private access.

For new Azure Database for PostgreSQL flexible server creation by using private network access with an API, Azure Resource Manager template (ARM template), or Terraform, create Private DNS zones. Then use them while you configure Azure Database for PostgreSQL flexible servers with private access. For more information, see REST API specifications for Azure.

If you use the Azure portal or the Azure CLI to create Azure Database for PostgreSQL flexible servers, you can provide a Private DNS zone name that you previously created in the same or a different subscription, or a default Private DNS zone is automatically created in your subscription.

If you use an Azure API, an ARM template, or Terraform, create Private DNS zones that end with .postgres.database.chinacloudapi.cn. Use those zones while you configure Azure Database for PostgreSQL flexible servers with private access. For example, use the form [name1].[name2].postgres.database.chinacloudapi.cn or [name].postgres.database.chinacloudapi.cn. If you choose to use the form [name].postgres.database.chinacloudapi.cn, the name can't be the name that you use for one of your Azure Database for PostgreSQL flexible servers, or you'll get an error message during provisioning. For more information, see Private DNS zones overview.

When you use the Azure portal, APIs, the Azure CLI, or an ARM template, you can also change the Private DNS zone from the one that you provided when you created your Azure Database for PostgreSQL flexible server to another Private DNS zone that exists for the same or different subscription.

After you create a Private DNS zone in Azure, you need to link a virtual network to it. Resources hosted in the linked virtual network can then access the Private DNS zone.

DNS private zones are resilient to regional outages because zone data is globally available. Resource records in a private zone are automatically replicated across regions. Azure Private DNS is an availability zone foundational, zone-reduntant service. For more information, see Azure services with availability zone support.

Integration with a custom DNS server

If you're using a custom DNS server, you must use a DNS forwarder to resolve the FQDN of Azure Database for PostgreSQL flexible server. The forwarder IP address should be 168.63.129.16.

The custom DNS server should be inside the virtual network or reachable via the virtual network's DNS server setting. To learn more, see Name resolution that uses your own DNS server.

Private DNS zone and virtual network peering

Private DNS zone settings and virtual network peering are independent of each other. If you want to connect to the Azure Database for PostgreSQL flexible server from a client that's provisioned in another virtual network from the same region or a different region, you have to link the Private DNS zone with the virtual network. For more information, see Link the virtual network.

To map a server name to the DNS record, you can run the nslookup command using Azure PowerShell or Bash. Substitute the name of your server for the <server_name> parameter in the following example:

nslookup -debug <server_name>.postgres.database.chinacloudapi.cn | grep 'canonical name'

Replication across Azure regions and virtual networks with private networking

Database replication is the process of copying data from a central or primary server to multiple servers known as replicas. The primary server accepts read and write operations, but the replicas serve read-only transactions. The primary server and replicas collectively form a database cluster. The goal of database replication is to ensure redundancy, consistency, high availability, and accessibility of data, especially in high-traffic, mission-critical applications.

Azure Database for PostgreSQL - Flexible Server offers two methods for replications: physical (that is, streaming) via the built-in Read Replica feature and logical replication. Both are ideal for different use cases, and a user might choose one over the other depending on the end goal.

Replication across Azure regions, with separate virtual networks in each region, requires connectivity across regional virtual network boundaries that can be provided via virtual network peering.

By default, DNS name resolution is scoped to a virtual network. Any client in one virtual network (VNET1) is unable to resolve the Azure Database for PostgreSQL - Flexible Server FQDN in another virtual network (VNET2).

To resolve this issue, you must make sure clients in VNET1 can access the Azure Database for PostgreSQL - Flexible Server Private DNS zone. Add a virtual network link to the Private DNS zone of your Azure Database for PostgreSQL flexible server.

Unsupported virtual network scenarios

Here are some limitations for working with virtual networks created via virtual network integration:

• After an Azure Database for PostgreSQL flexible server is deployed to a virtual network and subnet, you can't move it to another virtual network or subnet. You can't move the virtual network into another resource group or subscription.
• Subnet size (address spaces) can't be increased after resources exist in the subnet.
• Virtual network injected resources can't interact with Private Link by default. If you want to use Private Link for private networking, see Azure Database for PostgreSQL - Flexible Server networking with Private Link.

Host name

Regardless of the networking option that you choose, we recommend that you always use an FQDN as the host name when you connect to your Azure Database for PostgreSQL flexible server. The server's IP address isn't guaranteed to remain static. Using the FQDN helps you avoid making changes to your connection string.

An example that uses an FQDN as a host name is hostname = servername.postgres.database.chinacloudapi.cn. Where possible, avoid using hostname = 10.0.0.4 (a private address) or hostname = 40.2.45.67 (a public address).

Related content

• Azure portal
• Azure CLI