This is a continuation of the articles on IaC shortcomings and resolutions. The previous articles talked about different data backup and migration strategies and provided steps to go over the variations for resource types. This article discusses what is needed for a specific case where the data transfer must span azure management hierarchy of tenants, subscriptions, resource-groups and resources. As before, we will assume that all resources have private networking enabled for security and performance reasons. In addition, each virtual network for private networking is isolated from one another. For example, the virtual network in one subscription might not have any peering with that in any other subscription. Both public and private IP connectivity is enabled for each resource that acts as source and destination for data transfer.

Given such a scenario, the traditional way to allow cross virtual network access for use of resources in the said networks has been the use of private connections by virtue of private endpoints. Consequently, any destination for data transfer can request a private endpoint to be added where the data is saved on the source virtual network. Each virtual network can safely assume that typical options of name resolution to private IP assigned to these private connections is enabled with the help of private domain name resolution service. When the destination can connect to the remote source via the private IP connectivity thus established, the destination will be able to pull the data from the source. This works well for paired servers of the same resource type with the help of continuous replication that is supported by the resource types such as Azure managed instances of MySQL flexible servers and Azure managed instances for Apache Cassandra. However, it does not work that easily for cases where a third resource type or automation is involved to perform the transfers by way of pulling from the source and pushing to the destination. The involvement of a resource type, such as a Database Migration Service or an automation requires networking to be available to both source and the destination, so more connections need to be established than earlier and from both source and destination. These connections are always on the private IP connectivity plane, but it is also possible to keep the traffic over the public if the size of the data transfers is small and the encryption for data in transit is supported. In such cases, IP addresses for the entity performing the data transfers must be supported between the source and the destination. Any firewall or firewall polices must also support the allow listing of IP addresses. If the entity is an Azure resource and receives a public IP address from Azure, then it is not necessary to add allowlists for Microsoft IP addresses because such resources can be allowed traffic with the “Bypass trusted Azure services” option that is available under the network settings of the source and the destination. With the help of this option, it is easy to keep the public IP access restrictions light and simple. All traffic between Azure resources with public IP addresses from Azure will in such a case, flow over the Azure networking backbone. This prevents the Azure services from going over the public internet and provides very low latency of less than ten milliseconds as opposed to a hundred to two hundred milliseconds. In addition, to networking, authentication must be setup for each of the entity performing the data transfers. This again is required only in the case where continuous replication is not involved. An application identity can be dedicated for data backup/migration purposes. A role that honors the principle of least privilege must be assigned to this identity at both the source and the destination.

#codingexercise

https://1drv.ms/w/s!Ashlm-Nw-wnWhNIeZZhspIpNfjqURg?e=pymL9w