Bring Leased IPv4 to Azure with a Custom IP Prefix
Azure supports BYOIP through a resource called Custom IP Prefix, generally available across all public Azure regions.
Artem Kohanevich
Co-Founder & CEO at IPbnb
Last updated
Table of Contents
item
Two weeks before the cutover, the network lead pulls up a spreadsheet nobody has touched since 2019. Forty-one customer firewalls, each hardcoded with the same eight public IP addresses. Those addresses belong to a /24 the company has announced from its own rack for a decade. The migration plan says Azure. The spreadsheet says those addresses cannot change.
This is the moment most teams discover BYOIP - and then discover the second problem, which is the bill. Azure will happily issue you 256 fresh public IPs. It will also charge you for every one of them, every hour, indefinitely.
There is a better path, and it works with leased address space as well as owned.
How much do Azure public IPs cost in 2026
Azure prices public IPv4 per address, per hour. Four billing rules matter more than any single rate, and all four come straight from Microsoft's pricing FAQ:
A partial hour is billed as a full hour.
A static public IP in the ARM model is charged regardless of what it is attached to - stopping a VM does not stop the meter. Only dynamic public IPs go free while the associated VM is stopped-deallocated.
A Public IP Prefix is billed per IP, per hour, from the moment the prefix is created - reserving a block "for later" costs the same as using it.
Billing on a static IP starts the second hour after creation and stops only when you delete the resource.
On the rate itself: Microsoft's Basic SKU retirement notice states that from 31 March 2026, Static IPv4 Basic (ARM) rises from $0.0036/hr to $0.005/hr and Dynamic IPv4 Basic (ARM) from $0.004/hr to $0.005/hr, in both cases to match Standard (ARM). That puts Standard (ARM) static IPv4 at $0.005 per hour. Azure's pricing table is region- and currency-filtered and loads its figures dynamically, so confirm the number for your own region and agreement on the IP Addresses pricing page before it goes into a business case.
Working from $0.005/hour and a 730-hour month, one Standard static IPv4 costs about $3.65 per month:
Block size | Addresses | Approx. monthly cost |
|---|---|---|
/28 | 16 | $58 |
/26 | 64 | $234 |
/24 | 256 | $934 |
A /24 of Azure-issued addresses therefore runs to roughly $11,200 a year, before a single byte of egress.
Higher tiers cost more. Standard v2 and Global (ARM) are separate line items on Azure's pricing table, and the Global tier in particular carries a premium for cross-region capability. I'd pull those rates from the live calculator rather than quote them here.
What is a Custom IP Prefix (Azure BYOIP)?
Custom IP Prefix is Microsoft's name for BYOIP. It is a contiguous block of IP addresses owned by an external customer and provisioned into their subscription, which Microsoft is then permitted to advertise. Ownership does not transfer. You keep the RIR registration; Azure takes over the announcement.
Once onboarded, addresses from a custom IP prefix behave like Azure-owned public IPs: they attach to Azure resources, interact with private IPs and virtual networks, and reach external destinations outbound from the Azure Wide Area Network.
The commercial argument is short. There is no charge to provision or use custom IP prefixes, and no charge for any public IP prefixes or public IP addresses derived from them. The pricing page carries the same footnote: there is no charge for the use of any Public IPv4 Prefixes derived from Custom IPv4 Prefixes (BYOIP).
Egress is unaffected either way. Traffic destined to a custom IP prefix range is billed at the internet egress rate, at the same rate as an Azure public IP in the same region. BYOIP removes the address rental line item. It does not touch the bandwidth line item, and anyone promising otherwise is selling something.
The resource model is worth understanding before you start:
A Custom IP Prefix cannot be attached to a resource directly. You derive a Public IP Prefix from it, then derive individual public IPs from that.
The default limit is five custom IP prefixes per region, raisable on request.
Public IP Prefixes using Standard v2 IPs cannot be derived from a Custom IP Prefix, and neither Internet Routing Preference nor the Global Tier used for cross-region load balancing is supported.
In regions with availability zones, the prefix must be declared zone-redundant or pinned to a specific zone at creation.
A managed IPv4 leasing marketplace for holders
Monetize IPv4 Without Selling the Asset
Requirements
The block itself
The range must be registered under your name with one of the five RIRs - ARIN, RIPE NCC, APNIC, LACNIC or AFRINIC - and must be no smaller than a /24, because that is the smallest prefix ISPs will accept. There is no route around this. A /25 will not work, in Azure or anywhere else on the public internet.
Unified or global/regional
Azure offers two deployment models, and a block cannot be migrated between them once onboarded - it must be fully deprovisioned and re-onboarded. Choose deliberately.
Unified is the simple one: the same range is advertised by both Microsoft's WAN and the Azure region, and can be anywhere from /21 to /24. If you are landing one block in one region, take this.
Global/regional is a parent/child structure. Microsoft's WAN advertises the global (parent) range, while individual Azure regions advertise the regional (child) ranges. Global ranges run /21 to /24, regional ranges /22 to /26, and a child must be at least one level smaller than its parent - a /23 parent permits /24 to /26 children. Only the global range is validated during provisioning; children are derived from it. Children may sit in different subscriptions, but must share a tenant. This is the model for a multi-region estate split across teams.
The ROA
You must create a Route Origin Authorization on your RIR's portal or API, digitally signed with your RIR's RPKI. Three things must be right:
Origin AS must be 8075 for the public cloud, or 8070 for US Gov Cloud.
The prefix length must exactly match what Microsoft will advertise. If you are bringing both a /24 and a /23, name both.
The validity end date must cover the full period you intend Microsoft to advertise the block. Some RIRs set this date for you.
Allow at least 24 hours after submission for the ROA to become available to Microsoft. If another ASN currently announces the block, Microsoft also recommends creating a ROA for that ASN to avoid problems during migration.
The signed message
This step is separate from the ROA and catches people out. Azure proves the block belongs to your subscription by matching a signed message against a certificate you publish in the public registry record.
You generate a self-signed X509 certificate with OpenSSL and paste it into the public comments of the Whois/RDAP record for the prefix: the Comments field on ARIN, the Remarks field of the inetnum object on RIPE, APNIC and AFRINIC. LACNIC holders open a support ticket with Microsoft instead. You then build a string in the format subscription-ID|prefix|expiry-date, with the expiry matching the ROA validity date, and sign it with the private key. The base64 output goes into the portal.
Step by step: provisioning to commissioning
1. Prepare. Create the ROA for AS8075. Generate the key pair, publish the certificate in the Whois/RDAP record, sign the authorization message. Wait out the 24-hour ROA propagation.
2. Provision. In the portal, search Custom IP, open Custom IP Prefixes, and select + Create. Supply the CIDR, the ROA expiration date in yyyymmdd format, the signed message, and your zone setting. The range is pushed to Azure's IP Deployment Pipeline asynchronously; track progress in the Commissioned state field. Provisioning takes around 30 minutes.
3. Derive addresses. Once the prefix reaches Provisioned, open it and select + Add a public IP prefix, matching the region. From there you allocate Standard SKU public IPs and attach them to NICs or load balancer front ends. Nothing is advertised yet, so nothing is reachable. This is the useful part: you can build and test the entire target topology before a single packet moves.
4. Commission. Select Commission and choose the scope. The status moves to Commissioning, during which the range is partially advertised, then to Commissioned. The full rollout takes an estimated 3 to 4 hours.
The migration risk sits here. As the prefix commissions, Microsoft advertises it from the local Azure region and then globally over its wide area network under AS8075. Announcing the same range from anywhere else at the same time risks BGP routing instability or traffic loss. Plan the cutover inside a maintenance window, or use the regional-only commissioning option, which confines the advertisement to the Azure region where the prefix is deployed.
Regional-only commissioning is the underused feature here. It lets you validate reachability inside a region while your legacy announcement stays live globally.
If provisioning fails, the resource exposes a FailedReason attribute, surfaced as a banner in the portal. ASN8075NotAllowedToAdvertise means the ROA is missing or incorrect; a signed-message failure means the message cannot be verified against the Whois/RDAP record for the prefix.
Bringing a leased IPv4 block: what actually changes
Be precise about what Microsoft requires. The documentation says the range must be owned by you and registered under your name with an RIR, and Azure enforces this at the registry level: it checks a ROA and a certificate that both live on the RIR object. On a leased block, that object belongs to the IP owner, not the IP renter.
So BYOIP with leased space is not a workaround. It is a two-party procedure that only works with the owner's active cooperation, and the lease has to be written accordingly. The division below reflects where each Azure requirement lands in practice, given who controls which record:
Task | Who performs it | Why |
|---|---|---|
ROA authorizing AS8075 | IP owner | Holds the RIR object and RPKI credentials |
Publishing the X509 certificate in Whois/RDAP | IP owner | Controls the inetnum or net object |
Generating the key pair and signing the message | IP renter | The message contains the renter's Azure subscription ID |
Creating the Custom IP Prefix in the portal | IP renter | Runs in the renter's subscription |
LOA covering the lease term | Issued by owner, held by renter | Standard practice with upstreams |
A practical note on key handling: the renter can generate the key pair locally and hand only the public certificate to the owner for publication. The private key that signs the authorization message never has to leave the renter's side.
Three things to settle in the lease agreement before you provision:
ROA validity must outlast the lease term, with a named owner for renewal. An expired ROA does not stop Microsoft advertising, but Microsoft warns that external carriers may stop accepting the advertisement, and recommends creating a follow-up ROA if the original expiration has passed.
Decommission before the ROA changes. Microsoft is explicit that you should decommission the range before modifying or deleting the ROA, or Microsoft will continue advertising a range it is no longer authorized to advertise. Build this into the lease exit process, not into a runbook nobody reads.
Screen reputation before signing. Blocklist history follows the addresses, and remediation after the fact is slower than checking first.
Because the minimum onboarding size is a /24, leasing also fits the economics better than buying for most Azure workloads: you need at least 256 addresses to participate, whether or not you need 256 addresses.
The cost math: 256 Azure IPs vs. a leased /24 on BYOIP
Azure-issued Standard IPs | Leased /24 on BYOIP | |
|---|---|---|
Address cost | 256 × $3.65 ≈ $934/month | $77–$90/month |
Public IP Prefix charge | Per IP, per hour, from creation | None |
Custom IP Prefix charge | n/a | None |
Egress | Standard internet rates | Standard internet rates |
Annual address spend | ~$11,200 | ~$925–$1,080 |
At IPbnb's published marketplace rate of $0.30–$0.35 per IP per month with no platform fees, a /24 costs $77 to $90 monthly. Against roughly $934 in Azure address charges, that is about $850 a month, or close to 90% of the address line - before counting the operational value of keeping addresses that already sit in your customers' allowlists.
There is no amortization period, because Azure charges nothing to onboard.
Two honest caveats. Egress is identical either way, so if bandwidth dominates your bill this changes less than the percentage suggests. And you are trading a fully managed cost for a two-party compliance relationship: ROAs, certificates and renewal dates that someone has to own. For a handful of addresses nobody has memorized, Azure's meter is cheaper than the coordination. For a /24 with a decade of reputation attached, it is not close.
Run your own numbers with the IPv4 price calculator, and see our BYOIP overview for the AWS and Google Cloud equivalents.
FAQ
Does Azure support BYOIP?
Yes. Azure supports BYOIP through a resource called Custom IP Prefix, generally available across all public Azure regions. You bring your own IPv4 or IPv6 block, keep the registration at your RIR, and authorize Microsoft to advertise it under AS8075.
How does bring your own IP work?
You authorize the cloud provider to announce a block you control. On Azure, that means publishing a ROA naming AS8075 as origin, proving ownership with a signed message checked against a certificate in your Whois record, then provisioning the block as a Custom IP Prefix. Once commissioned, Microsoft advertises the range and you allocate addresses from it like any other.
Is Custom IP Prefix free?
Yes. Microsoft charges nothing to provision or use a custom IP prefix, and nothing for the public IP prefixes and public IP addresses derived from it. Egress traffic is still billed at normal internet rates.
What is the minimum prefix size for Azure BYOIP?
A /24, or 256 addresses, because that is the smallest block ISPs will accept. Unified and global (parent) ranges run from /21 to /24; regional (child) ranges run /22 to /26 and must be at least one level smaller than their parent.
Can I use leased IPv4 ranges with Azure BYOIP?
In practice yes, but only with the IP owner's cooperation. Azure verifies ownership against the RIR record, which the owner controls, so the owner must create the ROA for AS8075 and publish your X509 certificate in the inetnum remarks. You generate the keys, sign the authorization message with your subscription ID, and provision the prefix. Confirm the LOA covers the full lease term and that ROA validity extends past it.
