Cannot attach existing Public IP to zonal VM – zone constraint mismatch (Regional vs Zone 1)

Hi Ivan Tomio | Supra,

Thanks for reaching out in Microsoft Q&A forum<

Failed to update network interface Failed to update network interface "unifi1927_z1". Error: Compute resource /subscriptions/.../providers/Microsoft.Compute/virtualMachines/... has a zone constraint 1 but the PublicIpAddress /subscriptions/.../providers/Microsoft.Network/publicIPAddresses/... used by the compute resource via NetworkInterface or LoadBalancer has a different zone constraint Regional.

Your new VM is pinned to Availability Zone 1, but your existing Public IP is regional (meaning it has no zone assignment).

Azure doesn’t allow you to attach a regional Public IP to a zonal VM because it would break the zone isolation guarantee. the IP could end up being served from a different zone than your VM, defeating the purpose of zonal deployment. This is why you see that “zone constraint 1 vs Regional” error when trying to attach the IP.

Unfortunately, there’s no way to convert or “upgrade” your existing regional Standard Public IP to make it zonal or zone-redundant while keeping the same IP address. The zone configuration is locked at creation time. Your only supported options are:

• Create a new zone-redundant Standard Public IP (recommended) – This spans all three zones in West Europe, attaches cleanly to your Zone 1 VM, and gives you the best resiliency (the IP survives even if an entire zone goes down). You’ll get a new IP address, so you’ll need to update your DNS records.
• Create a new zonal Standard Public IP in Zone 1 – This matches your VM’s zone exactly and will attach without issues, but you lose resiliency if Zone 1 has an outage.
• Redeploy the VM as regional – If keeping the existing Public IP address is absolutely critical, you can redeploy your new VM without specifying an availability zone. This lets you reuse the old regional IP, but you sacrifice the zonal resiliency you were trying to gain.

For quota-related queries, please raise a new question in the Microsoft Q&A forum, and the concerned team will reach out to you.

Update:

Based on this, the only viable solution seems to be to redeploy the VM as a regional (non‑zonal) VM so that the existing regional Standard Public IP can be associated again. Could you please clarify in detail: How exactly to redeploy a zonal VM as a regional VM Whether this requires creating a new VM from the existing disks, or if a direct redeployment is supported What the Microsoft‑recommended procedure / best practice is for this scenario (official documentation would be appreciated) Additionally, it would be helpful to understand:

• Which resources can be safely reused (OS disk, NIC, managed data disks)
• Any caveats to be aware of to avoid data loss or configuration issues.

You’re right that keeping the existing Public IP locks you into a regional (non‑zonal) VM. Azure simply won’t let a regional Standard Public IP attach to a zonal VM, and there’s no way to “convert” that IP to zonal or zone‑redundant while keeping the same address. So, the only supported path is to rebuild the VM as regional and reuse the existing disks and networking.

There’s no in‑place “change zone to regional” switch on a VM. The zones property is immutable once the VM is created. What you actually do is a controlled rebuild: create a new regional VM that boots from the existing OS disk, reattach the existing NIC (with your precious Public IP still on it), reattach all data disks, validate everything, and then delete the old zonal VM. Microsoft’s own guidance for moving between regional and zonal configurations follows this same “copy‑then‑retire” pattern—you’re just doing it in reverse.

Here’s the practical, production‑safe flow:

1. Deallocate the zonal VM so its disks and NIC are released.
2. (Strongly recommended) Take snapshots or ensure you have a recent backup of the OS disk and all data disks.
3. Create a new VM in West Europe:
   • Set Availability zone to “No infrastructure redundancy required” (i.e., regional).
   • For the OS disk, choose “Use existing disk” and select the current OS managed disk.
   • Use the same VM size/SKU (or a compatible one).
4. Reuse the existing NIC and Public IP:
   • Either attach the existing NIC directly to the new VM, or
   • Recreate the NIC with the same subnet, private IP, NSG, and the existing regional Standard Public IP, then attach that NIC.
5. Reattach all data disks (the existing managed disks) with the same LUNs.
6. Start the new VM, validate boot, network, DNS, application behavior, and data access. Once everything is confirmed working,
7. delete the old zonal VM (not the disks).

You can safely reuse:

• The OS managed disk
• All data managed disks
• The NIC (or a recreated one with identical settings)
• The regional Standard Public IP (this is the whole point)
• NSGs, route tables, subnet, VNet, and any associated identities

Just keep in mind:

• VM extensions (Backup, Monitoring, Custom Script, etc.) are tied to the VM resource, so you’ll need to reconfigure them on the new VM.
• You’re giving up zonal isolation for this VM, so review any SLA or architecture assumptions that depended on it.
• Update any automation (ARM/Bicep/Terraform) that expects a zonal VM to now expect a regional one.

This approach keeps your Public IP unchanged, avoids any DNS updates, and follows Microsoft’s recommended pattern for changing a VM’s availability model.

Reference:

• Public IP addresses in Azure – Availability zone support
• Move Azure VMs from regional to zonal – FAQ
• Associate a public IP address to a VM
• Azure Public IPs are now zone-redundant by default
• i can’t able to assosiate the public ip to the vm - Microsoft Q&A -Similar error.
• Move Azure single-instance virtual machines from regional to zonal availability - Azure Virtual Machines | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.