由于可用区限制，无法将动态 IP 分配给我的虚拟机

Question

I wanted to change my Static Public IP into a Dynamic one in order to reduce cost. So i deleted the Static IP and created a new one with Dynamic allocation. So far so good. The thing now is that when i try to assign the public IP to my VM i get this error

Failed to save IP address changes for network interface 'deployment1477'. Error: Compute resource deployment1 has a zone constraint 1 but the PublicIPAddress deployment_ip used by the compute resource via NetworkInterface or LoadBalancer has a different zone constraint Regional.

What i found is that my VM has a availability zone constraint. It's not the Region, but it's the availability zone which is set to 1. I couldn't find an easy way to just change that setting somehow. So as of now i cannot assign a dynamic Public IP address to my VM.

Here is a screenshot of what i mean by availability zone constraint which could be found in the Overview (main page) page of your VM:

Answer 1

Why this is happening?

At the very base, you need to understand the difference between a regional service and a zone-redundant service. An Azure Basic Public IP is a regional service . That means if you create an IP address, it can be taken from ANY Data Center within a specific region.

A Standard SKU Public IP is a zone-redundant service, which means that the service will only exist in the specified zones, replicating across each other, to ensure availability of your services if one zone is unavailable.

This link explains the terminologies and also public IP SKU specifications. Extract below:

Basic SKU: If you are creating a public IP address in a region that supports availability zones, the Availability zone setting is set to None by default. Basic Public IPs do not support Availability zones. Standard SKU: A Standard SKU public IP can be associated to a virtual machine or a load balancer front end. If you're creating a public IP address in a region that supports availability zones, the Availability zone setting is set to Zone-redundant by default.

So here, your VM belongs to an availability zone, but the Basic IP address does not belong to a specific zone but to a region instead.

This is why the error says: ...Compute resource deployment1 has a zone constraint 1... and the PublicIPAddress deployment_ip...has a different zone constraint Regional.

This Azure Documentation provides all limitations of public IP addresses.

What are your options?

Scenario 1

You need to access the VM (or an application on the VM) through the Public IP.

Option 1 - (If you cannot delete the VM)

Use a Basic Load Balancer , with a Basic SKU IP, to route traffic to the VM but also provide Source NAT for outbound connection . Azure Basic Load Balancer is free. Standard Load Balancers require additional configuration for SNAT setup.

1. Create a Basic Load Balancers and assign a basic SKU IP to it.
2. Configure your VM as the backend pool. Instead of using the NIC as the Backend Pool Configuration , use the VM's private IP address.
3. Configure the load balancing rules to route traffic on required ports (eg Port 3389 , or Port 80 ).
4. Configure the health probe for the VM to pass the health check and send traffic to the backend.

Option 2 - (If you can rebuild the VM)

1. Detach the OS disk (and Data disks if applicable) from the VM.
2. Delete the VM (compute only) resource.
3. Create a new VM that you will not put in an Availability Zone, with a Basic SKU public IP address and Dynamic Allocation mode.
4. Once VM created, head to the Disks tab and go for Swap OS disk while specifying the OS disk from the original VM.

An alternative (proper but more complex) to Option 2 would be to take a Snapshot of the OS disk, and then when you're on the Snapshot, Create disk , then from the disk - Create VM , and parse all the VM parameters.

Scenario 2

The VM only needs outbound internet access and you do not need to remote in or access an application through its public IP.

You can just get rid of the public IP address. All VMs in Azure have internet access by default. Couldn't find a Microsoft Document on it but here's someone else mentioning it .

You will often encounter a lot of complex/frustrating scenarios when working with some Azure products. It's always evolving hence you should always take a look at current limitations to see whether a setup fits your scenario. There are simple issues which have been raised more than 5 years ago that are still unresolved.