Skip to main content
performance · azure

Busy VMs with accelerated networking switched off on the NIC

resource types
1
rule IDs covered
1
severity
low

What does ZopNight detect here?

RC-263 fires when a running Azure VM's NIC reports enableAcceleratedNetworking false and either VMNetworkIn or VMNetworkOut peaked at 3 GB or more within a single minute (a sustained 50 MB/s) across a 30-day window. Enabling SR-IOV offload is free, so the recommendation deliberately carries $0 savings.

Signal and threshold

How ZopNight evaluates Busy VMs with accelerated networking switched off on the NIC.
Field Value
Rule IDsRC-263
Categoryperformance
Severitylow
Metricnone — pure configuration read
Sourcevm_accel_network.go

What SR-IOV offload changes for a loaded NIC

Accelerated networking gives the VM single-root I/O virtualization: packets bypass the host’s virtual switch and land directly on the guest NIC. On a machine pushing serious traffic, the practical effect is lower latency, less jitter, and meaningfully less host CPU burned on packet processing, capacity that returns to the application. On a quiet NIC the change is imperceptible, which is exactly why the rule requires proof the NIC is busy before flagging anything.

The busy floor, in the units the metric really carries

Azure Monitor’s Network In/Out Total series is a sum of bytes with a 1-minute native grain. ZopNight’s aggregator requests it at hourly intervals, so each datapoint’s Maximum is the largest single 1-minute byte total inside that hour, and the series peak is the busiest minute of the whole 30-day lookback. The decision floor is 3,000,000,000 bytes per minute, or 50 MB/s sustained for a minute on either direction. An earlier comment mis-read the series as bytes-per-second and understated the implied rate by 60×; the source now documents the conversion explicitly.

Two independent ways it declines to fire

The NIC flag is fail-closed: the discoverer surfaces enableAcceleratedNetworking into metadata as accelerated_networking, and the rule abstains unless that value is an explicit "false". Recommending the toggle on a NIC that already has it would be noise. Metrics are equally strict: no throughput series for the VM, or a peak below the floor, and no recommendation exists. Stopped VMs are skipped before any of this runs.

Verify a NIC’s state from the CLI

Terminal window
az network nic list \
--query "[?enableAcceleratedNetworking==\`false\`].{nic:name, rg:resourceGroup, vm:virtualMachine.id}" \
-o table

Turning it on

Confirm the VM size supports accelerated networking first; most current general-purpose sizes with 2+ vCPUs do. Then update the NIC (az network nic update --accelerated-networking true); some VMs need a brief deallocate/start cycle for the setting to take. Monthly cost appears on the finding as context only, and savings are $0: a performance advisory never fabricates a cost fraction. Detection needs Reader plus Monitoring Reader for the throughput series; ZopNight does not apply this change itself.

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·