AWS, Azure and Google Cloud BYOIP compared: requirements side by side
Bringing your own IPv4 addresses to a hyperscaler follows the same broad idea everywhere: prove you control the prefix, authorise the provider to announce it, then allocate addresses from it inside your cloud account. The details differ enough to catch teams out, so this article sets the three main providers’ requirements next to each other and explains what each difference means when you plan a move.
What all three providers have in common
Every BYOIP flow rests on the same building blocks on the registry side:
- A registration you can prove. The prefix must be registered to your organisation, or to a holder who has authorised you, in the RIR database, with accurate organisation and contact data.
- An RPKI ROA. You create a Route Origin Authorisation that names the provider’s ASN as an authorised origin for the prefix.
- A proof-of-control check. Each provider asks for a specific record or signature so it can confirm the request really comes from the holder.
All three also stop charging the hourly public IPv4 fee for addresses that come from your own prefix, which is the main financial reason for doing this at all. Where they differ is in prefix sizes, the exact proof they want and how provisioning is staged.
Requirements side by side
The table is limited to points that are stable and well documented. Check each provider’s current documentation before you start, because limits and procedures change.
| AWS | Azure | Google Cloud | |
|---|---|---|---|
| Accepted prefix size | /24 minimum | Custom IP prefix, /21 to /24 | Advertised prefix, /16 to /24 |
| ROA origin | Amazon’s ASNs | AS8075 | ROA required, origin as per Google’s instructions |
| Proof of control | Self-signed X.509 certificate in the RDAP record, or DNS TXT record via VPC IPAM | Signed message in the registry record | Reverse DNS validation |
| Process notes | 5 ranges per Region by default | Validate, provision, commission | Provisioning takes weeks |
| Fee for provider public IPv4 | $0.005 per hour | $0.005 per hour (Standard static) | $0.005 per hour (standard VMs) |
| Fee for BYOIP addresses | None | None for custom IP prefixes or IPs derived from them | None |
On registries, AWS accepts space from RIPE NCC, ARIN and APNIC. If your block sits with another registry, or you are working with Azure or Google Cloud, confirm that your registry is supported before you commit to a timeline.
How the differences affect planning
Prefix size. A /24 is the one size all three accept, so it is the natural unit for any plan that might span providers. Azure will not take anything larger than a /21 as a single custom prefix, so a /20 or bigger has to be split. Google accepts advertised prefixes from /16 down to /24, which suits holders who want to bring a larger block in one go.
Proof of control. The proof step decides who has to be involved. An X.509 certificate or a signed message placed in the registry record needs someone with write access to the RIR database objects, usually the LIR. A DNS TXT record or reverse DNS validation needs control of the relevant DNS zones, so if your reverse DNS is delegated somewhere else, sort that out first.
Staging. Azure’s three stages separate preparation from going live: you validate and provision the prefix, then choose when to commission it. Google’s provisioning takes weeks, so build that into any migration plan rather than treating it as a quick configuration change. On AWS, the default of five ranges per Region matters if you intend to bring several small blocks rather than one larger one.
A pre-flight checklist
Before opening a request with any of the three, work through these steps:
- Confirm the prefix is registered correctly and the organisation matches the cloud account holder, or that you have written authorisation from the holder.
- Check the block’s reputation against the main blocklists. The provider announces the prefix as it is, so any listing history moves with it.
- Decide which part of the block goes to which provider, working on /24 boundaries.
- Create a ROA for each provider’s ASN, with a max length that matches what will actually be announced.
- Make sure no other network is still announcing the prefix, and that any existing ROA for an old origin is kept or withdrawn deliberately, not by accident.
- Prepare the specific proof record each provider requires, and note who will remove it once it is no longer needed.
What about other providers?
OVHcloud also supports BYOIP, for prefixes from /24 to /19 with a ROA for AS16276, and it does not charge extra for BYOIP addresses. IBM Cloud has no single public BYOIP flow, so discuss your requirements with IBM directly. For any provider not covered here, ask for the written requirements before you plan around them.
How TACS can help
As a RIPE NCC member, TACS prepares the registry side for each provider: ROAs, route objects, validation records, letters of authorisation and reverse DNS. Our guides to BYOIP on AWS, BYOIP on Azure and BYOIP on Google Cloud cover each flow in more detail, and we can supply a suitable block if you don’t hold one yet.