Was tun, wenn 2026 bei einer Burst-Cloud-VM die CPU-Credits aufgebraucht sind?

Dieser Beitrag richtet sich an Verantwortliche für den Cloud-Betrieb, die anhand überprüfbarer Metriken eine Leistungseinbuße untersuchen müssen. Er eignet sich ebenso für Budgetverantwortliche und Teams, die Website, API oder Datenbank auf eine andere Ressourcengrundlage stellen möchten.

Symptome und Modellgrenzen einer Burst-Cloud-VM

Eine Burst-Cloud-VM kann für kurze Lastspitzen zusätzliche CPU-Leistung bereitstellen, während ihr Basiswert darunterliegt. Das Credit-Modell beschreibt, wie ein bestimmter Instanztyp Guthaben aufbaut und verbraucht. Credits sind dabei weder eine allgemeine Eigenschaft jeder virtuellen Maschine noch ein plattformübergreifend einheitlicher Mechanismus. Die Dokumentation zum CPU-Credit-Modell der B-Serie beschreibt die Regeln für diese konkrete Serie. Andere Anbieter und Instanzfamilien verwenden eigene Modelle und Begriffe.

Deshalb bedeutet ein niedriger Credit-Stand nicht automatisch, dass ein Dienst bereits gedrosselt wird. Entscheidend ist, welches Verhalten die Dokumentation für genau die eingesetzte Instanz festlegt. Ein Modell kann die Leistung nach Verbrauch des Guthabens auf die Basisleistung zurückführen. Ein anderes kann Betriebsmodi, zusätzliche Gebühren oder abweichende Regeln vorsehen. Die Erläuterung zu Burst-Credits und Basisleistung gilt für die dort beschriebenen Instanzen, nicht für sämtliche Cloud-VMs.

Prüfen Sie zuerst im Portal oder in der Inventarliste den genauen Instanztyp und lesen Sie dessen Credit-Regeln nach. Verlassen Sie sich nicht darauf, dass eine Bezeichnung wie „Burst“ allein bereits verrät, was nach dem Verbrauch geschieht. Besonders wichtig ist, ob die Instanz im Standardmodus läuft oder eine abweichende Einstellung verwendet: Die Beschreibung des Standardmodus für Burst-Instanzen erläutert ein konkretes plattformspezifisches Verhalten.

CPU-Credits sind außerdem nicht dasselbe wie CPU-Steal-Zeit. Ein Credit-Modell steuert die Nutzung zusätzlicher CPU-Leistung gemäß den Regeln des Instanztyps. Steal-Zeit verweist dagegen auf CPU-Zeit, die der VM nicht zur Verfügung steht, obwohl Prozesse sie benötigen. Auch Speicherdruck, langsame Datenträger und Netzwerkengpässe können ähnliche Symptome erzeugen. Diese Ursachen sollten getrennt geprüft werden, statt aus einer einzelnen Kurve auf die Ursache zu schließen.

Messwerte und Anwendungsreaktion gemeinsam prüfen

Suchen Sie im Monitoring nach dem Credit-Stand und dem Credit-Verbrauch, sofern Ihr Anbieter diese Metriken für die verwendete Instanz bereitstellt. Ergänzen Sie CPU-Auslastung und – soweit vorhanden – die zugehörigen Überschuss- oder Kostenmetriken. Namen, Verfügbarkeit und Bedeutung unterscheiden sich zwischen Plattformen und Instanztypen. Eine Referenz für VM-Metriken und deren Bedeutung hilft, Messwerte der jeweils dokumentierten Umgebung einzuordnen. Für eine andere Plattform beschreibt die Metrikdokumentation zur Credit-Anzeige die entsprechenden Credit-Messwerte für unterstützte Instanzen.

Vergleichen Sie die Kurven mit Daten aus der Anwendung: Antwortzeit, Fehlerrate, Warteschlangenlänge, Zahl gleichzeitiger Anfragen und Datenbanklast. Die folgende Tabelle ist ein Arbeitsblatt, kein vorgegebener Grenzwert. Tragen Sie für dasselbe Zeitfenster den Credit-Verlauf und die Geschäftsauswirkung ein.

Für eine belastbare Einordnung müssen die Zeitstempel zusammenpassen. Ein Credit-Abfall, der erst nach dem Beginn der langen Antwortzeiten einsetzt, ist ein anderer Hinweis als ein vorheriger Guthabenverbrauch bei gleichzeitig wachsender CPU-Last. Prüfen Sie auch, ob das Monitoring Daten lückenlos erfasst. Eine fehlende Messreihe ist kein Beleg dafür, dass die Ressource unbelastet war.

Die Plattformdokumentation kann die verfügbaren Messwerte und deren Definitionen festlegen. Ergänzend zeigen die Definitionen für Monitoring-Metriken, dass Metriknamen und Eigenschaften aus dem jeweiligen Ressourcenkontext ermittelt werden müssen. Übertragen Sie Namen aus einem anderen VM-Typ daher nicht ungeprüft.

Ursachen vor einer Änderung eingrenzen

Ein sinkender Credit-Stand kann mit einer dauerhaft hohen CPU-Last zusammenhängen, erklärt aber noch nicht, welcher Prozess diese Last verursacht oder ob sie die beobachtete Störung auslöst. Vergleichen Sie Anwendungsprotokolle, Betriebssystemmetriken und Geschäftszeiten. Eine passende Plattformanleitung zur Untersuchung hoher CPU-Auslastung auf einer VM bietet eine ergänzende Vorgehensweise für die dort beschriebene Umgebung.

Arbeiten Sie die Prüfung in dieser Reihenfolge ab:

1. CPU-Verbrauch lokalisieren: Ermitteln Sie, ob ein Prozess dauerhaft CPU-Zeit beansprucht oder ob nur kurze Spitzen auftreten. Ordnen Sie die Prozesse konkreten Diensten, Anfragen oder Hintergrundaufgaben zu.
2. Zeitliche Auslöser abgleichen: Prüfen Sie Deployments, geplante Wartung, Importe, Backups und zeitgesteuerte Jobs. Ein regelmäßig startender Prozess kann die Credits auch dann verbrauchen, wenn der normale Webverkehr unauffällig ist.
3. Traffic und Parallelität untersuchen: Vergleichen Sie Anfragen, gleichzeitige Verbindungen und Antwortzeiten. Ein Anstieg der Last kann durch mehr Nutzung, eine Änderung im Clientverhalten oder eine ineffiziente Anfrage entstehen.
4. Andere Ressourcen ausschließen: Prüfen Sie Arbeitsspeicher, Datenträgerlatenz und Netzwerk. Bei Speichermangel können Prozesse ausgelagert werden; bei Datenträgerengpässen kann die Anwendung langsam reagieren, obwohl die CPU nicht ausgelastet ist.
5. Datenbank und Warteschlangen einbeziehen: Suchen Sie nach langsamen Abfragen, wachsender Queue und blockierten Jobs. Wenn die Datenbank wartet, lässt sich eine langsame Anwendung nicht automatisch durch mehr CPU lösen.
6. Änderungen einzeln bewerten: Legen Sie fest, welcher einzelne Eingriff getestet wird, und halten Sie Ausgangswerte sowie Rückkehrbedingungen fest. Ändern Sie mehrere Ressourcen nicht gleichzeitig, wenn sich die Wirkung anschließend nicht zuordnen lässt.

Diese Reihenfolge verhindert, dass ein Symptom vorschnell zur Ursache erklärt wird. Besonders bei Datenbanken kann eine höhere CPU-Auslastung sowohl Auslöser als auch Folge wachsender Arbeit sein. Prüfen Sie, ob Last und Credit-Verbrauch zeitlich vorausgehen oder ob sich die Reihenfolge umgekehrt darstellt.

Optionen nach Lastprofil und Abrechnung vergleichen

Ein Credit-Stand, der wiederholt sinkt, ist ein Anlass zur Prüfung, aber keine automatische Aufforderung zum Wechsel. Entscheidend ist, ob die Anwendung überwiegend kurze Spitzen hat oder im Normalbetrieb anhaltend CPU benötigt. Für die Kostenbewertung verwenden Sie denselben Abrechnungszeitraum und beziehen neben dem VM-Preis auch Speicher, Datenträger, ausgehenden Datenverkehr, öffentliche IP-Adressen, Backups und gegebenenfalls zusätzliche Credit-Kosten ein. Preise müssen aus den offiziellen Tarifseiten für die tatsächlich eingesetzte Region und den betreffenden Zeitraum stammen.

Die Tabelle ersetzt keine Preisabfrage. Für eine faire Gegenüberstellung dokumentieren Sie die verwendete Region, den konkreten Instanztyp, den beobachteten Verbrauch und die Rechnungsperiode. Ziehen Sie keine pauschalen Aussagen aus einem Listentarif, wenn Ihr tatsächlicher Vertrag oder die Abrechnung abweicht. Bei einem Betriebsmodus mit Zusatzabrechnung müssen auch dessen dokumentierte Regeln berücksichtigt werden; die Beispiele zur Abrechnung im Unlimited-Modus gelten für den dort beschriebenen Dienst und sind keine allgemeine Preisregel.

Nutzen Sie diese Entscheidungsbedingungen, bevor Sie eine Änderung freigeben:

• Wenn die VM laut offizieller Dokumentation Credits verwendet, dann prüfen Sie Credit-Stand, Verbrauch, CPU-Auslastung und Anwendungsreaktion über dasselbe Zeitfenster.
• Wenn die Leistungseinbuße nicht zeitlich mit Credit-Verbrauch und CPU-Last zusammenfällt, dann untersuchen Sie zuerst Anwendung, Speicher, Datenträger und Netzwerk.
• Wenn kurze Spitzen auftreten und die VM sich in ruhigeren Phasen erholt, dann vergleichen Sie die Kosten des unveränderten Betriebs mit einer passenden Cloud-Alternative, bevor Sie migrieren.
• Wenn der Bedarf regelmäßig über der Basisleistung liegt, dann vergleichen Sie eine größere oder fest dimensionierte Cloud-Variante mit den Kosten eines dedizierten Servers.
• Wenn starke Elastizität, mehrere Regionen oder eng integrierte verwaltete Dienste unverzichtbar sind, dann behalten Sie diese Komponenten zunächst in der Cloud und bewerten Sie höchstens eine Teilmigration.
• Wenn Ressourcenbedarf und Last stabil sind und das Team Sicherung, Wiederherstellung und Wartung verantworten kann, dann beziehen Sie unabhängige Servermiete in den Vergleich ein.

Bei Fragen zur Preisbasis können Sie die Abrechnungsinformationen für Servermiete für den Produktvergleich heranziehen. Für die Berechnung selbst sind die aktuell angezeigten Produktdaten maßgeblich; übernehmen Sie keine Beträge aus einem älteren Angebot oder aus einer anderen Region.

Betrieb und Migration verantwortbar vorbereiten

Eine virtuelle Maschine zu ersetzen ist nicht allein eine CPU-Entscheidung. Vor einer Migration müssen Anwendung, Daten und Wiederherstellung gemeinsam betrachtet werden. Ein dedizierter Server bedeutet exklusive physische Ressourcen, aber nicht automatisch Hochverfügbarkeit, externe Sicherungen, verwaltete Datenbanken oder einen Bereitschaftsdienst. Diese Aufgaben bleiben Teil der Betriebsplanung, sofern sie nicht gesondert geregelt sind.

Erstellen Sie vor der Entscheidung eine abhakbare Bestandsaufnahme:

• [ ] Abhängigkeiten erfasst: Anwendung, Datenbank, Queue, DNS, Zertifikate, externe APIs und verwaltete Cloud-Dienste sind dokumentiert.
• [ ] Ressourcenbedarf gemessen: CPU, Arbeitsspeicher, Datenträgerkapazität, Ein-/Ausgabe und Netzwerk sind aus repräsentativen Betriebsphasen abgeleitet.
• [ ] Datenübernahme geplant: Umfang, Konsistenzanforderungen und erlaubtes Wartungsfenster sind festgelegt.
• [ ] Sicherung und Wiederherstellung geprüft: Es gibt eine Kopie außerhalb des Zielsystems sowie einen nachvollziehbaren Wiederherstellungsablauf.
• [ ] Verantwortung zugewiesen: Zuständigkeiten für Betriebssystemupdates, Überwachung, Fehlerbehebung und Hardwareausfall sind geklärt.
• [ ] Rückweg vorbereitet: Für DNS, Anwendungsversion und Datenbank gibt es einen getesteten Rückfallplan.
• [ ] Netzwerk und Datenschutz bewertet: Zugriffswege, Datenstandort, Aufbewahrung und Anforderungen aus der DSGVO sind geprüft.

Eine starke Abhängigkeit von verwalteten Plattformdiensten kann gegen eine vollständige Migration sprechen. Das gilt ebenso für stark schwankende Last, bei der kurzfristiges automatisches Skalieren wesentlich ist, oder für Anforderungen an mehrere aktive Regionen. In solchen Fällen kann eine Hybridlösung sinnvoller sein: stabile Komponenten werden separat bewertet, während elastische oder eng gekoppelte Dienste vorerst dort bleiben, wo ihre Abhängigkeiten bereits erfüllt sind.

Für eine schrittweise Änderung sollte zuerst ein repräsentativer Teil der Last in einer Testumgebung oder mit einer kontrollierbaren Umschaltung geprüft werden. Definieren Sie vorher messbare Abnahmekriterien, etwa die zulässige Antwortzeit, Fehlerquote, Queue-Entwicklung und Wiederherstellbarkeit. Vergleichen Sie diese Werte mit dem bisherigen Betrieb unter ähnlichen Bedingungen. Ohne einen solchen Vergleich lässt sich weder eine Leistungsverbesserung noch eine Kostenersparnis belastbar behaupten.

Änderungsentscheidung mit einem überprüfbaren Test absichern

Legen Sie vor dem Test fest, welche Frage beantwortet werden muss: Reicht eine geänderte Cloud-VM aus, ist eine fest dimensionierte Variante geeigneter oder passt eine Migration zum dedizierten Betrieb? Halten Sie den bisherigen Zustand, die geplante Änderung und die Rückkehrbedingungen schriftlich fest. Die Anleitung zum Konfigurieren von Credit-Einstellungen beschreibt Einstellungen für die dort unterstützten Instanzen; sie ist nicht ohne Prüfung auf andere Plattformen übertragbar.

Führen Sie den Vergleich so durch, dass die Messwerte interpretierbar bleiben:

1. Erfassen Sie unter der bestehenden Konfiguration CPU-Auslastung, Credit-Verlauf, Antwortzeiten, Fehler und relevante Datenbankwerte.
2. Wählen Sie eine repräsentative Arbeitslast und halten Sie Änderungen an Anwendung und Datenbestand während des Vergleichs möglichst konstant.
3. Ändern Sie nur die zu prüfende Ressource oder den Betriebsmodus und protokollieren Sie Zeitpunkt sowie Rollback-Schritt.
4. Vergleichen Sie die Messreihen unter ähnlichen Lastbedingungen; dokumentieren Sie Abweichungen, die den Vergleich beeinflussen.
5. Prüfen Sie neben der Leistung auch Rechnung, Betriebsaufwand, Sicherungsweg und Wiederherstellung.
6. Erweitern Sie die Änderung nur, wenn die zuvor festgelegten Kriterien erfüllt sind und die Verantwortlichen den Rückfallweg akzeptieren.

Für eine unabhängige Serveroption können Sie die Konfigurationsübersicht für Server als Ausgangspunkt für die Prüfung der verfügbaren Ressourcen verwenden. Vergleichen Sie die dort aktuell angezeigten Konfigurationen mit dem gemessenen Bedarf, nicht mit einem aus dem Cloud-Instanznamen abgeleiteten CPU-Versprechen. Technische Eignung und Preis müssen beide anhand der konkreten Produktangaben geprüft werden.

Zuletzt aktualisiert am 02.11.2026; fachlich abgeglichen mit den verlinkten offiziellen Dokumentationen zu CPU-Credit-Modellen, Monitoring und Credit-Einstellungen. Die Regeln gelten jeweils nur für die dokumentierte Plattform und Instanzfamilie; bei einer Änderung der Metrikdefinition oder des Credit-Verhaltens ist die Prüfung zu wiederholen.

Wenn die Messungen einen stabilen, dauerhaft benötigten Ressourcenbedarf zeigen, kann die Miete eines dedizierten AMD-Servers von XFP Cloud eine passende Alternative sein. Sie beseitigt jedoch weder die Pflicht zu Sicherung und Wiederherstellung noch macht sie eine Migration automatisch wirtschaftlicher. Stimmen Sie daher zuerst Lastprofil, Betriebsverantwortung und Gesamtkosten ab und nutzen Sie anschließend die aktuellen Konfigurations- und Preisangaben von XFP Cloud für den konkreten Vergleich.