Das Problem
Kapazitäten für EC2-GPU-Instanzfamilien wie P5, P4d, G7, G6 und G5 sind knapp, gerade in Phasen hoher Nachfrage. Sobald Sie eine Instanz stoppen, wandert sie zurück in den gemeinsamen Pool – ohne Garantie, dass sie beim nächsten Start noch verfügbar ist.
Routine-Wartung wird damit zum Glücksspiel. In dem Moment, in dem Sie eine GPU-Instanz stoppen, um einen Treiber zu patchen, ein AMI zu wechseln, das Root-Volume zu vergrößern oder ein OS-Update einzuspielen, ist diese Kapazität für jeden anderen AWS-Kunden freigegeben.
Bei hoher Nachfrage kassieren Sie beim Neustart schnell einen InsufficientInstanceCapacity-Fehler – und aus dem vermeintlich "10-minütigen Wartungsfenster" werden Stunden mit Retry-Schleifen oder, im schlimmsten Fall, ein Ausfall, während Sie darauf warten, dass wieder Kapazität frei wird.
Was eine On-Demand Capacity Reservation tatsächlich bewirkt
Eine EC2 On-Demand Capacity Reservation (ODCR) reserviert Compute-Kapazität für einen bestimmten Instanztyp in einer bestimmten Availability Zone – so lange, wie Sie die Reservierung aktiv halten. Entscheidend dabei: Die Kapazität ist für Sie geblockt, ganz gleich, ob gerade eine Instanz läuft oder nicht.
Genau das macht ODCRs zum richtigen Werkzeug für Wartungsarbeiten. Stoppen Sie eine Instanz, die eine Reservierung nutzt, bleibt die reservierte Compute-Kapazität für Sie erhalten. AWS hält sie exklusiv für Ihren Account bereit. Beim erneuten Start garantiert AWS, dass die reservierte Kapazität zur Verfügung steht.
Ein paar wichtige Eigenschaften
Anders als der Name vielleicht vermuten lässt, ist eine sofortige Capacity Reservation keine langfristige Verpflichtung. Sie stellt lediglich sicher, dass die benötigte EC2-Kapazität dann bereitsteht, wenn Sie sie brauchen. Ändern sich Ihre Pläne oder benötigen Sie die Kapazität nicht mehr, können Sie die Reservierung jederzeit stornieren. Es fallen keine Stornogebühren an, und es gibt keine Mindestlaufzeit.
Die Kosten einer Capacity Reservation entsprechen denen einer laufenden On-Demand EC2-Instanz. Haben Sie einen passenden Savings Plan oder Reserved Instances, gilt der reduzierte Tarif auch für die Capacity Reservation. Der einzige Unterschied: Sie zahlen weiter für die reservierte Kapazität, auch wenn die Instanz gestoppt ist – bis Sie die Capacity Reservation stornieren oder die Instanz wieder starten.
Warum das gerade bei Wartungsarbeiten zählt
Die Ironie: Ausgerechnet während der Wartung sind Sie am angreifbarsten. Sobald Sie Ihre Instanz stoppen, geht ihre Kapazität zurück in den gemeinsamen Pool von AWS. Startet ein anderer AWS-Kunde in derselben Availability Zone eine passende Instanz, bevor Sie Ihre wieder hochfahren, kann er sich genau die Kapazität schnappen, die zuvor Ihre Instanz getragen hat – und aus dem geplanten Wartungsfenster wird ein ungewollter Ausfall.
Stop/Start-Vorgänge
Viele Wartungsaufgaben verlangen einen kompletten Stop/Start statt eines Reboots:
- Wechsel auf ein neues AMI
- Änderung bestimmter Instanzattribute
Jede dieser Aktionen gibt die Instanz zurück in den gemeinsamen Kapazitätspool.
Rollierende Wartung über eine Flotte hinweg
Wenn Sie eine Flotte Knoten für Knoten patchen, drainen und stoppen Sie in der Regel eine Instanz nach der anderen. Ohne reservierte Kapazität kommt vielleicht nicht jeder heruntergefahrene Knoten zurück – und Ihre Flotte ist am Ende dauerhaft kleiner als zu Beginn.
Geplante Hardware-Ereignisse
AWS plant gelegentlich Wartungen am darunterliegenden Host (etwa bei degradierter Hardware oder Host-Außerbetriebnahme). Eine Capacity Reservation sichert die Compute-Kapazität, wenn Sie die Instanz zum Umzug vom betroffenen Host stoppen und wieder starten.
So gehen Sie in der Praxis vor
Erstellen Sie in der EC2-Konsole eine offene On-Demand Capacity Reservation, die zu Folgendem passt:
- Instanztyp
- Availability Zone
- Betriebssystem (Plattform)
Dimensionieren Sie die Capacity Reservation so, dass sie der Gesamtzahl der Instanzen desselben Typs (zum Beispiel g7.xlarge) entspricht, die Sie während der rollierenden Wartung in dieser Availability Zone betreiben.
Prüfen Sie, ob Ihre Instanzen die Reservierung auch tatsächlich nutzen. Standardmäßig greifen EC2-Instanzen automatisch auf eine offene Capacity Reservation zu, sobald eine passende verfügbar ist. Stellen Sie sicher, dass Ihre angelegten Capacity Reservations wirklich durch Ihre Instanzen belegt werden.
Capacity Reservations decken auch anspruchsvollere Szenarien ab, etwa gezielte Capacity Reservations für bestimmte workloads. Diese Fälle sprengen den Rahmen dieses Artikels.
Führen Sie Ihre Wartung wie gewohnt durch:
- Instanz stoppen.
- Erforderliche Änderungen vornehmen.
- Instanz wieder starten.
Da die Kapazität reserviert bleibt, startet die Instanz, ohne um verfügbare GPU-Kapazität konkurrieren zu müssen.
Ist die Wartung abgeschlossen, stornieren Sie die Capacity Reservation, falls Sie sie nicht mehr benötigen. Ihre Instanzen laufen ganz normal weiter.
Was hat das gekostet?
Um exakt zu sehen, wie viel Sie für die reservierte Kapazität während des Stopps bezahlt haben, warten Sie nach Abschluss der Wartung etwa 48 Stunden. Die AWS-Abrechnungsdaten stehen nicht in Echtzeit bereit – es kann bis zu zwei Tage dauern, bis diese Kosten sichtbar werden.
Sobald die Abrechnungsdaten aktualisiert sind:
- Öffnen Sie AWS Billing → Bills.
- Suchen Sie nach "Unused Reservation".
Sie sehen dann eine Position mit:
- dem Instanztyp
- dem Betrag, der Ihnen für die Capacity Reservation berechnet wurde, während sie nicht von einer laufenden Instanz genutzt wurde
So lassen sich die Kosten für die Kapazitätsgarantie während Ihres Wartungsfensters einfach beziffern.
In meinem Fall dauerte die Wartung weniger als 30 Minuten. Ohne Capacity Reservation hätte ich womöglich stundenlang darauf gewartet, dass wieder GPU-Kapazität frei wird.
Fazit
Kapazitätsengpässe gehören zum Betrieb von workloads in einer gemeinsam genutzten Cloud-Umgebung dazu. Gut, dass AWS einen einfachen Weg bietet, diese Unsicherheit genau dann zu beseitigen, wenn es darauf ankommt.
Wenn Sie Wartungsarbeiten an GPU-Instanzen – oder an jedem anderen EC2-Instanztyp mit knapper Kapazität – planen, kann eine temporäre Capacity Reservation den Unterschied ausmachen zwischen einem Routine-Wartungsfenster und stundenlangen ungeplanten Ausfallzeiten.