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

What is BYOIP? BYOIP (Bring Your Own IP) is a feature offered by major cloud providers that lets you advertise a block of public IP addresses you control from inside their network, instead of using addresses assigned from the provider's own pool. You keep ownership of the range, prove that control through RPKI and registry records, and the provider originates the prefix to the internet on your behalf. The catch that most tutorials skip: you first need registered address space and, in nearly every real deployment, an Autonomous System Number 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, mail receivers score 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.

This guide covers what BYOIP is, the concrete reasons teams adopt it, the current requirements for each of the three big clouds (verified against their official documentation), and the part that trips people up: where the address space and the ASN come from before any cloud will touch them.

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

Cloud providers hand out perfectly usable public IPs for free-ish with every load balancer and NAT gateway. So why go through the trouble of onboarding your own range? Four reasons come up again and again.

IP reputation you built and control. Sending IP reputation takes months or years to establish. If your mail or API traffic leaves from a provider's shared or recycled pool, you inherit whatever the previous tenant did with that address. With BYOIP, your reputation is your own asset, portable and defensible.

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.

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 created at your Regional Internet Registry. 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. Without a valid ROA authorizing the cloud's ASN, RPKI-validating networks across the internet will treat the announcement as invalid and drop it. 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 two ways. You add a self-signed X.509 certificate to the RDAP record for your range, and you create a ROA. The ROA must authorize Amazon's ASNs 16509 and 14618 to advertise your range (for AWS GovCloud regions, you authorize 8987 instead). 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.

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" parent-child model for spreading a larger block across regions.

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.

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 ASN for Google Cloud: 396982. 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.

As with the other clouds, the practical IPv4 floor is a /24, because that is the longest prefix the global routing table reliably accepts, and Google's provisioning of a new PAP can take up to about four weeks.

BYOIP requirements compared across the three clouds

The table below distills what each provider requires today. 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." They do not tell you how to get 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 via a sponsoring LIR. Provider-independent (PI) resources are registered directly to you and are not tied to any single network operator, which is exactly what makes them cloud-portable. Individuals and organizations can obtain PI IPv4, IPv6 PI and an ASN through a sponsoring Local Internet Registry that is a member of the RIR. You hold the resource, you control the RPKI, and you decide which ASN (a cloud's, or your own) each ROA authorizes. This is the cleanest foundation for BYOIP because nothing about it depends on a third party's goodwill.

Option 2: Leased space with an LOA and 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 lease has to come with two things: a Letter of Authorization (LOA) and, more importantly, the ability to create the ROA authorizing the cloud provider's ASN. Without ROA support, a lease is useless for BYOIP, because the provider's RPKI check will fail. Always confirm ROA support before signing a leasing agreement intended 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 redundancy, multi-cloud routing, on-premises failover or a clean migration path, you need an ASN of your own to originate the prefix from anywhere that is not that single cloud. In practice, serious BYOIP deployments pair the address block with a dedicated ASN. It is the difference between renting a parking spot and owning the car.

An ASN is also far more affordable than most teams assume. Through a sponsoring LIR, ASN sponsorship runs 130 EUR per year all-in (that figure already includes the RIPE NCC per-ASN fee, with no setup charge), and even natural persons can be sponsored. If you are weighing that against the operational cost of being locked to one provider's address pool, the math is not close. For the full breakdown, see our ASN registration cost guide and the complete ASN registration walkthrough.

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 a registered IPv4 /24 (or larger) or an IPv6 /48, either as your own PI assignment or as leased space with explicit ROA support.
• Can you create ROAs for it? Confirm you have RPKI authority. For leased space, this is contractual, get it in writing.
• 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, APNIC); Azure the widest.
• Have you budgeted the lead time? Provisioning is not instant, and ROA propagation alone can take a day. 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

BYOIP is one of those features that looks like a cloud-console checkbox and is really an internet-routing project. The console steps are genuinely well documented by AWS, Azure and Google. What none of them explain is the prerequisite: registered, RPKI-capable address space and, for any deployment that values resilience or portability, an ASN of your own.

If you are planning to bring your own IPs to the cloud and do not yet hold the underlying resources, that is the first thing to sort out, not the last. A PI assignment and an ASN through a sponsoring LIR give you a foundation that works across every cloud on this page and every one you might move to next. Start there, and BYOIP becomes exactly what it should be: your addresses, following your infrastructure, wherever it lives.

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)

Facts checked July 2026.