September last year I wrote a Module called azurerm-alz-subnet and released it to v1.0 the purpose of the module is to help deploying subnet with network security group and route table associated as 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 a quite attention as a great workaround to the issues that the native azurerm_subnet resource has with the Azure API and conflicting with these policies.
Last month I got an issue on 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 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
But don't go far, I want to continue with this post little bit further and would like to pin point 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 resouce 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 resouce 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 the part of the problem as the azurerm_virtual_network resouce doesn't support complex configurations on the subnet like Subnet Delegation, Service Endpoints and Private link-/ endpoint network policies
In addition to prevent autonomous work teams/owners/contributors of their Landing Zone to create a subnet within their own code repository, and constant need to involve the Platform Team to create the subnets for the landing zones.
Issues that have been previously been posted and resolved with workarounds on this bug when creating subnet while adhearing 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.
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.
