Network guide for migration service in Azure Database for PostgreSQL
APPLIES TO: Azure Database for PostgreSQL - Flexible Server
This document outlines various scenarios for connecting a source database to an Azure Database for PostgreSQL using the migration service. Each scenario presents different networking requirements and configurations to establish a successful connection for migration. Specific details vary based on the actual network setup and requirements of the source and target environments.
The table summarizes the scenarios for connecting a source database to an Azure Database for PostgreSQL using the migration service. It indicates whether each scenario is supported based on the configurations of the source and target environments.
PostgreSQL Source | Target | Supported |
---|---|---|
On-premises with public IP | Azure Database for PostgreSQL - Flexible Server with public access | Yes |
On-premises with private IP via VPN/ExpressRoute | VNet-integrated Azure Database for PostgreSQL - Flexible Server | Yes |
Amazon RDS for PostgreSQL/Amazon Aurora PostgreSQL with public IP | Azure Database for PostgreSQL - Flexible Server with public access | Yes |
Amazon RDS for PostgreSQL/Amazon Aurora PostgreSQL with private access via VPN/ExpressRoute | VNet-integrated Azure Database for PostgreSQL - Flexible Server | Yes |
PostgreSQL installed Azure VM in same/different virtual network | VNet-integrated Azure Database for PostgreSQL - Flexible Server in same/different virtual network | Yes |
Azure Database for PostgreSQL - Single Server with public access | VNet-integrated Azure Database for PostgreSQL - Flexible Server | Yes |
Azure Database for PostgreSQL - Single Server with private endpoint | VNet-integrated Azure Database for PostgreSQL - Flexible Server | Yes |
Azure Database for PostgreSQL - Single Server with private endpoint | Azure Database for PostgreSQL - Flexible Server with private endpoint | Yes |
PostgreSQL sources with private access | Azure Database for PostgreSQL - Flexible Server with private endpoint | Yes |
PostgreSQL sources with private access | Azure Database for PostgreSQL - Flexible Server with public access | No |
Scenario 1: On-premises source to Azure Database for PostgreSQL with public access
Networking Steps:
- The source database server must have a public IP address.
- Configure the firewall to allow outbound connections on the PostgreSQL port (default 5432).
- Ensure the source database server is accessible over the internet.
- Verify the network configuration by testing connectivity from the target Azure Database for PostgreSQL to the source database, confirming that the migration service can access the source data.
Scenario 2: Private IP on-premises source to virtual network-Integrated Azure Database for PostgreSQL via Express Route/IPSec VPN
Networking Steps:
- Set up a Site-to-Site VPN or ExpressRoute for a secure, reliable connection between the on-premises network and Azure.
- Configure Azure's Virtual Network (virtual network) to allow access from the on-premises IP range.
- Set up Network Security Group (NSG) rules to allow traffic on the PostgreSQL port (default 5432) from the on-premises network.
- Verify the network configuration by testing connectivity from the target Azure Database for PostgreSQL to the source database, confirming that the migration service can access the source data.
Scenario 3: Amazon RDS for PostgreSQL/Amazon Aurora PostgreSQL to Azure Database for PostgreSQL
The source database in another cloud provider (AWS) must have a public IP or a direct connection to Azure.
Networking Steps:
Public Access:
- If your Amazon RDS/Amazon Aurora instance isn't publicly accessible, you can modify the instance to allow connections from Azure. This can be done through the AWS Management Console by changing the Publicly Accessible setting to Yes.
- In the Amazon RDS/Amazon Aurora security group, add an inbound rule to allow traffic from the Azure Database for PostgreSQL's public IP address/domain.
Private Access
- Establish a secure connection using the express route or a VPN from Amazon to Azure.
- In the Amazon RDS/Amazon Aurora security group, add an inbound rule to allow traffic from the Azure Database for PostgreSQL's public IP address/domain or the range of IP addresses in the Azure virtual network on the PostgreSQL port (default 5432).
- Create an Azure Virtual Network (virtual network) where your Azure Database for PostgreSQL resides. Configure the virtual network's Network Security Group (NSG) to allow outbound connections to the Amazon RDS/Amazon Aurora instance's IP address on the PostgreSQL port.
- Set up NSG rules in Azure to permit incoming connections from the cloud provider, Amazon RDS/Amazon Aurora IP range.
- Test the connectivity between Amazon RDS/Amazon Aurora and Azure Database for PostgreSQL to ensure no network issues.
Scenario 4: Azure VMs to Azure Database for PostgreSQL (different virtual networks)
This scenario describes the connectivity between an Azure VM and an Azure Database for PostgreSQL, which are located in different virtual networks. Virtual network peering and appropriate NSG rules are required to facilitate traffic between the VNets.
Networking Steps:
- Set up virtual network peering between the two VNets to enable direct network connectivity.
- Configure NSG rules to allow traffic between the VNets on the PostgreSQL port.
Scenario 5: Azure VMs to Azure PostgreSQL (same virtual network)
The configuration is straightforward when an Azure VM and Azure Database for PostgreSQL are within the same virtual network. NSG rules should be set to allow internal traffic on the PostgreSQL port, and no additional firewall rules are necessary for the Azure Database for PostgreSQL since the traffic remains within the virtual network.
Networking Steps:
- Ensure that the VM and the PostgreSQL server are in the same virtual network.
- Configure NSG rules to allow traffic within the virtual network on the PostgreSQL port.
- No other firewall rules are needed for the Azure Database for PostgreSQL since the traffic is internal to the virtual network.
Scenario 6: Azure Database for PostgreSQL - Single server to VNet-Integrated Azure Database for PostgreSQL - Flexible server
To facilitate connectivity between an Azure Database for PostgreSQL - Single Server with public access and a Vnet-Integrated Flexible Server, you need to configure the Single Server to allow connections from the subnet where the Flexible Server is deployed. Here's a brief outline of the steps to set up this connectivity:
Add VNet Rule to Single Server:
Navigate to the Azure portal and open your PostgreSQL Single Server instance.
Go to the "Connection Security" settings.
Locate the "virtual network rules" section and select "Add existing virtual network".
This action lets you specify which virtual network can connect to your Single Server.
Configure Rule Settings:
Enter a name for the new virtual network rule in the configuration panel that appears.
Select the subscription where your Flexible Server is located.
Choose the virtual network (virtual network) and the specific subnet associated with your Flexible Server.
Confirm the settings by selecting "OK".
After completing these steps, the Single Server will be configured to accept connections from the Flexible Server's subnet, enabling secure communication between the two servers.
Scenario 7: Azure Database for PostgreSQL - Single server with private endpoint to VNet-Integrated Azure Database for PostgreSQL - Flexible server
To facilitate connectivity from an Azure Database for PostgreSQL Single Server with a private endpoint to a VNet-integrated Flexible Server, follow these steps:
Get private endpoint details:
In the Azure portal, navigate to the Single Server instance and select the private endpoint to view its virtual network and subnet details.
Access the Networking page of the Flexible Server to note its virtual network and subnet information.
Assess VNet Peering Requirements
- If both are in different VNets, you need to enable virtual network peering to connect one virtual network to another. Peering is optional if they are in the same virtual network but in different subnets. Ensure that no network security groups (NSGs) block the traffic from flexible server to single server.
Private DNS Zone Configuration
Go to the Networking page on the flexible server and check if a private DNS zone is being used. If used, open this private DNS zone in the portal. In the left pane, select the Virtual network links and check if the virtual network of single server and flexible server is added to this list.
If not, select the Add button and create a link to this private DNS zone for the VNets of single and flexible servers.
Go to the private endpoint on your single server and select the DNS configuration page. Check if a private DNS zone is attached with this endpoint. If not, attach a private DNS zone by selecting on the Add Configuration button.
Select the Private DNS zone on your single server private endpoint and check if the Vnets of single server and flexible server are added to the Virtual network links. If not, follow the steps mentioned in the above step to add the links to the virtual networks of the single and flexible server to this private DNS zone.
The final check would be to go the private DNS zone of the private endpoint on your single server and check if there exists an A record for your single server that points a private IP address.
Completing these steps enables the Azure Database for PostgreSQL - Flexible Server to connect to the Azure Database for PostgreSQL - Single Server.
Scenario 8: Azure Database for PostgreSQL single server with private endpoint to Azure Database for PostgreSQL flexible server with private endpoint
Below are the essential networking steps for migrating from a Single Server with a private endpoint to a Flexible Server with a private endpoint in Azure PostgreSQL, including the integration of a runtime server's virtual network with private endpoint configurations. For more information about the Runtime Server, visit the Migration Runtime Server.
Gather Private Endpoint Details for Single Server
- Access the Azure portal and locate the Azure Database for PostgreSQL - Single Server instance.
- Record the Virtual Network (virtual network) and subnet details listed under the private endpoint connection of the Single Server.
Gather Private Endpoint Details for Flexible Server
- Access the Azure portal and locate the Azure Database for PostgreSQL - Flexible Server instance.
- Record the Virtual Network (virtual network) and subnet details listed under the private endpoint connection of the Flexible Server.
Gather VNET details for Migration Runtime Server
- Access the Azure portal and locate the migration runtime server, that is, Azure Database for PostgreSQL - Flexible Server (VNET Integrated) instance.
- Record the Virtual Network (virtual network) and subnet details listed under the virtual network.
Assess VNet Peering Requirements
- Enable virtual network peering if the servers are in different VNets; no peering is needed in the same virtual network but with different subnets.
- Ensure no NSGs block traffic between the source, migration runtime, and target servers.
Private DNS Zone Configuration
- Verify the use of a private DNS zone on the networking page of the Migration Runtime Server.
- Ensure both source Azure Database for PostgreSQL - Single Server and target Azure Database for PostgreSQL - Flexible Server VNets are linked to the private DNS zone of the migration runtime server
- Attach a private DNS zone to the Single Server's private endpoint if not already configured.
- Add virtual network links for the Single Server and Migration Runtime Server to the private DNS zone.
- Repeat the DNS zone attachment and virtual network linking process for the Flexible Server's private endpoint.
Scenario 9: PostgreSQL source with private IPs to Azure Database for PostgreSQL flexible server with private endpoint
Below are the networking steps for migrating a PostgreSQL database from a cloud-based PostgreSQL service, an on-premises setup, or a virtual machine, all of which are configured with private IPs to an Azure Database for PostgreSQL Flexible Server that is secured with a private endpoint. The migration ensures secure data transfer within a private network space, using Azure's VPN or ExpressRoute for on-premises connections and virtual network peering or VPN for cloud-to-cloud migrations. For more information about the Runtime Server, visit the Migration Runtime Server.
Establish Network Connectivity:
- For on-premises sources, set up a Site-to-Site VPN or ExpressRoute to connect your local network to Azure's virtual network.
- For Azure VM or Amazon instances, ensure virtual network peering or a VPN gateway or a ExpressRoute is in place for secure connectivity to Azure's virtual network.
Gather VNET details for Migration Runtime Server
- Access the Azure portal and locate the migration runtime server, that is, Azure Database for PostgreSQL - Flexible Server (VNET Integrated) instance.
- Record the Virtual Network (virtual network) and subnet details listed under the virtual network.
Assess VNet Peering Requirements
- Enable virtual network peering if the servers are in different VNets; no peering is needed in the same virtual network but with different subnets.
- Ensure no NSGs are blocking traffic between the source, migration runtime, and target servers.
Private DNS Zone Configuration
- Verify the use of a private DNS zone on the networking page of the Migration Runtime Server.
- Ensure both source and target Azure Database for PostgreSQL - Flexible Server VNets are linked to the private DNS zone of the migration runtime server.
- Attach a private DNS zone to the Flexible Server's private endpoint if not already configured.
- Add virtual network links for the Flexible Server and Migration Runtime Server to the private DNS zone.
Resources for network setup
- To establish an ExpressRoute connection, refer to the What is Azure ExpressRoute?.
- For setting up an IPsec VPN, consult the guide on About Point-to-Site VPN.
- For virtual network peering, Virtual network peering