I found in the azure virtual network deployment using automation-api that when I run the stack repeatedly, there is a phenomenon that the resources are rebuilt. In fact, I have not changed the network configuration. My output is as follows： Refreshing (network): ~ pulumipulumiStack pulumi-prod-network refreshing pulumipulumiStack pulumi-prod-network running ~ azure-nativeresourcesResourceGroup cnn3-pulumi-network-rg refreshing ~ azure-nativenetworkRouteTable cnn3-pulumi-prod-app-rb01 refreshing ~ azure-nativenetworkVirtualNetwork cnn3-pulumi-prod-vnet01 refreshing ~ azure-nativenetworkSubnet app-subnet refreshing ~ azure-nativenetworkRouteTable cnn3-pulumi-prod-db-rb01 refreshing ~ azure-nativenetworkSubnet db-subnet refreshing ~ azure-nativenetworkNetworkSecurityGroup cnn3-pulumi-prod-app-nsg01 refreshing ~ azure-nativenetworkNetworkSecurityGroup cnn3-pulumi-prod-db-nsg01 refreshing azure-nativeresourcesResourceGroup cnn3-pulumi-network-rg ~ azure-nativenetworkRouteTable cnn3-pulumi-prod-app-rb01 updated [diff: +subnets~etag] azure-nativenetworkSubnet app-subnet ~ azure-nativenetworkVirtualNetwork cnn3-pulumi-prod-vnet01 updated [diff: ~etag,subnets] ~ azure-nativenetworkNetworkSecurityGroup cnn3-pulumi-prod-db-nsg01 updated [diff: +subnets~defaultSecurityRules,etag] ~ azure-nativenetworkNetworkSecurityGroup cnn3-pulumi-prod-app-nsg01 updated [diff: +subnets~defaultSecurityRules,etag] ~ azure-nativenetworkRouteTable cnn3-pulumi-prod-db-rb01 updated [diff: +subnets~etag] azure-nativenetworkSubnet db-subnet pulumipulumiStack pulumi-prod-network Resources: ~ 5 updated 4 unchanged Duration: 5s Refreshing (resources): ~ pulumipulumiStack pulumi-prod-resources refreshing pulumipulumiStack pulumi-prod-resources running pulumipulumiStack pulumi-prod-resources Resources: 1 unchanged Duration: 1s E0516 012010.189403400 5621 socket_utils_common_posix.cc:223] check for SO_REUSEPORT: {"created":"@1652635210.189353600","description":"Protocol not available","errno":92,"file":"src/core/lib/iomgr/socket_utils_common_posix.cc","file_line":202,"os_error":"Protocol not available","syscall":"getsockopt(SO_REUSEPORT)"} E0516 012010.193124300 5621 fork_posix.cc:76] Other threads are currently calling into gRPC, skipping fork() handlers Updating (network): pulumipulumiStack pulumi-prod-network running azure-nativeresourcesResourceGroup cnn3-pulumi-network-rg ~ azure-nativenetworkVirtualNetwork cnn3-pulumi-prod-vnet01 updating [diff: -subnets] ~ azure-nativenetworkVirtualNetwork cnn3-pulumi-prod-vnet01 updated [diff: -subnets] azure-nativenetworkNetworkSecurityGroup cnn3-pulumi-prod-app-nsg01 azure-nativenetworkRouteTable cnn3-pulumi-prod-app-rb01 azure-nativenetworkNetworkSecurityGroup cnn3-pulumi-prod-db-nsg01 azure-nativenetworkRouteTable cnn3-pulumi-prod-db-rb01 azure-nativenetworkSubnet app-subnet azure-nativenetworkSubnet db-subnet pulumipulumiStack pulumi-prod-network Resources: ~ 1 updated 8 unchanged Duration: 10s E0516 012026.896494800 5621 fork_posix.cc:76] Other threads are currently calling into gRPC, skipping fork() handlers E0516 012028.804288700 5621 fork_posix.cc:76] Other threads are currently calling into gRPC, skipping fork() handlers E0516 012030.265914000 5621 fork_posix.cc:76] Other threads are currently calling into gRPC, skipping fork() handlers network update summary: { "same": 8, "update": 1 }

Are you subnets nested in the virtual network or separate?

subnet is separate and it references the name of the vnet.

Azure resource manager (ARM) has a well known bug that has been around since the invention of ARM. Creating subnets separate from the vnet will cause the behavior your are seeing. This happens with ARM templates and bicep too because we all call the same API. Just nest the subnets inside the vnet.

@clean-truck-93285 Thanks for the reply, will there be a fix plan for this bug? Because for automation, we will rely on templates to flexibly change the subnet by passing parameters. If the nested definition in vnet lacks the corresponding flexibility, or do you have any suggestions here to declare subnet in vnet and pass the same Template loop to create subnet in same vnet.

I doubt Microsoft cares at this point. Here the GitHub issue I see the most when searching forums. https://github.com/Azure/azure-quickstart-templates/issues/2786 Also note I don't work for Pulumi or Microsoft. I just a cloud engineer that encountered this problem before. Thinking you could make an array outside of the vnet, save to a variable, and put that inside the vnet. Never tried but might work.