Subnet issue while migrating to Postgres flexible server

GeethaThatipatri-MSFT 29,017 Reputation points Microsoft Employee
2024-07-26T18:59:14.97+00:00

What are the limitations and solutions when facing subnet issues while migrating to an Azure Database for PostgreSQL flexible server?

PS - Based on common issues that we have seen from customers and other sources, we are posting these questions to help the Azure community

Azure Database for PostgreSQL
{count} votes

2 answers

Sort by: Most helpful
  1. Amanulla Asfak Ahamed 80 Reputation points
    2024-07-26T19:01:55.2833333+00:00

    When migrating to an Azure Database for PostgreSQL Flexible Server, common subnet-related issues include:

    1. Subnet Size: Ensure the subnet is large enough to accommodate the Flexible Server and any other resources, with a recommended CIDR range of /27 or larger to avoid IP address limitations.
    2. Network Security: Verify that the subnet’s network security group (NSG) rules allow for the required inbound and outbound traffic on the necessary ports (typically 5432 for PostgreSQL).
    3. Service Endpoints: Configure the subnet with the required service endpoints or private link to securely connect to other Azure services.
    4. Resource Conflicts: The subnet should not have any conflicting resources that interfere with the Flexible Server, such as incompatible service endpoints.

    Solutions often involve resizing the subnet, adjusting NSG rules, configuring proper service endpoints, or choosing an appropriate VNet for the Flexible Server. If issues persist, consider consulting Azure support or documentation for specific guidance tailored to your migration scenario.

    0 comments No comments

  2. GeethaThatipatri-MSFT 29,017 Reputation points Microsoft Employee
    2024-07-26T19:05:49.14+00:00

    Greetings!

    When migrating to an Azure Database for PostgreSQL flexible server, certain limitations exist concerning virtual networks (VNET) and subnets. Specifically, once a PostgreSQL flexible server instance is deployed to a virtual network and subnet, it cannot be moved to another virtual network or subnet. Additionally, the virtual network itself cannot be moved into another resource group or subscription. This is documented in the official Azure documentation and is an unsupported scenario.

     User's image

    For more information on unsupported virtual network scenarios and subnet delegation, please refer to the official Azure documentation:

     

    Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.

     

    Please do not forget to "up-vote" wherever the information provided helps you, as this can be beneficial to other community members.

    Regards

    Geetha

    0 comments No comments