Bewährte Methoden: Verwalten und Bereitstellen von Anwendungen und Rezeptbüchern

Wichtig

Der AWS OpsWorks Stacks Dienst hat am 26. Mai 2024 das Ende seiner Lebensdauer erreicht und wurde sowohl für neue als auch für bestehende Kunden deaktiviert. Wir empfehlen Kunden dringend, ihre Workloads so bald wie möglich auf andere Lösungen zu migrieren. Wenn Sie Fragen zur Migration haben, wenden Sie sich an das AWS Support Team auf AWS re:POST oder über den AWS Premium-Support.

AWS OpsWorks Stacks stellt Apps und Kochbücher aus einem Remote-Repository für jede neue Instanz bereit. Im Verlauf der Nutzungsdauer einer Instance müssen Sie häufig Anwendungen oder Rezeptbücher auf den Online-Instances des Stacks aktualisieren, um Funktionen, Fehlerkorrekturen oder Ähnliches hinzuzufügen. Es gibt eine Vielzahl von Möglichkeiten zum Verwalten von Stack-Anwendungen und Rezeptbüchern, aber der Ansatz sollte die folgenden allgemeinen Anforderungen erfüllen:

• Alle Instances von Produktions-Stacks sollten, mit begrenzten Ausnahmen, wie beispielsweise für A/B-Tests, denselben Anwendungscode und denselben benutzerspezifischen Rezeptbuch-Code haben.

• Das Bereitstellen eines Updates darf, auch bei Auftreten eines Fehlers, nicht den Betrieb der Website unterbrechen.

Dieser Abschnitt beschreibt empfohlene Vorgehensweisen für die Verwaltung und Bereitstellung von Anwendungen und benutzerdefinierten Rezeptbüchern.

Bewahren der Konsistenz

Im Allgemeinen müssen Sie die auf Ihren Produktions-Stacks laufenden Anwendungs- und Rezeptbuch-Codes engmaschig kontrollieren. In der Regel sollten alle Instances die aktuell genehmigte Code-Version ausführen. Ausnahmen kann es beim Aktualisieren der Anwendungen oder Rezeptbücher geben, wie unten beschrieben, sowie beim Zuweisen spezieller Fälle, wie der Durchführung von A/B-Tests.

Der Anwendungs- und Rezeptbuch-Code wird für die Instances Ihres Stacks auf zweierlei Weise von einer angegebenen Quelle bereitgestellt:

• Wenn Sie eine Instanz starten, stellt AWS OpsWorks Stacks automatisch den aktuellen App- und Kochbuchcode für die Instanz bereit.

• Für Online-Instances müssen Sie den aktuellen Code der Anwendung oder des Rezeptbuchs manuell bereitstellen, indem Sie den Bereitstellungsbefehl (für die Anwendungen) oder den Befehl "update custom cookbooks" (für Rezeptbücher) ausführen.

Da es zwei Bereitstellungsmethoden gibt, ist es wichtig, dass Sie Ihren Quellcode sorgfältig verwalten, um zu vermeiden, dass versehentlich verschiedene Codes auf verschiedenen Instances ausgeführt werden. Wenn Sie beispielsweise Apps oder Kochbücher von einem Git-Master-Branch aus bereitstellen, stellt AWS OpsWorks Stacks bereit, was sich zu diesem Zeitpunkt in diesem Branch befindet. Wenn Sie den Code im Master-Branch aktualisieren und dann eine neue Instance starten, weist diese Instance eine neuere Code-Version auf als die älteren Instances. Die neuere Version ist möglicherweise noch nicht für den Produktivbetrieb genehmigt.

Empfehlung: Amazon S3 S3-Archive

Um sicherzustellen, dass alle Ihre Instances über die genehmigte Codeversion verfügen, empfehlen wir, Ihre Apps und Kochbücher aus einem Amazon Simple Storage Service (Amazon S3) -Archiv bereitzustellen. Dadurch wird garantiert, dass es sich bei dem Code um ein statisches Artefakt handelt — eine ZIP-Datei oder eine andere Archivdatei —, die explizit aktualisiert werden muss. Darüber hinaus ist Amazon S3 äußerst zuverlässig, sodass Sie selten, wenn überhaupt, nicht auf das Archiv zugreifen können. Um die Konsistenz weiter zu gewährleisten, sollten Sie jede Archivdatei explizit versionieren, indem Sie eine Namenskonvention oder die Amazon S3 S3-Versionierung verwenden, was einen Prüfpfad und eine einfache Möglichkeit bietet, zu einer früheren Version zurückzukehren.

Sie können beispielsweise mit einem Tool wie Jenkins eine Bereitstellungspipeline erstellen. Nachdem der Code, den Sie bereitstellen möchten, festgeschrieben und getestet wurde, erstellen Sie eine Archivdatei und laden Sie sie auf Amazon S3 hoch. Alle Bereitstellungen von Apps oder Updates von Rezeptbüchern installieren dann den Code dieser Archivdatei und jede Instance verfügt über denselben Code.

Empfehlung: Git- oder Subversion-Repositorys

Wenn Sie lieber mit einem Git oder Subversion-Repository arbeiten, stellen Sie dieses nicht aus der Master-Branch bereit. Taggen Sie stattdessen die genehmigte Version und geben Sie diese Version als Quelle für die Anwendung oder das Rezeptbuch an.

Bereitstellen von Code für Online-Instances

AWS OpsWorks Stacks stellt aktualisierten Code nicht automatisch für Online-Instances bereit. Sie müssen den Vorgang manuell auszuführen, was mit folgenden Herausforderungen verbunden ist:

• Effiziente Update-Bereitstellung, ohne die Fähigkeit der Website zu beeinträchtigen, Kundenanforderungen während des Bereitstellungsprozesses zu beantworten.

• Umgang mit einer nicht erfolgreichen Bereitstellung, sei es aufgrund von Problemen mit der bereitgestellten Anwendung oder den bereitgestellten Rezeptbüchern oder durch Probleme mit dem Bereitstellungsprozess selbst.

Der einfachste Ansatz besteht darin, den Standardbefehl "deploy" (für Anwendungen) oder den Befehl "update custom cookbooks" (für Rezeptbücher) auszuführen, wodurch das Update für jede Instance gleichzeitig bereitgestellt wird. Diese Methode ist einfach und schnell, es darf jedoch kein Fehler unterlaufen. Wenn die Bereitstellung fehlschlägt oder der aktualisierte Code Probleme aufweist, können alle Instances in Ihrem Produktions-Stack betroffen sein und Ihre Website potenziell unterbrechen oder außer Funktion setzen, bis das Problem behoben ist oder Sie auf eine frühere Version zurückgegangen sind.

Empfehlung: Verwenden Sie eine robuste Bereitstellungsstrategie, die es den Instances ermöglicht, die alte Code-Version noch so lange zur Anforderungsverarbeitung zu verwenden, bis sichergestellt ist, dass die Bereitstellung erfolgreich war und der eingehende Datenverkehr auf die neue Version umgestellt werden kann.

In den folgenden Abschnitten finden Sie zwei Beispiele für robuste Bereitstellungsstrategien und eine Besprechung, wie eine Backend-Datenbank während der Bereitstellung verwaltet werden kann. Zugunsten einer knappen Darstellung wird die Aktualisierung von Anwendungen beschrieben, aber Sie können ähnliche Strategien auch für Rezeptbücher verwenden.

Themen

• Verwenden einer fortlaufenden Bereitstellung
• Verwenden separater Stacks
• Verwalten einer Backend-Datenbank

Verwenden einer fortlaufenden Bereitstellung

Eine fortlaufende Bereitstellung aktualisiert die Anwendung für die Online-Anwendungsserver-Instances eines Stacks in mehreren Phasen. Mit jeder Phase aktualisieren Sie eine Teilmenge der Online-Instances und stellen sicher, dass das Update erfolgreich ist, bevor Sie die nächste Phase starten. Wenn Probleme auftreten, können die Instances den eingehenden Datenverkehr noch mit der alten Anwendungsversion bearbeiten, bis die Probleme gelöst sind.

Das folgende Beispiel geht davon aus, dass Sie die empfohlene Methode anwenden, die Anwendungsserver-Instances Ihres Stacks über mehrere Availability Zones zu verteilen.

Ausführen einer fortlaufende Bereitstellung

1. Wählen Sie auf der Seite Deploy App (App bereitstellen) die Option Advanced (Erweitert) und anschließend eine einzelne Anwendungsserver-Instance aus und stellen Sie die Anwendung für diese Instance bereit.

   Aus Sicherheitsgründen können Sie die Instance aus dem Load Balancer entfernen, bevor Sie die Anwendung bereitstellen. Auf diese Weise ist gewährleistet, dass die Benutzer nicht auf die aktualisierte Anwendung zugreifen können, so lange nicht geprüft wurde, ob sie ordnungsgemäß funktioniert. Wenn Sie Elastic Load Balancing verwenden, entfernen Sie die Instance mithilfe der Elastic Load Balancing-Konsole, CLI oder eines SDK aus dem Load Balancer.

2. Überprüfen Sie, ob die aktualisierte Anwendung ordnungsgemäß funktioniert und die Performance-Metriken der Instance akzeptabel sind.

   Wenn Sie die Instance von einem Elastic Load Balancing Load Balancer entfernt haben, verwenden Sie die Elastic Load Balancing Balancing-Konsole, CLI oder ein SDK, um sie wiederherzustellen. Die aktualisierte Anwendungsversion verarbeitet jetzt die Benutzeranforderungen.

3. Stellen Sie das Update für die übrigen Instances in der Availability Zone bereit und prüfen Sie, ob sie korrekt arbeiten und die Metriken akzeptabel sind.

4. Wiederholen Sie Schritt 3, Zone für Zone, für die übrigen Availability Zones des Stacks. Wenn Sie besonders vorsichtig sein möchten, wiederholen Sie die Schritte 1 bis 3.

Anmerkung

Wenn Sie einen Elastic Load Balancing Load Balancer verwenden, können Sie dessen Integritätsprüfung verwenden, um zu überprüfen, ob die Bereitstellung erfolgreich war. Stellen Sie in diesem Fall den Ping-Pfad auf eine Anwendung ein, die Abhängigkeiten überprüft und bestätigt, dass alles ordnungsgemäß funktioniert, und nicht einfach auf eine statische Datei, die nur bestätigt, dass der Anwendungsserver ausgeführt wird.

Verwenden separater Stacks

Eine weitere Vorgehensweise zur Verwaltung von Anwendungen besteht darin, einen separaten Stack für jede Lebenszyklusphase der Anwendung zu verwenden. Die verschiedenen Stacks werden manchmal auch als Umgebungen bezeichnet. Auf diese Weise können Sie Stacks entwickeln und testen, die nicht öffentlich zugänglich sind. Wenn Sie ein Update bereitstellen möchten, leiten Sie den Datenverkehr von dem Stack, auf dem sich die aktuelle Anwendungsversion befindet, auf den Stack um, auf dem die aktualisierte Anwendungsversion gehostet wird.

Themen

• Verwenden von Entwicklungs-, Staging- und Produktions-Stacks
• Verwenden einer blau-grünen Bereitstellungsstrategie

Verwenden von Entwicklungs-, Staging- und Produktions-Stacks

Der häufigste Ansatz verwendet die folgenden Stacks.

Entwicklungs-Stack

Verwenden Sie einen Entwicklungs-Stack für Aufgaben wie die Implementierung von neuen Funktionen oder zur Fehlerbehebung. Bei einem Entwicklungs-Stack handelt es sich im Wesentlichen um einen Prototypen-Stack für den Produktivbetrieb mit den gleichen Layern, Anwendungen, Ressourcen und so weiter, die auch auf Ihrem Produktions-Stack vorhanden sind. Da der Entwicklungs-Stack in der Regel nicht dieselbe Last bearbeiten muss wie der Stack für den Produktivbetrieb, können Sie weniger oder kleinere Instances verwenden.

Entwicklungs-Stacks sind nicht öffentlich. Sie steuern den Zugriff wie folgt:

• Beschränken Sie den Netzwerkzugriff durch Konfigurieren der Eingangsregeln für Sicherheitsgruppen des Anwendungsservers oder Load Balancers, sodass nur eingehende Anforderungen von angegebenen IP-Adressen oder Adressbereichen akzeptiert werden.

  Begrenzen Sie z.B. HTTP-, HTTPS- und SSH-Zugriffe auf Adressen in Ihrem Unternehmensadressbereich.

• Steuern Sie den Zugriff auf die AWS OpsWorks Stack-Management-Funktionen von Stacks, indem Sie die Seite „Berechtigungen“ des Stacks verwenden.

  Teilen Sie beispielsweise dem Entwicklungsteam eine Ebene zu, auf der es Berechtigungen verwalten kann und allen anderen Mitarbeiter eine Leseberechtigung.

Staging-Stack

Verwenden Sie einen Staging-Stack, um Kandidaten für einen aktualisierten Stack für den Produktivbetrieb zu testen und abzuschließen. Im Anschluss an die Entwicklung erstellen Sie einen Staging-Stack, indem Sie den Entwicklungs-Stack klonen. Führen Sie dann Ihre Test-Suite auf dem Staging-Stack aus und stellen Sie Updates bereit, um auftretende Stack-Probleme zu beheben.

Staging-Stacks sind ebenfalls nicht öffentlich. Sie steuern den Stack- und Netzwerk-Zugriff auf dieselbe Weise wie für den Entwicklungs-Stack. Beachten Sie, dass Sie beim Klonen eines Entwicklungsstapels, um einen Staging-Stack zu erstellen, die von AWS OpsWorks Stacks Permissions Management gewährten Berechtigungen klonen können. Allerdings hat das Klonen keine Auswirkungen auf Berechtigungen, die durch die IAM-Benutzerrichtlinien erteilt wurden. Zum Ändern dieser Berechtigungen müssen Sie eine IAM-Konsole, eine CLI oder ein SDK verwenden. Weitere Informationen finden Sie unter Verwalten von Benutzerberechtigungen.

Produktions-Stack

Der Produktions-Stack ist der öffentlich zugängliche Stack, der Ihre aktuelle Anwendung unterstützt. Wenn der Staging-Stack die Testphase durchlaufen hat, können Sie ihn für den Produktivbetrieb hochstufen und den alten Produktions-Stack deaktivieren. Ein Beispiel für diese Vorgehensweise finden Sie unter Verwenden einer blau-grünen Bereitstellungsstrategie.

Anmerkung

Anstatt die AWS OpsWorks Stacks-Konsole zum manuellen Erstellen von Stacks zu verwenden, erstellen Sie für jeden Stack eine AWS CloudFormation Vorlage. Dieser Ansatz bietet folgende Vorteile:

• Geschwindigkeit und Komfort — Wenn Sie die Vorlage starten, AWS CloudFormation wird der Stack automatisch erstellt, einschließlich aller erforderlichen Instanzen.

• Konsistenz — Speichern Sie die Vorlage für jeden Stack in Ihrem Quell-Repository, um sicherzustellen, dass Entwickler denselben Stack für denselben Zweck verwenden.

Verwenden einer blau-grünen Bereitstellungsstrategie

Die blau-grüne Bereitstellungsstrategie ist eine gängige Methode, um separate Stacks effizient zur Bereitstellung eines Anwendungs-Updates für die Produktion einzusetzen.

• Die blaue Umgebung ist der Produktions-Stack, der die aktuelle Anwendung hostet.

• Die grüne Umgebung ist der Staging-Stack, der die aktualisierte Anwendung hostet.

Wenn Sie bereit sind, die aktualisierte Anwendung zur Produktion bereitzustellen, leiten Sie das Datenaufkommen vom blauen Stack auf den grünen Stack um, der nun der neue Produktions-Stack ist. Anschließend können Sie den alten blauen Stack deaktivieren.

Das folgende Beispiel beschreibt, wie eine blaugrüne Bereitstellung mit AWS OpsWorks Stacks-Stacks in Verbindung mit Route 53 und einem Pool von Elastic Load Balancing-Load Balancing-Load Balancern durchgeführt wird. Vor dem Wechsel sollten Sie sicherstellen, dass die folgenden Schritte ausgeführt wurden:

• Das Anwendungs-Update auf dem grünen Stack hat die Tests bestanden und ist bereit für den Produktivbetrieb.

• Der grüne Stack ist identisch mit dem blauen Stack, abgesehen davon, dass er die aktualisierte Anwendung enthält und nicht öffentlich zugänglich ist.

  Beide Stacks haben dieselben Berechtigungen, die gleiche Anzahl und Art von Instances in jeder Ebene, dieselbe zeitbasierte und lastbasierte Konfiguration usw.

• Alle 24/7-Instances und geplanten, zeitbasierten Instances der grünen Stacks sind online.

• Sie verfügen über einen Pool von Elastic Load Balancing-Load Balancern, die dynamisch an eine Ebene in beiden Stacks angehängt und vorgewärmt werden können, um das erwartete Datenverkehrsvolumen zu bewältigen.

• Sie haben die Funktion für gewichtetes Routing von Route 53 verwendet, um einen Datensatz in einer Hosting-Zone zu erstellen, der Ihre gepoolten Load Balancer enthält.

• Sie haben dem Load Balancer, der an den Anwendungsserver-Layer des blauen Stacks angefügt ist, ein von null abweichendes Gewicht zugewiesen, und den nicht verwendeten Load Balancern ein Gewicht von null. Auf diese Weise wird sichergestellt, dass der Load Balancer des blauen Stacks den gesamten eingehenden Datenverkehr verarbeitet.

Umleiten der Benutzer auf den grünen Stack

1. Fügen Sie einen der ungenutzten Load Balancer des Pools an die Anwendungsserver-Ebene des grünen Stacks an. In einigen Szenarien, wie bei blitzartig auftretendem Datenverkehr oder wenn keine Lasttestkonfiguration möglich ist, um den Datenverkehr allmählich zu steigern, sollten Sie den Load Balancer vorwärmen, damit er den erwarteten Datenverkehr verarbeiten kann.

2. Nachdem alle Instances des grünen Stacks den Elastic Load Balancing Health Check bestanden haben, ändern Sie die Gewichtungen im Route 53-Datensatz, sodass der Load Balancer des grünen Stacks eine Gewichtung ungleich Null und der Load Balancer des blauen Stacks eine entsprechend reduzierte Gewichtung hat. Wir empfehlen, dass Sie zunächst den grünen Stack eine kleine Menge an Anforderungen von vielleicht 5% verarbeiten lassen und der blaue Stack den Rest verarbeitet. Sie verfügen jetzt über zwei Produktions-Stacks, wobei der grüne Stack einige der eingehenden Anforderungen verarbeitet und der blaue Stack den Rest.

3. Überwachen Sie die Performance-Metriken des grüne Stacks. Wenn sie akzeptabel sind, erhöhen Sie das Gewicht des grüne Stacks, sodass er ca. 10% des eingehenden Datenverkehrs verarbeiten kann.

4. Wiederholen Sie Schritt 3, bis der grüne Stack ca. die Hälfte des eingehenden Datenverkehrs verarbeitet. Mögliche Probleme sollten zu diesem Zeitpunkt deutlich geworden sein, sodass Sie, wenn die Performance des grünen Stacks akzeptabel ist, den Vorgang abschließen können, indem Sie das Gewicht des blauen Stacks auf null reduzieren. Der grüne Stack ist jetzt der neue blaue Stack und verarbeitet den gesamten eingehenden Datenverkehr.

5. Trennen Sie den Load Balancer aus der alten Anwendungsserver-Ebene des blauen Stacks und geben Sie ihn zurück an den Pool.

6. Obwohl der alte blaue Stack keine Benutzeranforderungen mehr verarbeitet, empfehlen wir, ihn noch eine Weile zu behalten, falls es Probleme mit dem neuen blauen Stack geben sollte. In diesem Fall können Sie das Update rückgängig machen, indem Sie den Vorgang umkehren und den eingehenden Datenverkehr auf den alten blauen Stack umleiten. Wenn Sie sicher sind, dass der neue blaue Stack akzeptabel arbeitet, setzen Sie den alten blauen Stack außer Betrieb.

Verwalten einer Backend-Datenbank

Wenn Ihre Anwendung von einer Backend-Datenbank abhängt, müssen Sie von der alten Anwendung zur neuen wechseln. AWS OpsWorks Stacks unterstützt die folgenden Datenbankoptionen.

Amazon RDS-Ebene

Mit einer Amazon Relational Database Service (Amazon RDS) -Layer erstellen Sie die RDS-DB-Instance separat und registrieren sie dann bei Ihrem Stack. Sie können eine RDS-DB-Instance immer nur jeweils mit einem Stack registrieren, aber Sie können eine RDS-DB-Instance von einem Stack auf einen anderen umschalten.

AWS OpsWorks Stacks installiert eine Datei mit den Verbindungsdaten auf Ihren Anwendungsservern in einem Format, das von Ihrer Anwendung problemlos verwendet werden kann. AWS OpsWorks Stacks fügt außerdem die Datenbankverbindungsinformationen zu den Stackkonfigurations- und Bereitstellungsattributen hinzu, auf die über Rezepte zugegriffen werden kann. Sie können Verbindungsdaten für Anwendungen auch mithilfe von JSON bereitstellen. Weitere Informationen finden Sie unter Verbinden mit einer Datenbank.

Das Aktualisieren einer Anwendung, die von einer Datenbank abhängig ist, birgt zwei grundlegende Herausforderungen:

• Sicherzustellen, dass alle Transaktionen während des Übergangs ordnungsgemäß aufgezeichnet werden und gleichzeitig Race-Bedingungen zwischen den neuen und alten Anwendungsversionen zu vermeiden.

• Den Übergang so zu gestalten, dass die Auswirkungen auf die Leistungsfähigkeit Ihrer Website begrenzt sind und Ausfallzeiten minimiert werden oder gar nicht auftreten.

Wenn Sie die in diesem Abschnitt beschriebenen Bereitstellungsstrategien verwenden, können Sie nicht einfach die Datenbank von der alten Anwendung trennen und der neuen anfügen. Beide Anwendungsversionen werden während des Übergangs parallel ausgeführt und müssen Zugriff auf die gleichen Daten haben. Im Folgenden werden zwei Ansätze zur Übergangsverwaltung beschrieben, die beide Vorteile haben, aber auch Herausforderungen mit sich bringen.

Ansatz 1: Beide Anwendungen mit derselben Datenbank verbinden

Vorteile

• Es gibt keine Ausfallzeiten während des Übergangs.

  Eine Anwendung stoppt schrittweise den Zugriff auf die Datenbank, während die andere schrittweise übernimmt.

• Sie müssen keine Daten zwischen zwei Datenbanken synchronisieren.

Herausforderungen

• Beide Anwendungen greifen auf dieselbe Datenbank zu. Sie müssen also den Zugriff verwalten, um zu verhindern, dass Daten verloren gehen oder beschädigt werden.

• Sie müssen auf ein neues Datenbankschema migrieren, die alte Anwendungsversion muss das neue Schema verwenden können.

Wenn Sie separate Stacks verwenden, ist dieser Ansatz wahrscheinlich am besten für Amazon RDS geeignet, da die Instance nicht dauerhaft an einen bestimmten Stack gebunden ist und von Anwendungen, die auf verschiedenen Stacks ausgeführt werden, aufgerufen werden kann. Es ist jedoch nicht möglich, eine RDS-DB-Instance mit mehr als einem Stack gleichzeitig zu registrieren. Daher müssen Sie Verbindungsdaten für beide Anwendungen zur Verfügung stellen, z. B. durch die Verwendung von JSON. Weitere Informationen finden Sie unter Verwenden von benutzerdefinierten Rezepten.

Wenn Sie ein fortlaufendes Upgrade verwenden, werden die alte und die neue Anwendungsversion auf demselben Stack gehostet, sodass Sie entweder eine Amazon RDS- oder eine MySQL-Schicht verwenden können.

Ansatz 2: Jede Anwendungsversion mit einer eigenen Datenbank ausstatten

Vorteile

• Jede Version verfügt über eine eigene Datenbank, sodass die Schemata nicht kompatibel sein müssen.

Herausforderungen

• Die Daten beim Übergang zwischen den beiden Datenbanken ohne Datenverlust oder -beschädigung zu synchronisieren.

• Sicherzustellen, dass der Synchronisierungsvorgang nicht zu erheblichen Ausfallzeiten führt oder die Leistung der Website nicht erheblich beeinträchtigt wird.

Wenn Sie separate Stacks verwenden, hat jeder seine eigene Datenbank. Wenn Sie eine fortlaufende Bereitstellung ausführen, können Sie dem Stack zwei Datenbanken anfügen, eine für jede Anwendung. Wenn die alten und neuen Anwendungen kein kompatibles Datenbankschema haben, ist dieser Ansatz besser.

Empfehlung: Im Allgemeinen empfehlen wir die Verwendung einer Amazon RDS-Schicht als Backend-Datenbank einer Anwendung, da diese flexibler ist und für jedes Übergangsszenario verwendet werden kann. Weitere Informationen zum Umgang mit Übergängen finden Sie im Amazon RDS-Benutzerhandbuch.