Azure Architecture Series #69 — Public IPs: Basic Versus Standard, Static Versus Dynamic

Business Challenge

A public IP looks like the simplest object in Azure networking. It is an address. You attach it to something and the something becomes reachable. In fact it carries a SKU, and the documentation is blunt about how much that one field decides:

“The SKU determines their functionality including allocation method, feature support, and resources they can be associated with.”

Three different kinds of thing, settled by one choice at creation time. And the choice has effectively already been made for you, because one of the two SKUs is gone:

“On September 30, 2025, Basic SKU public IPs were retired.”

That date is already in the past. Which would make this a short post, except that “retired” means something different here than it did in #68 — and the difference is worth putting side by side, because the same word is doing two unrelated jobs in consecutive parts of the same product.

The full sentence is worth having, because it is the whole decision: “Basic public IPs will remain operational after September 30, 2025, giving users more time to transition to Standard SKU. Customers who choose to continue using Basic public IPs after retirement date accept the risks and acknowledge that the service is unsupported and not covered by SLA guarantees.”

So nothing breaks. You simply hold an address that Microsoft will not stand behind. For a lab that is fine. For anything with an availability commitment it is a quiet transfer of risk onto you, and it will not announce itself.

Architecture

One immutable field, two allocation methods of which Standard offers one, and a security default that flips between the SKUs.

The comparison, with the row that matters most first

That last row is worth noticing precisely because it is the one people assume differs. The idle timeouts are word-for-word the same in both columns. If a connection is dropping after four minutes, the SKU is not the reason and upgrading will not fix it.

The security row, by contrast, is a behaviour change disguised as a SKU attribute. Basic is reachable unless you stop it; Standard is unreachable until you permit it. Which means a Basic-to-Standard migration is not like-for-like: the same VM, same rules, same everything else, becomes unreachable unless an NSG explicitly allows the traffic. Everything #64 said about needing an allow in both levels applies at exactly this moment.

What static and dynamic actually mean

Both words mean something narrower than they sound.

“Dynamic — The IP address isn’t given to the resource at the time of creation… The IP is assigned when you associate the public IP address with a resource. The IP address is released when you stop, or delete the resource.”

“Static — The resource is assigned an IP address at the time it’s created. The IP address is released when the resource is deleted and can’t be recovered.”

So dynamic does not mean “changes occasionally”; it means you lose it on a stop. And static does not mean “yours forever”; it means yours until the resource is deleted, after which it is gone irrecoverably. There is also no address picking: “When you set the allocation method to static, you can’t specify the actual IP address… Azure assigns the IP address from a pool of available IP addresses in the Azure location.”

The four documented reasons to need static are all forms of something else having written the address down — “update firewall rules… DNS name resolution, where a change in IP address would require updating A records… an IP address-based security model… TLS/SSL certificates linked to an IP address”. Each is a dependency outside Azure that a stop/start would break.

Which is why Standard being static-only is a simplification rather than a restriction. The decision tree collapses: there is no allocation choice to get wrong.

Three things fixed at creation

The zone one deserves a second look, because the labelling changed underneath everybody: “All formerly Standard non-zonal IPs are now zone-redundant in all regions that support availability zones. The means that IPs that show as either ‘zones 1 2 3’ or have no zones are equivalently zone-redundant.”

So a blank zone field no longer means what it used to. An auditor reading “no zones” on a Standard IP and concluding it is not zone-redundant would be wrong — while the same blank field on a Basic IP means exactly non-zonal, since “Basic SKU Public IPs don’t have any zones and are created as non-zonal.” Same display, opposite meaning, decided by the SKU.

Why This Architecture Holds Up

Because the migration is not like-for-like, and the difference is reachability

The single most consequential thing in this post: upgrading a public IP changes the default security posture of whatever it is attached to. Basic is open by default. Standard is “closed to inbound traffic when used as a frontend” with an NSG “required”.

So the upgrade sequence has an order that is not optional: the NSG rules must exist before the Standard IP is attached, or the service goes dark at the moment of cutover. Microsoft's own step list includes “Create a migration plan for planned downtime”, which is the honest framing — this is a change with an outage, not a property edit.

And it connects the whole networking phase: a Standard public IP is the first thing in this series that requires the NSG work from #64 through #66 rather than merely benefiting from it. If the subnet has no NSG at all, a Standard IP makes the resource unreachable rather than open.

Because some things cannot be upgraded at all

The upgrade table is mostly “run a script”, with one genuine dead end worth knowing before planning an estate-wide migration:

“If you have a virtual machine scale set (uniform model) with public IP configurations per instance, note these aren’t Public IP resources and as such can’t be upgraded; a new public IP address is required.”

Per-instance IP configurations on a uniform scale set are not addressable objects, so there is nothing to convert. Two other paths are redeployments rather than upgrades too: a Basic load balancer needs “a new Load Balancer SKU… required”, and VPN Gateway migration carries a side effect worth planning for — “All non-AZ SKUs become AZ SKUs”, which changes the gateway as well as the address.

And one path has its own expired deadline nested inside it: Application Gateway v1 users must move to v2, because “Microsoft retired Application Gateway v1 on April 28, 2026”. A Basic IP on a v1 gateway is therefore two retirements deep.

Because SKUs must match, so one Basic resource pins the others

This is the constraint that turns a small migration into a large one: “matching SKUs are required for load balancer and public IP resources. You can’t have a mixture of basic SKU resources and standard SKU resources.” And for tiers specifically, “If the public IP address aligns with a standard load balancer, the IP address must align with the load balancer tier.”

So you cannot migrate an address in isolation when it fronts a load balancer — the balancer moves with it, and anything else attached to the balancer moves too. The unit of migration is the connected set, not the IP. That is worth mapping before scheduling anything, because the blast radius is discovered rather than chosen.

Because Standard v2 is not simply “newer Standard”

A trap sitting right next to the obvious answer. Standard v2 looks like the natural choice on a fresh deployment, and it is almost always wrong today: “Standard v2 IPs can only be utilized with the Standard v2 NAT GW product at this time. It cannot be used with any other product or component.”

It also loses two Standard features: routing preference is “Standardv2: Not supported” and the global tier is “Standardv2: Not yet supported”. And its zone behaviour is fixed rather than chosen — “Standard v2 IPs can only be zone-redundant”.

Which makes the practical reading short: unless you are attaching it to a Standard v2 NAT Gateway, Standard v1 is the answer. “v2” here denotes a different product line, not a successor.

Because the address you did not create is the one from #68

A sentence on this page closes the loop with yesterday's post precisely: “A resource without an assigned public IP can still communicate outbound; in these instances, Azure automatically assigns an available dynamic IP address for outbound communication. This dynamically assigned address isn’t dedicated to the resource and can change over time.”

That is default outbound access, described from the public-IP side. So the two posts are two views of one mechanism: #68 is about Azure withdrawing that implicit address for new subnets, and this post is about the explicit address you attach instead. A Standard public IP on the NIC is one of the four explicit outbound methods from #68 — the per-machine one, with per-machine cost, since “Public IPv4 addresses have a nominal charge”.

Because the DNS label is a security surface, not a convenience

The domain name label looks like a nicety — it maps “domainnamelabel.location.cloudapp.azure.com” to the address, for “IPv4 addresses (32-bit A records) and IPv6 addresses (128-bit AAAA records)”, and each one “must be unique within its Azure location”.

The preview feature attached to it is the interesting part, because of what it defends against: Domain Name Label Scope “can help to prevent ‘dangling DNS names’ which can be reused by malicious actors” by inserting a subscription-derived hash into the name. Delete a resource whose label someone else can then claim, and the name keeps resolving — for them.

It is in public preview and “not recommended for production workloads”, and it “can only be specified at the creation of a public IP address” — so it is a decision you can only make at the moment you are least thinking about it. Worth knowing the subdomain-takeover risk exists even if the mitigation is not yet production-ready.

Because one SKU exception survives the retirement

Worth recording so nobody wastes time hunting a Basic IP that is legitimately still there: “this retirement won’t impact your existing or new deployments on CSES… you can still create (via non-Azure portal methods; for example, Azure CLI, PowerShell, etc.) and use Basic SKU public IPs for CSES deployments.”

Cloud Services Extended Support keeps the Basic SKU, creatable outside the portal. An inventory script that flags every Basic public IP as a violation will raise those, and they are not violations.

Key Architecture Decisions

Closing Thought

Two posts, two retirements, and neither one turns anything off — which is becoming a pattern worth naming. Default outbound access was retired by changing a default for new networks. The Basic public IP SKU was retired by withdrawing support while leaving the resource running. In both cases the announcement sounds like a deadline and the reality is a slow transfer of risk: in #68 the risk that two pipelines disagree, here the risk that something load-bearing sits on a resource with no SLA behind it.

What makes the public IP version sharper is that the remedy is not free. Upgrading changes the default security posture of whatever the address fronts, from open to closed, so the cutover needs its NSG rules in place first and an outage window around it. And because SKUs cannot be mixed, the unit of work is not the address but everything attached to it — a Basic IP on a Basic load balancer drags the balancer and its backend along. That is why Microsoft's own step list contains a downtime plan rather than a command.

The small thing I would take away is the idle timeout row. It is identical on both SKUs, word for word, and it is the row people most often expect to differ — four minutes outbound, fixed, on everything. When a long-lived connection dies quietly and the SKU is the first suspect, that row is the answer, and the answer is that the SKU has nothing to do with it.

Official Azure Reference

• Public IP addresses in Azure — the full SKU comparison including the identical idle timeouts, the static and dynamic definitions, the zone-redundancy relabelling, the domain name label and its scope, and the IPv6 limitations
• Upgrade Basic public IP to Standard SKU — the retirement date and what it actually means, the per-resource upgrade paths, the scale-set dead end, the VPN gateway side effect, and the CSES exception
• What is routing preference? — the Standard-only feature referenced in the comparison (no claims drawn from it)
• Public IP address prefixes — the contiguous-range option for scale sets and predictable egress (no claims drawn from it)