Hetzner Online und AS24940: Auch günstige Cloud-Dienste brauchen

Zusammenfassung

Der RDAP-Datensatz des RIPE NCC führt AS24940 als aktives HETZNER-AS und nennt Hetzner Online GmbH bei der registrierten Organisation. Ein RIPEstat-Abruf vom 5. August 2026 zeigte das ASN als angekündigt und enthielt 94 beobachtete Präfixeinträge, davon 89 für IPv4 und fünf für IPv6. Das ist ein datierter Identitäts- und Routingbeleg, aber kein Verfügbarkeitszertifikat.
Hetzner beschreibt miteinander verbundene Rechenzentrumsparks, DDoS-Schutz, Cloud-Backups, Snapshots und eine definierte Verfügbarkeitszusage für Cloud Server. Zugleich weisen die Bedingungen den Betreibern von Root- und Cloud-Servern wesentliche Aufgaben zu: Sie administrieren und sichern ihre Systeme, sorgen für geeignete Datenkopien und müssen die Wiederherstellung des eigentlichen Dienstes selbst prüfen.

Hetzner Online GmbH verkauft Cloud Server, dedizierte Systeme, Speicher und weitere Infrastrukturleistungen. Viele kleine Unternehmen wählen den Anbieter wegen eines leicht verständlichen Angebots und vergleichsweise niedriger monatlicher Kosten. Diese Vorteile verschwinden nicht, wenn man die Betriebsrisiken betrachtet. Sie müssen nur in den richtigen Zusammenhang eingeordnet werden.

Ein produktiver Dienst besteht selten aus genau einem Server. Zu ihm gehören Internetwege, DNS, Benutzerkonten, Zertifikate, Firewall-Regeln, Datenbanken, externe Schnittstellen, Überwachung und Menschen mit Entscheidungsbefugnis. Die Rechnung für Rechenleistung enthält nicht automatisch die Arbeit, die diese Teile zu einem belastbaren Gesamtsystem verbindet.

AS24940 macht einen Ausschnitt dieser Kette öffentlich sichtbar. Eine Autonomous System Number, kurz ASN, ist eine eindeutige Kennung, mit der ein Netz Routinginformationen mit anderen Netzen austauscht. Für Nichtfachleute ist sie mit dem Namen eines Betreibers auf einer Straßenkarte vergleichbar. Der Eintrag hilft bei der Zuordnung eines Weges. Er beweist nicht, dass eine Bestellung, Anmeldung oder Datensicherung erfolgreich war.

Darum trennt diese Analyse mehrere Ebenen. Ein Register beantwortet Verwaltungs- und Identitätsfragen. Routingbeobachtungen zeigen, was Messpunkte in einem Zeitraum gesehen haben. Ein Betreiberverzeichnis beschreibt veröffentlichte Interkonnektivität. Ein SLA misst einen vertraglich festgelegten Gegenstand. Erst ein Test im Kundensystem belegt, dass eine Geschäftsfunktion wieder arbeitet.

Das Titelbild ist eine für BTW Media erzeugte, fotorealistische redaktionelle Szene. Zu sehen ist eine nicht identifizierbare Person bei der Prüfung eines markenlosen Netzwerkschranks. Das Bild zeigt weder Beschäftigte noch Rechenzentren, Technik, Kunden, Vorfälle oder Leistungswerte von Hetzner Online GmbH und vermittelt keine Billigung.

Das Register hält Identität fest, nicht die gesamte Betriebswirklichkeit

Grundlage der Verknüpfung ist der veröffentlichte COMPANY-Eintrag „Hetzner Online GmbH“ im BTW-Verzeichnis. Bei der aktuellen Kollisionsprüfung war diesem Objekt noch kein ArticleEntity-Link zugeordnet. Ähnlich benannte Einträge anderer Typen oder Kontexte wurden nicht ersatzweise verwendet.

Die RDAP-Antwort des RIPE NCC bezeichnet AS24940 als HETZNER-AS, meldet den Status active und nennt Hetzner Online GmbH in Organisations- und Kontaktfeldern. RDAP steht für Registration Data Access Protocol und stellt Registerdaten in strukturierter Form bereit. Der eingefrorene Abruf enthält den 3. Juni 2002 als ursprüngliches Registrierungsereignis und den 30. Juni 2026 als letzte Änderung.

Ein solcher Datensatz ist für den Betrieb wertvoll. Eine eindeutige Nummer, ein zugeordnetes Unternehmen und gepflegte Rollen schaffen einen Ausgangspunkt für Routingfragen, Missbrauchsmeldungen und Eskalationen. Veränderungen lassen sich gegen eine bekannte Fassung prüfen.

Das Register verfügt aber nicht über alle laufenden Systeme. Es bildet weder jeden Router und Glasfaserweg noch jedes Rechenzentrum, Produkt, Vertragsverhältnis oder Kundenkonto ab. Es misst keine Kapazität, Latenz oder Reparaturdauer. Selbst eine formal korrekte Kontaktadresse sagt nichts über die tatsächliche Reaktionszeit aus.

Die Beweisfrage entscheidet daher über die Quelle. Wer wissen will, wer für AS24940 eingetragen ist, nutzt RDAP. Wer eine aktuell sichtbare Route untersuchen will, braucht Beobachtungsdaten. Ob die Gehaltsabrechnung durchlief, kann nur der betroffene Geschäftsprozess zeigen.

Ein belastbarer Kontrollprozess gleicht Register, internes Inventar, Routenautorisierungen, beobachtete BGP-Ankündigungen und betriebliche Kontakte ab. Eine Abweichung ist nicht automatisch ein Missbrauchsfall. Sie ist ein Grund, eine Migration, Kundenbeziehung, verzögerte Pflege oder Fehlkonfiguration zu untersuchen.

94 beobachtete Präfixe sind eine Momentaufnahme

Der AS-Überblick von RIPEstat verband die Ressource 24940 am 5. August 2026 mit HETZNER-AS Hetzner Online GmbH und kennzeichnete sie als announced. Vereinfacht gesagt konnten Routingkollektoren die Beteiligung des autonomen Systems am weltweiten Routingaustausch sehen.

Der Datensatz zu angekündigten Präfixen nannte ein Beobachtungsfenster vom 22. Juli bis 5. August. Er enthielt 94 Einträge, darunter 89 IPv4- und fünf IPv6-Präfixe. Ein Präfix beschreibt einen Adressblock. Der Abruf belegt damit Sichtbarkeit in beiden Adressfamilien zu dieser Zeit.

Die Zahl ist weder eine Kunden- noch eine Server-, Standort- oder Produktzählung. Kollektoren beobachten aus bestimmten Perspektiven, und Routen verändern sich. Aggregation kann dazu führen, dass verschiedene Datensätze unterschiedlich viele Zeilen enthalten, obwohl sie keinen unmittelbaren Widerspruch darstellen.

Auch Eigentum oder Autorisierung folgt nicht allein aus der Beobachtung. Registerdaten, laufendes BGP und RPKI Route Origin Authorizations beantworten unterschiedliche Fragen. Keine einzelne Quelle beschreibt zugleich rechtliche Zuordnung, kryptografische Autorisierung, physische Topologie und Anwendungsverfügbarkeit.

Für Kunden bleibt der Blick auf Routen relevant. Verschwindet ein erwartetes Präfix an mehreren Messpunkten oder taucht eine unerwartete Herkunft auf, sollte jemand die Änderung mit dem Sollzustand vergleichen. Das Team braucht dafür eine Liste wichtiger Domains und Adressen, erwartete Ursprünge, Eskalationskontakte und eine verständliche Entscheidungsschwelle.

Eine Geschäftsleitung muss BGP nicht selbst bedienen. Sie sollte aber wissen, wer die Routingabhängigkeit überwacht, welche Auswirkungen ein Alarm haben kann und welcher Diensttest das Ende einer Störung bestätigt.

PeeringDB bietet Orientierung statt Kapazitätsgarantie

Im erfassten PeeringDB-Profil wird das Netz als Hetzner Online bezeichnet, mit AS24940 und AS-HETZNER verbunden, als Content eingeordnet und mit einer offenen allgemeinen Peering-Policy beschrieben. Außerdem enthält das Profil geschätzte Präfixzahlen. Diese Felder haben einen anderen Zweck und Umfang als die beobachteten Einträge von RIPEstat.

Die separaten Schnittstellen lieferten 63 NetIXLAN-Zeilen über 49 verschiedene Internet-Exchange-Kennungen sowie 23 NetFac-Zeilen für 23 verschiedene Einrichtungen. Alle erfassten Exchange-LAN-Zeilen waren als operational markiert. Die Änderungsdaten der einzelnen Datensätze waren nicht einheitlich.

Das ist ein nützlicher Hinweis auf eine umfangreiche veröffentlichte Interkonnektivitätsfläche. Es ist kein Beweis für momentanen Datenverkehr, freie Kapazität oder echte physische Unabhängigkeit. Zwei Ports können einen Leitungsweg, eine Stromversorgung oder einen Metropolbereich teilen. Ein gelisteter Standort muss nicht Teil des Pfades eines bestimmten Kunden sein.

Betreibergepflegte Metadaten können außerdem veralten. Die richtige Anwendung besteht darin, Kontaktaufnahme und Planung zu unterstützen. Aktuelle Verträge, Telemetrie, Pfadtests und direkte Bestätigungen bleiben notwendig, bevor aus einem Verzeichniseintrag eine Resilienzaussage wird.

Diese Grenze ist kein Mangel der Quelle. Sie beschreibt ihre Rolle. Eine Karte kann die Wirklichkeit ordnen, ohne sie zu beherrschen. Die laufende Netz- und Anwendungsschicht entscheidet, was tatsächlich funktioniert.

Virtuelle Produkte beruhen auf physischen Ketten

Hetzners Infrastrukturdokumentation zählt acht Rechenzentren im Park Nürnberg, 22 in Falkenstein und zehn in Helsinki auf. Sie beschreibt unterbrechungsfreie Stromversorgung, Dieselgeneratoren, Strompfade und redundante Dark-Fibre-Verbindungen zum Backbone. Für benannte Verbindungen zwischen Nürnberg, Falkenstein und Frankfurt werden mindestens 120 Gbit/s genannt.

Diese Aussagen stammen vom Unternehmen selbst und ersetzen kein unabhängiges technisches Audit. Sie zeigen dennoch die materiellen Abhängigkeiten hinter einer virtuellen Maschine: Host, Switches, Stromverteilung, Kühlung, Glasfaser, externe Konnektivität und Personal vor Ort.

Redundanz braucht eine genaue Definition. Zwei Netzteile schützen gegen bestimmte Komponentenfehler, nicht gegen jedes Stromereignis. Zwei Fasern helfen bei einem Schnitt nur, wenn ihre Wege im entscheidenden Abschnitt getrennt sind. Mehrere Standorte nützen erst dann, wenn Anwendung, Daten und Steuerung tatsächlich wechseln können.

Kunden benötigen keine geheimen Baupläne. Sie müssen aber Standort, Produktgrenzen und relevante Ausfalldomänen kennen. Eine Kopie im selben Rack schützt anders als eine Kopie in einem anderen Brandabschnitt oder einer anderen Region. Jede zusätzliche Distanz bringt zugleich Kosten, Datenübertragung, Latenz und Rechtsfragen mit sich.

Das Ziel ist deshalb nicht maximale Vervielfachung, sondern passende und getestete Unabhängigkeit. Eine Architektur muss zu den Folgen eines Ausfalls und zu den Fähigkeiten des betreibenden Teams passen.

99,9 Prozent messen nicht den vollständigen Geschäftsprozess

Das veröffentlichte Cloud-Server-SLA von Hetzner nennt 99,9 Prozent monatliche Verfügbarkeit je Cloud Server. Die Definition bezieht sich auf den Aktivitätszustand der Instanz und die Funktion von Host beziehungsweise Hypervisor. Das Dokument nennt Ausschlüsse, einen Antragsweg und Cloud Credits als beschriebenes Rechtsmittel.

Diese Kennzahl ist sinnvoll, wenn ihr Messobjekt erhalten bleibt. Sie ist keine automatische Zusage für DNS, Datenbank, Kundensoftware, Identitätsdienst, Zahlungsanbieter oder den Weg eines Endnutzers. Jede dieser Schichten kann den Dienst stoppen, obwohl der Cloud Server nach der SLA-Definition verfügbar ist.

Eine Instanz kann laufen, während die Anwendung nicht lauscht. Das Betriebssystem kann starten, ohne erwartete Daten einzubinden. Die Website kann erscheinen, während der Bezahlvorgang scheitert. Ein abgelaufenes Zertifikat oder eine falsche Firewall-Regel kann Nutzer aussperren, ohne dass der Host ausgefallen ist.

Prozentangaben sagen außerdem nichts über akzeptablen Datenverlust. Das Unternehmen braucht ein Recovery Time Objective für die vertretbare Unterbrechung und ein Recovery Point Objective für den tolerierbaren Informationsverlust. Beide Werte müssen auf den Geschäftsprozess bezogen sein.

Am Ende braucht es einen Transaktionstest. Ein Händler führt eine kontrollierte Bestellung aus, ein Medienbetrieb öffnet und exportiert eine Datei, ein internes System beendet einen vollständigen Vorgang. Erst dann ist „wiederhergestellt“ mehr als ein grüner Infrastrukturstatus.

Bei Root- und Cloud-Servern bleibt Administration Kundenarbeit

Hetzners allgemeine Bedingungen ordnen die Administration und Absicherung von Root- und Cloud-Systemen dem Kunden zu. Dieses Verantwortungsmodell ist bei Infrastructure as a Service üblich. Der Anbieter betreibt die vereinbarte Plattform; der Kunde entscheidet über Betriebssystem, Anwendungen, Konten, Daten und zahlreiche Sicherheitsregeln.

Jemand muss Aktualisierungen installieren, Angriffsflächen reduzieren, Schlüssel verwahren, frühere Nutzer entfernen, Protokolle prüfen und auf Missbrauch reagieren. Fehlt ein eindeutiger Eigentümer, wird ein günstiger Server schnell teuer. Die ausgelassene Betriebsarbeit erscheint später als Incident, Datenverlust oder ungeplante Arbeitszeit.

Auch Berechtigungen müssen vor einer Störung geklärt sein. Wer darf eine Instanz neu starten, DNS ändern, ein Backup wiederherstellen oder ein Ticket eröffnen? Wo liegen Wiederherstellungscodes? Wer kann eine Änderung freigeben, wenn die übliche Person nicht erreichbar ist?

Geteilte Konten wirken kurzfristig praktisch, erschweren aber Ursachenanalyse und Widerruf. Individuelle Zugänge, protokollierte Notfallrechte und ein regelmäßig geprüfter Besitzer schaffen zugleich Geschwindigkeit und Nachvollziehbarkeit.

Überwachung bedeutet nicht, ständig auf ein Dashboard zu schauen. Sie verbindet Signale mit Zuständigkeiten, Grenzwerten und Handlungen. Ein Alarm muss die Person erreichen, die entscheiden kann, und den betroffenen Geschäftsdienst benennen.

Backup ist erst nach einer Wiederherstellung ein belastbarer Kontrollnachweis

Die Cloud-FAQ unterscheidet optionale automatische Backups und manuell erstellte Snapshots. Bei aktiviertem Backup werden bis zu sieben tägliche Sicherungspunkte aufbewahrt. Backups sind an den Server gebunden, werden bei dessen Löschung mit entfernt und besitzen keinen Löschschutz. Snapshots können gegen Löschung geschützt werden.

Diese Lebenszyklen sind wichtiger als das Wort „Backup“. Wenn dieselbe Handlung Produktion und einzige Kopie löscht, bleibt ein gemeinsamer Fehlerbereich. Kompromittierte Zugangsdaten können möglicherweise beide erreichen. Sieben tägliche Stände helfen nicht gegen eine erst Wochen später bemerkte Beschädigung.

Die betriebliche Checkliste muss daher konkreter sein: Welche Daten werden erfasst? In welchem Intervall? Wie lange? Unter welcher Identität? In welcher Region? Mit welchem Löschschutz? Wann wurde die letzte Wiederherstellung tatsächlich durchgeführt?

Eine regelmäßig angelegte, unabhängig kontrollierte Kopie kann den gemeinsamen Fehlerbereich verkleinern. Abhängig vom Risiko liegt sie in einem anderen Projekt, unter einer anderen Berechtigung, bei einem zweiten Anbieter oder offline. Unabhängigkeit ist eine Autoritäts- und nicht nur eine Entfernungsfrage.

Ein Wiederherstellungstest sollte Zeit, Datenstand, Vollständigkeit und Geschäftsfunktion erfassen. Ein erfolgreich entpacktes Archiv ist noch kein funktionierender Dienst. Konfiguration, Schlüssel, Datenbank, Anwendung und Abhängigkeiten müssen zusammenpassen.

DDoS-Schutz ist ein Kontrollbaustein

In den veröffentlichten technischen und organisatorischen Maßnahmen beschreibt Hetzner physische und logische Sicherheitskontrollen und verweist auf DDoS-Schutz. Bei einem verteilten Denial-of-Service-Angriff versuchen viele Quellen, Wege oder Systeme mit Datenverkehr zu überlasten. Filterung im Netz des Anbieters kann wichtig sein, weil der einzelne Kunde die vorgeschalteten Leitungen nicht kontrolliert.

Aus der Existenz eines Filters folgt nicht, dass jede Angriffsart und jedes Protokoll ohne Beeinträchtigung bleibt. Angriffe können ihre Form verändern oder die Anwendung mit scheinbar legitimen Anfragen belasten. Viele Ausfälle haben außerdem gar keinen Angriffsbezug, sondern entstehen durch Software, Konfiguration, DNS, Speicher, Konten oder externe Dienste.

Deshalb braucht die Anwendung zusätzliche Kontrollen: sinnvolle Ratenbegrenzung, Caches, Warteschlangen, Authentifizierung, Kapazitätsgrenzen und ein geübtes Incident-Verfahren. Netzfilterung und Anwendungsresilienz ergänzen sich; sie sind nicht austauschbar.

Ein Kunde sollte den Eskalationsweg kennen und Daten aufbewahren, die Angriff, Überlastung und Anwendungsfehler unterscheidbar machen. Ohne diesen Kontext arbeiten mehrere Teams möglicherweise am falschen Problem.

Standortentscheidungen verändern die Abhängigkeitskette

Hetzners Datenschutz- und Standortinformationen erläutern Wahlmöglichkeiten und weisen darauf hin, dass Angebote in den USA und Singapur Einrichtungen Dritter nutzen, während Hetzner Online GmbH Vertragspartner bleibt. „Bei Hetzner“ bezeichnet daher nicht in jedem Fall eine identische physische Betreiberkette.

Der Standort beeinflusst Latenz, Routing, Rechtsrahmen, Unterauftragnehmer, Supportzeiten und Kosten des Datentransfers. Das Team sollte die Entscheidung pro Dienst dokumentieren. Eine Erinnerung der Person, die den Server angelegt hat, ist kein dauerhaftes Inventar.

Datenresidenz und Wiederherstellbarkeit sind getrennte Ziele. Eine regelkonforme Kopie kann wegen eines Kontoproblems unerreichbar sein. Eine zusätzliche Region kann die Kontinuität verbessern und gleichzeitig neue Transfer- oder Rechtsfragen aufwerfen. Beide Dimensionen gehören in dieselbe Entscheidung.

Vor dem Start sollten Datenklassen, erlaubte Standorte, Rollen, externe Abhängigkeiten und ein Ausstiegsweg feststehen. Später muss das tatsächliche Inventar mit dieser Freigabe abgeglichen werden.

Alltagsszenarien zeigen, wer handeln muss

Eine kleine Webanwendung kann auf einem einzelnen Cloud Server laufen. Ist dessen Datenträger voll, kann der Host weiterhin als verfügbar erscheinen. Nur ein anwendungsnaher Alarm zeigt die Wirkung. Der Verantwortliche muss Platz sicher schaffen, die Ursache beheben und einen Nutzerweg testen.

Wird der Server versehentlich gelöscht, können gebundene Backups mit verschwinden. Ein geschützter Snapshot oder eine externe Kopie verändert den Ausgang. Entscheidend sind Lebenszyklus und Berechtigungsgrenze, nicht nur die erfolgreiche Meldung des letzten Sicherungslaufs.

Auch DNS kann den Dienst stoppen. Netz und Instanz funktionieren, aber ein Eintrag zeigt auf eine falsche Adresse oder die Domain läuft ab. Dann braucht das Team Zugriff auf Registrar und DNS-Anbieter, Wissen über Zwischenspeicherung und Tests aus mehreren Netzen.

Bei einem Routingproblem hilft die Beobachtung von AS24940, die Ebene einzugrenzen. Sie erklärt jedoch nicht jede Nutzerperspektive. Messungen von mehreren Orten, Traceroutes, Anbieterinformationen und Kundentelemetrie müssen zusammengeführt werden.

Schließlich kann eine Softwareänderung die Anwendung beschädigen, obwohl die Infrastruktur fehlerfrei ist. Ein kontrollierter Rollback, eine Testumgebung und beobachtbare Releases gehören zur Verantwortung des Kunden. Vorschnelle Schuldzuweisungen verlängern nur die Diagnose.

Günstige Infrastruktur hat zusätzliche Betriebs- und Integrationskosten

Zu den Gesamtkosten gehören neben der monatlichen Instanz Speicher, Datenverkehr, Monitoring, Administration, Sicherheitsarbeit, Bereitschaft, Wiederherstellungstests und spätere Migration. Ein preisgünstiges Angebot kann nach dieser Rechnung weiterhin sehr attraktiv sein. Voraussetzung ist, dass die fehlenden Aufgaben nicht unsichtbar bleiben.

Auch Integrationen bilden Fehlerquellen. Eine Automatisierung kann wegen eines veralteten Inventars das falsche System neu starten. Ein Alarm kann in einem unbetreuten Postfach enden. Ein Backup-Token kann ablaufen. Ein gemeinsames Dashboard kann grün sein, obwohl der Nutzerprozess scheitert.

Jede kritische Verbindung braucht daher einen Besitzer, ein Signal für ihr eigenes Versagen und gegebenenfalls einen manuellen Ersatzweg. Nicht jede Komponente muss doppelt vorhanden sein. Die Organisation muss aber wissen, welche Einzelabhängigkeiten sie bewusst akzeptiert.

Für kleine Teams genügt oft eine knappe Dienstkarte: Geschäftsfunktion, verantwortliche Person, Standort, Domain, Instanz, Daten, Backup, letzter Test, Anbieterkanal und Notverfahren. Sie muss während einer Störung auffindbar und verständlich sein.

Ausfälle werden schnell zu Geschäftskosten

Der Schaden umfasst entgangene Einnahmen, stillstehende Arbeit, Kundensupport, technische Stunden, Kommunikation, mögliche Vertragsfolgen, Datenrekonstruktion und Vertrauensverlust. Eine Stunde hat für ein internes Archiv eine andere Bedeutung als für einen Bezahlvorgang.

Eine grobe Schätzung pro Stunde und kritischem Zeitfenster ist besser als keine. Sie hilft zu entscheiden, ob eine zweite Region, häufigere Kopie oder kürzere Bereitschaft wirtschaftlich ist. Wenn vier Stunden Stillstand existenzbedrohend wären, genügt ein nie getestetes Backup nicht.

Auch ein Anbieterwechsel kostet. Daten müssen vollständig exportiert, Formate geprüft, DNS und Zugänge geändert und das alte System erst nach gesicherter Beweislage beendet werden. Kleine regelmäßige Exportübungen reduzieren das Risiko einer hektischen Migration.

Preisvergleiche sollten deshalb die zuverlässig betriebene Lösung betrachten. Die billigste Rechnung kann Teil der besten Lösung sein, aber sie darf nicht mit der Gesamtheit der Verantwortung verwechselt werden.

Prüffragen für Beschaffung und laufenden Betrieb

Welcher Geschäftsprozess hängt von der jeweiligen Instanz ab, und wie lange darf er ausfallen?
Welcher Standort und welche Ausfalldomäne wurden gewählt?
Welches Objekt misst das SLA, und welche Schichten sind ausgeschlossen?
Wer besitzt Administrationszugang, DNS, Schlüssel, Backups und Supportrechte?
Wo liegen die Datenkopien, wie lange bleiben sie erhalten und wann wurde eine Wiederherstellung geprüft?
Welcher Nutzertest beweist das Ende eines Incidents?
Welche Domains, Präfixe und erwarteten Routingursprünge werden überwacht?
Gibt es einen dokumentierten Export- und Wechselweg?

Nach der Beschaffung müssen Antworten zu Nachweisen werden: aktuelles Inventar, getestete Alarme, protokollierte Restores, geprüfte Benutzer, erwartete Routen und geübte Incident-Schritte. Ein nur auf Folien vorhandener Kontrollpunkt schützt keinen Dienst.

Praktisches Fazit

AS24940 und die zugehörigen Quellen machen einen Teil von Hetzners Netzidentität und Betriebsfläche überprüfbar. Die erfassten Daten zeigen ein aktives registriertes ASN, beobachtete Routen und eine umfangreiche veröffentlichte Interkonnektivität. Unternehmensdokumente beschreiben physische, technische und vertragliche Kontrollen.

Keine dieser Quellen verspricht die Kontinuität eines beliebigen Kundensystems. Hetzner betreibt die vereinbarte Infrastruktur innerhalb ihres Umfangs. Kunden administrieren Anwendungen, Zugänge und Daten, überwachen Geschäftsfunktionen und testen Wiederherstellung. Weitere Anbieter können DNS, Zahlungen, Software oder Teile der physischen Kette kontrollieren.

Der belastbare Grundsatz lautet: Register als Buch der Zuordnung nutzen, laufende Systeme als Realität prüfen und beide Ebenen immer wieder abgleichen. Unabhängige Kopien, klare Autorität, verständliche Alarme und Ende-zu-Ende-Tests verwandeln günstige Rechenleistung in einen verantwortbaren Dienst.

Sources

Bildnachweis

Für BTW Media erzeugtes fotorealistisches Redaktionsbild: Eine generische, nicht identifizierbare Fachkraft prüft in einem gewöhnlichen Rechenzentrumsgang einen markenlosen Netzwerkschrank. Die Szene wurde mit dem integrierten Bildgenerator erstellt und ohne inhaltliche Veränderung als JPEG mit 1600 × 900 Pixeln ausgegeben. Sie zeigt keine reale Einrichtung, Beschäftigten, Kundenausstattung, Oberfläche oder Störung und stellt weder Hetzner Online GmbH noch deren Leistung oder Billigung dar.

Hetzner Online und AS24940: Auch günstige Cloud-Dienste brauchen teure Betriebsdisziplin

Warum es wichtig ist