The conceptualization and deployment of Azure Virtual Networks (VNets) and their constituent subnets represent the critical first phase of any cloud architectural journey. In the Azure ecosystem, a Virtual Network serves as the primary isolation boundary, providing a logically isolated section of the Azure cloud. By leveraging Terraform, an open-source Infrastructure as Code (IaC) tool, engineers can shift from manual, error-prone portal configurations to version-controlled, repeatable, and scalable network topologies. The ability to define private networking through code ensures that the environment is reproducible across multiple regions or stages, such as development, staging, and production, while eliminating the risk of human configuration drift.

At its core, a VNet allows for the creation of a private IP address space, which acts as the foundation for all subsequent resource deployments. Subnets, which are further subdivisions of the VNet, allow architects to group resources based on their function, security requirements, or operational needs. This segmentation is not merely an organizational preference but a security mandate. By dividing a network into tiers—such as web, application, and database tiers—administrators can implement granular traffic control. When managed through Terraform, these boundaries are defined as distinct resource blocks, ensuring that each segment of the network has a predictable address range and a specific purpose.

The evolution of Terraform modules for Azure networking has seen a transition in methodology. While early iterations relied heavily on the count meta-argument for deploying multiple similar resources, modern standards have shifted toward the for_each loop. This transition is pivotal because count is index-based; removing a resource from the middle of a list can trigger the destruction and recreation of all subsequent resources. In contrast, for_each uses a map of keys, allowing for the addition or removal of specific subnets without disrupting the rest of the network infrastructure. This architectural shift minimizes downtime and reduces the blast radius of configuration changes in production environments.

Fundamental Prerequisites and Environment Setup

Before initiating the deployment of network resources, a specific set of technical prerequisites must be met to ensure the Terraform binary can communicate effectively with the Azure Resource Manager (ARM) API. Failure to align these versions can lead to provider conflicts or the inability to use the latest Azure feature sets.

The following table outlines the mandatory requirements for the environment:

To begin the process, the user must initialize the Terraform environment. This is achieved through the terraform init command, which downloads the necessary Azure provider plugin from the HashiCorp registry and initializes the backend where the state file will be stored. Once initialized, the terraform plan command must be executed. This step is critical for production safety, as it allows the operator to review exactly which resources will be created, modified, or destroyed before any changes are committed to the live Azure environment.

Architecting the Virtual Network Foundation

The Virtual Network (VNet) is the overarching container for all private IP traffic. In Terraform, this is defined using the azurerm_virtual_network resource. The most critical decision during this phase is the definition of the address_space. This is a list of IP address prefixes that the VNet will use.

The selection of the address space has profound long-term implications. If an architect chooses a range that overlaps with another VNet or an on-premises network, it will be impossible to establish VNet peering or VPN gateways later. For instance, using a common range like 10.0.0.0/16 provides 65,536 IP addresses, which is generally sufficient for most enterprise workloads.

The implementation of the VNet is structured as follows:

```hcl

Resource group for networking

resource "azurermresourcegroup" "networking" {
name = "rg-networking-prod-eus"
location = "East US"
tags = {
Environment = "production"
Purpose = "networking"
}
}

Virtual Network

resource "azurermvirtualnetwork" "main" {
name = "vnet-main-prod-eus"
location = azurermresourcegroup.networking.location
resourcegroupname = azurermresourcegroup.networking.name

Address space for the entire VNet

address_space = ["10.0.0.0/16"]

Optional DNS servers (defaults to Azure-provided DNS)

dns_servers = []
tags = {
Environment = "production"
ManagedBy = "terraform"
}
}
```

In this configuration, the azurerm_resource_group acts as the logical grouping for the network assets. By tagging the resource group with Environment = "production", the organization can track costs and apply policy constraints specifically to production traffic. The VNet itself is tied to the resource group's location to ensure low latency between the network and the resources it hosts.

Tiered Subnet Implementation and Logical Isolation

Once the VNet is established, it must be partitioned into subnets. A subnet allows you to divide the VNet into smaller, manageable segments. Each subnet is assigned a specific address prefix that must fall within the VNet's overall address space.

The standard architectural pattern for a secure application is the three-tier approach: a web tier, an application tier, and a database tier. This ensures that the database is never directly exposed to the internet, and the application tier acts as a buffer between the public-facing web servers and the sensitive data layer.

Web Tier Subnet

The web tier is the entry point for external traffic. While it remains private within the VNet, it often requires connectivity to other Azure services.

```hcl

Subnet for web tier

resource "azurermsubnet" "web" {
name = "snet-web"
resourcegroupname = azurermresourcegroup.networking.name
virtualnetworkname = azurermvirtualnetwork.main.name
addressprefixes = ["10.0.1.0/24"]

Enable service endpoints for web tier

service_endpoints = ["Microsoft.Sql", "Microsoft.Storage"]
}
```

The inclusion of service_endpoints is a critical security feature. By specifying Microsoft.Sql and Microsoft.Storage, the traffic from this subnet to Azure SQL or Azure Storage remains on the Azure backbone network rather than traversing the public internet. This reduces the attack surface and improves performance.

Application Tier Subnet

The application tier houses the business logic and processes. It typically communicates with the web tier and the database tier.

```hcl

Subnet for application tier

resource "azurermsubnet" "app" {
name = "snet-app"
resourcegroupname = azurermresourcegroup.networking.name
virtualnetworkname = azurermvirtualnetwork.main.name
addressprefixes = ["10.0.2.0/24"]
service_endpoints = ["Microsoft.Sql", "Microsoft.KeyVault"]
}
```

In this tier, the Microsoft.KeyVault service endpoint is added. This allows the application to securely retrieve secrets, certificates, and keys without exposing the traffic to the public web.

Database Tier and Service Delegation

The database tier is the most restricted zone. Beyond simple IP range isolation, certain Azure services require "subnet delegation." Delegation tells the VNet that a specific subnet is reserved for a specific Azure service, allowing that service to inject its own network configurations.

```hcl

Subnet for database tier

resource "azurermsubnet" "db" {
name = "snet-db"
resourcegroupname = azurermresourcegroup.networking.name
virtualnetworkname = azurermvirtualnetwork.main.name
addressprefixes = ["10.0.3.0/24"]

Delegate this subnet to a specific service

delegation {
name = "mysql-delegation"
service_delegation {
name = "Microsoft.DBforMySQL/flexibleServers"
actions = ["Microsoft.Network/virtualNetworks/subnets/join/action"]
}
}
}
```

The delegation block in the example above is specifically for Azure Database for MySQL flexible servers. By granting the join/action permission, the MySQL service can manage the network interface required for the database to reside within the private subnet. This effectively creates a "Private Subnet," ensuring the database has no public IP address and is only reachable from within the VNet or through a VPN/ExpressRoute.

Dynamic Subnet Orchestration with for_each

For environments that scale to dozens or hundreds of subnets, defining each one as a separate azurerm_subnet resource block becomes unmanageable. To solve this, Terraform provides the for_each meta-argument, which allows for the creation of resources based on a map of configurations.

The following configuration demonstrates how to abstract the subnet definitions into a variable:

```hcl
variable "subnets" {
description = "Map of subnet configurations"
type = map(object({
addressprefix = string
serviceendpoints = list(string)
delegation = optional(object({
name = string
service = string
actions = list(string)
}))
}))
default = {
web = {
addressprefix = "10.0.1.0/24"
serviceendpoints = ["Microsoft.Sql", "Microsoft.Storage"]
}
app = {
addressprefix = "10.0.2.0/24"
serviceendpoints = ["Microsoft.Sql", "Microsoft.KeyVault"]
}
db = {
addressprefix = "10.0.3.0/24"
serviceendpoints = []
delegation = {
name = "mysql-delegation"
service = "Microsoft.DBforMySQL/flexibleServers"
actions = ["Microsoft.Network/virtualNetworks/subnets/join/action"]
}
}
}

resource "azurermsubnet" "dynamicsubnets" {
foreach = var.subnets
name = "snet-${each.key}"
resourcegroupname = azurermresourcegroup.networking.name
virtualnetworkname = azurermvirtualnetwork.main.name
addressprefixes = [each.value.addressprefix]
serviceendpoints = each.value.service_endpoints

dynamic "delegation" {
foreach = each.value.delegation != null ? [each.value.delegation] : []
name = delegation.value.name
servicedelegation {
name = delegation.value.service
actions = delegation.value.actions
}
}
}
```

The use of the dynamic block within the azurerm_subnet resource is essential here. Because not every subnet requires delegation, the dynamic "delegation" block checks if the delegation object exists in the map before attempting to create it. This approach ensures a clean, single-resource block that can scale to any number of subnets simply by updating the subnets variable.

Module Evolution and Deprecation Lifecycle

In the Terraform ecosystem, modules are used to package common patterns. However, as the azurerm provider evolves, older modules may become obsolete. A prime example is the terraform-azurerm-subnets module.

The terraform-azurerm-subnets module was originally designed to deploy a VNet with a set of subnets. However, it has been officially deprecated. The primary reason for this deprecation is the shift in best practices regarding resource iteration. Specifically, the module relied on the count parameter. As previously mentioned, using count for resource lists can lead to catastrophic infrastructure destruction if a resource is removed from the middle of the list, as Terraform shifts the index of all subsequent items.

Users currently utilizing terraform-azurerm-subnets are encouraged to transition to the avm-res-network-virtualnetwork module. The newer AVM (Azure Verified Modules) standard ensures that resources are built following the most current Azure Landing Zone (ALZ) guidelines. For existing infrastructure already deployed with the deprecated module, maintaining the current state is possible, and critical bugs will be patched, but new deployments should avoid it.

The following table compares the count and for_each methods as they relate to module design:

Advanced Connectivity and Observability

A network is only as useful as its connectivity and the visibility into its performance. Beyond the creation of VNets and subnets, a production-ready environment requires the implementation of Network Security Groups (NSGs), VNet Peering, and comprehensive monitoring.

Network Security Groups (NSGs)

While subnets provide IP isolation, NSGs provide the "firewall" logic. An NSG contains a list of security rules that allow or deny inbound and outbound traffic based on source/destination IP, port, and protocol. It is important to note that the terraform-azurerm-subnets module does not create or expose a security group by default. This means security rules must be defined as separate azurerm_network_security_group resources and then associated with the subnets using azurerm_subnet_network_security_group_association.

VNet Peering and Hub-Spoke Architecture

For organizations with multiple workloads, a "Hub-and-Spoke" architecture is recommended. In this model:
- The Hub VNet contains shared services (e.g., Firewalls, VPN Gateways, DNS).
- The Spoke VNets contain the actual application workloads.
- Peering is established between the Hub and each Spoke.

Terraform makes this straightforward by allowing the use of the azurerm_virtual_network_peering resource. Careful planning of address spaces is mandatory here; any overlapping IP ranges between the Hub and Spoke will prevent the peering from being established.

Observability and Monitoring

Deploying the network is only half the battle. Continuous observability is required to ensure that DNS resolution is functioning and that peering states remain healthy. OneUptime and Azure Monitor are the primary tools for this.

By configuring Azure Monitor and Log Analytics via Terraform, engineers can set up alerts for:
- VNet connectivity failures.
- DNS timeout incidents.
- Peering state changes.

Catching a DNS timeout or a peering failure early through an automated alert can save hours of debugging time and prevent downstream service outages. This observability layer should be integrated into the Terraform code from day one to ensure that the infrastructure is not only deployed but also managed.

Conclusion: Strategic Analysis of Infrastructure as Code in Azure Networking

The transition from manual network configuration to Terraform-driven orchestration represents a fundamental shift in how cloud environments are managed. By treating the network as code, organizations gain the ability to version their topology, audit every change through pull requests, and deploy entire environments in minutes rather than days.

The technical journey begins with the foundational azurerm_virtual_network, which defines the boundary of the private cloud. The subsequent division into subnets—specifically the implementation of tiered architectures for web, application, and database layers—establishes the first line of defense. The use of service endpoints and subnet delegation further hardens this security posture by ensuring that traffic to critical services like Azure SQL or Key Vault never touches the public internet.

The evolution from count to for_each highlights a broader trend in IaC: the movement toward immutable, key-based identification of resources. This ensures that the infrastructure is resilient to changes and scalable without the risk of accidental resource destruction. Furthermore, the shift toward Azure Verified Modules (AVM) indicates a move toward standardized, industry-approved blueprints that reduce the cognitive load on DevOps engineers.

Ultimately, the success of an Azure networking strategy depends on the foresight applied during the planning phase. Overlapping address spaces, neglected NSG associations, and a lack of integrated monitoring are common pitfalls that can lead to catastrophic failures. However, by utilizing the deep-drilling approach to Terraform configuration—where every subnet is logically mapped, every service endpoint is explicitly declared, and every resource is monitored—architects can create a robust, secure, and highly available foundation upon which all other cloud services can thrive. The investment in a correctly architected network today pays dividends in the form of reduced technical debt and increased operational stability for the entire lifecycle of the application.

Sources

1. Azure Terraform Subnets GitHub
2. Terraform Pilot Azure Networking
3. OneUptime Azure VNet Guide
4. Microsoft Learn Azure Private Subnet Q&A