Private PostgreSQL flexible server geo-backup networking and pre-deployment zone-HA capacity checks

Fabric Admin 0 Reputation points
2026-10-09T04:02:09.2666667+00:00

We are evaluating a new private Azure Database for PostgreSQL flexible server in Central US: PostgreSQL 17, General Purpose Standard_D2ds_v5, Premium SSD 32 GiB, different-zone HA with same-zone fallback disabled, 35-day retention and geo-redundant backups. Authentication would be Entra-only. No deployment has been submitted.

  1. For a delegated private subnet, is outbound TCP 443 to Storage.CentralUS plus the automatically configured Microsoft.Storage endpoint sufficient for WAL archival and managed geographic backup replication? If not, what authoritative tags/routes are required for the primary, and separately for a private East US 2 recovery subnet? No cross-region read replica is planned.
  2. How can an administrator check exact D2ds_v5 eligibility/quota and different-zone placement capacity before deployment when only aggregate cores and older VM families appear in the quota page? What is the corresponding prerequisite check for an internal zone-redundant Container Apps workload-profile environment?
  3. What private DNS/network and capacity prerequisites apply to an East US 2 geo restore, and what limitations apply to re-enabling HA on the restored server?

Please link the current Microsoft documentation for the requirements. Generic regional availability or selectable portal controls do not establish subscription placement capacity. This asks for guidance only; it does not request a quota adjustment or resource change.

Azure Database for PostgreSQL
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Andriy Bilous 12,436 Reputation points MVP
    2026-10-09T05:03:14.19+00:00

    Hello Fabric Admin

    Your configuration is supported in principle, but networking requirements, quota eligibility, and actual availability-zone capacity are separate checks.

    1)Private networking and geo-backups

    For the Central US delegated subnet, Microsoft documents:

    • Allow outbound TCP 443 to Azure Storage (Storage.CentralUS is a regional service-tag option).
    • Preserve the automatically configured Microsoft.Storage service endpoint for WAL archival.
    • Allow TCP 5432 within the PostgreSQL delegated subnet for HA.
    • Allow outbound AzureActiveDirectory connectivity for Entra authentication.
    • Avoid UDRs that force Azure Storage traffic through an NVA.

    Geo-redundant backup replication is managed by Azure Storage, not by cross-region PostgreSQL read-replica traffic. You do not need to configure East US 2 database-subnet connectivity solely for backup replication.

    Microsoft: Private networking requirements

    2)SKU, quota, and zone-HA capacity

    Check the regional PostgreSQL SKU catalog:

    az postgres flexible-server list-skus \
  --location centralus -o json

    This helps verify SKU eligibility, but does not guarantee that Standard_D2ds_v5 can be allocated simultaneously in two different zones.

    Use Azure Support → Service and subscription limits → PostgreSQL Flexible Server → Region access with zonal dependency. Specify Central US, the exact SKU, both required zones, and the planned primary/standby vCores.

    With same-zone fallback disabled, deployment can fail if different-zone capacity is unavailable.

    However sufficient quota does not guarantee zone-HA capacity.

    For an internal, zone-redundant Container Apps workload-profile environment, use a dedicated VNet subnet of at least /27, delegated to Microsoft.App/environments, and enable zone redundancy during environment creation.

    Check supported profiles with:

    az containerapp env workload-profile list-supported \
  --location centralus

    This establishes supported profiles, not guaranteed placement capacity.

    Microsoft: Container Apps zone redundancy

    3)East US 2 geo-restore

    Prepare a separate East US 2 VNet and PostgreSQL-delegated subnet, private DNS zone/link, appropriate NSG/UDR rules, and Entra connectivity.

    Important limitations:

    • Geo-restore creates a new server using asynchronously replicated backups; RPO can reach approximately one hour.
    • Geo-backup restore is not an arbitrary point-in-time restore.
    • The restored server initially has HA disabled. You can enable zone-redundant HA afterward, subject to East US 2 capacity.
    • Compute tier, SKU, and storage cannot generally be changed during geo-restore.

    Microsoft: Backup and geo-restore requirements

    Validate both regions' SKU eligibility and networking now, request Microsoft confirmation of zone-dependent capacity, and perform a controlled geo-restore drill. Portal availability and unused quota alone are insufficient evidence that the planned HA or disaster-recovery deployment will succeed.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.