Azure virtual network, Application gateway, Front Door
Virtual Networking
A local area network, or LAN, is a kind of wired network that can usually only reach within the domain of a single building. A wide area network, or WAN, is another kind of wired network, but the computers and devices connected to the network can stretch over a half-mile in some cases.
Conversely, a virtual network doesn’t follow the conventional rules of networking because it isn’t wired at all. Therefore, all devices that interact with each other in the network do so through internet technology, allowing them to have a further reach than they would have if they were wired. The network itself is as limitless as the internet
A virtual network is a network where all devices, servers, virtual machines, and data centers that are connected are done so through software and wireless technology.
Azure Virtual Network (VNet)
An Azure Virtual Network (VNet) is a representation of your own network in the cloud. It is a logical isolation of the Azure cloud dedicated to your subscription. You can use VNets to provision and manage virtual private networks (VPNs) in Azure and, optionally, link the VNets with other VNets in Azure, or with your on-premises IT infrastructure to create hybrid or cross-premises solutions. Azure resources like VMs, web apps and DB etc can communicate with each other, with user on internet.
When creating a VNet, you must specify a custom private IP address space using public and private (RFC 1918) addresses. Azure assigns resources in a virtual network a private IP address from the address space that you assign. For example, if you deploy a VM in a VNet with address space, 10.0.0.0/16, the VM will be assigned a private IP like 10.0.0.4.
Subscription: VNet is scoped to a subscription. You can implement multiple virtual networks within each Azure subscription and Azure region.
Advantages of VNet
- Create a dedicated private cloud-only VNet. Sometimes you don’t require a cross-premises configuration for your solution. When you create a VNet, your services and VMs within your VNet can communicate directly and securely with each other in the cloud.
- Securely extend your data center. With VNets, you can build traditional site-to-site (S2S) VPNs to securely scale your datacenter capacity
- Enable hybrid cloud scenarios. VNets give you the flexibility to support a range of hybrid cloud scenarios. You can securely connect cloud-based applications to any type of on-premises system
- Scale, availability, isolation
Internet communications
A VM in Azure can connect to the internet by default. You can enable incoming connections from the internet by defining a public IP address or a public load balancer. For VM management, you can connect via the Azure CLI, Remote Desktop Protocol, or Secure Shell.
Communicate with on-premises resources
Azure virtual networks enable you to link resources together in your on-premises environment and within your Azure subscription. In effect, you can create a network that spans both your local and cloud environments. There are three mechanisms for you to achieve this connectivity:
Point-to-site virtual private networks: This approach is like a virtual private network (VPN) connection that a computer outside your organization makes back into your corporate network, except that it’s working in the opposite direction. In this case, the client computer initiates an encrypted VPN connection to Azure to connect that computer to the Azure virtual network.
Site-to-site virtual private networks: A site-to-site VPN links your on-premises VPN device or gateway to the Azure VPN gateway in a virtual network. In effect, the devices in Azure can appear as being on the local network. The connection is encrypted and works over the internet.
Azure ExpressRoute: For environments where you need greater bandwidth and even higher levels of security, Azure ExpressRoute is the best approach. ExpressRoute provides dedicated private connectivity to Azure that doesn’t travel over the internet.
Virtual network peering
You can link virtual networks together by using virtual network peering. Peering enables resources in each virtual network to communicate with each other. These virtual networks can be in separate regions, which allows you to create a global interconnected network through Azure.
UDR is user-defined Routing or UDR is a significant update to Azure’s Virtual Networks as this allows network admins to control the routing tables between subnets within a subnet as well as between VNets thereby allowing for greater control over network traffic flow.
Performance and Redirection Options
Load Balancer:
If you wish to present a number of virtual machines as a single public or private IP address to other services or clients, then load balancers can be used to load balance TCP or UDP traffic.
Azure Load Balancer
It is a load balancer service that Microsoft provides that helps take care of the maintenance for you. Load Balancer supports inbound and outbound scenarios, provides low latency and high throughput, and scales up to millions of flows for all Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) applications. You can use Load Balancer with:
- Incoming internet traffic
- Internal traffic across Azure services
- Port forwarding for specific traffic
- Outbound connectivity for VMs in your virtual network.
(Web) Application Gateway (WAG):
Web traffic load balancer that enables you to manage traffic to your web applications. It is Layer 7 load balancing for HTTP or HTTPS services.
Content Delivery Network (CDN):
Store common files on the edge, closer to the users for (perceived) improved performance.
Azure Application Gateway
Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. Traditional load balancers operate at the transport layer (OSI layer 4 — TCP and UDP) and route traffic based on source IP address and port, to a destination IP address and port.
Application Gateway can make routing decisions based on additional attributes of an HTTP request, for example URI path or host headers. For example, you can route traffic based on the incoming URL. So if /images
is in the incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If /video
is in the URL, that traffic is routed to another pool that's optimized for videos.
This type of routing is known as application layer (OSI layer 7) load balancing. Azure Application Gateway can do URL-based routing and more.
Microsoft WAN
Microsoft is the second largest private global dark fiber network in the world. Once you get a packet onto this WAN, you have an extremely low latency connection between any two points. For example, if a client connects to Azure in a region, they have a low latency connection all the way to Microsoft services in another region — the speed cannot be matched on the public Internet where there would be many hops and much higher latency.
Let’s say that you use a service such as Azure’s Traffic Manager to present a web service to the world. Once a client hits your public frontend, it will be redirected across the public Internet to the public IP address (endpoint) of your website. If the client is in Sydney, Australia, and the service is hosted in India, then that introduces a lot of latency. Static content delivery will be enhanced, but other interactive services will suffer from latency.
What if we could enable the client to enter the Microsoft WAN closer to their location, and connect to the Azure-hosted service across that WAN?
Azure Front Door
Front Door is like a global load balancing, but it is doing more by enhancing performance. Front Door is an entry point into the Microsoft WAN that is deployed in edge sites around the world. When you connect to a service that Front Door is enhancing, you enter the Microsoft WAN through the closest (AnyCast protocol) edge site and, from there, you connect to the closest available (probe tested) instance or replica of the service via the Microsoft WAN.
The core capabilities of Azure Front Door include:
- Application and API acceleration through the use of anycast which will optimize the connectivity to Azure application services and reduce the latency for end users.
- Global HTTP load balancing allows developers to build out geo-distributed services and lets Azure determine endpoint availability and intelligent routing to local, and available, endpoints.
- SSL offload relieves endpoints of performing expensive decryption computation and moves the function higher-up in the stack.
- WAF @ Edge web application filtering provides protection against DDoS attacks or malicious users at the edge without impacting backend services.
Route network traffic
By default, Azure routes traffic between subnets on any connected virtual networks, on-premises networks, and the internet. You also can control routing and override those settings, as follows:
Route tables: A route table allows you to dene rules about how traffic should be directed. You can create custom route tables that control how packets are routed between subnets.
Border Gateway Protocol: Border Gateway Protocol (BGP) works with Azure VPN gateways or ExpressRoute to propagate on-premises BGP routes to Azure virtual networks.