Azure PostgreSQL Lesson #15: Private DNS in Another Subscription Causing Server Deployment Failures
Co‑authored with angesalsaa Case Overview A customer attempted to deploy Azure Database for PostgreSQL – Flexible Server using private networking (VNet injection + Private DNS). The deployment failed with a generic “Internal error”, offering no clear indication of what was wrong. At first glance, networking looked correct: VNet was properly peered Subnet delegation was in place Private DNS zone existed Permissions appeared sufficient Yet, the deployment consistently failed. Root Cause (What We Found) The Virtual Network and Private DNS zone were hosted in a different subscription than the PostgreSQL server. While the PostgreSQL subscription had Microsoft.DBforPostgreSQL registered, the subscription hosting the VNet / Private DNS zone did NOT. Azure requires the Microsoft.DBforPostgreSQL resource provider to be registered in every subscription involved not just where the PostgreSQL server lives. This applies to: VNets used for VNet injection Private DNS zones linked to those VNets If the provider is missing, the deployment fails silently with an internal error. Key Insight Cross‑subscription networking for Azure PostgreSQL Flexible Server is not passive. Azure actively validates resource providers in all referenced subscriptions. Resolution Once Microsoft.DBforPostgreSQL was registered in the network/DNS subscription, the deployment completed successfully without any other changes. Troubleshooting & Validation Steps STEP 1 – Identify Cross‑Subscription Dependencies Check whether: VNet is in a different subscription Private DNS zone is in a different subscription STEP 2 – Validate Resource Provider Registration In every involved subscription, ensure: Microsoft.DBforPostgreSQL is registered. Azure Portal path: Subscription → Resource Providers → Microsoft.DBforPostgreSQL → Register Azure resource providers and types - Azure Resource Manager | Microsoft Learn STEP 3 – Retry Deployment After registration: Re-run PostgreSQL Flexible Server deployment Internal error should no longer occur Best Practices (Avoid This in Future) Always register Microsoft.DBforPostgreSQL in: PostgreSQL subscription VNet subscription Private DNS subscription Validate provider registration before private deployments Document cross‑subscription prerequisites in landing zones Include this check in IaC / ARM / Bicep pipelines References Azure Database for PostgreSQL – Flexible Server Networking overview with private access (virtual network) | Microsoft Learn Takeaway If your PostgreSQL Flexible Server deployment fails with an Internal error in a private network setup check resource provider registration across subscriptions before touching networking.
