← Zurück zum Blog

Selbst gehostete IP-Geolocation-Datenbank vs. API

Selbst gehostete IP-Geolocation-Datenbank vs. API

Eine selbst gehostete IP-Geolocation-Datenbank ist eine Datei, die Sie herunterladen und im eigenen Prozess abfragen, während eine IP-Geolocation-API ein Netzwerkaufruf an einen Anbieter ist, der die Daten hält und für Sie aktualisiert. Bei der Wahl geht es vor allem darum, wo Sie zahlen wollen: in Betriebsaufwand und Disziplin bei Updates oder in Netzwerklatenz und Abhängigkeit vom Dienst eines anderen.

Was das Selbst-Hosten einer IP-Datenbank bedeutet

Bei einer selbst gehosteten Datenbank liegt eine Binärdatei (je nach Anbieter und enthaltenen Feldern oft einige zehn bis mehrere hundert Megabyte) neben Ihrer Anwendung. Abfragen sind Lesezugriffe im Arbeitsspeicher, die typischerweise in Mikrosekunden fertig sind, es gibt keinen Netzwerksprung pro Anfrage, und keine Adresse verlässt Ihre Infrastruktur. Letzteres ist wichtig, wenn Ihre Datenschutzprüfung die IP eines Besuchers als personenbezogenes Datum behandelt, das nicht an Dritte weitergegeben werden soll.

Die Kosten liegen in allem rund um die Datei. Jemand muss neue Releases nach Zeitplan herunterladen, validieren, auf jeden Server oder Container ausrollen und den Fall behandeln, dass ein Deployment eine veraltete Kopie ausliefert. Die Lizenzierung unterscheidet sich je nach Anbieter, und manche kommerziellen Datenbanken haben Bedingungen, die von kostenlosen abweichen. Lesen Sie sie, bevor Sie eine Datei in ein Produkt einbetten. Eine Datenbank beantwortet außerdem nur, was sie enthält: Wollen Sie VPN-, Tor- oder Abuse-Flags, stammen die aus separaten Dateien oder Diensten, die Sie in eigenem Takt aktualisieren müssen.

Was eine IP-Geolocation-API ändert

Eine API verlagert die Datenpipeline zum Anbieter. Sie senden eine Adresse und erhalten strukturiertes JSON zurück, und die dahinterliegenden Daten werden aktualisiert, ohne dass Sie ein Deployment anfassen. Für ein kleines Team entfällt damit eine wiederkehrende Aufgabe. Es erleichtert auch den Zugang zu Feldern, die sich als Datei umständlich ausliefern ließen. Ein einziger Aufruf der IP-Abfrage von ipto liefert Land, Stadt, ASN, Organisation und Währungscode sowie die Flags is_vpn, is_tor, is_abuser, is_datacenter und bogon mit bogon_type.

Die Abwägungen sind real. Jede Abfrage fügt einen Netzwerk-Roundtrip hinzu, die Latenz wird also in Millisekunden statt Mikrosekunden gemessen. Sie hängen von Verfügbarkeit und Rate Limits des Anbieters ab, brauchen also Timeouts, einen Fallback und idealerweise einen Cache. Und die Adresse wird an einen Dritten gesendet, was in Ihre Datenschutzdokumentation gehört. ipto ist kostenlos, ohne Anmeldung nutzbar und erlaubt 1.000 kostenlose Anfragen pro Tag, genug zum Prototyping oder für einen Dienst mit geringem Volumen, wobei Workloads mit hohem Traffic dieses Limit einplanen sollten.

Aktualität ist nicht dasselbe wie Genauigkeit

Oft wird angenommen, eine API sei genauer, weil sie „live“ ist. Meist ist sie nur aktueller. Das zugrunde liegende Problem, eine Adresse einem Ort zuzuordnen, ist in beiden Fällen dasselbe, und Ergebnisse auf Stadtebene sind bei beiden Modellen schwächer als auf Länderebene, besonders bei Mobilfunk- und Privatanschlüssen. Der Unterschied liegt darin, wie veraltet die Daten werden können. Eine selbst gehostete Datei ist so alt wie Ihre letzte erfolgreiche Aktualisierung. Eine API ist so alt wie der Aktualisierungszyklus des Anbieters: Bei ipto werden Threat Feeds (VPN, Tor, Abuse) alle 6 Stunden aktualisiert und die IP- und ASN-Datensätze täglich. Keines von beiden ist Echtzeit, und ein brandneuer VPN-Endpunkt wird erst markiert, wenn ein Feed ihn aufgreift.

Eine praktische Entscheidungsregel

  • Sehr hohes Volumen oder hartes Latenzbudget: Eine lokale Datenbank gewinnt meist, da Netzwerkkosten pro Aufruf und Rate Limits entfallen.
  • Strenge Regeln zur Datenresidenz: Halten Sie Abfragen lokal, da keine Adresse irgendwohin übertragen wird.
  • Kleines Team, moderater Traffic, Bedarf an Risikosignalen: Eine API ist meist günstiger an Engineering-Zeit, weil Feeds, ASN-Daten und Reputation bereits zusammengestellt sind.
  • Dazwischen: Nutzen Sie eine API mit lokalem Cache, der nach Adresse (oder nach Netzbereich) verschlüsselt ist, und einer sinnvollen Time-to-Live. Viele Anwendungen sehen dieselben Adressen wiederholt, sodass der Cache den Großteil des Traffics abfängt.

Sie können die Modelle auch kombinieren: eine lokale Datei auf Länderebene für den Hot Path und einen API-Aufruf nur, wenn eine Anfrage ungewöhnlich aussieht und Sie ASN-, VPN- oder Abuse-Kontext wollen. Der VPN-, Tor- und Proxy-Checker zeigt genau, wie diese Risiko-Flags für eine bestimmte Adresse aussehen, und die ASN-Abfrage zeigt den Netzinhaber dahinter. Das Anfrage- und Antwortformat ist in der API-Dokumentation beschrieben.

Erst ausprobieren, dann entscheiden

Am günstigsten bewerten Sie das API-Modell, indem Sie Ihre realen Traffic-Stichproben hindurchlaufen lassen und vergleichen. Fügen Sie ein paar Adressen aus Ihren Logs in den IP-Abuse-Checker ein oder rufen Sie den Lookup-Endpunkt aus einem Skript auf und messen Sie den Roundtrip dort, wo Ihre Server tatsächlich laufen. Messen Sie Ihre eigene Latenz und Trefferquote, statt einer allgemeinen Behauptung zu vertrauen, und entscheiden Sie, ob die verbleibenden Unterschiede rechtfertigen, selbst eine Datenpipeline zu betreiben.

Klare Antworten

In der Regel ja, weil eine lokale Abfrage ein Lesezugriff im Arbeitsspeicher ohne Netzwerk-Roundtrip ist. Ein API-Aufruf fügt Netzwerklatenz hinzu, die ein lokaler Cache bei wiederholten Adressen weitgehend verbergen kann.
Nicht von Haus aus. Beide ordnen Adressen mit ähnlichen Daten Orten zu, daher ist die Genauigkeit auf Stadtebene in beiden Fällen begrenzt; eine API ist vor allem aktueller, weil der Anbieter die Updates übernimmt.
ipto wird als kostenlose API und Web-Tools mit 1.000 kostenlosen Anfragen pro Tag angeboten, nicht als herunterladbare Datenbank. Teams, die vollständig lokale Abfragen brauchen, benötigten eine separate lokale Datei.
← Zurück zum Blog