Skip to content

IONOS Cloud BYOIP Integration Overview

BYOIP SUPPORTER
ASN AS8560
IPv4 support
IPv6 support
LOA support
ROA support
Process Semi-automatic
Locations supported
Other: Germany, Spain, United Kingdom, United States

This page outlines the technical and procedural information required for integrating Bring Your Own IP (BYOIP) and Bring Your Own ASN (BYOASN) with IONOS Cloud infrastructure. IONOS currently supports IPv4 BYOIP with two deployment models: (1) provider-announced BYOIP, where IONOS originates your public IPv4 prefixes from its global backbone ASN (AS8560) and makes them available in VDC Networking and Private Cloud, and (2) BYOASN, where your own ASN participates in BGP, originates your prefixes, and uses AS8560 as an upstream. The latest BYOIP/BYOASN tutorial (November 2025) formalises the IPv4-only scope, a minimum prefix size of /24, and a typical activation time of up to five business days from approval.

Provider Details

FieldInformation
Provider NameIONOS Cloud
Website VDC Networking (Network Services) | Bring Your Own IP (BYOIP) address to IONOS Cloud (VDC tutorial) | Requirements for BYOIP & BYOASN (Private Cloud) | Private Cloud: Using BYOIP in NSX | Letter of Authorisation (LoA)
ASN(s) Global backbone ASN: AS8560 (IONOS SE global backbone; used as origin for provider-announced BYOIP in IRR/RPKI and on the Internet).
BYOASN: uses the customer’s own ASN as BGP origin, with AS8560 configured as an upstream / transit ASN and explicitly authorised in your AUTNUM (RPSL) policy.
Regions Supported BYOIP/BYOASN is documented for both IONOS Private Cloud powered by VMware and VDC Networking (Compute Engine). The 2025 BYOIP tutorial states that onboarded prefixes can be used across all IONOS infrastructure locations worldwide; key cloud data centers (per current Service Catalog) include:
DE: Berlin (DE/TXL), Frankfurt (DE/FRA, DE/FRA/2), Karlsruhe (DE/FKB – legacy only for new VDC/Private Cloud)
UK: London (GB/LHR), Worcester (GB/BHX) | FR: Paris (FR/PAR) | ES: Logroño (ES/VIT) | US: Las Vegas (US/LAS), Newark (US/EWR), Lenexa / Kansas City (US/MCI).
Private Cloud clusters are currently provisionable in Berlin, Worcester, and Logroño (Karlsruhe remains available only for existing tenants). Always confirm current BYOIP/BYOASN availability per region and product with IONOS Cloud Support.
Support Contact IONOS Cloud Support (24/7 Enterprise Level Support via tickets/portal) | Email (per LoA): support@cloud.ionos.co.uk
Tech Article & Date Bring Your Own IP (BYOIP) address to IONOS Cloud (VDC Networking tutorial; published November 2025; details IPv4-only BYOIP/BYOASN, /24 minimum and ~5 business day onboarding).
Requirements for Bring Your Own IP (BYOIP) and Bring Your Own ASN (BYOASN) (Private Cloud IRR/RPKI/RPSL requirements).
Private Cloud: Using BYOIP in NSX (NSX implementation).
VDC Networking (networking overview; links to BYOIP/BYOASN tutorial and IP Management docs).
BYOIP Scope Provider-announced BYOIP: you remain the owner of your public IPv4 range; IONOS onboards the prefix (IPv4 /24 or larger) into IP Management, configures IRR/RPKI with AS8560 as the origin, and announces it on the Internet from AS8560. The addresses then behave like standard public IPv4 blocks inside IONOS Cloud and can be assigned to supported services in VDC Networking and Private Cloud (e.g. NSX segments, NAT/VPN endpoints, public NICs, load balancers, Managed NAT Gateway, etc.).
BYOASN (Bring Your Own ASN): after BYOIP prerequisites are met, IONOS establishes one or more BGP sessions between AS8560 and your ASN; you originate your prefixes from your ASN with AS8560 as upstream. The same IRR/RPKI/RPSL requirements apply, with additional policy updates to authorise AS8560 as an upstream in your AUTNUM object. BYOIP/BYOASN for Private Cloud and VDC Networking share the same approval letter (LoA) and validation workflow.
Supported Versions IONOS networking and most services are dual-stack (IPv4 and IPv6) in general. However, the current BYOIP/BYOASN onboarding tutorial explicitly supports IPv4 only: you must provide an IPv4 address range of at least /24 (256 addresses) with correct IRR and RPKI registration. IPv6 BYOIP/BYOASN is not available as of November 2025; customers who require IPv6 should use platform-assigned IPv6 ranges and monitor IONOS documentation for potential future IPv6 BYOIP support.
Supported Services VDC Networking / Compute Engine: BYOIP/BYOASN onboarding is integrated with VDC Networking. Once your IPv4 range is approved, it appears as an IP block in IP Management and can be consumed by services that support public IPv4 addresses (VM NICs, public LANs, load balancers, Managed NAT Gateway, VPN Gateway, etc.), subject to regional availability.
Private Cloud (NSX): BYOIP ranges can back NSX segments and are used in SNAT/DNAT and VPN endpoints in the IONOS Private Cloud environment, following the same BYOIP/BYOASN IRR/RPKI/LoA requirements as the VDC tutorial.

Technical Requirements

RequirementDetails
Prefix Size Public, globally routable IPv4 ranges registered in a RIR (RIPE, ARIN, etc.) with correct IRR and RPKI data.
The 2025 BYOIP/BYOASN tutorial specifies that onboarding is currently limited to IPv4 prefixes of at least /24 (256 addresses). Smaller subnets (e.g. /25) are not eligible and are typically filtered by Internet routers. RPKI ROAs must use a maximum prefix length of /24 to match BGP best practice.
ASN Ownership Required Provider-announced BYOIP: ASN ownership not required; IONOS announces your prefix using AS8560 under a signed LoA once IRR/RPKI prerequisites are met.
BYOASN: ASN ownership required; your ASN is origin, with AS8560 configured as upstream. Your AUTNUM object must explicitly authorise AS8560 as an upstream in RPSL, and ROAs must list your ASN as the origin.
IRR / Route Objects Customers must ensure that relevant IRR databases (e.g. RIPE, ARIN, APNIC) contain accurate, up-to-date information:
– IP range correctly registered (start/end addresses).
– Route objects created and maintained with correct origin AS:
  • BYOIP: origin AS must be AS8560 (IONOS).
  • BYOASN: origin AS is your ASN.
– AS-SET information maintained where applicable.
The official BYOIP/BYOASN requirements article and the 2025 tutorial walk through creating and updating these objects before IONOS will accept announcements.
ROA or LOA RPKI ROAs: Required. Customers must create and keep correct ROAs for their prefixes with the right prefix lengths and origin AS (AS8560 for BYOIP, customer ASN for BYOASN). For IPv4, the maximum prefix length is /24.
Letter of Authorisation (LoA): Required. The signed LoA grants IONOS permission to announce your BYOIP ranges via AS8560 and/or establish BGP sessions with your ASN for BYOASN. The template explicitly lists these permissions and remains valid until revoked or the underlying contract is terminated.
RIR Limitations No specific RIR is mandated; IP ranges and ASNs must be properly registered in the appropriate RIR and IRR databases. The tutorial uses RIPE NCC as the worked example, but the same principles apply to ARIN, APNIC, etc. Customers are responsible for registration and ongoing management with the relevant registries and for keeping IRR/RPKI data accurate and up to date.

Step-by-Step BYOIP Process

Estimated Setup Time: The IONOS BYOIP/BYOASN tutorial indicates that, after IONOS has received a correctly completed approval letter and validated your IRR/RPKI configuration, onboarding and routing are typically activated within up to five business days. Actual timelines can vary, so confirm lead times with IONOS Cloud Support for your specific deployment.

Tested By Us: Not yet

A) Provider-announced BYOIP (IONOS originates your prefixes from AS8560)

  • Request BYOIP onboarding via IONOS Cloud Support or your account manager, specifying that you want provider-announced BYOIP, listing each IPv4 prefix (/24 or larger) and the target environment (VDC Networking, Private Cloud, or both).
  • Verify in your RIR/IRR that the IPv4 range is correctly registered, not being announced elsewhere, and eligible for BYOIP: create or update route objects so origin AS is AS8560 for each prefix and ensure the range is withdrawn from any previous external announcements.
  • Create or update RPKI ROAs for the prefix with origin AS8560 and a maximum prefix length of /24, in line with IONOS guidance and global BGP best practice.
  • Complete and sign the IONOS Letter of Authorisation (LoA), granting IONOS permission to announce your IPv4 range via AS8560 and confirming that IRR, RPKI, and (if relevant) RPSL prerequisites are met.
  • After validation and processing, IONOS imports your BYOIP block into IP Management, starts announcing it from AS8560, and makes the addresses available to your VDC or Private Cloud projects (e.g. NSX segments, NAT, VPN endpoints).
  • Monitor global propagation and reachability using standard tools (BGP looking glasses, RIPEstat, etc.) and adjust firewall, NAT, DNS, and application configuration so traffic flows via the new BYOIP-based addresses.

B) BYOASN + Prefixes (you originate; IONOS as upstream)

  • Verify that your ASN and IPv4 prefixes are correctly registered in the RIR/IRR: create or update route objects so that your ASN is the origin for the onboarded prefixes, and ensure RPKI ROAs exist with your ASN and correct prefix lengths (maximum /24).
  • Update your AUTNUM (ASN) object’s RPSL policy so that AS8560 (IONOS) is explicitly authorised as an upstream, for example with an export policy line of the form `export: TO AS8560 ANNOUNCE your-ASN-or-route-set`.
  • Request BYOASN onboarding from IONOS Cloud Support, providing your ASN, prefixes, IRR details, and existing ROAs; sign the LoA authorising IONOS to establish BGP sessions with your ASN and to forward traffic to and from your network.
  • IONOS provisions BGP toward your ASN from AS8560 in the relevant data center(s) and validates route and ROA state before accepting announcements from your ASN.
  • In the Private Cloud NSX environment (or VDC Networking), configure segments, gateways, and NAT using your BYOIP prefixes; ensure your BGP session is up, your prefixes are being advertised from your ASN, and traffic paths behave as expected.
  • Monitor BGP sessions and end-to-end connectivity; keep IRR, RPKI ROAs, and RPSL policies in sync with your live configuration and maintain LoA validity over time.

References: Bring Your Own IP (BYOIP) address to IONOS Cloud (VDC tutorial, Nov 2025), Requirements for BYOIP/BYOASN, Private Cloud: Using BYOIP in NSX, VDC Networking FAQ (BYOIP/BYOASN question), Letter of Authorisation (LoA), IONOS Cloud Release Notes – November 2025 (BYOIP/BYOASN tutorial announcement).

Cost and Limitations

ItemDetails
Fees No separate BYOIP/BYOASN price list is published in the referenced docs. BYOIP/BYOASN is an add-on to an existing IONOS Cloud contract (Private Cloud and/or VDC). Standard charges for Private Cloud resources, reserved IPs, traffic, and support apply. The BYOIP/BYOASN tutorial highlights using your own IP space and ASN to avoid additional IP rental fees and states that traffic to and from BYOIP/BYOASN addresses is billed at the same rates as platform-managed IPs. Confirm any one-time or recurring BYOIP/BYOASN fees with IONOS Sales.
Bundled or Standalone BYOIP/BYOASN is integrated with IONOS networking and IP Management:
– VDC Networking / Compute Engine: onboarded IPv4 prefixes appear as IP blocks that you can assign to servers and network services like any other public IPv4 block.
– Private Cloud: implemented via NSX (segments, VPN local endpoints, NAT rules) using the same BYOIP/BYOASN approval and validation workflow.
BYOIP/BYOASN is not a stand-alone transit or routing product; it is tied to IONOS infrastructure and services.
Traffic/Peering Restrictions Prefixes must be correctly registered and routable and must comply with IONOS terms and acceptable-use policies. BYOIP IPv4 ranges must not be simultaneously advertised by other providers or networks while onboarded at IONOS; any previous external announcements should be withdrawn before the process starts to avoid unintended anycast routing and potential outages. AS8560 must be listed as origin (BYOIP) or as an authorised upstream (BYOASN) in IRR/RPSL, and prefixes must be RPKI-valid. IONOS reserves the right (per LoA) to decline requests, request additional documentation, or filter problematic routes.
Other Limitations – BYOIP/BYOASN currently applies only to public IPv4 prefixes /24 or larger; private RFC1918 space and IPv6 addresses are configured using standard platform networking features.
– In NSX, BYOIP-backed segments must be more specific than the parent BYOIP range (e.g. a /24 BYOIP can be split into /25, /26, etc. for individual segments).
– BYOASN requires functional BGP and correct RPKI/IRR/RPSL; misconfigured prefixes may be rejected or filtered until corrected.
– Service availability (BYOIP and BYOASN) may vary by data center and product variant, and most official examples use RIPE NCC; customers using other RIRs should expect similar conceptual steps but slightly different tooling. All combinations should be validated with IONOS for each deployment.

Automation & Developer Access

  • API Access: Yes — IONOS Cloud API (REST) covers VDC Networking, Compute, IP Management, and related services. Cloud API docs are available under Developer Reference and allow you to manage resources that consume BYOIP-backed IP blocks once onboarding is complete.
  • CLI: ionosctl — official command line tool to manage IONOS Cloud resources, including data centers, servers, and network objects, from the terminal, suitable for scripting BYOIP-backed infrastructure changes.
  • Terraform: Official IonosCloud Terraform provider (ionos-cloud/ionoscloud) for managing data centers, servers, networks, and IP resources as code, including assigning BYOIP-backed IP blocks to instances and services.
  • SDKs: Cloud SDKs for Go, Java, Ruby, Python, and NodeJS wrap the Cloud API and can be used to orchestrate BYOIP/BYOASN-backed infrastructure programmatically across multiple regions and environments.

Abuse & Reputation Management

  • BYOIP is positioned as a way to preserve established IP reputation during migrations (e.g. email whitelists) while retaining ownership of your address space. Customers remain responsible for the standing of their ranges in RIR/IRR and any third-party reputation lists (blocklists, RBLs, etc.).
  • IONOS requires correct IRR, RPKI, and (for BYOASN) RPSL data and may decline requests or require remediation if prefixes or ASNs are misconfigured or problematic. Ongoing monitoring, abuse handling, delisting, and reputation management for BYOIP/BYOASN ranges remain the customer’s responsibility.

IONOS Cloud Homepage
VDC Networking (Network Services overview)
Bring Your Own IP (BYOIP) address to IONOS Cloud (VDC tutorial)
VDC Networking FAQ (includes BYOIP/BYOASN question)
Service Catalog (locations, IP Management, External Network capacity)
Private Cloud Documentation Hub
Requirements for BYOIP & BYOASN
Private Cloud: Using BYOIP in NSX
Letter of Authorisation (LoA, UK example)
Cloud API SDKs (Go, Java, Ruby, Python, NodeJS)
IonosCloud Terraform Provider
ionosctl CLI Documentation
IONOS Cloud Support

FAQ

BYOIP, or Bring Your Own IP, is a service that enables organizations to bring their own public IP addresses—whether owned outright or leased from an IP provider—into a service provider’s network infrastructure. Instead of relying on IP addresses assigned by the provider, BYOIP allows businesses to retain control over their IP resources. This ensures continuity, particularly for organizations with established IP-based reputations, branding, or dependencies on specific address blocks. IP providers can assist in streamlining this process, making it easy to integrate your IPs into the desired network environment.

BYOIP offers several compelling advantages. By using your own IPs, you can maintain continuity in your network’s identity, reduce the risk of disruptions to email deliverability or service recognition, and avoid reputational concerns associated with shared IPs. Additionally, BYOIP provides enhanced flexibility and control over your IP resources.

BYOIP is ideal for organizations that either own public IP addresses or lease them from a trusted IP provider with explicit BYOIP support. This includes enterprises, cloud providers, content delivery networks (CDNs), and businesses with compliance requirements or IP reputation needs. Working with a reputable IP provider ensures that leased IPs can be seamlessly integrated into another provider’s infrastructure without ownership concerns.

You must either legally own the IP addresses or have explicit authorization from a leasing IP provider to route and manage them. IP providers who offer BYOIP-ready IP addresses simplify this process, providing documentation and support to ensure compliance with regional internet registry (RIR) policies and service provider requirements. This collaboration ensures smooth implementation without any legal or operational issues.

To use BYOIP, you’ll typically need to present documentation verifying your authority over the IP block. This can include official records from a regional internet registry (RIR) such as ARIN, RIPE NCC, or APNIC. If you are leasing IPs, the IP provider should supply proof of their ownership and grant you permission for BYOIP. Providers that specialize in IP leasing often handle this paperwork for you, reducing administrative burden and ensuring compliance.

Yes, BYOIP is designed to be a secure and reliable solution. Reputable service providers and IP providers implement robust safeguards to prevent unauthorized use or hijacking of IP addresses. Security measures include BGP filtering, route validation, and advanced protocols like Resource Public Key Infrastructure (RPKI). By collaborating with a trusted IP provider, businesses can benefit from additional layers of protection, ensuring that only authorized traffic is routed through their IP blocks.

The setup process for BYOIP varies by provider, typically taking anywhere from a few hours to a few days. Factors include the complexity of your network, the verification process for IP ownership or authorization, and the time needed for global BGP route propagation. IP providers often expedite the preparation and validation stages, ensuring a smooth and timely integration into the desired infrastructure.

Absolutely. Many providers, in partnership with IP providers, support routing IPs across multiple data centers or geographic regions. This feature optimizes performance for global businesses by reducing latency and improving service availability. When working with an IP provider, you can also ensure that your leased or owned IPs are aligned with your geographic requirements for compliance and efficiency.

If you choose to discontinue BYOIP with a provider, your IP addresses will be released from their network, and routing will cease. You can then reallocate these IPs for use with a different service provider or project.