Kostenlos bei AWS einsteigen

Kostenloses Konto erstellen

Das kostenlose Kontingent für AWS umfasst für Amazon Relational Database Service (RDS) ein Jahr lang jeden Monat 750 Micro-DB-Instance-Stunden, 20 GB Speicher und 20 GB für Backups.

Details zum kostenlosen Kontingent für AWS anzeigen »


F: Was ist Amazon RDS?

Amazon Relational Database Service (Amazon RDS) ist ein verwalteter Service zum einfachen Einrichten, Betreiben und Skalieren einer relationalen Datenbank in der Cloud. Sie stellt kostengünstige und anpassbare Kapazitäten zur Verfügung und erledigt gleichzeitig zeitraubende Datenbankverwaltungsaufgaben, sodass Sie sich stärker auf Ihre Anwendungen und Ihr Unternehmen konzentrieren können.

Amazon RDS bietet Ihnen Zugriff auf den Funktionsumfang einer vertrauten MySQL-, MariaDB-, Oracle-, SQL-Server- oder PostgreSQL-Datenbank. Das bedeutet, dass der Code, die Anwendungen und die Tools, die Sie heute mit Ihren bestehenden Datenbanken nutzen, nahtlos mit Amazon RDS funktionieren sollten. Amazon RDS kann Ihre Datenbank automatisch sichern und Ihre Datenbank-Software mit der jeweils aktuellen Version auf dem neuesten Stand halten. Ein weiterer Vorteil für Sie ist die flexible Skalierung der Rechenressourcen oder der Speicherkapazität für die Instance Ihrer relationalen Datenbank. Darüber hinaus können Sie mit Amazon RDS einfach mithilfe von Replikation die Datenbankverfügbarkeit und die Widerstandsfähigkeit Ihrer Daten verbessern oder über Kapazitätsgrenzen einer einzelnen Datenbank-Instance hinaus skalieren, wenn Sie Datenbank-Arbeitslasten mit umfassenden Lesevorgängen haben. Wie bei allen Amazon Web Services fallen keine Vorabkosten an und Sie zahlen nur für die Ressourcen, die Sie tatsächlich nutzen.

F: Welche relationalen Datenbank-Engines werden von Amazon RDS unterstützt?

Amazon RDS unterstützt die Datenbank-Engines Amazon Aurora, MySQL, MariaDB, Oracle, SQL Server und PostgreSQL.

F: Was verwaltet Amazon RDS für mich?

Amazon RDS verwaltet die mit der Einrichtung einer relationalen Datenbank verbundenen Arbeitsschritte, von der Bereitstellung der gewünschten Infrastrukturkapazität bis hin zur Installation der Datenbank-Software. Sobald Ihre Datenbank einsatzbereit ist, automatisiert Amazon RDS allgemeine Verwaltungsaufgaben wie die Durchführung von Backups und das Patching der Software, mit der die Datenbank betrieben wird. Bei optionalen Multi-AZ-Bereitstellungen verwaltet Amazon RDS auch die synchrone Datenreplikation über mehrere Availability Zones mit automatischem Failover.

Dank des nativen Datenbankzugriffs in Amazon RDS interagieren Sie mit der Software der relationalen Datenbank auf die übliche Weise. Das bedeutet, dass Sie immer noch für die Verwaltung der anwendungsspezifischen Datenbankeinstellungen verantwortlich sind. Sie müssen das relationale Schema entwickeln, das am besten für Ihren Anwendungsfall geeignet ist, und zudem die Leistung Ihrer Datenbank für die Auftragsabläufe Ihrer Anwendung optimieren.

F: Wann sollte ich Amazon RDS und wann Amazon EC2-AMIs für relationale Datenbanken verwenden?

Amazon Web Services bietet eine Reihe verschiedener Datenbanklösungen für Entwickler an. Mit Amazon RDS kann eine voll funktionsfähige relationale Datenbank ausgeführt und gleichzeitig die Datenbankverwaltung vereinfacht werden. Mit dem Einsatz einer unserer zahlreichen AMIs für relationale Datenbanken in Amazon EC2 können Sie zudem Ihre eigene relationale Datenbank in der Cloud betreiben. Zwischen diesen Alternativen gibt es wichtige Unterschiede, daher sollte gut überlegt sein, welche für Ihre Bedürfnisse am besten geeignet ist. Unter Cloud-Datenbanken mit AWS erfahren Sie mehr darüber, welche Lösung am besten für Sie geeignet ist.

F: Was sind die ersten Schritte mit Amazon RDS?

Um sich für Amazon RDS anzumelden, müssen Sie über ein Amazon Web Services-Konto verfügen. Erstellen Sie ein Konto, wenn Sie noch keines haben. Nach der Anmeldung lesen Sie die Dokumentation zu Amazon RDS, die das Handbuch "Erste Schritte" enthält.

Amazon RDS gehört zum kostenlosen Kontingent von AWS, sodass neue AWS-Kunden den verwalteten Datenbankservice in der Cloud zunächst kostenlos nutzen können.


F: Was ist eine Datenbank-Instance (DB-Instance)?

Man kann sich eine DB-Instance als eine Datenbank-Umgebung in der Cloud vorstellen, die über die vom Benutzer festgelegten Rechen- und Speicherressourcen verfügt. Mithilfe der AWS-Managementkonsole, der Amazon RDS-APIs und der AWS-Befehlszeilenschnittstelle können Sie DB-Instances erstellen und löschen, Infrastrukturattribute der DB-Instance(s) definieren bzw. weiterentwickeln und Zugriff und Sicherheit steuern. Sie können eine oder mehrere DB-Instances ausführen. Jede DB-Instance kann je nach Engine-Typ ein(e) oder mehrere Datenbanken bzw. Datenbankschemas unterstützen.  

F: Wie erstelle ich eine DB-Instance?

DB-Instances sind einfach zu erstellen. Sie können hierfür entweder die AWS-Managementkonsole, Amazon RDS-APIs oder die AWS-Befehlszeilenschnittstelle verwenden. Um eine DB-Instance über die AWS-Managementkonsole zu starten, klicken Sie auf "RDS" und dann auf der Registerkarte Instances auf Launch DB Instance. Hier können Sie die Parameter für Ihre DB-Instance festlegen, einschließlich der DB-Engine und der -Version, des Lizenzmodells, Instance-Typs, Speichertyps und der Speichermenge sowie der Master-Benutzeranmeldedaten.

Darüber hinaus haben Sie die Möglichkeit, die Backup-Aufbewahrungsrichtlinie, das bevorzugte Backup-Fenster und das Fenster für geplante Aktualisierungen für Ihre DB-Instance zu ändern. Alternativ können Sie Ihre DB-Instance auch mithilfe der API CreateDBInstance oder über den Befehl "create-db-instance" erstellen.

F: Wie kann ich auf meine laufende DB-Instance zugreifen?

Sobald Ihre DB-Instance verfügbar ist, können Sie deren Endpunkt über die DB-Instance-Beschreibung in der AWS-Managementkonsole, in der API DescribeDBInstances oder im Befehl "describe-db-instances" abrufen. Mithilfe dieses Endpunkts können Sie die für eine direkte Verbindung zu Ihrer DB-Instance erforderliche Zeichenfolge erstellen und dabei Ihr bevorzugtes Datenbank-Tool bzw. Ihre bevorzugte Programmiersprache verwenden. Um für Ihre ausgeführte DB-Instance Netzwerkanfragen zu ermöglichen, müssen Sie den Zugriff autorisieren. Eine ausführliche Anleitung zur Erstellung der Verbindungszeichenfolge sowie Hinweise zu den ersten Schritten finden Sie im Handbuch "Erste Schritte".

F: Wie viele DB-Instances kann ich mit Amazon RDS ausführen?

Standardmäßig können Kunden über bis zu 40 Amazon RDS-DB-Instances verfügen. Von diesen 40 können bis zu 10 Oracle- oder SQL Server-DB-Instances unter das Modell "Lizenz enthalten" fallen. Alle 40 können gemäß dem "BYOL"-Modell (Verwendung der eigenen Lizenz) für Amazon Aurora, MySQL, MariaDB, PostgreSQL und Oracle genutzt werden. Beachten Sie, dass RDS for SQL Server auf 30 Datenbanken pro DB-Instance beschränkt ist.

Wenn Sie für Ihre Anwendung mehr DB-Instances benötigen, können Sie über dieses Formular weitere DB-Instances beantragen.

F: Wie viele Datenbanken oder Schemas kann ich innerhalb einer DB-Instance ausführen?

  • RDS for Amazon Aurora: Kein von der Software auferlegter Grenzwert
  • RDS for MySQL: Kein von der Software auferlegter Grenzwert
  • RDS for MariaDB: Kein von der Software auferlegter Grenzwert
  • RDS for Oracle: 1 Datenbank pro Instance; kein von der Software auferlegter Grenzwert für die Anzahl der Schemas pro Datenbank
  • RDS for SQL Server: 30 Datenbanken pro Instance
  • RDS for PostgreSQL: Kein von der Software auferlegter Grenzwert

F: Wie importiere ich Daten in eine Amazon RDS-DB-Instance?

Es gibt verschiedene einfache Möglichkeiten, Daten in Amazon RDS zu importieren, z. B. die Hilfsprogramme mysqldump oder mysqlimport für MySQL, Data Pump, Import/Export oder SQL Loader für Oracle, den Import/Export-Assistenten, Vollbackupdateien (.bak-Dateien) und das Massenkopierprogramm (BCP) für SQL Server oder pg_dump für PostgreSQL. Weitere Informationen zum Im- und Exportieren von Daten finden Sie im Datenimporthandbuch für MySQL, Datenimporthandbuch für Oracle, Datenimporthandbuch für SQL Server oder Datenimporthandbuch für PostgreSQL.

Außerdem kann Ihnen der AWS Database Migration Service bei der einfachen und sicheren Migration von Datenbanken in AWS helfen.

F: Was ist ein Wartungs- bzw. Aktualisierungsfenster? Ist meine DB-Instance während Wartungsarbeiten verfügbar?

Das Amazon RDS-Wartungs- bzw. Aktualisierungsfenster bietet Ihnen die Möglichkeit, zu kontrollieren, wann Modifizierungen der DB-Instance, Upgrades der Datenbank-Engine-Version oder Software-Patches vorgenommen werden, wenn diese angefordert wurden oder notwendig sind. Wenn ein Wartungsereignis für eine bestimmte Woche geplant ist, wird es innerhalb des von Ihnen festgelegten Wartungs- bzw. Aktualisierungszeitfensters ausgelöst.

Wartungsarbeiten, bei denen Amazon RDS Ihre DB-Instance offline schalten muss, sind Skalierungen des Datenverarbeitungsbetriebs (die in der Regel nur wenige Minuten in Anspruch nehmen), Upgrades der Datenbank-Engine-Version sowie erforderliche Software-Patches. Erforderliche Software-Patches werden automatisch und nur für Patches, die relevant für die Sicherheit und Zuverlässigkeit sind, angesetzt. Diese Patches erfolgen in unregelmäßigen Abständen (in der Regel einmal alle paar Monate) und sollten selten mehr als einen Bruchteil Ihres Wartungs- bzw. Aktualisierungsfensters in Anspruch nehmen.

Falls Sie bei der Erstellung Ihrer DB-Instance kein bevorzugtes wöchentliches Wartungs- bzw. Aktualisierungsfenster festlegen, wird ein 30-minütiger Standardwert zugewiesen. Wenn Sie den Wartungszeitpunkt ändern möchten, können Sie dazu Ihre DB-Instance in der AWS-Managementkonsole, in der API ModifyDBInstance oder im Befehl "modify-db-instance" modifizieren. Dabei haben Sie die Möglichkeit, für die einzelnen DB-Instances unterschiedliche bevorzugte Wartungsfenster anzugeben.

Wenn Sie Ihre DB-Instance als Multi-AZ-Bereitstellung ausführen, können Sie die Auswirkungen einer Wartung weiter verringern. Weitere Informationen zu Wartungsvorgängen finden Sie im Amazon RDS-Benutzerhandbuch.

F: Was soll ich tun, wenn die Ausführung meiner Abfragen langsam erscheint?

Für Produktionsdatenbanken sollten Sie Enhanced Monitoring aktivieren, um Zugriff auf über 50 Metriken für CPU, Arbeitsspeicher, Dateisystem und Datenträger-E/A bereitzustellen. Sie können diese Funktionen für jede Instance einzeln aktivieren und die Granularität (Minimalwert 1 Sekunde) auswählen. Eine erhöhte CPU-Auslastung kann die Abfrageleistung verringern. In diesem Fall könnte sich eine Skalierung Ihrer DB-Instance-Klasse anbieten. Weitere Informationen zur Überwachung der DB-Instance finden Sie im Amazon RDS-Benutzerhandbuch.

Falls Sie RDS for MySQL oder MariaDB verwenden, können Sie auf die langsamen Abfrageprotokolle für die Datenbank zugreifen, um zu ermitteln, ob langsame SQL-Abfragen vorhanden sind und, falls dies der Fall ist, die Leistungsmerkmale der einzelnen Abfragen feststellen. Sie können den DB-Parameter "slow_query_log" bestimmen und die Tabelle "mysql.slow_log" abfragen, um die langsamen SQL-Abfragen zu überprüfen. Weitere Informationen finden Sie im Amazon RDS-Benutzerhandbuch.

Falls Sie RDS for Oracle verwenden, können Sie die Oracle-Ablaufdateidaten verwenden, um langsame Abfragen zu identifizieren. Weitere Informationen zum Zugriff auf Ablaufdateidaten finden Sie im Amazon RDS-Benutzerhandbuch.

Falls Sie RDS for SQL Server verwenden, können Sie die Client-seitigen SQL Server-Ablaufverfolgungsprotokolle nutzen, um langsame Abfragen zu identifizieren. Weitere Informationen zum Zugriff auf die Daten in der Ablaufverfolgungsdatei auf Serverseite finden Sie im Amazon RDS-Benutzerhandbuch.


F: Welche relationalen Datenbank-Engine-Versionen werden von Amazon RDS unterstützt?

In der Dokumentation der einzelnen Engines finden Sie eine Liste der unterstützten Datenbank-Engine-Versionen:

F: Wie unterscheidet Amazon RDS zwischen Haupt- und Nebenversionen der DB-Engine?

Detaillierte Informationen zur Versionsnummerierung finden Sie auf der Seite für häufig gestellte Fragen der jeweiligen Amazon RDS-Datenbank-Engine.

F: Stellt Amazon RDS Richtlinien zur Unterstützung neuer DB-Engine-Versionen zur Verfügung?

Amazon RDS unterstützt mit der Zeit auch neue Haupt- und Nebenversionen von Datenbank-Engines. Die Anzahl der unterstützten neuen Versionen hängt von der Häufigkeit und den Inhalten der veröffentlichten Updates und Patches des Herstellers bzw. der Entwicklerorganisation der Engine ab, und selbstverständlich wird jede neue Version eingehend von unseren Datenbanktechnikern geprüft, bevor eine Unterstützung erfolgt. Als allgemeine Leitlinie können wir aber sagen, dass wir versuchen, neue Engine-Versionen innerhalb von 5 Monaten nach ihrer allgemeinen Verfügbarkeit zu unterstützen.

F: Wie kann ich festlegen, welche unterstützte DB-Engine-Version ich zur Ausführung meiner DB-Instance nutzen möchte?

Sie können alle aktuell unterstützten (Haupt- oder Neben-)Versionen festlegen, wenn Sie eine neue DB-Instance über die Operation Launch DB Instance in der AWS-Managementkonsole oder die API CreateDBInstance erstellen. Dabei ist zu beachten, dass nicht jede Version einer Datenbank-Engine in jeder AWS-Region verfügbar ist.

F: Wie steuere ich, ob und wann die Engine-Version meiner DB-Instance auf die jeweils neuen unterstützten Versionen aktualisiert wird?

Amazon RDS bemüht sich, Ihre Datenbank-Instances auf dem neuesten Stand zu halten, indem Ihnen neuere Versionen der unterstützten Datenbank-Engines zur Verfügung gestellt werden. Nachdem eine neue Version einer Datenbank-Engine vom Hersteller oder von der Entwicklerorganisation veröffentlicht wurde, wird diese von unseren Datenbanktechnikern gründlich geprüft, bevor sie in Amazon RDS zur Verfügung gestellt wird.

Wir empfehlen Ihnen, Ihre Datenbank-Instance stets in der jeweils aktuellsten Nebenversion zu betreiben, da diese die neuesten Sicherheits- und Funktionsaktualisierungen enthält. Upgrades für Nebenversionen enthalten, anders als Upgrades für Hauptversionen, nur Datenbankänderungen, die mit älteren Nebenversionen (derselben Hauptversion) der Datenbank-Engine abwärtskompatibel sind.

Wenn eine neue Nebenversion keine Aktualisierungen enthält, die RDS-Kunden zugutekommen würden, entscheiden wir uns eventuell, diese nicht in RDS zur Verfügung zu stellen. Kurz nachdem eine neue Nebenversion in RDS zur Verfügung gestellt wurde, wird diese als bevorzugte Nebenversion für neue DB-Instances definiert.

Um eine Datenbank-Instance manuell auf eine unterstützte Engine-Version zu aktualisieren, kann der Befehl Modify DB Instance in der AWS-Managementkonsole oder die API ModifyDBInstance verwendet und der Parameter DB Engine Version auf die gewünschte Version eingestellt werden. Standardmäßig wird das Upgrade während des nächsten Wartungsfensters angewendet. Sie können das Upgrade jedoch auch sofort ausführen, indem Sie die Option Apply Immediately in der API der Konsole auswählen.

Wenn wir feststellen, dass eine neue Nebenversion für eine Engine im Vergleich zu einer zuvor veröffentlichten Nebenversion wichtige Bugfixes enthält, planen wir automatische Upgrades für DB-Instances, bei denen die Option Auto Minor Version Upgrade auf "Yes" gesetzt ist. Diese Upgrades werden so geplant, dass sie im Rahmen der von den Kunden festgelegten Wartungs- und Aktualisierungsfenster durchgeführt werden.

Wir kündigen geplante Upgrades mindestens 30 Tage im Voraus im Amazon RDS-Forum und über E-Mail-Benachrichtigungen an unsere Kunden an. Wir planen diese so, dass Sie darum herum planen können. Denn für das Upgrade einer DB-Engine-Version ist eine gewisse Ausfallzeit erforderlich, auch bei Multi-AZ-Instances. Falls Sie automatische Versions-Upgrades für Nebenversionen lieber ausstellen möchten, können Sie dies tun, indem Sie die Option "Auto Minor Version Upgrade" auf "No" setzen.

Wenn ein Upgrade auf die nächste Nebenversion bei RDS for Oracle und RDS for SQL Server den Wechsel auf eine andere Edition erfordert, werden möglicherweise auch bei aktivierter Option Auto Minor Version Upgrade keine automatischen Upgrades geplant. In diesen Fällen wird im Einzelfall entschieden, ob automatische Upgrades geplant werden sollten oder nicht.

Da Upgrades auf neue Hauptversionen gewisse Kompatibilitätsrisiken mit sich bringen, erfolgen diese nicht automatisch. Sie müssen von Ihnen eingeleitet werden (es sei denn, eine Hauptversion ist veraltet; siehe unten).

Informationen zum Aktualisieren einer DB-Instance auf eine neue DB-Engine-Version finden Sie im Amazon RDS-Benutzerhandbuch.

F: Kann ich neue Versionen für meine DB-Instance testen, bevor ich ein Upgrade durchführe?

Ja. Erstellen Sie hierfür einen DB-Snapshot Ihrer bestehenden DB-Instance, erstellen Sie aus dem DB-Snapshot eine neue DB-Instance und initiieren Sie dann ein Versions-Upgrade für die neue DB-Instance. Nun können Sie ungefährdet mit der aktualisierten Kopie Ihrer DB-Instance experimentieren, bevor Sie entscheiden, ob Sie Ihre ursprüngliche DB-Instance aktualisieren möchten oder nicht.

Weitere Informationen zur Wiederherstellung eines DB-Snapshots finden Sie im Amazon RDS-Benutzerhandbuch.

F: Stellt Amazon RDS Richtlinien zur Einstellung der Unterstützung für derzeit unterstützte, veraltete Versionen der Datenbank-Engine zur Verfügung?

  • Wir versuchen, Hauptversionen (z. B. MySQL 5.6, PostgreSQL 9.6) über einen Zeitraum von mindestens drei Jahren ab der ersten Einführung für Amazon RDS zu unterstützen.
  • Nebenversionen (z. B. MySQL 5.6.37, PostgreSQL 9.6.1) sollen nach ihrer ersten Einführung für Amazon RDS mindestens ein Jahr lang unterstützt werden.

Von Zeit zu Zeit stellen wir die Unterstützung für Haupt- oder Nebenversionen der Engines ein. Bei Hauptversionen ist dies üblicherweise der Fall, wenn die Version in die Phase des verlängerten Supports eingetreten ist oder wenn für die Version keine Software-Patches oder Sicherheitsupdates mehr zur Verfügung gestellt werden. Bei Nebenversionen ist dies der Fall, wenn eine Nebenversion erhebliche Fehler oder Sicherheitsprobleme enthält, die in einer späteren Nebenversion entfernt wurden.

Wenngleich wir versuchen, diese Richtlinien einzuhalten, ist es mitunter möglich, dass bestimmte Haupt- und Nebenversionen schneller nicht mehr unterstützt werden, z. B. bei Sicherheitsproblemen. In einem solchen unwahrscheinlichen Fall aktualisiert Amazon RDS Ihre Datenbank-Engine automatisch, um das Problem zu beheben. Bestimmte Umstände können, je nach Problemstellung, andere Abläufe erforderlich machen.

F: Was passiert, wenn eine Version für eine RDS-DB-Engine als veraltet eingestuft wird?

Wenn eine Nebenversion einer Datenbank-Engine in Amazon RDS veraltet ist, beginnen wir drei (3) Monate nach der Ankündigung mit den automatischen Upgrades. Am Ende dieses Zeitraums werden alle Instances, auf denen immer noch die veraltete Nebenversion ausgeführt wird, im Rahmen der geplanten Wartungsfenster für das automatische Upgrade auf die neueste unterstützte Nebenversion eingeplant.

Wenn eine Hauptversion einer Datenbank-Engine in Amazon RDS als veraltet eingestuft wird, räumen wir Ihnen nach der Benachrichtigung über die Einstellung der Unterstützung einen Übergangszeitraum von mindestens sechs (6) Monaten ein, in dem Sie das Upgrade auf eine unterstützte Hauptversion initiieren können. Nach Ablauf dieses Zeitraums wird im Rahmen geplanter Wartungsfenster ein automatisches Upgrade auf die nächsthöhere Hauptversion auf alle Instances, auf denen noch die veraltete Version ausgeführt wird, angewendet.

Sobald eine Haupt- oder Nebenversion einer Datenbank-Engine in Amazon RDS nicht mehr unterstützt wird, wird jede DB-Instance, die von einem DB-Snapshot wiederhergestellt wird, der in der nicht mehr unterstützten Version erstellt wurde, sofort automatisch auf eine aktuell unterstützte Version aktualisiert.


F: Wie wird mir die Nutzung von Amazon RDS in Rechnung gestellt?

Sie zahlen nur für das, was Sie tatsächlich nutzen. Es gibt keine Mindest- oder Einrichtungsgebühren. Ihre Nutzung wird folgendermaßen abgerechnet:

  • DB-Instance-Stunden – diese basieren auf der Klasse (z. B. db.t2.micro, db.m4.large) der genutzten DB-Instance. Angebrochene DB-Instance-Stunden werden als volle Stunden in Rechnung gestellt.
  • Speicherung (pro GB und Monat) – die Speicherkapazität, die Sie Ihrer DB-Instance zur Verfügung gestellt haben. Bei einer Skalierung der zur Verfügung gestellten Speicherkapazität im laufenden Monat werden die Gebühren entsprechend anteilig erfasst.
  • E/A-Anforderungen pro Monat – Gesamtanzahl Ihrer E/A-Speicheranforderungen (nur für Amazon RDS-Magnetfestplatten und Amazon Aurora)
  • Bereitgestellte IOPS pro Monat – Bereitgestellte IOPS-Rate, unabhängig von den verbrauchten IOPS (nur für bereitgestellte IOPS-Speicher (SSD) in Amazon RDS)
  • Backup-Speicher – der Backup-Speicher ist der Speicher für Ihre automatisierten Datenbank-Backups und jegliche von Kunden initiierten Datenbank-Snapshots. Wenn Sie den Aufbewahrungszeitraum Ihrer Backups erhöhen oder zusätzliche Datenbank-Snapshots erstellen, belegt Ihre Datenbank dementsprechend mehr Backup-Speicher.
  • Datenübertragung – ein- und ausgehende Internet-Datenübertragung Ihrer DB-Instance.

Informationen zu den Preisen von Amazon RDS finden Sie auf der Amazon RDS-Produktseite im Abschnitt zu den Preisen.

F: Wann beginnt und endet die Fakturierung meiner Amazon RDS-DB-Instances?

Die Fakturierung einer DB-Instance beginnt zu dem Zeitpunkt, ab dem die DB-Instance verfügbar ist. Die Fakturierung wird so lange fortgesetzt, bis die DB-Instance durch Löschen oder aufgrund eines Ausfalls beendet wird.

F: Wie werden abrechenbare Amazon RDS-Instance-Stunden definiert?

Die Abrechnung erfolgt für jede Stunde, in der die DB-Instance in einem verfügbaren Zustand ausgeführt wird. Wenn Sie für die DB-Instance keine Gebühren mehr zahlen möchten, müssen Sie sie anhalten oder löschen, damit Ihnen keine weiteren Instance-Stunden in Rechnung gestellt werden. Angebrochene DB-Instance-Stunden werden als volle Stunden in Rechnung gestellt.

F: Wie wird eine angehaltene DB-Instance abgerechnet?

Während Ihre Datenbank-Instance angehalten ist, werden Ihnen der bereitgestellte Speicher (einschließlich bereitgestellter IOPS) und der Backup-Speicher (einschließlich manueller Snapshots und automatischer Backups innerhalb des angegebenen Aufbewahrungsfensters), aber nicht die DB-Instance-Stunden in Rechnung gestellt.

F: Warum ist mein zusätzlicher Backup-Speicher teurer als der zugewiesene DB-Instance-Speicher?

Der Speicher, der Ihrer DB-Instance für Ihre primären Daten zur Verfügung gestellt wird, befindet sich in einer einzigen Availability Zone. Beim Backup Ihrer Datenbank werden die Backup-Daten (einschließlich der Transaktionsprotokolle) für eine höhere Datenbeständigkeit georedundant in mehreren Availability Zones repliziert. Der Preis für die Backup-Speicherung, die über die kostenlose Zuordnung hinausgeht, spiegelt diese zusätzliche Replikation wider, die durchgeführt wird, um die Beständigkeit Ihrer kritischen Backups zu maximieren.

F: Wie werden Bereitstellungen von Multi-AZ-DB-Instances abgerechnet?

Wenn Sie festlegen, dass Ihre DB-Instance als Multi-AZ-Bereitstellung genutzt wird, wird entsprechend den Multi-AZ-Preisen, die auf der Seite zu den Amazon RDS-Preisen einzusehen sind, abgerechnet. Der Multi-AZ-Abrechnung liegen folgende Faktoren zugrunde:

  • Multi-AZ-DB-Instance-Stunden – diese basieren auf der Klasse (z. B. db.t2.micro, db.m4.large) der genutzten DB-Instance. Wie auch bei Standardbereitstellungen in einer einzelnen Availability Zone werden angebrochene DB-Instance-Stunden als ganze Stunden in Rechnung gestellt. Wenn Sie innerhalb einer angebrochenen Stunde zwischen der Standardbereitstellung und der Multi-AZ-Bereitstellung für Ihre DB-Instance wechseln, werden beide jeweils geltenden Gebühren für diese Stunde in Rechnung gestellt.
  • Bereitgestellter Speicherplatz (für Multi-AZ-DB-Instances) – wenn Sie innerhalb einer beliebigen Stunde zwischen der Standardbereitstellung und der Multi-AZ-Bereitstellung für Ihre DB-Instance wechseln, wird die höhere Speichergebühr für diese Stunde in Rechnung gestellt.
  • E/A-Anforderungen pro Monat – Gesamtanzahl Ihrer E/A-Speicheranforderungen. Bei Multi-AZ-Bereitstellungen werden mehr E/A-Anforderungen verbraucht als bei standardmäßigen DB-Instance-Bereitstellungen, wobei der genaue Verbrauch von den Schreib-/Leseraten Ihrer Datenbank abhängt. Die E/A-Vorgänge im Zusammenhang mit Datenbank-Updates werden verdoppelt, da Amazon RDS Ihre Daten synchron in der Standby-DB-Instance repliziert. Die E/A-Auslastung für Lesevorgänge bleibt unverändert.
  • Backup-Speicher – der Bedarf an Backup-Speicher bleibt gleich, egal, ob Sie eine standardmäßige oder eine Multi-AZ-Bereitstellung für Ihre DB-Instance nutzen. Backups werden einfach von der Standby-Replica angefertigt, um E/A-Unterbrechungen bei den primären Daten der DB-Instance zu vermeiden.
  • Datenübertragung – der beim Replizieren der Daten zwischen Primär-Instance und Replica anfallende Datenverkehr wird Ihnen nicht in Rechnung gestellt. Die Internet-Übertragung von Daten Ihrer DB-Instance wird in beide Richtungen genauso abgerechnet wie bei standardmäßigen Bereitstellungen.

F: Sind Steuern bereits in den Preisen enthalten?

Falls nicht anders angegeben, gelten unsere Preise zuzüglich anfallender Steuern und Abgaben, u. a. MwSt. und Umsatzsteuer. Bei Kunden mit japanischer Rechnungsadresse unterliegt die Nutzung von AWS-Services der japanischen Verbrauchssteuer. Weitere Informationen.


F: Welchen Umfang hat das kostenlose AWS-Kontingent für Amazon RDS?

Das kostenlose AWS-Kontingent für Amazon RDS sieht die kostenlose Nutzung von Single-AZ Micro-DB-Instances mit MySQL, MariaDB, PostgreSQL, Oracle (Lizenzmodell "Bring-Your-Own-License [BYOL], Verwendung der eigenen Lizenz") und SQL Server Express Edition vor. Das kostenlose Nutzungskontingent ist auf 750 Instance-Stunden pro Monat begrenzt. Kunden erhalten außerdem kostenlos 20 GB SSD-Mehrzweck-Datenbankspeicher und 20 GB Backup-Speicher pro Monat.

F: Für welche Zeitspanne steht AWS-Kunden das kostenlose AWS-Kontingent für Amazon RDS zur Verfügung?

Neuen AWS-Kunden steht das kostenlose Kontingent von AWS 12 Monate zur Verfügung. Auf der Seite mit den häufig gestellten Fragen zum kostenlosen AWS-Kontingent finden Sie weitere Informationen.

F: Kann ein AWS-Kunde im Rahmen des kostenlosen AWS-Nutzungskontingents für Amazon RDS mehr als eine DB-Instance ausführen?

Ja. AWS-Kunden können mehrere Single-AZ Micro-DB-Instances gleichzeitig ausführen und dafür das kostenlose AWS-Kontingent für Amazon RDS in Anspruch nehmen. Wenn die Nutzung jedoch für alle Amazon RDS Single-AZ Micro-DB-Instances für alle in Frage kommenden Datenbanktypen und Regionen 750 Instance-Stunden überschreitet, werden die üblichen Amazon RDS-Gebühren in Rechnung gestellt.

Beispiel: Wenn Sie zwei Single-AZ Micro-DB-Instances je 400 Stunden lang in einem Monat ausführen, kommen Sie auf eine Instance-Nutzungsdauer von 800 Stunden, von denen 750 Stunden kostenlos sind. Die verbleibenden 50 Stunden werden Ihnen zum Amazon RDS-Standardpreis in Rechnung gestellt.

F: Gelten die 750 Instance-Stunden für AWS-Kunden im Rahmen des kostenlosen AWS-Kontingents für jede der Micro-DB-Instances (MySQL, MariaDB, PostgreSQL, Oracle oder SQL Server) separat?

Nein. Ein Kunde mit Berechtigung für das kostenlose Kontingent für AWS kann Micro-Instances, die entweder mit MySQL, PostgreSQL, Oracle oder SQL Server Express Edition ausgeführt werden, nur insgesamt bis zu 750 Stunden nutzen. Wenn die Nutzung für alle Amazon RDS Single-AZ Micro-DB-Instances für alle in Frage kommenden Datenbank-Engines und Regionen 750 Instance-Stunden überschreitet, werden die üblichen Amazon RDS-Gebühren in Rechnung gestellt.

F: Steht das kostenlose AWS-Kontingent für Amazon RDS in allen AWS-Regionen zur Verfügung?

Das kostenlose AWS-Kontingent für Amazon RDS steht in allen AWS-Regionen außer GovCloud (US) zur Verfügung.

F: Was wird mir in Rechnung gestellt, wenn meine Nutzung von Instance-Stunden das kostenlose Kontingent überschreitet?

Die Stunden, die das kostenlose Kontingent überschreiten, werden Ihnen zu Amazon RDS-Standardpreisen in Rechnung gestellt. Einzelheiten finden Sie auf der Seite mit den Amazon RDS-Preisen.


F: Was ist eine Reserved Instance (RI)?

Mit Amazon RDS Reserved Instances haben Sie die Option, eine DB-Instance für ein Jahr oder drei Jahre zu reservieren und im Gegenzug einen erheblichen Rabatt im Vergleich zum Preis für On-Demand-Instances für diese DB-Instance zu erhalten. Es gibt drei RI-Zahlungsoptionen (keine Vorauszahlung, teilweise Vorauszahlung, komplette Vorauszahlung), die es Ihnen ermöglichen, den Betrag Ihrer Vorauszahlung und Ihren effektiven Stundenpreis aufeinander abzustimmen.  

F: Wie unterscheiden sich Reserved Instances von On-Demand-DB-Instances?

Funktionell gesehen sind Reserved Instances und On-Demand-DB-Instances genau gleich. Der einzige Unterschied besteht in der Abrechnung Ihrer DB-Instance(s). Bei Reserved Instances erwerben Sie eine Reservierung für ein Jahr oder drei Jahre und sichern sich damit eine niedrigere stündliche Nutzungsgebühr (verglichen mit On-Demand-DB-Instances) für die Dauer des Nutzungszeitraums. Soweit Sie Reserved Instances nicht in einer Region kaufen, werden alle DB-Instances zu den stündlichen On-Demand-Nutzungsgebühren verrechnet.

F: Wie kann ich Reserved Instances erwerben und erstellen?

Sie können eine Reserved Instance im Bereich "Reserved Instance" der AWS-Managementkonsole für Amazon RDS erwerben. Alternativ können Sie unter Verwendung der Amazon RDS-API oder der AWS-Befehlszeilenschnittstelle eine Liste der zum Kauf verfügbaren Reservierungen aufrufen und anschließend eine DB-Instance-Reservierung kaufen.

Nach dem Kauf der Reservierung unterscheidet sich die Nutzung einer reservierten DB-Instance nicht von der Nutzung einer On-Demand-DB-Instance. Starten Sie eine DB-Instance unter Verwendung derselben Klasse, Engine und Region, die Sie bei der Reservierung abgegeben haben. Solange Ihre Reservierung aktiv ist, erhalten Sie von Amazon RDS den entsprechenden reduzierten Stundensatz für die neue DB-Instance.

F: Ist in Reserved Instances auch eine Kapazitätsreservierung enthalten?

Die Reserved Instances von Amazon RDS werden eher für eine Region als für eine bestimmte Availability Zone gekauft. Da RIs nicht spezifisch für eine Availability Zone sind, stellen sie keine Kapazitätsreservierungen dar. Das bedeutet, dass auch dann, wenn die Kapazität in einer Availability Zone begrenzt ist, Reservierungen in der Region gekauft werden können und der Nachlass auf eine entsprechende Nutzung in Availability Zones innerhalb dieser Region angewendet wird.

F: Wie viele Reserved Instances kann ich erwerben?

Sie können bis zu 40 reservierte DB-Instances erwerben. Wenn Sie mehr als 40 DB-Instances ausführen möchten, füllen Sie bitte das Anfrageformular für Amazon RDS-DB-Instances aus.

F: Was muss ich tun, wenn ich eine vorhandene DB-Instance durch eine Reserved Instance abdecken möchte?

Erwerben Sie einfach eine DB-Instance-Reservierung derselben DB-Instance-Klasse, derselben DB-Engine, derselben Multi-AZ-Option und demselben Lizenzmodell in derselben Region wie die DB-Instance, die Sie aktuell ausführen und reservieren möchten. Nach dem erfolgreichen Erwerb der Reservierung wendet Amazon RDS die neue stündliche Nutzungsgebühr automatisch auf Ihre bestehende DB-Instance an.

F: Wann beginnt der Nutzungszeitraum, wenn ich mich für eine Reserved Instance registriere? Was geschieht mit meiner DB-Instance nach Ablauf des Zeitraums?

Preisänderungen für Reserved Instances werden aktiviert, sobald Ihr Antrag während der Zahlungsautorisierung eingegangen ist. Sie können den Status Ihrer Reservierung auf der Seite zu den AWS-Kontoaktivitäten oder über die API DescribeReservedDBInstances oder den Befehl "describe-reserved-db-instances" verfolgen. Falls die einmalige Zahlung nicht erfolgreich bis zur nächsten Abrechnungsperiode autorisiert werden kann, wird der rabattierte Preis nicht übernommen.

Nach Ablauf Ihres Reservierungszeitraums gilt für Ihre Reserved Instance wieder der entsprechende On-Demand-Nutzungstarif Ihrer DB-Instance-Klasse und -Region.

F: Wie kann ich steuern, welche DB-Instances nach dem Tarif für Reserved Instances berechnet werden?

Die Amazon RDS-Vorgänge zum Erstellen, Ändern und Löschen von DB-Instances sind für On-Demand-Instances und Reserved Instances identisch. Bei der Verarbeitung Ihrer Abrechnung wendet unser System automatisch Ihre Reservierung(en) an, sodass alle berechtigten DB-Instances nach dem reduzierten Stundentarif für reservierte DB-Instances abgerechnet werden.

F: Wenn ich meine DB-Instance-Klasse nach oben oder unten skaliere, was geschieht dann mit meiner Reservierung?

Jede Reservierung ist mit den folgenden Attributen verknüpft: DB-Engine, DB-Instance-Klasse, Multi-AZ-Bereitstellungsoption, Lizenzmodell und Region.

Mit einer aktiven DB-Instance beliebiger Größe erhalten Sie innerhalb derselben Instance-Familie (z. B. M4, T2 oder R3) für die gleiche Datenbank-Engine und Region automatisch eine für die Größenflexibilität (MySQL, MariaDB, PostgreSQL, Amazon Aurora oder Oracle "Bring Your Own License") anwendbare Reservierung für eine DB-Engine und ein Lizenzmodell. Diese Reservierung gilt darüber hinaus auch für DB-Instances in Single-AZ- oder Multi-AZ-Bereitstellungen.

Gehen wir beispielsweise davon aus, dass Sie eine MySQL-Reservierung des Typs db.m4.2xlarge gekauft haben. Wenn Sie sich nun entscheiden, die aktive DB-Instance auf eine db.m4.4xlarge-Instance zu skalieren, wird die Hälfte der Nutzung der größeren DB-Instance bereits durch den Vorzugspreis für diese Reserved Instance abgedeckt.

Führen Sie dagegen eine DB-Engine oder ein Lizenzmodell aus, für die keine Größenflexibilität gilt (Microsoft SQL Server oder Oracle "License Included"), kann jede Reservierung für die Dauer des Vertrags nur auf eine DB-Instance mit den gleichen Merkmalen angewendet werden. Wenn Sie sich entscheiden, ein beliebiges Attribut Ihrer DB-Instance vor dem Ende des Reservierungszeitraums zu modifizieren, gelten wieder die normalen On-Demand-Tarifsätze für diese DB-Instance.

Weitere Informationen zur Größenflexibilität finden Sie im Amazon RDS-Benutzerhandbuch.

F: Kann ich eine Reserved Instance aus einer Region oder Availability Zone in eine andere verschieben?

Jede Reserved Instance ist an eine bestimmte Region gebunden, die für die Lebensdauer der Reservierung festgelegt ist und nicht geändert werden kann. Jede Reservierung kann jedoch in beliebigen AZs der zugeordneten Region verwendet werden.

F: Sind Reserved Instances für Multi-AZ-Bereitstellungen verfügbar?

Ja. Wenn Sie die API DescribeReservedDBInstancesOfferings oder den Befehl "describe-reserved-db-instances-offerings" aufrufen, machen Sie die Multi-AZ-Optionen ausfindig, die bei den zum Erwerb verfügbaren DB-Instance-Konfigurationen aufgelistet sind. Wenn Sie eine Reservierung für eine DB-Instance mit synchroner Replikation über mehrere Availability Zones erwerben möchten, spezifizieren Sie eines dieser Angebote im API-Befehl "PurchaseReservedDBInstancesOffering".

F: Sind Reserved Instances für Read Replicas verfügbar?

Eine DB-Instance-Reservierung kann auch auf eine Read Replica angewandt werden, sofern DB-Instance-Klasse und -Region identisch sind. Bei der Verarbeitung Ihrer Abrechnung wendet unser System automatisch Ihre Reservierung(en) an, sodass alle berechtigten DB-Instances nach dem reduzierten Stundentarif für Reserved Instances abgerechnet werden.

F: Kann ich eine Reservierung stornieren?

Nein. Sie können Ihre reservierte DB-Instance nicht stornieren und die Einmalzahlung (falls durchgeführt) wird nicht zurückerstattet. Sie zahlen unabhängig von der tatsächlichen Nutzung weiter für jede Stunde Ihrer Vertragslaufzeit für die reservierte DB-Instance.

F: Wie wirken sich die Zahlungsoptionen auf meine Rechnung aus?

Wenn Sie eine RI mit der Zahlungsoption "Komplette Vorauszahlung" erwerben, zahlen Sie in einer Vorauszahlung für die gesamte Laufzeit der RI. Bei Wahl der Option "Keine Vorauszahlung" leisten Sie vorab keine Zahlung. Der gesamte Wert der RI vom Typ "Keine Vorauszahlung" wird auf alle Stunden in der Laufzeit verteilt und Ihnen wird jede Stunde der Laufzeit ungeachtet der Nutzung in Rechnung gestellt. Die dritte Zahlungsoption heißt "Teilweise Vorauszahlung". Sie leisten eine niedrige Vorauszahlung und anschließend wird Ihnen ein niedriger Stundentarif für die Dauer der Laufzeit in Rechnung gestellt.


F: Wie bestimme ich, welche anfängliche DB-Instance-Klasse und Speicherkapazität für meine Anforderungen angemessen sind?

Um Ihre anfängliche DB-Instance-Klasse und Speicherkapazität auszuwählen, sollten Sie den Rechen- und Speicherbedarf der betreffenden Anwendung abschätzen. Informationen zu den verfügbaren DB-Instance-Klassen finden Sie im Amazon RDS-Benutzerhandbuch.

F: Wie skaliere ich die mit meiner Amazon RDS-Datenbank-Instance verbundenen Rechenressourcen und/oder Speicherkapazitäten?

Sie können die Rechenressourcen und die Speicherkapazität, die Ihrer DB-Instance zugeordnet ist, skalieren, indem Sie die AWS-Managementkonsole (gewünschte DB-Instance auswählen und auf die Schaltfläche Modify klicken), die RDS-API oder die AWS-Befehlszeilenschnittstelle verwenden. Speicher- und CPU-Ressourcen können durch eine Änderung der DB-Instance-Klasse modifiziert werden, und der verfügbare Speicher wird geändert, wenn Sie Ihre Speicherzuteilung ändern. Bitte beachten Sie, dass alle gewünschten Änderungen der DB-Instance-Klasse oder des zugeteilten Speichers während des festgelegten Wartungs- bzw. Aktualisierungsfensters durchgeführt werden. Alternativ können Sie ein "apply-immediately"-Flag setzen, um die angeforderte Skalierung sofort durchzuführen. Beachten Sie, dass in diesem Fall alle anderen noch ausstehenden Systemänderungen ebenfalls durchgeführt werden.

Mit Amazon CloudWatch können Sie die Auslastung der Rechen- und Speicherkapazitäten Ihrer DB-Instance ohne zusätzliche Gebühren überwachen. Sie können Metriken wie die CPU-Auslastung, die Speicherauslastung oder den Netzwerkverkehr abrufen. Klicken Sie hierfür auf die Registerkarte "Monitoring" Ihrer DB-Instance in der AWS-Managementkonsole oder verwenden Sie die Amazon CloudWatch-APIs. Weitere Informationen zur Überwachung Ihrer aktiven DB-Instances finden Sie im Amazon RDS-Benutzerhandbuch.

Beachten Sie für SQL Server, dass Amazon RDS aufgrund der Einschränkungen bei der Erweiterbarkeit von Speicher mit Striping-Technologie, der an eine Windows Server -Umgebung angeschlossen ist, eine Speichervergrößerung derzeit nicht unterstützt. Amazon plant, diese Funktionalität künftig zu unterstützen, und empfiehlt die Bereitstellung von Speicher basierend auf dem erwarteten künftigen Speicherbedarf. Wenn es in der Zwischenzeit erforderlich wird, den Speicherplatz einer SQL Server-DB-Instance zu erweitern, müssen Sie die Daten exportieren, eine neue DB-Instance mit mehr Speicherplatz erstellen und die Daten in diese importieren. Weitere Informationen finden Sie im Datenimporthandbuch für SQL Server.

F: Welche Hardware-Konfiguration ist für den Amazon RDS-Speicher zu empfehlen?

Amazon RDS verwendet EBS-Datenträger zum Speichern von Datenbank und Protokoll. Je nach der Größe des erforderlichen Speichers verteilt Amazon RDS Daten automatisch per Striping auf mehrere EBS-Datenträger, um die IOPS-Leistung zu verbessern. Bei einer vorhandenen MySQL- oder Oracle-DB-Instance stellen Sie eventuell eine Verbesserung der E/A-Kapazitäten fest, wenn Sie Ihren Speicherplatz erweitern. Sie können die der DB-Instance zugewiesene Speicherkapazität erweitern. Verwenden Sie hierfür die AWS-Managementkonsole, die API ModifyDBInstance oder den Befehl "modify-db-instance".

Beachten Sie jedoch für SQL Server, dass Amazon RDS aufgrund der Einschränkungen bei der Erweiterbarkeit von Speicher mit Striping-Technologie, der an eine Windows Server-Umgebung angeschlossen ist, eine Speichervergrößerung derzeit nicht unterstützt.

Weitere Informationen finden Sie unter Speicher für Amazon RDS.

F: Ist meine DB-Instance während der Skalierung weiterhin verfügbar?

Ihre DB-Instance ist auch während einer Skalierung der ihr zugeteilten Speicherkapazität verfügbar. Bei einer Skalierung der zur Verfügung stehenden Rechenressourcen Ihrer DB-Instance ist die Datenbank jedoch während der Änderung der DB-Instance-Klasse vorübergehend nicht verfügbar. Der Zeitraum der Nichtverfügbarkeit dauert in der Regel nur wenige Minuten und liegt innerhalb des Wartungs- bzw. Aktualisierungsfensters für Ihre DB-Instance, es sei denn, Sie legen fest, dass die Änderung sofort durchgeführt werden soll.

F: Wie kann ich meine DB-Instance so skalieren, dass sie die größte DB-Instance-Klasse und maximale Speicherkapazität übersteigt?

Amazon RDS unterstützt eine Reihe verschiedener DB-Instance-Klassen und Speicherzuteilungen, die diverse Anwendungsanforderungen erfüllen. Wenn die von Ihrer Anwendung benötigten Rechenressourcen die höchste DB-Instance-Klasse bzw. die maximale Speicherzuteilung übersteigen, können Sie eine Partitionierung implementieren und so die Daten auf mehrere DB-Instances verteilen.

F: Was ist Amazon RDS-Standardspeicher (SSD)?

Amazon RDS-Standardspeicher (SSD) ist für ein breites Spektrum von Datenbankarbeitslasten mit mäßigen E/A-Anforderungen geeignet. Mit einer Basisleistung von 3 IOPS/GB und der Fähigkeit kurzzeitiger Spitzenleistung von bis zu 3 000 IOPS bietet diese Speicheroption eine vorhersehbare Leistung, die die Anforderungen der meisten Anwendungen erfüllt.

F: Was ist bereitgestellter IOPS-Speicher (SSD) in Amazon RDS?

Bereitgestellter IOPS-Speicher (SSD) in Amazon RDS ist eine durch SSD unterstützte Speicheroption, die so konzipiert wurde, dass sie eine schnelle, vorhersehbare und konsistente E/A-Leistung bietet. Bei bereitgestelltem IOPS-Speicher (SSD) in Amazon RDS geben Sie bei der Erstellung einer DB-Instance eine IOPS-Rate an und Amazon RDS stellt diese IOPS-Rate dann für die Lebensdauer dieser DB-Instance bereit. Bereitgestellter IOPS-Speicher (SSD) in Amazon RDS ist für E/A-intensive, transaktionale Datenbankarbeitslasten (OLTP) optimiert. Nähere Informationen finden Sie im Amazon RDS-Benutzerhandbuch.

F: Was ist Amazon RDS-Magnetspeicher?

Amazon RDS-Magnetspeicher ist bei kleinen Datenbankarbeitslasten nützlich, bei denen weniger häufig auf die Daten zugegriffen wird. Für Produktionsdatenbank-Instances ist Magnetspeicher nicht empfehlenswert.

F: Wie entscheide ich mich für einen Speichertyp in Amazon RDS?

Wählen Sie den Speichertyp, der für Ihre Arbeitslast am besten geeignet ist.

  • Hochleistungs-OLTP-Arbeitslasten: Bereitgestellter IOPS-Speicher (SSD) in Amazon RDS
  • Datenbanken mit mäßigen E/A-Anforderungen: Amazon RDS-Standardspeicher (SSD)

F: Welche minimale und maximale IOPS-Kapazität wird von Amazon RDS unterstützt?

Die von Amazon RDS unterstützte IOPS-Kapazität hängt von der jeweiligen Datenbank-Engine ab. Nähere Informationen finden Sie im Amazon RDS-Benutzerhandbuch.

F: Was ist der Unterschied zwischen automatischen Backups und DB-Snapshots?

Amazon RDS bietet zwei verschiedene Methoden zum Backup und zur Wiederherstellung Ihrer DB-Instance(s) an: automatische Backups und Datenbank-Snapshots (DB-Snapshots).

Die Amazon RDS-Funktion für automatisierte Backups ermöglicht zeitpunktbezogene Wiederherstellungen Ihrer DB-Instance. Wenn automatisierte Backups für Ihre DB-Instance aktiviert sind, führt Amazon RDS täglich automatisch einen vollständigen Snapshot Ihrer Daten aus (im Rahmen Ihres festgelegten Backup-Fensters) und generiert Transaktionsprotokolle (zu den Updates Ihrer DB-Instance). Wenn Sie eine Wiederherstellung für einen bestimmten Zeitpunkt initiieren, werden die Transaktionsprotokolle für das passendste Backup angewandt, um Ihre DB-Instance zum gewünschten Zeitpunkt zurückzusetzen. Amazon RDS bewahrt Backups einer DB-Instance für einen begrenzten, benutzerdefinierten Zeitraum (den "Aufbewahrungszeitraum") auf. Dieser liegt standardmäßig bei sieben Tagen, kann aber auf bis zu 35 Tage verlängert werden. Sie können eine Wiederherstellung zu jeder beliebigen Sekunde Ihres Wiederherstellungszeitraums bis zum letztmöglichen Zeitpunkt initiieren. Sie können die API DescribeDBInstances verwenden, um den letztmöglichen Wiederherstellungszeitpunkt für Ihre DB-Instance zu nutzen. Dieser liegt in der Regel innerhalb der letzten fünf Minuten. Alternativ können Sie den letztmöglichen Wiederherstellungszeitpunkt für eine DB-Instance auch finden, indem Sie die Instance in der AWS-Managementkonsole auswählen und unter der Registerkarte "Description" im unteren Arbeitsbereich der Konsole nachsehen.

DB-Snapshots werden vom Benutzer initiiert und ermöglichen es Ihnen, Ihre DB-Instance in einem bekannten Zustand beliebig oft zu sichern und dann diesen spezifischen Zustand jederzeit wiederherzustellen. DB-Snapshots können mit der AWS-Managementkonsole, der API CreateDBSnapshot oder dem Befehl "create-db-snapshot" erstellt werden. Sie werden so lange aufbewahrt, bis sie explizit von Ihnen gelöscht werden.

Die von Amazon RDS zur Aktivierung automatischer Backups ausgeführten Snapshots stehen zum Kopieren (über die AWS-Konsole oder den Befehl "copy-db-snapshot") oder für die Snapshot-Wiederherstellung zur Verfügung. Sie ermitteln sie anhand des "automatisierten" Snapshot-Typs. Außerdem können Sie den Zeitpunkt ermitteln, zu dem der Snapshot erstellt wurde, indem Sie das Feld "Zeitpunkt der Snapshot-Erstellung" anzeigen. Die Kennzeichnung des "automatisierten" Snapshots enthält alternativ ebenfalls den Zeitpunkt (UTC), zu dem der Snapshot erstellt wurde.

Hinweis: Wenn Sie einen Wiederherstellungsvorgang zu einem bestimmten Zeitpunkt oder mithilfe eines DB-Snapshots durchführen, wird eine neue DB-Instance mit einem neuen Endpunkt erstellt (die alte DB-Instance kann auf Wunsch gelöscht werden). Auf diese Weise haben Sie die Möglichkeit, mehrere DB-Instances aus einem bestimmten DB-Snapshot oder zu einem bestimmten Zeitpunkt zu erstellen.

F: Muss ich Backups für meine DB-Instance aktivieren oder geschieht dies automatisch?

Automatische Backups Ihrer DB-Instance sind in Amazon RDS standardmäßig aktiviert. Es gilt ein Aufbewahrungszeitraum von sieben Tagen. Der kostenlose Backup-Speicher ist auf die Größe der bereitgestellten Datenbank begrenzt und gilt nur für aktive DB-Instances. Wenn Sie beispielsweise über einen bereitgestellten Datenbankspeicher von monatlich 100 GB verfügen, bieten wir Ihnen ohne Aufpreis 100 GB Backup-Speicher pro Monat. Mit der API CreateDBInstance (bei der Erstellung einer neuen DB-Instance) oder der API ModifyDBInstance (bei einer bestehenden DB-Instance) kann der Aufbewahrungszeitraum für Backups über den standardmäßigen Zeitraum hinaus verlängert werden. Setzen Sie hierzu mithilfe der APIs den Parameter für den Aufbewahrungszeitraum von 1 auf die gewünschte Anzahl an Tagen. Weitere Informationen zu automatischen Backups finden Sie im Amazon RDS-Benutzerhandbuch.

F: Was ist ein Backup-Fenster und wofür wird es benötigt? Steht meine Datenbank während des Backup-Fensters zur Verfügung?

Beim bevorzugten Backup-Fenster handelt es sich um den vom Benutzer festgelegten Zeitraum, in dem das Backup der DB-Instance durchgeführt wird. Amazon RDS nutzt diese regelmäßigen Daten-Backups in Verbindung mit Ihren Transaktionsprotokollen, um Ihnen die Möglichkeit zu geben, Ihre DB-Instance zu jeder Sekunde des Aufbewahrungszeitraums bis zum letztmöglichen Wiederherstellungszeitpunkt (üblicherweise innerhalb der letzten Minuten) wiederherzustellen. Während des Backup-Fensters kann die Speicher-E/A kurz unterbrochen werden, während der Backup-Prozess initialisiert wird (normalerweise innerhalb weniger Sekunden). Möglicherweise tritt auch kurzzeitig eine höhere Latenz auf. Bei Multi-AZ-DB-Bereitstellungen gibt es keine E/A-Unterbrechungen, da das Backup aus der Standby-Replica angefertigt wird.

F: Wo werden meine automatisierten Backups und DB-Snapshots gespeichert und wie kann ich deren Aufbewahrung verwalten?

Amazon RDS-DB-Snapshots und automatisierte Backups werden in S3 gespeichert.

Unter Verwendung der AWS-Managementkonsole, der API ModifyDBInstance oder des Befehls "modify-db-instance" können Sie den Aufbewahrungszeitraum für automatische Backups verwalten, indem Sie den Parameter "RetentionPeriod" ändern. Wenn Sie automatische Backups vollständig deaktivieren möchten (was nicht empfohlen wird), setzen Sie den Aufbewahrungszeitraum auf 0. Sie können Ihre benutzererstellten DB-Snapshots über den Bereich "Snapshots" in der Amazon RDS-Konsole verwalten. Alternativ können Sie eine Liste der vom Benutzer für eine bestimmte DB-Instance erstellten DB-Snapshots anzeigen, indem Sie die API DescribeDBSnapshots oder den Befehl "describe-db-snapshots" verwenden und die Snapshots über die API DeleteDBSnapshot oder den Befehl "delete-db-snapshot" löschen.

F: Warum sind mehr automatisierte DB-Snapshots als Tage im Aufbewahrungszeitraum für meine DB-Instance vorhanden?

Es ist nicht ungewöhnlich, dass ein oder zwei automatisierte DB-Snapshots mehr als die Anzahl der Tage im Aufbewahrungszeitraum vorhanden sind. Es wird ein zusätzlicher automatisierter Snapshot beibehalten, um eine Wiederherstellung zu einem bestimmten Zeitpunkt für jeden Zeitpunkt im Aufbewahrungszeitraum ausführen zu können. Wenn das Backup-Fenster z. B. auf einen Tag festgelegt wird, werden zwei automatisierte Snapshots benötigt, um Wiederherstellungen zu jedem Zeitpunkt in den vorhergehenden 24 Stunden zu ermöglichen. Außerdem wird möglicherweise ein weiterer automatisierter Snapshot angezeigt, da immer erst ein neuer automatisierter Snapshot erstellt wird, bevor der älteste automatisierte Snapshot gelöscht wird.

F: Was passiert mit meinen Backups und DB-Snapshots, wenn ich meine DB-Instance lösche?

Wenn Sie eine DB-Instance löschen, können Sie vor dem Löschvorgang einen letzten DB-Snapshot erstellen. In diesem Fall können Sie diesen DB-Snapshot zum Wiederherstellen der gelöschten DB-Instance zu einem späteren Zeitpunkt nutzen. Amazon RDS behält diesen letzten vom Benutzer erstellten DB-Snapshot zusammen mit allen anderen manuell erstellten DB-Snapshots bei, nachdem die DB-Instance gelöscht wurde. Auf der Seite mit den Preisen finden Sie Details zu den Kosten des Speicherns von Backups.

Beim Löschen der DB-Instance werden automatisierte Backups ebenfalls gelöscht. Nach dem Löschen der DB-Instance werden nur manuell erstellte DB-Snapshots beibehalten.


F: Was ist die Amazon Virtual Private Cloud (VPC) und wie wird sie mit Amazon RDS zusammen verwendet?

Mit Amazon VPC können Sie eine virtuelle Netzwerkumgebung in einem privaten, isolierten Bereich der AWS Cloud erstellen. Hier haben Sie die vollständige Kontrolle über private IP-Adressbereiche, Subnetze, Routing-Tabellen und Netzwerk-Gateways. Mit Amazon VPC definieren Sie eine virtuelle Netzwerktopologie und passen die Netzwerkkonfiguration an Ihre Bedürfnisse an, sodass sie einem herkömmlichen IP-Netzwerk ähnelt, das Sie in Ihrem eigenen Rechenzentrum betreiben könnten.

VPC eignet sich besonders, wenn Sie eine öffentlich zugängliche Webanwendung ausführen, aber nicht öffentlich zugängliche Backend-Server in einem privaten Subnetz beibehalten möchten. Sie können ein öffentlich zugängliches Subnetz für Ihre Webserver erstellen, das Zugang zum Internet hat, und Ihre Backend-RDS-DB-Instances in einem nicht öffentlich zugänglichen Subnetz ohne Internetzugriff einrichten. Weitere Informationen zu Amazon VPC erhalten Sie im Amazon Virtual Private Cloud-Benutzerhandbuch.

F: Inwiefern unterscheidet sich die Nutzung von Amazon RDS in einer VPC von der Nutzung auf der EC2-Classic-Plattform (ohne VPC)?

Wurde Ihr AWS-Konto vor dem 4. Dezember 2013 erstellt, können Sie Amazon RDS möglicherweise in einer Amazon Elastic Compute Cloud (EC2)-Classic-Umgebung ausführen. Die grundlegenden Funktionen von Amazon RDS sind dieselben, unabhängig davon, ob EC2-Classic oder EC2-VPC genutzt wird. Amazon RDS verwaltet Backups, Software-Patches, automatische Fehlererkennung, Read Replicas und Wiederherstellungen unabhängig davon, ob Ihre DB-Instances innerhalb oder außerhalb einer VPC bereitgestellt werden. Weitere Informationen zu den Unterschieden zwischen EC2-Classic und EC2-VPC finden Sie in der EC2-Dokumentation.

F: Was ist eine DB-Subnetzgruppe und warum benötige ich eine?

Eine DB-Subnetzgruppe ist eine Sammlung von Subnetzen, die Sie für Ihre RDS-DB-Instances in einer VPC verwenden können. Jede DB-Subnetzgruppe sollte mindestens über ein Subnetz für jede Availability Zone in einer bestimmten Region verfügen. Wenn Sie eine DB-Instance in VPC erstellen, müssen Sie eine DB-Subnetzgruppe auswählen. Amazon RDS verwendet diese DB-Subnetzgruppe und Ihre bevorzugte Availability Zone dann zur Auswahl eines Subnetzes und einer IP-Adresse in diesem Subnetz. Amazon RDS erstellt und ordnet Ihrer DB-Instance eine Elastic Network-Schnittstelle mit dieser IP-Adresse zu.

Es wird dringend empfohlen, dass Sie den DNS-Namen für die Verbindung mit Ihrer DB-Instance verwenden, da sich die zugrunde liegende IP-Adresse ändern kann (z. B während eines Failovers).

Bei Multi-AZ-Bereitstellungen kann Amazon RDS durch die Definition eines Subnetzes für alle Availability Zones in einer Region bei Bedarf eine neue Standby-Instance in einer anderen Availability Zone erstellen. Sie müssen dies sogar für Einzel-AZ-Bereitstellungen vornehmen, nur für den Fall, dass Sie sie zu einem späteren Zeitpunkt in Multi-AZ-Bereitstellungen umwandeln möchten.

F: Wie kann ich eine Amazon RDS-DB-Instance in VPC erstellen?

Eine Schritt-für-Schritt-Anleitung zu diesem Prozess finden Sie im Amazon RDS-Benutzerhandbuch unter Creating a DB Instance in a VPC.

F: Wie kontrolliere ich den Netzwerkzugriff auf meine DB-Instances?

Im Amazon RDS-Benutzerhandbuch finden Sie im Abschnitt Security Groups Informationen zu den verschiedenen Möglichkeiten, den Zugriff auf Ihre DB-Instances zu steuern.

F: Wie kann ich eine Verbindung mit einer RDS-DB-Instance in VPC herstellen?

Auf DB-Instances, die innerhalb einer VPC bereitgestellt werden, kann von in derselben VPC bereitgestellten EC2-Instances zugegriffen werden. Wenn diese EC2-Instances in einem öffentlichen Subnetz mit zugeordneten Elastic-IP-Adressen bereitgestellt werden, können Sie über das Internet auf die EC2-Instances zugreifen.

Auf in einer VPC bereitgestellte DB-Instances kann über das Internet oder von EC2-Instances außerhalb der VPC über VPN oder Bastion-Hosts zugegriffen werden, die Sie in Ihrem öffentlichen Subnetz oder über die Amazon RDS-Option "Publicly Accessible" starten können:

  • Wenn Sie einen Bastion-Host verwenden möchten, müssen Sie ein öffentliches Subnetz mit einer EC2-Instance einrichten, die als SSH-Bastion fungiert. Dieses öffentliche Subnetz muss über ein Internet-Gateway und Routing-Regeln verfügen, die erlauben, dass der Datenverkehr über den SSH-Host gerichtet wird. Dieser muss dann Anforderungen an die private IP-Adresse Ihrer RDS-DB-Instance weiterleiten.
  • Erstellen Sie für eine öffentliche Anbindung Ihre DB-Instances mit auf "Yes" festgelegter Option "Publicly Accessible". Wenn "Publicly Accessible" aktiv ist, kann standardmäßig von außerhalb Ihrer VPC voll auf Ihre DB-Instances in der VPC zugegriffen werden. Das heißt, dass Sie kein VPN bzw. keinen Bastion-Host konfigurieren müssen, um den Zugriff auf Ihre Instances zuzulassen.

Sie können auch ein VPN-Gateway einrichten, durch das Ihr Unternehmensnetzwerk in Ihre VPC ausgedehnt wird und das einen Zugriff auf die RDS-DB-Instance in dieser VPC ermöglicht. Weitere Informationen hierzu finden Sie im Amazon VPC-Benutzerhandbuch.

Es wird dringend empfohlen, dass Sie den DNS-Namen für die Verbindung mit Ihrer DB-Instance verwenden, da sich die zugrunde liegende IP-Adresse ändern kann (z. B während eines Failovers).

F: Kann ich meine vorhandenen DB-Instances außerhalb der VPC in meine VPC verschieben?

Falls sich Ihre DB-Instance nicht in einer VPC befindet, können Sie sie einfach mithilfe der AWS-Managementkonsole in eine VPC verschieben. Weitere Informationen hierzu finden Sie im Amazon RDS-Benutzerhandbuch. Sie können auch einen Snapshot Ihrer DB-Instance außerhalb der VPC erstellen und ihn in der VPC wiederherstellen, indem Sie die gewünschte DB-Subnetzgruppe angeben. Sie können auch eine "Wiederherstellung zu einem bestimmten Zeitpunkt" vornehmen.

F: Kann ich meine vorhandenen DB-Instances von innerhalb der VPC aus der VPC heraus verschieben?

Die Migration von DB-Instances von innerhalb zu außerhalb der VPC wird nicht unterstützt. Aus Sicherheitsgründen kann ein DB-Snapshot einer DB-Instance in einer VPC nicht außerhalb der VPC wiederhergestellt werden. Dasselbe gilt für die Funktion "Wiederherstellung zu einem bestimmten Zeitpunkt". 

F: Welche Vorkehrungen sollte ich treffen, um sicherzustellen, dass meine Anwendung auf die DB-Instances in der VPC zugreifen kann?

Sie müssen Routing-Tabellen und Netzwerk-ACLs in Ihrer VPC entsprechend ändern, um sicherzustellen, dass Ihre DB-Instance von Ihren Client-Instances in der VPC erreichbar sind.

Bei Multi-AZ-Bereitstellungen befindet sich Ihre Client-EC2-Instance und die RDS-DB-Instance nach einem Failover eventuell in verschiedenen Availability Zones. Sie sollten Ihre Netzwerk-ACLs so konfigurieren, dass eine übergreifende AZ-Kommunikation möglich ist.

F: Kann ich die DB-Subnetzgruppe meiner DB-Instance ändern?

Eine vorhandene DB-Subnetzgruppe kann aktualisiert werden, um weitere Subnetze für vorhandene Availability Zones oder für neue Availability Zones hinzuzufügen, die nach dem Erstellen der DB-Instance hinzugefügt wurden. Das Entfernen von Subnetzen aus einer vorhandenen DB-Subnetzgruppe kann eine Nichtverfügbarkeit für Instances bewirken, wenn diese in einer bestimmten Availability Zone ausgeführt werden, die aus der Subnetzgruppe entfernt wird. Weitere Informationen hierzu finden Sie im Amazon RDS-Benutzerhandbuch.

F: Was ist ein Amazon RDS-Master-Benutzerkonto und wie unterscheidet es sich von einem AWS-Konto?

Um Amazon RDS verwenden zu können, benötigen Sie ein AWS-Entwicklerkonto. Wenn Sie vor der Anmeldung für Amazon RDS kein Entwicklerkonto besitzen, werden Sie zu Beginn des Anmeldevorgangs zur Erstellung eines solchen Kontos aufgefordert. Ein Master-Benutzerkonto unterscheidet sich von einem AWS-Entwicklerkonto und wird ausschließlich im Rahmen von Amazon RDS verwendet, um den Zugriff auf Ihre DB-Instance(s) zu kontrollieren. Beim Master-Benutzerkonto handelt es sich um das Benutzerkonto einer nativen Datenbank, über das Sie auf Ihre DB-Instance zugreifen können. Bei Erstellung der einzelnen DB-Instances können Sie festlegen, welcher Master-Benutzername und welches Kennwort diesen zugewiesen werden sollen. Nach Erstellung Ihrer DB-Instance können Sie mithilfe der Master-Benutzerdaten auf die Datenbank zugreifen. Anschließend können Sie weitere Benutzerkonten erstellen, mit denen Sie den Zugriff auf Ihre DB-Instance einschränken können.

F: Welche Berechtigungen werden dem Master-Benutzer meiner DB-Instance gewährt?

Der Master-Benutzer verfügt über folgende Standardberechtigungen für MySQL: Erstellen, Entfernen, Referenzen, Ereignis, Ändern, Löschen, Index, Einfügen, Auswählen, Aktualisieren, temporäre Tabellen erstellen, Tabellen sperren, Auslösen, Ansicht erstellen, Ansicht anzeigen, Routine ändern, Routine erstellen, Ausführen, Benutzer erstellen, Verarbeiten, Datenbanken anzeigen, Option erteilen.

Der Master-Benutzer verfügt in Oracle über die "DBA"-Rolle. Der Master-Benutzer übernimmt die meisten der der Rolle zugeordneten Berechtigungen. Eine Liste mit den eingeschränkten Berechtigungen und den entsprechenden Alternativen, um administrative Aufgaben durchzuführen, die diese Berechtigungen eventuell erfordern, finden Sie im Amazon RDS-Benutzerhandbuch.

Bei SQL Server wird dem Benutzer, der eine Datenbank anlegt, die Rolle "db_owner" zugewiesen. Eine Liste mit den eingeschränkten Berechtigungen und den entsprechenden Alternativen, um administrative Aufgaben durchzuführen, die diese Berechtigungen eventuell erfordern, finden Sie im Amazon RDS-Benutzerhandbuch.

F: Gibt es in Amazon RDS Besonderheiten, was die Benutzerverwaltung betrifft?

Nein, alles funktioniert so, wie Sie es von relationalen Datenbanken gewohnt sind, die Sie selbst verwalten.

F: Können Programme, die auf Servern in meinem eigenen Rechenzentrum ausgeführt werden, auf Amazon RDS-Datenbanken zugreifen?

Ja. Sie müssen den Zugriff auf Ihre Datenbank über das Internet manuell aktivieren, indem Sie Sicherheitsgruppen konfigurieren. Sie können den Zugriff nur für die spezifischen IP-Adressen, IP-Adressbereiche und Subnetze autorisieren, die Servern in Ihrem eigenen Rechenzentrum entsprechen.

F: Kann ich Verbindungen zwischen meiner Anwendung und meiner DB-Instance mithilfe von SSL verschlüsseln?

Ja, diese Option wird derzeit für MySQL-, MariaDB-, SQL Server-, PostgreSQL- und Oracle-Engines unterstützt.

Amazon RDS generiert für jede DB-Instance ein SSL-Zertifikat. Nach dem Herstellen einer verschlüsselten Verbindung werden Daten zwischen der DB-Instance und Ihrer Anwendung verschlüsselt übertragen.

Wenngleich SSL Sicherheitsvorteile bietet, sollten Sie daran denken, dass eine SSL-Verschlüsselung sehr rechenintensiv ist und die Latenz Ihrer Datenbankverbindung erhöhen wird. Die SSL-Unterstützung in Amazon RDS dient zur Verschlüsselung der Verbindung zwischen Ihrer Anwendung und Ihrer DB-Instance. Sie sollte nicht zur Authentifizierung der DB-Instance selbst genutzt werden.

Einzelheiten zum Einrichten einer verschlüsselten Verbindung mit Amazon RDS finden Sie im MySQL-Benutzerhandbuch, MariaDB-Benutzerhandbuch, SQL Server-Benutzerhandbuch, PostgreSQL-Benutzerhandbuch oder Oracle-Benutzerhandbuch von Amazon RDS. Weitere Informationen zur Funktionsweise von SSL mit diesen Engines finden Sie in der MySQL-Dokumentation, der MariaDB-Dokumentation, der MSDN SQL Server-Dokumentation, der PostgreSQL-Dokumentation oder der Oracle-Dokumentation.

F: Kann ich in meinen Amazon RDS-Datenbanken im Ruhezustand befindliche Daten verschlüsseln?

Amazon RDS unterstützt Verschlüsselung im Ruhezustand für alle Datenbank-Engines mithilfe von Schlüsseln, die Sie mit AWS Key Management Service (KMS) verwalten. Bei einer mit Amazon RDS-Verschlüsselung ausgeführten DB-Instance sind die im zugrunde liegenden Speicher gespeicherten Daten verschlüsselt, was auch für deren automatisierte Backups, Read Replicas und Snapshots gilt. Ver- und Entschlüsselung erfolgen transparent. Weitere Informationen zur Verwendung von KMS mit Amazon RDS finden Sie im Amazon RDS-Benutzerhandbuch.

Sie können auch eine Verschlüsselung zu einer zuvor unverschlüsselten DB-Instance oder einem DB-Cluster hinzufügen, indem Sie einen DB-Snapshot erstellen, eine Kopie davon erzeugen und anschließend eine KMS-Verschlüsselung festlegen. Sie können dann eine verschlüsselte DB-Instance oder einen DB-Cluster aus dem verschlüsselten Snapshot wiederherstellen.

Amazon RDS for Oracle und SQL Server unterstützen die transparenten Datenverschlüsselungstechnologien dieser Engines. Die transparente Datenverschlüsselung in Oracle ist in AWS CloudHSM integriert, sodass Sie in der AWS-Cloud in HSM-Appliances (Hardwaresicherheitsmodul) für Einzelmandanten Ihre kryptografischen Schlüssel sicher generieren, speichern und verwalten können. Weitere Informationen finden Sie im Amazon RDS-Benutzerhandbuch in den Abschnitten zu Oracle und SQL Server.

F: Wie kontrolliere ich die Aktionen, die meine Systeme und Benutzer auf bestimmte RDS-Ressourcen anwenden können?

Sie können die Aktionen kontrollieren, die Ihre AWS IAM-Benutzer und -Gruppen auf bestimmte RDS-Ressourcen anwenden können. Dies erfolgt über Verweise auf die RDS-Ressourcen in den AWS IAM-Richtlinien, die Sie Benutzern und Gruppen zuweisen können. RDS-Ressourcen, auf die in einer AWS IAM-Richtlinie verwiesen werden kann, sind DB-Instances, DB-Snapshots, Read Replicas, DB-Sicherheitsgruppen, DB-Optionsgruppen, DB-Parametergruppen, Ereignisabonnements und DB-Subnetzgruppen. Darüber hinaus können Sie diese Ressourcen mit Kategorien versehen, um ihnen weitere Metadaten hinzuzufügen. Sie können Ihren Ressourcen Kategorien zuweisen (z. B. DB-Instances "Entwicklung", DB-Instances "Produktion", DB-Instances "Test" usw.) und AWS IAM-Richtlinien festlegen, in denen die Berechtigungen für die Aktionen aufgeführt sind, die auf Ressourcen der jeweiligen Kategorie angewendet werden dürfen. Weitere Informationen finden Sie unter Managing Access to Your Amazon RDS Resources and Databases und Tagging Amazon RDS Resources.

F: Ich möchte für meine RDS-Bereitstellung eine Sicherheitsanalyse oder Behebung von Betriebsproblemen durchführen. Kann ich einen Verlauf aller RDS-API-Aufrufe abrufen, die für mein Konto erfolgt sind?

Ja. AWS CloudTrail ist ein Web-Service, der Aufrufe von AWS-APIs für Ihr Konto aufzeichnet und Protokolldateien an Sie übermittelt. Der AWS-API-Aufrufverlauf, der von CloudTrail generiert wird, ermöglicht eine Sicherheitsanalyse, Nachverfolgung von Ressourcenänderungen und Überwachung der Einhaltung von Vorschriften. Weitere Informationen zu CloudTrail finden Sie auf der Detailseite zu AWS CloudTrail. Auf der CloudTrail-Startseite in der AWS-Managementkonsole können Sie CloudTrail aktivieren.

F: Kann ich Amazon RDS mit Anwendungen verwenden, die dem HIPAA-Standard entsprechen müssen?

A: Ja, alle RDS-Datenbank-Engines sind HIPAA-fähig, Sie können damit daher HIPAA-konforme Anwendungen erstellen und gesundheitsbezogene Daten speichern, u. a. Protected Health Information (PHI) im Rahmen eines aktiven Business Associate Agreement (BAA) mit AWS. Wenn Sie bereits ein aktives BAA haben, können Sie ohne weitere Maßnahmen diese Services mit den vom BAA abgedeckten Konten verwenden. Wenn kein aktives BAA mit AWS vorhanden ist oder Sie Fragen zu HIPAA-konformen Anwendungen in AWS haben, wenden Sie sich an uns.


F: Wie wähle ich die passenden Konfigurationsparameter für meine DB-Instances aus?

Amazon RDS wählt standardmäßig die optimalen Konfigurationsparameter für Ihre DB-Instance aus und berücksichtigt dabei Instance-Klasse und Speicherkapazität. Wenn Sie die Parameter ändern möchten, können Sie hierfür die AWS-Managementkonsole, die Amazon RDS-APIs oder die AWS-Befehlszeilenschnittstelle verwenden. Bitte beachten Sie, dass eine Änderung der empfohlenen Werte der Konfigurationsparameter unbeabsichtigte Folgen haben kann, die von einer herabgesetzten Leistung bis hin zu Systemzusammenbrüchen reichen können. Derartige Änderungen sollten daher nur von erfahrenen Benutzern vorgenommen werden, die bereit sind, diese Risiken in Kauf zu nehmen.

F: Was sind DB-Parametergruppen? Wofür sind sie nützlich?

Eine DB-Parametergruppe (Database Parameter Group) dient als eine Art "Behälter" für die Werte der Engine-Konfiguration, die für eine oder mehrere DB-Instances verwendet werden können. Falls Sie eine DB-Instance erstellen, ohne eine DB-Parametergruppe anzugeben, wird eine standardmäßige DB-Parametergruppe verwendet. Diese Standardgruppe enthält Engine-Standards und Systemstandards für Amazon RDS, die für die gerade ausgeführte DB-Instance optimiert sind. Wenn Sie die DB-Instance jedoch mit benutzerdefinierten Werten für die Engine-Konfiguration ausführen möchten, können Sie einfach eine neue DB-Parametergruppe erstellen, die betreffenden Parameter ändern und festlegen, dass die DB-Instance die neue DB-Parametergruppe verwendet. Nach der Zuordnung der einzelnen DB-Instances zu bestimmten DB-Parametergruppen werden alle DB-Instances mit den Parametern der jeweiligen DB-Parametergruppe aktualisiert.

Weitere Informationen zur Konfiguration von DB-Parametergruppen finden Sie im Amazon RDS-Benutzerhandbuch.

F: Wie kann ich die Konfiguration meiner Amazon RDS-Ressourcen überwachen?

Sie können mithilfe von AWS Config kontinuierlich Konfigurationsänderungen erfassen, die an Amazon RDS-DB-Instances, -DB-Subnetzgruppen, -DB-Snapshots, -DB-Sicherheitsgruppen und -Ereignisabonnements vorgenommen werden, und das System so konfigurieren, dass Sie über Amazon Simple Notification Service (SNS) eine Änderungsbenachrichtigung erhalten. Sie können auch AWS Config-Regeln erstellen, um zu überprüfen, ob die RDS-Ressourcen die gewünschte Konfiguration aufweisen.  


F: Welche Arten von Replikation unterstützt Amazon RDS und wann sollte ich die einzelnen Arten verwenden?

Amazon RDS bietet zwei verschiedene Replikationsoptionen für unterschiedliche Zwecke an.

Wenn Sie mithilfe der Replikation die Datenbankverfügbarkeit erhöhen und gleichzeitig Ihre letzten Datenbank-Updates gegen ungeplante Ausfälle schützen möchten, sollten Sie Ihre DB-Instance als Multi-AZ-Bereitstellung ausführen. Wenn Sie Ihre DB-Instance zur Ausführung als Multi-AZ-Bereitstellung erstellen oder modifizieren, erzeugt und verwaltet Amazon RDS automatisch synchron eine "Standby"-Replica in einer anderen Availability Zone (unabhängige Infrastruktur an einem physisch getrennten Standort). Im Fall einer geplanten Datenbankaktualisierung, eines Ausfalls einer DB-Instance oder der Availability Zone führt Amazon RDS automatisch einen Failover zur aktuellen Standby-Replica durch, sodass der Datenbankbetrieb schnell und ohne Verwaltungsaufwand fortgesetzt werden kann. Multi-AZ-Bereitstellungen verwenden eine synchrone Replikation, wobei Datenbank-Schreibvorgänge gleichzeitig in der Primär- und der Standby-Instance erfolgen, sodass die Standby-Replica im Fall eines Failovers stets auf dem aktuellen Stand ist. Unsere technologische Implementierung für Multi-AZ-DB -Instances maximiert zwar die Beständigkeit Ihrer Daten bei Ausfällen, gleichzeitig ist es hier aber nicht möglich, die Standby-Daten direkt aufzurufen oder für Lesevorgänge zu verwenden. Dank der Fehlertoleranz sind Multi-AZ-Bereitstellungen die ideale Lösung für Produktionsumgebungen.

Amazon RDS bietet Read Replicas an, damit Sie für leseintensive Datenbank-Arbeitslasten über die Kapazitätsgrenzen einer einzelnen DB-Instance hinaus skalieren können. Sie können eine Read Replica einer bestimmten Quell-DB-Instance erstellen, indem Sie die AWS-Managementkonsole, die RDS-API oder die AWS-Befehlszeilenschnittstelle verwenden. Nach dem Erstellen der Read Replica werden Datenbank-Updates auf der Quell-DB-Instance auch für die Read Replica übernommen. Sie können mehrere Read Replicas für eine bestimmte Quell-DB-Instance erstellen und den Lesedatenverkehr Ihrer Anwendung auf diese verteilen.

Read Replicas werden durch Amazon Aurora sowie durch Amazon RDS for MySQL, MariaDB und PostgreSQL unterstützt. Anders als Multi-AZ-Bereitstellungen verwenden Read Replicas die integrierte Replikation dieser Engines und unterliegen deren Stärken und Einschränkungen. Das bedeutet insbesondere, dass Updates in Ihre Read Replica(s) übernommen werden, nachdem sie in der Quell-DB-Instance erfolgt sind ("asynchrone" Replikation), und die Verzögerung bei der Replikation kann erheblichen Schwankungen unterliegen. Das bedeutet, dass kürzlich an einer standardmäßigen Quell-DB-Instance (nicht Multi-AZ) durchgeführte Datenbank-Updates bei einem ungeplanten Ausfall der Quell-DB-Instance möglicherweise noch nicht in die zugehörigen Read Replicas übernommen wurden. Read Replicas an sich bieten daher nicht dieselben Vorteile in puncto Datenbeständigkeit wie Multi-AZ-Bereitstellungen. Read Replicas können einige Vorteile im Hinblick auf die Verfügbarkeit von Leseleistung bieten, sind aber nicht darauf ausgelegt, die Leistung bei Schreibvorgängen zu verbessern.

Mit Amazon RDS können Sie Multi-AZ-Bereitstellungen und Read Replicas in Kombination verwenden, um sich die jeweiligen Vorteile beider Lösungen zunutze zu machen. Sie können einfach festlegen, dass eine beliebige Multi-AZ-Bereitstellung die Quell-DB-Instance für Ihre Read Replica(s) sein soll. Auf diese Weise sichern Sie sich die Vorzüge, die Multi-AZ-Bereitstellungen im Hinblick auf die Beständigkeit und Verfügbarkeit von Daten bieten, und die erhöhte Leseleistung von Read Replicas.

F: Was bedeutet es, eine DB-Instance als Multi-AZ-Bereitstellung zu betreiben?

Wenn Sie Ihre DB-Instance zur Ausführung als Multi-AZ-Bereitstellung erstellen oder modifizieren, erzeugt und unterhält Amazon RDS automatisch synchron eine "Standby"-Replica in einer anderen Availability Zone. Updates Ihrer DB-Instance werden synchron über mehrere Availability Zones in der Standby-Datenbank repliziert, damit Ihre letzten Datenbank-Updates synchronisiert und gegen einen Ausfall der DB-Instance geschützt sind. Während bestimmten geplanten Wartungs- bzw. Aktualisierungsarbeiten oder im unwahrscheinlichen Fall eines Ausfalls der DB-Instance oder der Availability Zone führt Amazon RDS automatisch einen Failover zur Standby-Datenbank aus, sodass die Schreib- und Lesevorgänge in Ihrer Datenbank unmittelbar nach dem Wechsel fortgesetzt werden können. Da der Namensdatensatz für Ihre DB-Instance gleich bleibt, kann Ihre Anwendung den Datenbankbetrieb ohne manuellen administrativen Eingriff fortsetzen. Mit Multi-AZ-Bereitstellungen erhalten Sie eine transparente Replikation: Sie interagieren nicht direkt mit der Standby-Instance, und diese kann nicht zur Unterstützung des Lesedatenverkehrs genutzt werden. Weitere Informationen zu Multi-AZ-Bereitstellungen finden Sie im Amazon RDS-Benutzerhandbuch.

F: Was ist eine Availability Zone?

Availability Zones sind isolierte Standorte innerhalb einer Region, d. h., sie sind bei Ausfällen in anderen Availability Zones nicht betroffen. Jede Availability Zone wird auf ihrer eigenen physisch getrennten, unabhängigen Infrastruktur ausgeführt und ist auf hohe Zuverlässigkeit ausgelegt. Übliche Fehlerquellen wie Generatoren und Kühlanlagen werden nicht von mehreren Availability Zones geteilt. Die physische Trennung sorgt außerdem dafür, dass sogar bei äußerst seltenen Katastrophen wie Bränden, Stürmen oder Überflutungen nur eine Availability Zone betroffen ist. Availability Zones innerhalb derselben Region profitieren von einer Netzwerkverbindung mit niedrigen Latenzen.

F: Was bedeutet "primär" und "Standby" im Zusammenhang mit Multi-AZ-Bereitstellungen?

Wenn Sie eine DB-Instance als Multi-AZ-Bereitstellung betreiben, steht die primäre Datenbank für Schreib- und Lesevorgänge in der Datenbank zur Verfügung. Zusätzlich dazu stellt Amazon RDS im Hintergrund eine "Standby"-Instance zur Verfügung, die eine stets aktuelle Replica der Primär-Instance darstellt. Bei Failover-Szenarios wird die Standby-Instance "hochgestuft". Nach dem Failover wird also die Standby-Instance zur Primär-Instance und nimmt dann Ihre Datenbank-Operationen entgegen. Zu keinem Zeitpunkt vor der Hochstufung interagieren Sie direkt mit der Standby-Instance (etwa bei Lesevorgängen). Wenn Sie den Lesedatenverkehr über die Kapazitätseinschränkungen einer einzelnen DB-Instance hinaus skalieren möchten, finden Sie weitere Informationen in den häufig gestellten Fragen zu Read Replicas.

F: Welche Vorteile bietet eine Multi-AZ-Bereitstellung?

Die Hauptvorteile einer Ausführung Ihrer DB-Instance als Multi-AZ-Bereitstellung sind die erhöhte Zuverlässigkeit und Verfügbarkeit der Datenbank. Dank ihrer erhöhten Verfügbarkeit und Fehlertoleranz sind Multi-AZ-Bereitstellungen die ideale Lösung für Produktionsumgebungen.

Wenn Sie Ihre DB-Instance als Multi-AZ-Bereitstellung ausführen, sind Ihre Daten im unwahrscheinlichen Fall, dass eine DB-Instance-Komponente ausfällt oder der Dienst in einer Availability Zone unterbrochen wird, sicher. Wenn beispielsweise ein Speicher-Volume Ihrer Primär-Instance ausfällt, initiiert Amazon RDS automatisch einen Failover zur Standby-Instance, wo all Ihre Datenbank-Updates in intakter Form vorliegen. Dies bietet also zusätzliche Datenbeständigkeit im Vergleich zu Standard-Bereitstellungen in einer einzelnen AZ: Hier wäre eine vom Benutzer angestoßene Wiederherstellung erforderlich, und Updates, die nach dem letztmöglichen Wiederherstellungszeitpunkt (in der Regel in den letzten fünf Minuten) durchgeführt wurden, stünden nicht zur Verfügung.

Beim Betrieb Ihrer DB-Instance als Multi-AZ-Bereitstellung profitieren Sie darüber hinaus von einer verbesserten Datenbankverfügbarkeit. Bei einem Ausfall einer Availability Zone oder DB-Instance wird die Verfügbarkeit lediglich für den Zeitraum beeinträchtigt, der für das automatische Failover benötigt wird. Die Verfügbarkeitsvorteile von Multi-AZ kommen auch bei geplanten Wartungen bzw. Aktualisierungen zum Tragen. So werden E/A-Vorgänge in Ihrer Primär-Instance beispielsweise bei automatisierten Backups im von Ihnen bestimmten Backup-Fenster nicht mehr unterbrochen, da die Backups von der Standby-Replica angefertigt werden. Im Fall von Patches oder Skalierungen der DB-Instance-Klasse werden diese Operationen zunächst auf der Standby-Replica vorgenommen, bevor das automatische Failover erfolgt. Das Ergebnis: Es kommt lediglich für die Dauer, die der automatische Failover in Anspruch nimmt, zu Einschränkungen der Verfügbarkeit.

Ein weiterer Vorteil, den die Ausführung Ihrer DB-Instance als Multi-AZ-Bereitstellung mit sich bringt, liegt darin, dass das DB-Instance-Failover automatisch erfolgt und keinen Verwaltungsaufwand mit sich bringt. Im Hinblick auf Amazon RDS bedeutet das, dass Sie die DB-Instance-Ereignisse nicht überwachen und keine manuelle Wiederherstellung der DB-Instance (über die APIs RestoreDBInstanceToPointInTime oder RestoreDBInstanceFromSnapshot) anstoßen müssen, wenn es zu einem Ausfall in einer Availability Zone oder zu einem DB-Instance-Ausfall kommen sollte.

F: Hat die Ausführung meiner DB-Instance als Multi-AZ-Bereitstellung Auswirkungen auf die Leistung?

Aufgrund der synchronen Datenreplikation, die in Ihrem Auftrag durchgeführt wird, kann es zu erhöhten Latenzen im Vergleich zur standardmäßigen Bereitstellung einer DB-Instance in einer einzelnen Availability Zone kommen.

F: Kann ich, wenn ich meine DB-Instance als Multi-AZ-Bereitstellung betreibe, die Standby-Replica für Lese- oder Schreibvorgänge nutzen?

Nein, die Standby-Replica kann keine Leseanforderungen bearbeiten. Der Zweck von Multi-AZ-Bereitstellungen ist eine Verbesserung der Datenbankverfügbarkeit und -beständigkeit und nicht eine Skalierung der Lesevorgänge. Die Replikation zwischen Primär- und Standby-Instance erfolgt synchron. Durch unsere Implementierung wird sichergestellt, dass Primär- und Standby-Instance konstant synchronisiert werden, gleichzeitig ist die Standby-Instance aber von Lese- oder Schreibvorgängen ausgeschlossen. Wenn Sie sich für eine Lösung zur Skalierung der Lesevorgänge interessieren, erfahren Sie mehr in den häufig gestellten Fragen zu Read Replicas.

F: Wie richte ich die Multi-AZ-Bereitstellung für eine DB-Instance ein?

Um eine Multi-AZ-Bereitstellung für eine DB-Instance einzurichten, klicken Sie einfach auf die Option "Yes" für "Multi-AZ Deployment", wenn Sie eine DB-Instance mit der AWS-Managementkonsole starten. Wenn Sie die Amazon RDS-APIs verwenden, können Sie die API CreateDBInstance nutzen und den Parameter "Multi-AZ" auf "true" setzen. Um eine bestehende, standardmäßige DB-Instance (Single-AZ) in eine Multi-AZ-Bereitstellung zu konvertieren, modifizieren Sie die DB-Instance in der AWS-Managementkonsole oder verwenden Sie die API ModifyDBInstance und setzen Sie den Parameter "Multi-AZ" auf "true".

F: Was geschieht, wenn ich meine RDS-Instance von Single-AZ in Multi-AZ konvertiere?

Für die RDS-Datenbank-Engines MySQL, MariaDB, PostgreSQL und Oracle geschieht Folgendes, wenn Sie Ihre RDS-Instance von Single-AZ in Multi-AZ konvertieren möchten:

  • Ein Snapshot Ihrer Primär-Instance wird erstellt.
  • Eine neue Standby-Instance wird aus dem Snapshot in einer anderen Availability Zone erstellt.
  • Die synchrone Replikation wird zwischen Primär- und Standby-Instances konfiguriert.

Dadurch sollte es keine Ausfallzeiten geben, wenn eine Instance von Single-AZ in Multi-AZ konvertiert wird.

F: Welche Ereignisse veranlassen Amazon RDS zu einem Failover auf die Standby-Replica?

Bei Multi-AZ-Bereitstellungen erfolgt bei den meisten gängigen Ausfallszenarien nach deren Erkennen eine automatische Wiederherstellung durch Amazon RDS, sodass Sie ohne Verwaltungsaufwand Datenbankvorgänge schnellstmöglich fortsetzen können. Amazon RDS führt in den folgenden Szenarien automatisch ein Failover durch:

  • Verlust der Verfügbarkeit in der primären Availability Zone
  • Verlust der Netzwerkverbindung zur Primär-Instance
  • Ausfall einer Datenverarbeitungseinheit in der Primär-Instance
  • Speicherfehler in der Primär-Instance

Hinweis: Wenn für Multi-AZ-Bereitstellungen Vorgänge wie die Skalierung von DB-Instances oder System-Upgrades wie das Einspielen von Betriebssystem-Patches ausgelöst werden, werden diese zur Optimierung der Verfügbarkeit vor einem automatischen Failover zunächst auf die Standby-Replica angewendet. Es kommt deshalb lediglich für die Dauer, die das automatische Failover in Anspruch nimmt, zu Einschränkungen der Verfügbarkeit. Hinweis: Bei Multi-AZ-Bereitstellungen von Amazon RDS erfolgt kein automatisches Failover als Reaktion auf Datenbankvorgänge wie lang andauernde Abfragen, gegenseitige Sperren (Deadlocks) oder Fehler aufgrund von Datenbankbeschädigungen.

F: Werde ich bei einem automatischen Failover benachrichtigt?

Ja, Amazon RDS veranlasst ein DB-Instance-Ereignis, um Sie über den automatischen Failover zu informieren. Durch Klicken in den Bereich "Events" der Amazon RDS-Konsole oder mithilfe der API DescribeEvents können Sie Informationen zu Ereignissen in Verbindung mit Ihrer DB-Instance aufrufen. Sie können auch den Service Amazon RDS Event Notifications so konfigurieren, dass Sie bei Eintreten eines bestimmten DB-Ereignisses benachrichtigt werden.

F: Was geschieht während eines Multi-AZ-Failovers und wie viel Zeit nimmt dieser Vorgang in Anspruch?

Der Failover wird automatisch von Amazon RDS durchgeführt, damit Sie den Datenbankbetrieb schnellstmöglich und ohne Verwaltungsaufwand wieder aufnehmen können. Bei einem Failover wechselt Amazon RDS einfach den anerkannten Namensdatensatz (CNAME) für Ihre DB-Instance, sodass auf die Standby-Replica verwiesen wird, das dadurch zur neuen Primär-Instance hochgestuft wird. Wir empfehlen Ihnen, sich an bewährte Methoden zu halten und eine Funktion auf der Anwendungsebene zu implementieren, über die gegebenenfalls erneut versucht wird, eine Datenbankverbindung herzustellen.

Failover-Vorgänge erfolgen entsprechend der Festlegung des Zeitraums zwischen dem Erkennen des Ausfalls auf der Primär-Instance und Fortsetzung von Transaktionen auf der Standby-Instance in der Regel binnen 1-2 Minuten. Die Dauer des Failovers kann auch davon abhängen, ob umfassende Transaktionen ohne Datenbank-Commit wiederhergestellt werden müssen. Für optimale Ergebnisse wird der Einsatz ausreichend großer Instance-Typen für Multi-AZ-Bereitstellungen empfohlen. AWS empfiehlt auch die Nutzung von bereitgestellten IOPS mit Multi-AZ-Instances zum Sicherstellen einer schnellen, berechenbaren und einheitlichen Durchsatzleistung.

F: Kann ich ein Failover für meine Multi-AZ-Bereitstellung von DB-Instances "erzwingen"?

Amazon RDS führt bei einer Vielzahl von Fehlerbedingungen automatisch ein Failover durch, ohne dass Benutzer eingreifen müssen. Zusätzlich bietet Amazon RDS eine Option zum Initiieren eines Failovers beim Neustarten Ihrer Instance. Sie können auf diese Funktion über die AWS-Managementkonsole oder bei Verwendung des RebootDBInstance-API-Aufrufs zugreifen.

F: Wie kontrolliere/konfiguriere ich die synchrone Multi-AZ-Replikation?

Bei Multi-AZ-Bereitstellungen setzen Sie einfach den Parameter "Multi-AZ" auf "true". Die Erstellung der synchronen Standby-Replikation und das Failover werden automatisch abgewickelt. Das bedeutet, dass Sie die Availability Zone nicht auswählen können, in der Ihre Standby-Replica bereitgestellt wird, und auch nicht die Anzahl der verfügbaren Standby-Instances verändern können (Amazon RDS erzeugt eine dedizierte Standby-Replica für jede primäre DB-Instance). Die Standby-Replica kann auch nicht für das Akzeptieren von Datenbankleseaktivitäten konfiguriert werden. Weitere Informationen zu Multi-AZ-Konfigurationen.

F: Befindet sich meine Standby-Replica in derselben Region wie die Primär-Instance?

Ja. Ihre Standby-Replica wird automatisch in einer anderen Availability Zone in derselben Region wie Ihre primäre DB-Instance bereitgestellt.

F: Kann ich sehen, in welcher Availability Zone sich meine Primär-Instance derzeit befindet?

Ja, Sie können über die AWS-Managementkonsole oder mithilfe der API DescribeDBInstances den Speicherort der aktuellen Primär-Instance ermitteln.

F: Nach einem Failover befindet sich meine Primär-Instance nun in einer anderen Availability Zone als meine anderen AWS-Ressourcen (z. B. EC2-Instances). Muss ich mir Sorgen um Latenzen machen?

Availability Zones sind darauf ausgelegt, Netzwerkverbindungen mit niedrigen Latenzen zu anderen Availability Zones derselben Region bereitzustellen. Zusätzlich empfiehlt es sich eventuell, die Architektur Ihrer Anwendung und anderer AWS-Ressourcen mit Redundanzen über mehrere Availability Zones anzulegen, damit Ihre Anwendung bei einem Ausfall einer einzelnen Availability Zone geschützt ist. Bei Multi-AZ-Bereitstellungen ist dies auf Datenbankebene der Fall, ohne dass hierfür ein administratives Zutun Ihrerseits erforderlich ist.

F: Wie funktionieren DB-Snapshots und automatisierte Backups im Zusammenhang mit meiner Multi-AZ-Bereitstellung?

Die Interaktion mit automatisierten Backups und DB-Snapshot-Funktionalität ist bei Standardbereitstellungen in einer Single-AZ- oder Multi-AZ-Bereitstellung identisch. Wenn Sie eine Multi-AZ-Bereitstellung betreiben, werden automatisierte Backups und DB-Snapshots mithilfe der Standby-Replica erstellt, um eine E/A-Unterbrechung in der Primär-Instance zu vermeiden. Beachten Sie, dass es bei Single-AZ- oder Multi-AZ-Bereitstellungen im Verlauf von Backups zu einer erhöhten E-/A-Latenz (für gewöhnlich wenige Minuten) kommen kann.

Auch das Auslösen von Wiederherstellungsvorgängen (zeitpunktbezogene Wiederherstellung oder Wiederherstellung aus einem DB-Snapshot) erfolgt bei standardmäßigen Single-AZ- und Multi-AZ-Bereitstellungen gleich. Neue DB-Instance-Bereitstellungen können mithilfe der APIs RestoreDBInstanceFromSnapshot oder RestoreDBInstanceToPointInTime erstellt werden. Diese neuen DB-Instance-Bereitstellungen können entweder Standard- oder Multi-AZ-Bereitstellungen sein, unabhängig davon, ob das Quell-Backup von einer standardmäßigen oder einer Multi-AZ-Bereitstellung aus initiiert wurde.

F: Was bedeutet es, eine DB-Instance als Read Replica zu betreiben?

Read Replicas sind eine einfache Möglichkeit, die Vorteile der integrierten Replikationsfunktionen der unterstützten Engines zu nutzen, um bei leseintensiven Datenbank-Arbeitslasten elastisch über die Kapazitätseinschränkungen einer einzelnen DB-Instance hinaus zu skalieren. Read Replicas können mit wenigen Klicks in der AWS-Managementkonsole oder über die API CreateDBInstanceReadReplica erstellt werden. Nach Erstellung der Read Replica werden Updates der Quell-DB-Instance unter Verwendung der nativen, asynchronen Replikation einer unterstützten Engine repliziert. Sie können mehrere Read Replicas für eine bestimmte Quell-DB-Instance erstellen und den Lesedatenverkehr Ihrer Anwendung auf diese verteilen. Da Read Replicas die integrierte Replikation der unterstützten Engines verwenden, unterliegen sie auch deren Stärken und Einschränkungen. Das bedeutet insbesondere, dass Updates in Ihren Read Replica(s) übernommen werden, nachdem sie in der Quell-DB-Instance erfolgt sind, und die Verzögerung bei der Replikation kann erheblichen Schwankungen unterliegen. Read Replicas können mit Multi-AZ-Bereitstellungen verbunden werden, um zusätzlich zu den Skalierungsvorteilen im Hinblick auf Lesevorgänge von der verbesserten Schreibverfügbarkeit der Datenbank und Datenbeständigkeit zu profitieren, die Multi-AZ-Bereitstellungen bieten.

F: Wann sollte ich die Verwendung einer Amazon RDS Read Replica in Erwägung ziehen?

Es gibt verschiedene Szenarios, in denen die Bereitstellung einer oder mehrerer Read Replicas für eine bestimmte Quell-DB-Instance sinnvoll ist. Häufige Gründe für die Bereitstellung einer Read Replica:

  • Skalierung über die Rechen- oder E/A-Leistung einer einzelnen DB-Instance bei Datenbank-Arbeitslasten mit umfassenden Lesevorgängen. Dieser zusätzliche Lesedatenverkehr kann an eine oder mehrere Read Replicas geleitet werden.
  • Unterstützung des Lesedatenverkehrs bei einer nicht verfügbaren Quell-DB-Instance. Wenn Ihre Quell-DB-Instance keine E/A-Anforderungen bearbeiten kann (z. B. aufgrund von E/A-Einschränkungen für Backups oder geplanten Wartungsarbeiten), können Sie den Lesedatenverkehr an Ihre Read Replica(s) leiten. Denken Sie in diesem Fall daran, dass die Daten in der Read Replica "veraltet" sein können, da die Quell-DB-Instance nicht verfügbar ist.
  • Berichterstattung in Unternehmen oder Data-Warehousing-Szenarios. Eventuell empfiehlt es sich, Anforderungen zur geschäftlichen Berichterstattung über eine Read Replica und nicht über Ihre primäre DB-Instance für die Produktion laufen zu lassen.

F: Muss ich automatische Backups auf einer DB-Instance aktivieren, bevor ich Read Replicas erstellen kann?

Ja. Aktivieren Sie automatische Backups auf Ihrer DB-Instance, bevor Sie Read Replicas hinzufügen, indem Sie den Aufbewahrungszeitraum für Backups auf einen Wert von größer als 0 setzen. Damit Read Replicas funktionieren, müssen Backups aktiviert bleiben.

F: Welche Versionen von Datenbank-Engines unterstützen Amazon RDS Read Replicas?

Amazon Aurora: Alle DB-Cluster.

Amazon RDS for MySQL: DB-Instances mit MySQL Version 5.5 oder höher unterstützen das Erstellen von Read Replicas. Automatische Backups müssen auf der Quell-DB-Instance für Read Replica-Vorgänge aktiviert sein und bleiben. Automatische Backups auf der Replica werden nur für Amazon RDS Read Replicas unter MySQL 5.6 und höher unterstützt, jedoch nicht für Version 5.5 und darunter.

Amazon RDS for PostgreSQL: DB-Instances mit PostgreSQL Version 9.3.5 oder höher unterstützen das Erstellen von Read Replicas. Bestehende PostgreSQL-Instances vor Version 9.3.5 müssen auf PostgreSQL Version 9.3.5 aktualisiert werden, um die Vorteile von Amazon RDS Read Replicas nutzen zu können.

Amazon RDS for MariaDB: Alle DB-Instances unterstützen die Erstellung von Read Replicas. Automatische Backups müssen auf der Quell-DB-Instance für Read Replica-Vorgänge aktiviert sein und bleiben.

F: Wie stelle ich eine Read Replica für eine vorhandene DB-Instance bereit?

Read Replicas können binnen Minuten über die standardmäßige API CreateDBInstanceReadReplica oder mit wenigen Klicks in der AWS-Managementkonsole erstellt werden. Beim Erstellen einer Read Replica können Sie sie durch Spezifizieren eines SourceDBInstanceIdentifier als Read Replica kennzeichnen. Der SourceDBInstanceIdentifier ist die DB-Instance-Kennung der "Quell"-DB-Instance, aus der Sie Daten replizieren möchten. Wie bei einer standardmäßigen DB-Instance können Sie auch die Availability Zone, DB-Instance-Klasse und das bevorzugte Wartungsfenster festlegen. Die Engine-Version (z. B. PostgreSQL 9.3.5) und die Speicherzuweisung einer Read Replica werden aus der Quell-DB-Instance übernommen. Wenn Sie die Erstellung einer Read Replica anstoßen, fertigt Amazon RDS einen Snapshot Ihrer Quell-DB-Instance an und beginnt mit der Replikation. Das hat eine kurze Aussetzung des E/A-Datenverkehrs Ihrer Quell-DB-Instance zur Folge. Diese Aussetzung dauert in der Regel nicht länger als eine Minute und kann vermieden werden, wenn es sich bei der DB-Instance um eine Multi-AZ-Bereitstellung handelt (bei Multi-AZ-Bereitstellungen werden Snapshots von der Standby-Instance angefertigt). Amazon RDS arbeitet derzeit auch an einer weiteren (in Kürze verfügbaren) Optimierung, bei der alle Read Replicas denselben Quell-Snapshot nutzen, wenn Sie mehrere Read Replicas innerhalb eines 30-minütigen Fensters erstellen, um die E/A-Beeinträchtigung zu minimieren (die "Aufhol"-Replikation für jede Read Replica beginnt dann nach der Erstellung).

F: Wie stelle ich eine Verbindung mit meinen Read Replicas her?

Verbindungen mit einer Read Replica können wie mit einer Standard-DB-Instance über die API DescribeDBInstance oder die AWS-Managementkonsole hergestellt werden, um den/die Endpunkt(e) für Ihre Read Replica(s) abzurufen. Wenn Sie mehrere Read Replicas nutzen, muss Ihre Anwendung bestimmen, wie der Lesedatenverkehr auf diese verteilt wird.

F: Wie viele Read Replicas kann ich für eine vorhandene Quell-DB-Instance erstellen?

Mit Amazon Aurora können Sie bis zu 15 Read Replicas für einen bestimmten DB-Cluster erstellen.

Amazon RDS for MySQL, MariaDB und PostgreSQL erlauben Ihnen zurzeit, bis zu fünf Read Replicas für eine bestimmte Quell-DB-Instance zu erstellen.

F: Kann ich eine Read Replica in einer AWS-Region erstellen, die nicht mit der Region der Quell-DB-Instance übereinstimmt?

Ja, RDS unterstützt regionsübergreifende Read Replicas.

F: Unterstützen Amazon RDS Read Replicas die synchrone Replikation?

Nein. Read Replicas in Amazon RDS for MySQL, MariaDB und PostgreSQL sind so implementiert, dass sie die native asynchrone Replikation dieser Engines verwenden. Amazon Aurora verwendet einen anderen, aber auch einen asynchronen Datenreplikationsmechanismus.

F: Kann ich eine Read Replica nutzen, um die Datenbankverfügbarkeit für Schreibvorgänge zu erweitern oder Daten auf meiner Quell-DB-Instance gegen Ausfälle zu schützen?

Wenn Sie mithilfe von Replikation die Schreibverfügbarkeit Ihrer Datenbank erhöhen und aktuelle Datenbank-Updates vor diversen Ausfallbedingungen schützen möchten, empfehlen wir Ihnen, Ihre DB-Instance als Multi-AZ-Bereitstellung auszuführen. Mit Read Replicas von Amazon RDS und der nativen, asynchronen Replikation der unterstützten Engines erfolgen die Schreibvorgänge in einer Read Replica erst, nachdem sie in der Quell-DB-Instance erfolgt sind, und diese Verzögerung bei der Replikation kann erheblichen Schwankungen unterliegen. Im Gegensatz dazu erfolgt die Replikation bei Multi-AZ-Bereitstellungen synchron, d. h., alle Datenbank-Schreibvorgänge erfolgen in der Primär- und der Standby-Instance gleichzeitig. Damit sind Ihre letzten Datenbank-Updates geschützt, da sie, falls ein Failover erforderlich wird, schon in der Standby-Instance verfügbar sind. Darüber hinaus ist die Replikation bei Multi-AZ-Bereitstellungen komplett verwaltet. Amazon RDS überwacht automatisch die DB-Instance auf Ausfallbedingungen oder einen Ausfall der Availability Zone hin und initiiert einen automatischen Failover zur Standby-Instance (oder im Fall von Amazon Aurora zu einer Read Replica), wenn es zu einem Ausfall kommt.

F: Kann ich eine Read Replica mit einer Multi-AZ-Bereitstellung einer DB-Instance als Quelle erstellen?

Ja. Da Multi-AZ-DB-Instances auf andere Bedürfnisse als Read Replicas ausgelegt sind, ist es durchaus sinnvoll, beide Komponenten kombiniert für Produktionsbereitstellungen zu nutzen und einer Multi-AZ-DB-Instance-Bereitstellung eine Read Replica zuzuweisen. Die Multi-AZ-"Quell"-DB-Instance bietet Ihnen eine erhöhte Schreibverfügbarkeit und eine höhere Datenbeständigkeit, während die zugeordnete Read Replica die Skalierbarkeit des Lesedatenverkehrs verbessert.

F: Kann ich die Read Replicas von Amazon RDS in Multi-AZ-Bereitstellungen konvertieren?

Amazon RDS for MySQL und MariaDB ermöglichen Ihnen die Aktivierung von Multi-AZ auf Read Replicas, um die Notfallwiederherstellung zu unterstützen und Ausfallzeiten durch Engine-Upgrades so kurz wie möglich zu halten. Amazon RDS for PostgreSQL unterstützt diese Funktion zurzeit nicht.

F: Was geschieht im Fall eines Multi-AZ-Failovers, wenn meine Read Replicas eine Multi-AZ-Bereitstellung einer DB-Instance als Quelle nutzen?

Im Falle eines Multi-AZ-Failovers sollten alle zugeordneten und verfügbaren Read Replicas automatisch die Replikation wiederaufnehmen, nachdem das Failover abgeschlossen wurde (d. h., sie beginnen mit dem Abrufen von Updates aus der neuen Primär-Instance).

F: Kann ich eine Read Replica einer anderen Read Replica erstellen?

Amazon Aurora, Amazon RDS for MySQL und MariaDB: Sie können anhand einer bestehenden primären Read Replica eine sekundäre Read Replica erstellen. Durch Erstellen einer sekundären Read Replica können Sie ggf. einen Teil der Replikationslast von einer Master-Datenbank-Instance zu einer primären Read Replica verlagern. Beachten Sie, dass eine sekundäre Read Replica ggf. länger hinter der Master-DB-Instance zurückbleibt, da es zu weiterer Replikationslatenz kommt, wenn Transaktionen von der Master-DB-Instance in die primäre Read Replica und anschließend in die sekundäre Read Replica repliziert werden.

Amazon RDS for PostgreSQL: Read Replicas von Read Replicas werden zurzeit nicht unterstützt.

F: Können meine Read Replicas nur Lesevorgänge von Datenbanken akzeptieren?

Read Replicas sind darauf ausgelegt, Lesedatenverkehr zu unterstützen. Es kann allerdings auch Nutzungsszenarios geben, in denen fortgeschrittene Nutzer DDL-SQL-Statements (Data Definition Language) für eine Read Replica ausfüllen möchten. Beispiele hierfür wären das Hinzufügen eines Datenbank-Indexes zu einer für geschäftliche Berichterstattungen genutzten Read Replica, ohne dass derselbe Index zur entsprechenden Quell-DB-Instance hinzugefügt wird.

Amazon RDS for MySQL kann so konfiguriert werden, dass DDL-SQL-Statements für eine Read Replica erlaubt werden. Wenn Sie andere Operationen als Lesevorgänge für eine bestimmte Read Replica ermöglichen möchten, modifizieren Sie die aktive DB-Parametergruppe für die Read Replica und setzen den Parameter "read_only" auf "0".

Amazon RDS for PostgreSQL unterstützt die Ausführung von DDL-SQL-Statements für eine Read Replica zurzeit nicht.

F: Kann ich meine Read Replica zu einer "eigenständigen" DB-Instance hochstufen?

Ja. Weitere Informationen hierzu finden Sie im Amazon RDS-Benutzerhandbuch.

F: Wird meine Read Replica mit ihrer Quell-DB-Instance auf dem neuesten Stand gehalten?

Updates an einer Quell-DB-Instance werden automatisch in allen zugeordneten Read Replicas repliziert. Bei der asynchronen Replikationstechnologie der unterstützten Engines kann es jedoch aus verschiedenen Gründen dazu kommen, dass eine Read Replica hinter ihrer Quell-DB-Instance "hinterherhinkt". Typische Gründe hierfür sind:

  • Das Schreiben von E/A-Volumen auf die Quell-DB-Instance überschreitet die Rate, mit der Änderungen an der Read Replica vorgenommen werden können. Dieses Problem tritt insbesondere auf, wenn die Rechenleistung einer Read Replica geringer als die der Quell-DB-Instance ist.
  • Komplexe oder lange andauernde Transaktionen auf die Quell-DB-Instance beeinträchtigen die Replikation auf die Read Replica.
  • Netzwerk-Partitionen oder Latenzen zwischen der Quell-DB-Instance und einer Read Replica

Read Replicas unterliegen den Stärken und Einschränkungen der nativen Replikation der unterstützten Engines. Wenn Sie Read Replicas verwenden, sollten Sie sich über die potenziellen Verzögerungen zwischen einer Read Replica und ihrer Quell-DB-Instance (die sogenannten "Inkonsistenzen") bewusst sein. Klicken Sie hier, um Tipps zur Handhabung von Read Replicas zu erhalten, die deutlich hinter ihrer Quelle zurückliegen.

F: Wo kann ich den Status meiner aktiven Read Replicas sehen?

Sie können die Standard-API DescribeDBInstances nutzen, um eine Liste aller von Ihnen bereitgestellten DB-Instances (inklusive Read Replicas) ausgeben zu lassen, oder einfach in der Amazon RDS-Konsole auf die Registerkarte "DB-Instances" klicken.

Mit Amazon RDS können Sie sehen, wie weit eine Read Replica hinter ihre Quell-DB-Instance zurückgefallen ist. Die Anzahl der Sekunden, die die Read Replica hinter den Master zurückgefallen ist, wird als eine Amazon CloudWatch-Metrik ("Replica-Verzögerung") veröffentlicht, die über die AWS-Managementkonsole oder Amazon CloudWatch-APIs verfügbar ist. Bei Amazon RDS for MySQL ist die Quelle dieser Daten die gleiche wie durch den MySQL-Standardbefehl "Show Slave Status" für die Read Replica angezeigt wird. Bei Amazon RDS for PostgreSQL können Sie die pg_stat_replication-Ansicht auf der Quell-DB-Instance verwenden, um die Replikationsmetriken anzuzeigen.

Amazon RDS überwacht den Replikationsstatus Ihrer Read Replicas und aktualisiert das Feld "Replication State" in der AWS-Managementkonsole mit der Meldung "Error", wenn die Replikation aus einem beliebigen Grund unterbrochen wird. (Beispielweise beim Versuch von DML-Anfragen auf Ihrer Replica, die mit den an der Master-Datenbank-Instance vorgenommenen Updates in Konflikt stehen, was zu einem Replikationsfehler führen könnte.) Die Details zu dem von der MySQL-Engine gemeldeten Fehler können Sie im Feld "Replication Error" sehen und somit anschließend entsprechende Abhilfemaßnahmen ergreifen. Im Abschnitt "Troubleshooting a Read Replica Problem" des Amazon RDS-Benutzerhandbuchs für MySQL oder PostgreSQL finden Sie weitere Informationen zur Fehlerbehebung bei Replikationsproblemen.

Wurde ein Replikationsfehler behoben, ändert sich das Feld "Replication State" in "Replicating".

F: Meine Read Replica liegt deutlich hinter ihrer Quell-DB-Instance zurück. Was soll ich tun?

Wie in den vorherigen Fragen erörtert, sind "Inkonsistenzen" oder Verzögerungen zwischen einer Read Replica und ihrer Quell-DB-Instance ein häufiges Problem bei der asynchronen Replikation. Wenn eine bestehende Read Replica zu weit zurückgefallen ist, um Ihre Anforderungen zu erfüllen, können Sie sie löschen und eine neue mit demselben Endpunkt erstellen, indem Sie dieselbe DB-Instance-Kennung und Quell-DB-Instance-Kennung wie bei der gelöschten Read Replica verwenden. Denken Sie daran, dass der Neuerstellungsprozess bei geringfügigen Verzögerungen (z. B. weniger als fünf Minuten Verzögerung) kontraproduktiv ist und mit Bedacht genutzt werden sollte (d. h. nur, wenn die Read Replica deutlich hinter ihrer Quell-DB-Instance zurückliegt). Beachten Sie außerdem, dass Replica-Verzögerungen im Laufe der Zeit natürlich ab- und zunehmen können, abhängig vom jeweiligen Nutzungsmuster Ihrer Quell-DB-Instance.

Durch Skalieren der DB-Instance-Klasse einer Read Replica können Verzögerungen in einigen Fällen verringert werden, insbesondere, wenn Ihre Quell-DB-Instance-Klasse höher als die Klasse der DB-Instance Ihrer Read Replica ist. Dennoch ist es nicht garantiert, dass Read Replicas in allen Fällen funktionieren. Es kann Szenarios und Nutzungsmuster geben, in denen eine Read Replica nach ihrer ersten Erstellung nie ganz zur Quelle aufholt oder zu weit hinter ihr zurückbleibt, um Ihre individuellen Anforderungen zu erfüllen.

F: Ich habe die Rechen- und/oder Speicherkapazität meiner Quell-DB-Instance skaliert. Sollte ich die Ressourcen für zugehörige Read Replica(s) ebenfalls skalieren?

Für eine effektiv funktionierende Replikation empfehlen wir, Read Replicas gleich viel oder mehr Rechen- und Speicherressourcen zuzuweisen wie ihren entsprechenden Quell-DB-Instances. Andernfalls ist es wahrscheinlich, dass es zu größeren Verzögerungen bei der Replikation kommt oder dass ihre Read Replica nicht über genügend Speicherplatz zur Speicherung replizierter Updates verfügt.

F: Kann ich DB-Snapshots oder automatisierte Backups von Read Replicas anfertigen?

Nein. Wenn Sie die Schreibverfügbarkeit der Datenbank erhöhen möchten, indem Sie Backups von Ihrer Read Replica statt von der Quell-DB-Instance anfordern, können Sie dieses Ziel auch erreichen, indem Sie Ihre DB-Instance als Multi-AZ-Bereitstellung ausführen. Backups werden dann von der Multi-AZ-Standby-Instance initiiert, um die Beeinträchtigung der Verfügbarkeit zu minimieren.

F: Wie lösche ich eine Read Replica? Wird sie automatisch gelöscht, wenn auch die Quell-DB-Instance gelöscht wird?

Sie können eine Read Replica ganz einfach mit wenigen Klicks in der AWS-Managementkonsole oder durch Weitergabe ihrer DB-Instance-Kennung an die API DeleteDBInstance löschen.

Eine Read Replica von Amazon Aurora (MySQL) bleibt selbst dann aktiv und verarbeitet weiterhin Lesedatenverkehr, wenn ihre zugehörige Quell-DB-Instance gelöscht wurde. Eine der Read Replicas im Cluster wird automatisch zur neuen Master-Instance hochgestuft und beginnt mit der Verarbeitung des Schreibverkehrs.

Eine Read Replica von Amazon RDS for MySQL oder MariaDB bleibt selbst dann aktiv und verarbeitet weiterhin Lesedatenverkehr, wenn ihre zugehörige Quell-DB-Instance gelöscht wurde. Wenn Sie die Read Replica zusätzlich zur Quell-DB-Instance löschen möchten, müssen Sie die Read Replica explizit über die API DeleteDBInstance oder die AWS-Managementkonsole löschen.

Wenn Sie eine Amazon RDS for PostgreSQL-DB-Instance löschen, die über Read Replicas verfügt, werden alle Read Replicas zu eigenständigen DB-Instances umgewandelt und können dann sowohl Lese- als auch Schreibverkehr verarbeiten. Die umgewandelten DB-Instances arbeiten unabhängig voneinander. Falls Sie diese DB-Instances zusätzlich zur ursprünglichen Quell-DB-Instance löschen möchten, müssen Sie dies explizit über die API DeleteDBInstance oder die AWS-Managementkonsole tun.

F: Kann ich direkt auf die Ereignisprotokolle für meine Datenbank-Instance zugreifen?

Mit Amazon RDS for MySQL oder Amazon RDS for MariaDB können Sie mithilfe des Dienstprogramms mysqlbinlog Binärprotokolle aus Ihrer DB-Instance herunterladen oder streamen. Amazon RDS for PostgreSQL bietet zurzeit keinen Zugriff auf die WAL-Dateien für Ihre DB-Instance.

F: Wie viel kosten Read Replicas? Wann beginnt und endet die Fakturierung?

Eine Read Replica wird als standardmäßige DB-Instance zu denselben Tarifen abgerechnet. Klicken Sie hier, um die häufig gestellten Fragen zur Fakturierung von DB-Instances aufzurufen. Wie bei einer standardmäßigen DB-Instance wird der Tarif pro "DB-Instance-Stunde" für eine Read Replica durch die DB-Instance-Klasse der Read Replica bestimmt. Aktuelle Preisangaben finden Sie auf der Detailseite von Amazon RDS. Der bei der Replikation von Daten zwischen Ihrer Quell-DB-Instance und der Read Replica anfallende Datenverkehr wird Ihnen nicht in Rechnung gestellt.

Die Fakturierung für eine Read Replica beginnt, sobald diese erfolgreich erstellt wurde (d. h., wenn ihr Status als "aktiv" aufgeführt ist). Die Read Replica wird so lange nach standardmäßigen DB-Instance-Stundensätzen von Amazon RDS abgerechnet, bis Sie den Befehl ausgeben, sie zu löschen.

F: Wie unterscheidet sich der Support für Read Replicas zwischen den Amazon RDS-Engines, die diese Funktion unterstützen?

Read Replicas in Amazon RDS for PostgreSQL, MySQL und MariaDB ermöglichen Ihnen die elastische Skalierung über die Kapazitätsgrenzen einer einzelnen DB-Instance hinaus, um leseintensive Datenbank-Arbeitslasten zu ermöglichen. Es gibt Ähnlichkeiten und Unterschiede bei den Implementierungen, da sie native Engine-Funktionen nutzen. Details finden Sie in der folgenden Tabelle.

Funktion PostgreSQL MySQL MariaDB
Höchstzahl der erlaubten Read Replicas pro Quell-DB-Instance
5 5 5
Replikationsmethode Asynchron
Physisch
Asynchron
Logisch
Asynchron
Logisch
Müssen automatische Backups für die Unterstützung von Read Replicas aktiviert sein? Ja Ja Ja
Engine-Versionen, für die Read Replicas verfügbar sind 9.3.5 oder höher 5.5 oder höher 10.0 oder höher
Umwandlung einer Read Replica in eine eigenständige DB-Instance Unterstützt Unterstützt Unterstützt
Erstellen von Indizes auf Read Replicas Zurzeit nicht unterstützt Unterstützt Unterstützt
Erstellen von Backups auf Read Replicas Zurzeit nicht unterstützt Unterstützt Unterstützt
Chaining von Read Replicas
(d. h. Read Replicas von Read Replicas)
Zurzeit nicht unterstützt Unterstützt Unterstützt
Regionsübergreifende Read Replicas Unterstützt Unterstützt Unterstützt
Multi-AZ-Read-Replicas
Unterstützt Unterstützt Unterstützt

F: Was ist Enhanced Monitoring für RDS?

Enhanced Monitoring für RDS bietet Ihnen bessere Einblicke in den Zustand Ihrer RDS-Instances. Schalten Sie einfach die Option "Enhanced Monitoring" für Ihre RDS-DB-Instance ein und legen Sie die Granularität fest. Enhanced Monitoring erfasst wichtige Metriken des Betriebssystems und verarbeitet Daten mit der definierten Granularität.

F: Welche Metriken und Prozesse kann ich in Enhanced Monitoring überwachen?

Enhanced Monitoring erfasst Metriken Ihrer RDS-Instance auf Systemebene, beispielsweise CPU, Arbeitsspeicher, Dateisystem, Festplatten-E/A usw. Eine vollständige Liste der Metriken finden Sie hier.

F: Welche Engines werden durch Enhanced Monitoring unterstützt?

Enhanced Monitoring unterstützt alle RDS-Datenbank-Engines.

F: Welche Instance-Typen werden durch Enhanced Monitoring unterstützt?

Enhanced Monitoring unterstützt alle Instance-Typen außer t1.micro und m1.small. Die Software nutzt CPU, Arbeitsspeicher und E/A in geringem Umfang. Für eine allgemeine Überwachung empfehlen wir, für mittlere oder größere Instances höhere Granularitäten zu verwenden. Bei Nicht-Produktions-DB-Instances lautet die Standardeinstellung für Enhanced Monitoring "off". Sie können die Option deaktiviert lassen oder die Granularität ändern, wenn die Option aktiviert ist.

F: Welche Informationen finde ich auf dem RDS-Dashboard?

Sie können in der Konsole alle Systemmetriken und Prozessinformationen zu Ihrer RDS-DB-Instance in einem grafischen Format anzeigen. Sie können festlegen, welche Metriken Sie für jede Instance überwachen wollen, und das Dashboard an Ihre Anforderungen anpassen.

F: Erfassen alle Instances in meinem RDS-Konto Metriken mit der gleichen Granularität?

Nein. Sie können für jede einzelne DB-Instance in Ihrem RDS-Konto unterschiedliche Granularitäten festlegen. Außerdem können Sie wählen, für welche Instances Enhanced Monitoring aktiviert werden soll, und Sie können die Granularität aller Instances jederzeit ändern.

F: Bis wie weit in die Vergangenheit kann ich historische Metriken auf der RDS-Konsole abrufen?

Sie können die Leistungswerte aller Metriken bis zu einer Stunde in der Vergangenheit und mit einer Granularität von bis zu einer Sekunde sehen.

F: Wie kann ich die durch RDS Enhanced Monitoring generierten Metriken in CloudWatch visualisieren?

Die Metriken von RDS Enhanced Monitoring werden in Ihr CloudWatch Logs-Konto übermittelt. Sie können in CloudWatch Metrikfilter aus CloudWatch Logs erstellen und die Grafiken auf dem CloudWatch-Dashboard anzeigen. Weitere Informationen finden Sie auf der Seite Amazon CloudWatch.

F: Wann sollte ich CloudWatch statt des Dashboards der RDS-Konsole verwenden?

Sie sollten CloudWatch verwenden, wenn Sie historische Daten anzeigen möchten, die im Dashboard der RDS-Konsole nicht verfügbar sind. Sie können Ihre RDS-Instances in CloudWatch überwachen, um den Zustand Ihres gesamten AWS-Stacks an einer zentralen Stelle zu diagnostizieren. Zurzeit unterstützt CloudWatch Granularitäten von bis zu einer Minute und für niedrigere Granularitäten werden Durchschnittswerte gebildet.

F: Kann ich Alarme und Benachrichtigungen auf Basis bestimmter Metriken einrichten?

Ja. Sie können in CloudWatch einen Alarm einrichten, der eine Benachrichtigung versendet, wenn sich der Zustand einer Metrik ändert. Der Alarm überwacht eine Metrik über einen bestimmten, von Ihnen definierten Zeitraum und führt eine oder mehrere Aktionen durch, die vom Wert der Metrik im Vergleich zu einem bestimmten Schwellenwert in einer Reihe von Zeiträumen abhängt. Nähere Informationen zum Erstellen von CloudWatch-Alarmen finden Sie im Amazon CloudWatch-Entwicklerhandbuch.

F: Wie kann ich Enhanced Monitoring in das Tool integrieren, das ich zurzeit verwende?

RDS Enhanced Monitoring sendet eine Reihe von Metriken in Form von JSON-Inhalten, die in Ihr CloudWatch Logs-Konto übermittelt werden. Die JSON-Inhalte werden in der Granularität übermittelt, die zuletzt für die RDS-Instance konfiguriert wurde.

Es gibt zwei Methoden, die Metriken über ein Dashboard oder eine Anwendung eines Drittanbieters zu beziehen. Überwachungs-Tools können CloudWatch Logs-Abonnements verwenden, um für Metriken einen Feed fast in Echtzeit einzurichten. Als Alternative können Sie Filter in CloudWatch Logs verwenden, um Metriken an CloudWatch zu übertragen und Ihre Anwendung in CloudWatch zu integrieren. Weitere Informationen finden Sie in der Amazon CloudWatch-Dokumentation.

F: Wie kann ich historische Daten löschen?

Da Enhanced Monitoring JSON-Inhalte in ein Protokoll in Ihrem CloudWatch Logs-Konto übermittelt, können Sie den Aufbewahrungszeitraum ebenso wie bei jedem anderen CloudWatch Logs-Stream festlegen. Der Standardzeitraum für die Aufbewahrung beträgt für Enhanced Monitoring in CloudWatch Logs 30 Tage. Informationen zum Einstellen des Aufbewahrungszeitraums finden Sie im Amazon CloudWatch-Entwicklerhandbuch.

F: Wie wirkt sich Enhanced Monitoring auf meine monatlichen Rechnungen aus?

Da die Metriken in CloudWatch Logs aufgenommen werden, sind die Kosten von den CloudWatch Logs-Gebühren für Datenübertragung und -speicherung abhängig, nachdem Sie das kostenlose Kontingent für CloudWatch Logs aufgebraucht haben. Preisinformationen finden Sie hier. Der Umfang der übertragenen Daten für eine RDS-Instance ist direkt proportional zur definierten Granularität für Enhanced Monitoring. Administratoren können in ihren Konten unterschiedliche Granularitäten für unterschiedliche Instances einstellen, um die Kosten zu verwalten.

Das ungefähre Volumen der durch Enhanced Monitoring für eine Instance in CloudWatch Logs übertragenen Daten lautet wie folgt:

Granularität

60 Sekunden

30 Sekunden

15 Sekunden

10 Sekunden

5 Sekunden

1 Sekunde

In CloudWatch Logs* übertragene Daten (GB pro Monat)

0,27

0,53

1,07

1,61

3,21

16,07