Hetzners Preiserhöhung im Juni 2026: richtig skalieren

Der 15. Juni ist Hetzners vierte Preismaßnahme seit Februar: Setup-Gebühren im Februar, eine portfolioweite monatliche Erhöhung am 1. April, erneut Setup-Gebühren für Dedicated Server am 29. April und nun eine Standardisierung mit einer weiteren Preisanpassung. Diese Änderung ist anders. Anders als am 1. April ändert sich der Preis für keinen einzigen bestehenden Server.

Kurz gefasst. Bestehende Server behalten ihren aktuellen Preis. Nur Neubestellungen und neu skalierte Server bekommen den neuen Preis. Schützen Sie also Ihre stabilen Server, verhindern Sie versehentliche Neuaufbauten durch Automatisierung, und legen Sie variable Lasten auf Wegwerf-Kapazität, für die der neue Tarif ohnehin gilt.

Die Änderung bepreist nur zwei Dinge neu: Neubestellungen und Rescales. Hetzner hat sie am 27. Mai angekündigt, allerdings ohne Preistabellen und mit dem Hinweis, die Zahlen „im Laufe der Umstellung" zu nennen. Den genauen Euro-Effekt können Sie also noch nicht berechnen. Die Struktur steht aber fest, und genau dort fallen die Entscheidungen.

Der hilfreiche Blickwinkel lautet nicht „die Preise sind gestiegen". Hetzner bepreist den Vorgang des Skalierens und Neuaufbaus von Servern neu, nicht die laufenden Server selbst. Die Antwort besteht nicht darin, Skalierung einzustellen, und das tut ohnehin kaum jemand. Die Antwort ist, anders zu skalieren. Halten Sie die stabile Grundlast auf den heutigen Tarifen. Legen Sie Wachstum und variable Last auf Kapazität, die ohnehin zum neuen Tarif abgerechnet wird. Und verhindern Sie, dass Ihre Automatisierung einen gesicherten Server zum neuen Preis neu aufbaut.

Was der 15. Juni tatsächlich neu bepreist

Die Mechanik lässt sich auf drei Regeln reduzieren, und alle drei folgen aus einem Kernsatz der Ankündigung: Die Änderungen gelten ausschließlich für Neubestellungen und Rescales bestehender Server.

• Ein vor dem 15. Juni bereitgestellter Server behält seinen aktuellen Monatspreis, solange Sie seinen Tarif unangetastet lassen. „Aktuell" bedeutet bereits den Tarif vom 1. April, denn diese Erhöhung betraf bestehende Server.
• Jeder ab dem 15. Juni bestellte Server wird zum neuen Tarif abgerechnet.
• Jeder Rescale, in beide Richtungen, überführt diesen Server in den neuen Tarif. Hetzner unterscheidet nicht zwischen Hoch- und Herunterskalieren.

Mehrere Ressourcen bleiben von dieser Änderung vollständig unberührt: Volumes, Snapshots, Load Balancer, Object Storage, IPs, Server-Auction-Bestand, Webhosting und Managed Server. Günstiger werden sie nicht; sie wurden bereits am 1. April neu bepreist. Die Standardisierung vom 15. Juni lässt sie aber unangetastet.

Für Dedicated Server gibt es ein echtes Zugeständnis. Hetzner senkt die einmaligen Setup-Gebühren „für die meisten Dedicated Server deutlich" und verlagert diese Kosten stattdessen in einen höheren Monatspreis. Außerdem fasst Hetzner die bisherigen RAM- und Storage-Optionen pro Server zu bis zu drei festen Konfigurationen je Typ zusammen, ergänzt um eine günstigere „Limited"-Linie. Dieser Tausch zwischen Setup-Gebühr und Monatspreis wird zu einer Timing-Entscheidung; darum geht es in der zweiten Hälfte dieses Beitrags.

Der teure Schritt ist der Rescale, nicht der Server

Hier greift der verbreitete Rat „schützen Sie Ihre gesicherten Preise" zu kurz. Ein gesicherter Preis lohnt sich nur dann, wenn der kleinere Server, auf den Sie wechseln würden, zum neuen Tarif immer noch mehr kostet als das, was Sie heute zahlen. Bei einem überdimensionierten Server ist es umgekehrt: Die Sicherung schützt eine Rechnung, die ohnehin zu hoch ist.

Rechnen wir ein echtes Beispiel durch. Ein CCX33 (Dedicated vCPU), vor April bereitgestellt, liegt jetzt bei seinem gesicherten Preis von 62,49 € pro Monat (nach 47,99 € vor dem 1. April). Angenommen, 30 Tage Messdaten zeigen im Schnitt 12 % CPU-Auslastung ohne Speicherdruck: Ein Server der CPX32-Klasse würde diese Last bewältigen. Ein CPX32 kostet 13,99 € pro Monat. Dorthin zu wechseln führt ohnehin in den neuen Tarif. Sie können einen Rescale machen, und Hetzner berechnet bei jedem Rescale den neuen Tarif. Oder Sie bauen auf dem kleineren Typ neu auf, was oft ohnehin nötig ist, weil ein Rescale die Festplatte nicht verkleinern kann.

Den CCX33 zu behalten, um den „gesicherten Preis zu schützen", heißt: 62,49 € für 13,99 € tatsächliche Arbeit zu zahlen. Der gesicherte Preis lohnt sich dann nicht mehr. Die Entscheidung ist ein einfacher Vergleich:

Ihr gesicherter Tarif (G)	Richtig dimensionierter Server, neuer Tarif (N)	Entscheidung
62,49 € (CCX33, überdimensioniert)	13,99 € (CPX32)	Wechseln. Die Sicherung treibt die Rechnung unnötig hoch.
15,99 € (CCX13, richtig dimensioniert)	höher als 15,99 €	Behalten. Die Sicherung schlägt einen frischen Server.

Welche N Sie tatsächlich treffen würden, und damit in welcher Zeile Sie stehen, zeigen Ihre Auslastungsdaten. CPU, Speicher und Netzwerk pro Server über 30 Tage machen aus der Entscheidung „behalten oder wechseln" einen Vergleich zweier Zahlen statt einer Vermutung.

Ihre Automatisierung kann einen gesicherten Tarif unbemerkt verlieren

Das Teuerste, was ein DevOps-Team in den kommenden Wochen tun kann, ist, einen preislich gesicherten Server unbemerkt zu zerstören und neu zu erstellen. Ein neu aufgebauter Server ist eine Neubestellung und wird zum neuen Tarif abgerechnet, selbst wenn das Terraform genauso aussieht wie im Vormonat.

Das passiert leichter, als es klingt. Mehrere alltägliche Aktionen zerstören die alte Instanz und erstellen eine neue:

• das Ändern eines Attributs, das eine Neuerstellung erzwingt, an einer hcloud_server-Ressource (Image, Standort, manchmal der Servertyp, wenn die Festplatte schrumpfen würde),
• ein terraform apply -replace,
• oder jede Pipeline nach dem Muster „frisches Image backen und die Flotte durchrollen".

In der Plan-Ausgabe steht forces replacement in kleiner grauer Schrift, und die Preissicherung ist weg.

Die zuverlässige Verteidigung ist Hetzners eigene Schutzfunktion. Für jeden Cloud-Server lassen sich Löschschutz und Rebuild-Schutz aktivieren. Ist der Schutz aktiv, verweigert die API das Löschen des Servers, und ein versehentliches terraform apply -replace schlägt sichtbar fehl, statt den Server still zum neuen Tarif neu aufzubauen. In der Cloud Console zeigt ein geschützter Server ein Schloss-Symbol mit dem Tooltip „Schutz aktiv". In Terraform sind es delete_protection = true und rebuild_protection = true an der hcloud_server-Ressource, oder hcloud server enable-protection <name> delete rebuild über die CLI. Schalten Sie den Schutz für jeden vor dem 15. Juni bereitgestellten Server ein.

Zwei Gewohnheiten stützen das ab. Bevorzugen Sie In-Place-Updates, wo Hetzner sie zulässt, denn eine Änderung des Servertyps auf gleich groß oder größer ist ein Rescale statt einer Neuerstellung. Ein Rescale erhält den Server immerhin, wenn auch zum neuen Tarif. Prüfen Sie außerdem terraform plan auf forces replacement, bevor Sie anwenden. Doch nur der Schutz stoppt den Neuaufbau technisch, statt sich darauf zu verlassen, dass Sie ihn rechtzeitig bemerken.

Horizontal statt vertikal skalieren, um gesicherte Tarife zu halten

Vertikales Skalieren bepreist den Server neu, den Sie anfassen. Horizontales Skalieren fasst ihn gar nicht an.

Einen CCX23 auf einen CCX33 hochzuskalieren überführt genau diesen Server in den neuen Tarif. Einen zweiten CCX23 danebenzustellen lässt den ursprünglichen Server preislich gesichert und bepreist nur den neuen Knoten zum neuen Tarif. Für jede horizontal skalierbare Schicht (zustandslose Web- und API-Worker, Queue-Consumer, Read-Replicas) erhält das Hinzufügen von Knoten die gesicherten Tarife für alles, was Sie bereits betreiben. Ihr Mischtarif steigt dann mit dem Wachstum langsam, statt in einem Sprung zurückgesetzt zu werden.

Der Kompromiss ist real und sei genannt: mehr Knoten bedeuten mehr Orchestrierung, und die neuen Knoten sind weiterhin zum neuen Preis. Doch die bestehende Flotte bleibt gesichert, und genau das ist der Vermögenswert, den die Änderung vom 15. Juni wertvoll macht.

Die Grundlast sichern, den variablen Teil wegwerfbar machen

Teilen Sie Ihre Flotte in zwei Gruppen: stabile Server und temporäre Server. Behandeln Sie sie unterschiedlich.

Stabile Server. Die stabile Grundlast ist alles, was durchgängig läuft: Datenbanken, die feste Web-Schicht, Broker, Monitoring. Dimensionieren Sie sie jetzt anhand realer Auslastung, planen Sie bewusst einen Wachstumspuffer von drei bis sechs Monaten ein (größer als üblich, weil ein späteres Hochskalieren sie auf den neuen Tarif bringt), und lassen Sie sie dann in Ruhe. Diese Flotte ist Ihr preislich gesicherter Vermögenswert.

Temporäre Server. Der variable Teil ist alles, was kommt und geht: CI/CD-Runner, Preview-Umgebungen, Batch-Jobs, Lasttests, durch Cron ausgelöste Spitzen. Diese Kapazität wird ohnehin zum neuen Preis abgerechnet, weil sie jedes Mal frisch erzeugt wird. Es gibt also nichts zu schützen und allen Grund, sie konsequent zu optimieren. Verdichten Sie sie mit einem Container-Orchestrator (Kubernetes oder Nomad), skalieren Sie aggressiv automatisch, und fahren Sie sie herunter, sobald sie ungenutzt ist. Vorübergehende Spitzen sollen temporäre Kapazität nutzen und Sie nicht zwingen, langlaufende Server umzudimensionieren.

Zwei Timing-Manöver, bevor die Preise veröffentlicht werden

Die Änderung bei den Setup-Gebühren und eine leicht zu übersehende Ausnahme sprechen beide dafür, vor dem 15. Juni zu handeln.

Langlebige Dedicated Server vor dem 15. Juni bestellen

Die monatlichen Dedicated-Tarife steigen am 15. Juni, während die Setup-Gebühren fallen. Für einen Server, den Sie über Jahre betreiben, sichert eine Bestellung jetzt den niedrigeren Monatstarif; Sie zahlen die höhere Setup-Gebühr einmalig und sparen die monatliche Differenz danach Monat für Monat. Für einen Server, den Sie nur kurz behalten, etwa eine Staging-Maschine für eine Migration oder einen einmaligen Batch-Cruncher, kann die niedrigere Setup-Gebühr nach dem 15. Juni trotz des höheren Monatstarifs günstiger sein.

Der Break-even ist schlicht die Ersparnis bei der Setup-Gebühr geteilt durch die monatliche Erhöhung. Spart das Warten 60 € Setup, kostet aber 10 € pro Monat mehr, liegt der Break-even bei sechs Monaten: Behalten Sie den Server kürzer, warten Sie. Behalten Sie ihn länger, bestellen Sie jetzt. Cloud-Server haben keine Setup-Gebühr, also lautet die Regel für die Cloud einfach: Alles Langlebige vor dem 15. Juni bestellen. Die genauen Zahlen können Sie erst einsetzen, wenn Hetzner sie veröffentlicht, aber Sie können die Regel jetzt festlegen und am Tag der Veröffentlichung handeln.

Die Senkung der Setup-Gebühr ist eine Korrektur, kein Geschenk. Die Erhöhung Ende April trieb die einmaligen Gebühren bei neuerer Dedicated-Hardware auf rund das Vierfache des Monatstarifs. Die AX-Linien-Matrix zeigt es deutlich: Der AX102-U, eine aktuelle 16-Kern-Maschine mit Ryzen 9 7950X3D und 128 GB RAM, hat eine Setup-Gebühr von 500 € gegenüber 119 € pro Monat (netto). Der AX42-U und der AX162-R liegen bei ähnlichen Vielfachen; nur der ältere AX41-NVMe bleibt nahe bei einer Monatsgebühr. Auf diesem Niveau zahlen Sie mehrere Monatsmieten im Voraus, bevor der Server überhaupt arbeitet. Das macht kurzfristige und experimentelle Dedicated Server unwirtschaftlich und verschiebt dieses Geschäft zu Anbietern ohne hohe Einstiegsgebühr. Der 15. Juni macht das rückgängig, weshalb Warten bei allem Kurzlebigen meist besser ist.

Server Auction wurde unbemerkt zum günstigeren Pool

Der Server-Auction-Bestand erhielt am 1. April nur eine Erhöhung von 3 % und steht auf der Ausnahmeliste für den 15. Juni. Während die standardisierte Dedicated-Linie teurer wird, bleibt der Auction-Pool im Vergleich günstig. Für unkritische oder variable Dedicated-Lasten, die ältere Hardware und die jeweils vorrätige Konfiguration vertragen, ist er nun die günstigere Option, und der Abstand wächst. Auction-Server haben zudem gar keine Setup-Gebühr, also genau jene Kosten, die neue Dedicated-Bestellungen gerade so teuer im Einstieg machen.

Intensive CI belohnt Beständigkeit statt Kurzlebigkeit

Cloud-Server werden stündlich abgerechnet, der neue Tarif skaliert also mit Runner-Stunden, nicht mit der Anzahl der Server. Ein Team, das monatlich Tausende CI-Runner-Stunden verbraucht, zahlt die Erhöhung auf jede einzelne davon.

Ein einzelner dauerhafter Runner, vor dem 15. Juni bereitgestellt, ist preislich gesichert und wird zu einem festen Monatstarif abgerechnet, egal wie stark er ausgelastet ist. Für intensive, stetige CI-Pipelines kann ein gut dimensionierter, stehender Runner zum heutigen Tarif weniger kosten als Flotten frischer, neu bepreister kurzlebiger Instanzen. Die Voreinstellung „immer kurzlebig" ist sinnvoll, aber nicht mehr automatisch die günstigste. Das lohnt sich, an Ihrem tatsächlichen Runner-Stunden-Volumen zu messen.

Was Sie vor dem 15. Juni sichern sollten

Das Zeitfenster belohnt gezielte Maßnahmen statt Panik:

1. Dimensionieren Sie die stabile Grundlast anhand von 30 Tagen Auslastung, planen Sie einen Puffer von drei bis sechs Monaten ein, und frieren Sie sie dann ein.
2. Pinnen oder schützen Sie Server von vor dem 15. Juni in Ihrem IaC, damit ein versehentliches forces replacement sie nicht zum neuen Tarif neu aufbaut.
3. Bestellen Sie jede langlebige Dedicated- oder Cloud-Kapazität, von der Sie bereits wissen, dass Sie sie brauchen, um den aktuellen Monatstarif zu sichern.
4. Löschen Sie jetzt ungenutzte und verwaiste Ressourcen. Der Leitfaden zum Ressourcen-Audit listet die hcloud-Befehle; ein gesicherter Tarif auf einem ungenutzten Server ist nur abgesicherte Verschwendung.
5. Legen Sie die Break-even-Regel für die Dedicated-Setup-Gebühr fest, damit Sie am Tag der Preisveröffentlichung handeln können.

Planen Sie für die nächste Erhöhung, nicht für eine Rücknahme

Vier Preismaßnahmen in viereinhalb Monaten sind kein Ausreißer. Die DRAM-Knappheit hinter der April-Erhöhung dürfte bis 2028 anhalten, und Hardwarekosten fallen weit langsamer, als sie steigen. Die realistische Annahme lautet also: weitere Erhöhungen, keine Rückkehr zu alten Preisen. Jede dürfte ähnlich aussehen wie dieser Juni: bestehende Server unangetastet, Neubestellungen und Rescales neu bepreist. Die eigentliche Frage ist nicht, wie Sie auf den 15. Juni reagieren. Sie lautet, ob Ihre Infrastruktur die nächste Erhöhung ohne hektische Änderungen verkraftet: mit einer Grundlast, die stillstehen kann, und einer variablen Schicht, die günstig neu aufzubauen ist, weil sie ohnehin zum Wegwerfen gedacht war.

Dieser Artikel wurde maschinell übersetzt.