BYOIP with Leased IPv4: Bring Your Own IP to AWS, GCP and Azure

Since February 2024, when AWS started charging for public IPv4, every cloud-assigned address costs $0.005 per IP per hour. That works out to roughly $3.65 per IP per month — around $934 per month for a standard /24 block of 256 addresses. This AWS IPv4 cost — which many operators call the AWS IPv4 charge — adds up fast at scale.

BYOIP addresses are exempt from that charge entirely. It is the simplest way to avoid AWS IPv4 charges for operators with existing address space.

If you are running a meaningful IPv4 footprint on AWS and using cloud-assigned IPs, you are likely paying several hundred to several thousand dollars per month that you do not have to pay. This is how to avoid AWS IPv4 charges using BYOIP with leased blocks. The technical barrier is lower than most operators expect. And the same logic — with slightly different mechanics — applies to GCP and Azure.

This post covers what BYOIP requires, what a BYOIP-ready lease looks like, and how to bring leased IPv4 to each of the three major cloud providers — including how BYOIP without owning IPs works in practice.

It also covers IPv4 cloud migration via BYOIP for operators moving workloads from on-premises or other hosting environments. If you own unused IPv4 that others could use via BYOIP, see how to monetize your IPv4 blocks instead.

This guide is particularly relevant for hosting and cloud infrastructure providers, who represent the primary BYOIP user base.

What BYOIP Is and Why It Matters Now

Bring Your Own IP (BYOIP) is a feature offered by cloud providers that lets you use IP address space you control — space you own or lease — inside their network, instead of using addresses they assign.

Your IPs behave like any other public IPv4 on the platform. You can assign them to EC2 instances, load balancers, GKE nodes, Azure VMs. The difference is that you brought the addresses, you control the reputation, and you are not paying the provider's IPv4 surcharge for the privilege.

There are two reasons this has become a practical priority for more operators in the past two years. First, AWS public IPv4 address pricing stands at $0.005/IP/hour as of 2026, and AWS IPv4 charges apply to all cloud-assigned addresses — a cost that did not exist before February 2024. Second, GCP's BYOIP v2 update in December 2025 introduced more granular individual IP allocation from delegated prefixes, making the Google Cloud implementation significantly more usable for teams that need to distribute IPs across projects and regions.

One thing most BYOIP guides miss: you do not have to own IPv4 to use this. This means BYOIP with leased IPv4 is fully supported — you do not need to own your address space. BYOIP with leased IP blocks is fully supported across all three major providers. Leased blocks that meet the provider's documentation requirements — a valid LOA, a correctly configured ROA, and a clean reputation history — are accepted. You can lease IPv4 blocks for AWS, GCP, or Azure deployment and bring them through the standard BYOIP process. The operator needs to confirm these prerequisites with their lessor before starting the cloud onboarding process.

What a BYOIP-Ready Lease Looks Like

Before touching the AWS Console, GCP Portal, or Azure CLI, there are five things to confirm with your IP lessor. Gaps in any of these are the most common reason a BYOIP onboarding gets delayed or rejected — many overlap with common leasing mistakes worth reviewing before you start. For context on what a lease costs, see IPbnb pricing.

LOA requirements checklist:

• Clean block history

All three providers check the reputation of a prefix before accepting it. AWS explicitly reserves the right to reject ranges with poor history. Ask your lessor to confirm the block has no significant abuse records, active blacklist entries, or routing irregularities. A reputable platform will be able to provide this confirmation directly.

• LOA that covers cloud use

The Letter of Authorisation must be valid, current, and — importantly — it must permit the specific use case. Not all lease contracts explicitly cover BYOIP deployment. Confirm with your lessor before starting the process, not after.

• RPKI ROA setup correctly configured

A valid Route Origin Authorization must exist for the prefix. For AWS, the ROA must authorise both AWS ASNs: 16509 and 14618. For Azure, it must authorise Microsoft's ASN (8075). Confirm with your lessor who is responsible for ROA setup and maintenance across the lease term, and what happens at ROA renewal — for RIPE-region blocks, temporary transfer terms have a one-year maximum, which means ROAs can break at renewal if the process is not managed. See our guide on RIPE 24-month hold strategy for more on how RIPE transfer terms affect ROA management.

• RIR registration under a business entity

AWS does not accept blocks registered to natural persons. The RIR record must show a legal entity as the holder.

• Sub-allocation rights (if needed)

If you plan to bring only part of a leased block to the cloud, the lease must permit sub-allocation to the relevant prefix size. Confirm this before assuming the contract covers it.

If your current provider cannot confirm all five of the above, see our guide on choosing an IPv4 lease provider before proceeding.

AWS BYOIP

AWS Bring Your Own IP (BYOIP) is the most mature implementation and offers the clearest pricing advantage. AWS BYOIP lets you use address space you control — including leased blocks — on the AWS network, exempt from the public IPv4 fee that applies to all cloud-assigned addresses.

AWS IPv4 Cost: What You're Actually Paying

AWS IPv4 cost for cloud-assigned addresses is $0.005 per IP per hour. Under current AWS public IPv4 address pricing, that equates to ~$3.65 per IP per month. AWS BYOIP pricing advantage: $0 for brought IPs versus $3.65 per month per cloud-assigned IP. At /24 scale, that difference is substantial:

AWS IPv4 charges apply to every cloud-assigned address from the moment it is allocated, whether or not it is attached to a running instance. BYOIP AWS setup eliminates this cost entirely for the brought range. To see what a leased /24 would cost versus your current AWS spend, calculate your lease cost.

Requirements:

• Minimum prefix size: /24

• Block registered to a business entity (not a natural person)

• Valid ROA for the prefix

• RDAP record updated at your RIR

• Legacy IPv4 space requires a ROA object even if the space pre-dates the RIR system — it is not exempt from the ROA requirement

• Maximum 5 BYOIP ranges per AWS Region per account (quota increase available via AWS Support)

Setup process:

1. Confirm the block meets the requirements above — clean history, /24 minimum, business entity registration, valid ROA, RDAP up to date

2. Create an RSA key pair on your local machine

3. Generate a self-signed X.509 certificate using that key pair

4. Submit the provision request via AWS CLI, providing the certificate

5. AWS validates ownership via RDAP record check and ROA confirmation

6. Once validated, advertise the prefix from your AWS account

7. Assign individual Elastic IPs or IP prefixes from the brought range to your EC2 instances, load balancers, NAT Gateways, or other resources

One important operational note: do not make manual changes to RADb or any other IRR database for this prefix once the AWS BYOIP process has started. AWS automatically updates RADb as part of the provisioning workflow. Any manual entry that includes the BYOIP ASN will cause provisioning to fail.

AWS BYOIP works with EC2, Global Accelerator, VPC IPAM, and several other services. It is not supported on Wavelength Zones or AWS Outposts.

GCP BYOIP: Bring Your Own IP to Google Cloud

GCP BYOIP uses a Public Advertised Prefix (PAP) and Public Delegated Prefix (PDP) hierarchy. GCP Bring Your Own IP works through this two-level structure, and the December 2025 BYOIP v2 update meaningfully improved granular control — adding individual IP address allocation from delegated prefixes. This matters if you need to distribute a single leased block across multiple GCP projects or deploy individual /32 addresses rather than always working with sub-ranges.

Requirements:

• Minimum prefix: /24

• ROA authorising Google Cloud's ASN 396982 to announce the prefix

• DNS verification via PTR record (for v2 prefixes, you configure a PTR record for a verification IP address provided by Google Cloud)

• Block cannot overlap with any other externally announced prefix you control — GCP explicitly rejects overlapping announcements for imported prefixes

Setup process:

1. Create a Public Advertised Prefix (PAP) in the GCP Console or via gcloud compute public-advertised-prefixes create

2. Verify ownership — GCP checks the ROA (ASN 396982) and a PTR record. For v2 prefixes, configure a PTR record for the verification IP address that Google Cloud provides after you create the PAP. Allow time for ROA propagation before submitting

3. Once the PAP is validated and commissioned, GCP begins advertising the prefix both within its network and to the internet

4. Divide the PAP into Public Delegated Prefixes (PDPs) for specific regions or projects. The PAP → PDP hierarchy is mandatory — you cannot use addresses directly from a PAP

5. With BYOIP v2 (December 2025 onwards): create individual IP addresses from delegated prefixes using enhanced IP address allocation. This allows allocating individual IPs to load balancers, VMs, or forwarding rules without consuming an entire sub-prefix

One planning note: the PAP → PDP structure means you should map your allocation plan before starting provisioning. Decide which regions need which prefix sizes, and whether you need the v2 enhanced allocation mode, before you begin. BYOIP addresses cannot be moved between GCP projects after allocation.

Azure BYOIP: Bring Your Own IP with Custom IP Prefix

Azure BYOIP is implemented through Custom IP Prefix. Azure Bring Your Own IP allows you to use address space you control — owned or leased — inside the Azure network, with no public IP fee for custom IP prefixes or for public IP addresses derived from them. The cost saving rationale is the same across all three providers.

Azure's implementation has a few differences worth noting before you start.

Requirements:

• Prefix size /24 to /21 (unified prefix); for global/regional hierarchy, the parent prefix must be /21–/24 and regional child prefixes range from /22 to /26

• Valid ROA authorising Microsoft's ASN 8075 to announce the prefix

• RIR registration under a business entity

• Maximum 5 custom IP prefixes per region (increasable on request)

Setup process:

1. Confirm the block is registered at your RIR under a business entity

2. Configure a ROA at your RIR authorising ASN 8075 (Microsoft) to announce the prefix

3. In the Azure Portal, navigate to Custom IP Prefixes and submit the prefix for provisioning

4. Azure performs ownership validation — it checks both your RIR records and the ROA. This typically takes a few hours to a few days, depending on RIR response times

5. Once provisioned and commissioned, derive Public IP Prefixes from the custom prefix

6. Allocate individual Standard SKU public IPs from those prefixes to your Azure resources: VMs, Standard Load Balancers, NAT Gateways, Application Gateways

Azure-specific limitations to know before starting:

Azure does not support Azure BYOIP for outbound SMTP. If you plan to send email from your leased IPs on Azure, this is a hard blocker — consider AWS for that use case instead.

Reverse DNS on Azure BYOIP requires hosting your own rDNS zone. Azure's managed DNS zones do not handle reverse DNS for custom IP prefixes natively — you will need to configure PTR records yourself or through your IP provider.

Azure abstracts BGP entirely. You do not peer directly with Azure's network for prefix advertisement. Microsoft handles all route advertisements internally once the prefix is commissioned. There is no direct BGP session to manage.

IP Reputation Management: What Changes When Your Lease Goes to the Cloud

Most BYOIP guides end at "prefix successfully advertised." The operational reality does not.

When a leased block is deployed via BYOIP, your cloud workloads are running on addresses that the IP owner is ultimately responsible for maintaining in good standing. Any abuse those workloads generate — outbound spam, port scanning, excessive API requests, scraping at scale — is now traceable to addresses associated with a real organisation and a real RIR registration.

Cloud environments can generate abuse patterns that on-premises setups do not. Container orchestration with high pod churn, bulk email sending, large-scale web crawling, and load testing against external targets are common cloud workload types that trigger abuse reports at volume.

The lessee should treat BYOIP IP reputation management as a continuous operational responsibility, not a setup task. That means monitoring outbound traffic for abuse signatures, maintaining clear acceptable-use rules for internal teams using the IP space, and having a defined process for handling abuse reports that arrive at the IP owner level — because they will arrive there, not just at your cloud account. IPbnb's approach to compliance and IP reputation management covers how this is handled at the platform level.

A BYOIP deployment does not reduce your abuse management obligations. In some environments, it increases them.

Common Failure Points

Based on how BYOIP onboarding typically goes wrong:

Expired or mismatched ROA. The ROA must be valid at the time of submission and must correctly authorise the provider's ASN. A ROA that expires mid-process — or that was configured for a different ASN — will cause validation to fail silently in some cases and noisily in others. Check ROA status immediately before submitting.

LOA that does not cover BYOIP. The lease contract may permit routing to your own infrastructure but say nothing about delegating announcement rights to a cloud provider's ASN. Read the contract or ask the lessor before starting.

Dirty block history. If the prefix appears in major blocklists or has recent abuse reports, the cloud provider's reputation check may reject it during validation. Running the block through standard IP reputation monitoring tools (MXToolbox, Spamhaus, IPVoid) before submitting is worth five minutes.

Manual IRR edits on AWS. As noted above: do not manually edit RADb or other IRR entries for a prefix you are provisioning via AWS BYOIP. AWS automates this, and manual entries for the BYOIP ASN break the process.

GCP overlapping announcements. If the prefix is already being announced externally — from your own ASN or another provider — GCP BYOIP will reject it. The prefix must not be in active external advertisement when you submit the PAP.

A Note on Leased Blocks: BYOIP Without Owning IPs

The setup steps above apply whether you own your IPv4 space or lease it. When you lease IPv4 for cloud deployment, the setup steps are identical to owned blocks — the process at the cloud provider level does not change. BYOIP without owning IPs is fully achievable — the operational and contractual prerequisites are what distinguish the leasing case from the ownership case. If you are new to leasing, how IPv4 leasing works is a useful primer before continuing. If you are weighing whether to sell or hold your space, see our comparison of selling vs. leasing IPv4.

A BYOIP-ready lease should give you a clean block with documented history, a LOA that explicitly covers cloud provider deployment, correctly configured RPKI with defined maintenance responsibilities, and RIR registration under a qualifying business entity. BYOIP with leased IPv4 works exactly the same way as BYOIP with owned space at the cloud provider level — the difference is entirely in what you confirm with your lessor before starting.

If your current lease does not confirm these prerequisites, clarify them before starting the onboarding process — not after waiting a week for a cloud provider validation to come back rejected.

IPbnb provides LOA documentation, RPKI setup, and abuse management as part of the leasing arrangement. If you are looking for blocks ready to bring to a cloud provider, the IP Catalogue is the right starting point.

Summary

BYOIP eliminates cloud IPv4 surcharges across all three major providers — AWS, GCP, and Azure all exempt brought prefixes from their public IP fees. Whether you use AWS BYOIP, GCP BYOIP, or Azure BYOIP, the setup process is straightforward for any operator with a clean leased block and the correct documentation. IPv4 cloud migration via BYOIP is one of the most cost-effective moves available to operators running meaningful IPv4 footprints on cloud infrastructure.

The prerequisites are consistent regardless of provider: a clean reputation history, a valid and current LOA that covers cloud deployment, RPKI in order, and RIR registration under a business entity. BYOIP with leased IP blocks follows the same path — confirm the lease contract, the ROA, and the block history first. The rest follows. For operators looking to reduce AWS IPv4 costs while maintaining IP reputation control, BYOIP with leased IPv4 is the most practical path.

Lease BYOIP-Ready IPv4 Blocks → Browse the IP Catalogue