EBS gp2 vs. gp3: IOPS unabhängig skalieren und Kosten sparen

Wer in der AWS-Konsole ein neues EBS-Volume anlegt, sieht zwei Optionen für General Purpose SSDs: gp2 und gp3. Der Unterschied klingt zunächst marginal, hat aber in der Praxis erhebliche Auswirkungen auf Performance-Engpässe und monatliche Kosten – besonders wenn Workloads wachsen oder IOPS-Anforderungen sich von der tatsächlich benötigten Speichergröße entkoppeln.

TL;DR: gp2 vs. gp3 auf einen Blick

Merkmal	gp2	gp3
IOPS-Modell	Gekoppelt an Volume-Größe (3 IOPS/GB)	Unabhängig konfigurierbar
Basis-IOPS	100–16.000 (größenabhängig)	3.000 (immer inklusive)
Max. IOPS	16.000	16.000
Max. Durchsatz	250 MiB/s	1.000 MiB/s
Burst-Mechanismus	Credit-basiert (Volumes < 1 TB)	Kein Burst-Modell
Kosten	Höher pro GB	Niedriger pro GB (typischerweise ~20% günstiger)

Preise und Limits variieren je nach Region – aktuelle Werte immer in der offiziellen AWS-Dokumentation prüfen.

Wie gp2 und gp3 intern funktionieren

Das Verständnis des IOPS-Modells ist entscheidend, bevor man eine Migrationsentscheidung trifft.

gp2: IOPS als Funktion der Volume-Größe

Bei gp2 sind IOPS direkt an die Volume-Größe gekoppelt: 3 IOPS pro GB, mit einem Minimum von 100 IOPS und einem Maximum von 16.000 IOPS. Das bedeutet, ein Volume muss mindestens 5.334 GB groß sein, um die maximalen 16.000 IOPS dauerhaft zu erreichen. Für Volumes unter 1 TB gibt es einen Credit-basierten Burst-Mechanismus, der kurzfristig bis zu 3.000 IOPS ermöglicht – aber nur solange das Burst-Guthaben nicht erschöpft ist.

Das ist der klassische Fallstrick: Eine Datenbank braucht 10.000 IOPS, aber nur 200 GB Speicher. Mit gp2 erzwingt das ein Volume von mindestens ~3.334 GB – man zahlt für Speicher, den man nicht braucht.

gp2 IOPS-Kopplung: Die IOPS steigen linear mit der Volume-Größe. Wer mehr Performance braucht, muss das Volume vergrößern – unabhängig vom tatsächlichen Speicherbedarf.
gp3 Entkopplung: IOPS und Durchsatz werden separat konfiguriert. 3.000 IOPS und 125 MiB/s sind ohne Aufpreis enthalten; darüber hinaus wird pro zusätzliche IOPS und MiB/s separat abgerechnet.
Burst-Grenze bei gp2: Volumes unter 1 TB können kurzfristig auf 3.000 IOPS bursten, aber nur wenn ausreichend Credits vorhanden sind. Ein dauerhaft hochlastiger Workload leert das Guthaben schnell.

gp3: Entkoppelte Performance

gp3 liefert standardmäßig 3.000 IOPS und 125 MiB/s – unabhängig von der Volume-Größe, ohne Burst-Mechanismus und ohne Credit-System. Wer mehr benötigt, konfiguriert IOPS und Durchsatz separat bis zu den Maximalwerten (16.000 IOPS, 1.000 MiB/s). Ein 20-GB-Volume kann damit auf 10.000 IOPS konfiguriert werden, ohne die Größe anpassen zu müssen.

gp3 verhält sich wie ein Mietwagen mit wählbarer Motorleistung: Man zahlt für den Kofferraum (Speicher) und die PS (IOPS) getrennt – nicht für einen übergroßen Kofferraum, nur weil man mehr PS braucht.

IOPS unabhängig von der Speichergröße skalieren – gp3 im Detail

Das ist der entscheidende operative Vorteil von gp3: IOPS lassen sich ohne Volume-Resize anpassen. Das ist besonders relevant für Datenbank-Volumes, bei denen Speicher und I/O-Last unterschiedliche Wachstumskurven haben.

gp3-Volume erstellen mit spezifischen IOPS

aws ec2 create-volume \
  --volume-type gp3 \
  --size 100 \
  --iops 6000 \
  --throughput 250 \
  --availability-zone us-east-1a

Dieses Kommando erstellt ein 100-GB-gp3-Volume mit 6.000 IOPS und 250 MiB/s Durchsatz. Mit gp2 wäre dafür ein Volume von mindestens 2.000 GB erforderlich.

IOPS eines bestehenden gp3-Volumes anpassen

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --iops 10000 \
  --throughput 500

Die Änderung erfolgt ohne Downtime. AWS wendet die neue Konfiguration im Hintergrund an – der Optimierungsstatus lässt sich mit describe-volumes-modifications verfolgen.

aws ec2 describe-volumes-modifications \
  --volume-ids vol-0123456789abcdef0 \
  --query 'VolumesModifications[*].{Status:ModificationState,Progress:Progress}'

Kostenvergleich: Wann ist gp3 günstiger?

gp3 ist in den meisten Szenarien günstiger als gp2 – der Preis pro GB ist niedriger, und die inkludierten 3.000 IOPS decken viele Standard-Workloads ab. Die Kostendifferenz wird größer, je mehr man bei gp2 Speicher überdimensionieren müsste, um IOPS zu erreichen.

graph TD Start(["Neues EBS-Volume planen"]) --> Q1{"Benötigte IOPS > 3 x Volume-GB?"} Q1 -->|"Ja"| gp3_rec["gp3 empfohlen IOPS separat konfigurieren"] Q1 -->|"Nein"| Q2{"Volume > 1 TB?"} Q2 -->|"Ja"| Q3{"Kosten optimieren?"} Q2 -->|"Nein"| Q4{"Dauerhaft hohe Last (kein Burst-Muster)?"} Q3 -->|"Ja"| gp3_rec2["gp3 empfohlen günstiger pro GB"] Q3 -->|"Nein – Legacy"| gp2_ok["gp2 akzeptabel Migration prüfen"] Q4 -->|"Ja"| gp3_rec3["gp3 empfohlen kein Credit-Risiko"] Q4 -->|"Nein – sporadisch"| gp3_rec4["gp3 trotzdem empfohlen stabiler und günstiger"]

Szenario A (kleines Volume, hohe IOPS): Ein 200-GB-Volume mit 6.000 IOPS-Bedarf. gp2 liefert nur 600 IOPS – man müsste auf ~2.000 GB vergrößern. gp3 deckt das direkt ab.
Szenario B (großes Volume, moderate IOPS): Ein 5-TB-Archiv-Volume mit geringem I/O. gp2 liefert hier automatisch 15.000 IOPS, die niemand braucht. gp3 ist trotzdem günstiger pro GB.
Szenario C (Standard-Workload): Ein 500-GB-Volume mit ~1.500 IOPS. gp2 Burst deckt das ab, aber gp3 ist stabiler und günstiger – kein Credit-Risiko.

Konkrete Preiszahlen variieren je nach Region und ändern sich. Aktuelle Preise immer im AWS EBS Pricing prüfen.

Migration von gp2 zu gp3: Schritt für Schritt

Die Migration ist non-destruktiv und kann ohne Downtime durchgeführt werden. AWS empfiehlt, vor der Modifikation den aktuellen IOPS-Bedarf aus CloudWatch zu ermitteln.

Schritt 1: Aktuellen IOPS-Verbrauch prüfen

Bevor man migriert, sollte man wissen, welche IOPS das Volume tatsächlich nutzt – sonst riskiert man eine Unter-Provisionierung nach der Migration.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name VolumeReadOps \
  --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-08T00:00:00Z \
  --period 3600 \
  --statistics Maximum

Dasselbe für VolumeWriteOps ausführen. Die Summe beider Maximalwerte pro Sekunde ergibt den Peak-IOPS-Bedarf.

Schritt 2: Volume-Typ ändern

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3 \
  --iops 3000 \
  --throughput 125

Startet man ohne explizite IOPS-Angabe, setzt AWS die Standardwerte (3.000 IOPS, 125 MiB/s). Für Produktions-Datenbanken empfiehlt es sich, die IOPS basierend auf den CloudWatch-Daten aus Schritt 1 zu setzen.

Schritt 3: Optimierungsstatus überwachen

aws ec2 describe-volumes-modifications \
  --volume-ids vol-0123456789abcdef0

Der Status durchläuft die Zustände modifying → optimizing → completed. Während der Optimierung ist das Volume vollständig nutzbar.

stateDiagram-v2 [*] --> modifying : modify-volume aufgerufen modifying --> optimizing : Konfiguration übernommen optimizing --> completed : Hintergrund-Optimierung abgeschlossen optimizing --> failed : Fehler während Optimierung completed --> [*] failed --> [*] note right of optimizing : Volume bleibt nutzbar note right of completed : Neue IOPS/Throughput aktiv

modifying: AWS nimmt die Konfigurationsänderung entgegen und beginnt mit der Umstellung.
optimizing: Das Volume wird im Hintergrund optimiert. I/O-Operationen laufen weiter, können aber leicht beeinträchtigt sein.
completed: Die Migration ist abgeschlossen. Neue Performance-Parameter sind aktiv.

Ein reales Muster: Der Burst-Credit-Kollaps

Symptom: Eine Anwendung läuft nachts problemlos, bricht aber tagsüber unter Last ein. CloudWatch zeigt sporadische IOPS-Einbrüche auf exakt 100 IOPS – dem Minimum für kleine gp2-Volumes.

Erste Diagnose: Applikations-Bottleneck, Datenbankabfragen ohne Index, zu wenig RAM für den Buffer Pool.

Tatsächliche Ursache: Das 50-GB-gp2-Volume hat nur 150 Basis-IOPS (50 × 3). Nachts ist die Last gering, Credits akkumulieren sich. Tagsüber erschöpft der Workload das Burst-Guthaben innerhalb von Stunden – danach throttelt AWS auf die Basis-IOPS.

Fix: Migration auf gp3 mit 3.000 IOPS. Kein Credit-System, keine Überraschungen. Die Nacht-Tag-Asymmetrie verschwindet sofort.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name BurstBalance \
  --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-02T00:00:00Z \
  --period 300 \
  --statistics Minimum

Ein BurstBalance-Wert der auf 0 fällt und dort verbleibt ist der eindeutige Beweis. gp3 hat keine BurstBalance-Metrik – das ist kein Fehler, sondern Absicht.

Wann bleibt gp2 sinnvoll?

In der Praxis gibt es kaum noch Szenarien, in denen gp2 die bessere Wahl ist. Mögliche Ausnahmen:

Sehr große Volumes (> 5.334 GB), bei denen gp2 automatisch 16.000 IOPS liefert und kein zusätzliches IOPS-Provisioning nötig ist – obwohl gp3 hier trotzdem günstiger pro GB bleibt.
Legacy-Umgebungen mit Terraform- oder CloudFormation-Stacks, die noch nicht auf gp3 aktualisiert wurden und bei denen das Migrationsrisiko den Nutzen übersteigt.
Compliance- oder Change-Freeze-Situationen, in denen keine Volume-Modifikationen erlaubt sind.

Für neue Volumes ist gp3 die dokumentierte AWS-Empfehlung.

IAM-Berechtigungen für Volume-Modifikationen

Wer modify-volume ausführen möchte, benötigt explizit die ec2:ModifyVolume-Berechtigung. Read-only-Rollen reichen nicht aus.

🔽 IAM-Policy für EBS-Volume-Migration (klicken zum Aufklappen)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:ModifyVolume",
        "ec2:DescribeVolumes",
        "ec2:DescribeVolumesModifications"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics"
      ],
      "Resource": "*"
    }
  ]
}

Hinweis: ec2:DescribeVolumes und ec2:DescribeVolumesModifications unterstützen keine ressourcenbasierte Einschränkung – "Resource": "*" ist hier erforderlich. Für ec2:ModifyVolume kann die Ressource auf spezifische Volume-ARNs eingeschränkt werden.

Fazit und nächste Schritte: gp3 als Standard setzen

gp3 ist in nahezu allen Szenarien die bessere Wahl gegenüber gp2: niedrigere Kosten pro GB, garantierte Basis-IOPS ohne Credit-Mechanismus, und die Möglichkeit, IOPS vollständig unabhängig von der Volume-Größe zu skalieren. Die Migration ist non-destruktiv und lässt sich mit einem einzigen modify-volume-Aufruf anstoßen.

Empfohlene nächste Schritte:

Bestehende gp2-Volumes mit describe-volumes --filters Name=volume-type,Values=gp2 inventarisieren.
CloudWatch-Metriken (BurstBalance, VolumeReadOps, VolumeWriteOps) für mindestens eine Woche auswerten, bevor IOPS-Werte für gp3 festgelegt werden.
Migration in nicht-produktiven Umgebungen zuerst testen.
Infrastructure-as-Code (Terraform, CloudFormation) auf gp3 als Standard aktualisieren.

Weiterführende Ressourcen: AWS EBS Volume Types Dokumentation und EBS Volume Modifications.

Glossar

Begriff	Bedeutung
IOPS	Input/Output Operations Per Second – Maß für die I/O-Performance eines Speichervolumes.
Burst Balance	Credit-Guthaben bei gp2-Volumes, das kurzfristige IOPS-Spitzen über dem Basiswert ermöglicht.
Durchsatz (Throughput)	Datenmenge pro Sekunde (MiB/s), die ein Volume übertragen kann – unabhängig von IOPS.
Volume Modification	AWS-Funktion zum Ändern von Typ, Größe, IOPS oder Durchsatz eines EBS-Volumes ohne Downtime.
Provisioned IOPS	Explizit konfigurierte IOPS-Kapazität, die unabhängig von der Volume-Größe garantiert wird.

Dieses Blog durchsuchen

SW BBANG D