Production VMs placed in no availability set and no availability zone
What does ZopNight detect here?
Azure Resource Graph surfaces each VM's availabilitySet.id and zones; when both are empty on a production-classified VM, ZopNight fires RC-1306 because the compute SLA drops from 99.99% to 99.9% for single-instance placement. Remediation means recreating the VM, since availability set membership cannot be changed after creation.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1306 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | vm_availability.go |
Where it applies
One planned maintenance event from downtime
A production VM outside any availability set or zone shares fault and update domains with nothing, which means it shares them with everything. When Azure drains the host for planned maintenance, or the host fails, that workload is simply down until the platform heals it. Spreading two or more instances across fault domains is what turns a host event into a non-event, and Azure’s compute SLA reflects the difference: 99.99% for zone-spread instances, 99.9% for a lone VM on premium storage.
The evidence chain: name, tag, then the ARG flag
Production classification is evidence-based: the VM’s name matches a production pattern or
it carries an env=prod tag. An untagged dev box is no longer misclassified as production
by default, which an earlier name-negation approach did. Placement itself is read from the
discoverer’s availability_set_configured metadata flag, derived in Azure Resource Graph
from the VM’s availabilitySet.id and zones properties. The rule fires only when the
provider authoritatively reports "false" (no availability set and no zone) and abstains
when the flag is absent.
Scale-set members: excluded, with one honest gap
A VM inside a scale set already inherits fault-domain or zone spread, so flagging its members individually would be a false compliance claim. Uniform-orchestration members are recognised by their nested resource ID and excluded. Flexible-orchestration members, however, have flat resource IDs indistinguishable from standalone VMs in today’s metadata, so a regional Flex member can still draw a false positive until the discoverer stamps scale-set membership. The gap is documented in the rule source rather than papered over.
List production VMs with no HA placement
az vm list \ --query "[?availabilitySet==null && (zones==null || length(zones)==\`0\`)].{name:name, rg:resourceGroup, size:hardwareProfile.vmSize}" \ -o tableCross-reference the output against your production tags before acting on it.
Why fixing it means rebuilding
Availability set membership is set at creation time and is immutable afterwards. The remediation is to recreate the VM with the same disks in a new placement, inside an availability set or a zone, or to fold the workload into a scale set and let it manage the spread. Reader alone reproduces the entire detection; ZopNight performs no write for this rule.