Azure Subnet Design Best Practices

Designing your Azure Virtual Network (VNet) subnets effectively is a critical step in building a secure, scalable, and manageable cloud infrastructure. Proper subnetting allows for granular control over network traffic, efficient IP address utilization, and simplified security policy implementation.

Key Considerations for Subnet Design

1. IP Address Planning

The most fundamental aspect of subnet design is IP address planning. Each subnet requires a unique private IP address space. Consider the following:

CIDR Blocks: Use Classless Inter-Domain Routing (CIDR) notation for defining your subnet ranges (e.g., 10.0.0.0/24).
Address Space Size: Allocate enough IP addresses for your current needs and future growth. A common starting point is a /24 or /23, but this depends heavily on the number of resources you expect to deploy.
Overlap Avoidance: Ensure that no subnet within your VNet overlaps with another, and that VNet address spaces do not overlap with on-premises networks if you plan to use hybrid connectivity.

2. Granularity and Segmentation

Subnets are the primary mechanism for segmenting your network. This segmentation is crucial for security and management.

Application Tiers: Design subnets based on application tiers (e.g., web tier, application tier, data tier). This allows for specific Network Security Group (NSG) rules to be applied to each tier.
Environment Separation: Create separate subnets or even VNets for different environments (e.g., development, staging, production).
Workload Isolation: Isolate specific workloads or security zones into their own subnets for enhanced security.

3. Reserved IP Addresses

Azure reserves the first four and the last IP address in each subnet's address range for protocol configuration. This means the usable IP addresses are always two less than the total IPs in the subnet. Always account for this when calculating your needs.

4. Service-Specific Subnets

Certain Azure services have specific requirements or recommendations for subnetting:

Azure Bastion: Requires a dedicated subnet named AzureBastionSubnet.
Azure Kubernetes Service (AKS): Often uses dedicated subnets for its nodes and pods.
Azure Firewall: Requires a dedicated subnet named AzureFirewallSubnet.

Best Practice: Dedicated Subnets for Infrastructure Services

It's highly recommended to create dedicated subnets for infrastructure services like Azure Bastion, Azure Firewall, or any shared services. This enhances security and simplifies management.

5. Routing

Subnets are the basis for routing tables. Understanding how traffic flows between subnets and to/from external networks is vital.

Default Routing: Azure provides default system routes for traffic within a VNet and to/from the internet.
User-Defined Routes (UDRs): You can create UDRs to force traffic through network virtual appliances (NVAs) or Azure Firewall for inspection or redirection.

Example Subnet Design

Consider a simple web application with a database:

VNet Address Space: 10.1.0.0/16
Web Tier Subnet: 10.1.1.0/24 (254 usable IPs) - Hosts VMs running web servers. NSGs allow HTTP/S from the internet and access to the App Tier.
App Tier Subnet: 10.1.2.0/24 (254 usable IPs) - Hosts VMs running application logic. NSGs allow access from the Web Tier and to the Data Tier.
Data Tier Subnet: 10.1.3.0/24 (254 usable IPs) - Hosts database servers. NSGs allow access only from the App Tier.
Gateway Subnet: 10.1.254.0/27 (30 usable IPs) - Required if you plan to use a VNet gateway for VPN or ExpressRoute.

                
// Example of defining subnets using ARM templates or Terraform
{
  "type": "Microsoft.Network/virtualNetworks",
  "apiVersion": "2020-07-01",
  "name": "myVNet",
  "properties": {
    "addressSpace": {
      "addressPrefixes": [
        "10.1.0.0/16"
      ]
    },
    "subnets": [
      {
        "name": "WebTierSubnet",
        "properties": {
          "addressPrefix": "10.1.1.0/24"
        }
      },
      {
        "name": "AppTierSubnet",
        "properties": {
          "addressPrefix": "10.1.2.0/24"
        }
      },
      {
        "name": "DataTierSubnet",
        "properties": {
          "addressPrefix": "10.1.3.0/24"
        }
      },
      {
        "name": "GatewaySubnet",
        "properties": {
          "addressPrefix": "10.1.254.0/27"
        }
      }
    ]
  }
}
                
            

Future-Proofing Your Subnet Design

While it's impossible to predict every future requirement, consider these points for long-term flexibility:

Larger Address Spaces: When in doubt, allocate slightly more IP address space than immediately required. It's easier to manage a larger subnet than to re-architect an entire VNet later.
Scalability: Design subnets with future scaling in mind. If an application is expected to grow significantly, ensure its subnet has ample capacity.
Future Services: Anticipate the deployment of new Azure services that might require dedicated subnets.