In all of my Azure deployment for clients, networking plays a key role of cloud architecture integration with on-premises networks. Often, companies have headquarters and offices around the world and need to access resources hosted on Azure.
The hub-and-spoke model allows for growth, flexibility, planning and designing virtual networks in Azure. The hub acts as a central point of connectivity and shared services while the spokes are VNETs that connect to the hub Vnet using virtual network peering.
Implementing the Hub and Spoke architecture has the following benefits :
Overcoming subscription limits by peering VNets from multiple subscriptions to the central hub
Routing traffic through the central hub so workloads can be managed centrally
Cost reduction by centralizing services (NVAs, DNS servers) that can be shared by multiple workloads
Hub-and-Spoke Architecture Components in Azure
The hub is the virtual network in Azure that acts as a central point of business connectivity to your on-premises network.
The spokes are virtual networks in Azure that peer with the hub, used to isolate workloads.
The traffic flows between the on-premises datacenter and the hub through an ExpressRoute.
The spoke 1 virtual network and spoke 2 virtual network are peered to the Hub which fosters communication to on-premises resources. The peering allows the virtual network to exchange traffic using Azure backbone without the need for a router. Peering virtual networks in the same region or different region are allowed; however, there are certain requirements and constraints.
Requirements and components for a hub and spoke network in Azure
Naming: Having a naming convention that can be used consistently when naming resources is essential when managing network resources over time. The name should be unique within a scope. The name of the virtual network must be unique within a resource group, but can be duplicated within a subscription or Azure region.
Regions: Your networking resources are created in an Azure region and subscription. It is important that you choose the region that aligns with your data sovereignty and compliance requirements. Also, ensuring that your resources can be accessed without high latency is relative to your on-premises specified location and Azure regions.
Hub virtual network: The virtual network is used as the hub in the hub-spoke topology. The hub is the central point of connectivity to your on-premises network and a place to host services that can be consumed by the different workloads hosted in the spoke virtual networks.
Spoke virtual networks: One or more virtual networks are used as spokes in the hub-and-spoke topology.
Azure VPN Gateway: VPN Gateway is the bridge between your on-premises network and Azure. VPN gateways are a special type of Virtual Network gateway that sends encrypted traffic between the two networks over the internet
Gateway subnet: The virtual network gateways are held in the same subnet.
Azure ExpressRoute: ExpressRoute is a service in Azure that allows you to extend on-premises networks over a private connection. Implementation of ExpressRoute does take some time. You must work through a connectivity provider, and this might require a physical network device implementation. Pending the time Express Route is setup, site-to-site VPN can be leveraged between your on-premises resources and Azure virtual networks. You can then migrate to ExpressRoute once the setup is complete.
Virtual network peering: Two virtual networks can be connected using a peering connection. Peering connections are non-transitive, low latency connections between virtual networks. Once peered, the virtual networks exchange traffic by using the Azure backbone, without the need for a router. In a hub-and-spoke network topology, you use virtual network peering to connect the hub to each spoke. You can peer virtual networks in the same region, or different regions.
Segmentation: It is important to consider potential isolation of traffic into different subnets or virtual networks, or into separate subscriptions.
Security: Use network security groups and network virtual appliances to filter network traffic to and from resources in a virtual network. You can also leverage Azure Firewall to protect Azure Virtual Network resources.
Routing: Azure virtual networks automatically create routing tables within each subnet and add default system routes to the tables. Custom routes would allow you to override these default system routes. When using a Network Virtual Appliance (NVA), you must create custom routes to route traffic from subnets to the NVA to provide enhanced security and filtering capabilities
Base Components for securing your hub-and-spoke network
To ensure that your resources are protected from any authorized access or attack, the following components should be implemented:
Use Network Security Group (NSG) to filter Vnet traffic: The NSG rules allow or deny inbound network traffic to and from each resource in the topology. Each subnet within the virtual networks should have a NSG associated to it. Associating NSG at the NIC level would be a nightmare for Network Administrators to manage.
Implement Firewalls and NVAs in the hub networks: Network virtual appliances (NVAs) provide a secure network boundary by checking all inbound and outbound network traffic. Then the NVA passes only the traffic that meets network security rules, essentially acting as a firewall.
Implement ExpressRoute for your mission critical connections: ExpressRoute creates a dedicated private WAN link between on-premises resources and an Azure gateway subnet in the hub virtual network. They do not go over the public internet. ExpressRoute connections offer higher security, reliability, and higher speeds (up to 10 Gbps), along with consistent latency.
Implement an Azure Perimeter Network: You should configure a perimeter network in its own subnet in the hub virtual network for routing external traffic. The perimeter network is designed to host network virtual appliances to provide security functionality, such as firewalls and packet inspection. You can route the outbound traffic from the perimeter network through virtual appliances so that traffic is monitored, secured, and audited.
Deploy Azure Firewall: Microsoft manages this network security service. It protects Azure virtual networks and their resources by letting you manage and enforce connectivity policies centrally. Azure Firewall uses a static, public IP address for virtual network resources, allowing outside firewalls to identify your virtual network traffic. Because Azure Firewall is integrated with Azure Monitor Logs, you can view the full logs there. It also provides some logs available for viewing from the Azure Portal.
Other Additional Security Components to Consider
Use Application Security Groups (ASGs) where necessary: ASGs group VMs and define network security policies based on application security groups. Application security groups will enable you to reuse your security policy at scale without manual maintenance of explicit IP addresses.
Azure Network Watcher: It provides tools to monitor, diagnose, view metrics, and enable or disable logs for resources in an Azure virtual network. For example, you can monitor communications between a VM and an endpoint such as another VM or FQDN, view resources and resource relationships in a VNet, or diagnose network traffic issues.
Use Virtual Network Service Endpoints: With this, you can extend your VNet private address space and identity to Azure services over a direct connection. Traffic from your VNet to the Azure service always remains on the Azure backbone network
Control your Public IP addresses: Public IP addresses in Azure can be associated with VMs, application gateways, load balancers, and VPN gateways. As a best practice, VMs should not be configured with a public IP address. If you need to have a port opened, it should only be for web services such as port 443 or 80. The standard remote management ports such as RDP (3389) and SSH (22) should be set to deny.
Comments