You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/postgresql/flexible-server/concepts-networking-private.md
+9-9
Original file line number
Diff line number
Diff line change
@@ -92,14 +92,14 @@ For new Azure Database for PostgreSQL flexible server creation by using private
92
92
93
93
If you use the [Azure portal](./how-to-manage-virtual-network-portal.md) or the [Azure CLI](./how-to-manage-virtual-network-cli.md) to create Azure Database for PostgreSQL flexible servers, you can provide a Private DNS zone name that you previously created in the same or a different subscription, or a default Private DNS zone is automatically created in your subscription.
94
94
95
-
If you use an Azure API, an ARM template, or Terraform, create Private DNS zones that end with `.postgres.database.azure.com`. Use those zones while you configure Azure Database for PostgreSQL flexible servers with private access. For example, use the form `[name1].[name2].postgres.database.azure.com` or `[name].postgres.database.azure.com`. If you choose to use the form `[name].postgres.database.azure.com`, the name _can't_ be the name that you use for one of your Azure Database for PostgreSQL flexible servers. You get an error message during provisioning. For more information, see [Private DNS zones overview](/azure/dns/private-dns-overview).
95
+
If you use an Azure API, an ARM template, or Terraform, create Private DNS zones that end with `.postgres.database.azure.com`. Use those zones while you configure Azure Database for PostgreSQL flexible servers with private access. For example, use the form `[name1].[name2].postgres.database.azure.com` or `[name].postgres.database.azure.com`. If you choose to use the form `[name].postgres.database.azure.com`, the name _can't_ be the name that you use for one of your Azure Database for PostgreSQL flexible servers, or you'll get an error message during provisioning. For more information, see [Private DNS zones overview](/azure/dns/private-dns-overview).
96
96
97
-
When you use the Azure portal, APIs, the Azure CLI, or an ARM template, you can also change the Private DNS zone from the one you provided when you created your Azure Database for PostgreSQL flexible server to another Private DNS zone that exists for the same or different subscription.
97
+
When you use the Azure portal, APIs, the Azure CLI, or an ARM template, you can also change the Private DNS zone from the one that you provided when you created your Azure Database for PostgreSQL flexible server to another Private DNS zone that exists for the same or different subscription.
98
98
99
99
> [!IMPORTANT]
100
-
> The ability to change a Private DNS zone from the one you provided when you created your Azure Database for PostgreSQL flexible server to another Private DNS zone is currently disabled for servers with the high-availability feature enabled.
100
+
> The ability to change a Private DNS zone from the one that you provided when you created your Azure Database for PostgreSQL flexible server to another Private DNS zone is currently disabled for servers with the high-availability feature enabled.
101
101
102
-
After you create a Private DNS zone in Azure, you need to [link](/azure/dns/private-dns-virtual-network-links) a virtual network to it. Once linked, resources hosted in that virtual network can access the Private DNS zone.
102
+
After you create a Private DNS zone in Azure, you need to [link](/azure/dns/private-dns-virtual-network-links) a virtual network to it. Resources hosted in the linked virtual network can then access the Private DNS zone.
103
103
104
104
> [!IMPORTANT]
105
105
> We no longer validate virtual network link presence on server creation for Azure Database for PostgreSQL - Flexible Server with private networking. When you create a server through the portal, we provide customer choice to create a link on server creation via the checkbox **Link a Private DNS zone to your virtual network** in the Azure portal.
@@ -135,9 +135,9 @@ The spokes are also virtual networks in Azure that are used to isolate individua
135
135
136
136
There are three main patterns for connecting spoke virtual networks to each other:
137
137
138
-
-**Spokes directly connected to each other**: Virtual network peerings or VPN tunnels are created between the spoke virtual networks to provide direct connectivity without traversing the hub virtual network.
138
+
-**Spokes are directly connected to each other**: Virtual network peerings or VPN tunnels are created between the spoke virtual networks to provide direct connectivity without traversing the hub virtual network.
139
139
-**Spokes communicate over a network appliance**: Each spoke virtual network has a peering to a virtual WAN or to a hub virtual network. An appliance routes traffic from spoke to spoke. The appliance can be managed by Microsoft (as with a virtual WAN) or by you.
140
-
-**Virtual network gateway attached to the hub network and make use of user-defined routes**: Enables communication between the spokes.
140
+
-**A virtual network gateway is attached to the hub network and makes use of user-defined routes**: Enables communication between the spokes.
141
141
142
142
:::image type="content" source="media/concepts-networking-private/hub-spoke-architecture.png" alt-text="Diagram that shows basic hub-and-spoke architecture with hybrid connectivity via an express hub.":::
143
143
@@ -147,10 +147,10 @@ Use [Azure Virtual Network Manager](/azure/virtual-network-manager/overview) to
147
147
148
148
Frequently, customers have a need to connect to clients' different Azure regions. More specifically, this question typically boils down to how to connect two virtual networks (one of which has Azure Database for PostgreSQL - Flexible Server and another has an application client) that are in different regions.
149
149
150
-
There are multiple ways to achieve such connectivity, some of which are:
150
+
There are multiple ways to achieve such connectivity, including:
151
151
152
-
-[Global virtual network peering](/azure/virtual-network/virtual-network-peering-overview). This methodology is the most common because it's the easiest way to connect networks in different regions together. Global virtual network peering creates a connection over the Azure backbone directly between the two peered virtual networks. This provides the best network throughput and lowest latencies for connectivity by using this method. When virtual networks are peered, Azure also handles the routing automatically for you. These virtual networks can communicate with all resources in the peered virtual network that are established on a VPN gateway.
153
-
-[Virtual network-to-virtual network connection](/azure/vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal). A virtual network-to-virtual network connection is essentially a VPN between the two different Azure locations. The virtual network-to-virtual network connection is established on a VPN gateway. Your traffic incurs two more traffic hops as compared to global virtual network peering. There's also extra latency and lower bandwidth as compared to that method.
152
+
-[Global virtual network peering](/azure/virtual-network/virtual-network-peering-overview). This methodology is the most common because it's the easiest way to connect networks in different regions together. Global virtual network peering creates a connection over the Azure backbone directly between the two peered virtual networks. This method provides the best network throughput and lowest latencies for connectivity. When virtual networks are peered, Azure also handles the routing automatically for you. These virtual networks can communicate with all resources in the peered virtual network that are established on a VPN gateway.
153
+
-[Network-to-network connection](/azure/vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal). A connection between virtual networks (network-to-network connection) is essentially a VPN between the two Azure locations. The network-to-network connection is established on a VPN gateway. Your traffic incurs two more traffic hops as compared to global virtual network peering. There's also extra latency and lower bandwidth as compared to that method.
154
154
-**Communication via network appliance in hub-and-spoke architecture.** Instead of connecting spoke virtual networks directly to each other, you can use network appliances to forward traffic between spokes. Network appliances provide more network services like deep packet inspection and traffic segmentation or monitoring, but they can introduce latency and performance bottlenecks if they're not properly sized.
155
155
156
156
### Replication across Azure regions and virtual networks with private networking
0 commit comments