By 30th September 2025, Basic SKU public IP addresses will be officially retired. Although the Azure Updates note states that existing Basic SKU public IP addresses won’t be affected immediately, all Microsoft Learn articles emphasize the importance of migrating before 30th September 2025. To add to this urgency, new Basic SKU addresses haven’t been able to be created since 31st March 2025.
If you haven’t migrated yet, don’t panic—as there are still some scenarios where Basic SKU IP addresses will be supported by Microsoft until 2026. Rest assured, Microsoft isn’t pulling the plug immediately on already deployed Basic SKU IP addresses. At least I hope so and as of today, some customers of mine still work with Basic SKU public IP addresses to be honest.
In this blog post, you’ll learn about the retirement of Basic SKU public IP addresses, the functionality of public IPs in Azure, the migration process from Basic SKU to Standard SKU, and my personal experiences and challenges during this transition, particularly when migrating VPN Gateway with Basic SKU
What are Azure public IP addresses
Public IP addresses in Azure enable Internet resources to communicate inbound and allow Azure services to interact with the Internet and public-facing services. These addresses are dedicated to specific resources until unassigned, while dynamic IP addresses are automatically assigned for outbound communication, although they can change over time. In Azure Resource Manager, public IP addresses are distinct resources with their own properties and can be associated with various resources including:
- Virtual machines
- Virtual Machine Scale Sets
- Azure Load Balancers
- VPN/ER gateways
- NAT gateways
- Application Gateways
- Azure Firewalls
- Bastion Hosts
- Route Servers
- API Management
Azure public IP addresses are / were “available” in Standard or Basic SKUs (retired yesterday; but you still find them), which determine their functionality, allocation method, feature support, and associated resources. Historically, Basic SKU public IP addresses were the default choice for provisioning services such as VPN Gateways (depending on the SKU) and Just-in-time access on virtual machines. However, in line with Microsoft’s “security by default” initiative, Basic SKU public IP addresses have been retired.
Basic SKU Vs. Standard SKU
Here are some key differences between these two SKUs you have to be aware of after the migration:
Aspect | Standard SKU public IP | Basic SKU public IP |
---|---|---|
Allocation method | Static | For IPv4: Dynamic or Static; For IPv6: Dynamic |
Security | Secure by default with restricted inbound traffic. Network security group required | Open by default. Network security groups recommended but optional |
Availability zones | Supported (nonzonal, zonal, zone-redundant). Zone redundant IPs only in regions with three availability zones. | Not supported |
Routing preference | Supported for more granular traffic control | Not supported |
Global tier | Supported via cross-region load balancers | Not supported |
Standard Load Balancer support | Both IPv4 and IPv6 are supported | Not supported |
NAT Gateway support | IPv4 is supported | Not supported |
Azure Firewall support | IPv4 is supported | Not supported |
Allocation method
This refers to how IPs are assigned. Static allocation means the IP address remains the same unless manually changed, while dynamic allocation can change over time. Basic SKU supports both static and dynamic allocation for IPv4, and dynamic only for IPv6, whereas Standard SKU uses static allocation for better predictability and management.
Security
Standard SKU IPs are secure by default, meaning inbound traffic is restricted unless specifically allowed via network security groups. Basic SKU IPs, on the other hand, are open by default, requiring you to add network security groups to restrict traffic if needed.
Availability zones
Standard SKU IPs support various zone configurations such as nonzonal, zonal, and zone-redundant, ensuring high availability and redundancy. This support is not available for Basic SKU IPs, limiting disaster recovery and high availability options.
Routing preference
Standard SKU IPs offer routing preference settings, allowing more granular control over how traffic is routed between Azure and the Internet. This feature is not supported with Basic SKU IPs, which means less control over traffic routing.
Global tier
The Standard SKU supports global tier capabilities like cross-region load balancing, allowing you to connect services across multiple Azure regions. Basic SKU does not support this feature, limiting it to local regions only.
Standard Load Balancer support
Standard SKU IPs can be used with both IPv4 and IPv6 addresses, allowing greater flexibility and future-proofing your network configurations. Basic SKU IPs do not support Standard Load Balancer, restricting usage options.
NAT Gateway support
Standard SKU IPs support NAT Gateway for IPv4 addresses, enabling efficient outbound internet access for virtual networks. Basic SKU IPs lack this support, potentially complicating internet access configurations.
Azure Firewall support
Standard SKU IPs are compatible with Azure Firewall, providing advanced security features for network protection. Basic SKU IPs do not offer this support, limiting security options.
Pricing
Not only do functionalities change, but also the prices. View the actual prices on Azure Pricing.
Type | Basic (Classic) | Basic (ARM) | Standard (ARM) | Global (ARM) |
---|---|---|---|---|
Dynamic IPv4 address | First Cloud Service VIP: Free Additional: CHF 0.00322/hour | CHF 0.00322/hour | N/A | N/A |
Static IPv4 address | CHF 0.00290/hour | CHF 0.00290/hour | CHF 0.0041/hour | CHF 0.0081/hour |
Public IPv4 prefix | N/A | N/A | CHF 0.005 per IP/hour | CHF 0.010 per IP/hour |
Dynamic IPv4 address
Dynamic IP addresses are allocated and can change over time. Basic SKU for ARM dynamically allocated IPs at the rate of CHF 0.00322/hour, while Standard and Global SKUs don’t support dynamic allocation.
Static IPv4 address
Static IP addresses remain assigned to the resource until manually changed. Basic SKU’s static IP costs CHF 0.00290/hour, whereas Standard SKU costs CHF 0.0041/hour, reflecting the added features and stability. Global SKU static IPs have the highest rate at CHF 0.0081/hour due to their extended capabilities across regions.
Public IPv4 prefix
This is the cost associated with IP address ranges (prefixes) allocated. Basic SKU does not support public IP prefixes, while Standard and Global SKUs charge CHF 0.005 per IP/hour and CHF 0.010 per IP/hour respectively, indicating better scalability and control over multiple IPs.
Upgrade Basic Public IP Address To Standard SKU In Azure
Steps To Complete The Upgrade
I made some recommendations based on Microsoft’s approach to ensure a seamless transition from Basic SKU to Standard SKU public IP addresses. Following these steps will help you minimize disruptions while migrating.
- Understand key differences:
- Begin by thoroughly understanding the major differences between Basic SKU and Standard SKU public IP addresses. Familiarize yourself with the technical specifications, functionalities, allocation methods, and security features. Refer to the following Microsoft Learn articles to gain in-depth insights:
- Identify IPs for upgrade:
- Conduct an assessment of your existing infrastructure to identify all Basic SKU public IPs that require upgrading. To do so use the Azure Portal and search for public IP addresses.
- Conduct an assessment of your existing infrastructure to identify all Basic SKU public IPs that require upgrading. To do so use the Azure Portal and search for public IP addresses.
- Assess zone redundancy needs:
- Evaluate whether your applications and services require zone redundancy for additional resilience and high availability.
- Implementation:
- Zone Redundant IPs: If zone redundancy is necessary, you have to create new Standard SKU public IP addresses using the Azure Portal, PowerShell, CLI, or ARM templates.
- Non-Zone Redundant IPs: If zone redundancy is not required, you can follow the upgrade pathways that I will mention later in that blog post.
- Determine IP tier (load balancer only):
- Decide whether your workloads require regional or global tier public IP addresses based on factors such as geographic distribution, traffic routing, and scalability needs. Ensure that the chosen public IP address tier aligns with the load balancer tier, if applicable. This will guarantee optimal performance and resource allocation.
- Plan for downtime:
- Schedule the upgrade process during maintenance windows or periods of low traffic to minimize service disruptions.
- Execute the upgrade:
- Follow the paths below based on the resource associated with your Basic SKU public IPs:
Resource Using Basic SKU Public IP Addresses
Resource | Decision Path |
---|---|
Virtual Machine | Use scripts or manually detach and upgrade public IPs. For standalone virtual machines, use this upgrade script, and for virtual machines in an availability set, use this script.
SPECIAL NOTE: In my cases, the upgrade script worked perfectly as hoped. I was able to migrate the public IPs to the Standard SKU without any detaching of the IPs required. The downtime was less than 10 minutes for a standalone virtual machine with a public IP address associated. |
Virtual Machine Scale Sets | Replace Basic SKU instance public IP addresses with new Standard SKU. |
Load Balancer (Basic SKU) | New Load Balancer SKU required. Use this script to upgrade to Standard Load Balancer. |
VPN Gateway (using Basic IPs) | Follow this migration guidance to upgrade to Standard SKU public IPs. For the latest migration timeline, please see this page.
During the IP address migration, a VPN Gateway migration is required and all non-AZ SKUs become AZ SKUs after the migration. |
ExpressRoute Gateway (using Basic IPs) | Follow this migration guidance. |
Application Gateway (v1 SKU) | New Application Gateway SKU required. Use this migration script to migrate from v1 to v2. Although Basic SKU public IPs are set to be retired by September 2025, Basic IP resources linked to Application Gateway V1 deployments will remain unaffected until V1 Application Gateway itself is retired. For more details, please see here. |
Azure Databricks (using Basic IPs) | For ephemeral workloads, Standard SKU public IP addresses are automatically deployed as virtual machines (short VMs) cycle out through regular usage attrition with new VMs. For long-running workloads, manually restarting the compute resources will replace existing Basic IPs with Standard IPs. |
Personal Experiences And Challenges With Migrating VPN Gateways
Migrating VPN Gateways, especially from Basic to Standard SKU public IP addresses, has been quite a journey. Here, I share my experiences and the challenges faced during this transition.
Story Behind My Struggles with the Basic VPN Gateway
I attempted to migrate two VPN gateways at the same day last week—one Basic and one VPNGW1. The attempt to migrate the Basic gateway migration initially failed when I tried to migrate it via the Azure Portal. I didn’t have the migration wizard available, prompting me to dig deeper into this inconvenience. I came across recent changes in Microsoft’s guidance regarding Basic SKU public IP address migration for Basic VPN Gateway:
So I had to postpone the migration for some weeks or even months.
Story Behind My Struggles with VPNGW(1)
After the initial setback with the Basic VPN gateway migration, I prepared thoroughly for the migration of the VPNGW1 gateway (standalone). Here’s a guide based on my experiences, with steps and recommendations to help ensure a smooth transition.
Migration Approach
To choose the best migration approach, the simplest method to follow is the guidelines provided by Microsoft in How to migrate a Basic SKU public IP address to a Standard SKU – Preview.
During the migration process, your Basic SKU public IP address resource will be converted to a Standard SKU public IP address resource. The IP address assigned to your gateway will remain unchanged. Additionally, if your VPN Gateway SKU is VpnGw 1-5, it will be upgraded to VPN Gateway AZ SKU (VpnGw 1-5 AZ). Be aware of changes in pricing and functionalities that accompany this migration.
Important: Basic SKU public IP address migration for VPN Gateway is currently in PREVIEW. Trust me, it really is PREVIEW!
Prepare for the Migration
If you follow the migration guidelines like I did via the Azure portal, the migration process is divided into three primary sections. Here’s how I navigated each phase, along with the challenges and solutions encountered.
First, go to the Azure portal and navigate to your virtual network gateway resource. In the left pane, under Settings, click Configuration. On the Configuration page, select the Migrate tab.
NOTE: Before initiating the migration for your VPN gateway, ensure that your gateway subnet has at least three available IP addresses in your current prefix. If your current gateway subnet is /28 or smaller, the migration tool might encounter errors. I resolved this by expanding the subnet to /27.
After these migration considerations were met, I then initiated the migration process where the struggles began.
Clicking the Prepare button initially showed me a failed status, which made me uneasy. After about 20 minutes, I tried to stop the migration via Azure Cloud Shell, thinking something was off. However, I had no luck; the Cloud Shell consistently stated that something else was still running in the background with that VPN Gateway, but there was no indication in the notifications bar of Azure. I then stumbled across a Reddit post: Upgrade to Standard SKU IP – Need help : r/AZURE.
This error didn’t indicate an actual failure; it just meant the job was running in the background. It took about 25 – 30 minutes for my status to change to Succeed, allowing me to proceed with the migration. During this check, the VPN gateway is in a provisioning state and doesn’t function properly. My heart stopped for a while because Microsoft states it should take about 10 minutes downtime for the entire migration.
Migrate
Once the Prepare step is completed, the option to Migrate your resources becomes available. Click the Migrate button to migrate both your public IP address SKU and your gateway SKU. Although Microsoft states you should expect about 5 minutes of downtime during this phase, you cannot make any changes to the VPN gateway.
-
Public IP Migration: The IP address assigned to my gateway did not change.
-
Gateway SKU Migration: My gateway SKU migrated from a non-AZ SKU to an AZ SKU (e.g., VpnGw1 became VpnGw1AZ).
-
Downtime Planning: The Migrate button initially showed a failed status too, but this was just a misleading UI error. I allowed 15-20 minutes for the migration to complete.
Validate the Migration
Once the migration is complete, the Commit button will appear. Clicking this button also initially showed a failed status for me but completed successfully after about 15 minutes.
To ensure the migration was successful, go to the VPN gateway resource Overview page by clicking the Gateway Validation link. Verify that your gateway is receiving and transmitting traffic. Checking the tunnel ingress and egress graphs on the Overview page was particularly useful for me.
If validation is successful and traffic is flowing as expected, then click Commit and Commit changes to finalize the migration. If you don’t commit changes in this step, your Basic SKU public IP address resource remains in a pending state and won’t be deleted.
Viewing Resources After Migration
When the public IP address migration is complete, you can view your resources on the VPN gateway resource page:
- To view the gateway SKU, go to the Overview page for your VPN gateway.
- To view the public IP address SKU, go to the Properties page for your VPN gateway. Click the IP address value to open the Public IP address resource and view the resource SKU.
Additional Resources
For more details, refer to:
- Basic SKU Public IP address migration
- About migrating a Basic SKU public IP address to Standard SKU for VPN Gateways
- VPN Gateway – What’s New
Conclusion
Migrating from Basic SKU to Standard SKU public IP addresses has been a challenging but rewarding journey for me an for sure others. This blog post covered the technical changes, necessary migration steps, and my personal experiences, including the obstacles faced with VPN gateways. Understanding the distinctions between Basic and Standard SKUs is crucial, as factors such as allocation methods, security, availability zones, routing preferences, and support for Azure services must be considered.
Effective planning for downtime is vital. My experiences showed that migrations might extend beyond the anticipated timeframe, sometimes taking over an hour. The Azure portal may temporarily show misleading failure statuses while background processes complete, requiring patience and understanding. It seems this experience is quite normal. If there is an actual problem, you may need to wait until it times out or contact Microsoft Support for assistance.