Summary

  • Im Zustand scheduled ist eine künftige RDS-Reservierung angenommen: Es fallen noch keine Gebühren an, eine Stornierung ist bereits ausgeschlossen. Nach der Aktivierung gilt die Bindung bis zum Ende der Zusagedauer.
  • Künftige Buchungen beginnen bei 14 Tagen und 32 vCPUs pro Availability Zone; für die X-Familie gelten mindestens zwölf Wochen. Ein Mindestbeispiel mit db.r7g.large über zwei Zonen ergibt 32 reservierte Datenbank-Kapazitätsplätze.

Erst die Zusage, später die Rechnung

Ein Starttermin lässt sich in einer Projektbesprechung verschieben. Die gebuchte Datenbankkapazität folgt einem eigenen Ablauf. AWS führte mit der Ankündigung vom 21. Oktober On-Demand Capacity Reservations für Aurora und RDS in seinen kommerziellen Regionen ein. Kunden können bestimmte Rechenkapazität für Vorgänge wie Erstellung, Wiederherstellung, Start und Änderung der Rechenleistung sichern.

Ein verfügbarer Platz hat für eine termingebundene Migration einen wirtschaftlichen Wert. Die entscheidende Frage für den Einkauf lautet, wann er den Platz wieder abbestellen kann. Die Zustandsübersicht nennt eine angenommene künftige Buchung scheduled und hält fest, dass noch keine Gebühren anfallen. Die Stornoregeln schließen die Stornierung in genau diesem Zustand aus.

Damit kann das Ausgabenfenster ruhig aussehen, während eine Entscheidung schon bindet. Wer erst beim ersten Gebühreneintrag nachfragt, erreicht einen Teil des Einkaufs zu spät. Der Verantwortliche für den Starttermin muss die Ausstiegsdaten vor der Annahme kennen.

Ein Mindestumfang je Zone

Sofort nutzbare Reservierungen haben keine Zusagedauer und lassen sich nach Bedarf stornieren. Künftige Reservierungen werden fünf bis 120 Tage im Voraus geplant und verlangen mindestens 14 Tage Bindung. Bei der X-Familie sind es zwölf Wochen. Hinzu kommen mindestens 32 vCPUs in jeder gewählten Availability Zone.

Die Dokumentation beschreibt db.r7g.large als Einheit mit zwei vCPUs. In einem konstruierten Mindestbeispiel über zwei Zonen braucht jede Zone 16 Einheiten. Zusammen sind es 32 Kapazitätsplätze für mindestens 14 Tage. Gezählt werden reservierte Recheneinheiten beider Zonen; eine Multi-AZ-Konfiguration benötigt auch Plätze für die Bereitschaftsseite.

Ein kurzes Ereignis kann den längeren Schutz rechtfertigen. Umfang und Dauer gehören dann in die Freigabe des Ereignisses. Hinter dem Wunsch, etwas Platz für eine Migration freizuhalten, steckt eine Mindestbestellung, die der Dienst vorgibt.

Welcher Termin verschoben wurde, zählt

Während AWS die Lieferung prüft, erlaubt assessing eine Stornierung. Nach scheduled bleibt die Buchung bis zum Beginn bestehen. Anschließend muss die aktive künftige Reservierung ihre Zusagedauer erfüllen. Wenn AWS die Kapazität nicht am gewünschten Tag liefert und der Zustand delayed eintritt, erlaubt der Stornoleitfaden einen sofortigen Ausstieg. Diese Ausnahme folgt dem Lieferzustand des Anbieters. Eine intern verschobene Kampagne ändert ihn allein nicht.

Der Projektkalender beantwortet, wann das Geschäft Kapazität braucht. Der Reservierungszustand beantwortet, wann es die Bestellung verlassen kann. Der Anbieter plant die Versorgung; der Kunde trägt das Risiko, dass sein eigener Termin inzwischen wandert. Diese beiden Entscheidungen benötigen eine gemeinsame Budgetverantwortung.

Eine gestoppte Datenbank lässt den Platz gebucht

Die Abrechnungsregeln beginnen mit der Bereitstellung der Kapazität im Konto. Aktive ungenutzte Einheiten werden zum entsprechenden On-Demand-Preis abgerechnet. Nutzt eine passende Instanz einen Platz, zahlt der Kunde für die Instanz; für diesen Platz entsteht keine gesonderte Reservierungsgebühr.

Beim Stoppen der Instanz wird ihre Kapazität zur ungenutzten Reservierung, deren Kosten weiterlaufen. Eine zulässige Stornierung oder das Enddatum beendet diese Reservierungskosten. Speicher, Ein- und Ausgabe sowie andere Ressourcen behalten ihre übliche Abrechnung. Passende Rabatte können über Reserved DB Instances oder Database Savings Plans hinzukommen.

Der Betriebsauftrag zum Stoppen kann also erledigt sein, während der Einkauf des Platzes fortbesteht. Seine Freigabe hat eigene Bedingungen und braucht einen zuständigen Entscheider.

Den bezahlten Platz auch treffen

Die Nutzungsanleitung verlangt, Name oder Kennung der Reservierung ausdrücklich anzugeben. Engine, Instanzklasse, gegebenenfalls Lizenzmodell und Zone müssen passen; freie Kapazität muss vorhanden sein. Für Multi-AZ brauchen sowohl die Primär- als auch die Bereitschaftszone Platz. Die Bestellung schützt den Betrieb erst, wenn die Bereitstellung tatsächlich auf sie zielt.

Wird eine Freigabe zulässig, bleibt eine betriebliche Abwägung. Die Stornierungs-API lässt eine bestehende Datenbank unverändert laufen und gibt die reservierte Kapazität frei. Ein späterer Hardwarewechsel kann dann auf fehlende Kapazität treffen. Der Platz hat damit auch einen Wert für die nächste Bewegung nach dem ursprünglichen Ereignis.

Kundenhistorien und tatsächliche Gebühren sind nicht verfügbar; sie würden die Kosten leer gebliebener Zusagen beziffern. Die veröffentlichten Regeln zeigen bereits den Freigabepunkt. AWS verkauft vorgezogenen Zugriff auf bestimmte Kapazität. Der Kunde finanziert das Risiko seiner eigenen Terminänderung nach Schließung des Ausstiegs. Die Zustimmung gehört vor scheduled. Der Zähler beginnt später.

Quellen