NAT Gateway occasionally looses network settings

Microsoft does not document NAT Gateway subnet associations as periodically resetting by themselves, so first identify the subnet write that removed natGateway.id; then correct the responsible deployment or identity and alert on future subnet updates.

1. Identify what removed the association

The association is stored on the subnet, not only on the NAT Gateway resource. Removing it is a managed subnet update—for example, Azure CLI removes it with az network vnet subnet update --remove natGateway. ^1^

1. Open Azure portal → Virtual networks → vnet01 → Activity log.
2. Set the time range to when the association disappeared.
3. Filter for:
   • Resource: subnet_ContainerInstances, where available
   • Operation: Create or Update Subnet / Microsoft.Network/virtualNetworks/subnets/write
   • Also check Create or Update Virtual Network, because some tools submit the subnet as part of a VNet update.
4. Open each event and inspect:
   • Event initiated by
   • Correlation ID
   • Change history, especially whether the subnet’s NAT Gateway property changed from its resource ID to empty/null.

Activity Log records control-plane create, update, and delete operations automatically. Entries normally become available within 3–20 minutes and remain for 90 days; export them through a diagnostic setting if longer retention is required. Change history can show property values before and after an operation. ^2^

If the event is no longer in Activity Log, use Azure portal → Change Analysis and filter for the VNet/subnet. Change Analysis automatically collects resource snapshots. ^3^ Resource Graph change records can identify changedBy, clientType, and operation, but their resource-configuration change window is shorter than Activity Log retention. ^4^

2. Prevent recurrence

Once the initiating identity or client is known:

• IaC or automation: Ensure every template that redeploys vnet01 or subnet_ContainerInstances includes the expected NAT Gateway association. A deployment that submits the subnet without that property is the first item to correct.
• Access control: Remove unnecessary subnet write permissions. Grant network administrators the least-privilege Network Contributor role rather than broader Contributor access. ^5^
• Deployment ownership: Manage the VNet, subnet, and association from one authoritative IaC workflow to avoid competing deployments overwriting the same subnet.
• Locks: A Delete/CanNotDelete lock does not prevent modification, so it will not protect this association. A Read-only lock blocks control-plane updates, but it can also block legitimate ACI or subnet lifecycle operations; test it before using it on this delegated subnet. ^6^

If no user, service principal, deployment, policy, or tool operation appears around the incident, preserve the timestamps, correlation IDs, subnet resource ID, and Change Analysis output and open an Azure support case. The public NAT Gateway troubleshooting guidance does not list spontaneous subnet-association loss as a known issue. ^7^

3. Alert when the subnet is changed

Create an Activity Log alert for the subnet write, with a broader VNet-write alert as supplemental coverage:

1. Go to Monitor → Alerts → + Create → Alert rule.
2. Scope it to vnet01 or, if selectable, subnet_ContainerInstances.
3. Under Condition, select an Activity Log administrative signal.
4. Select Create or Update Subnet / Microsoft.Network/virtualNetworks/subnets/write.
5. Under Actions, create or select an action group for email, SMS, webhook, Logic App, or Azure Function notification.
6. Create a second rule for Create or Update Virtual Network if your deployment tooling updates subnets through the parent VNet.
7. Enable the rules and perform a controlled subnet update to verify delivery.

Creating the alert requires read access to the target, write access to the alert rule’s resource group, and read access to its action group. ^8^

This alerts on every matching update, not specifically on the association becoming empty.

4. Detect the exact missing state

Use Azure Resource Graph Explorer to check whether the subnet currently references the expected NAT Gateway:

resources
| where type =~ "microsoft.network/virtualnetworks/subnets"
| where name =~ "vnet01/subnet_ContainerInstances"
| extend natGatewayId = tostring(properties.natGateway.id)
| where isempty(natGatewayId)
   or natGatewayId !endswith "/InternetGateway_AzureContainerInstances"
| project id, name, resourceGroup, natGatewayId

A returned row means the association is absent or points to a different NAT Gateway. Resource Graph supports filtering resource properties at subscription scale. ^9^

Resource Graph queries do not send notifications by themselves. For exact-state notification, run this query on a schedule from an authorized Logic App, Function, or automation job and invoke an Azure Monitor action group or webhook when it returns a row. Keep the Activity Log alert as the immediate notification and the scheduled query as protection against missed or unexpected state changes.

References

1. Manage a NAT gateway - Azure NAT Gateway | Microsoft Learn
2. Activity log in Azure Monitor
3. View resource changes in the Azure portal
4. Get resource changes
5. Secure your Azure NAT Gateway deployment
6. Lock your Azure resources to protect your infrastructure
7. Troubleshoot Azure NAT Gateway - Azure NAT Gateway
8. Create or edit an activity log, service health, or resource health alert rule
9. What is Azure Resource Graph?