Azure Networking Components
- Availability zone
- Networking Security Groups
- Public and private IP
- Virtual Network Gateways (VPN & Express Route, Gateway Subnet, Express Route, and Local Network Gateway)
- VNET Perring
A Virtual Network, or a VNet, is an isolated network within the Microsoft Azure cloud. A VNet in Azure provides a range of networking functions comparable to AWS Virtual Private Cloud (VPC). These functions include DNS, routing, enabling customization of DHCP blocks, access control, connectivity between virtual machines (VM), and virtual private networks (VPN).
An Azure VNet is a representation of a network in the cloud and is a logical isolation of the Azure cloud dedicated to a subscription. In the background, it’s a software abstraction of a network that overlays Azure’s infrastructure to provide isolation from resources outside of the VNet, practically making it a private network.
Operationally, a VNet follows common IP routing principles to connect resources inside. So, it needs to have one or more address spaces associated with it (CIDR), which can be segmented into subnets, within which resources will reside. The scope of a virtual network is a single region; however, several virtual networks of the same or different regions can be connected by virtual network peering.
VNets can be used to:
Create a dedicated private cloud-only VNet to allow services and VMs within the VNet to communicate directly and securely in the cloud. Securely extend a data center, by building traditional site-to-site (S2S) VPNs or Express Route private circuits, to securely scale capacity. Deploy hybrid clouds by securely connecting cloud-based applications to on-premises systems.
Components of Azure Vnet
Subdivide a VNet into multiple networks which can be used for more granular separation of services
Assigned Public or Private IP to Azure VNET
Network Security Group
Network Traffic ACL is referred to as a subnet or NIC level for Filtering.
Application Security Group
Group common workloads in world-readable tags for use in NSGs.
Secure Azure Service Resouces to your VNet
Private Connectivity to Vnet or Azure PaaS like Outlook, Microsoft Partners, and customer-owned service.
Azure offers a managed Firewall service that provides the ability to define L3–7 connectivity policies for granular control of what enters and leaves the network
Azure Balcning Included
- Azure Traffic Manager — Route 53 in AWS
- Azure Load Balancer
- Azure Application Gateway
- Azure FrontDoor
As with general routing, anytime traffic needs to leave a subnet, it needs a routing function to forward packets to other subnets and networks. A router does this using a routing table, and that route table configuration is exposed in Azure for customized configuration. Route table can have rules that define where traffic should be sent to, i.e a virtual network, virtual network gateway, or virtual machine
User-Defined Route (UDR)
A static entry in a Route Table which can be used to forward traffic to a different Vnet, Network Virtual Appliance, This can be a powerful tool to build a connection between hubs.
Virtual Network Appliance(NVA)
or integration of 3rd party solutions, a virtual network appliance can be inserted into a VNet. This appliance is a virtual machine that executes a network function, such as a firewall, WAN optimization, or other network function. To see a list of virtual network applications that can be deployed in a virtual network, see Azure Marketplace.
Transit in Azure — Inter-Region
- Express Router Hairpining
- Peering VNET
Azure Virtual WAN
A Big hub providing connectivity for all type of entities to Azure or connecting to Azure
Azure Virtual WAN Limitations
- No MultiCloud Support
- Costly: Need to buy all features
- No 3rd party integration
- No NAT Capability
- Problem with Troubleshooting and visibility
- several features are still in previews
- Lack in controlling routing
- Lack in controlling security
Aviatrix Transit Architecture for Azure
Azure Native Transit
A Hub is a Virtual Network (Vnet) in Azure that acts as a central Connectivity in the azure network. The Spoke is Vnet that peers with a Hub that can be used for subscription, department, and workload, etc. Traffic route on-premise network to Virtual network through Express Route or VPN Gateway
Azure natively provides three methods for performing this functionality. Each of these options has advantages and disadvantages however, these options can be used simultaneously for customers to apply the right transit method for the desired outcome.
IntraRegion Transit Options
The options for spoke to spoke communication across regions follow the same patterns above with a few notable nuances.
leveraging Express Route
the most common transitive method is for customers to leverage their ExpressRoute circuits to provide spoke to spoke communication. The Method is default 0.0.0.0/0.
The advantage to this method is that this traffic will not incur VNET peering charges and this provides any to any spoke connectivity.
The disadvantage to this approach is that bandwidth is limited by the ExpressRoute gateway SKU, traffic takes a longer path from spoke to spoke, a lack of granular control as this method provides any to any communication and the fact that this is not a recommended approach as there is no dedicated bandwidth allocation on the Microsoft Edge Routers for this configuration
Leveraging a HUB (NVA)
for this method, A NVA is deployed inside the Vnet, and UDR (Suer Defined Route) is created to spoke to spoke traffic from the route.
The advantage of this approach is that traffic takes a more ideal path, does not require any route advertisements from on-prem.
The disadvantage to this approach comes with the management of UDRs at scale, potential bandwidth limits of the NVA itself, and the configuration of NVA high availability (HA) to ensure redundancy in case of failure.
The Recommended Approach to Spoke to Spoke Communication is VNEt Peering.
This option provides the lowest latency possible and has no bandwidth restrictions as opposed to the options previously discussed.
The disadvantage of this model is this connectivity is a 1 to 1 mapping.
InterRegion Transit Region
Leveraging Express route
this method is similar to what was described in Intra-Region however, as ExpressRoute circuits are terminated across regions the routes are propagated automatically. To facilitate cross-region spoke to spoke communication, no summary or default route is required. The same advantages and disadvantages apply.
Leveraging a HUb NVA
this method is also similar to what was previously described however, the number of UDRs increases as additional routes must be defined in the HUB VNETs to facilitate routing across regions to another HUB. Additionally, a VNET peer must be leveraged between the HUB to facilitate this HUB to HUB transit path.
the only change in VNET peering across regions is in naming convention. Microsoft refers to this as Global VNET Peering but still has the same advantages and disadvantages previously discussed. Azure Virtual WAN is another native architectural approach that can also provide transitive functionality. Aviatrix Transit can integrate with Azure Virtual WAN and is not covered in detail here.
Aviatrix Transit for Azure
The Aviatrix Controller provides an abstraction layer and workflow to build the Transit network. You do not need to program any Azure route tables, manage the route entries, or understand the significant details about Azure networking.
- Multi Subscriptions
The Controller provides a single pane of glass to manage the entire cloud network of multiple Azure subscriptions.
- Logging Service Integration
Out-of-the-box integration with Splunk, Sumo Logic, DataDog, ELK, Remote Syslog, and Netflow.
View connectivity status, network latency, and traffic statistics from a central dashboard.
- Granular Routing Control
Route redistribution can be controlled to selectively allow specific route propagation and/or summarization.
- Advanced Networking Features
Support for Network Address Translation, NGFW Insertion, FQDN filtering, etc.
- No Routing Limits
The Aviatrix solution auto summarizes the on-prem and Spoke VNet routes so that Spoke VNet route entries do not exceed the route limits.
- end to end encryptions.
All traffic in flight, between Spoke VNets and between Spoke to on-prem, is encrypted.