Warum Ihre Hetzner-Rechnung höher ausfällt als erwartet

Preishinweis. Alle nachstehenden Euro-Beträge verstehen sich zzgl. MwSt. und basieren auf den Hetzner-Preisen mit Gültigkeit ab dem 1. April 2026.

Sie haben die Rechnung geöffnet und festgestellt, dass der Gesamtbetrag höher ausfällt, als er sollte. Nichts Wesentliches hat sich geändert. Keine neuen Dienste sind live gegangen. Kein Projekt hat seine Größe verdoppelt. Und trotzdem stimmt die Zahl nicht – manchmal um wenige Euro, manchmal um einige hundert.

Sie bilden sich das nicht ein, und es ist höchst unwahrscheinlich, dass Sie es mit einem Abrechnungsfehler zu tun haben. Hetzners Abrechnung ist ziemlich geradlinig: stündlich, anteilig und nach veröffentlichter Preisliste. Die Rechnung entspricht in der Regel den Ressourcen im Konto. Meist driften eher Ihre Erwartungen und der tatsächliche Ressourcenzustand auseinander, oft in kleinen Schritten, die sich summieren: ein paar übersehene Positionen, einige Abrechnungsregeln, die sich von AWS oder Azure unterscheiden, und ein oder zwei Stellen außerhalb der Cloud Console, an denen sich Gebühren unbemerkt ansammeln.

Dieser Leitfaden ist als Diagnosewerkzeug gedacht. Beginnen Sie mit der kurzen Liste der wichtigsten Ursachen unten, überfliegen Sie anschließend die Kategorien und bleiben Sie bei denen hängen, die auf Ihren Fall zutreffen. Der letzte Abschnitt ist ein zehnminütiger Abgleich, den Sie direkt mit der Rechnung vor sich durchführen können.

Diese Punkte zuerst prüfen

Wer die Kurzversion möchte, ordnet sein Symptom einer Zeile zu und beginnt dort.

Passt keines dieser Symptome, decken die folgenden Kategorien den Rest ab.

1. Vergessene oder verwaiste Ressourcen

Das ist die größte Kategorie unerwarteter Gebühren. Nichts Dramatisches – nur Ressourcen, die weiter existieren, obwohl der Anlass dafür längst weggefallen ist.

Ausgeschaltete Server werden weiterhin zum vollen Preis berechnet

Einen Hetzner-Server auszuschalten ändert nichts an der Rechnung. Der Stundensatz läuft weiter, bis der Server gelöscht wird, sodass ein CCX13 zu 15,99 €/Monat im ausgeschalteten Zustand genauso viel kostet wie unter Produktionslast. Das ist mit Abstand der häufigste Grund dafür, dass die monatliche Grundlast unbemerkt höher liegt, als sie sein sollte – besonders bei Teams, die von AWS migrieren.

Prüfen: hcloud server list ausführen und nach Status off suchen. Mit den Workloads abgleichen, die laufen sollten.

Beheben: Falls Sie die Festplatte später noch benötigen könnten, einen Snapshot erstellen (~0,57 €/Monat für ein komprimiertes 40-GB-Image) und den Server löschen. Ein Snapshot erhält diese Option für 3–5 % der laufenden Kosten.

Abgekoppelte Volumes aus alten Experimenten

Volumes überleben den Server, an den sie angebunden waren. Das macht sie bei Migrationen und Neuaufbauten nützlich, sorgt aber auch dafür, dass sie danach leicht in Vergessenheit geraten. Zu 0,0572 €/GB/Monat kostet ein abgekoppeltes 100-GB-Volume 5,72 €/Monat, und fünf davon aus aufgegebenen Datenbank-Experimenten und alten Importen schlagen dauerhaft mit 28,60 €/Monat zu Buche.

Prüfen: hcloud volume list ausführen und nach einer leeren SERVER-Spalte Ausschau halten.

Beheben: Alles Aufbewahrungswürdige in Object Storage kopieren (günstiger für selten genutzte Daten) und das Volume löschen.

Snapshot-Sammlungen, die niemand bereinigt

Hetzner-Snapshots sind vollständige, komprimierte Abbilder ohne inkrementelle Speicherung, Deduplizierung oder automatische Aufbewahrungsregeln. Jeder Snapshot, der vor einem Deploy, einer Schemaänderung oder einem Resize erstellt wurde, bleibt zu 0,0143 €/GB/Monat auf der Rechnung, bis ihn jemand löscht. Zwanzig komprimierte 40-GB-Abbilder ergeben rund 11,44 €/Monat und werden Monat für Monat mehr, wenn niemand aufräumt.

Prüfen: hcloud image list --type snapshot zeigt jeden Snapshot mit Größe und Alter.

Beheben: Alles löschen, was älter ist als Ihr tatsächliches Rollback-Fenster (in der Regel 30–90 Tage); dokumentieren, warum ältere Snapshots erhalten bleiben.

2. Abrechnungsregeln, die nicht zu AWS- oder Azure-Gewohnheiten passen

Manche Rechnungsüberraschungen haben nichts mit vergessenen Ressourcen zu tun. Es sind korrekte Gebühren, die Regeln folgen, die viele aus AWS oder Azure so nicht gewohnt sind.

Backups kosten pauschal 20 % des Serverpreises

Hetzner berechnet automatische Backups als monatlichen Aufschlag in Höhe von 20 % des Serverpreises – nicht pro GB wie AWS oder Azure. Für zustandsbehaftete Produktionssysteme ist das vertretbar. Wenn Backups jedoch flottenweit standardmäßig aktiviert sind, ergibt das einen 20-%-Aufschlag auf CI-Runner, Staging und ephemere Worker, bei denen Backups kaum Nutzen bringen. Ein CCX13 kostet dadurch 3,20 €/Monat mehr; ein CCX33 12,50 €/Monat.

Prüfen: Server mit aktivierten Backups zeigen ein Backup-Symbol in der Console, und die Rechnung weist Backups auf einer eigenen Position aus.

Beheben: Backups dort deaktivieren, wo sich alles aus Code oder vorgelagerten Daten neu aufbauen lässt. Aktiviert lassen bei Systemen, deren Zustand aufwendig wiederherzustellen ist.

Inkludierter Traffic hängt am einzelnen Server, nicht an der Flotte

Das Traffic-Freikontingent wird pro Server gewährt. Das bedeutet: Ein einzelner trafficstarker Knoten kann eine Überschreitung erzeugen, obwohl der Rest der Flotte deutlich unter dem jeweiligen Freikontingent bleibt. Das ist eine häufige Überraschung, wenn ein Server Downloads, API-Traffic oder Medienauslieferung abwickelt, während ruhigere Knoten ihr Kontingent kaum ausschöpfen.

Prüfen: Ausgehenden Traffic pro Server vergleichen und auf einen einzelnen Hotspot achten, statt anzunehmen, dass das ungenutzte Flotten-Freikontingent ihn ausgleicht.

Beheben: Starken Egress auf dafür vorgesehene Infrastruktur verlagern oder das Routing so ändern, dass die trafficlastige Rolle gezielter abgedeckt wird.

3. Rightsizing-Drift

Selten ein dramatischer Ausschlag. Häufiger ist sie der Grund, warum die Rechnung über Monate langsam nach oben driftet und dort dann bleibt.

Dedizierte vCPU, wo geteilte ausreichen würden

CCX (dedizierte vCPU) ist bei vergleichbarer Ausstattung deutlich teurer als CPX (geteiltes x86) oder CAX (geteiltes Arm). Ein CCX13 kostet 15,99 €/Monat; ein CPX11 5,99 €; ein CAX11 4,49 €. Teams standardisieren für die Produktion häufig auf CCX, was auch sinnvoll ist, ziehen diese Vorgabe dann aber oft auf Staging, CI, interne Tools und Worker mit geringem Lastprofil durch, obwohl dort die Garantie dedizierter CPU-Kapazität gar nicht gebraucht wird.

Prüfen: Server-Typen in hcloud server list ansehen und fragen, welche produktionskritisch sind. Der Rest sind Kandidaten für CPX oder CAX.

Beheben: Nicht-kritische Workloads auf CAX verlagern, sofern der Stack Arm-kompatibel ist, andernfalls auf CPX. CCX für Dienste reservieren, die tatsächlich stabile CPU-Leistung benötigen.

Für den Backfill dimensioniert, für den Dauerbetrieb beibehalten

Ein Server, der für einen einmaligen Import, eine Migration oder einen Reindex bereitgestellt wurde, bleibt oft unverändert für den deutlich kleineren Dauerbetrieb bestehen. Der Backfill hatte das 10- bis 100-Fache des Normalbetriebs, aber der Typ wurde nie überprüft, weil der laufende Job schnell fertig wird und nichts offensichtlich falsch wirkt. Die Auslastung fällt auf 5–10 %, während der Server weiterhin in der vollen Kategorie abgerechnet wird.

Prüfen: Die Spitzenlast des Servers während des ursprünglichen Imports mit der aktuellen Auslastung vergleichen – die meisten Monitoring-Tools zeigen den Rückgang deutlich.

Beheben: Auf eine Kategorie verkleinern, die zum Dauerbetrieb passt. Für geplante Jobs erwägen, auf kurzlebige, bedarfsweise bereitgestellte Worker umzustellen.

Für einen Vorfall vergrößert, nie wieder verkleinert

Ein Hochskalieren, um eine Launch-Spitze, einen DDoS oder ein anderes Lastproblem zu überstehen, wird häufig dauerhaft, sobald das Ereignis vorbei ist. Ein CCX33 statt eines CCX23 bedeutet rund 30 €/Monat zusätzlich – ein Jahr lang belassen sind das 360 € pro Server, und die meisten Flotten tragen ein oder zwei solcher Fälle mit sich herum. Was das bei Hetzner besonders hartnäckig macht: Festplatten lassen sich vergrößern, aber nicht verkleinern. Wenn der Resize auch die Disk vergrößert hat, führt der einzige Weg zurück über eine manuelle Migration. Die Rescale-Option „Nur CPU und RAM“ erhält den Downgrade-Pfad, ist in der UI aber leicht zu übersehen.

Prüfen: hcloud server list -o columns=id,name,type,primary_disk_size zeigt aktuelle Kategorien und Festplattengrößen; mit dem tatsächlichen Bedarf des Workloads und der Resize-Historie rund um vergangene Vorfälle abgleichen.

Beheben: Beim Hochskalieren für ein bekanntes, einmaliges Ereignis „Nur CPU und RAM“ wählen, damit die Festplatte auf der kleineren Kategorie bleibt. Wer bereits auf einer größeren Disk festsitzt, sollte die Migration explizit einplanen – von allein geschieht sie nicht.

4. Autoscaling und Automatisierung

Autoscaler, CI-Systeme und Batch-Worker fahren Infrastruktur hoch, wenn niemand hinsieht. Meist funktioniert das unauffällig. Wenn es schiefläuft, fällt es oft erst spät auf.

Autoscaler-Minimum nach einem Vorfall erhöht, nie wieder gesenkt

Während einer Spitze oder eines DDoS hebt jemand die minimale Instanzzahl des Clusters an, um das System zu stabilisieren. Der Vorfall vergeht; die Untergrenze bleibt. Der Cluster hält dauerhaft zusätzliche Kapazität vor, weil diese Untergrenze für jeden, der das Ereignis nicht miterlebt hat, wie eine bewusste Entscheidung aussieht. Drei leerlaufende CPX41 auf dieser Untergrenze kosten rund 105 €/Monat.

Prüfen: Autoscaler-Konfiguration überprüfen und die minimale Instanzzahl mit den Werten vor dem Vorfall vergleichen.

Beheben: Die Untergrenze wieder senken. Besteht tatsächlicher Bedarf an mehr Grundkapazität, den Grund dokumentieren, damit das nächste Review Kontext hat.

CI-Runner, die nie auf null skalieren

Ein selbst gehosteter GitHub-Actions- oder GitLab-Runner-Pool, der auf die Spitzenkonkurrenz dimensioniert ist, bleibt oft über Nacht, am Wochenende und über die Feiertage in voller Anzahl bestehen. Die Runner melden „healthy“: keine fehlgeschlagenen Jobs, keine Alarme, also bemerkt es niemand. Fünf leerlaufende CPX31 zu je 11,99 €/Monat sind 60 €/Monat reine Leerlauf-Kapazität.

Prüfen: Runner-Anzahl mit der tatsächlichen Pipeline-Konkurrenz abgleichen, insbesondere außerhalb der Geschäftszeiten.

Beheben: Den Pool so konfigurieren, dass er im Leerlauf auf null skaliert, oder ephemere Runner pro Job für stoßlastige Workloads verwenden.

5. Traffic und Egress

Hetzners Preisgestaltung pro TB ist im Vergleich zu AWS vergleichsweise günstig, aber „günstig“ ist nicht dasselbe wie „null“. Die teuren Fälle rutschen meist durch, weil die Anwendung weiter funktioniert und kein operativer Alarm auslöst.

Tatsächliches Workload-Wachstum überschreitet das Freikontingent

Ein Server, der jahrelang innerhalb des monatlichen Freikontingents von 20 TB blieb, kann es unauffällig zu überschreiten beginnen – ein Asset geht viral, eine Build-Pipeline zieht aggressiv, eine externe Integration fängt an zu scrapen. Die Überschreitung kostet 1 €/TB (EU), pro Server. Ein Server mit 25 TB/Monat ergibt 5 € zusätzlich; 100 TB/Monat ergeben 80 €. Kein Schutzschalter greift – lediglich E-Mail-Benachrichtigungen bei 75 % und 100 %, die leicht zu übersehen sind.

Prüfen: hcloud server list -o columns=id,name,outgoing_traffic,included_traffic zeigt die Nutzung pro Server im Vergleich zum Freikontingent.

Beheben: Ist das Wachstum real, große öffentliche Downloads vom Anwendungsserver auf eine dedizierte Auslieferungsschicht verlagern, etwa ein CDN oder einen separaten Download-Origin. Kommt der Traffic von Scraping statt echten Nutzern, Rate Limits einführen, bevor Sie die Architektur ändern.

Ein kompromittierter Server sendet mit voller Leitungsrate

Ein Server mit öffentlicher IP hat alle Ports zum Internet offen, sofern nicht explizit eine Cloud Firewall zugewiesen wurde. Wird er kompromittiert und in ein Botnetz eingebunden, kann er dauerhaft über 500 Mbit/s senden, ohne dass es anwendungsseitig auffällt. Der erste Hinweis ist meist eine Traffic-Überschreitung von 100–200 € auf einem Server, der normalerweise wenige hundert GB pro Monat verbraucht.

Prüfen: Nach Ausreißern beim ausgehenden Traffic pro Server suchen – ein Anwendungsserver, der von 500 MiB/Tag auf 500 GiB/Tag springt, ist das Signal. Mit ss -tupn und last nach unbekannten Verbindungen und Logins sehen.

Beheben: Den Server isolieren (Deny-all-Firewall oder Primary IP abhängen), einen forensischen Snapshot erstellen und aus einem bekannten guten Image neu aufbauen. Künftig jedem neu erstellten Server eine Cloud Firewall mit Minimalregelwerk zuweisen.

6. Darstellung der Rechnung

Manchmal liegt die Ursache nicht in der Infrastruktur, sondern darin, wie die Rechnung gelesen wird.

MwSt. wird auf den Listenpreis aufgeschlagen

Hetzners Preisliste und die Cloud Console zeigen Nettopreise; die MwSt. – 19 % für deutsche Kunden oder der jeweilige EU-Satz – wird bei der Rechnungsstellung addiert. Ein CCX13, der mit 15,99 € gelistet ist, steht auf einer deutschen Rechnung mit 19,03 €. Teams, die auf Basis der Preisliste budgetieren oder per Terraform provisionieren und nie auf die Rechnung selbst schauen, können eine Differenz von 19–21 % zwischen Preistabelle und Rechnungssumme leicht übersehen.

Prüfen: Die Steuerposition der Rechnung. Nettosumme × (1 + lokaler MwSt.-Satz) sollte die Bruttosumme ergeben.

Beheben: Mit Bruttopreisen planen oder die MwSt. als separate Position im FinOps-Reporting führen, damit dieselbe Differenz nicht immer wieder überrascht.

Gebühren aus anderen Projekten oder aus Robot

Ein Hetzner-Konto kann mehrere Cloud-Projekte enthalten, und im selben Konto können auch über Robot bestellte Dedicated Server liegen. Alles landet auf derselben Rechnung, aber nur das aktuell gewählte Cloud-Projekt taucht in der Nutzungsvorschau der Console auf. Eine Sandbox, ein Migrationsprojekt, das nur kurz bestehen sollte, oder das Scratch-Projekt eines ausgeschiedenen Engineers wird weiter abgerechnet – unsichtbar für alle, die nur das Hauptproduktionsprojekt prüfen.

Prüfen: Jedes Projekt im Dropdown der Cloud Console durchgehen und sich dann separat unter robot.hetzner.com einloggen, um nach Dedicated Servern und Storage Boxes zu sehen.

Beheben: Projektverantwortung formalisieren – jedes Projekt sollte einen benannten Verantwortlichen und eine Review-Taktung haben – und Robot getrennt von Cloud abgleichen.

Setup-Gebühren für Dedicated Server auf den ersten Rechnungen

Cloud-Server haben keine Einrichtungsgebühr. Dedicated Server (Robot) haben in der Regel eine, die einmal pro Provisionierung fällig wird. Ein GEX44 zu 252,64 €/Monat trägt eine einmalige Einrichtungsgebühr von 314,16 € auf der ersten Rechnung, was diesen Monat effektiv auf 566,80 € netto hebt. Wer einen Dedicated Server wiederholt erstellt und wieder beendet, zahlt die Einrichtungsgebühr jedes Mal neu.

Prüfen: Die Position für Einmalgebühren der Rechnung gegen jede kürzliche Provisionierung eines Dedicated Servers abgleichen.

Beheben: Dedicated Server als langlebige Fixpunkte behandeln. Wer kurzfristige Kapazität benötigt, ist mit Cloud-Servern (ohne Einrichtungsgebühr) besser bedient.

So gleichen Sie eine Hetzner-Rechnung in 10–15 Minuten ab

Wenn die Rechnung vor Ihnen liegt und die Frage lautet „Welche Position ist die Überraschung?“, kommen Sie mit einem strukturierten Abgleich schneller ans Ziel als mit einer ungerichteten Suche. Jeder Schritt dauert 2–3 Minuten; die meisten Fälle klären sich, bevor Sie das Ende erreichen.

1. Abgleich der Rechnungspositionen. Die Rechnung dieses Monats neben die des Vormonats legen. Hetzner schlüsselt nach Ressourcentyp auf – Cloud-Server, Primary IPs, Volumes, Snapshots, Backups, Traffic, Robot, Einmalgebühren. Untersuchen Sie zuerst die Kategorie, die gewachsen ist. Ist eine einzelne Position um mehr als wenige Prozent gestiegen, geht es in allen weiteren Schritten darum, genau diese Abweichung zu erklären.

2. Audit der Console über alle Projekte. Das Projekt-Dropdown in der Cloud Console öffnen und jedes Projekt durchgehen – nicht nur das, auf das Sie üblicherweise schauen. In jedem Projekt Server-Liste und Kostenübersicht überfliegen. Sie suchen zwei Dinge: ein Projekt, dessen Existenz Sie vergessen hatten, und eine laufende Grundlast, die nicht zu Ihrer Erinnerung an den Workload passt.

3. Inventurcheck der Ressourcen. Für jedes Projekt mit Workloads die fünf abrechenbaren Objekttypen auflisten. Die meisten Teams machen das mit hcloud:

hcloud server list -o columns=id,name,status,type,primary_disk_size
hcloud primary-ip list
hcloud floating-ip list
hcloud volume list
hcloud image list --type snapshot -o columns=id,description,created,image_size

Für jede Zeile die Frage stellen: „Weiß ich, warum das existiert, und würde ich es heute wieder anlegen?“ Zeilen, bei denen die Antwort Nein lautet, sind die ersten Löschkandidaten. Auf Primary IPs mit AUTO DELETE auf no achten – das sind die Gebühren für nicht angebundene IPs, die die Grundlast leise hochhalten.

4. Traffic-Ausreißer prüfen. Wenn die Rechnung eine Traffic-Position ausweist, mit der Sie nicht gerechnet haben:

hcloud server list -o columns=id,name,outgoing_traffic,included_traffic

Ein Server mit deutlich mehr ausgehendem Traffic als der Rest ist entweder eine echte Workload-Änderung, ein fehlgeleiteter interner Pfad oder eine Kompromittierung. Alle drei Fälle verdienen einen genaueren Blick.

5. Robot-Check. Separat robot.hetzner.com besuchen und auf Dedicated Server, Storage Boxes und andere Robot-spezifische Produkte prüfen. Diese erscheinen in keinem Audit der Cloud Console. Steht eine Einmalgebühr auf der Rechnung, kommt sie in der Regel von hier.

6. Terraform-Abgleich (optional). Wird das Konto über Terraform verwaltet, terraform state list ausführen und mit hcloud server list abgleichen. Ressourcen, die in hcloud, aber nicht in Terraform auftauchen, sind Ad-hoc-Arbeit oder Drift. Ressourcen, die in Terraform, aber nicht in hcloud auftauchen, sind meist ein Problem der State-Datei, bedeuten aber gelegentlich, dass etwas in der Console gelöscht wurde und Terraform es beim nächsten apply neu anlegen wird.

7. Plausibilitätsprüfung der Rechnungsinterpretation. Bevor Sie schließen, dass die Plattform falsch abgerechnet hat: prüfen, ob die MwSt.-Position dem erwarteten Satz entspricht und keine kürzlich angefallenen Setup-Gebühren aus Robot-Bestellungen den Monat aufblähen. Diese beiden Punkte erklären die meisten Fälle nach dem Muster „Die Zahl stimmt, aber nicht das, was ich erwartet habe“.

Die meisten Rechnungen klären sich in den Schritten 1–3. Schritt 4 erklärt trafficbedingte Überraschungen, Schritt 5 Robot-bedingte, Schritt 7 Fälle, die aus der Rechnungsdarstellung entstehen. Die verbleibenden Fälle – meist die, deren Aufklärung am längsten dauert – sind fast immer ein Automatisierungsmuster aus Abschnitt 4, das einen Blick auf den Ressourcenzustand über die Zeit erfordert, nicht auf eine Momentaufnahme.

So verhindern Sie die Wiederholung

Eine überraschend hohe Rechnung aufzuklären ist eine einmalige Triage. Dafür zu sorgen, dass die nächste Rechnung Sie nicht überrascht, ist eine andere Aufgabe – nämlich eine Frage operativer Gewohnheit. Drei kleine Gewohnheiten fangen den Großteil der hier beschriebenen Fälle ab:

• Quartalsweiser Ressourcen-Review über alle Projekte, nicht nur die Produktion. Fünfzehn Minuten pro Quartal verhindern die meisten Fälle aus §1 (vergessene Ressourcen) und §6 (versteckte Projekte, Robot).
• Ein Standard-Servertyp für Nicht-Produktions-Arbeit – CPX oder CAX. Ist CCX der organisationsweite Standard für alles, ist Rightsizing-Drift unausweichlich. Ist CCX eine explizite Entscheidung, entsteht die Drift gar nicht erst.
• Eine namentlich benannte verantwortliche Person pro Projekt. Projekte ohne klare Zuständigkeit driften; Projekte mit klarer Verantwortung werden in der Regel stillgelegt, wenn ihre Aufgabe endet.

Nichts davon braucht Tooling. Es braucht einen wiederkehrenden Kalendereintrag und die Regel, dass niemand ein Projekt anlegt, ohne seinen Namen daran zu hängen.

Wer den Audit nicht quartalsweise, sondern kontinuierlich möchte: CloudTally erfasst den Zustand von Hetzner-Ressourcen alle 15 Minuten über jedes Projekt eines Kontos – einschließlich autoskalierter Server und nächtlicher CI-Kapazität, die nur existieren, wenn niemand hinsieht – und macht diese Muster als wiederkehrende Befunde sichtbar, statt als monatliche Rechnungsüberraschungen.

Dieser Artikel wurde maschinell übersetzt.