IPXO AWS BYOIP Automated Provisioning – Reducing Public IPv4 Cost and Operational Friction

AWS BYOIP has existed for years, but the incentive to use it changed when AWS introduced a direct hourly charge for public IPv4. For teams running internet-facing workloads at scale, this turns address usage into a recurring cost driver and makes BYOIP a practical lever for reducing spend. The challenge is that BYOIP onboarding is rarely lightweight when done manually, which is why automation matters as much as the underlying cost benefit.

Public IPv4 on AWS now has a meter

In February 2024, AWS introduced a public IPv4 charge of $0.005 per IP-hour for all public IPv4 addresses, whether attached or idle. The pricing model is simple and explicit, and it applies across standard public IPv4 usage. At the same time, AWS documentation clearly states that IPv4 addresses you own and bring to AWS via BYOIP are not subject to this charge.

This change shifted the economics of public IPv4 on AWS. What was previously absorbed into broader infrastructure cost is now visible, predictable, and directly tied to address count. For teams operating meaningful public IPv4 footprints, the impact compounds quickly.

BYOIP – Bring Your Own IP – changes the ownership model. Instead of consuming AWS-assigned public IPs, you import an IPv4 prefix you own or lease into AWS. AWS validates that you control the range and then advertises it on your behalf, while governance over the address space remains with you. The technical building blocks stay the same, but the cost and control model changes materially.

AWS has recently expanded BYOIP capabilities beyond IPv4. Through VPC IPAM and CloudFront integration, organizations can now bring their own IPv6 address ranges (/48) and manage them alongside IPv4 in a dual-stack configuration. This extends the same ownership and control model to IPv6 without requiring changes to existing application architectures.

Why BYOIP is financially decisive on AWS

The AWS public IPv4 charge is linear and easy to model:

• Monthly average per IP: $0.005 × 730 hours ≈ $3.65 per IP-month
• Annual per IP: $0.005 × 8,760 hours = $43.80 per IP-year

At scale, the numbers stop being abstract:

• 100 public IPv4s → approximately $365 per month avoided
• 1,000 public IPv4s → approximately $3,650 per month avoided
• A /24 (256 IPs) → approximately $934 per month avoided

Importantly, BYOIP does not require architectural compromises. Customer-owned IPs can still be used with familiar AWS constructs such as Elastic IPs for EC2 instances and ENIs, NAT Gateways, and Network Load Balancers. The difference is not in how services are built, but in where the IPs come from and how they are accounted for.

Why BYOIP becomes complex when done manually

While the economic case is straightforward, AWS BYOIP has real prerequisites and operational sharp edges.

At a minimum, AWS requires IPv4 ranges no more specific than /24. BYOIP provisioning is performed per Region, with default limits on the number of ranges that can be imported into a single Region. Certain environments, such as Wavelength and Outposts, are not supported. AWS also performs reputation checks and may reject address ranges with problematic history.

The manual workflow itself is rarely trivial. It typically involves:

• Proving control of the prefix through RDAP and X.509 certificates or IPAM-based DNS TXT verification
• Ensuring two Route Origin Authorisations (ROAs) for publicly advertisable ranges, covering ASNs 16509 and 14618
• Producing AWS-specific authorisation context
• Executing provision and advertise steps, followed by polling until the range becomes usable

Additional constraints apply for specific services. For example, Global Accelerator introduces its own limitations, including the fact that IPv6 BYOIP is not currently supported in that service.

At the same time, support for IPv6 BYOIP is expanding in other parts of AWS. For example, CloudFront now allows customer-owned IPv6 ranges to be used for Anycast static IP configurations via IPAM, enabling consistent IP identity across both IPv4 and IPv6 where supported.

As a result, BYOIP often turns into a specialist exercise involving PKI, registry updates, and routing validation. It is valuable work, but it is rarely work platform or network teams want to repeat frequently.

IPXO AWS BYOIP Automated Provisioning

IPXO’s approach reduces BYOIP onboarding from a multi-step, error-prone runbook to a single CloudFormation action backed by automated orchestration.

1. A tightly scoped IAM role, created in one step

Customers start from an IPXO-provided CloudFormation quick-create link. This opens AWS CloudFormation with the template URL and required parameters prefilled.

The template creates an IAM role in the customer’s AWS account, with permissions limited specifically to BYOIP-related operations. No broad account access is granted.

2. Secure cross-account access using External ID

The role trust policy enforces the use of an External ID that is unique per customer or tenant. IPXO supplies this External ID when assuming the role via AWS STS. If the External ID does not match, the assume-role operation fails.

This model aligns with AWS best practices for partner-to-customer cross-account access and mitigates the confused deputy problem by requiring a provider-generated unique identifier.

3. Automation of the error-prone steps

Once the role is assumed, IPXO’s backend automates the sequence that commonly causes manual failures. This includes control verification steps, orchestration of provision and advertise actions, retry logic, polling, and surfacing clear status information back to the user.

Control remains with the customer. The IAM role exists in their account, and all actions are executed through that role.

4. Auditability by default

Because all actions are performed via an assumed role in the customer’s AWS account, they are visible to standard AWS auditing tools, including CloudTrail. This aligns naturally with enterprise security reviews and internal change-management expectations.

Why automated BYOIP provisioning can reduce risk

Even in well-run organisations, BYOIP is a high-risk change. It is infrequent, cross-functional, and easy to execute slightly differently each time. IPXO’s automated provisioning is designed to turn that one-off procedure into a repeatable, reviewed workflow, reducing variance, human error, and security drift.

The security advantages come from several factors:

• Fewer manual steps mean fewer failure modes. Automation replaces ad-hoc runbooks, copy-pasted CLI commands, and undocumented tribal knowledge with a consistent execution path and built-in checks.
• Reduced operational exposure. The model supports least-privilege authorisation and time-bounded execution rather than broad, long-lived access patterns.
• A cleaner audit trail. Repeatable automation makes it easier to show what changed, who approved it, and why, compared to manual procedures performed under time pressure.

For organisations with mature change-management pipelines, IPXO integrates as an opinionated automation step. For those without one, it provides a hardened baseline process that can be evaluated once and reused confidently.

IPXO’s security posture

IPXO is ISO/IEC 27001 certified and operates under a formal Information Security Management System. Public materials also outline Cyber Essentials and GDPR-aligned commitments, including explicit regulatory disclosures. The platform is designed to be compliance-ready, with audit trails and documentation that support customer requirements under frameworks such as SOC 2, PCI-DSS, or HIPAA.

Where BYOIP fits in an AWS architecture

Engineering teams typically adopt BYOIP in one or more of the following patterns:

• Static inbound endpoints, such as internet-facing Network Load Balancers or EC2 services that require stable IPs across deployments
• Static outbound egress using NAT Gateways or fixed Elastic IPs for allow-listed partners and controlled egress
• Global entry via AWS Global Accelerator using customer-owned IPv4 addresses
• Advanced CDN allowlisting scenarios, where CloudFront uses BYOIP via IPAM for Anycast static IP lists, subject to specific prerequisites

Advanced CDN allowlisting scenarios, where CloudFront uses BYOIP via IPAM for Anycast static IP lists, now extend to both IPv4 and IPv6 in supported configurations, enabling dual-stack environments with consistent IP identity for allowlisting and partner integrations.

In each case, BYOIP does not change how AWS services behave. It changes how public IPv4 is sourced, governed, and paid for.

FAQ