Kostenlos bei AWS einsteigen

Kostenloses Konto erstellen

Das kostenlose Nutzungskontingent 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 Sicherungen.

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 führt automatisch Patches der Datenbank-Software durch und erstellt Backups Ihrer Datenbank. Diese Backups werden für einen vom Benutzer definierten Zeitraum aufbewahrt. Ein weiterer Vorteil für Sie ist die flexible Skalierung der Rechenressourcen oder der Speicherkapazität für die Instanz Ihrer relationalen Datenbank. Darüber hinaus können Sie mit Amazon RDS einfach mithilfe von Replizierung die Datenbankverfügbarkeit und die Widerstandsfähigkeit Ihrer Daten verbessern oder über Kapazitätsgrenzen einer einzelnen Datenbank-Instanz 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: 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 Management Console,der Amazon RDS-APIs und der 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: 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 auf der eigenen DB Instance ausgeführt wird, automatisiert Amazon RDS allgemeine administrative Aufgaben, z. B. die Durchführung von Backups und die Aktualisierung der Datenbank-Software mit Patches. Für optionale Multi-AZ-Bereitstellungen verwaltet Amazon RDS auch die synchrone Datenreplizierung über mehrere Availability Zones und den automatischen 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 würde ich Amazon RDS gegenüber Amazon EC2-AMIs für relationale Datenbanken vorziehen?

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. Auf der Seite 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 bitte die Dokumentation zu Amazon RDS, die das Handbuch "Erste Schritte" enthält.

F: Wie erstelle ich eine DB-Instance?

DB-Instances sind einfach zu erstellen. Sie können hierfür entweder die AWS Management Console, Amazon RDS-APIs oder die AWS-Befehlszeilenschnittstelle verwenden. Um eine DB-Instance über die AWS Management Console zu starten, klicken Sie auf "RDS" und dann auf "Launch DB Instance" auf der Registerkarte "Instances". 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 eine ausgeführte DB-Instance zugreifen?

Sobald Ihre DB-Instance verfügbar ist, können Sie deren Endpunkt über die DB-Instance-Beschreibung in der AWS Management Console, 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 dem Modell "License Included" (Lizenz eingeschlossen) sein. Alle 40 können für Amazon Aurora, MySQL, MariaDB, Oracle, SQL Server oder PostgreSQL gemäß dem "BYOL"-Modell (Verwendung der eigenen Lizenz) genutzt werden. 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 in einer DB-Instance ausführen?

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

F: Wie importiere ich Daten in Amazon RDS?

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 Data Import Guide for MySQL, Data Import Guide for Oracle, Data Import Guide for SQL Server oder Data Import Guide for PostgreSQL.

F: Welche relationalen Datenbanksysteme werden von Amazon RDS unterstützt?

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

Amazon RDS unterstützt derzeit MySQL 5.5, 5.6 und 5.7 (Community Edition) mit InnoDB als standardmäßige Datenbank-Storage-Engine. Amazon RDS für MariaDB unterstützt derzeit MariaDB 10.0 und 10.1. Amazon RDS für Oracle unterstützt derzeit Oracle Database 11gR2 und 12c. Amazon RDS für SQL Server unterstützt derzeit 2008 R2, SQL Server 2012 (SP2) und SQL Server 2014. Amazon RDS für PostgreSQL unterstützt derzeit PostgreSQL 9.3, 9.4 und 9.5.

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

F: Was ist ein Wartungs- bzw. Aktualisierungsfenster? Steht meine DB Instance während der Softwareaktualisierung zur Verfügung?

Das Amazon RDS-Aktualisierungsfenster bietet gewissermaßen die Möglichkeit, zu kontrollieren, wann Modifizierungen der DB-Instance (z. B. eine Skalierung der DB-Instance-Klasse) oder Software-Patches vorgenommen werden, sollten diese angefordert oder notwendig werden. Wenn ein Wartungsereignis für eine bestimmte Woche angesetzt ist, wird es innerhalb des von Ihnen festgelegten Wartungsfensters ausgelöst und abgeschlossen. Wartungsfenster haben eine Dauer von 30 Minuten.

Die einzigen Aktualisierungsarbeiten, bei denen Amazon RDS Ihre DB Instance offline nehmen muss, sind Skalierungen des Datenverarbeitungsbetriebs (die in der Regel nur wenige Minuten in Anspruch nehmen) sowie erforderliche Software-Patches. Erforderliche 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 Aktualisierungsfensters in Anspruch nehmen. Falls Sie kein bevorzugtes Aktualisierungsfenster festlegen, wenn Sie Ihre DB Instance erstellen, wird ein 30-minütiger Standardwert zugewiesen. Wenn Sie den Wartungszeitpunkt modifizieren möchten, können Sie dazu Ihre DB-Instance in der AWS Management Console, 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 Aktualisierungsfenster anzugeben.

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

F: Stellt Amazon RDS Richtlinien zur Unterstützung der neuen Datenbank-Engine-Versionen und der veralteten Datenbank-Engine-Versionen, die derzeit unterstützt werden, zur Verfügung?

Diese Aussage gilt für Amazon RDS für Amazon Aurora, MySQL, MariaDB, Oracle, SQL Server und PostgreSQL.

Wir planen, im weiteren Verlauf weitere Datenbankversionen für Amazon RDS-Engines zu unterstützen, sowohl Haupt- als auch Nebenversionen. Die Anzahl der in einem bestimmten Jahr unterstützten neuen Versions-Updates hängt von der Häufigkeit und den Inhalten der veröffentlichten Updates und Patches des Herstellers bzw. Kernteam 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 3-5 Monaten nach ihrer allgemeinen Einführung zu unterstützen.

Hier ein allgemeiner Überblick über die Aktualisierungsrichtlinie für Amazon RDS:

  • Wir versuchen, Hauptversionen (z. B. MySQL 5.6), über einen Zeitraum von drei Jahren ab der ersten Einführung für Amazon RDS zu unterstützen.
  • Nebenversionen (z. B. MySQL 5.6.21) sollen nach ihrer ersten Einführung für Amazon RDS mindestens ein Jahr unterstützt werden.
  • Von Zeit zu Zeit wird die Unterstützung von Haupt- und Nebenversionen eingestellt. Nach der Ankündigung des Einstellens der Unterstützung einer Version wird ein dreimonatiger Übergangszeitraum eingeräumt, in dem Sie selbst ein Upgrade auf eine unterstützte Version ausführen können. Nach Ablauf dieses Übergangszeitraums wird im Rahmen geplanter Wartungsfenster ein automatisches Upgrade auf alle Instances ohne zuvor erfolgtes Upgrade angewendet.
  • 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.

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 Kennzahlen 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 zum Überwachen der DB-Instance finden Sie im Amazon RDS-Benutzerhandbuch.

Falls Sie 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 Oracle verwenden, können Sie Oracle Ablaufdateidaten verwenden, um langsame Abfragen zu identifizieren. Für weitere Informationen zu Ablaufdateidaten lesen Sie bitte das Amazon RDS Benutzerhandbuch.

Falls Sie SQL Server verwenden, können Sie die SQL Server-Ablaufverfolgungsprotokolle auf Client-Seite zum Bestimmen langsamer Abfragen nutzen. Weitere Informationen für den Zugriff auf die Daten in der Ablaufverfolgungsdatei auf Serverseite finden Sie im Amazon RDS-Benutzerhandbuch.

F: Warum sind die Gebühren für die einzelnen RDS-Datenbank-Engines unterschiedlich?

Die Gebühren für die einzelnen Datenbank-Engines von RDS sind unterschiedlich, da unsere Kosten jeweils unterschiedlich sind. Diese Kosten umfassen zusätzlich zur Softwarelizenzierung viele Betriebskomponenten. Wir arbeiten weiter daran, Kosten zu senken und die daraus entstehenden Einsparungen an unsere Kunden weiterzugeben.  


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. Standard Small, Large, Extra 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)
  • Bereitgestellte E/A\Sek. pro Monat – Bereitgestellte E/A\Sek.-Rate, unabhängig von den verbrauchten E/A\Sek. (nur für bereitgestellte E/A\Sek.-Speicher (SSD) in Amazon RDS)
  • Backup-Speicher – der Backup-Speicher ist der Speicher für Ihre automatisierten Datenbank-Backups und jegliche selbst erstellten aktiven Datenbank-Snapshots. Wenn Sie die Aufbewahrungszeit Ihrer Backups erhöhen oder zusätzliche Datenbank-Snapshots erstellen, belegt Ihre Datenbank dementsprechend mehr Backup-Speicher. Amazon RDS bietet ohne Aufpreis eine Backup-Speicherung von bis zu 100 % Ihres bereitgestellten Datenbankspeichers. Wenn Sie beispielsweise über einen bereitgestellten Datenspeicher von monatlich 10 GB verfügen, bieten wir Ihnen ohne Aufpreis bis zu 10 GB Backup-Speicher pro Monat. Nach unserer eigenen Erfahrung als Datenbankadministratoren benötigen die weitaus meisten Datenbanken weniger reinen Speicher für das Backup als für den primären Datensatz, d. h., dass unsere Kunden in der Regel nie für Backup-Speicher zahlen müssen. Der Backup-Speicher ist nur für aktive DB Instances kostenlos.
  • 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.

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

Die Fakturierung einer DB Instance beginnt zu dem Zeitpunkt, ab dem die Instanz 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 beenden, damit Ihnen keine weiteren Instanzstunden in Rechnung gestellt werden. Angebrochene DB Instance-Stunden werden als volle Stunden in Rechnung gestellt.

F: Warum ist zusätzlicher Reservespeicher 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, der über die kostenlose Zuordnung hinausgeht, spiegelt diese zusätzliche Replizierung 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 zu Grunde:

  • Multi-AZ DB Instance-Stunden – diese basieren auf der Klasse (z. B. Small, Large, Extra Large) der genutzten DB Instance. Wie 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 einer DB Instance-Standardbereitstellung und einer Multi-AZ-Bereitstellung wechseln, werden die beiden jeweiligen Gebühren für diese Stunde in Rechnung gestellt.
  • Bereitgestellter Speicherplatz (für Multi-AZ DB Instance) – wenn Sie innerhalb einer angebrochenen Stunde zwischen einer DB Instance-Standardbereitstellung und einer Multi-AZ-Bereitstellung wechseln, wird der höhere der beiden jeweiligen Gebührensätze für Speicher 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 als bei standardmäßigen DB Instance-Bereitstellungen verbraucht, in Abhängigkeit von den Schreib-/Leseraten Ihrer Datenbank. 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 Ihrer DB Instance nutzen. Backups werden einfach von der Standby-Replika 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-Instanz und Replika anfallende Datenverkehr wird Ihnen nicht in Rechnung gestellt.

F: Sind Steuern bereits in den Preisen enthalten?

Falls nicht anders angegeben, gelten unsere Preise zuzüglich geltender Steuern und Abgaben, darunter MwSt. und Umsatzsteuer. Bei Kunden mit japanischer Rechungsadresse unterliegt die Nutzung der Region Asien-Pazifik (Tokio) der japanischen Verbrauchssteuer. Weitere Informationen.


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

Das kostenlose AWS-Nutzungskontingent 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 ohne Berechnung 20 GB Datenbankspeicher, 10 Mio. E/A-Vorgänge und 20 GB Speicher für Sicherungen pro Monat.

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

Neuen AWS-Konten steht das kostenlose Nutzungskontingent von AWS 12 Monate zur Verfügung. Auf der Seite mit den häufig gestellten Fragen zum kostenlosen 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-Nutzungskontingent 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 für je 400 Stunden 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 Nutzungsstunden für AWS-Kunden im Rahmen des kostenlosen AWS-Nutzungskontingents für jede der Micro DB-Instances (MySQL, MariaDB, PostgreSQL, Oracle oder SQL Server) separat?

Nein. Nein. Ein Kunde mit Berechtigung für das kostenlose Nutzungskontingent für AWS kann Micro-Instances, die mit entweder 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-Nutzungskontingent für Amazon RDS in allen AWS-Regionen zur Verfügung?

Das kostenlose AWS-Nutzungskontingent 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 für Instances das kostenlose Nutzungskontingent ü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 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, eine Abstimmung zwischen dem Betrag Ihrer Vorauszahlung und Ihrem effektiven Stundenpreis zu finden.

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

Funktionell gesehen sind reservierte Instances und On-Demand Instances genau gleich. Der einzige Unterschied besteht in der Abrechnung Ihrer Instance(s). Bei Reserved Instances erwerben Sie eine Reservierung für ein 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.

F: Wie kann ich Reserved Instances erwerben und erstellen?

Sie können eine Reserved Instance im Bereich "Reserved Purchase" der AWS Management Console erwerben. Alternativ können Sie unter Verwendung der API "Amazon RDS" 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 einer On-Demand-DB-Instance. Starten Sie eine DB-Instance unter Verwendung derselben Klasse, Engine und Region wie für die Instance, für die Sie die Reservierung vorgenommen haben. Solange Ihre Reservierung aktiv ist, erhalten Sie von Amazon RDS den entsprechenden reduzierten Stundensatz für die neue DB-Instance.

F: Stehen immer Reservierungen zum Erwerb zur Verfügung?

Ja. Reservierte Instances werden für die Region, nicht für die Availability Zone erworben. Also auch dann, wenn die Kapazität in einer Availability Zone begrenzt ist, können Reservierungen für eine Region erworben und in einer anderen Availability Zone innerhalb der Region genutzt werden.

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 in eine Reserved Instance umwandeln möchte?

Erwerben Sie einfach eine DB Instance-Reservierung derselben DB Instance-Klasse, dem gleichen DB Engine und Lizenzmodell in derselben Region wie die DB Instance, die Sie aktuell ausführen und reservieren möchten. Nach erfolgreichem 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 reservierte Instance wieder der entsprechende On-Demand-Nutzungstarif Ihrer DB Instance-Klasse und -Region.

F: Wie kann ich kontrollieren, 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: Was geschieht mit meiner Reservierung, wenn ich meine ich meine Reserved Instance erweitere oder verkleinere?

Jede Reservierung wird mit dem folgenden Satz an Attributen verknüpft: DB Engine, DB Instance-Klasse, Bereitstellungstyp, Lizenzmodell und Region. Jede Reservierung kann nur für eine DB Instance mit den gleichen Attributen für die Dauer der Laufzeit angewandt werden. Wenn Sie sich entscheiden, Ihre DB Instance-Klasse vor dem Ende des Abrechnungszeitraums zu modifizieren, gelten wieder die normalen On-Demand-Tarifsätze für diese DB Instance anstatt des Stundentarifsatzes. Wenn Sie die Attribute der ausgeführten DB Instance später an die ursprüngliche Reservierung anpassen oder eine neue DB Instance mit denselben Attributen wie Ihre ursprüngliche Reservierung erstellen, findet bis zum Ende Ihres Reservierungszeitraums wieder der reduzierte Tarif Anwendung.

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

Jede reservierte Instance ist mit einer bestimmten Region verbunden, 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 Replizierung ü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 standardmäßige DB Instance-Reservierung kann auch auf eine Read Replica angewandt werden, vorausgesetzt, die DB Instance-Klasse und -Region sind identisch. Bei der Verarbeitung Ihrer Abrechnung wendet unser System automatisch Ihre Reservierung(en) an, sodass alle berechtigten Instances nach dem reduzierten Stundentarif für reservierte DB Instances abgerechnet werden.

F: Kann ich eine Reservierung stornieren?

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

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

Wenn Sie eine RI mit der Zahlungsoption "Komplette Vorauszahlung" erwerben, zahlen 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 DB-Instance-Klasse und Speicherkapazität für meine anfänglichen 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 Management Console (gewünschte DB-Instance auswählen und auf "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 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 Werte wie die CPU-Auslastung, die Speicherauslastung oder den Netzwerkverkehr abrufen. Klicken Sie hierfür auf die Registerkarte "Monitoring" (Überwachung) in der AWS Management Console 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 Speicher einer SQL Server DB Instance zu vergrößern, müssen Sie die Daten exportieren, eine neue DB Instance mit größerem Speicher 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. Sie können bei MySQL und Oracle bei einer vorhandenen DB-Instance eine Verbesserung der E/A-Kapazität feststellen, wenn Sie Ihren Speicher vergrößern. Sie können die der DB-Instance zugewiesene Speicherkapazität erweitern. Verwenden Sie hierfür die AWS Management Console, 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 vorübergehend nicht verfügbar. Der Zeitraum der Nichtverfügbarkeit dauert in der Regel nur wenige Minuten und liegt innerhalb des 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 dadurch 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 der Basisleistung von 3 E/A\Sek./GB und der Fähigkeit kurzzeitiger Spitzenleistung von bis zu 3 000 E/A\Sek. bietet diese Speicheroption eine vorhersehbare Leistung, die die Anforderungen der meisten Anwendungen erfüllt.

F: Was ist bereitgestellter E/A\Sek.-Speicher (SSD) in Amazon RDS?

Bereitgestellter E/A\Sek.-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. Mit bereitgestelltem E/A\Sek.-Speicher (SSD) in Amazon RDS geben Sie bei der Erstellung einer DB-Instance eine E/A\Sek.-Rate an und Amazon RDS stellt diese E/A\Sek.-Rate dann für die Lebensdauer der DB-Instance bereit. Von Amazon RDS bereitgestellter E/A\Sek.-Speicher ist für E/A-intensive, transaktionale Datenbankarbeitslasten (OLTP) optimiert. Nähere Informationen finden Sie im Benutzerhandbuch zu Amazon RDS.

F: Was sind Magnetfestplatten in Amazon RDS Magnetic?

Magnetfestplatten (zuvor als Amazon RDS-Standardspeicher bezeichnet) sind bei kleinen Datenbankarbeitslasten nützlich, bei denen weniger häufig auf Daten zugegriffen wird.

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 E/A\Sek.-Speicher (SSD) in Amazon RDS
  • Datenbanken mit mäßigen E/A-Anforderungen: Amazon RDS-Standardspeicher (SSD)
  • Kleine Datenbankarbeitslasten mit seltenen E/A: Amazon RDS-Magnetfestplatten

F: Welche minimale und maximale E/A\Sek.-Kapazität wird von Amazon RDS unterstützt?

Die von Amazon RDS unterstützte E/A\Sek.-Kapazität hängt von der jeweiligen Datenbank-Engine ab. Nähere Informationen finden Sie im Benutzerhandbuch zu Amazon RDS.

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

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

Die Amazon RDS-Funktion für automatisierte Backups gestattet Wiederherstellungen Ihrer DB Instance zu einem beliebigen Zeitpunkt. 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 zu dem gewünschten Zeitpunkt wiederherzustellen. Amazon RDS bewahrt Backups einer DB Instance für einen begrenzten, benutzerdefinierten Zeitraum (den "Aufbewahrungszeitraum") auf. Dieser liegt standardmäßig bei einem Tag, 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(s) 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 Management Console auswählen und unter der Registerkarte "Description" (Beschreibung) im unteren Arbeitsbereich der Console 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 Management Console, der API "CreateDBSnapshot" oder dem Befehl "create-db-snapshot" erstellt werden. Sie werden solange 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 Console 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 die Zeit ermitteln, zu der der Snapshot erstellt wurde, indem Sie das Feld "Zeitpunkt der Snapshot-Erstellung" anzeigen. Die Kennzeichnung des "automatisierten" Snapshots enthält alternativ ebenfalls die Zeit (UTC), zu der 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 Sicherungen für meine DB-Instance aktivieren oder geschieht dies automatisch?

Das automatische Backup Ihrer DB Instance ist in Amazon RDS standardmäßig aktiviert und kostenlos. Es gilt ein Aufbewahrungszeitraum von einem Tag. 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 Datenspeicher von monatlich 10 GB verfügen, bieten wir Ihnen ohne Aufpreis höchstens 10 GB Backup-Speicher pro Monat. Mit der "CreateDBInstance"-API (bei der Erstellung einer neuen DB Instance) oder der ModifyDBInstance-API (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 Sicherungsfenster 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 Backups 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 dem Standby-Replikat angefertigt wird.

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

Amazon RDS DB Snapshots und automatisierte Sicherungen werden in S3 gespeichert.

Unter Verwendung der AWS Management Console, 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 Sicherungen vollständig deaktivieren möchten (was nicht empfohlen wird), setzen Sie den Aufbewahrungszeitraum auf 0. Sie können Ihre benutzererstellten Snapshots über den Bereich "Snapshots" in der Amazon RDS Console 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: Was passiert mit meinen Sicherungen 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 Sicherungen.

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


F: Was ist Amazon Virtual Private Cloud (VPC) und warum sollte ich sie mit Amazon RDS nutzen?

Mit Amazon VPC können Sie eine virtuelle Netzwerkumgebung in einem privaten, isolierten Bereich der Amazon Web Services (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, so dass sie einem herkömmlichen IP-Netzwerk ähnelt, das sie in Ihrem eigenen Rechenzentrum betreiben könnten.

Eines der Szenarien, in denen es hilfreich wäre, wenn Sie Amazon RDS in VPC verwenden ist die Ausführung einer öffentlich zugänglichen Webanwendung bei einer gleichzeitigen Nutzung nicht öffentlich zugänglicher Backend-Server in einem privaten Subnetz. 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 User Guide.

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

Die grundlegenden Funktionen von Amazon RDS sind dieselben, unabhängig davon, ob VPC genutzt wird. Amazon RDS verwaltet Sicherungen, Software-Patches, automatische Fehlererkennung, Read Replicas und Wiederherstellungen unabhängig davon, ob Ihre DB-Instances innerhalb oder außerhalb einer VPC bereitgestellt werden.

Amazon RDS DB Instances, die außerhalb einer VPC bereitgestellt werden, erhalten eine externe IP-Adresse (bei der der Endpunkt/DNS-Name aufgelöst wird). Diese stellt die Verbindung von EC2 oder vom Internet dar. In Amazon VPC haben Amazon RDS DB Instances nur eine private IP-Adresse (innerhalb eines von Ihnen definierten Subnetzes). Sie können eine VPC so konfigurieren, dass eine Amazon RDS-DB-Instance in dieser VPC öffentlich zugänglich ist. Weitere Informationen finden Sie in der VPC-Dokumentation. 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önnten. 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-Netzwerkschnittstelle mit dieser IP-Adresse zu.

Es wird dringend empfohlen, dass Sie den DNS-Namen für die Verbindung mit Ihrer DB Instance verwenden, da die zugrunde liegende IP-Adresse sich ä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?

Ein detailliertes Beispiel zur Erstellung einer DB Instance in VPC erhalten Sie im Amazon RDS User Guide.

Im Folgenden sehen Sie die erforderlichen Voraussetzungen zum Erstellen von DB Instances in einer VPC:

  • In jeder Availability Zone einer Region, in der Sie Ihre DB Instance bereitstellen möchten, muss eine VPC mit mindestens einem Subnetz eingerichtet sein. Weitere Informationen zum Erstellen von Amazon VPC und Subnetzen erhalten Sie im Getting Started Guide for Amazon VPC.
  • Für Ihre VPC muss eine DB Subnet Group definiert sein.
  • Für Ihre VPC muss eine DB-Sicherheitsgruppe definiert sein (oder Sie können den verfügbaren Standard verwenden).
  • Außerdem sollten Sie jedem Subnetz entsprechend große CIDR-Blocks zuweisen, damit ausreichend zusätzliche IP-Adressen für Amazon RDS zur Verfügung stehen. Diese können Sie während Wartungsaktivitäten, u. a. Skalierung des Rechenbetriebs und Failover, verwenden.

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

Im Amazon RDS User Guide finden Sie im Abschnitt Security GroupsInformationen zu den verschiedenen Möglichkeiten, den Zugriff auf Ihre DB-Instances zu steuern.

F: Wie sichere ich Amazon RDS-DB-Instances, die in meiner VPC ausgeführt werden?

Sie können VPC-Sicherheitsgruppen verwenden, um DB-Instances innerhalb einer Amazon VPC zu schützen. Zusätzlich kann eingehender oder ausgehender Netzwerkverkehr der Subnetze über Netzwerk-Zugriffskontrolllisten (ACLs) zugelassen oder gesperrt werden. Sie können den gesamten ein- und ausgehenden Netzwerkverkehr Ihrer VPC über die IPsec VPN-Verbindung mit Ihrer bestehenden Sicherheitsinfrastruktur, wie Firewalls und Intrusion-Detection- und Intrusion-Prevention-Systeme, am Standort überprüfen.

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 auf die EC2-Instances über das Internet 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-Instanz 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-Instanz weiterleiten.
  • Erstellen Sie für eine öffentliche Anbindung Ihre DB-Instances mit auf "yes" festgelegter Option "Publicly Accessible". Wenn "Publicly Accessible" aktiv ist, kann von außerhalb Ihrer VPC standardmäßig auf Ihre DB-Instances in der VPC voll 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 User Guide.

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 Management Console 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 nicht unterstützt. Aus Sicherheitsgründen kann ein 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". Wenn Sie Ihre DB Instance von innerhalb der VPC nach außen verschieben, müssen Sie Ihre Daten aus Ihrer Quell-DB Instance in Ihrer VPC in Ihre außerhalb der VPC bereitgestellte Ziel-DB Instance exportieren.

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 für Ihre Client-Instances im VPC erreichbar sind.

Bei Multi-AZ-Bereitstellungen befinden sich Ihre Client-EC2 Instance und die RDS DB-Instance 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 nach dem Erstellen der DB-Instance für vorhandene Availability Zones oder für neue Availability Zones mehr Subnetze hinzuzufügen. 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.

Derzeit wird bei Aktualisierung einer vorhandenen DB-Subnetzgruppe nicht das aktuelle Subnetz der bereitgestellten DB-Instance geändert. Eine Skalierung des Instance-Typs ist erforderlich. Das explizite Ändern der DB-Subnetzgruppe einer bereitgestellten DB-Instance ist derzeit nicht zulässig.

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 ihnen 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 der Rolle zugeordneten Berechtigungen. Bitte lesen Sie das Amazon RDS Benutzerhandbuch für eine Liste mit den eingeschränkten Privilegien und den entsprechenden Alternativen, um administrative Aufgaben durchzuführen, die diese Privilegien eventuell erfordern.

Bei SQL Server wird dem Benutzer, der eine Datenbank anlegt, die Rolle "db_owner" zugewiesen. Bitte lesen Sie das Amazon RDS Benutzerhandbuch für eine Liste mit den eingeschränkten Privilegien und den entsprechenden Alternativen, um administrative Aufgaben durchzuführen, die diese Privilegien eventuell erfordern.

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

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 absichtlich 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 Datenbank-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 User Guide, MariaDB User GuideSQL Server User GuidePostgreSQL User Guide oder Oracle User Guide 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 gespeicherte 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 Datenbank-Instance sind die im zugrunde liegenden Speicher gespeicherten Daten verschlüsselt, was auch für deren automatisierte Sicherungen, Read Replicas und Snapshots gilt. Ver- und Entschlüsselung erfolgen vom Benutzer unbemerkt. Weitere Informationen zur Verwendung von KMS mit Amazon RDS finden Sie im Amazon RDS User Guide.

Das Verschlüsseln einer vorhandenen DB-Instance wird derzeit nicht unterstützt. Erstellen Sie zum Verwenden der Amazon RDS-Verschlüsselung für eine vorhandene Datenbank eine neue DB-Instance mit aktivierter Verschlüsselung und übertragen Sie Ihre Daten in diese Instance.

Amazon RDS for Oracle Database und SQL Server unterstützt 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 in den Abschnitten im Amazon RDS User Guide 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, die auf 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 Ihre 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 Management Console können Sie CloudTrail aktivieren.


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 Management Console, 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 Database Parameter Group (DB-Parametergruppe) 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 zu erstellen, wird eine DB-Parametergruppe verwendet. Diese Standardgruppe enthält Engine-Standards und Systemstandards für Amazon RDS, die für gerade ausgeführte DB Instances 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-Parametergruppe 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-Konfigurationsregeln 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 Replizierungsoptionen für unterschiedliche Zwecke an.

Wenn Sie mithilfe von Replizierung die Datenbankverfügbarkeit erhöhen und gleichzeitig Ihre aktuellsten 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 wartet Amazon RDS automatisch synchron ein "Standby"-Replikat in einer anderen Availability Zone (unabhängige Infrastruktur an einem physisch getrennten Standort). Im Fall einer geplanten Datenbank-Aktualisierung, eines Ausfalls einer DB Instance oder der Availability Zone führt Amazon RDS automatisch einen Failover zur aktuellen Standby-Replika durch, sodass der Datenbankbetrieb schnell und ohne Verwaltungsaufwand fortgesetzt werden kann. Multi-AZ-Bereitstellungen verwenden eine synchrone Replizierung, wobei Datenbank-Schreibvorgänge gleichzeitig in der primären und der Standby-Instanz erfolgen, sodass die Standby-Replika im Fall eines Failovers stets auf dem aktuellsten 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, damit Sie für leseintensive Datenbank-Arbeitslasten über die Kapazitätsgrenzen einer einzelnen Datenbank-Instance hinaus skalieren können. Sie können eine Read Replica einer bestimmten Quell-DB-Instance erstellen, indem Sie die AWS Management Console, die RDS-API oder die AWS-Befehlszeilenschnittstelle verwenden. Nach dem Erstellen der Read Replica werden Datenbank-Aktualisierungen an der Quell-DB-Instance auch für die Read Replica übernommen. Sie können mehrere Read Replicas für eine gegebene Quell-DB-Instance erstellen und den Lesedatenverkehr Ihrer Anwendung auf diese verteilen.

Read Replicas werden durch Amazon RDS für MySQL and 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 Ihrer/n Read Replica(s) übernommen werden, nachdem sie in der Quell-DB-Instance erfolgt sind ("asynchrone" Replizierung), und die Verzögerung bei der Replizierung 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 der zugehörigen Read Replica ü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, um 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 gegebene 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 wartet Amazon RDS automatisch synchron eine "Standby"-Replika in einer anderen Availability Zone. Aktualisierungen Ihrer DB Instance werden synchron über mehrere Availability Zones an den Standby-Daten repliziert, damit Ihre aktuellsten Datenbank-Updates synchronisiert und gegen einen Ausfall der DB Instance geschützt bleiben. Während bestimmten geplanten Aktualisierungsarbeiten oder im unwahrscheinlichen Fall eines Ausfalls der DB Instance oder der Availability Zone führt Amazon RDS automatisch einen Failover zu den Standby-Daten aus, sodass Sie die Schreib- und Lesevorgänge in Ihrer Datenbank unmittelbar nach dem Wechsel fortsetzen 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-Instanz, 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, dient die primäre Replika für Schreib- und Lesevorgänge in der Datenbank. Zusätzlich dazu stellt Amazon RDS im Hintergrund eine "Standby"-Instanz zur Verfügung, die eine stets aktuelle Replika der Primär-Instanz darstellt, und wartet diese. Bei Failover-Vorgängen wird die Standby-Instanz "hochgestuft". Nach dem Failover wird also die Standby-Instanz zur Primär-Instanz und nimmt dann Ihre Datenbank-Operationen entgegen. Zu keinem Zeitpunkt vor der Hochstufung interagieren Sie direkt mit der Standby-Instanz (etwa bei Lesevorgängen). Wenn Sie den Lesedatenverkehr über die Kapazitätseinschränkungen einer einzelnen DB-Instance hinaus skalieren möchten, lesen Sie die Fragen und Antworten unter 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 wichtige 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 Aktualisierungen zum Tragen. So werden E/A-Vorgänge in Ihrer Primär-Instanz beispielsweise bei automatisierten Backups im von Ihnen bestimmten Backup-Fenster nicht mehr unterbrochen, da die Backups von der Standby-Replika angefertigt werden. Im Fall von Patches oder Skalierungen der DB Instance-Klasse werden diese zunächst an der Standby-Replika vorgenommen, bevor der 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 der DB Instance-Failover automatisch erfolgt und keine Wartungsarbeiten mit sich bringt. Im Hinblick auf Amazon RDS bedeutet das, dass Sie nicht die DB Instance-Ereignisse überwachen und eine manuelle Wiederherstellung der DB Instance anstoßen müssen (über die APIs "RestoreDBInstanceToPointInTime" oder "RestoreDBInstanceFromSnapshot"), sollte es zu einer Unterbrechung in einer Availability Zone oder zu einem DB Instance-Ausfall kommen.

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 einzigen Availability Zone kommen.

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

Nein, die Standby-Replika kann keine Leseanforderungen bearbeiten. Der Zweck von Multi-AZ-Bereitstellungen ist eine Verbesserung der Datenbankverfügbarkeit und -zuverlässigkeit und nicht eine Skalierung der Lesevorgänge. Die Replikation zwischen primärer und Standby-Instanz erfolgt synchron. Durch unsere Implementierung wird sichergestellt, dass Primär- und Standby-Instanz konstant synchronisiert werden, gleichzeitig ist die Standby-Instanz 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 unter dem Punkt Read Replicas.

F: Wie richte ich eine Multi-AZ-Bereitstellung einer DB-Instance ein?

Um eine Multi-AZ-Bereitstellung einer DB Instance einzurichten, klicken Sie einfach auf die Option "Yes" (Ja) für "Multi-AZ Deployment" (Multi-AZ-Bereitstellung", wenn Sie eine DB Instance mit der AWS Management Console starten. Wenn Sie die Amazon RDS-APIs verwenden, können Sie die "CreateDBInstance"-API nutzen und den Parameter "Multi-AZ" auf "true" setzen. Um eine bestehende, standardmäßige DB Instance (einzelne AZ) in eine Multi-AZ-Bereitstellung zu konvertieren, modifizieren Sie die DB Instance in der AWS Management Console oder verwenden Sie die "ModifyDBInstance"-API 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 Datenbank-Engines von RDS 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ären Instance wird erstellt.
  • Eine neue Standby-Instance wird in einer anderen Availability Zone aus dem Snapshot erstellt.
  • Die synchrone Replikation wird zwischen primären 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-Replika?

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-Instanz
  • Ausfall einer Datenverarbeitungseinheit in der Primär-Instanz
  • Speicherfehler in der Primär-Instanz

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 das Standby-Replikat 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 Console oder Verwenden 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-Replika verwiesen wird, die dadurch zur neuen Primär-Instanz hochgestuft wird. Wir empfehlen Ihnen, sich an bewährte Methoden zu halten und eine Funktion auf der Anwendungsebene zu implementieren, die gegebenenfalls erneut versucht, eine Datenbankverbindung herzustellen.

Failover-Vorgänge erfolgen entsprechend der Festlegung des Zeitraums zwischen dem Erkennen des Ausfalls auf der primären 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 E/A-Sek.-Vorgängen 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 Management Console 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 "Multi-AZ"-Parameter auf "true". Die Erstellung der synchronen Standby-Replikation und das Failover werden automatisch abgewickelt. Das bedeutet, dass Sie nicht die Availability Zone auswählen können, in der Ihre Standby-Replika bereitgestellt wird, und auch nicht die Anzahl der verfügbaren Standby-Instanzen verändern können (Amazon RDS erzeugt eine dedizierte Standby-Replika pro primärer DB Instance). Die Standby-Replika kann auch nicht für das Akzeptieren von Datenbankleseaktivität konfiguriert werden. Weitere Informationen zu Multi-AZ-Konfigurationen.

F: Befindet sich meine Standby-Replika in derselben Region wie die primäre Replika?

Ja. Ihre Standby-Replika 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 mein Primärknoten derzeit befindet?

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

F: Nach einem Failover befindet sich meine primäre Replika 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-Architekturen 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 Sicherungen im Zusammenhang mit meiner Multi-AZ-Bereitstellung?

Die Interaktion mit automatisierten Sicherungen 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 Sicherungen und DB-Snapshots mithilfe des Standby-Replikats erstellt, um eine E/A-Unterbrechung in der Primär-Instanz zu vermeiden. Beachten Sie, dass es bei Single-AZ- oder Multi-AZ-Bereitstellungen im Verlauf von Sicherungen 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 Management Console oder über die CreateDBInstanceReadReplica-API erstellt werden. Nach Erstellung der Read Replica werden Aktualisierungen an der Quell-DB-Instance unter Verwendung der nativen, asynchronen Replikation einer Engine repliziert. Sie können mehrere Read Replicas für eine gegebene 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 Replizierung 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 gegebene 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 geplante 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 zur 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 RDS for MySQL: DB-Instances mit MySQL Version 5.5 oder neuer 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 werden nur für Amazon RDS Read Replicas unter MySQL 5.6 und höher unterstützt, jedoch nicht unter oder 5.5.

Amazon RDS for PostgreSQL: DB-Instances mit PostgreSQL Version 9.3.5 oder neuer 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: DB-Instances mit MariaDB Version 10.0 oder neuer 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.

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 Management Console 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 Replizierung. 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-Instanz angefertigt). Amazon RDS arbeitet derzeit auch an einer weiteren (in Kürze verfügbaren) Optimierung, mit der Sie mehrere Read Replicas innerhalb eines 30-minütigen Fensters erstellen können, wobei alle denselben Quell-Snapshot nutzen, um die E/A-Beeinträchtigung zu minimieren (die "Aufhol"-Replizierung für jede Read Replica beginnt dann nach der Erstellung).

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

Verbindungen mit einer Read Replica können wie mit einer Standard-DB-Instance über die DescribeDBInstance-API oder die AWS Management Console 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?

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?

Amazon RDS for MySQL, MariaDB und PostgreSQL unterstützt regionsübergreifende Read Replicas.

F: Unterstützen Amazon RDS Read Replicas 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.

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 Replizierung 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 Replizierung bei Multi-AZ-Bereitstellungen synchron, d. h., alle Datenbank-Schreibvorgänge erfolgen in der Primär- und der Standby-Instanz gleichzeitig. Damit sind Ihre aktuellsten Datenbank-Updates geschützt, da sie, falls ein Failover erforderlich wird, schon in der Standby-Instanz verfügbar sind. Darüber hinaus ist die Replizierung 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-Instanz, 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 Datensicherheit, während die zugeordnete Read Replica die Skalierbarkeit des Lesedatenverkehrs verbessert.

F: Kann ich die Read Replicas von Amazon RDS zu Multi-AZ machen?

Amazon RDS for MySQL, MariaDB und PostgreSQL unterstützen dies 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ären Replika).

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

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 für 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 korrespondierenden Quell-DB-Instance hinzugefügt wird.

Amazon RDS für 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 gegebene 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 für 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 User Guide.

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, das eine Read Replica hinter ihrer Quell-DB-Instance "hinterher hängt". Typische Gründe hierfür sind:

  • Das Schreiben von E/A-Volumen auf die Quell-DB-Instance überschreitet die Rate, bei 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 Replizierung 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 für Tipps zur Handhabung von Read Replicas, 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 Console auf die Registerkarte "DB-Instances" klicken.

Mit Amazon RDS können Sie sehen, wie weit eine Read Replica gegen 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 Management Console oder Amazon CloudWatch-APIs verfügbar ist. Bei Amazon RDS für MySQL ist die Quelle dieser Daten die gleiche wie durch den MySQL-Standardbefehl "Show Slave Status" für Read Replica angezeigt wird. Bei Amazon RDS für PostgreSQL können Sie die pg_stat_replication-Ansicht auf der Quell-DB-Instance benutzen, um die Replikationsmetriken anzuzeigen.

Amazon RDS überwacht den Replikationsstatus Ihrer Read Replicas und aktualisiert das Feld "Replication State" in der AWS Management Console mit der Meldung "Error", wenn die Replikation aus einem beliebigen Grund unterbrochen wird. (Beispielweise beim Versuch von DML-Anfragen auf Ihre 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-Datenbank-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" 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 denselben DB Instance Identifier und Quell-DB-Instance-Identifier 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 Auslastungsmuster 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 Ihrer Read Replica DB Instance 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 Datenverarbeitungs- und/oder Speicherkapazität meiner Quell-DB-Instance skaliert. Muss ich auch die Ressourcen für die dazugehörigen Read Replicas skalieren?

Für eine effektiv funktionierende Replizierung 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 Replizierung kommt oder dass ihre Read Replica nicht über genügend Speicherplatz zur Speicherung replizierter Updates verfügt.

F: Kann ich DB-Snapshots oder automatisierte Sicherungen 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-Instanz initiiert, um die Beeinträchtigung der Verfügbarkeit zu minimieren.

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

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

Eine Read Replica von Amazon RDS for MySQL oder MariaDB bleibt selbst dann aktiv und nimmt weiterhin Lesedatenverkehr entgegen, 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 DeleteDBInstance-API oder die AWS Management Console löschen.

Wenn Sie eine Amazon RDS für 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 DeleteDBInstance-API oder die AWS Management Console 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 für 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 durchzugehen. Wie bei einer standardmäßigen DB-Instance auch 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" gelistet 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 Datenbank-Instance für leseintensive Datenbank-Arbeitslasten hinaus. 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 den Support 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 zu einer eigenständigen 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
(Read Replicas von Read Replicas)
Zurzeit nicht unterstützt Unterstützt Unterstützt
Regionsübergreifende Read Replicas Unterstützt Unterstützt Unterstützt

Informationen zur Unterstützung von Replikationen mit der Amazon Aurora-Engine finden Sie in den Häufig gestellten Fragen zu Amazon RDS for Aurora.


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?

Erweiterte Überwachung 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 allgemeine Überwachung empfehlen wir, für mittlere oder größere Instances höhere Granularitäten zu verwenden. Bei nicht produktiven 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: Wie weit in der Vergangenheit kann ich auf der RDS-Konsole historische Metriken sehen?

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 geliefert. 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 RDS Console Dashboards verwenden?

Sie sollten CloudWatch verwenden, wenn Sie historische Daten anzeigen möchten, die im RDS Console Dashboard 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 der 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 der Form von JSON-Inhalten, die in Ihr CloudWatch Logs-Konto geliefert werden. Die JSON-Inhalte werden in der Granularität geliefert, 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 Dokumentation zu Amazon CloudWatch.

F: Wie kann ich historische Daten löschen?

Da Enhanced Monitoring JSON-Inhalte in ein Protokoll in Ihrem CloudWatch Logs-Konto liefert, 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 über das Einstellen des Aufbewahrungszeitraums finden Sie im Amazon CloudWatch Developer Guide.

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 Nutzungskontingent für CloudWatch Logs aufgebraucht haben. Preisinformationen finden Sie hier. Der Umfang der übertragenen Daten für eine RDS-Instance ist direkt proportional zu der definierten Granularität für Enhanced Monitoring. Administratoren können in ihren Konten unterschiedliche Granularitäten für unterschiedliche Instances einstellen.

Das ungefähre Volumen der durch Enhanced Monitoring für eine Instance in CloudWatch Logs übertragenen Daten ist 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