Hetzner-Abrechnungsfallen für AWS-, Azure- und GCP-Teams

Ein Wechsel zu Hetzner ist meist eine positive Überraschung, denn beim Preis-Leistungs-Verhältnis ist Hetzner schwer zu schlagen. Die Abrechnungsüberraschungen kommen oft erst später, wenn Gewohnheiten aus AWS, Azure oder GCP zu Ergebnissen führen, die nicht zu den eigenen Erwartungen passen.

Bei AWS folgen die Kosten in der Regel der Aktivität: Wer eine EC2-Instanz stoppt, stoppt damit auch die Compute-Kosten. 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 gerade irgendeinen Nutzen stiftet.

Das ist kein Konstruktionsfehler. Dahinter steht eine bewusste Infrastrukturphilosophie: Wenn eine Ressource erstellt wird, reserviert Hetzner dafür reale Hardware. Diese Reservierung bleibt bestehen, bis sie explizit freigegeben wird. Wer diesen Unterschied versteht, kann Hetzner-Rechnungen deutlich besser einschätzen. Nach der Preisanpassung vom 1. April 2026 kosten all diese Muster spürbar mehr als noch im ersten Quartal.

Ausgeschaltete Server kosten weiter den vollen Serverpreis

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.

In 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 sieht so aus: Ein Entwicklungsteam in Nürnberg oder Helsinki erstellt vor einem riskanten Deployment einen Snapshot, schaltet den Server für einen Sprint „vorübergehend” 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 sie nirgends hängen

Seit Februar 2024 berechnet Hetzner primäre IPv4-Adressen unabhängig vom jeweiligen Server. Jede primäre IPv4-Adresse kostet rund 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 später 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 nicht zugewiesene IP-Adressen unbemerkt ansammeln, 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 damit, alle öffentlichen IPv4-Adressen zu berechnen (0,005 $ pro Stunde bzw. ca. 3,65 $ pro Monat), sodass die Abrechnung unabhängig von der Zuweisung kein reines Hetzner-Thema mehr ist. Das Fehlermuster sieht aber anders aus: Eine als Hochverfügbarkeits-Failover reservierte Floating IP, die nie tatsächlich genutzt wird, kostet 36 € pro Jahr.

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

Backups kosten 20 % des Serverpreises, egal wie voll die Festplatte ist

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, verursacht damit 3,20 € zusätzliche Backup-Kosten - 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 trifft vor allem Teams, die Backups aus Prinzip auf allen Servern aktivieren. Eine Flotte von zehn CCX13-Entwicklungsservern verursacht damit Compute-Kosten von 159,90 € pro Monat und zusätzlich 31,98 € pro Monat für Backups, obwohl solche Umgebungen in der Regel keine nächtlichen Backups brauchen.

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

Snapshots erfassen den vollständigen Festplattenzustand, nicht nur die Änderungen seit dem letzten Stand

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. Das wirkt zunächst überschaubar, aber bei drei Monaten Deployment-Snapshots ohne Aufbewahrungsrichtlinie sieht es anders aus: Zehn Snapshots à 0,65 € kosten 6,50 € pro Monat für Festplattenabbilder, die mit hoher Wahrscheinlichkeit keinen nützlichen Zeitpunkt mehr abbilden.

Die praktische Regel lautet: Snapshots gezielt erstellen und nach einem festen Zeitplan löschen. Anders als bei AWS gibt es keine inkrementelle Kosteneinsparung durch ältere oder „ruhige“ Snapshots. Jeder Snapshot wird für sich berechnet.

Cloud-Server lassen sich nicht auf eine kleinere Größe als die ursprünglich provisionierte zurückskalieren

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 Größe der Boot-Festplatte ist bei all diesen Anbietern vollständig vom Compute-Tier entkoppelt.

Hetzner-Realität: CPU- und RAM-Rescaling 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ückskaliert werden, weil die Festplatte jetzt zu groß ist. Es gibt dafür 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 bereits 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 über Robot haben eine einmalige Einrichtungsgebühr

Hetzner hat zwei getrennte Bestellsysteme mit unterschiedlichen Eigenschaften: die Cloud Console (console.hetzner.cloud) und Robot (robot.hetzner.com). Cloud-Server haben keine Einrichtungsgebühr, sondern werden ab dem Moment der Provisionierung stündlich 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 zusätzlich eine einmalige Einrichtungsgebühr, die zum Zeitpunkt der Provisionierung berechnet wird. Diese Gebühr erscheint auf der ersten Rechnung, bevor nennenswerte 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 hingegen dediziert für den Kunden reserviert und nach dessen Vorgaben konfiguriert. Die einmaligen Provisionierungskosten fallen also 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 verschärft die Situation zusätzlich. Die Gebühren für Robot-Dedicated-Server erscheinen nicht in der Nutzungsvorschau der Hetzner Cloud Console, da diese ausschließlich Cloud-Ressourcen abdeckt. Die eigentliche Rechnung wird erst am zugewiesenen Abrechnungsdatum verschickt, das mitten im Folgemonat liegen kann. Ein Team, das mehrere Erstell- und Terminier-Zyklen durchläuft, bekommt in der Konsole also keinen Hinweis auf die sich ansammelnden Einrichtungsgebühren - bis die Rechnung eintrifft.

Es gibt zwei Möglichkeiten, das Risiko durch Einrichtungsgebühren zu senken. 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 passen möglicherweise nicht genau zu Ihren Anforderungen. Zweitens umfassen alle über Robot provisionierten Dedicated Server unbegrenztes Traffic-Volumen auf einem 1-Gbit-Uplink - ein deutlicher 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 direkt 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 das 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 müssen IP-Forwarding und IPTables-MASQUERADE-Regeln konfiguriert werden. Die meisten Teams, die neu bei Hetzner sind, überspringen diese NAT-Architektur und weisen stattdessen öffentliche IP-Adressen zu.

Die monatlichen Kosten für eine öffentliche IP-Adresse betragen 0,50 €. Weniger offensichtlich sind die Sicherheitsfolgen: Ein Hetzner-Server mit öffentlicher IP hat alle Ports zum Internet offen, sofern keine Cloud-Firewall zugewiesen ist. Cloud-Firewalls sind Opt-in 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 richtige Setup für einen Server mit öffentlicher IP besteht darin, ihm bereits beim Erstellen 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 Muster ein reines privates Netzwerk ohne öffentliche IP-Adresse. Benötigen diese Server ausgehenden Internetzugang, sollte dieser über einen dedizierten Egress-Host geroutet werden - also einen Server mit öffentlicher IP, der für NAT konfiguriert ist. Der Admin-SSH-Zugang erfolgt über einen separaten Bastion-Host mit ProxyJump.

ProxyJump-Bastion für Admin-Zugriff, separates NAT für ausgehenden Traffic

In kleinen Umgebungen können Egress-Host und Bastion-Host dieselbe VM sein. Besser ist jedoch eine Trennung: Der Bastion-Host sollte möglichst minimal und gehärtet bleiben, ohne zusätzliche Routing-Verantwortung. 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 Lücke zwischen diesen Regeln und Gewohnheiten, die auf anderen Plattformen entstanden sind - und sie wird umso größer, je mehr AWS-, Azure- oder GCP-Infrastruktur ein Team gewohnt ist.

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 - keines 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 noch schneller getroffen.

Es lohnt sich, zwei Dinge als Team-Standard 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 bleiben), und Cloud-Firewalls sollten bei der Erstellung mit einem minimalen Regelwerk zugewiesen werden. Beides ist als Richtlinie nicht schwer umzusetzen, aber später nur mühsam auf eine bestehende Flotte nachzuziehen.

Diese Muster wirken einzeln betrachtet klein. Wenn sie in einem Team, das aktiv Infrastruktur bereitstellt und skaliert, jedoch nicht angegangen werden, können sie sich spürbar summieren. CloudTally schlüsselt Hetzner-Ausgaben nach Ressourcentyp auf, etwa inaktive Server, verwaiste IPs, Snapshot-Anhäufungen und abgekoppelte Volumes, sodass diese Muster vor der Rechnung sichtbar werden und nicht erst danach.

Dieser Artikel wurde maschinell übersetzt.