Terraform Module: azurerm-alz-subnet

In September last year, I wrote a Terraform Module called azurerm-alz-subnet and released it to v1.0 the purpose of the module is to help deploy the subnet with the network security group and route table associated as a workaround to the azurerm_subnet resource so it doesn’t conflict with the Azure Landing Zone policies “Subnets should have a Network Security Group” and “Subnets should have a User Defined Route” which are commonly used in Azure Landing Zone Ref. Architecture.

This module has gotten quite attention as a great workaround to the issues that the native azurerm_subnet resource has with the Azure API and conflicts with these policies.

Last month I had an issue with the module, and now I’m releasing version 2.0 of this module based on the issue, input from one of the module users around having the ability to use the existing resource group instead of creating a new one for the network resources, and some other improvements.

v2.0.0 release of the Terraform module

Check out v2.0.0 here.

But don’t go far, I want to continue with this post a little bit further and would like to pinpoint why I saw the need for creating this module, so let’s dig in.

Why was this module created?

One might wonder why not just use the terraform resource azurerm_subnet to deploy the subnet within the virtual network deployed by the e.g. Azure Landing Zone vending module?

That is because it’s known for having a bug that conflicts with these deny policies due to how the resource is designed, and how it’s not able to associate the Network Security Group (NSG) and the Route Table (RT) to the subnet when the resource is deployed, due to those restrictions in the resource it needs to use separate resources for that action azurerm_subnet_network_security_group_association and the azurerm_route_table_association but unfortunately that conflicts with the Deny policies and doesn’t allow you to create the subnet.

The only way to deploy a subnet that doesn’t conflict with these policies is to use the azurerm_virtual_network resource to deploy the subnet and reference the network security group, and the route table in one API call.

However, that only resolves part of the problem as the azurerm_virtual_network resource doesn’t support complex configurations on the subnet like Subnet Delegation, Service Endpoints, and Private link-/ endpoint network policies

In addition, it prevents autonomous work teams/owners/contributors of their Landing Zone from creating a subnet within their code repository, and constant need to involve the Platform Team to create the subnets for the landing zones.

Issues that have been previously posted and resolved with workarounds on this bug when creating a subnet while adhering to these policies.

These GitHub issues have been around since mid-2019, say whaaat! some of them have been resolved with workarounds, workaround similar to what is being used in this module, and some are still open.

• ▶️ Feature Request: Subnets defined in-line within the Virtual Network resource doesn’t support all parameters #3917
• ▶️ Example of using the Subnet Association resources with Azure Policy #9022
• ▶️ Unable to create subnet due to Azure policy deny subnet with NSG, need NSG parameter #16952
• ▶️ Support for azurerm_subnet to configure route table association, nsg association #16921

Conclusion

In conclusion, the reason this module was created in the first place is because the native resources in Terraform azurerm provider are still having issues and conflicts with Azure Policies and a proper workaround was needed.

As always, leave a comment below, make sure to hit that like button if you liked this post, and don’t forget to subscribe so you don’t miss out on future posts.