VNET Peering and Transit Hub

VNET Peering:

Once virtual networks are peered, resources in both virtual networks can communicate with each other, with the same latency and bandwidth as if the resources were in the same virtual network.

So, with this diagram:

I see that VNETs Virtual Network, VNET1, VNET2, and On-premise can all access the SQL database.

Then:

Scenario

• What say SQL 1 and SQL 2 databases exist.
  • SQL 1 DB has a Private Link in VNET1.
  • SQL 2 DB has a Private Link in VNET2.
• Peering is the same as shown in this diagram.

Questions:

• I assume the fact that the Private Links for SQL 1 in VNET 1 and SQL 2 for VNET are accessible from on-premises? Or do I need to have the Private Link in the Virtual Network VNET? How then?
• Can VNET1 and VNET2 access eachother's SQL databases via Virtual Network VNET?

Solution 1:

When a private link is used, PaaS services are connected to a VNet using private endpoints: they get private IP addresses in that VNet, and those private IP addresses can be used to access them; thus yes, everything that can reach a VNet (via peering, ExpressRoute, VPN or whatever) can access services which have a private link to it.

However, some DNS tuning could be required, depending on your DNS configuration; private links rely on the public names of PaaS services being remapped to their private IP addresses, which is automatically done by Azure DNS only when it's queried from inside the linked VNet.

Update

VNet peerings are not transitive, thus traffic will not flow between the two spoke VNets unless you create an explicit peering between them.

Traffic will instead flow between on-premises computer and them, if you enable gateway transit and remote gateways in their peerings with the hub VNet.