Merge pull request #269281 from GennadNY/gennadyk-branch24

v-dirichards · web-flow · commit 6727e87ad4fc · 2024-03-18T10:30:40.000-05:00
Gennadyk branch24
diff --git a/articles/postgresql/TOC.yml b/articles/postgresql/TOC.yml
@@ -331,6 +331,8 @@
         items:
         - name: Azure portal
           href: flexible-server/how-to-manage-virtual-network-private-endpoint-portal.md
+        - name: Azure CLI
+          href: flexible-server/how-to-manage-virtual-network-private-endpoint-cli.md
         - name: Connect to managed data factory via Private Endpoint
           href: flexible-server/how-to-connect-to-data-factory-private-endpoint.md
       - name: Public access (allowed IP addresses)
diff --git a/articles/postgresql/flexible-server/concepts-networking-private-link.md b/articles/postgresql/flexible-server/concepts-networking-private-link.md
@@ -12,12 +12,13 @@ ms.custom:
 ms.topic: conceptual
 ---
 
-# Azure Database for PostgreSQL - Flexible Server networking with Private Link - Preview
+# Azure Database for PostgreSQL - Flexible Server networking with Private Link 
 
 **Azure Private Link** allows you to create private endpoints for Azure Database for PostgreSQL flexible server to bring it inside your Virtual Network (virtual network). That functionality is introduced **in addition** to already [existing networking capabilities provided by VNET Integration](./concepts-networking-private.md), which is currently in general availability with Azure Database for PostgreSQL flexible server. With **Private Link**, traffic between your virtual network and the service travels the Microsoft backbone network. Exposing your service to the public internet is no longer necessary. You can create your own private link service in your virtual network and deliver it to your customers. Setup and consumption using Azure Private Link is consistent across Azure PaaS, customer-owned, and shared partner services.
 
-> [!NOTE]
-> Azure Database for PostgreSQL flexible server supports Private Link based networking in Preview.
+
+
+
 
 Private Link is exposed to users through two  Azure resource types:
 
@@ -31,10 +32,6 @@ For a list to PaaS services that support Private Link functionality, review the
 
 The same public service instance can be referenced by multiple private endpoints in different VNets/subnets, even if they belong to different users/subscriptions (including within differing Microsoft Entra ID tenants) or if they have overlapping address spaces.
 
-> [!NOTE]
-> **Important Prerequisite:** Azure Database for PostgreSQL flexible server support for Private Endpoints in Preview requires enablement of [**Azure Database for PostgreSQL flexible server Private Endpoint capability** preview feature in your subscription](../../azure-resource-manager/management/preview-features.md). 
-> Only **after preview feature is enabled** you can create servers which are PE capable, i.e. can be networked using Private Link.
-
 
 ## Key Benefits of Azure Private Link
 
@@ -56,25 +53,25 @@ Clients can connect to the private endpoint from the same VNet, peered VNet in s
 
 ### Limitations and Supported Features for Private Link  Preview with Azure Database for PostgreSQL flexible server
 
-In  Preview of Private Endpoint for Azure Database for PostgreSQL flexible server, there are certain limitations as explain in cross feature availability matrix below.
 
-Cross Feature Availability Matrix for preview of Private Endpoint in Azure Database for PostgreSQL flexible server.
+Cross Feature Availability Matrix for Private Endpoint in Azure Database for PostgreSQL flexible server.
 
 | **Feature** | **Availability** | **Notes** |
 | --- | --- | --- |
 | High Availability (HA) | Yes |Works as designed |
-| Read Replica | No | |
+| Read Replica | Yes | **Limitation: support replica site swap only with single replica.**|
 | Point in Time Restore (PITR) | Yes |Works as designed |
 | Allowing also public/internet access with firewall rules | Yes | Works as designed|
 | Major Version Upgrade (MVU) | Yes | Works as designed |
 | Microsoft Entra Authentication (Entra Auth) | Yes | Works as designed |
 | Connection pooling with PGBouncer | Yes | Works as designed |
 | Private Endpoint DNS | Yes | Works as designed and [documented](../../private-link/private-endpoint-dns.md) |
+| Encryption with Customer Managed Keys (CMK)| Yes| Works as designed|
 
 
 ### Connect from an Azure VM in Peered Virtual Network 
 
-Configure [VNet peering](../../virtual-network/tutorial-connect-virtual-networks-powershell.md) to establish connectivity to Azure Database for PostgreSQL flexible server from an Azure VM in a peered VNet.
+Configure [virtual network peering](../../virtual-network/tutorial-connect-virtual-networks-powershell.md) to establish connectivity to Azure Database for PostgreSQL flexible server from an Azure VM in a peered virtual network.
 
 ### Connect from an Azure VM in VNet-to-VNet environment
 
@@ -89,11 +86,12 @@ To establish connectivity from an on-premises environment to the Azure Database
 
 ## Network Security and Private Link
 
-When you use private endpoints, traffic is secured to a **private-link resource**. The platform validates network connections, allowing only those that reach the specified private-link resource. To access more subresources within the same Azure service, more private endpoints with corresponding targets are required. In the case of Azure Storage, for instance, you would need separate private endpoints to access the file and blob subresources.
+When you use private endpoints, traffic is secured to a **private-link resource**. The platform validates network connections, allowing only those connections that reach the specified private-link resource. To access more subresources within the same Azure service, more private endpoints with corresponding targets are required. In the case of Azure Storage, for instance, you would need separate private endpoints to access the file and blob subresources.
 
 **Private endpoints** provide a privately accessible IP address for the Azure service, but don't necessarily restrict public network access to it. All other Azure services require another [access controls](../../event-hubs/event-hubs-ip-filtering.md), however. These controls provide an extra network security layer to your resources, providing protection that helps prevent access to the Azure service associated with the private-link resource.
 
 Private endpoints support network policies. Network policies enable support for Network Security Groups (NSG), User Defined Routes (UDR), and Application Security Groups (ASG). For more information about enabling network policies for a private endpoint, see [Manage network policies for private endpoints](../../private-link/disable-private-endpoint-network-policy.md). To use an ASG with a private endpoint, see [Configure an application security group (ASG) with a private endpoint](../../private-link/configure-asg-private-endpoint.md).
+
 ## Private Link and DNS
 
 When using a private endpoint, you need to connect to the same Azure service but use the private endpoint IP address. The intimate endpoint connection requires separate DNS settings to resolve the private IP address to the resource name.
@@ -102,6 +100,8 @@ Private DNS zones provide domain name resolution within a virtual network withou
 Private DNS zones provide separate DNS zone names for each Azure service. For example, if you configured a private DNS zone for the storage account blob service in the previous image, the DNS zones name is **privatelink.blob.core.windows.net**. Check out the Microsoft documentation here to see more of the private DNS zone names for all Azure services.
 > [!NOTE]  
 > Private endpoint private DNS zone configurations will only automatically generate if you use the recommended naming scheme: **privatelink.postgres.database.azure.com**
+> On newly provisioned public access (non VNET injected) servers there is a temporary DNS layout change. The server's FQDN will now be a CName, resolving to A record, in format **servername.privatelink.postgres.database.azure.com**. In the near future, this format will apply  only when private endpoints are created on the server.
+
 
 ## Private Link and Network Security Groups
 
@@ -126,10 +126,10 @@ The following situations and outcomes are possible when you use Private Link in
 
 ## Troubleshooting connectivity issues with Private Endpoint based networking
 
-Following are basic areas to check if you are having connectivity issues using Private Endpoint based networking:
+Following are basic areas to check if you're having connectivity issues using Private Endpoint based networking:
 
 1. **Verify IP Address Assignments:** Check that the private endpoint has the correct IP address assigned and that there are no conflicts with other resources. For more information on private endpoint and IP see this [doc](../../private-link/manage-private-endpoint.md)
-2. **Check Network Security Groups (NSGs):** Review the NSG rules for the private endpoint's subnet to ensure the necessary traffic is allowed and does not have conflicting rules.  For more information on NSG see this [doc](../../virtual-network/network-security-groups-overview.md)
+2. **Check Network Security Groups (NSGs):** Review the NSG rules for the private endpoint's subnet to ensure the necessary traffic is allowed and doesn't have conflicting rules.  For more information on NSG see this [doc](../../virtual-network/network-security-groups-overview.md)
 3. **Validate Route Table Configuration:** Ensure the route tables associated with the private endpoint's subnet and the connected resources are correctly configured with the appropriate routes.
 4. **Use Network Monitoring and Diagnostics:** Leverage Azure Network Watcher to monitor and diagnose network traffic using tools like Connection Monitor or Packet Capture. For more information on network diagnostics see this [doc](../../network-watcher/network-watcher-overview.md)
 
diff --git a/articles/postgresql/flexible-server/concepts-networking-private.md b/articles/postgresql/flexible-server/concepts-networking-private.md
@@ -52,7 +52,6 @@ Here are some concepts to be familiar with when you're using virtual networks wh
 
   > [!IMPORTANT]
   > The names `AzureFirewallSubnet`, `AzureFirewallManagementSubnet`, `AzureBastionSubnet`, and `GatewaySubnet` are reserved within Azure. Don't use any of these as your subnet name.
-  > For Azure Storage connection please make sure the Azure Database for PostgreSQL flexible server delegated subnet has Service Endpoints for Azure Storage in the region of the VNet. The endpoints are created by default, but please take care not to remove these manually.
 
 * **Network security group (NSG)**. Security rules in NSGs enable you to filter the type of network traffic that can flow in and out of virtual network subnets and network interfaces. For more information, see the [NSG overview](../../virtual-network/network-security-groups-overview.md).
 
@@ -134,7 +133,7 @@ Use [Azure Virtual Network Manager (AVNM)](../../virtual-network-manager/overvie
 
 Frequently customers have a need  to connect to clients different Azure regions. More specifically, this question typically boils down to how to connect two VNETs (one of which has Azure Database for PostgreSQL - Flexible Server and another application client) that are in different regions.
 There are multiple ways to achieve such connectivity, some of which are:
-* **[Global VNET peering](../../virtual-network/virtual-network-peering-overview.md)**. Most common methodology, as its is the easiest way to connect networks in different regions together. Global VNET peering creates a connection over the Azure backbone directly between the two peered VNETs. This provides best network throughput and lowest latencies for connectivity using this method. When VNETs are peered, Azure will also handle the routing automatically for you, these VNETs can communicate with all resources in the peered VNET, established on a VPN gateway. 
+* **[Global VNET peering](../../virtual-network/virtual-network-peering-overview.md)**. Most common methodology, as it's the easiest way to connect networks in different regions together. Global VNET peering creates a connection over the Azure backbone directly between the two peered VNETs. This provides best network throughput and lowest latencies for connectivity using this method. When VNETs are peered, Azure will also handle the routing automatically for you, these VNETs can communicate with all resources in the peered VNET, established on a VPN gateway. 
 * **[VNET-to-VNET connection](../../vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal.md)**. A VNET-to-VNET connection is essentially a VPN between the two different Azure locations. The VNET-to-VNET connection is established on a VPN gateway. This means your traffic incurs two additional traffic hops as compared to global VNET peering. There's also additional latency and lower bandwidth as compared to that method. 
 * **[Communication via network appliance in Hub and Spoke architecture](#using-hub-and-spoke-private-networking-design)**. 
 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. 
diff --git a/articles/postgresql/flexible-server/how-to-manage-virtual-network-private-endpoint-cli.md b/articles/postgresql/flexible-server/how-to-manage-virtual-network-private-endpoint-cli.md
@@ -0,0 +1,80 @@
+---
+title: Manage virtual networks with Private Link - CLI
+description: Create an Azure Database for PostgreSQL - Flexible Server instance with public access by using the Azure CLI, and add private networking to the server based on Azure Private Link.
+author: gennadNY
+ms.author: gennadyk
+ms.service: postgresql
+ms.subservice: flexible-server
+ms.custom:
+  - ignite-2023
+ms.topic: how-to
+ms.date: 03/12/2024
+---
+
+
+# Create and manage virtual networks with Private Link for Azure Database for PostgreSQL - Flexible Server by using the Azure CLI
+
+[!INCLUDE [applies-to-postgresql-flexible-server](../includes/applies-to-postgresql-flexible-server.md)]
+
+Azure Database for PostgreSQL flexible server supports two types of mutually exclusive network connectivity methods to connect to your Azure Database for PostgreSQL flexible server instance. The two options are:
+
+* Public access through allowed IP addresses. You can further secure that method by using [Azure Private Link](./concepts-networking-private-link.md)-based networking with Azure Database for PostgreSQL flexible server. The feature is in preview.
+* Private access through virtual network integration.
+
+This article focuses on creating an Azure Database for PostgreSQL flexible server instance with public access (allowed IP addresses) by using the Azure portal. You can then help secure the server by adding private networking based on Private Link technology.
+
+You can use [Private Link](../../private-link/private-link-overview.md) to access the following services over a private endpoint in your virtual network:
+
+* Azure platform as a service (PaaS) services, such as Azure Database for PostgreSQL flexible server
+* Customer-owned or partner services that are hosted in Azure
+
+Traffic between your virtual network and a service traverses the Microsoft backbone network, which eliminates exposure to the public internet.
+
+
+
+## Prerequisites
+
+To add an Azure Database for PostgreSQL flexible server instance to a virtual network by using Private Link, you need:
+
+1.  A [virtual network](../../virtual-network/quick-create-portal.md#create-a-virtual-network). The virtual network and subnet should be in the same region and subscription as your Azure Database for PostgreSQL flexible server instance.
+
+    Be sure to remove any locks (**Delete** or **Read only**) from your virtual network and all subnets before you add a server to the virtual network, because locks might interfere with operations on the network and DNS. You can reset the locks after server creation.
+
+
+2. You need to sign in to your account using the [az login](/cli/azure/reference-index#az-login) command. Note the **ID** property, which refers to **Subscription ID** for your Azure account.
+
+    ```azurecli
+    az login
+    ```
+
+3.  Select the specific subscription under your account using [az account set](/cli/azure/account#az-account-set) command. Make a note of the **ID** value from the **az login** output to use as the value for **subscription** argument in the command. If you have multiple subscriptions, choose the appropriate subscription in which the resource should be billed. To get all your subscription, use [az account list](/cli/azure/account#az-account-list).
+
+    ```azurecli
+    az account set --subscription <subscription id>
+    ```
+
+## Create an Azure Database for PostgreSQL flexible server instance with a private endpoint
+
+1. Create virtual network, private endpoint, private DNS zone and link it
+
+   You can follow this Azure networking [doc](../../private-link/create-private-endpoint-cli.md) to complete these steps.
+
+2. Create PostgreSQL Flexible Server with no public access
+
+    ```azurecli
+
+    az postgres flexible-server create --resource-group <resource_group_name> --name <server_name> --public-access 'None'
+    ```
+
+3. Approve the specified private endpoint connection created in first step associated with a PostgreSQL flexible server.
+
+    ```azurecli
+    az postgres flexible-server private-endpoint-connection approve -g <resource_group> -s <server_name> -n <connection_name>        --description "Approve connection"
+    ```
+
+## Next steps
+
+* Learn more about [networking in Azure Database for PostgreSQL flexible server with Private Link](./concepts-networking-private-link.md).
+* Understand more about [virtual network integration in Azure Database for PostgreSQL flexible server](./concepts-networking-private.md).
+
+
diff --git a/articles/postgresql/flexible-server/how-to-manage-virtual-network-private-endpoint-portal.md b/articles/postgresql/flexible-server/how-to-manage-virtual-network-private-endpoint-portal.md
@@ -30,14 +30,16 @@ You can use [Private Link](../../private-link/private-link-overview.md) to acces
 
 Traffic between your virtual network and a service traverses the Microsoft backbone network, which eliminates exposure to the public internet.
 
+
+
 ## Prerequisites
 
 To add an Azure Database for PostgreSQL flexible server instance to a virtual network by using Private Link, you need:
 
 * A [virtual network](../../virtual-network/quick-create-portal.md#create-a-virtual-network). The virtual network and subnet should be in the same region and subscription as your Azure Database for PostgreSQL flexible server instance.
 
   Be sure to remove any locks (**Delete** or **Read only**) from your virtual network and all subnets before you add a server to the virtual network, because locks might interfere with operations on the network and DNS. You can reset the locks after server creation.
-* Registration of the [PostgreSQL private endpoint preview feature in your subscription](../../azure-resource-manager/management/preview-features.md).
+
 
 ## Create an Azure Database for PostgreSQL flexible server instance with a private endpoint
 
