Azure Networking Components Overview
Key components for Azure Networking:
Azure Virtual Network
IP Addressing in Virtual Networks
Azure Load Balancer
Application gateways
Domain Name System (DNS)
Subnets
Microsoft Azure Traffic Manager
Cross-Premises Network Connectivity: VPN Gateway ExpressRoute
Azure offer two deployment models: Azure Resource Manager vs. classic deployment: Understand deployment models and the state of your resources.
1. Azure Classic Deployment Model
2. Azure Resource Manager Deployment Model
Microsoft is moving towards the Resource Manager deployment model.
Azure Resource Manager contains a network provider that provides advanced control and network management capabilities.
Advantages of using Azure Resource Manager to configure Azure Virtual Networks
- Faster configuration due to resources being grouped.
- Easier management.
- Customization and deployment based on JavaScript Object Notation (JSON) templates.
- Networking resources such as IP addresses, DNS settings, or NICs are managed independently and can be assigned to VMs, Azure load balancers, or application gateways.
You can create Azure network resources by using either the Azure Portal, Azure PowerShell module, Azure command-line interface (Azure CLI), or by using deployment templates as well.
Connecting to Virtual Networks
There are several ways to connect to Azure VNet:-
Cloud-Only Virtual Networks
Point-to-Site VPNs
Site-to-Site VPNs
ExpressRoute
VNet-to-VNet
Planning IP Address Space
Always plan to use an address space that is not already in use in your organisation, either on-premises or in other VNets. Even if you plan for a VNet to be cloud-only, you may want to make a VPN connection to it later. If there is any overlap in address spaces at that point, you will have to reconfigure or recreate the VNet.
Subnet Allocation
You must also sub-divide the VMs and cloud services in your VNet by providing one or more subnets.
Planning for Name Resolution
Name Resolution Scenarios
- VMs in the same cloud service. VMs can resolve the names of all other VMs in the same cloud service automatically by using the internal Azure name resolution.
- VMs in the same VNet. If the VMs are in different cloud services but within a single VNet, those VMs can resolve IP addresses for each other by using the internal Azure name resolution service and their Fully Qualified Domain Names (FQDNs). This is supported only for the first 100 cloud services in the VNet. Alternatively, use your own DNS system to support this scenario.
- Between VMs in a VNet and on-premises computers. To support this scenario you must use your own DNS system.
- Between VMs in different VNets. To support this scenario you must use your own DNS system.
- Between on-premises computers and public endpoints. If you publish an endpoint from a VM in an Azure VNet, the Azure-provided external name resolution service will resolve the public VIP. This also applies for any internet-connected computers that are not on your premises.