Architectural considerations for virtual networks

Virtual networks like any other resource can be provisioned using ARM templates, REST API's, PowerShell, and CLI. It is quite important to plan the network topology at the beginning stage itself to avoid troubles later in the development life cycle. This is because once the network is provisioned and resources start using it, it is difficult to change it without having a downtime. For example, for moving a virtual machine from one network to another will require the virtual machine to shut down.

• Regions: The virtual network is an Azure resource and is provisioned within a region such as West Europe. Applications spanning multiple regions will need separate virtual networks, one per region, and they also need to be connected using the VNET-to-VNET connectivity. There is a cost associated with VNET-to-VNET connectivity for both inbound and outbound traffic. There are no charges for inbound (ingress) data; however, there are charges associated with outbound data.
• Dedicated DNS: Virtual networks by default use Azure provided DNS to resolve names within a virtual network and it also allows name resolution on the internet. If the application wants a dedicated name resolution service or wants to connect to the on-premise data centers, it should provide its own DNS server and they should be configured within the virtual network for successful name resolution.
• Network performance: Every virtual network has a defined throughput, and it is wise to create a separate virtual network to have a consistent performance instead of putting all network related resources on a single network. This might clog the network.
• Number of virtual networks: The number of virtual networks is affected by the number of regions, bandwidth usage by services, cross-region connectivity, and security.
• Number of subnets in each virtual network: Subnets provide isolation within a virtual network. It is also a security boundary. Network security groups can be associated with subnets thereby restricting or allowing specific access to IP addresses and ports. Application components having separate security and accessibility requirements should be placed within separate subnets.
• IP ranges for networks and subnets: Each subnet has an IP range. The IP range should not be large enough to be underutilized them while other subnets are getting suffocated because of lack of IP addresses. It should have just enough IP addresses to meet current and future requirements. This should be considered after understanding the future IP address needs of the deployment.

Planning should be done for IP addressing and ranges for Azure networks, subnets and on-premise data centers. There should not be an overlap for seamless connectivity and accessibility.

• Monitoring: Monitoring is an important architectural facet and is a must to be included in the overall deployment architecture. Azure Network Watcher provides logging and diagnostic capabilities with insights into network performance and health. It provides capabilities to watch both inbound or outbound packets to and from virtual machines, whether they are allowed or denied, next hop flow for validating the configuration of user-defined routes, an audit of network security, capturing packets along with subscription limits. It also provides diagnostic logs for all the network resources in a resource group.

Network performance can be monitored through log analytics. The network performance monitor management solution provides network monitoring capability. It monitors the health, availability, and reachability of networks. It is also used to monitor connectivity between public cloud and on-premises and subnets hosting various tiers of a multi-tiered application.

• Security considerations: Virtual networks are one of the first components that is accessed by any resource on Azure. Security plays an important role to allow or deny access to the resource. Network security groups (NSG) are the primary means of enabling security for virtual networks. They can be attached to virtual network subnets and every inbound and outbound flow is constrained, filtered, and allowed to them.

User-defined routing (UDR) and IP forwarding also helps in filtering and routing requests to resources on Azure.

Resources can also be secured and protected by deploying network appliances such as barracuda, F5, and other third-party components.

• Deployment: Virtual networks should be deployed in its own dedicated resource groups. Network administrators should have owner permission on this resource group, while developers or team members should have contributor permissions for allowing them to create another Azure resource in other resource groups consuming services from the virtual network.

It is also good practice to deploy resources with static IP addresses in a dedicated subnet, while dynamic IP address related resources can be on another subnet.

Policies should be created so that only network administrators can delete the virtual network, and it should also be tagged for billing purposes.

• Connectivity: Resources in a region on a virtual network can talk seamlessly. Even resources on other subnets within a virtual network can talk to each other without any explicit configuration. Resources in multiple regions cannot use the same virtual network. The boundary of a virtual network is within a region. To make resources available across regions, communicate with each dedicated gateway, which is required on each end to facilitate conversation. The networks on each end are connected to other networks through these gateways.

However, resources on Azure also at times have connectivity needs to on-premise data centers. Azure virtual networks can connect to on-premise data centers using VPN technology and ExpressRoute. In fact, one virtual network is capable of connecting to multiple on-premise data centers and other Azure regions in parallel. As a best practice, each of these connections should be in their dedicated subnets within a virtual network.