- Preserve external trust and reputation: If your IP ranges are long-trusted by partners or reputation services, BYOIP avoids changing those addresses.
- Avoid widespread DNS and firewall changes: Keeping the same public IPs prevents large-scale DNS updates and partner firewall reconfiguration.
- Simplify compliance and allowlist continuity: Organizations with IP-based compliance or allowlisting can retain the same controls after migration.
- Validation Azure confirms you legitimately own the prefix you want to bring in. Typical methods include RIR (Regional Internet Registry) or RPKI-based proof such as creating a Route Origin Authorization (ROA) or delegating a verification token/certificate per the registry’s processes. As part of validation you may be required to publish a token or a public key that ties the prefix to your Azure account — these steps prevent IP prefix hijacking and make the transfer auditable.
- Provisioning Once validation is successful, you create a custom IP prefix resource inside Azure (Portal, CLI, or PowerShell). This resource represents the brought-in IP range and allows Azure to allocate addresses from it to your Azure resources (VMs, public IPs, load balancers). During provisioning the addresses exist in Azure but are not advertised to the Internet — they remain reserved and unreachable externally until you perform commissioning.
- Commissioning When ready to cut over, commission the prefix so Azure advertises it to the global Internet via Microsoft’s BGP announcements. Before commissioning, you must stop advertising the same prefix from any other network (on-premises, other clouds, or third parties). Failing to withdraw previous advertisements can cause routing conflicts or blackholing. After successful commissioning, external traffic will reach your Azure-hosted services using the original public IPs.
| Phase | Primary purpose | Outcome |
|---|---|---|
| Validation | Prove ownership via RIR/RPKI or verification token | Azure accepts the prefix for migration |
| Provisioning | Create a custom IP prefix resource in Azure | Addresses reserved and available to allocate internally |
| Commissioning | Begin Azure BGP advertisement of the prefix | External reachability using original public IPs |
| Topic | Guidance |
|---|---|
| Minimum prefix sizes | Cloud providers commonly require minimum IPv4 prefix sizes (typically /24). Confirm Azure’s current minimums before initiating BYOIP. |
| Cutover coordination | Coordinate with network teams and partners to stop external advertisements before commissioning in Azure to avoid routing conflicts. |
| Security & provenance | Validation steps (RPKI/ROA or verification tokens) prevent IP impersonation and create an auditable transfer trail. |
| Announcement timing | Plan DNS TTLs and partner allowlist updates; allow time for BGP propagation and verification after commissioning. |
Bring Your Own IP is ideal when you need to preserve IP-based allowlists, reputation, or compliance during a cloud migration. It minimizes DNS and firewall churn while keeping client and partner integrations intact.
Do not commission a prefix in Azure while it is still being advertised by another network. Simultaneous announcements for the same prefix can cause route conflicts, traffic blackholing, and service disruption.
- Verify your IP allocation and RIR records are up-to-date.
- Create any required ROA/RPKI artifacts or verification tokens per Azure’s BYOIP validation instructions.
- Confirm prefix size meets Azure’s minimum requirements.
- Plan coordination to withdraw existing BGP advertisements and schedule the cutover window.
- Update DNS TTLs and notify partners who rely on your IPs.
- Azure BYOIP documentation: https://learn.microsoft.com/azure/virtual-network/bring-your-own-ip-addresses
- RPKI overview: https://rpki.org/
- BGP fundamentals: https://learn.microsoft.com/azure/virtual-network/bgp-overview
- RIR information and ROA guidance: see your regional registry (e.g., ARIN, RIPE, APNIC)