BYOIP on AWS, Google Cloud and Azure: What Actually Differs?

Technical snapshot: 30 July 2026. Provider capabilities and limits can change; consult the linked provider documentation before implementation.

AWS, Google Cloud and Microsoft Azure all support Bring Your Own IP, but the same acronym hides three substantially different control-plane models.

AWS imports customer-controlled ranges into EC2 or VPC IPAM address pools and increasingly connects those pools to other AWS services. Google Cloud uses a hierarchy of public advertised prefixes, public delegated prefixes and sub-prefixes. Azure represents imported space as a Custom IP Prefix from which public prefixes and individual public IP resources are derived.

None of these approaches is universally best. The right platform depends on prefix size, regional design, IPv6 requirements, supported services, provisioning lead time and how much control an organization needs over advertisement and withdrawal.

The main comparison at a glance

Area	AWS	Google Cloud	Microsoft Azure
Primary resource model	EC2 BYOIP address pool or VPC IPAM pool	Public Advertised Prefix → Public Delegated Prefix → sub-prefix / address	Custom IP Prefix → Public IP Prefix → Public IP
IPv4 imported range	/24 or larger	Public Advertised Prefix /16 through /24; allocation subdividable down to /28	Unified or global prefix /21 through /24; regional children /22 through /26
IPv6 model	Publicly advertised prefix as specific as /48; non-publicly advertised range as specific as /60	Regional v2 external and internal configurations with multiple delegation modes	Global parent /48, regional child /64
Control validation	RDAP plus temporary X.509 certificate, or VPC IPAM validation via a DNS TXT record	ROA authorizing Google ASN 396982, plus PTR-based validation for external prefixes	RIR registration, provider authorization and signed validation; Microsoft originates via ASN 8075
Advertisement control	Provision, advertise, withdraw and deprovision operations; regional and network-border-group considerations	Regional v2 separates provisioning from BGP announcement, allowing explicit announce and withdraw actions	Three phases: validation, provision and commission
Typical lead time	Depends on registry readiness, validation path and service	~2 weeks for a regional v2 advertised prefix; delegated prefixes and sub-prefixes in minutes after the parent is ready	Asynchronous provisioning and commissioning; timing depends on prefix type and validation
Default prefix quota	Five IPv4/IPv6 ranges per Region, increaseable via support	Subject to Compute Engine BYOIP quotas and selected architecture	Five custom prefixes per region by default, increaseable on request
Important caveats	Clean-history requirement; one Region at a time for an EC2 range; no Wavelength or Outposts in the standard flow	No overlapping external advertisements; global v1 requires allowlisting and is not the recommended regional model	Custom prefix cannot attach directly to a resource; reverse DNS requires customer-managed zones; subscription movement and some global-tier scenarios are restricted

AWS BYOIP — the expanding service ecosystem

AWS has the strongest “what is new?” story because its BYOIP ecosystem has expanded noticeably:

• VPC IPAM gained DNS-based validation for addresses registered with any Internet Registry in 2024.
• BYOASN allows organizations to preserve both their addresses and originating ASN in supported configurations.
• Global Accelerator added cross-account use of provisioned BYOIP space.
• Application Load Balancer added integration with public IPAM pools containing BYOIP in March 2025.
• CloudFront added BYOIPv4 through VPC IPAM in November 2025 and BYOIPv6 for Anycast Static IP configurations in March 2026.
• VPC introduced ingress routing for large public IP pools in August 2025, including customer BYOIP pools.

AWS caveats to keep in mind

Google Cloud BYOIP — granular delegation and controlled cutover

Google Cloud’s model is structurally explicit: a Public Advertised Prefix delegates to a Public Delegated Prefix, which can be divided into an optional delegated sub-prefix, which finally yields individual address resources or IPv6 ranges.

The recommended regional v2 model materially improves operational control:

• The advertised prefix takes roughly two weeks to provision.
• Public delegated prefixes and sub-prefixes can then be created in minutes.
• The customer chooses when to announce or withdraw the prefix.
• IPv4 imported ranges can be /16 through /24.
• Delegated space can be divided down to /28.
• External validation uses a ROA for Google ASN 396982 and a PTR record.
• The older global v1 path requires the project to be allowlisted and generally takes longer.

Watch for a few Google-specific constraints: an externally originated overlapping route must not remain active when Google announces the imported range; global v1 is a distinct, allowlisted model; resource support differs between regional IPv4, global IPv4 and the available IPv6 modes; and deprovisioning must follow the hierarchy in reverse, with Google advising a wait before removing the provider ROA after deleting the public advertised prefix.

Best suited to: teams that value fine-grained delegation, project-level separation and explicit control over the regional v2 announcement lifecycle.

Azure BYOIP — a resource-oriented model

Azure represents imported space as a Custom IP Prefix. Once provisioned, public IP prefixes and individual Standard SKU public IPs are derived from it. The lifecycle has three named phases: validation, provision and commission.

Azure supports both unified and global/regional IPv4 models. Current documentation permits unified or global IPv4 ranges from /21 through /24, with regional children from /22 through /26. IPv6 uses a /48 global parent and /64 regional children.

Key Azure caveats: the Custom IP Prefix itself is not attached directly to a workload; the default quota is five custom prefixes per region; Internet Routing Preference and Global Tier derivation have limitations; customer-managed reverse DNS zones are required for reverse lookups; provisioned custom ranges cannot simply be moved to another subscription; ExpressRoute Microsoft-peering advertisement is not supported in the documented model; and zonal properties must be chosen consistently in regions with availability zones.

Azure does not charge for provisioning or using the Custom IP Prefix or for public IP prefixes and public IPs derived from it, although normal resource and traffic charges remain relevant.

Best suited to: organizations already standardized on Azure’s public-IP resource model and Azure Resource Manager workflows.

The practical decision matrix

Requirement	Strongest initial candidate
Broadest range of recent service integrations	AWS
Explicit regional announcement and withdrawal control	Google Cloud regional v2
Deep subdivision of imported IPv4 inside the cloud	Google Cloud
Existing Azure Standard SKU public-IP architecture	Azure
Direct AWS public IPv4 cost avoidance	AWS BYOIP
Bring both IP and originating ASN	AWS BYOASN-supported architecture
Global-parent / regional-child IPv6 model	Azure
CloudFront customer-owned dual-stack static addressing	AWS through VPC IPAM

Treat this as a starting point, not a universal ranking. The best way to compare hyperscalers is to begin from the problem you are solving — cost, delegation granularity, migration safety or IPv6 design — and let the provider behavior follow from that.

References

• AWS – Bring your own IP addresses (BYOIP) to Amazon EC2
• Google Cloud – Bring your own IP addresses
• Google Cloud – Create a public advertised prefix
• Microsoft Azure – Custom IP address prefix (BYOIP)