Hetzner-Abrechnungsüberraschungen: Was AWS-, Azure- und GCP-Gewohnheiten falsch machen

Ein Wechsel zu Hetzner ist in der Regel positiv überraschend, denn das Preis-Leistungs-Verhältnis ist kaum zu schlagen. Abrechnungsüberraschungen folgen jedoch oft erst später, wenn Gewohnheiten aus AWS, Azure oder GCP zu Ergebnissen führen, die nicht den Erwartungen entsprechen.

Bei AWS folgen die Kosten in der Regel der Aktivität: Wenn man eine EC2-Instanz stoppt, stoppt auch der Compute-Preis. Ein EBS-Snapshot speichert nur die Änderungen seit dem letzten Snapshot. Eine Elastic IP, die an eine laufende Instanz gebunden ist, kostet nichts extra. Bei Hetzner hingegen folgen die Kosten der Existenz. Ist eine Ressource im Projekt vorhanden, wird sie berechnet – unabhängig davon, ob sie läuft, angebunden ist oder eine nützliche Funktion erfüllt.

Das ist kein Konstruktionsfehler. Es spiegelt eine bewusste Infrastrukturphilosophie wider: Wenn eine Ressource erstellt wird, reserviert Hetzner echte Hardware. Diese Reservierung bleibt bestehen, bis sie explizit freigegeben wird. Diesen Unterschied zu verstehen, ist entscheidend dafür, dass Hetzner-Rechnungen vorhersehbar bleiben. Nach der Preisanpassung vom 1. April 2026 kostet jedes dieser Modelle deutlich mehr als noch im ersten Quartal.

Ausgeschaltete Server werden zum vollen Serverpreis berechnet

Die AWS-Annahme: Eine EC2-Instanz zu stoppen, stoppt die Compute-Kosten. Während die Instanz ausgeschaltet ist, werden nur die Kosten für den EBS-Speicher fällig, nicht jedoch für vCPUs oder RAM.

Hetzner-Realität: Ein Server auszuschalten hat keinen Einfluss auf die Rechnung. Der Server, seine Festplatte und die zugewiesene IP-Adresse bleiben reserviert. Es wird der volle Serverpreis berechnet, bis der Server gelöscht wird – nicht nur gestoppt.

Hetzners Abrechnungs-FAQ heißt es eindeutig: „Until you, the customer, delete your servers, we will bill you for them, regardless of their state. This is because, internally, we allocate full resources to servers regardless of their power state."

Ein typisches Fehlermuster ist das folgende: Ein Entwicklungsteam in Nürnberg oder Helsinki erstellt vor einem riskanten Deployment einen Snapshot, schaltet den Server „vorübergehend” während eines Sprints aus und vergisst ihn dann für sechs Wochen. Beim CCX13-Tarif von 15,99 € pro Monat kostet diese vergessene Instanz 192 € pro Jahr, ohne eine einzige Anfrage zu verarbeiten.

Einen Server zu stoppen, ist ein valider operativer Schritt, aber er bedeutet nicht, dass weniger gezahlt wird. Wenn ein Server nicht mehr benötigt wird, sollte er gelöscht werden. Ein vorheriger Snapshot ermöglicht eine spätere Wiederherstellung; ein neuer Server kann jederzeit aus diesem Snapshot erstellt werden.

IPv4-Adressen werden pro Adresse und Stunde berechnet, auch wenn keine Verbindung besteht.

Seit Februar 2024 berechnet Hetzner primäre IPv4-Adressen unabhängig von den zugehörigen Servern. Jede primäre IPv4-Adresse kostet ca. 0,50 € pro Monat, unabhängig davon, ob sie einem laufenden Server zugewiesen ist.

Die erste Falle: IP-Adressen, die ihre Server überleben. Beim Löschen eines Servers löscht Hetzner dessen IP-Adresse nicht automatisch. Wird die Adresse „für alle Fälle” behalten und nie zurückgegeben, fallen für jede ungenutzte Adresse dauerhaft 0,50 € pro Monat an. In Infrastrukturen, die regelmäßig Server austauschen – CI/CD-Pipelines, Staging-Umgebungen, kurzlebige Testinstanzen – können sich unbemerkt nicht zugewiesene IP-Adressen anhäufen, bis die Rechnung kommt.

Die zweite Falle: Floating IPs. Floating IPv4-Adressen kosten 3,00 € pro Monat und werden unabhängig davon berechnet, ob sie an einen Server gebunden sind. AWS begann im Februar 2024 ebenfalls mit der Berechnung aller öffentlichen IPv4-Adressen (0,005 $ pro Stunde bzw. ca. 3,65 $ pro Monat), sodass eine Berechnung unabhängig von der Zuweisung kein Hetzner-Spezifikum mehr ist. Das Fehlermuster unterscheidet sich jedoch: Eine als Hochverfügbarkeits-Failover reservierte Floating IP, die nie tatsächlich ausgelöst wird, kostet 36 € pro Jahr.

Bei 50 Servern mit je einer primären IPv4-Adresse entspricht das 25 € pro Monat an IP-Kosten, bevor ein einziges Compute-Byte übertragen wird. Zwei nicht zugewiesene Floating IPs erhöhen die Rechnung weiter, obwohl diese Adressen keinen Mehrwert liefern.

Backups kosten 20 % des Serverpreises, unabhängig davon, wie viel Daten auf der Festplatte liegen

Die AWS-Annahme: Die Backup-Kosten korrelieren mit dem genutzten Speicher. AWS EBS-Snapshots sind inkrementell und werden pro Gigabyte gespeicherter Daten berechnet.

Hetzner-Realität: Das Aktivieren automatischer Backups verursacht einen pauschalen Aufschlag von 20 % auf den Serverpreis. Ein CCX13-Server, der 15,99 € pro Monat kostet, würde somit 3,20 € zusätzliche Kosten für Backups verursachen – unabhängig davon, ob die Festplatte zu 2 % oder zu 95 % gefüllt ist. Im Gegenzug werden sieben Backup-Slots in einem rollierenden Zeitplan vorgehalten.

Dieses Modell betrifft Teams, die als Organisationsrichtlinie Backups standardmäßig auf allen Servern aktivieren. Eine Flotte von zehn CCX13-Entwicklungsservern verursacht somit Compute-Kosten von 159,90 € pro Monat und zusätzlich Backup-Kosten von 31,98 € pro Monat, obwohl solche Umgebungen üblicherweise keine nächtlichen Backups benötigen.

Der 20-%-Aufschlag wird jetzt auf einen höheren Basispreis angewendet: Backups auf einem CCX13 kosten nun 3,20 € pro Monat, gegenüber zuvor 2,40 € pro Monat. Diese Differenz summiert sich über eine Flotte, auf der Backups aktiviert und nie überprüft wurden. Der Beitrag zur Preiserhöhung im April 2026 behandelte dies im Kontext allgemeiner Kostensteigerungen; das eigentliche Problem ist ein Missverständnis des Abrechnungsmodells, nicht allein die Preisänderung.

Snapshots erfassen den vollständigen Festplattenzustand, nicht nur die Änderungen

Die AWS-Annahme: EBS-Snapshots sind von Haus aus inkrementell — jeder speichert nur die Blöcke, die sich seit dem vorherigen Snapshot geändert haben. Eine 100-GB-Festplatte mit 8 GB Daten ergibt einen Snapshot von ca. 8 GB, und ein zweiter Snapshot eines inaktiven Servers kostet nahezu nichts.

Hetzner-Realität: Hetzner-Snapshots sind vollständige Abbilder der Festplatte, keine inkrementellen Deltas. Jeder Snapshot erfasst den vollständigen Zustand der Festplatte zu diesem Zeitpunkt und wird komprimiert. Ein zweiter Snapshot desselben Servers hat daher ungefähr die gleiche Größe wie der erste, da es keine Deduplizierung über Snapshot-Versionen hinweg gibt.

Der Preis beträgt 0,0143 €/GB (gegenüber zuvor 0,0110 €/GB) und wird auf die tatsächliche komprimierte Imagegröße berechnet. Eine 160-GB-Festplatte mit 40 GB Daten ergibt beispielsweise einen 40–50 GB großen Snapshot, der ca. 0,57–0,72 € pro Monat kostet. Diese Zahl mag überschaubar wirken, aber bei drei Monaten Deployment-Snapshots ohne Aufbewahrungsrichtlinie: Zehn Snapshots à 0,65 € kosten 6,50 € pro Monat für Festplattenabbilder, die fast sicher keinen nützlichen Zeitpunkt mehr darstellen.

Die praktische Regel: Snapshots gezielt erstellen und nach einem festen Zeitplan löschen. Anders als bei AWS gibt es keine inkrementelle Kosteneinsparung durch weniger aktuelle Snapshots. Jeder Snapshot wird unabhängig bemessen.

Cloud-Server können nicht auf eine kleinere Größe als die ursprünglich provisionierte skaliert werden

Die AWS/Azure/GCP/OCI-Annahme: Compute und Speicher skalieren unabhängig voneinander. Bei EC2 sind EBS-Volumes separate Ressourcen; ein Wechsel von t3.large auf t3.medium lässt das Root-Volume unberührt. Azures VM-Resize-Dokumentation stellt ausdrücklich fest, dass „die Betriebssystem- und Datenfestplatten nicht betroffen sind". Bei GCP werden Maschinentyp und Persistent Disk über separate Befehle verwaltet. Bei OCI betreffen Shape-Änderungen OCPUs und RAM, während „Volume-Attachments gleich bleiben". Die Boot-Festplattengröße ist bei all diesen Anbietern vollständig vom Compute-Tier entkoppelt.

Hetzner-Realität: CPU- und RAM-Neuskalierung ist bei Hetzner reversibel. Die Festplatte nicht. Hetzners eigene Dokumentation ist direkt: „Rescaling to a plan with a smaller disk is not possible, regardless of how much storage you are actually using."

Wird von einem CCX23 (80 GB Festplatte) auf einen CCX33 (160 GB Festplatte) skaliert, um einen temporären Traffic-Peak abzufangen, kann anschließend nicht mehr auf den CCX23 zurück skaliert werden, weil die Festplatte jetzt zu groß ist. Es gibt keine automatisierte Lösung. Hetzner stellt keinen Snapshot auf einem Server wieder her, dessen Festplatte kleiner ist als die Quellfestplatte des Snapshots — der Wiederherstellungsprozess schlägt bei der Erstellung fehl, unabhängig davon, wie wenige Daten tatsächlich auf der Festplatte lagen. Die einzige Lösung ist eine manuelle Migration: Zunächst wird ein neuer, kleinerer Server provisioniert. Anschließend werden die Daten mit „rsync” oder einem gleichwertigen Tool übertragen. Zuletzt wird der alte Server außer Betrieb genommen. Diese Methode funktioniert nur, wenn die tatsächlichen Daten auf die Zielfestplatte passen, und sie erfordert geplante Downtime.

Hetzner bietet eine „Nur CPU und RAM“-Skalierungsoption, bei der die Festplattengröße beibehalten wird und der Downgrade-Pfad erhalten bleibt. Diese Option ist leicht zu übersehen, wenn der Standard ein Festplatten-Upgrade beinhaltet. Wer für eine temporäre Arbeitslast skaliert und erwartet, wieder zurückzuskalieren, sollte diese Option explizit auswählen.

Der Folgeeffekt: Eine größere Festplatte bedeutet einen größeren Snapshot. Ein Upgrade von einer 80-GB- auf eine 160-GB-Festplatte verdoppelt die Snapshot-Kosten dauerhaft – für jeden ab diesem Zeitpunkt erstellten Snapshot, auch wenn der zusätzliche Festplattenplatz nie genutzt wird.

Dedizierte Server, die über Robot bestellt werden, haben eine einmalige Einrichtungsgebühr

Hetzner hat zwei separate Bestellsysteme mit unterschiedlichen Funktionen: die Cloud Console (console.hetzner.cloud) und Robot (robot.hetzner.com). Cloud-Server haben keine Einrichtungsgebühr, sondern werden stündlich ab dem Moment der Provisionierung abgerechnet. Der Server ist dann innerhalb weniger Sekunden bereit. Dedizierte Server, die über Robot bestellt werden, funktionieren anders.

Robot-Dedicated-Server sind physische Maschinen, die speziell für den jeweiligen Kunden reserviert werden. Sie werden stündlich abgerechnet (Hetzner führte die Stundenabrechnung für Dedicated Server im Jahr 2024 ein), aber die meisten haben eine einmalige Einrichtungsgebühr, die zum Zeitpunkt der Provisionierung berechnet wird. Diese Gebühr erscheint auf der ersten Rechnung, bevor eine monatliche Nutzung anfällt. Im Februar 2026 erhöhte Hetzner die Einrichtungsgebühren und begründete dies mit gestiegenen Hardwarebeschaffungskosten.

Am bedeutendsten ist diese Gebühr bei GPU-Maschinen, da die Kosten im Verhältnis zur monatlichen Rate relativ hoch sind. Der GEX44 – Hetzners Einstiegs-GPU-Dedicated-Server – kostet 252,64 € pro Monat. Seine Einrichtungsgebühr beträgt 314,16 € – das sind 124 % des monatlichen Preises. Wer einen GEX44 bestellt, ihn eine Stunde lang betreibt und dann kündigt, erhält eine Rechnung über 314,56 €. Das ist der Mindestbetrag, unabhängig davon, wie kurz die Nutzung andauerte.

Die AWS/GCP-Gewohnheit, die hier nicht funktioniert: Das Starten einer GPU-Instanz (g5.xlarge oder p3.2xlarge) bei AWS verursacht keine Einrichtungsgebühr. Die Abrechnung erfolgt stündlich, beginnend mit der ersten Sekunde. Nach einer Stunde kann die Instanz beendet werden, wobei nur diese eine Stunde gezahlt werden muss. Bei Hetzner Robot ist die Hardware dediziert für den Kunden und nach dessen Vorgaben konfiguriert. Die einmaligen Provisionierungskosten fallen an, unabhängig davon, ob die Maschine eine Stunde oder ein Jahr betrieben wird.

Dieses Modell wird teuer, wenn der AWS-Ansatz wiederholt wird. Ein Beispiel: Ein Team provisioniert einen GEX44, führt einen Trainingsjob aus, terminiert ihn dann, um keine Kosten für Leerlaufzeit zu zahlen, und provisioniert ihn in der folgenden Woche erneut. Vor Ablauf eines vollen Monats hat es somit zwei Einrichtungsgebühren von insgesamt 628,32 € bezahlt. Die Einrichtungsgebühr fällt bei jeder neuen Provisionierung an.

Das Transparenzproblem verschlimmert die Situation zusätzlich. Die Gebühren für den Robot-Dedicated-Server erscheinen nicht in der Nutzungsvorschau der Hetzner Cloud Console, da diese ausschließlich Cloud-Ressourcen abdeckt. Die eigentliche Rechnung wird am zugewiesenen Abrechnungsdatum verschickt, welches Mitte des Folgemonats liegen kann. Ein Team, das mehrere Erstell- und Terminier-Zyklen durchläuft, hat in der Konsole keinen Hinweis auf die sich ansammelnden Einrichtungsgebühren – bis die Rechnung eintrifft.

Es gibt zwei Möglichkeiten, das Risiko durch Einrichtungsgebühren zu reduzieren. In Hetzners Server-Auktion (Serverbörse unter robot.hetzner.com/order/market) werden vorprovisionierte Dedicated Server ohne Einrichtungsgebühren gelistet. Der GEX44 taucht dort gelegentlich auf. Wenn Sie ihn über die Auktion bestellen, entfällt die Einrichtungsgebühr. Die Verfügbarkeit ist jedoch nicht garantiert und die Konfigurationen entsprechen möglicherweise nicht den genauen Anforderungen. Zweitens umfassen alle über Robot provisionierten Dedicated Server unbegrenztes Traffic-Volumen auf einem 1-Gbit-Uplink – ein erheblicher Vorteil gegenüber Cloud-Servern, die eine monatliche Traffic-Quote pro Server haben.

Die Provisionierungszeit unterscheidet sich ebenfalls: Robot-Dedicated-Server benötigen ein bis drei Werktage, während Cloud-Server innerhalb von Sekunden bereit sind.

Es gibt kein verwaltetes NAT-Gateway; ein Server mit öffentlicher IP ist standardmäßig aus dem Internet erreichbar

Die AWS/GCP-Annahme: VMs in privaten Subnetzen erreichen das Internet über ein verwaltetes NAT-Gateway — ein Cloud-Service, der ausgehende Verbindungen ohne Zuweisung einer öffentlichen IP an jede VM ermöglicht. Die VM selbst ist nie direkt aus dem Internet erreichbar, auch wenn sie ausgehende Anfragen stellt.

Hetzner-Realität: Hetzner hat kein verwaltetes NAT-Gateway. Server können ohne öffentliche IP-Adressen erstellt und in einem privaten Cloud-Netzwerk platziert werden. Ein Server mit ausschließlich privatem Zugang hat jedoch standardmäßig keinen ausgehenden Internetzugang. Um einen ausgehenden Internetzugang für einen solchen Server zu ermöglichen, muss entweder eine öffentliche IPv4-Adresse zugewiesen oder ein eigenes NAT-Setup mit einem separaten Server mit öffentlicher IPv4-Adresse aufgebaut werden, der den Traffic für die dahinterliegenden privaten Server routet. Dafür ist die Konfiguration von IP-Forwarding und IPTables-MASQUERADE-Regeln erforderlich. Die meisten Teams, die neu bei Hetzner sind, überspringen die NAT-Architektur und weisen stattdessen öffentliche IP-Adressen zu.

Die monatlichen Kosten für eine öffentliche IP-Adresse betragen 0,50 €. Die Sicherheitsimplikationen sind weniger offensichtlich: Ein Hetzner-Server mit öffentlicher IP hat alle Ports für das Internet offen, sofern keine Cloud-Firewall zugewiesen ist. Cloud-Firewalls sind Opt-in-Lösungen und werden beim Erstellen eines Servers nicht standardmäßig angewendet.

Ein Server ohne Firewall – oder einer, bei dem eine Container-Runtime die Host-Level-Firewall-Regeln umgeht, indem sie direkt in iptables schreibt – kann kompromittiert werden, ohne dass der Betreiber es bemerkt. Der Server kann dann als Teil eines Botnets genutzt werden. Dies würde lediglich als Traffic-Überschreitung auf der Rechnung auftauchen. EU-Cloud-Server umfassen 20 TB ausgehenden Traffic pro Monat. Überschreitungen werden mit 1 € pro TB und Server berechnet. Kürzlich generierte ein CX32-Server, der für persönliche Projekte genutzt wurde, eine Rechnung über 188 Euro für 176 Terabyte ausgehenden Traffic über einen einzigen Monat – 560 Megabit pro Sekunde dauerhaft für 30 Tage – vollständig durch einen kompromittierten Server. Hetzner verschickte Warn-E-Mails, als der Server 75 % und 100 % des enthaltenen Traffic-Kontingents erreichte. Sie blieben ungelesen.

Zum Vergleich: 176 TB von AWS ins Internet kosten bei Standardpreisen ca. 12.050 $. Hetzners TB-Preis ist günstig, ein ungesicherter, inaktiver Server jedoch nicht.

Das korrekte Setup für einen Server mit öffentlicher IP besteht darin, beim Erstellen des Servers eine Cloud-Firewall zuzuweisen, die nur die tatsächlich benötigten Ports zulässt und den SSH-Zugang auf bekannte IP-Bereiche beschränkt. Für Architekturen, in denen Anwendungsserver nicht direkt aus dem Internet erreichbar sein sollen, ist das übliche Vorgehen die Verwendung von Servern in einem reinen privaten Netzwerk ohne öffentliche IP-Adresse. Benötigen diese Server ausgehenden Internetzugang, sollte dieser über einen dedizierten Egress-Host geroutet werden – ein Server mit öffentlicher IP, der für NAT konfiguriert ist. Der Admin-SSH-Zugang erfolgt über einen separaten Bastion-Host mit ProxyJump. In kleinen Umgebungen können Egress-Host und Bastion-Host dieselbe VM sein. Besser ist jedoch eine Trennung: Der Bastion-Host sollte minimal und gehärtet gehalten werden, ohne zusätzliche Routing-Verantwortlichkeiten. Hetzners Tutorial How to set up NAT gateway for private Cloud Networks behandelt das NAT-Setup vollständig.

hcloud server list gegen hcloud firewall list zeigt, welche Server öffentliche IPs haben und denen keine Firewall zugewiesen ist.

Was damit zu tun ist

Keines dieser Abrechnungsverhalten ist versteckt. Hetzner dokumentiert sie alle. Die Überraschung entsteht durch die Diskrepanz zu Gewohnheiten, die auf anderen Plattformen aufgebaut wurden – eine Lücke, die sich umso mehr vergrößert, je mehr AWS-, Azure- oder GCP-Infrastruktur betrieben wurde.

Die grundlegende Gewohnheit ist ein Existenz-Audit, kein Nutzungs-Review. Was ist im Projekt vorhanden, das nicht bewusst beibehalten wurde? Ausgeschaltete Server, nicht zugewiesene IPs, verwaiste Volumes, veraltete Snapshots — keiner davon meldet sich von selbst. hcloud server list, hcloud volume list, hcloud primary-ip list und hcloud snapshot list auszuführen dauert zwei Minuten. Die Entscheidung, was behalten werden soll, ist meistens schneller getroffen.

Es lohnt sich, als Team-Standards zwei Einstellungen festzulegen, bevor die Infrastruktur wächst: Automatische Backups sollten für Nicht-Produktions-Server deaktiviert werden (aber explizit für Datenbanken und zustandsbehaftete Workloads aktiviert) und Cloud-Firewalls sollten bei der Erstellung mit einem minimalen Regelwerk zugewiesen werden. Beides ist als Richtlinie nicht schwer umzusetzen, aber schwer nachträglich auf eine bestehende Flotte anzuwenden.

Diese Muster sind einzeln betrachtet geringfügig. Werden sie jedoch in einem Team, das aktiv Infrastruktur bereitstellt und skaliert, nicht angegangen, können sie erhebliche Auswirkungen haben. CloudTally schlüsselt Hetzner-Ausgaben nach Ressourcentyp auf, beispielsweise inaktive Server, verwaiste IPs, Snapshot-Anhäufung und abgekoppelte Volumes, sodass diese Muster vor der Rechnung sichtbar werden und nicht erst danach.

Dieser Artikel wurde maschinell übersetzt.