Dedizierte Server statt Cloud-VM: mehr Leistung pro Euro, mehr Verantwortung im Betrieb

Bei Infrastruktur-Diskussionen geht es meistens um „Cloud oder nicht“. Für viele unserer Kunden ist eine andere Frage relevanter: dedizierte Hardware oder virtuelle Maschine? Bei planbarer Dauerlast fällt die Antwort ziemlich eindeutig aus, Bare Metal hat das bessere Preis-Leistungs-Verhältnis. Trotzdem schrecken viele davor zurück, und das liegt selten an der Rechnung. Mit dem eigenen Server übernimmt man Aufgaben, die vorher der Hypervisor erledigt hat.

Genau diese Aufgaben übernehmen wir für unsere Kunden. In diesem Artikel geht es deshalb um beide Seiten: was man mit dedizierter Hardware gewinnt, was man dafür tun muss und mit welchen Werkzeugen wir den Betrieb abdecken.

Was man gewinnt

• Dedizierte Kerne: Keine Steal Time und keine Nachbarn, die zur falschen Tageszeit die CPU auslasten. Bei Datenbanken und latenzkritischen Anwendungen ist das für uns meist das wichtigere Argument als der Preis.

• Viel RAM und NVMe: Eine MySQL-Instanz mit einem Buffer Pool im zweistelligen GB-Bereich ist auf dedizierter Hardware Standard. In der Cloud wird so eine Konfiguration schnell zur Budgetfrage.

• Lokaler Storage: Die NVMe steckt direkt im Server. Es gibt keine IOPS-Kontingente und keine Storage-Rechnung, die mit der Nutzung mitwächst.

• Planbare Kosten: Ein fester Monatspreis statt nutzungsbasierter Abrechnung, die man erst am Monatsende versteht. Beim Vergleich machen Storage und Traffic oft einen größeren Unterschied als der eigentliche Compute-Preis.

Was man dafür übernimmt

• Hardwaredefekte: Stirbt unter einer VM eine Platte, verschiebt der Anbieter die Instanz und man bekommt im besten Fall nichts davon mit. Auf dedizierter Hardware ist die defekte Platte oder das kaputte Netzteil das eigene Problem.

• Keine Snapshots: Mal eben zurückrollen geht nicht. Ersatz sind Backups mit regelmäßig getestetem Restore und ein Host, der vollständig in Ansible beschrieben ist. Letzteres wird gern unterschätzt. Lässt sich eine Maschine per Playbook reproduzieren, ist ein Neuaufbau keine große Sache mehr.

• Grobe Skalierung: Zwei zusätzliche vCPUs gibt es nicht, man zieht auf die nächstgrößere Maschine um. Das sollte man vorher einplanen. Eine ordentlich dimensionierte Maschine hat allerdings meistens lange Luft.

• Längere Bereitstellung: Ein neuer Server ist eher in Stunden als in Sekunden da, und ein Hardwaretausch braucht Vorlauf. Wir planen deshalb Reserven ein, anstatt auf Elastizität zu setzen.

• Hardware-Monitoring: Temperaturen, Lüfter und Plattenzustand muss man selbst im Blick behalten. Auf einer VM ist das nie ein Thema, auf Bare Metal ist es Pflicht.

Wer diesen Teil nicht selbst übernehmen möchte: Dafür gibt es unsere Managed Dedicated Server. Wie das bei uns in der Praxis aussieht, beschreiben wir weiter unten.

Die Zahlen nach Hetzners Preisrunde im Juni

Hetzner hat 2026 schon mehrfach an den Preisen gedreht. Zum 1. April wurde fast das komplette Portfolio um rund 30 % teurer, Hintergründe zu den explodierten RAM-Preisen gab es in allesnurgecloud Ausgabe 225. Am 15. Juni 2026 folgte die nächste Runde, und die trifft die Cloud-Instanzen mit dedizierter vCPU am stärksten. Die Preise laut Hetzner für Deutschland und Finnland, inklusive 19 % MwSt. und ohne IPv4:

• CCX23 (4 dedizierte vCPUs, 16 GB RAM, 160 GB NVMe): von 37,47 € auf 102,33 € im Monat, also fast das Dreifache.

• CCX33 (8 dedizierte vCPUs, 32 GB RAM, 240 GB NVMe): von 74,36 € auf 164,80 €.

• CX23: von 4,75 € auf 6,53 €.

• CX33: von 7,72 € auf 10,10 €.

Die neuen Preise gelten für Neubestellungen und für das Rescaling bestehender Instanzen. Laufende Server behalten ihren bisherigen Preis. Wer eine alte CCX-Instanz vergrößert, zahlt danach aber den neuen Tarif, und laut Hetzner-FAQ gilt das auch bei bestimmten anderen Änderungen am Server. Bestandsmaschinen sollte man also nicht leichtfertig anfassen.

Die geteilten CX-Instanzen sind vergleichsweise moderat gestiegen. Nur sind genau diese günstigen Größen derzeit an vielen Standorten kaum zu bekommen.

Jetzt der Vergleich, der sich lohnt. Ein AX42 kostet seit Juni 115,79 € im Monat plus 58,31 € Setup-Gebühr. Dafür gibt es einen Ryzen 7 PRO 8700GE mit acht physischen Kernen und 16 Threads, 64 GB DDR5-RAM mit ECC und zwei NVMe-SSDs mit je 512 GB. Die CCX33 hat acht dedizierte vCPUs, also acht Threads, dazu 32 GB RAM und 240 GB Speicher, und kostet 164,80 €. Selbst wenn man die beiden SSDs im AX42 als RAID 1 betreibt und nur 512 GB nutzbar bleiben, hat der dedizierte Server doppelt so viel RAM, gut doppelt so viel Speicher, ECC und lokale NVMe ohne IOPS-Limit. Und er kostet rund 49 € weniger im Monat.

Noch günstiger wird es mit Hetzners limitierten Angeboten. AX41 und EX44 gibt es dort für 68,19 € im Monat ohne Setup-Gebühr, den AX42 für 91,99 €. Laut Hetzner besteht diese Hardware aus günstiger beschafften Komponenten, die Verfügbarkeit hängt vor allem von Kündigungen ab. Man darf also davon ausgehen, dass diese Server häufig schon eine Weile gelaufen sind. Dazu kommt die Serverbörse, in der sich die Preise per Auktion ergeben und die von der Juni-Anpassung laut Hetzner nicht betroffen ist. In beiden Fällen lohnt sich der Abnahme-Check, den wir weiter unten beschreiben.

Bleibt noch die Verfügbarkeit. Mitte August hat der Hetzner-Shop die CCX-Instanzen als nicht bestellbar angezeigt, und auch die kleinen CX-Größen waren an den meisten Standorten knapp. Der beste Preis hilft wenig, wenn man die Maschine nicht bekommt. Bei dedizierten Servern ist die Lieferzeit planbar, und aus der Serverbörse steht ein Server oft noch am selben Tag bereit.

Zwei Einschränkungen gehören zur Rechnung dazu. Sie gilt für Dauerlast. Wer Maschinen nur stundenweise braucht, sie nach einem Lasttest wieder löscht oder regelmäßig zwischen Regionen verschiebt, ist in der Cloud weiterhin besser aufgehoben, dafür ist sie gebaut. Außerdem gehört die Setup-Gebühr in die Kalkulation. Im Vergleich zur CCX33 ist sie nach gut einem Monat wieder drin, bei kleineren Maschinen oder kurzer Laufzeit sieht das anders aus.

Unser Rat: Wer gerade eine Cloud-Instanz mit dedizierter CPU zum neuen Preis bestellen oder hochskalieren will, sollte vorher nachsehen, was es für das gleiche Geld als dedizierte Maschine gibt.

Hardware-Monitoring: Temperaturen, Leistungsaufnahme, Lüfter

Ob dedizierte Hardware eine gute Idee ist, hängt vor allem davon ab, ob man sie im Blick hat. Auf jedem unserer Hardware-Hosts läuft deshalb ein Skript, das im Minutentakt alle verfügbaren Sensordaten einsammelt und im Prometheus-Format ausgibt. Telegraf liest die Werte ein, gespeichert wird in VictoriaMetrics, dargestellt in Grafana.

Welche Quellen es gibt, erkennt das Skript pro Maschine selbst: IPMI bzw. das BMC, lm-sensors, die Thermal Zones des Kernels, hwmon, SMART und drivetemp für die Plattentemperaturen, ssacli für die RAID-Controller in den HPE ProLiants und nvidia-smi auf dem GPU-Host. Fehlt einer Maschine eine Quelle, meldet das Skript das als fehlende Capability. Im Dashboard sieht man so direkt, ob ein Sensor ausgefallen ist oder die Hardware ihn nie hatte.

Erfasst werden Temperaturen getrennt nach CPU, System, Platten, GPU, Netzteil und Chipsatz, außerdem die Leistungsaufnahme in Watt, Stromstärke und Spannungen, soweit das BMC sie liefert, und die Lüfterdrehzahlen. Der Stromverbrauch ist dabei ein guter Frühindikator. Zieht ein Server bei gleicher Last plötzlich mehr und drehen die Lüfter hoch, stimmt meistens etwas nicht, lange bevor eine Anwendung langsamer wird.

Telegraf ruft die Tools über eine eng gefasste sudo-Regel auf. Erlaubt sind nur namentlich aufgeführte Kommandos, und auch die Kernelmodule, die geladen werden dürfen, sind einzeln aufgelistet. Das Monitoring soll schließlich nicht selbst zum Sicherheitsrisiko werden. Die Alarmierung inklusive RAID-Check läuft über Icinga2, Grafana nutzen wir für die Verläufe.

Abnahme-Check vor der Inbetriebnahme

Laufendes Monitoring hilft bei Maschinen, die bereits in Betrieb sind. Neue und gebrauchte Server prüfen wir vorher mit einem zweiten Skript. Es erstellt einen vollständigen Hardware- und Disk-Health-Report, bevor ein Server in Produktion geht, zum Beispiel wenn er aus der Serverbörse kommt.

Zuerst liest das Skript das Inventar aus: Hersteller, Modell, Mainboard, BIOS-Version und -Datum, CPU sowie jedes Speichermodul einzeln mit Bestückung, Typ und Takt. Außerdem prüft es, ob ECC tatsächlich aktiv ist. Danach folgen die Werte, bei denen es unangenehm werden kann.

• ECC-Fehler: Das Skript liest die Fehlerzähler aus EDAC. Korrigierbare Fehler sind ein Grund, das Modul zu beobachten, unkorrigierbare sind kritisch. Auf einer VM bekommt man diese Werte nie zu sehen.

• SMART: Für NVMe und SATA/SAS gelten unterschiedliche Regeln. Bei NVMe schauen wir auf die verbrauchte Endurance in Prozent, die verbleibenden Reserve-Blöcke, Media Errors, Critical-Warning-Flags und die geschriebene Datenmenge. Bei SATA sind es reallozierte, schwebende und nicht korrigierbare Sektoren sowie CRC-Fehler, die meistens vom Kabel und nicht von der Platte kommen. Darauf weist das Skript auch hin. Dazu kommt der herstellerabhängige Verschleißindikator.

• Betriebsstunden: Umgerechnet in Jahre. Bei gebrauchter Hardware ist das der erste Wert, auf den wir schauen.

• RAID und Kernel-Log: Status von mdadm und ZFS sowie Storage-Fehler im Kernel-Log.

Am Ende steht eine Bewertung in drei Stufen, ausgegeben als Nagios-Exit-Code: in Ordnung, nutzbar aber beobachten, oder nicht abnehmen und nicht in Produktion nehmen. Außerdem kann das Skript auf allen Platten einen SMART-Selbsttest starten und meldet, wenn auf einer Platte noch nie einer gelaufen ist. Gerade bei günstiger Hardware aus der Serverbörse spart uns das einige böse Überraschungen.

Drei Beispiele aus unserem Betrieb

Server im Lager: Für KRUU betreuen wir fünf Server in den Fulfillment-Centern in Europa und den USA, teilweise ältere HPE ProLiants. Sie stehen direkt am Lager, damit der Warenausgang auch dann weiterläuft, wenn die Internetverbindung weg ist, und damit Scanner und Drucker lokal angebunden sind. Darauf laufen Docker, Node.js-Anwendungen, GitLab Runner und RabbitMQ, fluent-bit schickt die Logs an ein zentrales Logging. Angebunden sind die Server per Site-to-Site-VPN, verwaltet werden sie mit demselben Ansible wie alle anderen Maschinen. Ein Lager ist natürlich kein Rechenzentrum, Staub, Temperatur und Stromversorgung sind dort echte Themen. Deshalb haben wir bei diesen Servern die Temperaturen und Lüfterdrehzahlen besonders im Blick.

Bare Metal als Standard: Ein Kunde mit größerem Serverbestand betreibt auf dedizierter Hardware seine Anwendungsserver, MySQL Primary und Replica auf getrennten Maschinen, einen ClickHouse-Server und Elasticsearch. Cloud-VMs nutzt er zusätzlich, allerdings nur dort, wo es um Nähe zu den Nutzern geht und nicht um Rechenleistung. Das ist bei uns das typische Muster: dedizierte Hardware für Dauerlast und Datenbanken, VMs dort, wo Standort oder kurze Laufzeit wichtig sind.

Unsere eigene Backup-Infrastruktur: Zwei dedizierte Server mit vielen Platten an zwei Standorten, darauf SeaweedFS als S3-kompatibler Objektspeicher und VictoriaLogs. Die Backups unserer Kunden landen also auf eigener Hardware und nicht im Object Storage eines Drittanbieters. Für diesen Zweck ist dedizierte Hardware schlicht am wirtschaftlichsten: viel Speicher pro Euro und keine Abruf- oder Traffic-Kosten, die mit der Nutzung steigen.

Häufige Einwände

• „Was ist, wenn eine Platte ausfällt?“ Das passiert irgendwann. Dafür gibt es RAID, SMART-Trends über einen längeren Zeitraum und Backups an einem anderen Standort. Entscheidend ist, dass man den Ausfall kommen sieht und der Wiederanlauf geübt ist.

• „Ohne Snapshots kann man nichts zurückrollen.“ Stimmt. Ein Snapshot hilft allerdings nur bei eigenen Fehlern, bei einem Hardwaredefekt bringt er nichts. Dafür braucht man ohnehin ein Backup, und zusammen mit einem vollständig in Ansible beschriebenen Host ist der Restore gut planbar.

• „Wer fährt nachts ins Rechenzentrum?“ Niemand. Wir arbeiten mit Fernwartung über BMC bzw. iLO, dem Rescue-System und dem Remote-Hands-Service des Anbieters. Steht die Hardware beim Kunden vor Ort, muss das vorher geklärt sein, inklusive Ersatzteilen vor Ort und klarer Zuständigkeit.

• „Gebrauchte Hardware aus der Serverbörse?“ Dafür haben wir den Abnahme-Check. Passen Betriebsstunden, Verschleiß oder ECC-Fehler nicht, oder ist nie ein Selbsttest gelaufen, nehmen wir die Maschine nicht ab.

• „Wir sind zu klein für eigene Server.“ Unsere Erfahrung ist eher umgekehrt. Bei planbarer Dauerlast wie Datenbanken, Backups oder Analytics rechnet sich dedizierte Hardware oft früher als gedacht. Die Elastizität der Cloud bringt nur dann etwas, wenn man sie auch nutzt.

Dedizierte Server ohne eigenen Betriebsaufwand

Wir betreiben dedizierte Server und Cloud-VMs mit denselben Ansible-Rollen, Monitoring und Backups, als Managed Dedicated Server, anbieterunabhängig und mit 24/7-Bereitschaft. Dazu gehören die Abnahme neuer Hardware, die Überwachung von Temperatur und Stromverbrauch, RAID- und SMART-Trends sowie regelmäßig getestete Restores.

Du überlegst, ob sich dedizierte Hardware für deine Last lohnt?
Schreib uns, wir rechnen den Vergleich gerne durch. Auch dann, wenn am Ende die Cloud-VM die bessere Wahl ist.