BYOIP Explained: Bringing Your Own IP Addresses to AWS, Azure and GCP

What is BYOIP? BYOIP (Bring Your Own IP) lets you announce a public IP range registered to you from inside AWS, Azure or Google Cloud, instead of using addresses from the provider's pool. You prove control with an RPKI ROA and a registry record, and the provider originates the prefix on your behalf. What the console guides skip: before any cloud accepts the range, you need registered address space (an IPv4 /24 or an IPv6 /48 at minimum) and, in most real deployments, an ASN of your own.

If you have ever migrated a service to the cloud and watched half your integrations break because the source IP changed, you already understand the problem BYOIP solves. Your addresses are part of your infrastructure. Partners allowlist them, fraud and bot scoring systems remember them, licensing servers pin to them. BYOIP lets those addresses follow you into AWS, Azure or Google Cloud rather than forcing every downstream system to be reconfigured.

Why do teams bring their own IP addresses to the cloud?

Cloud providers hand out public IPs with every load balancer and NAT gateway, but on AWS each one has cost $0.005 per hour since 1 February 2024, about $43.80 per address per year (AWS VPC pricing). Addresses brought through BYOIP are exempt from that charge on AWS, and Google does not charge for idle or in-use BYOIP addresses either. Cost is the newest of five reasons teams bring their own range.

IP reputation you built and control. Reputation with anti-fraud and bot-management systems takes months to build. If your API traffic leaves from a provider's shared or recycled pool, you inherit whatever the previous tenant did with that address. With BYOIP, the history attached to your range is yours.

Allowlisted ranges that partners already trust. Enterprise integrations, payment processors, financial data feeds and B2B APIs frequently allowlist specific source ranges. Re-negotiating those allowlists across dozens of partners every time you change infrastructure is slow and error-prone. Keep your range, keep the allowlist.

Portability and exit strategy. Addresses assigned by a cloud provider stay with that provider. Bring your own, and you can move between AWS, Azure, Google Cloud, a colocation facility or another provider without renumbering. That optionality is worth real money at contract-renewal time.

A stable egress identity. Compliance tooling, geofencing, fraud systems and audit trails often key off a fixed set of source addresses. A consistent egress identity that you own simplifies every one of those conversations.

The public IPv4 charge. A /24 of your own on AWS saves about $11,200 per year in public IPv4 charges at 256 addresses, before you count anything else. At August 2026 transfer prices (about $6,000 for a /24) the block pays for itself inside a year.

None of this is exotic. It is the same logic that made provider-independent address space attractive in the first place, applied to a cloud-hosted world.

How does BYOIP actually work?

Under the hood, all three clouds follow the same shape, even though the console workflows and terminology differ.

1. You prove you control the range. The provider checks registry records (RDAP or whois) and, critically, checks RPKI. You demonstrate control cryptographically rather than by sending a PDF and hoping.
2. You authorize the provider's ASN to originate your prefix. This is a Route Origin Authorisation (ROA), an RPKI object you create in your RIR's portal. It says, in machine-verifiable terms, "this ASN is allowed to announce this prefix, up to this length."
3. The provider provisions and advertises. Once validation passes, the range is onboarded to your account. You allocate addresses from it to resources, then commission the range so the provider advertises it to the internet from their ASN.

The ROA is the load-bearing piece. All three providers use it as proof that the holder authorised them. If your prefix already has a ROA for another ASN (your own, or a previous provider's), networks that run route origin validation will see the cloud's announcement as RPKI-invalid and drop it unless a ROA for the cloud's ASN exists too. This is why every provider below insists on it, and why the ASN numbers matter so much.

What are the AWS BYOIP requirements?

AWS supports BYOIP for EC2, and separately through Amazon VPC IP Address Manager (IPAM) for organization-wide distribution. The core rules, from the official EC2 BYOIP documentation, are strict.

The most specific IPv4 range AWS accepts is a /24. For IPv6, the most specific publicly advertisable range is a /48 (or a /60 for ranges that are not publicly advertisable). The address space must be registered with ARIN, RIPE or APNIC, and, in the words of the AWS docs, "must be registered to a business or institutional entity and cannot be registered to an individual person" for this particular pathway.

Control is proven with a self-signed X.509 certificate in the RDAP record for your range, a message signed with that key, and a ROA. The ROA must authorize Amazon's ASNs 16509 and 14618 to advertise your range (GovCloud: 8987; AWS European Sovereign Cloud: 16509 and 214101). You set the ROA maximum length to match the prefix you are bringing, and AWS notes it can take up to 24 hours for the ROA to become visible to them.

Do not create route objects for the Amazon ASN yourself: AWS updates RADb automatically, and a manual IRR change that names the BYOIP ASN makes provisioning fail.

A useful detail: AWS also supports BYOASN, so you can bring your own ASN and have your range advertised under it rather than Amazon's. The addresses must also have a clean reputation history, AWS explicitly reserves the right to reject ranges associated with abuse.

What are the Azure BYOIP requirements?

Azure calls its feature "custom IP address prefix," and the mechanics are documented in the Azure custom IP prefix guides. Azure accepts the five major RIRs (ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC), a slightly wider net than AWS.

For IPv4, the range must be no smaller than a /24 for ISPs to accept the advertisement. Azure offers two deployment models: a "unified" model where a single range (by default /21 to /24) is advertised from both the WAN and the region, and a "global/regional" model in which a /21 to /24 parent is split into /22 to /26 regional children.

IPv6 uses a mandatory parent-child structure: the global (parent) range must be a /48, and each regional (child) range must be a /64. Only the parent is validated during onboarding, children are derived from it. One quirk worth planning around: only the first 2,048 addresses of each regional /64 are usable as public IPv6 space.

Validation combines a self-signed X.509 certificate in your whois/RDAP record with a signed authorization message. The ROA must list Microsoft's Origin AS as 8075 for the public cloud (8070 for US Gov Cloud), for both IPv4 and IPv6. Azure advises allowing at least 24 hours after submitting the ROA before it can be verified.

Set the ROA's validity end date to cover the whole period Microsoft will advertise the range; Microsoft keeps advertising after that date but recommends a follow-up ROA so other carriers keep accepting it.

What are the Google Cloud BYOIP requirements?

Google Cloud's BYOIP flow starts with a "public advertised prefix" (PAP), documented in the Google Cloud BYOIP guide and the create a public advertised prefix page. Ownership is verified with a combination of RPKI and reverse DNS.

You submit a ROA at your RIR that includes the prefix, the prefix length, and the Premium Tier ASN for Google Cloud, 396982 (Standard Tier prefixes, still in Preview, use 19527). Google adds a distinctive second check on top of the ROA: a reverse DNS (PTR) verification. You pass a --dns-verification-ip when creating the PAP, Google returns a shared-secret hostname, and you publish a public PTR record pointing that IP to the hostname to prove you control the range's DNS delegation. Internal-access prefixes skip the DNS step and rely on the ROA alone.

Google adds one recommendation the others do not emphasize as strongly, and it is a good one: submit a second ROA for the same prefix authorizing your own ASN. That way, if you ever advertise the prefix from your own network again, RPKI-validating networks will not reject it as invalid because it was also authorized for Google's ASN. It is a small step that saves a painful debugging session later.

Google accepts IPv4 public advertised prefixes from /16 to /24 on Premium Tier and /16 to /23 on Standard Tier (Preview). After validation, provisioning takes about two weeks for v2 prefixes and four weeks for v1, and Google cannot speed it up.

Google is stricter than Microsoft on expiry: if a ROA expires and is not renewed within four weeks of its renewal notice, Google stops advertising the prefix.

BYOIP requirements compared across the three clouds

The table below distills what each provider documented as of September 2026. Prefix lengths and ASN numbers are taken directly from each vendor's official documentation.

The pattern is clear. Every path demands a /24 or larger IPv4 block, an IPv6 /48 for public advertisement, a registered range at a real RIR, and a correctly scoped ROA. That is the shared floor. Which brings us to the question none of the cloud docs answer.

Where does the address space (and the ASN) actually come from?

Here is the part that BYOIP tutorials quietly assume you already have. AWS, Azure and Google all start their instructions with "your registered address range." None of them covers getting one. If you do not already hold a routable block and, in practice, an ASN, none of the steps above are available to you.

There are two legitimate ways to hold that address space.

Option 1: Your own PI assignment through a sponsoring LIR. Provider-independent (PI) space is registered by the RIPE NCC to your organisation rather than to a network operator, so it moves with you between clouds and between sponsoring LIRs. For IPv6 that means an IPv6 PI /48: the most specific range AWS will advertise, and exactly the parent size Azure requires. Through us it costs €300 setup plus €135 per year, so €435 the first year (as of September 2026). You sign its ROAs in your own End User hosted CA at the RIPE NCC, so you choose which ASN each ROA authorises: a cloud's, your own, or both.

IPv4 works differently. The RIPE NCC no longer assigns provider-independent IPv4 space to End Users (ripe-826, IXPs excepted). A /24 now comes from the transfer market: about $23.50 per address for /22 to /24 blocks in August 2026 according to broker IPv4.Global (monthly averages, prices at agreement date, online and private sales mixed), so roughly $6,000 for a /24. The RIPE NCC charges nothing for the transfer itself. If you already hold a PI block, IPv4 or IPv6, and your LIR closed or dropped you, you can change your sponsoring LIR and keep it.

Option 2: Leased space with ROA support. If you do not want to hold your own PI block, you can lease routable IPv4 or IPv6 space. For that space to work with BYOIP, the lessor has to do two things you cannot do yourself. It has to create a ROA authorising the cloud's ASN. It also has to place the self-signed X.509 certificate you generate for the onboarding in the registry record, which only the record's maintainer can edit (AWS and Azure), or delegate reverse DNS so you can add the PTR record (Google). AWS also refuses ranges whose record names an individual. Get both commitments in writing before signing a lease meant for cloud onboarding.

Why an ASN is part of the picture

Notice how often "your own ASN" appeared above. AWS supports BYOASN so you can advertise under your number. Google explicitly recommends a second ROA authorizing your ASN. Even when a cloud advertises your prefix under its own ASN, the moment you want to move the range back on-premises, to another cloud or to a failover site, you need an ASN of your own to originate it there once the cloud stops announcing it. In practice, serious BYOIP deployments pair the address block with a dedicated ASN.

An ASN costs less than most teams assume. Through a sponsoring LIR it is €130 per year (as of September 2026): our €80 fee plus the €50 RIPE NCC per-ASN fee, passed through at cost. Natural persons can hold one too, though AWS BYOIP itself does not accept ranges registered to individuals. Order it through our ASN registration service; the ASN registration cost guide compares sponsorship with direct RIPE NCC membership, and the complete ASN registration walkthrough covers the application step by step.

What should you check before starting a BYOIP project?

Before you open a single cloud console, run through this list. It will save you weeks of back-and-forth.

• Do you hold the range at an RIR? You need an IPv4 /24 (or larger) or an IPv6 /48, registered to your organisation (a PI /48, or IPv4 bought on the transfer market) or leased with ROA and registry-record support from the lessor.
• Can you create ROAs for it? Confirm you have RPKI authority. For leased space the ROA and the registry-record edit are both contractual: get them in writing. Check the result with the RPKI checker against the cloud's ASN before you submit.
• Is the reputation clean? Providers, AWS especially, will reject ranges tied to abuse. Check blocklists before you invest.
• Do you have, or need, an ASN? For single-cloud, single-region use you can advertise under the provider's ASN. For anything resilient or portable, plan on your own.
• Which RIR and which cloud? Match your registry to a provider that accepts it. AWS is the narrowest (ARIN, RIPE NCC, APNIC); Azure and Google accept all five RIRs.
• Have you budgeted the lead time? Provisioning is not instant, and ROA propagation alone can take a day. Google provisioning takes two to four weeks on top. Plan the cutover as a maintenance event, never advertise the same range from two places at once.

Get those six answered and the actual cloud onboarding is the easy part. Skip them, and you will discover the hard requirements one rejected provisioning request at a time.

Bringing it together

The cloud consoles document their side well; the prerequisite is registry work. In the RIPE region that means a PI /48 registered to your organisation or IPv4 bought on the transfer market, a ROA for each cloud's ASN, and for anything you may move later, an ASN of your own. Sort those out before the first provisioning request, and allow a day for ROA visibility everywhere and two to four weeks of provisioning at Google.

Official References

• AWS EC2 Bring Your Own IP (BYOIP)
• AWS EC2 BYOIP prerequisites and ROA (ASNs 16509, 14618, GovCloud 8987)
• AWS VPC IPAM: bring your IP addresses tutorial
• Azure: create a custom IPv4 address prefix (ROA Origin AS 8075 / Gov 8070)
• Azure: create a custom IPv6 address prefix (/48 global, /64 regional)
• Google Cloud: bring your own IP addresses
• Google Cloud: create a public advertised prefix (ROA ASN 396982, PTR verification)
• ARIN: using RPKI with Bring Your Own IP services
• RIPE NCC: Resource Certification (RPKI)