Geleastes IPv4 mit einem Custom IP Prefix zu Azure bringen
Azure unterstützt BYOIP über eine Ressource namens Custom IP Prefix, die in allen öffentlichen Azure-Regionen allgemein verfügbar ist.
Artem Kohanevich
Co-Founder & CEO bei IPbnb
Zuletzt aktualisiert
Inhaltsverzeichnis
Element
Zwei Wochen vor der Umstellung öffnet die Netzwerkleitung eine Tabelle, die seit 2019 niemand angefasst hat. Einundvierzig Kunden-Firewalls, jede mit denselben acht öffentlichen IP-Adressen fest konfiguriert. Diese Adressen gehören zu einem /24, das das Unternehmen seit zehn Jahren aus dem eigenen Rack ankündigt. Der Migrationsplan sagt Azure. Die Tabelle sagt, dass sich diese Adressen nicht ändern dürfen.
In diesem Moment entdecken die meisten Teams BYOIP – und dann das zweite Problem: die Rechnung. Azure stellt Ihnen bereitwillig 256 neue öffentliche IPs aus. Und berechnet jede einzelne davon, jede Stunde, auf unbestimmte Zeit.
Es gibt einen besseren Weg, und er funktioniert mit geleastem wie mit eigenem Adressraum.
Was öffentliche IPs bei Azure 2026 kosten
Azure berechnet öffentliches IPv4 pro Adresse und Stunde. Vier Abrechnungsregeln sind wichtiger als jeder einzelne Preis, und alle vier stammen direkt aus Microsofts Preis-FAQ:
Eine angefangene Stunde wird als volle Stunde berechnet.
Eine statische öffentliche IP im ARM-Modell wird unabhängig davon berechnet, woran sie gebunden ist – eine gestoppte VM stoppt den Zähler nicht. Nur dynamische öffentliche IPs sind kostenfrei, solange die zugehörige VM gestoppt und freigegeben ist.
Ein Public IP Prefix wird ab dem Moment der Erstellung pro IP und Stunde berechnet – einen Block „für später“ zu reservieren kostet genauso viel wie ihn zu nutzen.
Die Abrechnung einer statischen IP beginnt in der zweiten Stunde nach der Erstellung und endet erst, wenn Sie die Ressource löschen.
Zum Preis selbst: Laut Microsofts Hinweis zur Einstellung der Basic SKU steigt ab dem 31. März 2026 Static IPv4 Basic (ARM) von $0.0036/h auf $0.005/h und Dynamic IPv4 Basic (ARM) von $0.004/h auf $0.005/h – in beiden Fällen auf das Niveau von Standard (ARM). Damit liegt statisches IPv4 Standard (ARM) bei $0.005 pro Stunde. Azures Preistabelle wird nach Region und Währung gefiltert und lädt ihre Zahlen dynamisch – prüfen Sie den Wert für Ihre Region und Ihren Vertrag daher auf der Preisseite für IP-Adressen, bevor er in einen Business Case einfließt.
Bei $0.005 pro Stunde und einem Monat mit 730 Stunden kostet eine statische Standard-IPv4 etwa $3.65 pro Monat:
Blockgröße | Adressen | Ca. monatliche Kosten |
|---|---|---|
/28 | 16 | $58 |
/26 | 64 | $234 |
/24 | 256 | $934 |
Ein /24 aus von Azure ausgestellten Adressen kostet also rund $11,200 pro Jahr, noch bevor ein einziges Byte Egress anfällt.
Höhere Stufen kosten mehr. Standard v2 und Global (ARM) sind separate Positionen in Azures Preistabelle, und insbesondere die Global-Stufe hat einen Aufpreis für regionsübergreifende Funktionen. Diese Preise sollten Sie aus dem aktuellen Rechner holen, statt sie hier zitiert zu bekommen.
Was ist ein Custom IP Prefix (Azure BYOIP)?
Custom IP Prefix ist Microsofts Name für BYOIP. Es ist ein zusammenhängender Block von IP-Adressen, der einem externen Kunden gehört und in dessen Abonnement bereitgestellt wird, sodass Microsoft ihn ankündigen darf. Das Eigentum wird nicht übertragen. Sie behalten die RIR-Registrierung; Azure übernimmt die Ankündigung.
Nach dem Onboarding verhalten sich Adressen aus einem Custom IP Prefix wie Azure-eigene öffentliche IPs: Sie werden an Azure-Ressourcen gebunden, interagieren mit privaten IPs und virtuellen Netzwerken und erreichen externe Ziele ausgehend aus dem Azure Wide Area Network.
Das kommerzielle Argument ist kurz. Für Bereitstellung und Nutzung von Custom IP Prefixes fallen keine Gebühren an, ebenso wenig für daraus abgeleitete Public IP Prefixes oder öffentliche IP-Adressen. Die Preisseite enthält dieselbe Fußnote: Für die Nutzung von Public IPv4 Prefixes, die aus Custom IPv4 Prefixes (BYOIP) abgeleitet sind, fallen keine Gebühren an.
Der Egress bleibt in beiden Fällen gleich. Traffic zu einem Custom-IP-Prefix-Bereich wird zum Internet-Egress-Tarif abgerechnet, zum selben Satz wie bei einer öffentlichen Azure-IP in derselben Region. BYOIP entfernt den Posten für die Adressmiete. Den Posten für Bandbreite berührt es nicht, und wer etwas anderes verspricht, will Ihnen etwas verkaufen.
Das Ressourcenmodell sollten Sie verstehen, bevor Sie beginnen:
Ein Custom IP Prefix kann nicht direkt an eine Ressource gebunden werden. Sie leiten daraus ein Public IP Prefix ab und daraus wiederum einzelne öffentliche IPs.
Das Standardlimit beträgt fünf Custom IP Prefixes pro Region und kann auf Anfrage erhöht werden.
Public IP Prefixes mit Standard-v2-IPs können nicht aus einem Custom IP Prefix abgeleitet werden, und weder Internet Routing Preference noch die für regionsübergreifendes Load Balancing genutzte Global-Stufe werden unterstützt.
In Regionen mit Verfügbarkeitszonen muss das Präfix bei der Erstellung als zonenredundant deklariert oder an eine bestimmte Zone gebunden werden.
Anforderungen
Der Block selbst
Der Bereich muss auf Ihren Namen bei einer der fünf RIRs registriert sein – ARIN, RIPE NCC, APNIC, LACNIC oder AFRINIC – und darf nicht kleiner als /24 sein, denn das ist das kleinste Präfix, das ISPs akzeptieren. Daran führt kein Weg vorbei. Ein /25 funktioniert nicht, weder in Azure noch sonst irgendwo im öffentlichen Internet.
Unified oder Global/Regional
Azure bietet zwei Bereitstellungsmodelle, und ein Block kann nach dem Onboarding nicht zwischen ihnen migriert werden – er muss vollständig deprovisioniert und neu eingebracht werden. Wählen Sie bewusst.
Unified ist das einfache Modell: Derselbe Bereich wird sowohl vom WAN von Microsoft als auch von der Azure-Region angekündigt und kann zwischen /21 und /24 liegen. Wenn Sie einen Block in einer Region einsetzen, wählen Sie dieses Modell.
Global/Regional ist eine Parent/Child-Struktur. Das WAN von Microsoft kündigt den globalen (Parent-)Bereich an, einzelne Azure-Regionen die regionalen (Child-)Bereiche. Globale Bereiche reichen von /21 bis /24, regionale von /22 bis /26, und ein Child muss mindestens eine Stufe kleiner sein als sein Parent – ein /23-Parent erlaubt Children von /24 bis /26. Nur der globale Bereich wird bei der Bereitstellung validiert; Children werden daraus abgeleitet. Children können in verschiedenen Abonnements liegen, müssen aber denselben Tenant teilen. Das ist das Modell für eine Umgebung über mehrere Regionen und Teams.
Die ROA
Sie müssen im Portal oder über die API Ihrer RIR eine Route Origin Authorization anlegen, digital signiert mit dem RPKI Ihrer RIR. Drei Dinge müssen stimmen:
Das Origin-AS muss 8075 für die Public Cloud oder 8070 für die US Gov Cloud sein.
Die Präfixlänge muss exakt dem entsprechen, was Microsoft ankündigen wird. Wenn Sie sowohl ein /24 als auch ein /23 einbringen, nennen Sie beide.
Das Ablaufdatum der Gültigkeit muss den gesamten Zeitraum abdecken, in dem Microsoft den Block ankündigen soll. Manche RIRs legen dieses Datum für Sie fest.
Rechnen Sie nach dem Einreichen mindestens 24 Stunden, bis die ROA für Microsoft verfügbar ist. Wenn derzeit eine andere ASN den Block ankündigt, empfiehlt Microsoft, auch für diese ASN eine ROA anzulegen, um Probleme während der Migration zu vermeiden.
Die signierte Nachricht
Dieser Schritt ist von der ROA getrennt und wird oft übersehen. Azure weist nach, dass der Block zu Ihrem Abonnement gehört, indem es eine signierte Nachricht mit einem Zertifikat abgleicht, das Sie im öffentlichen Registry-Eintrag veröffentlichen.
Sie erzeugen mit OpenSSL ein selbstsigniertes X509-Zertifikat und fügen es in die öffentlichen Kommentare des Whois/RDAP-Eintrags für das Präfix ein: im Feld Comments bei ARIN, im Feld Remarks des inetnum-Objekts bei RIPE, APNIC und AFRINIC. Inhaber bei LACNIC eröffnen stattdessen ein Support-Ticket bei Microsoft. Anschließend bauen Sie einen String im Format subscription-ID|prefix|expiry-date, wobei das Ablaufdatum dem Gültigkeitsdatum der ROA entspricht, und signieren ihn mit dem privaten Schlüssel. Die Base64-Ausgabe kommt ins Portal.
Schritt für Schritt: von der Bereitstellung bis zur Inbetriebnahme
1. Vorbereiten. Legen Sie die ROA für AS8075 an. Erzeugen Sie das Schlüsselpaar, veröffentlichen Sie das Zertifikat im Whois/RDAP-Eintrag und signieren Sie die Autorisierungsnachricht. Warten Sie die 24-stündige Verbreitung der ROA ab.
2. Bereitstellen. Suchen Sie im Portal nach Custom IP, öffnen Sie Custom IP Prefixes und wählen Sie + Create. Geben Sie das CIDR, das Ablaufdatum der ROA im Format yyyymmdd, die signierte Nachricht und Ihre Zoneneinstellung an. Der Bereich wird asynchron an Azures IP Deployment Pipeline übergeben; den Fortschritt verfolgen Sie im Feld Commissioned state. Die Bereitstellung dauert etwa 30 Minuten.
3. Adressen ableiten. Sobald das Präfix den Status Provisioned erreicht, öffnen Sie es und wählen + Add a public IP prefix in der passenden Region. Von dort weisen Sie öffentliche IPs der Standard SKU zu und binden sie an NICs oder Load-Balancer-Frontends. Noch wird nichts angekündigt, also ist nichts erreichbar. Genau das ist der nützliche Teil: Sie können die gesamte Zieltopologie aufbauen und testen, bevor sich ein einziges Paket bewegt.
4. In Betrieb nehmen. Wählen Sie Commission und den Geltungsbereich. Der Status wechselt zu Commissioning, währenddessen der Bereich teilweise angekündigt wird, und dann zu Commissioned. Der vollständige Rollout dauert schätzungsweise 3 bis 4 Stunden.
Hier liegt das Risiko der Migration. Während das Präfix in Betrieb genommen wird, kündigt Microsoft es aus der lokalen Azure-Region und dann global über sein Wide Area Network unter AS8075 an. Denselben Bereich gleichzeitig von anderswo anzukündigen, riskiert BGP-Routing-Instabilität oder Traffic-Verlust. Planen Sie die Umstellung in einem Wartungsfenster oder nutzen Sie die Option der rein regionalen Inbetriebnahme, die die Ankündigung auf die Azure-Region beschränkt, in der das Präfix bereitgestellt ist.
Die rein regionale Inbetriebnahme ist hier die unterschätzte Funktion. Mit ihr validieren Sie die Erreichbarkeit innerhalb einer Region, während Ihre bisherige Ankündigung global aktiv bleibt.
Schlägt die Bereitstellung fehl, zeigt die Ressource ein Attribut FailedReason, das im Portal als Banner erscheint. ASN8075NotAllowedToAdvertise bedeutet, dass die ROA fehlt oder falsch ist; ein Fehler bei der signierten Nachricht bedeutet, dass sie nicht gegen den Whois/RDAP-Eintrag für das Präfix verifiziert werden kann.
Einen geleasten IPv4-Block einbringen: was sich tatsächlich ändert
Seien Sie genau bei dem, was Microsoft verlangt. Laut Dokumentation muss der Bereich Ihnen gehören und auf Ihren Namen bei einer RIR registriert sein, und Azure setzt das auf Registry-Ebene durch: Es prüft eine ROA und ein Zertifikat, die beide am RIR-Objekt hinterlegt sind. Bei einem geleasten Block gehört dieses Objekt dem IP-Eigentümer, nicht dem IP-Mieter.
BYOIP mit geleastem Adressraum ist also kein Workaround. Es ist ein Verfahren zwischen zwei Parteien, das nur mit aktiver Mitwirkung des Eigentümers funktioniert, und der Leasingvertrag muss entsprechend gestaltet sein. Die folgende Aufteilung zeigt, wo jede Azure-Anforderung in der Praxis landet – je nachdem, wer welchen Eintrag kontrolliert:
Aufgabe | Wer sie ausführt | Warum |
|---|---|---|
ROA, die AS8075 autorisiert | IP-Eigentümer | Hält das RIR-Objekt und die RPKI-Zugangsdaten |
Veröffentlichung des X509-Zertifikats in Whois/RDAP | IP-Eigentümer | Kontrolliert das inetnum- bzw. net-Objekt |
Erzeugen des Schlüsselpaars und Signieren der Nachricht | IP-Mieter | Die Nachricht enthält die Azure-Abonnement-ID des Mieters |
Anlegen des Custom IP Prefix im Portal | IP-Mieter | Läuft im Abonnement des Mieters |
LOA für die Leasinglaufzeit | Vom Eigentümer ausgestellt, vom Mieter gehalten | Übliche Praxis gegenüber Upstreams |
Ein praktischer Hinweis zum Umgang mit Schlüsseln: Der Mieter kann das Schlüsselpaar lokal erzeugen und dem Eigentümer nur das öffentliche Zertifikat zur Veröffentlichung übergeben. Der private Schlüssel, der die Autorisierungsnachricht signiert, muss die Seite des Mieters nie verlassen.
Drei Punkte, die vor der Bereitstellung im Leasingvertrag geklärt sein sollten:
Die Gültigkeit der ROA muss die Leasinglaufzeit überdauern, mit einer benannten Verantwortung für die Verlängerung. Eine abgelaufene ROA stoppt die Ankündigung durch Microsoft nicht, doch Microsoft warnt, dass externe Carrier die Ankündigung möglicherweise nicht mehr akzeptieren, und empfiehlt eine Folge-ROA, wenn das ursprüngliche Ablaufdatum überschritten ist.
Vor einer Änderung der ROA außer Betrieb nehmen. Microsoft betont ausdrücklich, dass Sie den Bereich vor dem Ändern oder Löschen der ROA außer Betrieb nehmen sollten, sonst kündigt Microsoft weiterhin einen Bereich an, für den es nicht mehr autorisiert ist. Verankern Sie das im Ausstiegsprozess des Leasings, nicht in einem Runbook, das niemand liest.
Reputation vor der Unterschrift prüfen. Die Blocklist-Historie haftet an den Adressen, und eine nachträgliche Bereinigung dauert länger als eine vorherige Prüfung.
Da die Mindestgröße für das Onboarding ein /24 ist, passt Leasing für die meisten Azure-Workloads auch wirtschaftlich besser als ein Kauf: Sie brauchen mindestens 256 Adressen, um teilzunehmen – ob Sie 256 Adressen benötigen oder nicht.
Die Kostenrechnung: 256 Azure-IPs vs. ein geleastes /24 per BYOIP
Von Azure ausgestellte Standard-IPs | Geleastes /24 per BYOIP | |
|---|---|---|
Adresskosten | 256 × $3.65 ≈ $934/Monat | $77–$90/Monat |
Gebühr für Public IP Prefix | Pro IP und Stunde ab Erstellung | Keine |
Gebühr für Custom IP Prefix | entfällt | Keine |
Egress | Normale Internettarife | Normale Internettarife |
Jährliche Adresskosten | ~$11,200 | ~$925–$1,080 |
Beim veröffentlichten Leasingpreis von IPbnb von $0.30–$0.35 pro IP und Monat ohne Plattformgebühren kostet ein /24 monatlich $77 bis $90. Gegenüber rund $934 an Azure-Adressgebühren sind das etwa $850 pro Monat bzw. knapp 90 % des Adresspostens – noch ohne den operativen Wert, Adressen zu behalten, die bereits in den Allowlists Ihrer Kunden stehen.
Eine Amortisationszeit gibt es nicht, denn Azure berechnet nichts für das Onboarding.
Zwei ehrliche Einschränkungen. Der Egress ist in beiden Fällen identisch – wenn Bandbreite Ihre Rechnung dominiert, ändert sich weniger, als der Prozentsatz vermuten lässt. Und Sie tauschen vollständig verwaltete Kosten gegen eine Compliance-Beziehung zwischen zwei Parteien: ROAs, Zertifikate und Verlängerungstermine, für die jemand verantwortlich sein muss. Für eine Handvoll Adressen, die niemand auswendig kennt, ist Azures Zähler günstiger als die Koordination. Für ein /24 mit zehn Jahren Reputation ist es nicht einmal knapp.
Rechnen Sie Ihre eigenen Zahlen mit dem IPv4-Preisrechner durch und sehen Sie sich unsere BYOIP-Übersicht für die Entsprechungen bei AWS und Google Cloud an.
FAQ
Unterstützt Azure BYOIP?
Ja. Azure unterstützt BYOIP über eine Ressource namens Custom IP Prefix, die in allen öffentlichen Azure-Regionen allgemein verfügbar ist. Sie bringen Ihren eigenen IPv4- oder IPv6-Block mit, behalten die Registrierung bei Ihrer RIR und autorisieren Microsoft, ihn unter AS8075 anzukündigen.
Wie funktioniert Bring Your Own IP?
Sie autorisieren den Cloud-Anbieter, einen Block anzukündigen, den Sie kontrollieren. Bei Azure bedeutet das: eine ROA mit AS8075 als Origin veröffentlichen, die Kontrolle per signierter Nachricht nachweisen, die gegen ein Zertifikat in Ihrem Whois-Eintrag geprüft wird, und den Block dann als Custom IP Prefix bereitstellen. Nach der Inbetriebnahme kündigt Microsoft den Bereich an, und Sie weisen daraus Adressen zu wie aus jedem anderen.
Ist ein Custom IP Prefix kostenfrei?
Ja. Microsoft berechnet nichts für Bereitstellung oder Nutzung eines Custom IP Prefix und nichts für die daraus abgeleiteten Public IP Prefixes und öffentlichen IP-Adressen. Egress-Traffic wird weiterhin zu normalen Internettarifen abgerechnet.
Welche Mindestgröße gilt für Azure BYOIP?
Ein /24, also 256 Adressen, denn das ist der kleinste Block, den ISPs akzeptieren. Unified- und globale (Parent-)Bereiche reichen von /21 bis /24; regionale (Child-)Bereiche von /22 bis /26 und müssen mindestens eine Stufe kleiner sein als ihr Parent.
Kann ich geleaste IPv4-Bereiche mit Azure BYOIP nutzen?
In der Praxis ja, aber nur mit Mitwirkung des IP-Eigentümers. Azure prüft die Kontrolle am RIR-Eintrag, den der Eigentümer kontrolliert – der Eigentümer muss also die ROA für AS8075 anlegen und Ihr X509-Zertifikat in den inetnum-Remarks veröffentlichen. Sie erzeugen die Schlüssel, signieren die Autorisierungsnachricht mit Ihrer Abonnement-ID und stellen das Präfix bereit. Stellen Sie sicher, dass die LOA die gesamte Leasinglaufzeit abdeckt und die Gültigkeit der ROA darüber hinausreicht.
