Before starting your journey into Azure IaaS, like in a physical world, one of the main topics which should be understood is networking. This is for many reasons, but most importantly:
- Understanding the basic topology of Azure networks enables correct placement of Virtual Machine workloads
- Understanding how deploying networks in ASM vs. ARM can affect management and functionality
- Understanding the security options within Azure helps you prevent data loss
- Understanding connectivity options helps you to optimise end-user experience
- Understanding how 3rd party appliances can enhance network features and security helps you meet regulatory and governance requirements
While it may not be immediately obvious, some decisions around networking can have a deep and lasting impact on your deployment such as being unable to move a Virtual Machine to a new network without deleting it and re-creating. As your Cloud deployment grows in size and complexity, such problems can quickly escalate and become near impossible to resolve without significant impact to your service.
This first post of the series will focus primarily on the basic topology of the Azure networks, look at the differences between networks in ASM vs. ARM, and touch on some of the core features available in Azure for securing your workloads and data.
Disclaimer: Some of the information in this post has been discovered or inferred through extensive research and testing, but is not based on inside knowledge from Microsoft. As such, the accuracy of statements made regarding the inner workings of the Azure platform is entirely speculative. Any feedback or thoughts would be greatly appreciated and happily referenced.
Azure IaaS Networking Components
As with many things in Microsoft Azure, the platform is continually evolving as Microsoft release new features and tweak some of those we’re learning to use.
The networking features available in Azure IaaS is no different!
At the time of writing, the Azure networking stack is built up from the following main components:
- Azure Network Access Layer
- Azure IDS/IPS Layer
- Azure Load Balancer
- Azure Fabric
- Private Networks
- Virtual Machines
These components can be represented in the following manner:
Below the Cloud Access Layer is what Microsoft refers to as the “Private Network”. This is the network element which can be managed and controlled by the client, and provides the logical isolation of customer workloads within the public cloud infrastructure.
One of the first things to understand is that ALL Virtual Machines (regardless of user configuration) are configured with a private IP address and all inbound connectivity from the Internet (blocked by default) is provided using NAT through the Azure Load Balancer. The way in which this works is currently changing as we transition from using Azure Service Management (ASM) to Azure Resource Manager (ARM) so I’ll give a quick overview below.
In ASM, VMs can only be created as part of a Cloud Service. The Cloud Service provides core functionality for the VM, including an Azure Load Balancer instance allocated with a Public IP address for external access, and a back-end network.
By default, the back-end network for a VM created in ASM is a “Deployment Network” which provides connectivity for private communication between all VMs within that Cloud Service (up to a maximum of 50 VMs). IP addresses are assigned to the VM from a pre-defined scope using a shared DHCP service within the Azure Fabric, while name resolution is provided by Azure DNS to ensure all VMs can resolve domain names for the Internet and for other VMs within the same Cloud Service.
Alternatively, the Cloud Service can be assigned to a new or existing Virtual Network and a VM can then be allocated to a Subnet within that Virtual Network. While IP addresses are still allocated by DHCP, these will now be from a user-defined scope and you’ll be given the flexibility to design a network topology suitable for hosting multi-tiered applications and multiple applications which require secure connectivity beyond the boundaries defined by a Cloud Service. A Virtual Network also allows you to configure a number of advanced options such as creating VPN gateways for external connectivity (more on that in a future post).
Note: Many of the configuration options within a Virtual Network can only be performed at the time of creation or while the network has no VMs associated with it. Similarly, a VM can only be associated with a network at the time of creation. As such, it’s important that you get the configuration right from the beginning or you face having to re-deploy your entire service from scratch!
In ARM, all resources (including VMs) are defined within Resource Groups. Resource groups allow the VM to be logically grouped with other resources as needed, including other VMs. Unlike ASM, ARM doesn’t use the concept of a Cloud Service. Instead, each VM must be associated with a Virtual Network. The Virtual Network can be either an existing network from another Resource Group, or a new one defined as part of the VM creation. This structure allows you to create a logical hierarchy of services, designed to meet the needs of your deployment.
Note: Virtual Networks follow the same basic concepts within both ASM and ARM, but are different entities and have a few differences. For example, Virtual Networks created in ARM don’t currently support connectivity with Azure ExpressRoute (although this is planned for a future release). Expect all new features to be focused on ARM though.
Both Deployment Networks and Virtual Networks sit within an abstracted layer of the Azure Fabric, allowing them to be distributed across all data centres within an Azure Region. When configured in Availability Sets, Microsoft can automatically place your VMs across multiple Update Domains and Failure Domains to provide an SLA backed uptime guarantee.
Cloud Access Layer
Regardless of the approach used for deploying your VMs, they will all share the same basic network infrastructure within Microsoft Azure. Microsoft has referred to the upper layers of this network infrastructure as the “Cloud Access Layer”. The Cloud Access Layer is shared by all Azure tenants and is the backbone of the Azure networking platform.
While all Azure tenants will use the Cloud Access Layer (often without realising it), not all components are user configurable and most are configured indirectly. For example, configuring an endpoint for a virtual machine will configure the Azure Load Balancer to allow the specified inbound traffic to the specified Virtual Machine. Access Control Lists (ACLs) or Network Security Groups (NSGs) can then be applied to these endpoints to control who can access your service. These are applied within the Azure Fabric which includes a Distributed Firewall component, but it should be noted that only one method or the other can be used.
Note: Although both can be configured within the portal, it appears that application of an NSG will override any ACLs configured on that object.
The component of most interest within the Cloud Access Layer is probably the Azure Load Balancer, which is a configurable Layer 4 Load Balancer. For more information, click on the image below:
Regardless of how you configure your application, chances are you’ll be using the Azure Load Balancer at some point as this is the only method by which you can present your application to the Internet for inbound traffic. Of course some organisations may consider Layer 4 load balancing to be insufficient. Fortunately a number of 3rd party providers are able to provide virtual appliances capable of providing enhanced load balancing functionality up to Layer 7 of the OSI Model, including Barracuda and F5 (again, more on that in a future post).
Multi-Tenancy in Azure IaaS
To provide segregation between different tenants, Microsoft has built the Azure platform on a hyper-scale Software-Defined Network (SDN). This allows Microsoft to offer customers logical isolation within a public Cloud platform to ensure security boundaries are maintained.
As Azure is a multi-tenant platform, the network infrastructure must provide protection against vulnerabilities from both internal and external threats. To achieve this, Microsoft has implemented comprehensive information security policies and processes. These measures are regularly certified by 3rd party auditors against industry standards, including ISO 27001, SOC 1 & SOC 2.
The following diagram provides an overview of traffic flow for multiple tenants in the Azure IaaS platform:
At this point it’s worth saying that direct communication between Private Networks (whether Deployment Networks or Virtual Networks) is not possible, unless sent via a published endpoint on the Azure Load Balancer. This means that any traffic permitted between Tenant A and Tenant B will traverse the Cloud Access Layer and be subject to the same controls and protection as traffic originating from the Internet. As such, the Azure IDS/IPS Layer is designed to not only withstand attacks from the Internet, but also to protect your data from other Azure tenants.
This is worth keeping in mind when working with hybrid deployments of PaaS and IaaS, or integrating multiple applications configured in isolated Private Networks. As this traffic is effectively going via the Internet (albeit within the Microsoft private infrastructure), any data sent in this manner should be encrypted at all times.
A good Microsoft article covering details of this and other topics regarding securing Virtual Networks, is the Microsoft Azure Network Security whitepaper (Version 3, Published February 2015)
In my next post, I’ll go into more detail around designing your Azure network and cover some of the basics for providing secure connectivity to your on-premise environment.
Until next time, happy Cloud spotting!
Kevin is a passionate and driven IT consultant with over a decade of experience in designing and implementing data centre infrastructure… he also has a passion for the coast, and loves kitesurfing!