Warum Hetzner für ausgeschaltete Server abrechnet

Hetzner rechnet ausgeschaltete Cloud-Server ab, weil die zugrunde liegende Hardware-Kapazität weiterhin exklusiv für Sie reserviert bleibt, bis der Server gelöscht wird. Auch im ausgeschalteten Zustand lassen sich die zugewiesenen CPU-Kerne, der Arbeitsspeicher und der NVMe-Speicher nicht an andere Kunden weitervergeben - die Abrechnung läuft daher zum vollen Tarif weiter, bis die Instanz gelöscht ist. Bei AWS, GCP und Azure ist es genau umgekehrt: Wird eine VM gestoppt, wird die Compute-Kapazität in den regionalen Pool zurückgegeben.

Beim ersten Mal wirkt es wie ein Abrechnungsfehler. Sie fahren vor dem Urlaub einen Hetzner-Cloud-Server herunter, und wenn Sie zwei Wochen später zurückkehren, weist die Rechnung den vollen Monatspreis aus, als wäre die Maschine die gesamte Zeit gelaufen. Sie lief aber nicht. Hetzner hat sie Ihnen trotzdem in Rechnung gestellt.

Der erste Impuls - besonders bei Teams mit AWS-, GCP- oder Azure-Erfahrung - ist oft: Das System hat den Serverstatus falsch erkannt. Das ist nicht der Fall. Hetzner berechnet ausgeschaltete Server bewusst zum vollen Preis, und das ist eine strukturelle Entscheidung, kein UX-Versehen und kein fehlendes Feature. Es ist sinnvoller zu verstehen, warum das so ist, als sich darüber zu ärgern, denn diese Regelung hängt unmittelbar damit zusammen, wie Hetzner seine Preise überhaupt so niedrig halten kann.

Was Hetzner tatsächlich sagt

Hetzners Abrechnungs-FAQ ist an diesem Punkt eindeutig:

Sobald der Erstellungsprozess eines Servers abgeschlossen wurde, wird dieser unabhängig vom Status solange in Rechnung gestellt, bis Sie ihn löschen.

Die FAQ erklärt weiter, dass Hetzner einem Server unabhängig von dessen Betriebszustand die vollen Ressourcen zuweist. Dadurch lässt er sich später schnell wieder starten. Daraus folgen zwei Dinge. Erstens lässt sich die Abrechnung nur durch das Löschen des Servers beenden - nicht durch Stoppen, Herunterfahren oder Trennen. Zweitens sind die dem Server zugewiesenen CPU-Kerne, der Arbeitsspeicher und der Festplattenspeicher physisch auf einem bestimmten Host in einem bestimmten Rechenzentrum reserviert, bis sie freigegeben werden.

Das ist das Gegenteil des AWS-Modells. Bei EC2 fällt der Compute-Preis auf null, sobald eine Instanz gestoppt wird; Sie zahlen dann nur noch für das zugrunde liegende EBS-Volume (siehe AWS EC2 Lifecycle Docs). Instanztyp, Security Groups und Metadaten bleiben erhalten, die physische Kapazität wird jedoch in den regionalen Pool zurückgegeben. Beim erneuten Starten platziert AWS die Instanz auf einem beliebigen Host, der freie Kapazität hat. Dasselbe gilt für GCP und Azure.

Hetzner macht das nicht. Die Kapazität bleibt Ihrem Server zugewiesen, bis Sie ihn löschen.

Warum Hetzner ausgeschaltete Server berechnet

Die Entscheidung zwischen „Kapazität beim Stoppen freigeben" und „Kapazität bis zum Löschen halten" ist keine Willkür - sie bestimmt, wie ein Cloud-Anbieter seine Kapazitäten planen und vorhalten muss.

Wären ausgeschaltete Server kostenlos, stünde Hetzner vor zwei unattraktiven Optionen. Die erste Option wäre, die zugrunde liegende Kapazität im selben Rechenzentrum und auf einem Host reserviert zu halten, der denselben VM-Typ starten kann. Diese Kapazität könnte nicht an andere Kunden verkauft werden. Hetzner würde für Hardware, Strom, Kühlung und Rack-Platz zahlen, die keinen Umsatz bringen. Diese Kosten müssten in den Preis jedes anderen Servers der Flotte einkalkuliert werden. Die zweite Option wäre, die Kapazität freizugeben und zu überbuchen. Beim nächsten Klick auf „Start" müsste Hetzner sofort Platz für die VM finden. Manchmal wäre kein Platz verfügbar, und der Start würde mit einem Kapazitätsfehler fehlschlagen. Mit gutem Grund wäre der Kunde in so einem Fall verärgert. Das würde Hetzners Ruf als günstiger, aber zuverlässiger Cloud-Anbieter beschädigen.

Bei kostenlos ausgeschalteten Servern würde dieselbe Hardware weniger zahlende Slots tragen.

Beide Ergebnisse sind für nahezu jede Kundengruppe schlechter als die aktuelle Regelung. Die aktuelle Regel macht den Tausch klar: Wer reservierte Kapazität behalten will, zahlt dafür. Wer sie nicht mehr braucht, löscht den Server und gibt den Slot frei. Damit liegt die Entscheidung bei dem Team, das am besten weiß, ob der Server noch gebraucht wird, und Hetzner kann die Flotte voll ausgelastet und mit möglichst wenig Leerkapazität betreiben. Das ist einer der Gründe, warum ein CCX13 in Falkenstein nur einen Bruchteil dessen kostet, was eine vergleichbare dedizierte vCPU-Instanz bei AWS oder Azure kostet.

Hetzners Produktlinie zeigt das deutlich

Wer daran zweifelt, dass Hetzner auf hohe Auslastung angewiesen ist, sollte sich die Cost-Optimized-Linie ansehen. Die CX-Serie (CX23, CX33, CX43 und CX53), die Ende 2025 zur Ablösung der älteren CX11-Generation eingeführt wurde, ist Hetzners günstigste Stufe. Sie besteht aus einfachen Shared-vCPU-Instanzen, die auf Testumgebungen, Blogs und Projekte mit wenig Traffic zugeschnitten sind. Die Produktseite selbst beschreibt den Kompromiss unverblümt: „Durch diese ressourcenschonende Nutzung ist die Anzahl der verfügbaren Server allerdings begrenzt." (hetzner.com/de/cloud/cost-optimized).

In der Praxis zeigt die Hetzner Cloud Console gelegentlich den Hinweis „Limited availability" bei Cost-Optimized-Servertypen an, und die Erstellung kann fehlschlagen, wenn der Kapazitätspool an einem Standort erschöpft ist. CX- und CAX-Instanzen sind zudem nur in EU-Regionen (Falkenstein, Nürnberg und Helsinki) verfügbar und werden in Ashburn, Hillsboro oder Singapur nicht angeboten - dort gibt es nur die teureren CPX- und CCX-Linien. Diese günstige Stufe existiert gerade deshalb, weil Hetzner sie nicht überbucht.

Hetzner Cloud Console - Formular zur Servererstellung: Die Kategorie Cost-Optimized zeigt ein „Limited availability“-Kennzeichen, während Regular Performance und General Purpose dies nicht tun — Hetzner Cloud Console - Cost-Optimized ist die einzige Serverfamilie mit dem Vermerk „Limited availability“. Dedizierte CPX-/CCX-Instanzen und Arm-basierte CAX-Instanzen tragen diesen Hinweis nicht.

Bei anderen Anbietern ist das selten. AWS, GCP und Azure zeigen in Hauptregionen für Standard-Instanztypen nur selten Kapazitätsfehler an, weil sie aggressiv überbuchen und die Kosten für die Vorhaltung von Ersatzhardware selbst tragen. Die verfügbare Reservekapazität bei AWS ist nicht kostenlos - sie ist im Stundenpreis enthalten. Hetzners Stundenpreis enthält das nicht, und das Abrechnungsmodell für ausgeschaltete Server ist die sichtbare Folge davon.

Warum das viele Teams überrascht

Die Regelung selbst ist unmissverständlich, aber einige gängige Arbeitsabläufe unterstellen das AWS-Modell und können bei Hetzner zu vermeidbaren Rechnungen führen.

Das „wir pausieren ihn für den Sprint"-Muster. Ein Team erstellt vor einer riskanten Migration einen Snapshot eines Entwicklungsservers, fährt die Maschine herunter und will in einer Woche zurückkehren. Rutscht die Arbeit nach hinten und gerät der Server in Vergessenheit, hat der CCX13 in Falkenstein sechs Wochen später rund 22 € an Kosten angehäuft (zum Preis nach April 2026 von 15,99 € pro Monat) - für nichts. Über eine gesamte Flotte hinweg ist das die größte einzelne Quelle von Cloud-Server-Verschwendung, die wir bei Hetzner beobachten. Die Lösung besteht nicht darin, den Server zu stoppen, sondern darin, einen Snapshot zu erstellen und anschließend den Server selbst zu löschen. Der Snapshot speichert das Festplatten-Image für 0,0143 €/GB/Monat - typischerweise ein Bruchteil des Serverpreises.

Das „über Nacht stoppen"-Sparschema aus AWS. Teams oder Entwicklerinnen und Entwickler, die den AWS Instance Scheduler genutzt haben, versuchen oft denselben Trick bei Hetzner: Entwicklungsserver um 18:00 Uhr stoppen und um 08:00 Uhr wieder starten, in der Erwartung, etwa ein Drittel des Monatspreises zu zahlen. Bei Hetzner spart das jedoch nichts. Das einzige wirklich vergleichbare Vorgehen besteht darin, den Server zu löschen und später aus einem Snapshot neu zu erstellen. Das ist für zustandslose Entwicklungsumgebungen machbar, bringt aber genug operativen Aufwand mit sich, dass die meisten Teams zu dem Schluss kommen, dass 5-20 € pro Server und Monat es nicht wert sind.

Das „für eine ruhige Phase herunterskalieren"-Muster. Ein Team skaliert einen CCX23 für einen Launch auf einen CCX33 hoch und plant, einige Wochen später wieder herunterzuskalieren. Zwischendurch wird der Server ausgeschaltet, um „in der ruhigen Phase etwas Geld zu sparen". Das Verkleinern wird dann jedoch blockiert, weil Hetzner kein Rescaling auf eine kleinere Festplatte erlaubt, unabhängig davon, wie voll diese tatsächlich ist. Folglich wird der ausgeschaltete Monat durchgehend zum CCX33-Tarif abgerechnet. Besser wäre gewesen, von Anfang an die Hetzner-Option „nur CPU und RAM" beim Rescaling zu nutzen, denn so wäre die ursprüngliche Festplattengröße und damit der Weg zum Downgrade erhalten geblieben.

Der zugrunde liegende Fehler ist in allen Fällen derselbe: ein zustandsbasiertes Denkmodell (gestoppt = günstig) auf ein System anzuwenden, das nicht nach Nutzung, sondern nach bloßem Vorhandensein abrechnet. Weitere Muster, in denen AWS-Gewohnheiten zu unerwarteten Hetzner-Rechnungen führen, beschreibt der Beitrag Hetzner-Abrechnungsfallen.

Ein einfacher Entscheidungsrahmen

Wenn Sie im Begriff sind, einen Hetzner-Cloud-Server herunterzufahren, gehen Sie die folgenden Fragen durch:

Wird der Server in den nächsten 24 Stunden wieder gebraucht? Dann lassen Sie ihn laufen. Stoppen kostet genauso viel wie Laufenlassen, und Sie ersparen sich die Bootzeit beim Zurückkehren.
Wird er innerhalb der nächsten zwei Wochen gebraucht? Erstellen Sie einen Snapshot, löschen Sie den Server und erstellen Sie ihn bei Bedarf aus dem Snapshot neu. Die Rechnung für einen CCX13 in Falkenstein sieht so aus: Laufenlassen kostet 15,99 € pro Monat; der Snapshot kostet rund 0,50-1,50 € pro Monat für eine typische 40-100-GB-Festplatte. Selbst wenn Sie den Server zweimal pro Woche neu aufsetzen, sparen Sie Geld.
Wird er überhaupt noch gebraucht? Erstellen Sie einen Snapshot, falls Sie die Daten vielleicht noch brauchen, und löschen Sie danach den Server. Snapshots sind laut Hetzners Snapshot-FAQ nicht ortsgebunden und lassen sich in jede Region derselben Architektur wiederherstellen (x86 zu x86, Arm64 zu Arm64) - Sie legen sich also nicht auf ein bestimmtes Rechenzentrum fest.
Handelt es sich um eine zustandsbehaftete Datenbank oder einen Server, den Sie sich nicht leisten können zu verlieren? Ein Snapshot mit anschließendem Löschen ist riskant, wenn Sie den exakten Festplattenzustand inklusive laufender Prozesse benötigen. Dann ist die ehrliche Antwort, den Server laufen zu lassen - und die Rechnung für diese betriebliche Entscheidung zu zahlen.

Wenn Sie einen Server behalten möchten, aber nicht weiter dafür zahlen wollen, lautet der sinnvolle Ablauf nicht „Stoppen und vergessen". Er lautet: sauberes Herunterfahren, Snapshot, Löschen und bei Bedarf später aus dem Snapshot wiederherstellen.

Genau diese leicht zu übersehenden Details erklären, warum der Ablauf aus fünf Schritten besteht. Ein ausgeschalteter Server wird weiterhin zum vollen Serverpreis berechnet, das „Herunterfahren" ist also nur ein kurzer Vorbereitungsschritt, kein Sparzustand. Und nachdem der Snapshot erstellt wurde, gibt es kurz eine Phase, in der Sie für beides zahlen, bis der Server gelöscht ist. Die Ersparnis beginnt erst mit dem Löschen.

Der Kostenabfall passiert beim Löschen, nicht beim Herunterfahren.

Kurz gesagt: Einen Hetzner-Server zu stoppen ist wirtschaftlich keine sinnvolle Lösung. Ein Snapshot mit anschließendem Löschen schon.

→ Siehe auch: Der Hetzner-Ressourcen-Audit-Leitfaden

Das Fazit

Diese Abrechnungsregel ist kein Fehler, den man umgehen müsste. Sie ist Teil des klaren Tauschgeschäfts, das Sie eingehen, wenn Sie sich für Hetzner statt für AWS oder GCP entscheiden. Die Hyperscaler bündeln die Kosten der Hot-Reserve-Kapazität in jeden Stundenpreis - egal, ob Sie sie nutzen oder nicht. Hetzner entbündelt sie und überlässt Ihnen die Entscheidung: Behalten, was Sie brauchen, löschen, was Sie nicht brauchen - und der Preis bleibt, wo er ist.

Wer das Löschen nicht als einschneidenden Ausnahmefall, sondern als normalen Betriebsablauf versteht, nutzt diesen Vorteil konsequent aus. CloudTally zeigt, wo genau das nicht passiert - bei ausgeschalteten Servern, verwaisten IPs und vergessenen Snapshots - damit sich dieser Vorteil auch tatsächlich auf der Rechnung bemerkbar macht.

Dieser Artikel wurde maschinell übersetzt.