AZ-900: Networking
In previous posts of this AZ-900 series, we have looked at the various compute and storage offerings from Azure. In this post, we are going to look at the Networking options.
Virtual Networks
To use private networking within Azure, you will need to use Azure Virtual Networks. These are the building blocks of private networking working in a similar manner to any other Network. But rather than having to install and configure switches and cable in each resource individually, Virtual Networks are software defined, meaning they can be configured and deployed in code with no physical interactive.
Virtual Networks provide you the ability to isolate resources and segment your network configuration as requires. VNets enable Azure resources to communicate with each other, the internet or on-premises resources. The VNet comprises an address space which can be segmented into multiple subnets.
By default, all resources in a VNet can communicate outbound to the Internet, assigning Public IP addresses or public Load Balancers would allow for inbound communication too. They also allow filtering or routing of network traffic.
When creating other resources, Azure can automatically create the networking resources it needs. But these additional resources my not align with your organizations networking structure, so it is advisable to deploy the required networking infrastructure before deploying your require resources.
Communication
There are several different methods you can use to ensure secure communication between resources. Resources deployed to the same Virtual Network can communicate with each via the private network using the internal IP address range. Being in the same VNets allows services like Azure Kubernetes Service (AKS) and Azure Virtual Machines to communicate within a secure environment.
The Virtual Network could also be extended using Service Endpoints. These allow direct communication over the Azure backbone network. Service Endpoints allows you to secure resources to only VNets without the need for public IP addresses. Service Endpoints are available for services like Azure Storage, Azure SQL Database or Azure CosmosDB.
You can also connect multiple virtual networks to each other through VNet Peering. VNet Peering provides a low-latency and high bandwidth connection between resources deployed into different virtual networks. These connections can be within the same Azure region or across Azure regions. There is a restriction on Peering that the address spaces of the two VNets must not overlap.
VPN Gateway
As well as allowing communication between different Azure resources, VNets can be used to connect to on-premises locations. You can use the VPN Gateway to connect your on-premises resources to your Azure VNet using an encrypted VPN tunnel.
Point-to-Site
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal
A Point-to-Site (P2S) VPN gateway connection lets you create a connection from an individual client computer to your virtual network. P2S connections are a useful solution for a distributed team that accesses Azure resources from remote locations such as home workers.
Site-to-Site
https://docs.microsoft.com/en-us/azure/vpn-gateway/tutorial-site-to-site-portal
A site-to-site (S2S) VPN gateway connection is a VPN tunnel. This is a good solution when looking for a hybrid configuration or needs on-premises connections into your Azure VNet. A Site-to-Site connection links a whole on-premises location to the VNet by using a VPN device and public IP address to create the tunnel between Azure and your local resources.
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal
As well as using VNet Peering, you can also use the VPN Gateway to create a VNet-to-VNet connection. This connection behaves similarly to a Site-2-Site connection to on-premises resources, providing an encrypted tunnel for communication between the two Azure VNets.
ExpressRoute
If you are looking to extend your on-premises networks into Azure, but find the bandwidth limits of a Site-2-Site connection or require the connection not to traverse the Internet. Then using ExpressRoute should be considered. ExpressRoute connections do not go over the public Internet, which means they offer faster speeds, more reliable and secure connections.
Further Reading:
VNets: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview
VPN Gateways: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways
ExpressRoute: https://docs.microsoft.com/en-us/azure/expressroute/expressroute-introduction
—Matt Boyd