Thursday, August 19, 2021

Azure Private Endpoint DNS configuration and zone separation

Introduction:

This article is a continuation of the series of articles starting with the description of SignalR service. In this article, we follow up on the discussion of Azure Private Endpoints with what helps Azure Gateway span private IP addresses, public IP addresses and availability zones. The topic in this article is the DNS configuration to route traffic between zones.

Zone-Down and DNS Configurations.

Availability zones are indistinguishable from one another. They are represented by numbers rather than by names in the Azure Resource Manager templates for resources provisioned in a region. A region can have up to three availability zones so their number is finite although there can be up to 100 private endpoints per application in a premium sku.

The Azure private endpoint is merely a network interface and has a designated IP address that can be reached over the virtual network. The endpoint can be accessed over the same virtual network, regionally peered virtual network, globally peered virtual network, on-premises using ExpressRoute or VPN and services with Azure Private Link. The connection to the private endpoint is always one-direction. It can only be initiated by the client.

An Azure service can have more than one private endpoints. These endpoints can be one per zone if the virtual network is separated. An application gateway can span all the endpoints including the public endpoint as its backend pool members. When the client sends traffic to the application gateway, it can be diverted to different private endpoints.

Some restrictions apply to the Azure private endpoint. For example, there are limits to the number of private endpoints that can be created per subscription. The resource and the virtual network must be in the same region otherwise there will be an error as follows: “Resource

/subscriptions/<hidden>/resourceGroups/RAVIRAJAMANI_TEST_RG/providers/Microsoft.Network/virtu alNetworks/RAVIRAJAMANI-VNET-1 referenced by resource /subscriptions/<hidden>/resourceGroups/ravirajamani_test_rg/providers/Microsoft.Network/privateEn dpoints/ravirajamani-redis-3-ep was not found. Please make sure that the referenced resource exists, and that both resources are in the same region.” Since all availability zones are in the same region for a resource, this restriction does not impose any difficulty with provisioning private endpoints for a given service. These endpoints can be one per zone if the virtual network is separated. An application gateway can span all the endpoints including the public endpoint as

its backend pool members. When the client sends traffic to the application gateway, it can be diverted to different private endpoints.

Azure Private Endpoint DNS configuration and zone separation

Introduction:

Zone-Down and DNS Configurations.

Each endpoint must be given a name. With records in the domain name server, the endpoint becomes reachable and resolvable from a virtual network. The following options are available to configure the DNS settings of an Azure private endpoint: 1) using only the host file that resolves the name locally 2) using a private DNS zone to override the DNS resolution for a private endpoint with the zone linked to the virtual network, and 3) using a DNS forwarder with a rule to use the DNS Zone in another DNS server. It is preferrable to not override a zone that resolves public endpoints because if the connectivity to the public DNS goes down, those public endpoints will remain unreachable. That is why a different domain name with a suffix such as “core.windows.net” is recommended. Multiple zones with the same name for different virtual networks would need manual operations to merge the DNS records.

Conclusion:

Zone based traffic diversion is not a feature that Azure services provide but they do allow private endpoints. If we setup endpoints per zone, the diversion of traffic between zones to simulate zone down can be facilitated with an application gateway.

Wednesday, August 18, 2021

Azure Private Link and Azure Private Endpoint

Introduction:

This article is a continuation of the series of articles starting with the description of SignalR service. In this article, we follow up on the discussion of Azure Gateway service with what helps Azure Gateway span private IP addresses, public IP addresses and availability zones. The topic in this article is Azure Private Link and its usage with the Azure Private endpoint.

Description and comparison:

Azure Private Link enables access to Azure Services over a virtual network so that they might be accessed over the Azure Backbone network rather than the public internet. An Azure service such as a cache provisioning service, a database provisioning service or a service bus broker service enables the corresponding provisioned resources to be accessed at their private endpoints via a virtual network that the user has setup for their application to interact with the services. Traffic between the virtual network and the services never goes to the internet providing benefits such as security, low latency, building and allowing private connections between resources as well as adding private endpoints to an application gateway backend pool.

The private link service is more than just the endpoint and its usage for a resource. It seamlessly connects customers to the Microsoft Azure resources and their client’s applications on a private network which would otherwise have required connectivity over the internet and the use of Virtual Private network (VPN). This provides a low cost, highly secure, and scalable environment that is a win-win for application, Microsoft cloud resources as well as the consumers that interact with those entities.

The benefit of using Azure Private Link include the privately accessed services on Azure platform because services written by Azure customers can now be put behind a load balancer to give it a private ip and then used with this service to communicate with one another using the private network. Connectivity between the customer’s virtual network and another service is now established one-on-one by this service. All that this customer needs to do is expose a private endpoint for the service. The private link platform will handle the connectivity over the Azure Backbone network.

This differs from the peered network in that the peered network allows many-to-many connectivity between the resources of either private network. Peered virtual networks appear as one to their client and resources on either network can access each other but it is used to connect separate virtual networks in the same Azure region or for global virtual networks that span different regions even if they are provisioned under different subscriptions and resource groups. Peering makes both networks appear as one where many resource in one network can access those in the other, but the links are cheap and efficient to perform only one mapping.

Azure Private Links can be set up for both on-premises network as well as peered virtual networks but without the overhead of ExpressRoute and Virtual Private Network (VPN). The link is always between the private endpoint on the customer’s virtual network and the Azure Private Link Service object provisioned by this service.

The link provides better protection against data exposure because it never transits the public internet. Also, other than the destination of the link, the traffic cannot be routed to another resource. All overheads associated with restricting access to service endpoints are now eliminated.

Yet there is no difference in reachability of the resource from anywhere in the world. The public endpoints were accessible over the internet and even when provisioned geographically were available to be accessed from anywhere making them hugely popular. The virtual networks always required additional setup and configuration to make them be accessible universally. This is not the case with a private link. It has global reach and yet the data never goes over the internet.

The Azure private endpoint is merely a network interface and has a designated ip address that can be reached over the virtual network. The endpoint can be accessed over the same virtual network, regionally peered virtual network, globally peered virtual network, on-premises using ExpressRoute or VPN and services with Azure Private Link. The connection to the private endpoint is always one-direction. It can only be initiated by the client. Some restrictions apply to the Azure private endpoint. For example, there are limits to the number of private endpoints that can be created per subscription. The resource and the virtual network must be in the same region otherwise there will be an error as follows: “Resource

Conclusion:

The use of private endpoints and private link from Azure is beneficial for the topology used with an architecture for the services. Its applicability is justified by the relevance of its benefits and almost wins hands-down in terms of avoiding the internet. This provides a low cost, highly secure, and scalable environment that is a win-win for application, Microsoft cloud resources as well as the consumers that interact with those entities.

Monday, August 16, 2021

Azure Private Link

Introduction:

This article is a continuation of the series of articles starting with the description of SignalR service. In this article, we follow up on the discussion of Azure Gateway service with what helps Azure Gateway span private IP addresses, public IP addresses and availability zones. We refer to the Azure Private Link Service and describe it this document.

Description and comparison:

Azure Private Link enables access to Azure Services over a virtual network so that they might be accessed over the Microsoft Backbone network rather than the public internet. The service such as a cache provisioning service, a database provisioning service or a service bus broker service enables the corresponding provisioned resources to be accessed at their private endpoints via a virtual network that the user has setup for their application to interact with the services. Traffic between the virtual network and the services never goes to the internet providing benefits such as security, low latency, building and allowing private connections between resources as well as adding private endpoints to an application gateway backend pool.

If the virtual network belonging to the client that has written the application involving the Microsoft Azure resources, is on-premises it can be directly connected to the Azure resources via this linking and avoids the use of ExpressRoute that traverses the internet. Similarly, it works on peered virtual networks. Peered virtual networks appear as one to their client and resources on either network can access each other but it is used to connect separate virtual networks in the same Azure region or for global virtual networks that span different regions even if they are provisioned under different subscriptions and resource groups. Peering makes both networks appear as one where many resource in one network can access those in the other, but the links are cheap and efficient to perform only one mapping. Azure Private Links can be setup for both the on-premises virtual network as well as the peered virtual network. All they need to do is create a private endpoint on their respective virtual networks so that the private endpoint can be linked to the Microsoft Azure resource. This private endpoint acts just like a proxy rather than the actual instance that would otherwise have required connectivity over the public internet. When the private endpoint is mapped to the Azure service, an Azure resource called the “private link service” which connects to the standard load balancer of the corresponding Azure service on its backend. The link is always between the private endpoint on the customer’s virtual network and the Azure Private Link Service object provisioned by this service.

Private connectivity facilitated by this service is preferred to the public connectivity for data protection, simpler network configuration, low latency for same region, global reach for cross-region access, and bringing together applications and services on a private network. The last one mentioned as a benefit is realized when the service written by an Azure customer can put it behind a standard load balancer and map to one another via this private link. The Azure Private Link can be setup for such load balancer regardless of whether it is an Azure service or the Azure customers’ service.

Conclusion:

Azure Private Links enhance the ability of the Azure customer to connect their applications and those of their customers to talk directly to Azure Services on a private network.