Geleastes IPv4 zu Google Cloud bringen: BYOIP-Leitfaden

Die Rechnung kommt am Dritten des Monats, und endlich liest jemand die Position für Networking.

Eine bekannte Geschichte. Ein Team migriert ein paar hundert Workloads zu Google Cloud, alles läuft hervorragend, und niemand denkt an IP-Adressen, bis die Finanzleitung eine Zahl einkreist und fragt, wofür sie ist. Die Antwort ist unangenehm: Das Unternehmen mietet öffentliche IPv4-Adressen stundenweise von Google, zusätzlich zur Rechenleistung, an die diese Adressen gebunden sind. Und es zahlt diese Miete für immer, denn die Adressen gehören Google, nicht dem Unternehmen.

Es gibt eine zweite Version derselben Geschichte, die anders endet. Darin hat das Team bereits ein /24 – eigenes oder von einem IP-Inhaber geleastes – und bringt es zu Google Cloud. Die Adressen behalten ihre Reputation, ihre Whitelisting-Historie, ihr Reverse DNS. Die stündliche Gebühr für externe IPs entfällt. Es bleibt nur das Leasing selbst – ein planbarer Posten, den das Unternehmen kontrolliert.

Der Mechanismus für die zweite Version heißt GCP BYOIP, und dieser Leitfaden geht ihn von Anfang bis Ende durch: was er kostet, wie das zweistufige Präfixmodell funktioniert, was Google tatsächlich verifiziert, wie lange die Bereitstellung dauert und was sich ändert, wenn der IP-Block geleast statt gekauft ist.

GCP-Preise für externe IPs 2026: Was Sie tatsächlich zahlen

Vor der Migrationsmechanik hilft ein Blick auf die Zahl, die die Migration beseitigen soll. Googles aktuelle Preise für externe IP-Adressen sehen so aus:

Zwei Details in dieser Tabelle überraschen die meisten.

Erstens kostet eine ungenutzte Adresse doppelt so viel wie eine genutzte. Google hat im Februar 2024 die Preise für genutzte VM-Adressen erhöht (von $0.004 auf $0.005 für Standard-VMs und von $0.002 auf $0.0025 für Spot), den Satz für nicht zugewiesene statische Adressen aber bei $0.01 belassen. Eine reservierte Adresse ohne Funktion kostet also $7.30 im Monat, dieselbe Adresse an einer laufenden VM $3.65. Teams, die Adresspools „für später“ reservieren, zahlen dafür einen Aufpreis.

Das zweite Detail ist für alle wichtig, deren Traffic über einen Load Balancer läuft: An Forwarding Rules gebundene Adressen sind bereits kostenfrei. Liegt Ihre gesamte Umgebung hinter externen Load Balancern, sind die Preise für externe IPs nicht Ihr Problem, und BYOIP spart Ihnen bei diesem Posten nichts. BYOIP spart dort, wo Adressen an VMs und Cloud-NAT-Gateways gebunden sind.

Hochgerechnet sieht ein volles /24 – 256 Adressen – so aus, wenn jede Adresse auf Standard-VMs genutzt wird:

256 × $0.005 × 730 = $934.40 pro Monat bzw. $11,212 pro Jahr.

Auf Spot-Instanzen kostet derselbe Block $467.20 pro Monat. Reserviert und ungenutzt kostet er $1,868.80 pro Monat. Das sind Obergrenzen; reale Umgebungen mischen die Zustände. Sie zeigen aber die Größenordnung dessen, worum es geht.

Dem stellt Googles eigene Dokumentation die BYOIP-Position in einem Satz gegenüber: Für ungenutzte oder genutzte IP-Adressen fallen keine Gebühren an. Sobald Ihr Präfix importiert ist, sind daraus bezogene Adressen in jedem Zustand kostenfrei – zugewiesen, nicht zugewiesen, auf einer Standard-VM, auf einer Spot-VM, hinter Cloud NAT.

So funktioniert GCP BYOIP: zwei Präfixe, nicht eines

Die häufigste Quelle der Verwirrung bei Google Cloud BYOIP ist, dass es zwei verschiedene Präfixobjekte mit unterschiedlichen Aufgaben gibt. Wer diese Aufteilung versteht, für den ist der Rest des Prozesses einfach.

Das Public Advertised Prefix (PAP) ist der Block, den Google in Ihrem Namen im Internet ankündigt. Es ist eine einzelne Einheit der Routenankündigung. An dieses Objekt sind Ihre ROA und Ihre Reverse-DNS-Validierung gebunden, und dieses Objekt braucht Wochen für die Bereitstellung. Für IPv4 im Premium Tier kann ein PAP zwischen /16 und /24 liegen – ein /24 ist also der kleinste Block, den Sie mitbringen können, genau wie bei jedem anderen Cloud-BYOIP-Programm, denn /24 ist das kleinste Präfix, das die globale Routing-Tabelle zuverlässig akzeptiert.

Das Public Delegated Prefix (PDP) ist ein Teil dieses PAP, der einem bestimmten Projekt und einem bestimmten Geltungsbereich zugewiesen ist – einer einzelnen Region oder global. Hier werden die Adressen nutzbar. Ein PDP der obersten Ebene kann in der empfohlenen regionalen v2-Konfiguration /16 bis /28 groß sein und so groß wie das übergeordnete PAP oder kleiner. Ein PDP lässt sich dann in Sub-Präfixe bis minimal /28 aufteilen, die an verschiedene Projekte Ihrer Organisation delegiert werden können. Aus einem einzelnen PAP ist bis zu dreimal eine Unterdelegation möglich.

Der praktische Nutzen dieser Aufteilung: Der langsame, Registry-seitige Teil des Prozesses findet einmal auf PAP-Ebene statt, der schnelle, organisationsseitige Teil wiederholt auf PDP-Ebene. Ein als ein PAP eingebrachtes /24 lässt sich in sechzehn /28-Subnetze aufteilen, verteilt auf sechzehn Projekte und Regionen, ohne BGP erneut anzufassen.

Eine harte Einschränkung bestimmt alles Weitere: Google unterstützt keine überlappenden BYOIP-Ankündigungen. Wird ein Präfix – oder ein Teil davon – irgendwo außerhalb von Google angekündigt, darf Google es nicht gleichzeitig ankündigen. Beides zusammen führt zu unvorhersehbarem Routing und Paketverlust. Diese eine Regel prägt die gesamte Umstellungsstrategie und ist der Grund für die Reihenfolge im Zeitplan unten.

Außerdem gibt es eine neuere Funktion, die Sie kennen sollten. Für v2-IPv4-Delegated-Prefixes und Sub-Präfixe, die nach dem 13. Dezember 2025 erstellt wurden, hat Google die erweiterte IP-Adresszuweisung aktiviert, mit der Sie einzelne Adressen aus einem Delegated Prefix erstellen können. Ältere Präfixe konnten nur Adressgruppen von /17 bis /28 erzeugen, also mindestens sechzehn Adressen auf einmal. Wenn Sie heute bereitstellen, erhalten Sie das granulare Verhalten.

Anforderungen: Was Google prüft, bevor es Ihren Block routet

Google validiert die Kontrolle über zwei Nachweise. Beide müssen vor Beginn der Bereitstellung vorhanden sein, und beide sind die häufigste Ursache für Verzögerungen, wenn sie fehlen.

1. Eine Route Origin Authorization (ROA), die Googles ASN benennt. Sie erstellen sie bei Ihrer RIR – RIPE NCC, ARIN, APNIC, LACNIC oder AFRINIC. Die ROA muss das exakte Präfix und die Präfixlänge Ihres PAP abdecken und die richtige Google-ASN für die gewählte Netzwerkstufe autorisieren:

• Premium Tier (Standard): AS 396982

• Standard Tier (Preview): AS 19527, entweder als separate ROAs für das PAP und jedes PDP der obersten Ebene oder als eine einzelne ROA mit maxLength /24

Google empfiehlt außerdem, eine zweite ROA für dasselbe Präfix mit Ihrer eigenen ASN als Origin anzulegen. Das kostet nichts und bedeutet: Falls Sie den Block jemals wieder selbst ankündigen müssen, verwerfen RPKI-validierende Netzwerke Ihre Route nicht als ungültig.

Beachten Sie, dass die ROA noch eine Zeit lang nach dem Löschen des PAP bestehen bleiben muss – sie ist nichts, was Sie im Moment des Migrationsabschlusses widerrufen.

2. Ein Reverse-DNS-PTR-Eintrag. Beim Anlegen des PAP benennen Sie eine ungenutzte Adresse aus dem Block als Verifizierungsadresse. Google liefert einen generierten Hostnamen zurück (in der API als sharedSecret bereitgestellt). Diesen PTR-Eintrag für die Adresse veröffentlichen Sie in der DNS-Zone Ihres Blocks und lassen ihn dann von Google validieren. Bei Erfolg wechselt der Status zu VALIDATED, andernfalls zu REVERSE_DNS_LOOKUP_FAILED.

An dieser zweiten Anforderung scheitern geleaste Blöcke am häufigsten; sie wird unten in einem eigenen Abschnitt behandelt.

Zwei weitere Voraussetzungen sind organisatorischer statt technischer Natur. Jemand benötigt die Rolle Compute Public IP Admin (roles/compute.publicIpAdmin), und Google empfiehlt, die Präfixverwaltung in einem eigenen Projekt zu isolieren, statt sie mit den Projekten zu mischen, die die Adressen nutzen. Mit Shared VPC können Adressen im Host-Projekt erstellt und von Service-Projekten genutzt werden, aber nicht in einem Service-Projekt erstellt werden.

Prüfen Sie außerdem vor Ihrer Entscheidung: Nicht jede Ressource akzeptiert BYOIP-Adressen. GKE-Nodes und Pods nicht. Externe Adressen von Cloud-VPN-Gateways, Classic oder HA, ebenfalls nicht – eine BYOIP-Adresse kann jedoch als Peer-Adresse eines Classic-VPN-Tunnels dienen. Und verwaltete Instanzgruppen, die Adressen automatisch zuweisen, nicht – zustandsbehaftete MIGs mit statischen Adressen, die bei der VM-Erstellung zugewiesen werden, dagegen schon. Gleichen Sie Ihre Architektur mit Googles Liste unterstützter Ressourcen ab, bevor das Leasing unterschrieben wird.

Schritt für Schritt: der gcloud-BYOIP-Workflow

Die gcloud-BYOIP-Befehle befinden sich unter gcloud compute public-advertised-prefixes und gcloud compute public-delegated-prefixes. Der vollständige Ablauf:

Schritt 1 – ROA bei Ihrer RIR anlegen. Tun Sie das zuerst und früh. Die Bearbeitung bei der RIR liegt weder in Googles noch in Ihrer Hand.

Schritt 2 – Public Advertised Prefix anlegen. Für die empfohlene regionale v2-Konfiguration:

Namen lassen sich später nicht ändern, ohne die Ressource zu löschen und neu anzulegen – verwenden Sie daher eine generische, dauerhafte Konvention wie pap-203-0-113-0-24.

Schritt 3 – Validierungs-Hostnamen abrufen und PTR-Eintrag veröffentlichen.

Veröffentlichen Sie den PTR-Eintrag und starten Sie dann die Validierung:

Schritt 4 – Auf die Bereitstellung warten und die Wartezeit sinnvoll nutzen. Während das PAP bereitgestellt wird, legen Sie Ihre Public Delegated Prefixes und Sub-Präfixe an. Bei v2 dauert das Minuten, nicht Wochen, und sie können angelegt werden, bevor das übergeordnete Präfix fertig bereitgestellt ist.

Schritt 5 – Adressen erstellen und an Ressourcen binden. Aus einem PDP bezogene Adressen funktionieren nur innerhalb des Projekts und Geltungsbereichs, an die sie delegiert wurden. Jede Adresse im Block ist nutzbar – es gibt keine reservierte Subnetz- oder Broadcast-Adresse, ein /28 liefert also sechzehn nutzbare Adressen, nicht vierzehn.

Schritt 6 – Ankündigen. Bei v2-Präfixen wird nichts automatisch angekündigt. Sie kündigen zuerst ein PDP an, dann das übergeordnete PAP:

Zeitplan: Womit Sie rechnen sollten

Googles Dokumentation nennt Bereitstellungszeiten, erklärt aber nicht, was den Kalender füllt. So sieht es realistisch aus:

Ein Hinweis, falls Sie die Dokumentation selbst prüfen: Die Seite zur Statusprüfung nennt noch pauschal vier Wochen – eine Angabe aus der Zeit vor der v2-Konfiguration. Die Vergleichstabelle in derselben Dokumentation ist aktuell. Planen Sie bei v2 mit zwei Wochen, wundern Sie sich aber nicht, wenn Googles eigene Oberfläche Ihnen die ältere Zahl nennt.

Die Kernaussage lautet also zwei bis vier Wochen – und welches Ende es wird, hängt von der gewählten Konfiguration ab. Die regionale v2-Konfiguration wird in etwa zwei Wochen bereitgestellt. Die ältere v1-Konfiguration und die globale Konfiguration brauchen etwa vier, und für global muss Ihr Projekt zusätzlich über einen Support-Fall auf eine Allowlist gesetzt werden – das kostet weitere Kalenderzeit, bevor die Uhr überhaupt zu laufen beginnt.

Das Deprovisionieren dauert noch länger, und das überrascht viele. Ein Delegated Prefix von einer Region in eine andere zu verschieben erfordert Löschen und Neuanlegen, was Google mit etwa acht Wochen veranschlagt. Entscheiden Sie, wo Ihre Adressen liegen sollen, bevor Sie bereitstellen – nicht danach.

Die beiden Gründe, warum Teams steckenbleiben, sind beide vermeidbar. Erstens: Die ROA bei der RIR erst nach dem PAP anzulegen, kostet vorne Tage. Zweitens: In der Validierung festzustellen, dass niemand das Reverse DNS für den Block kontrolliert, kostet so lange, wie die Delegation dauert.

Die Umstellung: Traffic verschieben ohne Umnummerierung

Hier zeigt die v2-Konfiguration ihren Wert, und es lohnt sich, das genau zu verstehen, denn das Internet erlaubt nicht, denselben Block gleichzeitig von zwei Stellen anzukündigen.

Bei einem v2-Public-Advertised-Prefix sind Bereitstellung und Ankündigung getrennte Ereignisse. Google schließt die gesamte interne Konfiguration für Ihren Block ab und wartet dann. Nichts wird angekündigt, bis Sie den Ankündigungsbefehl geben. Das verschafft Ihnen ein Staging-Fenster: Ihre Adressen existieren in Google Cloud, gebunden an echte VMs und echte Load Balancer, vollständig konfiguriert und testbar – während Ihr bisheriger Provider den Block noch ankündigt und Live-Traffic transportiert.

Die Umstellung selbst ist dann ein koordiniertes Paar von Aktionen statt eines Umnummerierungsprojekts:

1. Alles in Google Cloud aufbauen und validieren, Präfix nicht angekündigt.

2. Die Ankündigung aus Ihrem bestehenden Netzwerk oder beim Upstream zurückziehen.

3. In Google Cloud das PDP und dann das PAP ankündigen.

Der Traffic folgt der Routing-Tabelle. Anwendungskonfiguration, DNS-Einträge, Firewall-Allowlists und Partner-Integrationen, die auf Ihre Adressen verweisen, ändern sich nie, weil sich die Adressen nie ändern. Die Konvergenz in der globalen Routing-Tabelle dauert Minuten und lässt sich in ein Wartungsfenster einplanen statt in ein Migrationsquartal. Derselbe gestaffelte Ansatz gilt, ob Sie in eine Cloud oder zwischen Netzwerken wechseln – unser Leitfaden zur Migration auf geleastes IPv4 ohne Ausfallzeit behandelt die DNS- und TTL-Seite derselben Operation.

Ein feiner, für schrittweise Migrationen nützlicher Punkt: Sie können ein Public Delegated Prefix innerhalb von Google Cloud ankündigen, ohne das übergeordnete Public Advertised Prefix im Internet anzukündigen. So können Sie einen Teil intern in Betrieb nehmen, während der Block als Ganzes noch anderswo angekündigt wird.

Ein Hinweis zu älterem Material, das Sie online finden. Googles Bitly-Fallstudie von 2019 wird für ihren BYOIP-Umstellungsansatz noch häufig zitiert, doch Google hat dem Beitrag inzwischen einen Hinweis hinzugefügt, dass die beschriebene Umstellungsmethode nicht mehr unterstützt wird. Arbeiten Sie mit der aktuellen Dokumentation.

Wenn Ihr /24 geleast und nicht gekauft ist

Alles oben setzt voraus, dass Sie als Inhaber des IP-Blocks handeln können. Wenn Sie leasen statt besitzen, liegen einige dieser Schritte bei jemand anderem, und der Leasingvertrag muss entsprechend gestaltet sein.

Die ROA erstellt der registrierte Inhaber, nicht Sie. Die Befugnis zur RPKI-Signierung liegt bei demjenigen, der die Ressource bei der RIR hält. Ihr Leasinggeber muss bereit und in der Lage sein, eine ROA anzulegen, die Googles ASN für Ihr Präfix autorisiert, und sie für die gesamte Laufzeit plus die Deprovisionierungsphase bestehen zu lassen. Ein IP-Eigentümer, der das nicht anbietet, kann kein Cloud-BYOIP unterstützen – egal, was im Angebot steht.

Reverse DNS muss an Sie delegiert werden. Googles Validierung erfordert einen PTR-Eintrag in der DNS-Zone des Blocks. Entweder delegiert der Leasinggeber die Reverse-Zone an Ihre Nameserver, oder er sagt zu, den konkreten Validierungseintrag auf Anfrage zu veröffentlichen. Klären Sie vor der Unterschrift, welche Variante gilt, und auch die Bearbeitungszeit – ein Leasinggeber, der drei Wochen für einen PTR-Eintrag braucht, hat Ihre Migration um drei Wochen verlängert.

Die Laufzeit muss den gesamten Lebenszyklus abdecken. Zwei bis vier Wochen Bereitstellung, die Betriebsdauer der Umgebung und bis zu acht Wochen, falls Adressen jemals die Region wechseln müssen. Ein Zwölf-Monats-Leasing für einen Block, dessen Bereitstellung einen Monat dauert, ist in Wahrheit ein Elf-Monats-Leasing.

Exklusivität und Ankündigungsrechte müssen ausdrücklich geregelt sein. Da Google keinen Block ankündigen kann, der anderswo angekündigt wird, muss der Vertrag garantieren, dass während der Laufzeit keine andere Partei Ihr Präfix ankündigt. Untervermietete oder geteilte Blöcke sind mit BYOIP nicht vereinbar.

Registry-Einträge sollten sauber und konsistent sein. Google prüft die Kontrolle über ROA und Reverse DNS, nicht über RDAP oder whois. Ihre Peers, die Sicherheitsteams Ihrer Kunden und die Betreiber von Abuse-Datenbanken lesen jedoch RDAP – korrekte, aktuelle Einträge bleiben daher eine praktische Anforderung, auch wenn sie keine formale Hürde bei Google sind.

Bei IPbnb gestalten wir Leasingverträge genau entlang dieser Anforderungen, denn ein geleaster Block, der die Cloud-Verifizierung nicht besteht, ist kein wirklich nutzbarer Block. Wenn Sie IP-Mieter oder IP-Eigentümer für eine Cloud-Migration bewerten, behandeln Sie ROA-Unterstützung, Reverse-DNS-Delegation und Exklusivität der Ankündigung als K.-o.-Kriterien, nicht als nette Extras.

Kostenrechnung: ein geleastes /24 auf GCP

Die Zahlen nebeneinander für ein /24, das vollständig auf Standard-VMs genutzt wird:

Entscheidend ist der Vergleich der letzten beiden Zeilen mit der ersten: Die Gebühr für externe IPs bei Google fällt auf null und wird durch ein Leasing ersetzt, das weniger als ein Zehntel davon kostet. Bei einem voll genutzten /24 liegt die Ersparnis bei rund $10,100 bis $10,300 pro Jahr – und der Block bringt eine etablierte Reputation und eine saubere Historie mit, die keine frisch zugewiesene Cloud-Adresse hat.

Zur Einordnung: Die marktüblichen Leasingpreise in der RIPE-Region liegen bei etwa $0.30 bis $0.35 pro IP und Monat, in Regionen mit knappem Angebot teils höher. Die Preise schwanken außerdem mit der Reputation des Blocks: Saubere Blöcke erzielen einen Aufpreis, Blöcke mit Blocklist-Historie werden mit rund 40 % Abschlag gehandelt. Günstige Adressen sind aus gutem Grund günstig, und bei einer Migration, bei der es gerade um Partner-Allowlists geht, ist Reputation nicht der Ort zum Sparen.

Drei ehrliche Einschränkungen zur Rechnung. Adressen hinter Forwarding Rules waren bereits kostenfrei, eine Load-Balancer-lastige Umgebung spart also weniger. Die Ersparnis skaliert mit der Auslastung, ein halb leeres /24 spart also etwa halb so viel. Und die Wochen der Bereitstellung sind reale Engineering-Zeit, die in den Business Case gehört.

Rechnen Sie Ihre eigenen Zahlen mit Ihrer tatsächlichen Adresszahl und Auslastung im IPv4-Preisrechner durch, bevor Sie sich festlegen.

FAQ

Berechnet Google Cloud Gebühren für BYOIP-Adressen?

Nein. Googles Dokumentation ist eindeutig: Für ungenutzte oder genutzte BYOIP-IP-Adressen fallen keine Gebühren an. Sobald Ihr Präfix importiert ist, sind daraus bezogene Adressen kostenfrei, ob sie an eine Ressource gebunden oder nicht zugewiesen sind – ein deutlicher Unterschied zu von Google zugewiesenen statischen Adressen, bei denen eine nicht zugewiesene Adresse $0.01 pro Stunde kostet. Normale Gebühren für Datenübertragung, Load Balancing und Compute fallen weiterhin an.

Welche BYOIP-Limits gelten bei Google Cloud?

Die wichtigsten: Das angekündigte Präfix muss für IPv4 im Premium Tier zwischen /16 und /24 liegen (/16 bis /23 im Standard Tier, in Preview), /24 ist also der kleinste Block, den Sie mitbringen können. Delegated Prefixes reichen im Premium Tier v2 von /16 bis /28 (/17 bis /24 im Standard Tier), Sub-Präfixe enden bei /28, und ein Präfix kann bis zu dreimal unterdelegiert werden. Die Bereitstellung dauert mehrere Wochen und lässt sich nicht beschleunigen. Adressen können nicht zwischen Projekten verschoben werden. Überlappende Ankündigungen werden nicht unterstützt. Und mehrere Ressourcentypen sind ausgeschlossen – GKE-Nodes und Pods, externe Adressen von Cloud-VPN-Gateways sowie MIGs, die Adressen automatisch zuweisen.

Wie lange dauert GCP BYOIP?

Etwa zwei Wochen für die empfohlene regionale v2-Konfiguration und etwa vier Wochen für die ältere v1-Konfiguration oder für globale Präfixe. Globale Präfixe erfordern zudem vorab eine Allowlist-Anfrage über einen Support-Fall. Rechnen Sie vorne die Bearbeitungszeit der RIR für die ROA hinzu und planen Sie bis zu acht Wochen ein, falls ein Delegated Prefix jemals in eine andere Region wechseln muss.

Kann ich einen Bereich zwischen Google Cloud und meiner eigenen Infrastruktur aufteilen?

Nicht innerhalb eines einzelnen angekündigten Präfixes. Google kann keinen Block ankündigen, der gleichzeitig anderswo angekündigt wird; das gesamte PAP muss also exklusiv bei Google liegen, solange es angekündigt wird. Möglich ist eine Aufteilung an der Ankündigungsgrenze: Wenn Sie ein /23 halten, bringen Sie ein /24 als eigenes PAP zu Google Cloud und behalten das andere /24 in Ihrem eigenen Netzwerk. Innerhalb von Google Cloud lässt sich dieses /24 dann per Delegated Prefixes auf Regionen und Projekte bis hinunter zu /28 aufteilen. Und für schrittweise Umzüge kann ein Delegated Prefix innerhalb von Google Cloud angekündigt werden, während das übergeordnete Präfix noch aus Ihrer bestehenden Infrastruktur angekündigt wird.

Kann ich geleaste IPv4-Adressen für GCP BYOIP nutzen?

Ja. Google prüft die Kontrolle über den Block per ROA und Reverse-DNS-PTR-Eintrag – es verlangt nicht, dass Sie der registrierte Inhaber sind. Es verlangt aber, dass der registrierte Inhaber mitwirkt: Der Leasinggeber legt die ROA mit Googles ASN an, delegiert oder veröffentlicht das Reverse DNS und garantiert, dass niemand sonst den Block ankündigt. Ein Leasing mit diesen drei Regelungen funktioniert problemlos mit BYOIP.

Ein geleastes /24 zu Google Cloud zu bringen ist kein schwieriges Projekt, aber ein Projekt mit fester Reihenfolge. Der Engineering-Aufwand ist gering; die Wartezeit nicht, und fast die gesamte Wartezeit liegt vorne bei Registry- und DNS-Arbeiten, die beginnen können, bevor jemand die Konsole anfasst.

Wenn Sie einen geleasten Block gegen von Google zugewiesene Adressen abwägen, beginnen Sie mit Ihrer Adresszahl und Ihrer Auslastung und prüfen Sie dann die Leasing-Bedingungen anhand der vier Anforderungen oben. Und wenn Sie dieselbe Bewertung für eine andere Cloud durchführen, behandelt unser begleitender Leitfaden, wie Sie geleastes IPv4 mit einem Custom IP Prefix zu Azure bringen – dort unterscheiden sich Modell und Terminologie stärker, als man erwarten würde.

Entdecken Sie BYOIP-fähige IPv4-Blöcke bei IPbnb →