Separate BYOIP provisioning from public route advertisement

Source facts

For a unified custom IPv4 prefix, Microsoft permits child public prefixes and address attachments after provisioning. The documentation explicitly says those addresses are not yet advertised or reachable at that stage.

In Azure public cloud, commissioning advertises the range through Microsoft under ASN 8075. Microsoft warns that simultaneous Internet advertisement from another location can cause routing instability or traffic loss, and recommends a maintenance period for an active-range migration. Microsoft Learn.

Applicability

Use this distinction for the Azure public-cloud unified custom-prefix workflow, after the required ownership and authorization preparation. This article is not a complete prefix-onboarding or route-authorization procedure and does not prescribe the public-cloud ASN for sovereign clouds.

DSE recommendation

DSE recommends two separate sign-offs: the intended Azure resources have their planned addresses, and the routing change has been authorized and observed. Coordinate the existing advertiser, Azure operator and application owner before commissioning an active range. Keep the prior route state, approved transition sequence and recovery decision together. Do not interpret a successfully attached address as permission to move production traffic.

Verification

Record the actual prefix state and resource attachments before the change. During the approved window, observe route advertisement from appropriate external locations and test the intended application path. Preserve unsuccessful observations as well as successful ones. If resource provisioning is complete but the route transition is not, report those as separate outcomes rather than declaring the entire migration complete.

Official references

Microsoft Learn: Create a custom IPv4 address prefix in Azure. Source retrieved September 9, 2026.