Planning Vnet subnet segmentation
To provide isolation within a Vnet, we can divide it into one or more subnets. Subnets are primarily used for workload segmentation (logical perimeters within a Vnet). Figure 1.8 shows an example of this. In the diagram, we have a Vnet with two subnets. Web services are deployed into their own subnet (Web tier Subnet) and data services are deployed into their own subnet (Data tier Subnet).
With this approach, we can use an Azure route table to control how traffic is routed between the subnets. We can also use a network security group (NSG) or a network virtual appliance (NVA) to define allowed inbound/outbound traffic flow from/to the subnets (segments). The result of this is that if a part of our application stack is compromised, we are better placed to contain the impact of the security breach and mitigate the risk of lateral movement through the rest of our network. This is an important Zero Trust principle implementation. We will cover route tables, NSGs, and NVAs later in this book.
Figure 1.8 – Segmentation using subnets
How many subnets can Azure VNet have? It can have up to 3,000 subnets! Each subnet must have a unique IP address range that is within the defined IP address spaces of the Vnet (overlap is not allowed). For example, a Vnet with an IPv4 address space of 10.1.0.0/16 cannot have a subnet with an IP address range of 10.1.1.0/24 and another subnet with an address range of 10.1.1.0/25 as these ranges overlap with each other. Attempting to do so will result in the error message shown in Figure 1.9:
Figure 1.9 – Subnets with overlapping addresses not allowed
After defining the IP address range for a subnet, Azure reserves five IP addresses within each subnet that can’t be used! The first four IP addresses and the last IP address in an Azure subnet cannot be allocated to resources for the following reasons:
x.x.x.<first address>: This is reserved for protocol conformance as the network addressx.x.x. <second address>: This is reserved by Azure for the default gateway of the subnetx.x.x. <third address>andx.x.x. <fourth address>: This is reserved by Azure to map the Azure DNS IPs to the Vnet spacex.x.x. <last address>: This is reserved for protocol conformance as the broadcast address (even though Azure Vnets don’t use broadcasts as we mentioned earlier)
For example, if the IP address range of your subnet is 10.1.0.0/24, the following addresses will be reserved:
- 10.1.0.0: Network address
- 10.1.0.1: Default gateway address
- 10.1.0.2 and 10.1.0.3: Used to map Azure DNS IPs to the Vnet space
- 10.1.0.255: Broadcast address
This leaves a total of 250 addresses that can be allocated to subnet resources: 10.1.0.4 – 10.1.0.254. Because of the required address reservation, the smallest supported IPv4 address prefix is /29, which gives five reserved addresses and three usable addresses. Specifying anything less leaves zero usable IPv4 addresses, which results in the error message shown in Figure 1.10:
Figure 1.10 – The smallest supported IPv4 address prefix for a subnet is /29
Note
The smallest supported size for an Azure IPv4 subnet is /29. The largest is /2.
If you are implementing a dual-stack design, the standard size of the assigned IPv6 address space should be /64. This is in line with the standard defined by the IETF. A /64 space is the smallest subnet that can be used locally if auto-configuration is desired. Any attempt to add an IPv6 address space that is not a /64 will result in the error message shown in Figure 1.11:
Figure 1.11 – Only a /64 address space assignment allowed for a subnet
When planning your subnets, make sure that you design for scalability. Workloads in your subnets should not cover the entire address space, giving you no room to add more workloads if needed. Plan and reserve some address space for the future. Also, take into consideration that some network resources such as the VMSS may need to dynamically add more workloads based on incoming requests. Modifying the IP address range of an Azure subnet that has workloads deployed is no straightforward task. It involves you removing all existing resources! Attempting this will result in the error message shown in Figure 1.12:
Figure 1.12 – The error message when trying to resize a subnet with resources
Working with platform services in subnets
For most organizations, the main services that they will deploy into Azure VNet subnets are infrastructure-as-a-service (IaaS) services such as VMs and VMSSs but there are currently about 23 more services that can be deployed into a Vnet subnet, including platform services such as Azure SQL Managed Instance, App Service, Cache for Redis, and Azure Kubernetes Service. Deploying a supported platform service into a Vnet subnet is referred to as Vnet integration or Vnet injection.
A full list of services that are supported for VNet integration can be found at https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-for-azure-services#services-that-can-be-deployed-into-a-virtual-network.
There are about 25 services that can be deployed into a Vnet subnet, as shown in Figure 1.13:
Figure 1.13 – Various types of services supported for Vnet integration
Most PaaS services that support Vnet integration impose restrictions on the subnets that they can be deployed into, and this should be considered when planning your subnets. Here are some of the restrictions to consider:
- About 14 services require a dedicated subnet — this means that they cannot be combined with other services in the same subnet. For example, a VPN gateway cannot be deployed together with another service in the same subnet – the subnet must be dedicated only to that service!
- Still, on dedicated subnets, some services allow multiple instances of the same service in the same dedicated subnet while some require a dedicated subnet per service instance! For example, the Azure SQL Managed Instance’s service allows multiple instances of the same service to be deployed into the dedicated subnet (Figure 1.14), while the Azure Spring Cloud service requires dedicated subnets per service instance (Figure 1.14):
Figure 1.14 – Two SQL-managed instances in the same dedicated subnet. Spring cloud requires dedicated subnets per instance
- Some platform services require their subnets to be called a specific name. For example, the subnet that the Azure Firewall service is deployed into must be called AzureFirewallSubnet, the subnet that the VPN Gateway service is deployed into must be called GatewaySubnet, and the subnet that the Azure Bastion service is deployed into must be called AzureBastionSubnet. This is required for some automation components relating to the services to work.
- Some platform services require a minimum Classless Inter-Domain Routing (CIDR) block for their subnets. For example, the subnet that the Azure Bastion service is deployed into must have a minimum /26 prefix.
- Some platform services require permissions to establish basic network configuration rules for the subnet that they will be deployed into. The process of assigning this permission is called subnet delegation. For example, when a SQL-managed instance is deployed into a subnet, it automatically creates an NSG and a route table and applies them to that subnet.
The key takeaway here is this – before deploying platform services into subnets, ensure that you follow the guidance in the service documentation regarding the aforementioned considerations to avoid inconsistencies in service functionalities. Always refer to the documentation for up-to-date information: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-for-azure-services#services-that-can-be-deployed-into-a-virtual-network.
Now that you have some understanding of how to plan key aspects of Azure VNet, let us go ahead and get some implementation going!
