Leitfaden zur IPv4-Subnetzgröße: So wählen Sie die richtige Blockgröße für Ihren Anwendungsfall

Es gibt zwei Wege, die IPv4-Blockgröße falsch zu wählen, und beide sind teuer.

Der erste: zu klein leasen. Sie schätzen vorsichtig, das Projekt wächst schneller als erwartet, und im vierten Monat eines Sechsmonatsvertrags sind Sie unter Zeitdruck wieder am Markt – zahlen einen Aufpreis für die Eile, tragen die operativen Kosten für das Onboarding eines zweiten Blocks und laufen in der Zwischenzeit mit eingeschränkter Kapazität.

Der zweite: zu groß leasen. Der Block ist zu 30 % ausgelastet. Sie zahlen jeden Monat für ungenutzte Adressen, und diese ungenutzten Adressen sind nicht neutral – sie ziehen Probe-Traffic an, erzeugen Abuse-Meldungen durch automatisierte Scanner und drücken still die Reputation der aktiven IPs daneben.

Die richtige Größe ergibt sich aus drei Faktoren: Ihrem Anwendungsfall, Ihrem Wachstumshorizont und einer Handvoll operativer Einschränkungen, die erst offensichtlich werden, wenn sie jemand erklärt. Genau das leistet dieser Leitfaden.

Wenn Sie vor der Dimensionierung eine Einführung brauchen, wie IPv4-Leasing technisch funktioniert, beginnen Sie hier: So funktioniert IPv4-Leasing →

IPv4-Blockgrößen im Überblick

Budget und Preise

Leasingpreise skalieren in etwa linear mit der Blockgröße – ein /22 kostet bei gleichem Preis pro IP rund das Vierfache eines /24, weil es viermal so viele Adressen enthält. Ein /22 liegt typischerweise bei $307-358 pro Monat, ein /21 bei $614-717 pro Monat.

Relevanter ist der Vergleich des Monatspreises mit den Kosten einer falschen Größe: Ein mitten im Projekt notfallmäßig beschaffter zweiter Block – mit Eilpreisen und einem zweiten Onboarding – kostet durchweg mehr, als von Anfang an größer zu dimensionieren. Für genaue Preise nach Größe, Region und Verfügbarkeit: IPv4-Preisrechner →

Die vier Variablen, die Ihre Größenentscheidung bestimmen

Bevor Sie einem Anwendungsfall eine Blockgröße zuordnen, brauchen Sie einen Rahmen. Diese vier Variablen bestimmen in jedem Szenario die richtige Antwort.

Erwartete Auslastung

Nicht alle IPs eines geleasten Blocks sind gleichzeitig aktiv – und in manchen Anwendungsfällen ist das gewollt. Hosting-Anbieter arbeiten typischerweise mit 60–80 % Auslastung. E-Mail-Versender halten die Zahl aktiver IPs bewusst niedriger, um die Absenderreputation zu schützen: Ein Pool von 50 aktiven Versand-IPs aus einem /24 ist übliche Praxis, keine Verschwendung. Die praktische Regel ist einfach: Liegt Ihre erwartete Auslastung im Dauerbetrieb über 85 %, gehen Sie eine Stufe größer. Ein Block nahe der Kapazitätsgrenze lässt keinen Raum, Traffic-Spitzen ohne Folgen für Reputation oder Dienstqualität aufzufangen.

Wachstumshorizont vs. Laufzeit

Ein Block sollte für das Ende der Laufzeit dimensioniert werden, nicht für den Anfang. Unterschreiben Sie heute einen 12-Monats-Vertrag, dimensionieren Sie für Monat 10 – nicht für das, was Sie gerade brauchen. Ergibt diese Rechnung einen Block, der sich für Ihren aktuellen Stand zu groß anfühlt, überlegen Sie, ob eine kürzere Anfangslaufzeit mit geplanter Erweiterung operativ sinnvoller ist als eine lange Bindung an Adressraum, den Sie sofort ausreizen.

Kapazität für Reputationsmanagement

Größere Blöcke sind schwerer zu überwachen. Ein /19 (8.192 Adressen), das ein dreiköpfiges Infrastrukturteam verwaltet, bedeutet Tausende IPs, die Missbrauch erzeugen könnten, ohne dass es jemand bemerkt. Dimensionieren Sie nach dem, was Ihr Team aktiv überblicken kann. IPbnb bietet bei jedem Leasing Abuse-Monitoring rund um die Uhr – das hebt die Obergrenze dessen, was ein kleines Team bewältigen kann, deutlich an –, doch Plattform-Monitoring ersetzt nicht Ihre eigene operative Aufsicht. Die Reputation eines Blocks beeinflusst direkt die Verlängerungsbedingungen und künftige Flexibilität; sie zu vernachlässigen hat sich aufschaukelnde Kosten.

Budgetdisziplin

Leasingpreise skalieren in etwa linear mit der Blockgröße. Ein /22 kostet bei gleichem Preis pro IP rund das Vierfache eines /24. Die Frage ist nicht nur, welche Größe Sie brauchen – sondern was eine Unterdimensionierung kosten würde, wenn Sie notfallmäßig einen zweiten Block brauchen, im Vergleich zu den monatlichen Kosten ungenutzter Adressen bei Überdimensionierung. In den meisten Fällen ist die richtige Dimensionierung von Anfang an günstiger als beide Fehlerbilder.

Dimensionierung nach Anwendungsfall

Hosting-Anbieter / Shared Hosting

Empfohlen: /23 bis /21

Shared Hosting weist in etwa eine IP pro Kundenkonto zu, wobei manche Konten zusätzliche IPs für SSL-Zertifikate, eigene Versanddomains oder Mandantentrennung brauchen. Ein /23 (512 Adressen) deckt bei komfortabler Auslastung etwa 400–500 Konten ab. Wachstum erfolgt mit steigender Kundenzahl typischerweise in /23-Schritten.

Hosting ist eines der Umfelder mit dem höchsten Missbrauchsrisiko für geleastes IPv4. Kunden versenden E-Mails, betreiben Webanwendungen und verstoßen gelegentlich gegen Nutzungsrichtlinien auf eine Weise, die die Reputation benachbarter IPs im selben /24 beeinträchtigt. Daher ist Reputations-Monitoring pro /24 besonders wichtig – ein Problem mit dem Verhalten eines Kunden kann alle anderen im selben Bereich treffen. Das Abuse-Monitoring von IPbnb deckt das auf Plattformebene ab, doch der Hosting-Betreiber braucht trotzdem klare Nutzungsbedingungen für Kunden und einen schnellen internen Prozess für Beschwerden.

Der häufige Fehler: ein /24 leasen, um ein Hosting-Geschäft zu starten, IPs an 200 Konten vergeben und feststellen, dass ohne Rückkehr an den Markt kein Platz für Wachstum bleibt. Haben Sie aktuell 150 oder mehr Kunden, beginnen Sie mit einem /23. Erwarten Sie, das innerhalb von sechs Monaten zu erreichen, beginnen Sie trotzdem mit einem /23.

Verfügbare /23- und /22-Blöcke ansehen →

Cloud-Einsatz / BYOIP

Empfohlen: mindestens /24; /23 oder /22 für Einsatz über mehrere Regionen oder Dienste

AWS, GCP und Azure verlangen für BYOIP alle mindestens ein /24. Das ist eine harte Grenze – ein /25 oder kleiner wird im Onboarding des Cloud-Anbieters abgelehnt, egal wie sauber der Block ist. Einen Workaround gibt es nicht.

Über das Minimum hinaus: Ein einzelnes /24 reicht für einen Dienst in einer Region. Setzen Sie über mehrere Regionen ein, betreiben Dienste, die voneinander reputationsisoliert sein müssen, oder skalieren ein kundenseitiges Produkt, gibt Ihnen ein /23 oder /22 Raum, Workloads zu trennen, ohne mitten im Einsatz an den Markt zurückzukehren.

Der Cloud-BYOIP-Fall hat besondere Reputationsanforderungen über das Standard-Leasing hinaus. AWS behält sich ausdrücklich vor, Präfixe mit schlechter Historie abzulehnen. Die Reputation des Blocks muss überprüfbar sein, bevor Sie die Validierung des Cloud-Anbieters starten, die ein bis zwei Wochen dauern kann – bei GCP meist länger – und sich nach einer Ablehnung nicht schnell wiederholen lässt. Ein Block, der die Validierung nicht besteht, bedeutet einen Neuanfang.

Der häufige Fehler: das minimale /24 für einen Cloud-Einsatz leasen, der wachsen wird, und mitten im Projekt feststellen, dass eine Erweiterung einen separaten Block, eine separate LOA und ein neues BYOIP-Onboarding beim Cloud-Anbieter erfordert. Steht Cloud-Wachstum auf Ihrer Roadmap, dimensionieren Sie von Anfang an für 12 Monate Wachstum.

Die vollständigen Anforderungen je Anbieter: BYOIP mit geleastem IPv4 bei AWS, GCP und Azure →

ISP / kleiner Telekommunikationsanbieter

Empfohlen: /21 bis /18 je nach Kundenzahl

ISPs weisen Kunden IPs zu: Geschäftskunden erhalten meist eine oder einen kleinen Block dedizierter Adressen, Privatkunden teilen sich IPs per NAT. Die Blockgröße folgt der Kundenzahl und Wachstumsprognose statt einer festen Formel.

Ein brauchbarer Ausgangspunkt: Bei einer IP pro Geschäftskunde und NAT von 8:1 für Privatkunden unterstützt ein /21 (2.048 Adressen) etwa 500–800 Geschäftskunden oder eine gemischte Basis von mehreren tausend Privatkunden. Von dort skalieren Sie in /21- oder /20-Schritten.

ISPs unterschreiben in der Regel längere Laufzeiten als andere Betreibertypen – Jahresverträge sind Standard. Das macht die anfängliche Dimensionierung besonders folgenreich. Eine Unterdimensionierung bei einem 12-Monats-Vertrag bedeutet, entweder die gesamte Laufzeit an der Kapazitätsgrenze zu laufen oder mitten in der Laufzeit einen zusätzlichen Block zu verhandeln, was Kosten und operative Komplexität erhöht.

Der häufige Fehler: für die heutige Kundenzahl dimensionieren, ohne die Pipeline im Onboarding zu berücksichtigen. Haben Sie heute 200 aktive Kunden und 80 Abschlüsse in Arbeit, dimensionieren Sie für 280 – nicht für 200.

VPN-Betreiber / Privacy-Proxy-Dienst

Empfohlen: /22 bis /20

VPN- und Proxy-Betreiber brauchen geografische und reputationsbezogene Vielfalt über ihre Exit-Knoten und müssen IPs oft rotieren, wenn einzelne Adressen Reputationsvorfälle ansammeln. Ein /22 (1.024 Adressen) bietet für kleine bis mittlere Umgebungen genug Spielraum für sinnvolle Rotation und Vielfalt.

VPN-Traffic erzeugt strukturell mehr Abuse-Beschwerden als die meisten anderen Anwendungsfälle – nicht wegen Nachlässigkeit des Betreibers, sondern weil Exit-Knoten Port-Scans, Richtlinienverstöße von Nutzern und automatisierte Fehlalarme anziehen. Aktives Monitoring und schnelle Reaktion auf Missbrauch sind daher nicht verhandelbar. Es bedeutet auch, dass der Block einen Puffer über der Zahl aktiver IPs braucht, um Reputationsvorfälle aufzufangen, ohne Nutzer auf sauberen Adressen zu beeinträchtigen.

Ein Hinweis zur zulässigen Nutzung: Manche Plattformen schränken VPN- und Proxy-Anwendungsfälle ein oder verlangen eine Vorabfreigabe. Prüfen Sie das vor der Unterschrift. Das Team von IPbnb berät Sie beim Onboarding zu passenden Konfigurationen und Parametern der zulässigen Nutzung.

Der häufige Fehler: ein /24 für einen VPN-Dienst ohne Puffer leasen. Nachdem einige Abuse-Vorfälle mehrere IPs getroffen haben, schrumpft der nutzbare Pool so weit, dass aktive Nutzer die Folgen spüren.

/22-Blöcke für VPN-Umgebungen ansehen →

E-Mail-Versand / ESP-Infrastruktur

Empfohlen: ein /24 pro Versandpool

Die E-Mail-Reputation wird von den meisten großen Postfachanbietern auf /24-Ebene bewertet. Ein dediziertes /24 pro Versandstrom – Transaktions-E-Mails, Marketing-E-Mails, domainspezifischer Versand – isoliert Reputationsschäden zwischen den Pools. Werden Versandarten auf gemeinsamen IPs gemischt, trifft ein Zustellproblem eines Stroms alle.

Bei E-Mail geht es um Isolation mehr als um Menge. Die meisten Versandbetriebe brauchen keine 256 aktiven IPs – sie brauchen saubere, dedizierte, korrekt aufgewärmte IPs für bestimmte Zwecke. Ein /24 pro Pool, schrittweise auf volles Versandvolumen aufgewärmt, ist der richtige strukturelle Ansatz.

Der häufige Fehler: einen großen Block leasen und den gesamten E-Mail-Traffic darüber leiten. Löst eine Marketingkampagne eine Spitze bei Spam-Beschwerden aus, trifft das Transaktions-Mails auf denselben Adressen – und deren Zustellbarkeit ist weit schwerer wiederherzustellen als die von Marketing-Mails.

Wie Reputations-Monitoring in der Praxis aussieht, zeigt im Detail: IP-Reputations-Tools und Best Practices →

SaaS / API-lastige Anwendung

Empfohlen: /24

SaaS-Workloads brauchen meist saubere, stabile IPs für API-Authentifizierung, ausgehende Webhooks und das Allowlisting durch Unternehmenskunden. Stabilität der IPs zählt hier mehr als Menge. Ein einzelnes /24 reicht für die meisten SaaS-Teams in einer Region.

Eine wichtige Trennung: Versendet das Produkt auch Transaktions-E-Mails – Belege, Warnungen, Passwort-Resets –, nutzen Sie für diesen Traffic ein eigenes /24, getrennt vom API-Traffic. Beides auf denselben IPs zu mischen erschwert das Reputationsmanagement deutlich, weil API- und E-Mail-Traffic unterschiedliche Risikoprofile haben und unterschiedliches Monitoring erfordern.

Saubere /24-Blöcke für SaaS ansehen →

Rechenzentrum / Colocation-Betreiber

Empfohlen: /21 bis /20

Rechenzentren weisen IPs Kundenservern und -diensten zu. Ein /21 (2.048 Adressen) deckt einen mittelgroßen Colocation-Bestand ab. Prüfen Sie für Multi-Tenant-Umgebungen, ob mehrere /22 mehr operative Flexibilität bieten als ein einzelner großer Block – nicht zusammenhängende /24-Bereiche lassen sich kundenweise zuweisen und besser isolieren, was das Reputationsmanagement vereinfacht und die Auswirkungen begrenzt, wenn ein einzelner Mandant Probleme verursacht.

Der häufige Fehler: anzunehmen, ein großer zusammenhängender Block sei immer einfacher zu verwalten als mehrere kleinere. Im Maßstab eines Rechenzentrums überwiegt die IP-Isolation pro Kunde oft den Verwaltungskomfort eines einzigen großen Präfixes.

Verfügbare /21- und /20-Blöcke ansehen →

Kurzfristiges Projekt / Tests / Staging

Empfohlen: /24, monatlich kündbar

Für vorübergehende Workloads – Lasttests, Staging-Umgebungen, kurzfristige Infrastrukturexperimente – bietet ein /24 für die meisten Fälle genug Adressraum ohne Überbindung. Monatlich kündbare Laufzeiten ohne Mindestdauer halten die Ausstiegskosten niedrig und geben Ihnen volle Flexibilität, den Block nach Projektende zurückzugeben.

Prüfen Sie vor der Unterschrift, ob die Plattform kurze, flexible Laufzeiten unterstützt. IPbnb unterstützt monatliches Leasing ohne langfristige Bindung.

Monatlich kündbare /24-Blöcke ansehen →

Kurzübersicht: Blockgröße nach Anwendungsfall

Was passiert, wenn Sie die falsche Größe wählen

Eine falsche Größe in beide Richtungen hat vorhersehbare Kosten.

Zu klein: Sie kehren unter Zeitdruck an den Markt zurück. In der RIPE-Region dauert die Beschaffung und das Onboarding eines zusätzlichen Blocks mitten im Projekt seine Zeit – und Eile bedeutet Aufpreis. Der Betrieb an der Kapazitätsgrenze in der Zwischenzeit beeinträchtigt Dienstqualität und IP-Reputation. Die Korrektur eines zu kleinen Blocks mitten in der Laufzeit kostet fast immer mehr als die richtige Dimensionierung von Anfang an.

Zu groß: Ungenutzte Adressen sind nicht neutral. Ein Block mit 20–30 % Auslastung erzeugt über den ungenutzten Bereich Probe-Traffic und Abuse-Meldungen und schafft Reputationsrisiko ohne operativen Gegenwert. In der RIPE-Region wird von Betreibern erwartet, dass sie Adressraum effizient nutzen – ein schwach ausgelasteter Block kann Verlängerungsverhandlungen erschweren und Aufmerksamkeit auf sich ziehen, die Sie lieber vermeiden.

So begründen Sie Ihre Größenentscheidung intern

An den meisten Größenentscheidungen ist jemand beteiligt, der kein Netzwerk-Engineer ist – eine Finanzleitung, ein CTO, ein Einkäufer, der verstehen möchte, warum eine bestimmte Blockgröße beantragt wurde, bevor er die Ausgabe freigibt. Diese drei Argumentationen funktionieren gegenüber technischen und nichttechnischen Beteiligten gleichermaßen.

Die Kosten einer Unterdimensionierung. Mitten im Projekt an den Markt zurückzukehren bedeutet, einen zweiten Block zu Eilpreisen zu bezahlen, ein zweites Onboarding zu tragen und zwischenzeitlich womöglich mit eingeschränkter Kapazität zu laufen. Die richtige Dimensionierung vorab ist fast immer günstiger als die Behebung eines Engpasses mitten in der Laufzeit. Werden Sie zu einem kleineren Block gedrängt, um monatlich zu sparen, rechnen Sie aus, was eine notfallmäßige Blockbeschaffung kosten würde – an Gebühren, operativer Zeit und Projektverzögerung – und vergleichen Sie die beiden Zahlen.

Die Kosten einer Überdimensionierung. Ungenutzte IPs kosten Geld und schaffen Risiko. Ein Block mit 30 % Auslastung erzeugt über 70 % seines Adressraums Abuse-Risiko ohne Erlös oder operativen Gegenwert. Finanzteams reagieren gut auf das Argument, dass ungenutzter Adressraum eine Belastung ist und kein Puffer. Ziel ist nicht maximale Kapazität – sondern die richtige.

Das Belegungsmodell. Stellen Sie die Größenentscheidung so dar, wie ein Immobilienverwalter die Belegung eines Gebäudes betrachtet: 70–80 % Auslastung im Dauerbetrieb anpeilen, mit Reserve für Spitzen oder Wachstum. Unter 60 % ist verschwenderisch; über 90 % schafft operatives Risiko und lässt keinen Spielraum für Fehler. Dieses Modell gibt nichttechnischen Beteiligten einen klaren gedanklichen Rahmen zur Bewertung des Antrags – und macht die Begründung nachvollziehbar, falls die Entscheidung später überprüft wird.

Vier vermeidbare Fehler bei der Dimensionierung

Für heute dimensionieren statt für das Ende der Laufzeit. Die Blockgröße sollte die Auslastung in Monat 10 eines 12-Monats-Leasings widerspiegeln. Ein Block, der am ersten Tag perfekt passt, aber im sechsten Monat an seine Grenzen stößt, ist ein Planungsfehler mit vorhersehbaren Kosten.

Blockgröße mit Blockqualität verwechseln. Das billigste /22 am Markt kann aus gutem Grund billig sein – Missbrauchshistorie, Blacklist-Einträge, Unregelmäßigkeiten im Routing. Blockgröße und Blockreputation sind getrennte Entscheidungen. Tauschen Sie nicht Qualität gegen Größe, um beim Monatspreis zu sparen. Die Folgekosten eines belasteten Blocks – Zustellprobleme, Bearbeitung von Abuse-Beschwerden, Zeit für die Wiederherstellung der Reputation – übersteigen die Ersparnis durchweg.

Eine vollständige Übersicht, was Sie vor dem Leasing prüfen sollten: Sechs häufige Fehler beim IPv4-Leasing →

Planen, einen geleasten Block in Ankündigungen kleiner als /24 aufzuteilen, ohne die Unterstützung des Upstreams zu prüfen. Viele Netzwerke filtern Präfixe, die spezifischer als /24 sind. Hängt Ihr Plan davon ab, ein /23 als zwei separate /24 anzukündigen – für geografische Vielfalt oder Traffic-Trennung –, lassen Sie sich vor der Unterschrift ausdrücklich bestätigen, dass Ihr Upstream das unterstützt. Die Konfiguration ist zulässig, erfordert aber eine Abstimmung mit dem Upstream, die nicht alle Provider anbieten.

Einen großen Block leasen, wo mehrere kleinere besser passen würden. Für Anwendungsfälle, die IP-Vielfalt über Kunden, Dienste oder Regionen brauchen – Hosting, Rechenzentren, VPN –, sind mehrere /24 oder /23 einem einzelnen /21 bei Reputationsisolation und operativer Flexibilität oft überlegen. Konsolidierung wirkt auf dem Papier einfacher. In der Praxis begrenzt Segmentierung die Auswirkungen, wenn etwas schiefgeht.

Die richtige Größe von Anfang an beseitigt zwei der häufigsten und am leichtesten vermeidbaren Kostenfaktoren beim IPv4-Leasing. Die meisten Teams wissen entweder ungefähr, was sie brauchen, und suchen Bestätigung – oder sie haben schon einmal falsch dimensioniert und wollen einen Rahmen, um das nicht zu wiederholen. In beiden Fällen geben Ihnen die Tabelle der Anwendungsfälle und der Rahmen aus vier Variablen, was Sie für eine belastbare Entscheidung brauchen.

Sehen Sie sich verfügbare IPv4-Blöcke nach Größe und Region bei IPbnb an oder schätzen Sie Ihre Leasingkosten vor der Entscheidung: IPv4-Preisrechner →