Private networking deployments for Azure Database for PostgreSQL Flexible Server often span multiple subscriptions in enterprise environments shared VNets, central networking subscriptions, and centralized Private DNS zones are common patterns. In this lesson, we walk through a incident where a PostgreSQL Flexible Server deployment consistently failed with a vague Internal error, despite correct VNet injection, subnet delegation, and Private DNS configuration. This post explains why this happens, how to detect it quickly, and how to prevent it in future private deployments.
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.
Microsoft