BYOIP mit geleastem IPv4: Eigene IPs zu AWS, GCP und Azure bringen

Seit Februar 2024, als AWS begann, öffentliches IPv4 zu berechnen, kostet jede von der Cloud zugewiesene Adresse $0.005 pro IP und Stunde. Das sind etwa $3.65 pro IP und Monat – rund $934 pro Monat für einen Standard-/24-Block mit 256 Adressen. Diese IPv4-Kosten bei AWS – von vielen Betreibern AWS-IPv4-Gebühr genannt – summieren sich im großen Maßstab schnell.

BYOIP-Adressen sind von dieser Gebühr vollständig ausgenommen. Für Betreiber mit vorhandenem Adressraum ist das der einfachste Weg, die IPv4-Gebühren von AWS zu vermeiden.

Wenn Sie einen nennenswerten IPv4-Bestand auf AWS mit von der Cloud zugewiesenen IPs betreiben, zahlen Sie vermutlich jeden Monat mehrere hundert bis mehrere tausend Dollar, die Sie nicht zahlen müssten. So vermeiden Sie die IPv4-Gebühren von AWS per BYOIP mit geleasten Blöcken. Die technische Hürde ist niedriger, als die meisten Betreiber erwarten. Und dieselbe Logik – mit leicht anderer Mechanik – gilt für GCP und Azure.

Dieser Beitrag behandelt, was BYOIP voraussetzt, wie ein BYOIP-fähiges Leasing aussieht und wie Sie geleastes IPv4 zu jedem der drei großen Cloud-Anbieter bringen – einschließlich der Frage, wie BYOIP ohne eigene IPs in der Praxis funktioniert.

Er behandelt außerdem die IPv4-Cloud-Migration per BYOIP für Betreiber, die Workloads aus eigenen Rechenzentren oder anderen Hosting-Umgebungen umziehen. Wenn Sie ungenutztes IPv4 besitzen, das andere per BYOIP nutzen könnten, sehen Sie sich stattdessen an, wie Sie Ihre IPv4-Blöcke monetarisieren.

Dieser Leitfaden ist besonders relevant für Anbieter von Hosting- und Cloud-Infrastruktur, die den Großteil der BYOIP-Nutzer stellen.

Was BYOIP ist und warum es jetzt wichtig ist

Bring Your Own IP (BYOIP) ist eine Funktion von Cloud-Anbietern, mit der Sie IP-Adressraum, den Sie kontrollieren – eigenen oder geleasten –, in deren Netzwerk nutzen, statt vom Anbieter zugewiesene Adressen zu verwenden.

Ihre IPs verhalten sich wie jede andere öffentliche IPv4 auf der Plattform. Sie können sie EC2-Instanzen, Load Balancern, GKE-Nodes oder Azure-VMs zuweisen. Der Unterschied: Sie haben die Adressen mitgebracht, Sie kontrollieren die Reputation, und Sie zahlen nicht die IPv4-Gebühr des Anbieters für dieses Privileg.

Es gibt zwei Gründe, warum das in den letzten zwei Jahren für mehr Betreiber praktische Priorität bekommen hat. Erstens liegen die Preise für öffentliche IPv4-Adressen bei AWS 2026 bei $0.005/IP/Stunde, und die IPv4-Gebühren von AWS gelten für alle von der Cloud zugewiesenen Adressen – Kosten, die es vor Februar 2024 nicht gab. Zweitens hat das BYOIP-v2-Update von GCP im Dezember 2025 eine granularere Zuweisung einzelner IPs aus delegierten Präfixen eingeführt und die Umsetzung bei Google Cloud damit deutlich nutzbarer gemacht für Teams, die IPs über Projekte und Regionen verteilen müssen.

Was die meisten BYOIP-Leitfäden übersehen: Sie müssen IPv4 nicht besitzen, um das zu nutzen. BYOIP mit geleastem IPv4 wird also vollständig unterstützt – Sie brauchen keinen eigenen Adressraum. BYOIP mit geleasten IP-Blöcken wird von allen drei großen Anbietern vollständig unterstützt. Geleaste Blöcke, die die Dokumentationsanforderungen des Anbieters erfüllen – eine gültige LOA, eine korrekt konfigurierte ROA und eine saubere Reputationshistorie –, werden akzeptiert. Sie können IPv4-Blöcke leasen für den Einsatz bei AWS, GCP oder Azure und sie über den normalen BYOIP-Prozess einbringen. Der Betreiber muss diese Voraussetzungen vor Beginn des Cloud-Onboardings mit seinem Leasinggeber klären.

Wie ein BYOIP-fähiges Leasing aussieht

Bevor Sie die AWS Console, das GCP Portal oder die Azure CLI anfassen, sollten Sie fünf Dinge mit Ihrem IP-Leasinggeber klären. Lücken bei einem davon sind der häufigste Grund, warum ein BYOIP-Onboarding verzögert oder abgelehnt wird – viele überschneiden sich mit häufigen Leasing-Fehlern, die Sie vor dem Start durchgehen sollten. Was ein Leasing kostet, sehen Sie unter IPbnb Preise.

Checkliste zu den LOA-Anforderungen:

• Saubere Historie des Blocks

Alle drei Anbieter prüfen die Reputation eines Präfixes, bevor sie es akzeptieren. AWS behält sich ausdrücklich vor, Bereiche mit schlechter Historie abzulehnen. Lassen Sie sich von Ihrem Leasinggeber bestätigen, dass der Block keine nennenswerten Missbrauchseinträge, aktiven Blacklist-Einträge oder Routing-Unregelmäßigkeiten hat. Eine seriöse Plattform kann diese Bestätigung direkt liefern.

• LOA, die die Cloud-Nutzung abdeckt

Der Letter of Authorisation muss gültig und aktuell sein und – das ist wichtig – den konkreten Anwendungsfall erlauben. Nicht alle Leasingverträge decken den BYOIP-Einsatz ausdrücklich ab. Klären Sie das mit Ihrem Leasinggeber vor dem Start, nicht danach.

• Korrekt konfigurierte RPKI-ROA

Für das Präfix muss eine gültige Route Origin Authorization existieren. Für AWS muss die ROA beide AWS-ASNs autorisieren: 16509 und 14618. Für Azure muss sie die ASN von Microsoft (8075) autorisieren. Klären Sie mit Ihrem Leasinggeber, wer während der Laufzeit für Einrichtung und Pflege der ROA verantwortlich ist und was bei der Verlängerung der ROA passiert – bei Blöcken aus der RIPE-Region haben temporäre Transfers eine Höchstlaufzeit von einem Jahr, ROAs können also bei der Verlängerung brechen, wenn der Prozess nicht gesteuert wird. Mehr dazu, wie sich RIPE-Transferbedingungen auf die ROA-Verwaltung auswirken, finden Sie in unserem Leitfaden zur 24-monatigen Haltefrist bei RIPE.

• RIR-Registrierung auf ein Unternehmen

AWS akzeptiert keine Blöcke, die auf natürliche Personen registriert sind. Der RIR-Eintrag muss eine juristische Person als Inhaber ausweisen.

• Rechte zur Unterzuteilung (falls nötig)

Wenn Sie nur einen Teil eines geleasten Blocks in die Cloud bringen möchten, muss das Leasing die Unterzuteilung auf die entsprechende Präfixgröße erlauben. Klären Sie das, bevor Sie annehmen, dass der Vertrag es abdeckt.

Kann Ihr aktueller Anbieter nicht alle fünf Punkte bestätigen, lesen Sie vor dem nächsten Schritt unseren Leitfaden zur Auswahl eines Anbieters für IPv4-Leasing.

AWS BYOIP

AWS Bring Your Own IP (BYOIP) ist die ausgereifteste Umsetzung und bietet den klarsten Preisvorteil. Mit AWS BYOIP nutzen Sie Adressraum, den Sie kontrollieren – auch geleaste Blöcke –, im AWS-Netzwerk, befreit von der Gebühr für öffentliches IPv4, die für alle von der Cloud zugewiesenen Adressen gilt.

IPv4-Kosten bei AWS: Was Sie tatsächlich zahlen

Die IPv4-Kosten bei AWS für von der Cloud zugewiesene Adressen betragen $0.005 pro IP und Stunde. Bei den aktuellen Preisen für öffentliche IPv4-Adressen von AWS entspricht das ~$3.65 pro IP und Monat. Der Preisvorteil von AWS BYOIP: $0 für eingebrachte IPs gegenüber $3.65 pro Monat und von der Cloud zugewiesener IP. Bei einem /24 ist der Unterschied erheblich:

Die IPv4-Gebühren von AWS gelten für jede von der Cloud zugewiesene Adresse ab dem Moment der Zuweisung, unabhängig davon, ob sie an eine laufende Instanz gebunden ist. Ein BYOIP-Setup bei AWS beseitigt diese Kosten für den eingebrachten Bereich vollständig. Um zu sehen, was ein geleastes /24 im Vergleich zu Ihren aktuellen AWS-Ausgaben kosten würde, berechnen Sie Ihre Leasingkosten.

Anforderungen:

• Minimale Präfixgröße: /24

• Block auf ein Unternehmen registriert (keine natürliche Person)

• Gültige ROA für das Präfix

• RDAP-Eintrag bei Ihrer RIR aktualisiert

• Legacy-IPv4-Adressraum braucht ein ROA-Objekt, auch wenn er älter als das RIR-System ist – er ist von der ROA-Pflicht nicht ausgenommen

• Maximal 5 BYOIP-Bereiche pro AWS-Region und Konto (Kontingenterhöhung über den AWS Support möglich)

Einrichtung:

1. Bestätigen, dass der Block die obigen Anforderungen erfüllt – saubere Historie, mindestens /24, Registrierung auf ein Unternehmen, gültige ROA, aktuelles RDAP

2. Auf Ihrem lokalen Rechner ein RSA-Schlüsselpaar erzeugen

3. Mit diesem Schlüsselpaar ein selbstsigniertes X.509-Zertifikat erzeugen

4. Den Bereitstellungsantrag per AWS CLI mit dem Zertifikat einreichen

5. AWS prüft die Kontrolle per RDAP-Abfrage und ROA-Bestätigung

6. Nach der Validierung das Präfix aus Ihrem AWS-Konto ankündigen

7. Einzelne Elastic IPs oder IP-Präfixe aus dem eingebrachten Bereich Ihren EC2-Instanzen, Load Balancern, NAT-Gateways oder anderen Ressourcen zuweisen

Ein wichtiger operativer Hinweis: Nehmen Sie keine manuellen Änderungen an RADb oder einer anderen IRR-Datenbank für dieses Präfix vor, sobald der BYOIP-Prozess bei AWS begonnen hat. AWS aktualisiert RADb im Rahmen der Bereitstellung automatisch. Jeder manuelle Eintrag mit der BYOIP-ASN lässt die Bereitstellung scheitern.

AWS BYOIP funktioniert mit EC2, Global Accelerator, VPC IPAM und mehreren weiteren Diensten. In Wavelength Zones und auf AWS Outposts wird es nicht unterstützt.

GCP BYOIP: Eigene IPs zu Google Cloud bringen

GCP BYOIP nutzt eine Hierarchie aus Public Advertised Prefix (PAP) und Public Delegated Prefix (PDP). Bring Your Own IP bei GCP funktioniert über diese zweistufige Struktur, und das BYOIP-v2-Update vom Dezember 2025 hat die granulare Steuerung deutlich verbessert – mit der Zuweisung einzelner IP-Adressen aus delegierten Präfixen. Das zählt, wenn Sie einen einzelnen geleasten Block auf mehrere GCP-Projekte verteilen oder einzelne /32-Adressen einsetzen müssen, statt immer mit Teilbereichen zu arbeiten.

Anforderungen:

• Minimales Präfix: /24

• ROA, die die ASN 396982 von Google Cloud zur Ankündigung des Präfixes autorisiert

• DNS-Verifizierung per PTR-Eintrag (bei v2-Präfixen konfigurieren Sie einen PTR-Eintrag für eine von Google Cloud bereitgestellte Verifizierungs-IP)

• Der Block darf sich nicht mit einem anderen extern angekündigten Präfix überschneiden, das Sie kontrollieren – GCP lehnt überlappende Ankündigungen importierter Präfixe ausdrücklich ab

Einrichtung:

1. Ein Public Advertised Prefix (PAP) in der GCP Console oder per gcloud compute public-advertised-prefixes create anlegen

2. Kontrolle nachweisen – GCP prüft die ROA (ASN 396982) und einen PTR-Eintrag. Bei v2-Präfixen konfigurieren Sie einen PTR-Eintrag für die Verifizierungs-IP, die Google Cloud nach dem Anlegen des PAP bereitstellt. Planen Sie vor dem Einreichen Zeit für die Verbreitung der ROA ein

3. Sobald das PAP validiert und in Betrieb genommen ist, beginnt GCP, das Präfix intern und im Internet anzukündigen

4. Das PAP in Public Delegated Prefixes (PDPs) für bestimmte Regionen oder Projekte aufteilen. Die Hierarchie PAP → PDP ist verpflichtend – Sie können Adressen nicht direkt aus einem PAP nutzen

5. Mit BYOIP v2 (ab Dezember 2025): einzelne IP-Adressen aus delegierten Präfixen per erweiterter IP-Zuweisung erstellen. So lassen sich einzelne IPs Load Balancern, VMs oder Forwarding Rules zuweisen, ohne ein ganzes Teilpräfix zu verbrauchen

Ein Planungshinweis: Die Struktur PAP → PDP bedeutet, dass Sie Ihren Zuteilungsplan vor der Bereitstellung festlegen sollten. Entscheiden Sie vorab, welche Regionen welche Präfixgrößen brauchen und ob Sie den erweiterten Zuweisungsmodus von v2 benötigen. BYOIP-Adressen lassen sich nach der Zuweisung nicht zwischen GCP-Projekten verschieben – die Aufteilung muss also beim ersten Mal stimmen. Ein strukturierter Ansatz für die IP-Adressverwaltung bei geleastem IPv4 hilft, das Subnetz-Layout zu planen und festzuhalten, was wo zugewiesen ist, bevor Sie sich festlegen.

Azure BYOIP: Bring Your Own IP mit Custom IP Prefix

Azure BYOIP wird über Custom IP Prefix umgesetzt. Mit Bring Your Own IP bei Azure nutzen Sie Adressraum, den Sie kontrollieren – eigenen oder geleasten –, im Azure-Netzwerk, ohne Gebühr für Custom IP Prefixes oder für daraus abgeleitete öffentliche IP-Adressen. Die Kostenlogik ist bei allen drei Anbietern dieselbe.

Die Umsetzung bei Azure hat einige Unterschiede, die Sie vor dem Start kennen sollten.

Anforderungen:

• Präfixgröße /24 bis /21 (Unified Prefix); bei der global/regionalen Hierarchie muss das Parent-Präfix /21–/24 sein, regionale Child-Präfixe reichen von /22 bis /26

• Gültige ROA, die die ASN 8075 von Microsoft zur Ankündigung des Präfixes autorisiert

• RIR-Registrierung auf ein Unternehmen

• Maximal 5 Custom IP Prefixes pro Region (auf Anfrage erhöhbar)

Einrichtung:

1. Bestätigen, dass der Block bei Ihrer RIR auf ein Unternehmen registriert ist

2. Bei Ihrer RIR eine ROA konfigurieren, die die ASN 8075 (Microsoft) zur Ankündigung des Präfixes autorisiert

3. Im Azure Portal zu Custom IP Prefixes gehen und das Präfix zur Bereitstellung einreichen

4. Azure prüft die Kontrolle – sowohl Ihre RIR-Einträge als auch die ROA. Das dauert je nach Reaktionszeit der RIR typischerweise einige Stunden bis einige Tage

5. Nach Bereitstellung und Inbetriebnahme Public IP Prefixes aus dem Custom Prefix ableiten

6. Einzelne öffentliche IPs der Standard SKU aus diesen Präfixen Ihren Azure-Ressourcen zuweisen: VMs, Standard Load Balancer, NAT-Gateways, Application Gateways

Azure-spezifische Einschränkungen, die Sie vor dem Start kennen sollten:

Azure unterstützt BYOIP nicht für ausgehendes SMTP. Wenn Sie von Ihren geleasten IPs auf Azure E-Mails versenden möchten, ist das ein K.-o.-Kriterium – ziehen Sie für diesen Anwendungsfall stattdessen AWS in Betracht.

Reverse DNS bei Azure BYOIP erfordert eine selbst gehostete rDNS-Zone. Die verwalteten DNS-Zonen von Azure unterstützen Reverse DNS für Custom IP Prefixes nicht nativ – Sie müssen PTR-Einträge selbst oder über Ihren IP-Anbieter konfigurieren.

Azure abstrahiert BGP vollständig. Sie peeren für die Präfixankündigung nicht direkt mit dem Azure-Netzwerk. Microsoft übernimmt alle Routenankündigungen intern, sobald das Präfix in Betrieb ist. Es gibt keine direkte BGP-Session zu verwalten.

IP-Reputationsmanagement: Was sich ändert, wenn Ihr Leasing in die Cloud geht

Die meisten BYOIP-Leitfäden enden bei „Präfix erfolgreich angekündigt“. Die operative Realität nicht.

Wird ein geleaster Block per BYOIP eingesetzt, laufen Ihre Cloud-Workloads auf Adressen, für deren guten Ruf letztlich der IP-Eigentümer verantwortlich ist. Jeder Missbrauch, den diese Workloads erzeugen – ausgehender Spam, Port-Scans, übermäßige API-Anfragen, Scraping im großen Stil –, lässt sich nun auf Adressen zurückführen, die mit einer realen Organisation und einer realen RIR-Registrierung verbunden sind.

Cloud-Umgebungen können Missbrauchsmuster erzeugen, die es in eigenen Rechenzentren nicht gibt. Container-Orchestrierung mit häufig wechselnden Pods, Massen-E-Mail-Versand, Web-Crawling im großen Maßstab und Lasttests gegen externe Ziele sind typische Cloud-Workloads, die Abuse-Meldungen in großer Zahl auslösen.

Der Mieter sollte das Reputationsmanagement bei BYOIP als laufende operative Verantwortung behandeln, nicht als Einrichtungsaufgabe. Das heißt: ausgehenden Traffic auf Missbrauchsmuster überwachen, klare Nutzungsregeln für interne Teams festlegen, die den IP-Adressraum nutzen, und einen definierten Prozess für Abuse-Meldungen haben, die beim IP-Eigentümer eingehen – denn dort kommen sie an, nicht nur in Ihrem Cloud-Konto. Der Ansatz von IPbnb zu Compliance und IP-Reputationsmanagement beschreibt, wie das auf Plattformebene gehandhabt wird.

Ein BYOIP-Einsatz verringert Ihre Pflichten im Umgang mit Missbrauch nicht. In manchen Umgebungen erhöht er sie.

Häufige Fehlerquellen

Daran scheitert ein BYOIP-Onboarding typischerweise:

Abgelaufene oder nicht passende ROA. Die ROA muss zum Zeitpunkt der Einreichung gültig sein und die ASN des Anbieters korrekt autorisieren. Eine ROA, die mitten im Prozess abläuft – oder für eine andere ASN konfiguriert wurde –, lässt die Validierung mal still, mal deutlich scheitern. Prüfen Sie den ROA-Status unmittelbar vor dem Einreichen.

LOA, die BYOIP nicht abdeckt. Der Leasingvertrag erlaubt womöglich das Routing in Ihre eigene Infrastruktur, sagt aber nichts über die Übertragung von Ankündigungsrechten an die ASN eines Cloud-Anbieters. Lesen Sie den Vertrag oder fragen Sie den Leasinggeber vor dem Start.

Belastete Historie des Blocks. Steht das Präfix auf großen Blocklists oder gibt es jüngere Abuse-Meldungen, kann die Reputationsprüfung des Cloud-Anbieters es bei der Validierung ablehnen. Den Block vor dem Einreichen mit gängigen Tools zur IP-Reputationsüberwachung (MXToolbox, Spamhaus, IPVoid) zu prüfen, ist fünf Minuten wert.

Manuelle IRR-Änderungen bei AWS. Wie oben erwähnt: Bearbeiten Sie RADb oder andere IRR-Einträge nicht manuell für ein Präfix, das Sie per AWS BYOIP bereitstellen. AWS automatisiert das, und manuelle Einträge für die BYOIP-ASN brechen den Prozess.

Überlappende Ankündigungen bei GCP. Wird das Präfix bereits extern angekündigt – aus Ihrer eigenen ASN oder von einem anderen Anbieter –, lehnt GCP BYOIP es ab. Das Präfix darf beim Einreichen des PAP nicht aktiv extern angekündigt sein.

Ein Hinweis zu geleasten Blöcken: BYOIP ohne eigene IPs

Die obigen Schritte gelten, ob Sie Ihren IPv4-Adressraum besitzen oder leasen. Wenn Sie IPv4 für den Cloud-Einsatz leasen, sind die Schritte identisch mit eigenen Blöcken – der Prozess beim Cloud-Anbieter ändert sich nicht. BYOIP ohne eigene IPs ist vollständig machbar – was den Leasingfall vom Eigentumsfall unterscheidet, sind die operativen und vertraglichen Voraussetzungen. Wenn Leasing neu für Sie ist, ist So funktioniert IPv4-Leasing eine nützliche Einführung. Wenn Sie abwägen, ob Sie Ihren Adressraum verkaufen oder halten, sehen Sie sich unseren Vergleich Verkaufen vs. Leasen von IPv4 an.

Ein BYOIP-fähiges Leasing sollte Ihnen einen sauberen Block mit dokumentierter Historie, eine LOA, die den Einsatz bei Cloud-Anbietern ausdrücklich abdeckt, korrekt konfiguriertes RPKI mit festgelegter Verantwortung für die Pflege und eine RIR-Registrierung auf ein geeignetes Unternehmen bieten. BYOIP mit geleastem IPv4 funktioniert beim Cloud-Anbieter genau wie BYOIP mit eigenem Adressraum – der Unterschied liegt ausschließlich darin, was Sie vor dem Start mit Ihrem Leasinggeber klären.

Bestätigt Ihr aktuelles Leasing diese Voraussetzungen nicht, klären Sie sie vor Beginn des Onboardings – nicht nachdem Sie eine Woche auf eine abgelehnte Validierung beim Cloud-Anbieter gewartet haben.

IPbnb stellt LOA-Dokumentation, RPKI-Einrichtung und Abuse-Management als Teil des Leasings bereit. Wenn Sie Blöcke suchen, die bereit für einen Cloud-Anbieter sind, ist der IP-Katalog der richtige Startpunkt.

Zusammenfassung

BYOIP beseitigt IPv4-Gebühren in der Cloud bei allen drei großen Anbietern – AWS, GCP und Azure nehmen eingebrachte Präfixe von ihren Gebühren für öffentliche IPs aus. Ob AWS BYOIP, GCP BYOIP oder Azure BYOIP: Die Einrichtung ist für jeden Betreiber mit einem sauberen geleasten Block und der richtigen Dokumentation unkompliziert. Die IPv4-Cloud-Migration per BYOIP ist einer der kosteneffizientesten Schritte für Betreiber mit nennenswertem IPv4-Bestand in der Cloud.

Die Voraussetzungen sind bei allen Anbietern gleich: eine saubere Reputationshistorie, eine gültige, aktuelle LOA, die den Cloud-Einsatz abdeckt, korrektes RPKI und eine RIR-Registrierung auf ein Unternehmen. BYOIP mit geleasten IP-Blöcken folgt demselben Weg – klären Sie zuerst Leasingvertrag, ROA und Historie des Blocks. Der Rest ergibt sich. Für Betreiber, die ihre IPv4-Kosten bei AWS senken und gleichzeitig die Kontrolle über ihre IP-Reputation behalten möchten, ist BYOIP mit geleastem IPv4 der praktikabelste Weg.

BYOIP-fähige IPv4-Blöcke leasen → IP-Katalog ansehen