This is a continuation of a series of articles on operational engineering aspects of Azure public cloud computing that included the most networking discussions on Azure Private Endpoint which is a full-fledged general availability service.

This article discusses the troubleshooting of network connectivity problems as encountered with Azure Private Endpoints from operations:

1) When users convert their storage accounts or key vaults to use Azure Private endpoints, they are taking it offline from publicly accessible Internet and exposing it internally to their virtual networks. If they have existing usages of their resources that span more than one region, they will not be able to keep up those usages once those resources fall off the publicly vulnerable addresses. This does not impact usages that are all within the virtual network because an Azure private endpoint is a network interface that connects the other resources privately and securely to a private link service. The workloads running on other resources are given an option for private network connectivity as compared to the publicly vulnerable connectivity. This solution effectively brings those services to the virtual network.

By definition, a virtual network and the private endpoint must be in the same region. Use of multiple regions to connect a virtual network is not feasible without some form of regionally peered or globally peered virtual networks. The customer on-premises over VPN or Azure Express circuits can also access these private endpoints but care must be taken to ensure that the workloads are not impacted.

2) When a connectivity problem is encountered, the setup configuration must be checked. The Private Link Center provides an option to do so. The private endpoint is selected to diagnose, and the virtual network and DNS information is ascertained to be correct. The connection state must be in an Approved state. The resource must have connectivity to the virtual network that hosts the private endpoint. The FQDN and the private IP Address must be assigned. If these are correct, the setup is fine, but the data transfer might not be occurring. The Azure Monitor displays the Bytes in or Bytes out metrics for an Azure Private Endpoint. Attempting to connect to the private endpoint should display the data as flowing in under ten minutes. If this is not the case, the connection from the resource must be checked. The outbound connections page for the resource has a connection troubleshooting option as a Test Connection feature. This can be used with the Network Watcher for troubleshooting the connection. It is preferred to test by Fully Qualified Domain Name aka FQDN for the resource.

3) When a connection problem is identified aside from the private endpoint or its configuration, it would need to be investigated along with the name-resolution, Network Security Groups aka NSGs, or effective routes. Name resolution errors might occur due to DNS settings rather than IP connectivity. The steps to check the DNS settings depends on the use of a private zone or a custom DNS. If a private zone is used, the corresponding DNS zone record must exist. If it does not exist, it must be created. Delegation must be setup properly for the domain DNS to resolve to the child records. If a custom DNS is used, the settings must resolve to the private IP address of the private endpoint. The existing Azure services must already have a DNS configuration to use when connecting to a public endpoint. This configuration must be overwritten to connect to the private endpoint.

These are some of the ways in which the private connectivity can be made to work and used effectively as a replacement to public connectivity.