Subnets
Integrating Azure resources into a virtual network requires a subnet. Subnets are used to divide the VNet IP space. Different subnets can have different network security and routing rules, so applications and application tiers can be isolated and network flows between them can be controlled. For example, consider a typical three-tier application architecture compris- ing a web tier, an application tier, and a database tier. By implementing each tier as a separate subnet, you can control precisely which network flows are permitted between tiers and from the internet.
Azure reserves a few IP addresses from each subnet. Like standard IP networks, Azure reserves the first and last IP addresses in each subnet for network identification, broadcast. Additionally, it reserves another three addresses at the beginning for the range for internal Azure services, for a total of five unusable IP addresses.
You are required to define one subnet when creating a VNet using the Azure portal. VNets can typically have multiple subnets, and you can add new subnets to your VNet at any time.
You can’t change the address range if there are resources already associated with or deployed to the subnet. If you want to make a change to a subnet’s address range, you first must delete all the objects in that subnet. If the subnet is empty, you can change the range of addresses to any range that is within the address space of the VNet not assigned to any other subnets.
Subnets can be deleted from VNets only if they are empty. Once a subnet is deleted, the addresses that were part of that address range are released and available again for use within new subnets that you create.
Additional virtual network settings
So far, this section has focused on the most important settings of each VNet and subnet: the IP address ranges. There are some additional settings and features of VNets and subnets to be aware of. Table 4-1 provides a summary of a few settings supported by virtual networks.
TABLE 4-1 Properties of a virtual network
| Property | Description |
| Name | The VNet name must be unique within the resource group, have between 2 and 64 characters and may contain letters (case insensitive), numbers, underscores, periods, or hyphens. It must start with a letter or number and end with a letter, number, or underscore. |
| Location | Each VNet is tied to a single Azure region and can only be used by resources (such as virtual machines) in the same region. |
| Address Space | An array of IP address ranges available for use by subnets. |
| DNS settings | Contains an array of DNS servers. If specified, these DNS servers are configured on virtual machines in the virtual network in place of the Azure-provided DNS servers. |
| Subnets | The list of subnets configured for this VNet. |
| Peerings | The list of peerings configured for this VNet. Peerings are used to create network connectivity between separate VNets. |
Table 4-2 provides a summary of the settings supported by virtual network subnets.
TABLE 4-2 Settings of a virtual network subnet
| Property | Description |
| Name | The subnet name must be unique within the VNet. It must have between 2 and 80 characters and may contain letters (case insensitive), numbers, underscores, periods, or hyphens. It must start with a letter or number and must end with a letter, number, or underscore. |
| Address Range | The IP address range for a subnet, specified in CIDR notation. All subnets must sit within the VNet address space and cannot overlap. |
| Network Security Group | Reference to the network security group (NSG) for the subnet. NSGs can be associated to a subnet and are used to control which inbound and outbound traffic flows are permitted. |
| Route Table | Route table applied to the subnet and used to override the default system routes. These are used to send traffic to destination networks that are different than the routes that Azure uses by default. |
| Service Endpoints (And Policies) | An array of service endpoints for this subnet. Service endpoints provide a direct route to various Azure PaaS services (such as Azure Storage), without requiring an internet-facing endpoint. Service endpoint policies provide further control over which instances of those services may be accessed. |
| Delegations | An array of references to delegations on the subnet. Delegations allow subnets to be used by certain Azure services, which will then deploy managed resources (such as an Azure SQL Database Managed Instance) into the subnet. Access to these resources is private and can be controlled using NSGs. Delegations also support access to and from on-premises networks when hybrid networking is used. |