AWS T3 Instanzen verstehen: CPU-Credits und plötzliche Performance-Einbrüche erklärt

Die Anwendung läuft stundenlang stabil, dann bricht die Performance ohne erkennbaren Grund ein — CPU-Auslastung bleibt hoch, aber der Durchsatz fällt auf ein Bruchteil des Normalen. Wer burstable T3 Instanzen betreibt, ohne das CPU-Credit-Modell zu verstehen, tappt bei diesem Symptom regelmäßig in die falsche Diagnoserichtung.

TL;DR: T3 Instanzen und CPU-Credits auf einen Blick

Aspekt	Verhalten
Baseline-CPU	Festgelegter Prozentsatz je Instanzgröße (z.B. t3.micro: 10%)
CPU-Credits	Werden bei Nutzung unter Baseline angesammelt, bei Überschreitung verbraucht
Credit-Erschöpfung	Instanz wird auf Baseline-CPU gedrosselt
Standard-Modus	Burst begrenzt durch verfügbare Credits
Unlimited-Modus	Burst über Credits hinaus möglich — zusätzliche Kosten entstehen
Diagnose-Metrik	CPUCreditBalance in CloudWatch

Wie das T3 CPU-Credit-Modell funktioniert

T3 Instanzen gehören zur Kategorie der burstable performance instances. Das Grundprinzip: Jede Instanzgröße hat eine definierte Baseline-CPU-Auslastung. Läuft die Instanz dauerhaft unter dieser Baseline, sammelt sie CPU-Credits an. Überschreitet sie die Baseline, werden Credits verbraucht. Sind keine Credits mehr vorhanden und läuft die Instanz im Standard-Modus, drosselt AWS die CPU-Leistung auf exakt die Baseline.

Credits werden pro vCPU pro Stunde gutgeschrieben, solange die tatsächliche CPU-Nutzung unter der Baseline liegt. Die genauen Baseline-Werte und Credit-Akkumulationsraten sind in der offiziellen AWS-Dokumentation für jeden Instanztyp dokumentiert — Pricing und exakte Limits sollten dort immer aktuell geprüft werden.

Das Credit-Modell verhält sich wie ein Prepaid-Konto für Rechenleistung: Wer spart, darf kurz mehr ausgeben. Wer dauerhaft über seine Verhältnisse lebt, wird ausgebremst.

Standard-Modus vs. Unlimited-Modus

T3 Instanzen starten standardmäßig im Unlimited-Modus — das ist ein wichtiger Unterschied zu T2. Im Unlimited-Modus kann die Instanz über das Credit-Guthaben hinaus bursten, was jedoch zusätzliche Kosten pro vCPU-Stunde über der Baseline verursacht. Im Standard-Modus ist der Burst strikt auf das vorhandene Credit-Guthaben begrenzt.

graph LR A["Instanz startet"] --> B["CPU unter Baseline"] B --> C["Credits akkumulieren"] C --> D{"Lastspitze?"} D -- Nein --> B D -- Ja --> E["Credits werden verbraucht"] E --> F{"Credits erschöpft?"} F -- Nein --> E F -- Ja --> G{"Instanz-Modus?"} G -- Standard --> H["CPU auf Baseline gedrosselt"] G -- Unlimited --> I["Burst läuft weiter
Surplus-Kosten entstehen"] H --> J["Last sinkt"] I --> J J --> B

Credit-Akkumulation: Solange die CPU unter der Baseline läuft, wächst das Credit-Guthaben bis zum Maximum an.
Burst-Phase: Bei erhöhter Last werden Credits verbraucht. Die Instanz kann deutlich über die Baseline hinaus arbeiten.
Credit-Erschöpfung (Standard-Modus): Sind alle Credits aufgebraucht, wird die CPU auf die Baseline-Rate gedrosselt. Dies ist der Moment des plötzlichen Performance-Einbruchs.
Unlimited-Modus: Der Burst läuft weiter, aber AWS berechnet die zusätzliche CPU-Zeit separat.

Warum der Server plötzlich langsam wird — die eigentliche Ursache

Das klassische Fehlbild: Ein Deployment läuft an, Build-Prozesse oder Initialisierungsroutinen belasten die CPU für 20–30 Minuten stark. Danach läuft alles normal — bis das Credit-Guthaben leer ist und die Instanz auf Baseline gedrosselt wird. Der Zeitversatz zwischen Ursache (Credit-Verbrauch) und Symptom (Drosselung) führt dazu, dass Teams zunächst an Applikationsfehler, Speicherlecks oder Netzwerkprobleme denken.

Der entscheidende Hinweis steckt in CloudWatch: CPUCreditBalance fällt auf null, kurz bevor die Latenz steigt. Wer diese Korrelation nicht zieht, sucht an der falschen Stelle.

graph TD A["Normalbetrieb
Credits akkumulieren"] --> B["Lastspitze beginnt"] B --> C["CPUCreditBalance sinkt"] C --> D["CPUCreditBalance nahe null"] D --> E{"Standard- oder Unlimited-Modus?"} E -- Standard --> F["CPU-Drosselung auf Baseline
Performance-Einbruch sichtbar"] E -- Unlimited --> G["Burst läuft weiter
CPUSurplusCreditsCharged steigt"] F --> H["Last sinkt"] G --> H H --> I["Credits akkumulieren langsam
Erholung über Zeit"]

Normalbetrieb: Credits akkumulieren sich, CPU-Auslastung bleibt unter Baseline.
Lastspitze: CPU-Auslastung übersteigt Baseline, Credits werden verbraucht.
Kritischer Punkt: CPUCreditBalance nähert sich null.
Drosselung: CPU wird auf Baseline begrenzt — Antwortzeiten steigen, Throughput fällt.
Erholung: Sobald die Last sinkt, akkumulieren sich Credits wieder langsam.

T3 CPU-Credits diagnostizieren: CloudWatch-Metriken und CLI

Bevor Maßnahmen ergriffen werden, muss der aktuelle Zustand des Credit-Guthabens und des Instanz-Modus verifiziert werden. Die relevanten CloudWatch-Metriken für burstable Instanzen sind:

CPUCreditBalance: Aktuelles Credit-Guthaben der Instanz.
CPUCreditUsage: Verbrauchte Credits im Messzeitraum.
CPUSurplusCreditBalance: Im Unlimited-Modus über das Guthaben hinaus genutzte Credits (noch nicht abgerechnet).
CPUSurplusCreditsCharged: Tatsächlich berechnete Surplus-Credits.

Schritt 1: Instanz-Modus prüfen

Zuerst verifizieren, ob die Instanz im Standard- oder Unlimited-Modus läuft — das bestimmt, ob eine Credit-Erschöpfung zur Drosselung führt oder zu Zusatzkosten.

aws ec2 describe-instance-credit-specifications \
  --instance-ids i-1234567890abcdef0 \
  --region us-east-1

Die Ausgabe enthält CpuCredits: standard oder CpuCredits: unlimited. T3 Instanzen laufen standardmäßig im Unlimited-Modus. Wer unerwartete Kosten sieht, findet hier die Ursache.

Schritt 2: CPUCreditBalance über CloudWatch abrufen

Der aktuelle Credit-Stand lässt sich direkt über die CLI abfragen. Ein Wert nahe null bei gleichzeitig hoher CPU-Auslastung bestätigt die Diagnose.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T06:00:00Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Schritt 3: Surplus-Credits auf Kostenrelevanz prüfen

Im Unlimited-Modus entstehen Kosten, wenn CPUSurplusCreditsCharged größer null ist. Diese Metrik zeigt, wie viele Credits über das Guthaben hinaus verbraucht und abgerechnet wurden.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUSurplusCreditsCharged \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T06:00:00Z \
  --period 3600 \
  --statistics Sum \
  --region us-east-1

Schritt 4: Instanz-Modus ändern

Wenn die Drosselung im Standard-Modus das Problem ist und Zusatzkosten akzeptiert werden können, lässt sich auf Unlimited umschalten — ohne Neustart der Instanz.

aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications InstanceId=i-1234567890abcdef0,CpuCredits=unlimited \
  --region us-east-1

Umgekehrt, um Kosten zu begrenzen und auf Standard zurückzuschalten:

aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications InstanceId=i-1234567890abcdef0,CpuCredits=standard \
  --region us-east-1

CloudWatch-Alarm für CPUCreditBalance einrichten

Reaktive Diagnose reicht nicht — ein Alarm auf CPUCreditBalance gibt frühzeitig Warnung, bevor die Drosselung eintritt. Der Schwellenwert sollte so gewählt werden, dass noch Zeit für eine Reaktion bleibt.

🔽 CloudWatch-Alarm CLI-Befehl anzeigen

aws cloudwatch put-metric-alarm \
  --alarm-name 'T3-CreditBalance-Low' \
  --alarm-description 'CPUCreditBalance unter kritischem Schwellenwert' \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 20 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:ops-alerts \
  --region us-east-1

Der Alarm löst aus, wenn der Credit-Durchschnitt über zwei aufeinanderfolgende 5-Minuten-Perioden unter den Schwellenwert fällt. Der konkrete Schwellenwert hängt von der Instanzgröße und der typischen Last ab — hier ist Beobachtung über mehrere Tage sinnvoller als ein willkürlicher Wert.

Das Fehldiagnose-Muster: Symptom, Irrtum, Ursache

Ein typisches Szenario aus der Praxis: Eine t3.small-Instanz betreibt einen kleinen Web-Service. Morgens läuft ein Cron-Job, der Daten verarbeitet und die CPU für 45 Minuten auf 80–90% treibt. Gegen Mittag häufen sich Beschwerden über langsame API-Antworten. Das Team prüft Applikationslogs, Datenbankverbindungen, Netzwerk-Latenz — alles unauffällig.

Die Fehldiagnose: Ein Speicherleck oder ein hängender Thread wird vermutet, die Instanz wird neu gestartet. Kurze Besserung, dann dasselbe Muster am nächsten Tag.

Die tatsächliche Ursache: Der Cron-Job hat das gesamte Credit-Guthaben aufgebraucht. Die Instanz läuft im Standard-Modus und wird auf die Baseline-CPU gedrosselt. Der Neustart hat das Credit-Guthaben nicht wiederhergestellt — es akkumuliert sich nur durch tatsächliche Unterlast über Zeit.

Der Fix: Entweder auf Unlimited-Modus umschalten und die Zusatzkosten akzeptieren, den Cron-Job auf eine Zeit mit niedrigerer Baseline-Last verschieben, oder zur richtigen Instanzklasse (z.B. m5 oder c5) wechseln, wenn die Last dauerhaft über der Baseline liegt.

Ein Blick auf CPUCreditBalance im CloudWatch-Dashboard hätte die Diagnose in zwei Minuten geliefert.

Wann T3 Instanzen die falsche Wahl sind

Das Credit-Modell ist für workloads ausgelegt, die typischerweise niedrige CPU-Auslastung haben und nur gelegentlich bursten. Wenn die durchschnittliche CPU-Auslastung dauerhaft über der Baseline liegt, ist eine burstable Instanz strukturell ungeeignet — unabhängig vom gewählten Modus.

Geeignet: Entwicklungsumgebungen, kleine Web-Services mit sporadischen Lastspitzen, Microservices mit niedriger Grundlast, CI/CD-Runner mit kurzen Build-Phasen.
Nicht geeignet: Dauerhaft CPU-intensive Workloads, Datenbank-Instanzen mit kontinuierlicher Last, Video-Encoding, ML-Inferenz.

Im Unlimited-Modus kann eine T3-Instanz bei dauerhafter Überlast teurer werden als eine gleichwertige M5-Instanz — ohne den Vorteil der konsistenten Performance.

IAM-Berechtigungen für Credit-Diagnose und -Verwaltung

Für die oben gezeigten CLI-Operationen sind folgende IAM-Berechtigungen erforderlich. Das Prinzip der minimalen Rechtevergabe gilt auch hier.

🔽 IAM-Policy für T3 Credit-Verwaltung anzeigen

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EC2CreditRead",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstanceCreditSpecifications",
        "ec2:DescribeInstances"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EC2CreditModify",
      "Effect": "Allow",
      "Action": [
        "ec2:ModifyInstanceCreditSpecification"
      ],
      "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*"
    },
    {
      "Sid": "CloudWatchMetricsRead",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:PutMetricAlarm"
      ],
      "Resource": "*"
    }
  ]
}

Hinweis: ec2:DescribeInstanceCreditSpecifications und CloudWatch-Read-Aktionen erfordern "Resource": "*", da diese API-Aktionen keine ressourcenspezifische Einschränkung unterstützen. Dies ist dokumentiertes AWS-Verhalten, kein Konfigurationsfehler.

T3 Instanzen und CPU-Credits: Nächste Schritte

Das CPU-Credit-Modell ist kein Fehler — es ist ein bewusstes Design für intermittierende Workloads. Wer es versteht, kann T3 Instanzen kosteneffizient einsetzen. Wer es ignoriert, kämpft mit Symptomen, deren Ursache eine Zeile in CloudWatch ist.

Empfohlene nächste Schritte:

CloudWatch-Dashboard mit CPUCreditBalance und CPUCreditUsage für alle T3 Instanzen einrichten.
Alarm auf CPUCreditBalance konfigurieren, bevor die erste Drosselung im Produktionsbetrieb auftritt.
Instanz-Modus bewusst wählen: Standard für Kostenvorhersagbarkeit, Unlimited für Performance-Priorität.
Bei dauerhafter CPU-Überlast Wechsel zu M5 oder C5 evaluieren — die AWS-Dokumentation zu Burstable Performance Instances enthält aktuelle Baseline-Werte und Empfehlungen.

Glossar: Schlüsselbegriffe für T3 Instanzen

Begriff	Bedeutung
CPU-Credit	Einheit für akkumulierte Burst-Kapazität; wird bei Unterlast gesammelt, bei Überlast verbraucht
Baseline-CPU	Garantierter CPU-Prozentsatz je Instanzgröße; definiert die Akkumulationsrate
Standard-Modus	Burst strikt auf vorhandene Credits begrenzt; Drosselung bei Erschöpfung
Unlimited-Modus	Burst über Credits hinaus möglich; Surplus-Credits werden zusätzlich berechnet
CPUCreditBalance	CloudWatch-Metrik für das aktuelle Credit-Guthaben einer Instanz

Dieses Blog durchsuchen

SW BBANG D