2026: Wie schätzen Sie vor der Cloud-Migration die Konfiguration eines dedizierten Servers?

Messwerte statt Cloud-Sollwerte: der erste Entscheidungspunkt

Eine offizielle Anleitung zur Bewertung von Cloud-Arbeitslasten nennt CPU, Arbeitsspeicher, Speicher und Netzwerk als vier zentrale Ressourcenkategorien, die vor der Zielplanung betrachtet werden sollen (Migrationsbewertung und Erfassung von Arbeitslasten). Daraus folgt die wichtigste Regel für die Konfiguration eines dedizierten Servers vor der Cloud-Migration: Übernehmen Sie die gebuchten vCPU- und RAM-Werte nicht ungeprüft. Leiten Sie den Bedarf aus Messungen während repräsentativer Betriebsphasen ab, ordnen Sie Spitzen und Engpässe ein und berücksichtigen Sie Abhängigkeiten sowie Wiederherstellungsanforderungen. Bei stark schwankender Last oder einer zwingenden Abhängigkeit von verwalteten Diensten ist eine Teilmigration oder ein gemischter Betrieb oft die bessere Prüfung als das Zusammenziehen aller Ressourcen auf einer Maschine.

Dieser Ablauf richtet sich an technische Verantwortliche, die stabile Web- oder API-Dienste umziehen und vor der Auswahl eine belastbare Lastbasis benötigen.
Betriebsteams mit Datenbanken oder Warteschlangen müssen zusätzlich Arbeitsspeicher, Speicher-I/O und Wiederherstellung betrachten.
Für die Budgetplanung lassen sich mit den Tabellen unten Annahmen, offene Fragen und Angebotsoptionen getrennt dokumentieren.

Meilenstein 1: Umfang und Abhängigkeiten abgrenzen

Vor dem Sammeln von Messwerten muss klar sein, welche Dienste überhaupt in die Bewertung gehören. Eine gemeinsame Durchschnittszahl für Web-Frontend, Datenbank, Warteschlange und interne Werkzeuge kann genau die Unterschiede verdecken, die bei der Dimensionierung entscheidend sind. Legen Sie deshalb für jeden Dienst einen eigenen Eintrag an und notieren Sie, welche Komponenten mit ihm kommunizieren und welche außerhalb des geplanten Umzugs bleiben.

Die Abgrenzung sollte mindestens diese Punkte enthalten:

• Anwendung und Rolle: Web, API, Datenbank, Warteschlange, Hintergrundverarbeitung oder internes System.
• Abhängigkeiten: Verwaltete Datenbanken, Serverless-Funktionen, verwaltete Warteschlangen, externe Identitätsdienste, Objektspeicher oder andere Dienste, die nicht ohne Weiteres auf eine eigene Maschine übertragbar sind.
• Betriebsanforderung: Welche Dienste müssen dauerhaft verfügbar sein, welche dürfen ein Wartungsfenster haben und welche sind nur für Tests erforderlich?
• Lastprofil: Gleichmäßige Grundlast, planbare Spitzen, kurzfristige Ausschläge oder stark saisonale Nutzung.
• Datenverantwortung: Speicherort, Sicherungsverfahren, Wiederherstellung und Zuständigkeit im Fehlerfall.

Starke Elastizität, mehrere benötigte Regionen oder eine tiefe Bindung an verwaltete Dienste sind keine nebensächlichen Details: Sie können eine vollständige Migration ungeeignet machen, auch wenn die Rohressourcen auf einem Server verfügbar wären. Halten Sie diese Teile als Kandidaten für den Verbleib in der Cloud oder für einen gemischten Betrieb fest. Eine solche Abgrenzung verhindert außerdem, dass ein einzelner Maschinenbedarf mit Anforderungen verwechselt wird, die nur durch eine verteilte Architektur erfüllt werden.

Meilenstein 2: Eine repräsentative Lastbasis erheben

Die Cloud-Migration-Konfiguration eines dedizierten Servers lässt sich nur dann sinnvoll abschätzen, wenn die Messungen den tatsächlichen Betrieb abbilden. Die vorhandene Zuweisung ist kein Verbrauchswert: Eine Instanz kann mehr CPU oder Arbeitsspeicher erhalten haben, als die Anwendung dauerhaft nutzt. Umgekehrt kann eine niedrige mittlere Auslastung kurze, geschäftlich wichtige Spitzen verschleiern.

Erfassen Sie je Dienst mindestens CPU-Auslastung, belegten und verfügbaren Arbeitsspeicher, Speicherbelegung sowie Lese- und Schreibaktivität und Netzwerkdurchsatz. Notieren Sie daneben die Antwortzeiten, Fehler, Warteschlangenlängen oder andere Anwendungsindikatoren. Die Ressourcenzahlen allein sagen nicht, ob die Anwendung gesund ist: Eine hohe CPU-Auslastung kann zu einem geplanten Batch gehören; eine mäßige Auslastung kann trotzdem mit einer schlechten Antwortzeit einhergehen.

Welche Messdaten gehören in die Baseline?

Die offizielle Bewertungsanleitung für Migrationen empfiehlt, Arbeitslasten anhand ihrer Ressourcennutzung zu untersuchen und die Zielplanung daraus abzuleiten (Leitfaden zur Bewertung und Erfassung von Arbeitslasten). Für die Erhebung bedeutet das: Messgröße, Zeitraum, Quelle und Kontext gehören zusammen. Ein Wert ohne Zeitstempel und Betriebsereignis ist schwer zu interpretieren.

Dokumentieren Sie für jeden Messsatz:

• den Beginn und das Ende des Beobachtungszeitraums;
• ob die Erhebung einen typischen Geschäftstag, bekannte Spitzen, Monatsabschluss oder Wartungsarbeiten umfasst;
• die verwendete Auflösung und den Speicherort der Metriken;
• geplante Jobs, Deployments, Störungen und Änderungen an der Anwendung;
• ob der Messwert ein Mittelwert, ein Maximum oder ein zeitlicher Verlauf ist.

Prometheus empfiehlt für Metriken eine konsistente Instrumentierung mit klarer Bedeutung und geeigneten Labels; die Praxisempfehlungen zur Instrumentierung helfen dabei, Messreihen später nach Dienst und Betriebsbereich auszuwerten. Übernehmen Sie dabei keine unnötigen personenbezogenen Inhalte in Labels oder Logs. Für deutsche und europäische Betriebsumgebungen ist es sinnvoll, Erhebung, Zugriff und Aufbewahrung auch mit den internen Datenschutzvorgaben und der DSGVO abzugleichen.

Reichen die zugewiesenen vCPU und der Arbeitsspeicher als Vorlage?

Nein. Die zugewiesenen Cloud-Ressourcen zeigen, welche Obergrenze oder gebuchte Größe bereitsteht, nicht automatisch, was die Anwendung tatsächlich benötigt. Prüfen Sie die Nutzung zusammen mit Antwortzeiten, Fehlern und Warteschlangen. Bleibt eine Ressource dauerhaft weit unter ihrer Zuweisung, kann das auf Reserven oder eine überdimensionierte Instanz hindeuten; eine knappe Zuweisung ohne sichtbare Probleme kann dagegen auf eine geringe Last im Beobachtungszeitraum oder auf versteckte Engpässe hinweisen.

Verwechseln Sie zudem unterschiedliche Kennzahlen nicht: CPU-Auslastung, verfügbare Speicherkapazität und tatsächlich genutzter Arbeitsspeicher beantworten verschiedene Fragen. Bei einer Datenbank ist etwa relevant, ob der aktive Arbeitsbestand in den Arbeitsspeicher passt und wie sich Speicherzugriffe bei einer realen Abfrage verhalten. Für die spätere Server-Kapazitätsplanung reicht es deshalb nicht, einen einzelnen Prozentsatz aus dem Monitoring zu kopieren.

Meilenstein 3: Grundlast, Spitzen und Engpässe auseinanderhalten

Sobald die Messreihen vorliegen, wird jeder Ausschlag klassifiziert. Trennen Sie eine dauerhafte Grundlast von einer wiederkehrenden, erklärbaren Geschäftsspitze und von einem einmaligen Ausreißer. Ein einzelner kurzer Ausschlag durch Wartung oder einen fehlerhaften Job sollte nicht automatisch zur dauerhaften Konfigurationsanforderung werden. Wiederkehrende Spitzen, die Antwortzeiten oder Verarbeitung beeinträchtigen, dürfen umgekehrt nicht durch einen niedrigen Durchschnitt unsichtbar werden.

Die Zuordnung gelingt besser, wenn Messwerte mit Anwendungsereignissen zusammengeführt werden:

1. Markieren Sie Zeiträume mit erhöhtem CPU-Verbrauch und vergleichen Sie diese mit Antwortzeit, Jobdauer und Fehlerquote.
2. Prüfen Sie bei Speicherdruck, ob die Anwendung mehr Arbeitsspeicher anfordert, ob Auslagerung stattfindet und ob der Bedarf durch den normalen Arbeitsbestand oder durch einen einzelnen Prozess entsteht.
3. Stellen Sie bei Speicher-I/O fest, ob Durchsatz, Latenz oder Warteschlangen zeitgleich mit langsamen Abfragen oder verzögerten Jobs auffällig sind.
4. Ordnen Sie Netzwerkausschläge den verursachenden Diensten und Datenflüssen zu; unterscheiden Sie kontinuierlichen Verkehr von kurzen Transfers.
5. Halten Sie für jede Spitze fest, ob sie geschäftlich notwendig, wiederkehrend, vermeidbar oder noch ungeklärt ist.

Eine Zuordnung zwischen Ressource und Dienstverhalten ist wichtiger als das bloße Addieren von Maximumwerten. Die Leitlinie zu Zuverlässigkeitsmetriken unterstreicht, dass Metriken im Zusammenhang mit Zuverlässigkeit und dem beobachteten Dienstverhalten bewertet werden müssen. Damit wird aus „CPU war hoch“ eine prüfbare Aussage wie „Während der regulären Importverarbeitung stieg die CPU-Auslastung, während die Warteschlange anwuchs und die Bearbeitungszeit zunahm“.

Muss die Serverkonfiguration nach der Geschäftsspitze bemessen werden?

Die Zielkonfiguration muss die relevanten Spitzen abdecken, nicht jeden einmaligen Messwert. Eine vorhersehbare Spitze, die zu langsamer Verarbeitung oder nicht eingehaltenen Antwortzeiten führt, ist Teil des Bedarfs. Ein isolierter Ausreißer ohne Geschäftswirkung kann dagegen zunächst ein Diagnosepunkt bleiben. Legen Sie vor der Auswahl fest, welche Antwortzeit, Verarbeitungskapazität oder Warteschlangenentwicklung während eines Spitzenzeitraums akzeptabel ist.

Wenn die Spitze kurz, selten und stark ausgeprägt ist, prüfen Sie, ob sie durch zeitversetzte Verarbeitung, Begrenzung der Parallelität oder einen gemischten Betrieb aufgefangen werden kann. Eine einzelne Maschine bietet nicht automatisch dieselben Möglichkeiten zur kurzfristigen Skalierung wie eine elastische Cloud-Architektur. Ein pauschaler Aufschlag ohne Bezug zu Messdaten ist keine belastbare Kapazitätsplanung. Dokumentieren Sie stattdessen die beobachtete Spitze, ihren Grund und die Entscheidung, sie in der Zielplanung abzudecken oder architektonisch anders zu behandeln.

Meilenstein 4: Zielbedarf und Entscheidungsweg festlegen

Erstellen Sie aus der Auswertung eine Anforderungsliste mit Zielbereichen und Begründung. Wo die Messdaten lückenhaft sind, kennzeichnen Sie die Unsicherheit ausdrücklich, statt eine scheinbar genaue Zahl zu erfinden. Trennen Sie außerdem Kapazität von Ausfallsicherheit: Ein passender Arbeitsspeicherbedarf schützt nicht vor einem Datenträgerausfall, und ein schneller Speicher ersetzt keine externe Sicherung.

Die folgende Entscheidungstabelle stellt mögliche Wege gegenüber. Sie ersetzt keine Messung, sondern macht sichtbar, welche Befunde jeweils für eine weitere Prüfung sprechen.

Füllen Sie für jeden Dienst einen Zielbogen aus. Er sollte die bisherige Messung, die Begründung für das Ziel und offene Risiken gemeinsam abbilden:

• CPU: Grundlast, relevante Spitzen, zugehörige Anwendungsereignisse und gewünschtes Verhalten unter Last.
• Arbeitsspeicher: genutzter Speicher, aktiver Arbeitsbestand, Auslagerungsindikatoren und erwartete Veränderung.
• Speicher: belegte Kapazität, Wachstum, Lese- und Schreibmuster, I/O-Latenz und erforderliche Wiederherstellung.
• Netzwerk: kontinuierlicher Durchsatz, Spitzenverkehr, Datenübertragung zwischen Diensten und externe Kommunikationsabhängigkeiten.
• Betrieb: Sicherungsziel, Wiederherstellungsablauf, Überwachung, Zuständigkeit und zulässiges Wartungsfenster.

Wie lässt sich der ausreichende Arbeitsspeicher beurteilen?

Beziehen Sie nicht nur den aktuellen Verbrauch ein. Bei Datenbanken zählt, welcher Anteil des aktiven Arbeitsbestands häufig gebraucht wird; bei Anwendungsdiensten sind parallele Prozesse und kurzzeitige Spitzen relevant. Prüfen Sie, ob Speicherdruck mit längeren Antwortzeiten, häufigem Auslagern oder langsameren Abfragen zusammenfällt. Ein einzelner Wert „belegt“ reicht nicht, wenn unklar bleibt, ob der Verbrauch aus einem notwendigen Cache, einem wachsenden Datensatz oder einem fehlkonfigurierten Prozess stammt.

Vergleichen Sie die Messung über mehrere repräsentative Betriebsphasen und halten Sie die Annahme fest, die für Wachstum oder zusätzliche Aufgaben getroffen wird. Wenn die Messdaten keinen typischen Spitzenzeitraum enthalten, lautet das Ergebnis nicht „Speicherbedarf ist bestätigt“, sondern „Datenbasis unvollständig“. Diese Unterscheidung ist besonders wichtig, wenn eine Konfiguration später als Budgetgrundlage dient.

Meilenstein 5: Speicher, Wiederherstellung und Betrieb zusammen planen

Eine Zielmaschine ist erst dann plausibel dimensioniert, wenn auch die Datenrisiken berücksichtigt sind. Prüfen Sie, welche Daten wiederherstellbar sein müssen, wie lange eine Wiederherstellung dauern darf und wer den Ablauf praktisch ausführen kann. Eine lokale Spiegelung kann den Ausfall eines einzelnen Datenträgers abfangen, ist aber kein Ersatz für eine außerhalb der Maschine liegende Sicherung. Die Dokumentation zu Redundanz, Replikation und Sicherung erläutert, dass diese Verfahren unterschiedliche Schutzziele erfüllen; behandeln Sie sie deshalb nicht als austauschbare Begriffe.

Für jeden Dienst sollten Verantwortliche einen Wiederherstellungsweg festhalten: Wo liegt die Sicherung? Wie wird ihre Integrität geprüft? Welche Konfiguration und Zugangsdaten werden für den Wiederanlauf benötigt? Welche Abhängigkeiten müssen zuerst verfügbar sein? Wo nötig, gehört dazu auch ein Wiederherstellungstest in einer kontrollierten Umgebung. Ohne diese Angaben bleibt „Backup vorhanden“ eine unvollständige Aussage.

Auch der Betrieb nach der Migration benötigt eine klare Zuständigkeit für Updates, Überwachung, Speicherplatzkontrolle, Alarmierung und Störungsbearbeitung. Bei einer Cloud-Migration werden solche Aufgaben nicht automatisch mit der Hardwarekonfiguration erledigt. Wenn Datenschutzanforderungen gelten, sind Datenflüsse, administrative Zugriffe und Aufbewahrung gemeinsam mit dem vorgesehenen Betriebsmodell zu prüfen.

Meilenstein 6: Angebote abgleichen und Annahmen offenlegen

Vergleichen Sie einen Cloud-Ausgangszustand und einen Kandidaten für einen dedizierten Server anhand derselben Dienste und Zeiträume. Ein fairer Vergleich enthält keine Vermischung von Spitzenverbrauch auf der einen und Durchschnittswerten auf der anderen Seite. Falls Preise gegenübergestellt werden, müssen sie aus den jeweiligen aktuellen Angebots- oder offiziellen Abrechnungsinformationen stammen und Region, Zeitraum sowie erfasste Bestandteile nennen. Fehlen verlässliche Preise, halten Sie die Kostenpositionen als offene Prüfung fest, statt eine Einsparung zu behaupten.

Für die technische Angebotsprüfung empfiehlt sich eine kurze Liste:

• Sind CPU, Arbeitsspeicher, Speicher und Netzwerk anhand dokumentierter Messwerte begründet?
• Ist die erwartete Datenmenge einschließlich Wachstum und Sicherung getrennt betrachtet?
• Sind Durchsatzbedarf und Verkehrsrichtung beschrieben, statt nur eine Instanzgröße zu übernehmen?
• Ist klar, welche Cloud-Dienste verbleiben und wie ihre Schnittstellen erreichbar bleiben?
• Sind Betrieb, Sicherung, Wiederherstellung und Störungsbearbeitung personell abgedeckt?
• Sind die Messlücken und Annahmen sichtbar, damit spätere Änderungen nachvollziehbar bleiben?

Bei CloudUDP sollten die konkreten verfügbaren Konfigurationen und Abrechnungsoptionen direkt anhand der Tarifübersicht mit dieser Anforderungsliste abgeglichen werden. Die Übersicht ist der richtige Ort, um die aktuelle Angebotslage zu prüfen; aus einer allgemeinen Kapazitätsrechnung lässt sich keine bestimmte Konfiguration oder ein Preis ableiten. Vor einer Bestellung können die Angaben zusätzlich mit den Informationen im Bestellablauf abgeglichen werden.

Meilenstein 7: Nach dem Start die Schätzung validieren

Die erste Zielkonfiguration bleibt eine begründete Schätzung, bis reale Anwendungen darauf laufen. Legen Sie daher vor der Inbetriebnahme fest, welche Messwerte nach dem Umzug kontrolliert werden und welche Befunde eine Korrektur auslösen. Prüfen Sie die gleichen Ressourcenkategorien und Anwendungsindikatoren wie in der Ausgangsmessung. Erst dadurch wird erkennbar, ob eine Abweichung aus einer falschen Kapazitätsannahme, einer veränderten Datenverteilung oder einem noch nicht angepassten Dienst stammt.

Der Vergleich sollte mindestens diese Fragen beantworten:

• Entsprechen Antwortzeiten und Fehlerverhalten den vorab festgelegten Betriebszielen?
• Bleibt der Arbeitsspeicher bei typischer und relevanter Spitzenlast ausreichend, ohne dass sich Speicherdruck aufbaut?
• Entwickeln sich Speicherbelegung, I/O-Latenz und Netzwerkverkehr wie erwartet?
• Sind verbleibende Cloud-Abhängigkeiten erreichbar und ist ihr Ausfallverhalten verstanden?
• Funktionieren Sicherung und Wiederherstellung im vorgesehenen Ablauf?

Wenn ein Ergebnis außerhalb der vorher festgelegten Akzeptanzbedingungen liegt, wird nicht einfach weiter beobachtet, ohne eine Entscheidung zu treffen. Prüfen Sie zuerst Messfehler und Anwendungskonfiguration, danach die Ressourcenzuteilung und schließlich, ob der Dienst überhaupt für den vorgesehenen Betriebsort geeignet ist. Je nach Befund ist eine Anpassung, eine teilweise Rückverlagerung oder ein längerer Parallelbetrieb sachgerechter als das Festhalten an der ursprünglichen Planung.

Abschluss: Messbasis vor der Anbieterentscheidung

Cloud-Instanzen können mit variablen Abrechnungsbestandteilen, geteilten Ressourcen und zusätzlichen Abhängigkeiten verbunden sein; diese Eigenschaften sind jedoch nicht bei jedem Anbieter oder jeder Arbeitslast gleich ausgeprägt. Umgekehrt nimmt ein dedizierter Server nicht automatisch elastische Skalierung, verwaltete Datenbanken oder Mehrfachreplikation mit. Wer nur die Cloud-Zuweisung überträgt, riskiert deshalb sowohl eine unnötig große Zielkonfiguration als auch eine unzureichende Reserve bei kritischen Spitzen.

Für einen stabilen Dienst mit nachvollziehbarem Ressourcenprofil kann die Miete eines dedizierten AMD-Servers sinnvoll sein, wenn die Messwerte, die Betriebsverantwortung und die Wiederherstellung dazu passen. Bei CloudUDP sollte die Entscheidung erst nach dem Abgleich der erhobenen Zielbereiche mit der aktuellen Tarifübersicht fallen. Sind starke Elastizität oder verwaltete Dienste noch ungeklärt, bleibt zunächst die Abgrenzung der migrierbaren Komponenten der nächste Schritt, nicht die Auswahl einer Maschine.