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.

Hetzner hat die Änderung am 27. Mai angekündigt, zunächst ohne Preistabellen. Dieser Beitrag erschien vor der Umstellung und wurde am 18. Juni um die veröffentlichten Tarife ergänzt. Die angekündigte Zweiteilung hat sich bestätigt: Die kostenoptimierten Shared-vCPU-Tarife stiegen um rund ein Drittel, während sich die leistungsstarken und die Dedicated-vCPU-Cloud-Linien mehr als verdoppelten. Die Entscheidungen lagen ohnehin in der Struktur; die Zahlen schärfen sie nur, statt sie zu verändern.

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.

Die veröffentlichten Tarife teilen sich klar nach Leistungsklasse

Die kostenoptimierten Shared-vCPU-Linien stiegen moderat. Die Leistungs- und die Dedicated-vCPU-Linien haben sich grob verdoppelt bis verdreifacht. Die Zahlen unten sind die veröffentlichten Hetzner-Tarife für Deutschland und Finnland, monatlich, netto. Die Spalte „Bestandspreis" ist der Tarif vom 1. April, den bestehende Server behalten; der „neue Tarif" ist, was eine Neubestellung oder ein Rescale zahlt.

Tarif	Bestandspreis (1. April)	Neuer Tarif (15. Juni)	Änderung
CX23 (Shared vCPU)	3,99 €	5,49 €	+38 %
CAX11 (Shared Arm)	4,49 €	5,99 €	+33 %
CPX32 (High-Performance)	13,99 €	35,49 €	+154 %
CPX52 (High-Performance)	36,49 €	100,49 €	+175 %
CCX23 (Dedicated-vCPU-Cloud)	31,49 €	85,99 €	+173 %
CCX33 (Dedicated-vCPU-Cloud)	62,49 €	138,49 €	+122 %
CCX63 (Dedicated-vCPU-Cloud)	374,49 €	853,49 €	+128 %

Der Abstand zwischen den beiden Spalten ist der Kern. Bei einer CX- oder CAX-Maschine ist der Bestandspreis ein, zwei Euro im Monat wert. Bei einer CPX- oder CCX-Maschine ist er inzwischen mehr wert als der Server selbst, und genau daran hängt jede Entscheidung weiter unten.

Die Tabelle oben zeigt nur Hetzner-Cloud-Server. Hetzner verkauft außerdem Bare-Metal-Dedicated-Server (die AX-Reihe, über Robot bestellt); sie sind ein eigenes Produkt und haben sich anders verändert. Ein späterer Abschnitt behandelt sie.

Ein Bestandspreis lohnt sich meist, mit einer Ausnahme

Jetzt, da die neuen Tarife öffentlich sind, ist der Bestandspreis bei fast jedem CPX- und CCX-Server die richtige Wahl: Der neue Tarif liegt mehr als doppelt so hoch wie der gesicherte. Die Ausnahme ist eng und lohnt eine Prüfung von Hand. 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 stark überdimensionierten Server schützt die Sicherung eine Rechnung, die ohnehin zu hoch ist.

Hier der Fall, in dem sich ein Wechsel noch lohnt. Ein CCX33 (Dedicated vCPU), vor April bereitgestellt, liegt 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. Zum neuen Tarif kostet ein CPX32 35,49 € pro Monat. Dorthin zu wechseln führt ohnehin in den neuen Tarif. Der Wechsel von einem Dedicated-vCPU-CCX zu einem Shared-vCPU-CPX überschreitet die Server-Familien, ist also ein Neuaufbau statt eines Rescales, und ein Neuaufbau ist oft ohnehin nötig, weil ein Rescale die Festplatte nicht verkleinern kann. Selbst wo ein Rescale möglich ist, berechnet Hetzner darauf den neuen Tarif.

Den CCX33 zu behalten, um den „gesicherten Preis zu schützen", heißt dann: 62,49 € für 35,49 € an gleichwertiger Kapazität zu zahlen. Hier lohnt sich die Sicherung nicht mehr. Beachten Sie aber, wie viel knapper dieser Abstand ausfällt als noch im Mai, als derselbe CPX32 13,99 € kostete: Die Juni-Tarife machen den Bestandspreis weit häufiger zur richtigen als zur falschen Antwort. Die Entscheidung ist ein einfacher Vergleich:

Ihr gesicherter Tarif (G)	Right-sized Server, neuer Tarif (N)	Entscheidung
62,49 € (CCX33, überdimensioniert bei 12 % CPU)	35,49 € (CPX32)	Wechseln. Die Sicherung treibt die Rechnung unnötig hoch.
15,99 € (CCX13, bereits right-sized)	42,99 € (derselbe CCX13, neuer Tarif)	Behalten. Der neue Tarif ist das 2,7-Fache des Bestandspreises.

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 gerade jetzt 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 erscheint forces replacement in roter Schrift; in einer langen Ausgabe ist das leicht zu übersehen, 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 weitere Vorkehrungen helfen hier. Erstens: Wenn Sie den Typ eines Servers ändern müssen, wechseln Sie auf dieselbe Größe oder größer. Terraform führt das als In-Place-Update aus, das Hetzner als Rescale umsetzt, sodass der Server mit Festplatte und Daten erhalten bleibt. Ein kleinerer Typ (oder ein geändertes Image bzw. ein anderer Standort) erzwingt dagegen eine Ersetzung: Terraform zerstört den Server und legt einen neuen an. Das In-Place-Update bringt Sie trotzdem auf den neuen Tarif, erspart Ihnen aber das schlimmere Ergebnis einer versehentlichen Ersetzung, die zusätzlich den Server löscht. Zweitens: Prüfen Sie die terraform plan-Ausgabe auf forces replacement, bevor Sie anwenden. Nur die Schutzfunktion verhindert eine Ersetzung wirklich; alles andere hängt davon ab, dass Sie es 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, und der neue Tarif ist der Juni-Preis des Zielservers, nicht dessen alter. Ein CCX23, gesichert bei 31,49 €, wird nicht zu den 62,49 €, die ein CCX33 früher kostete; er wird in dem Moment, in dem der Rescale abgeschlossen ist, zum neuen CCX33-Tarif von 138,49 €. Einen zweiten CCX23 danebenzustellen lässt den ursprünglichen Server stattdessen 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. Right-sizen 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.

Diese Aufteilung ist das Muster, auf das sich die meisten Teams nach dem Inkrafttreten der Tarife eingependelt haben. Der wiederkehrende Rat in den Community-Threads seit dem 15. Juni läuft auf dasselbe hinaus: die produktive Flotte in ihrer aktuellen Größe einfrieren, nur Wegwerf-Lasten auf den neuen Tarif schicken und lieber einen zweiten kleinen Knoten hinzunehmen, als einen großen umzudimensionieren.

Intensive CI kann mit einem dauerhaften Runner günstiger sein

CI-Runner sehen wie klassische temporäre Server aus; die Aufteilung oben würde sie also auf neu bepreiste Wegwerf-Kapazität schicken. Bei intensiver, stetiger CI kann das die falsche Wahl sein. 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. Dieser Abstand hat sich am 15. Juni stark vergrößert: Kurzlebige CPX- und CCX-Runner werden nun zu Tarifen abgerechnet, die sich mehr als verdoppelt haben, während ein gesicherter dauerhafter Runner weiter zu seinem April-Preis läuft. 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.

Günstige Bare-Metal-Server gibt es jetzt in der Limited-Reihe

In diesem Abschnitt geht es um Bare-Metal-Dedicated-Server (die AX-Reihe, über Robot bestellt), nicht um die CCX-Cloud-Server von oben. Sie bekamen keinen schlichten prozentualen Aufschlag. Hetzner standardisierte jedes Modell auf bis zu drei feste Konfigurationen (-1, -2, -3) und machte diese Standardkonfigurationen in den meisten Fällen zu vollwertigeren Maschinen als die, die sie ablösen. Der Standard-AX42-1 liegt jetzt bei 187,30 € pro Monat als kräftigerer Aufbau (64 GB DDR5 und zwei NVMe-SSDs mit je 1,92 TB), während der alte AX42 eine kleinere Maschine näher an 57 € war. Auf den reinen Listenpreis bezogen wirkt das wie mehr als eine Verdreifachung, doch der Standard-AX42-1 ist in Wahrheit eine andere, vollwertigere Maschine.

Die günstigen Konfigurationen im Stil der alten Modelle sind auf eine eigene Limited-Linie gewandert, gekennzeichnet mit -1-Ltd. Sie laufen auf Hardware, die Hetzner günstiger und in begrenzter Menge beschafft, angeboten „solange der Vorrat reicht". Dort liegen jetzt die vertrauten Einstiegspreise:

Modell	Standard	Limited (-1-Ltd)
AX41	nur Limited	57,30 €/Monat, 0 € Setup
AX42	187,30 €/Monat, 94 € Setup	77,30 €/Monat, 39 € Setup
AX102	452,30 €/Monat, 224 € Setup	157,30 €/Monat, 39 € Setup
AX162	612,30 €/Monat, 304 € Setup	317,30 €/Monat, 39 € Setup

Damit hat sich der praktische Schritt für eine kostenorientierte Dedicated-Bestellung verschoben. Wenn Sie einen günstigen AX42 wie früher wollen, ist der passende jetzt der AX42-1-LTD zu 77,30 € statt des Standard-AX42-1 zu 187,30 €. Der günstigste AX überhaupt, der AX41, existiert nur noch auf der Limited-Linie, zu 57,30 € ohne Setup-Gebühr. Der Haken ist die Verfügbarkeit: Die Limited-Linie gibt es nur, wenn Hetzner die günstigere Hardware vorrätig hat; sie ist also ein Pool, den man im Auge behält, kein garantierter Katalog.

Die Server Auction ist der andere günstige Pool, und Hetzner sagt es selbst

Der Server-Auction-Bestand erhielt am 1. April nur eine Erhöhung von 3 % und steht auf der Ausnahmeliste für den 15. Juni. Auf der eigenen Preisanpassungs-Seite verweist Hetzner Käufer nun direkt dorthin und empfiehlt die Auction ausdrücklich für gute Angebote bei älteren Servermodellen. Für unkritische oder variable Dedicated-Lasten, die ältere Hardware und die jeweils vorrätige Konfiguration vertragen, sind die Auction und die Limited-Linie die beiden Orte, an denen das alte Preis-Leistungs-Verhältnis noch lebt. Auction-Server haben zudem keine Setup-Gebühr, also genau jene Kosten, die eine frische Standardbestellung im Einstieg teuer machen.

Was sich weiterhin lohnt

Das Bestellfenster schloss am 15. Juni, aber die Bestandspreise, die Sie bereits halten, sind nun der Vermögenswert, und ihn zu schützen ist die Arbeit:

1. 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. Das ist die wertvollste Einzelmaßnahme, denn ein einziger versehentlicher Neuaufbau bepreist den Server dauerhaft neu.
2. Right-sizen Sie die stabile Grundlast anhand von 30 Tagen Auslastung, mit einem Puffer von drei bis sechs Monaten, und frieren Sie sie dann ein. Der Puffer fällt größer aus als üblich, weil ein späteres Hochskalieren sie auf den neuen Tarif bringt.
3. Prüfen Sie Ihre am stärksten überdimensionierten gesicherten Server gegen den Vergleich „behalten oder wechseln" oben. Bei diesen hohen neuen Tarifen lautet die Antwort fast immer „behalten"; die seltenen Ausnahmen mit „wechseln" sollten Sie aber aufspüren.
4. Löschen Sie 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. Bepreisen Sie für neue Dedicated-Kapazität zuerst die Limited-Linie (-1-Ltd) und die Server Auction, bevor Sie zu den Standardkonfigurationen -1/-2/-3 greifen. Dort lebt das alte Preis-Leistungs-Verhältnis noch.

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. Der 15. Juni hat die Vorlage gesetzt, der die nächste Erhöhung wohl folgt: bestehende Server unangetastet, Neubestellungen und Rescales neu bepreist, und die stärksten Anstiege treffen die Leistungsklassen. 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.