Application Gateways provide load-balanced solutions for network traffic that is based on the HTTP protocol. They use routing rules as application-level policies that can offload Secure Sockets Layer (SSL) processing from load-balanced Virtual Machines (VMs). In addition, you can use Application Gateways for a cookie-based session affinity scenario.
Cross-Premises Network Connectivity
Azure Virtual Network (VNet) enables you to extend your on-premises networks to the cloud.
To extend your on-premises network, you can either:
- Create a Virtual Private Network (VPN) between your on-premises computers/networks and an Azure VNet, or
- Use ExpressRoute to provide a connection to an Azure VNet that does not cross the Internet.
Using these two methods, you can enable on-premises users to access Azure services as if they were physically located on-premises in your own datacenter.
To connect to an Azure VNet from an on-premises network, you can use:
- Point-To-Site (P2S) VPN
- Site-To-Site (S2S) VPN
- VNet-to-VNet VPN
The Domain Name System (DNS) enables clients to resolve user-friendly Fully Qualified Domain Names (FQDNs), such as http://www.microsoft.com, to IP addresses.
Azure provides a DNS system to support many name resolution scenarios. However, in some cases, such as hybrid connection you will need to configure an external DNS system to provide name resolution for VMs on a VNet.
You should also ALWAYS use Static IP Addresses for DNS Servers.
With Forced Tunneling you can redirect internet bound traffic back to the company’s on-premises infrastructure. Forced tunneling is commonly used in scenario where organizations want to implement packet inspection or corporate audit.
VMs, Load Balancers, and Application Gateways in a single VNet require unique IP addresses in the same way as clients in an on-premises subnet do. This enables these resources to communicate with each other.
There are 2 types of IP addresses that are used in a VNet:
Private IP addresses
A Private IP address is allocated to a VM dynamically or statically from the defined scope of IP addresses in the VNet. The default allocation method is dynamic. This address is used by VMs in the VNet to communicate with other VMs in the same VNet connected VNets/networks through a Gateway/ExpressRoute connection.
Public IP addresses
Public IP addresses allow Azure resources to communicate with external clients, and are assigned directly at the virtual Network Interface Card (NIC) of the VM or to the Load Balancer.
To increase availability and scalability, you can create two or more VMs that publish the same application.
For example, if three VMs host the same website, you might want to distribute incoming traffic between them and ensure that if one VM fails, traffic is distributed automatically to the other two.
You can use an Azure Load Balancer to enable this traffic distribution between VMs. In this configuration, a single endpoint is shared between multiple VMs. The Azure Load Balancer automatically distributes requests across those VMs as the requests arrive at the endpoint.
You can use 2 types of Azure Load Balancers:
Internal Load Balancer
The Internal Load Balancer enables you to load balance traffic between VMs in the same cloud service (for classic model), or between VMs and a VNet with a Regional scope, where the input IP address of the load balancer is a Private IP address.
Internet-Facing (Public) Load Balancer
The Internet-Facing load Balancer enables you to load balance incoming Internet traffic to VMs.
Network Interface Card (NIC)
VMs communicate with other VMs and other resources on the network by using Virtual Network Interface Cards (NICs).
Virtual NICs configure VMs with private and optional public IP address. VMs can have more than one NIC for different network configurations.
Network Security Groups (NSG)
You can use Network Security Groups (NSG) to provide network isolation for Azure resources by defining rules that can allow/deny specific traffic to individual VMs or subnets. This enables you to design your Azure VNet to provide a network experience that is similar to an on-premises network. You can achieve the same functionality in your Azure VNet as you would in the on-premises networks, such as Perimeter Networks (also known as DMZ or Demilitarized Zone).
Regional Virtual Networks
Azure VNet is bound to Azure subscriptions and it is not possible for multiple subscriptions to use the same Azure VNet.
If you need to provide communications between different Azure subscriptions, you need to create separate Azure VNets in each subscription and then use Site-To-Site VPN or ExpressRoute, to connect them.
All new VNets are Regional Virtual Networks. This means that they can span a complete Azure region or datacenter. This differs from the legacy implementation of VNets in Azure, which were restricted to a single Affinity Group, allowing you to co-locate VNets, Storage Accounts, and services in the physical proximity to each other within the same area of a single datacenter.
If you have older VNets in your subscription, these could be tied to an Affinity Group. However, over time, you need to migrate all VNets to Regional Virtual Networks and remove their ties to specific Affinity Groups.
You can further divide your network by using Subnets for logical and security isolation of Azure resources. Each Subnet contains a range of IP addresses that fall within the VNet address space.
Azure Traffic Manager is another load-balancing solution that is included within Azure. You can use Traffic Manager to load balance between endpoints that are located in different Azure regions, at hosted providers, or in on-premises datacenters. These endpoints can include Azure VMs and Azure websites. You can configure this load-balancing service to support priority or to ensure that users connect to an endpoint that is close to their physical location for faster response.
User Defined Routes (UDR)
User Defined Routes (UDR) control network traffic by defining routes that specify the next hop of the traffic flow. You can assign UDR to VNet subnets.
Virtual Network (VNet)
Azure Virtual Network (VNet) is a fundamental component that acts as an organization’s network in Azure. Organizations can use VNets to connect resources. Azure VNets are network overlays that you can use to configure and control connectivity between Azure resources such as VMs and Load Balancers.