A method to ensure Express Route Connections are not removed with vwanConnectivity module

[DavidLHannah]

Describe the feature end to end, including deployment scenario details under which the feature would occur.

We need a method where we can ensure that ExpressRoute Connections are not removed when redeploying our code, when using the vwanConnectivity module.

After we have deployed an Azure vWAN infrastructure via vwanConnectivity, we may use the hubPeeredSpoke orchestration module or some other method to peer vNets to our vWAN. When we redeploy the vwanConnectivity code , peering to our vNets does not get removed and network connectivity remains active between spokes during the deployment process.

In a production environment, we'd expect the expressRouteConnections should survive an updated deployment that does not explicitly nullify the connections. There should be a similar type of continuity for the ExpressRoute Connections.

Why is this feature important. Describe why this would be important for your organization and others. Would this impact similar orgs in the same way?

Our infrastructure includes the use of the vwanConnectivity module, deploying a vWAN Virtual Hub along with an ExpressRoute Gateway.

When redeploying our code, ExpressRoute Connections which have been added to our ExpressRoute Gateway get removed. This appears to occur because the resErGateway resource does not include the expressRouteConnections parameter.

Even if we decide to deploy an expressRouteConnections resource in subsequent code, the initial deploy of vwanConnectivity module will cause down-time between Azure and our ExpressRoute sites until the expressRouteConnections is deployed.

We need to be able to deploy updates to our vWAN environment via IaC without causing this kind of unnecessary downtime. This may be similar, or related to the issue discussed in #727 .

The VPN Gateway may benefit from a similar enhancement as well.

Can you describe any alternatives that you have taken since this feature does not exist?

Using a read only Resource Lock on the ExpressRoute Gateway will successfully prevent the removal of the Connections, but the deployment may otherwise fail due to the lock.

Feature Implementation

• We could potentially provide the expressRouteConnections parameter on the Hub object and pass it to the ExpressRoute Gateway. Although I am not sure if a scenario like this could improperly involve a reference loop.
• Some other Flag or Switch that would alter logic in the vwanConnectivity module, potentially reference the existing ExpressRoute Gateway?

Check previous GitHub issues

• I have searched the issues for this item and found no duplicate

Code of Conduct

• I agree to follow this project's Code of Conduct

[DavidLHannah]

Following up here with additional detail.

I was initially running into this issue while using a previous version of ALZ-Bicep. This was done by including the vwanConnectivity among a larger infrastructure which would also create a Resource Lock. Noticing that Resource Lock functionality had since been added, I updated to release v0.17.2 as well as the fix on this issue #743

When utilizing a ReadOnly resource lock on the ExpressRoute Gateway, we will need to set the lock kind to Delete before adding our required ExpressRoute Connection, then set the kind back to ReadOnly.

Upon deploying unrelated updates that are part of the larger infrastructure included in the vwanConnectivity module, the deployment will not affect our existing ExpressRoute Connections, as desired. However, the deployment ultimately fails.

This is as expected, producing the ScopeLocked error. There is still a need here for us to be able to deploy environment updates via IaC, without causing down-time due to the removal of the ExpressRoute Connections.

[oZakari]

Hey @DavidLHannah, thanks for providing all of the details and sorry for a frustration! I am looking into to see if we can add a ternary null value or potentially make use of the contains function so that the express route connections property won't try to revert your configuration. You can then incorporate the https://github.com/Azure/bicep-registry-modules/tree/main/avm/res/network/connection resource to provision the ExpressRoute Connection resource.