Häufig gestellte Fragen zu Amazon Aurora

Amazon Aurora ist ein moderner relationaler Datenbankservice, der Leistung und Hochverfügbarkeit in großem Umfang, vollständig quelloffene MySQL- und PostgreSQL-kompatible Versionen sowie eine Reihe von Entwickler-Tools für die Entwicklung von Serverless- und Machine Learning (ML)-gesteuerten Anwendungen bietet.

Aurora verfügt über ein verteiltes, fehlertolerantes und selbstheilendes Speichersystem, das von Datenverarbeitungsressourcen entkoppelt ist und automatisch auf bis zu 256 TiB pro Datenbank-Instance skaliert. Es bietet hohe Leistung und Verfügbarkeit mit bis zu 15 Lesereplikaten mit geringer Latenzzeit, zeitpunktbezogener Wiederherstellung, kontinuierlicher Sicherung in Amazon Simple Storage Service (Amazon S3) und Replikation über drei Availability Zones (AZs).

Aurora ist auch ein voll verwalteter Service, der zeitaufwendige Verwaltungsaufgaben wie die Hardwarebereitstellung, die Einrichtung von Datenbanken, das Patchen und Backups automatisiert. Zugleich werden Ihnen Sicherheit, Verfügbarkeit und Zuverlässigkeit Ihrer kommerziellen Datenbanken zu einem Zehntel der üblichen Kosten geboten.

Amazon Aurora ist sofort kompatibel mit vorhandenen Open-Source-Datenbanken von MySQL und fügt regelmäßig Support für neue Versionen hinzu. Dies bedeutet, dass Sie MySQL-Datenbanken einfach in Aurora importieren und aus Aurora exportieren können, indem Sie Standardtools zum Import/Export oder Snapshots verwenden. Auch die meisten der Codes, Anwendungen, Treiber und Werkzeuge, die Sie bereits heute mit Ihren MySQL-Datenbanken verwenden, können mit Aurora mit geringen oder keinen Änderungen verwendet werden. Somit ist es einfacher, Anwendungen zwischen den beiden Engines zu verschieben.

Informationen zur Kompatibilität der aktuellen Version von Amazon Aurora MySQL finden Sie in der Dokumentation.

Amazon unterstützt Aurora PostgreSQL und alle mit Aurora verfügbaren Erweiterungen vollständig. Wenn Sie Unterstützung für Aurora PostgreSQL benötigen, wenden Sie sich bitte an den AWS Support. Wenn Sie über ein aktives AWS-Premium-Support-Konto verfügen, können Sie sich bei Aurora-spezifischen Problemen an den AWS Premium Support wenden.

Amazon Aurora ist sofort kompatibel mit vorhandenen Open-Source-Datenbanken von PostgreSQL und fügt regelmäßig Support für neue Versionen hinzu. Dies bedeutet, dass Sie PostgreSQL-Datenbanken mithilfe von Standard-Import-/Export-Tools oder Snapshots problemlos zu und von Aurora migrieren können. Es bedeutet auch, dass die meisten Codes, Anwendungen, Treiber und Tools, die Sie bereits heute mit Ihren PostgreSQL-Datenbanken verwenden, mit Aurora mit geringen oder gar keinen Änderungen genutzt werden können.

Informationen zur Kompatibilität der aktuellen Version von Amazon Aurora PostgreSQL finden Sie in der Dokumentation.

Wenn Sie Aurora ausprobieren möchten, melden Sie sich bei der AWS-Managementkonsole an und wählen Sie in der Datenbank-Kategorie RDS und dann Amazon Aurora als Datenbank-Engine. Ausführliche Anleitungen und Ressourcen finden Sie auf unserer Seite Erste Schritte mit Aurora.

Die regionale Verfügbarkeit für Aurora können Sie hier anzeigen.

Wenn Sie von PostgreSQL nach Aurora und umgekehrt migrieren möchten, haben Sie mehrere Möglichkeiten:

• Sie können das Standard-pg_dump-Hilfsprogramm für den Export von Daten aus PostgreSQL verwenden, und das pg_restore-Hilfsprogramm für den Import von Daten in Aurora – und umgekehrt.
• Sie können auch das Migrations-Feature RDS-DB-Snapshot nutzen, um mit der AWS-Managementkonsole einen Snapshot von Amazon RDS für PostgreSQL DB zu Aurora zu migrieren.

Die Migration nach Aurora ist bei den meisten Kunden innerhalb einer Stunde abgeschlossen. Die Dauer hängt jedoch vom Format und der Größe des Datensatzes ab.

Um SQL-Server-Datenbanken zu Amazon Aurora-PostgreSQL-kompatible Edition zu migrieren, können Sie Babelfish für Aurora PostgreSQL verwenden. Ihre Anwendungen werden ohne Änderungen funktionieren. Weitere Informationen finden Sie in der Babelfish-Dokumentation.

Wenn Sie von MySQL zu Aurora und umgekehrt migrieren möchten, haben Sie mehrere Möglichkeiten:

• Sie können das Standard-mysqldump-Hilfsprogramm für den Export von Daten aus MySQL verwenden, und das mysqlimport-Hilfsprogramm für den Import von Daten in Amazon Aurora – und umgekehrt.
• Sie können auch das Migrations-Feature Amazon-RDS-DB-Snapshot verwenden, um einen Snapshot von Amazon RDS für MySQL DB über die AWS-Managementkonsole zu Aurora zu migrieren.

Die Migration nach Aurora ist bei den meisten Kunden innerhalb einer Stunde abgeschlossen. Die Dauer hängt jedoch vom Format und der Größe des Datensatzes ab. Weitere Informationen finden Sie unter Bewährte Methoden für die Migration von MySQL-Datenbanken in Amazon Aurora.

Nein, Aurora funktioniert mit Standard-PostgreSQL-Datenbanktreibern.

Amazon Aurora bietet erhebliche Leistungssteigerungen gegenüber MySQL durch die enge Integration der Datenbank-Engine mit einer SSD-basierten virtualisierten Speicherebene, die speziell für Datenbank-Workloads entwickelt wurde, wodurch Schreibvorgänge in das Speichersystem reduziert, Sperrkonflikte minimiert und durch Datenbankprozess-Threads verursachte Verzögerungen beseitigt werden.

Unsere Tests mit SysBench auf r3.8xlarge-Instances zeigen, dass Amazon Aurora über 500 000 SELECTs/Sek und 100 000 UPDATEs/Sek liefert, fünfmal mehr als MySQL, das denselben Benchmark auf derselben Hardware ausführt. Detaillierte Anweisungen zu diesem Benchmark und seiner Replikation, finden Sie im Leistungs-Benchmarking-Handbuch zur Amazon Aurora-MySQL-kompatiblen Edition.

Durch die völlige Integration der Datenbank-Engine in eine SSD-gestützte virtualisierte Speicherebene, die eigens für Datenbank-Workloads geschaffen wurde, erzielt Amazon Aurora eine signifikant höhere Leistung als PostgreSQL. Es reduziert Schreibvorgänge in das Speichersystem, minimiert Sperrkonflikte und eliminiert Verzögerungen aufgrund von Datenbankprozess-Threads.

Unsere Tests mit SysBench auf r4.16xlarge-Instances haben ergeben, dass Amazon Aurora mehr als dreimal so viele SELECTs/s und UPDATEs/s liefert wie PostgreSQL bei Verwendung desselben Benchmarks auf derselben Hardware. Detaillierte Anleitungen zu diesem Benchmark und seiner Replikation finden Sie im Leistungs-Benchmarking-Handbuch zur Amazon Aurora-PostgreSQL-kompatiblen Edition.

Amazon Aurora ist so konzipiert, dass es mit MySQL kompatibel ist. Daher können vorhandene MySQL-Anwendungen und -Tools ohne Änderung ausgeführt werden. Ein Bereich, in dem Amazon Aurora gegenüber MySQL deutlich bessere Leistung liefert, sind gleichzeitige Workloads. Zur Optimierung des Durchsatzes Ihres Workloads in Amazon Aurora empfehlen wir, Ihre Anwendungen so zu konstruieren, dass eine große Menge gleichzeitiger Abfragen und Transaktionen ausgeführt wird.

Amazon Aurora ist so konzipiert, dass es mit PostgreSQL kompatibel ist. Daher können vorhandene PostgreSQL-Anwendungen und -Tools ohne Änderung ausgeführt werden. Ein Bereich, in dem Amazon Aurora gegenüber PostgreSQL deutlich bessere Leistung liefert, sind gleichzeitige Verarbeitungslasten. Zur Optimierung des Durchsatzes Ihres Workloads in Amazon Aurora empfehlen wir, Ihre Anwendungen so zu konstruieren, dass eine große Menge gleichzeitiger Abfragen und Transaktionen ausgeführt wird.

Auf der Preisseite von Aurora finden Sie die aktuellen Preisinformationen.

Derzeit gibt es kein kostenloses AWS-Kontingent für Aurora. Aurora speichert Ihre Daten jedoch dauerhaft in drei Availability Zones in einer Region und berechnet nur eine Kopie der Daten. Backups von bis zu 100 % der Größe Ihres Datenbank-Clusters werden Ihnen nicht in Rechnung gestellt. Während des Backup-Aufbewahrungszeitraums, den Sie für Ihren Datenbank-Cluster konfiguriert haben, werden Ihnen auch keine Snapshots in Rechnung gestellt.

Ja, Sie können einen Database Savings Plan für Ihre Nutzung von Amazon Aurora erwerben und Ihre Kosten um bis zu 35 % reduzieren, wenn Sie sich zu einer gleichbleibenden Nutzung über einen Zeitraum von einem Jahr verpflichten. Weitere Informationen zur berechtigten Nutzung finden Sie auf der Preisseite der Database Savings Plans.

Nein. Die Aurora-Replikation ist im Paketpreis enthalten. Es wird auf Basis des Speichers verrechnet, den Ihre Datenbank in der Datenbankschicht nutzt, nicht auf Basis des in der virtualisierten Speicherebene von Aurora verbrauchten Speichers.

E/A-Vorgänge sind Ein- und Ausgabe-Operationen, die die Aurora-Datenbank-Engine in ihrer SSD-basierten virtualisierten Speicherschicht durchführt. Jeder Datenbank-Seiten-Lesevorgang zählt als ein E/A.
Die Aurora-Datenbank-Engine führt Lesevorgänge in der Speicherschicht aus, um Datenbankseiten abzurufen, die nicht im Speicher des Cache vorhanden sind:

• Wenn Ihr Abfrageverkehr vollständig aus dem Speicher oder dem Cache bedient werden kann, werden Ihnen keine Kosten für das Abrufen von Datenseiten aus dem Speicher berechnet.
• Wenn Ihr Abfrageverkehr nicht vollständig aus dem Speicher bedient werden kann, werden Ihnen Kosten für alle Datenseiten berechnet, die aus dem Speicher abgerufen werden müssen.
  Jede Datenbank in der Amazon-Aurora-MySQL-kompatiblen Edition ist 16 KB groß, jede Datenbank in der Aurora-PostgreSQL-kompatiblen Edition ist 8 KB groß.

Aurora ist so konzipiert, dass es unnötige E/A-Vorgänge eliminiert, so die Kosten senkt und sicherstellt, dass die Ressourcen für Lese-/Schreibvorgänge verfügbar sind. Schreib-E/As werden nur verbraucht, wenn Redo-Protokoll-Aufzeichnungen in Aurora-MySQL-kompatible Edition oder Write-Ahead-Protokoll-Aufzeichnungen in Aurora-PostgreSQL-kompatible Edition in der Speicherschicht persistiert werden, um Schreibvorgänge dauerhaft zu machen.

E/A-Schreibvorgänge werden in 4-KB-Einheiten gezählt. Eine Protokoll-Aufzeichnung mit 1,024 Bytes beispielsweise zählt als ein geschriebener E/A-Vorgang. Wenn die Protokoll-Aufzeichnung jedoch größer als 4 KB ist, ist mehr als ein Schreib-E/A-Vorgang erforderlich, um sie zu persistieren.

Gleichzeitige Schreibvorgänge, deren Transaktionsprotokoll weniger als 4 KB hat, können jedoch zur Optimierung der E/A-Nutzung durch die Aurora-Datenbank-Engine zusammengefasst werden. Im Gegensatz zu herkömmlichen Datenbank-Engines werden bei Aurora keine schmutzigen Datenseiten in den Speicher gespült.

Der Umfang der E/A-Anfragen, die Ihre Aurora-Instance nutzt, wird in der AWS-Managementkonsole angezeigt. Um Ihren E/A-Verbrauch zu ermitteln, gehen Sie in den Amazon-RDS-Bereich der Konsole, sehen Sie sich Ihre Liste der Instances an, wählen Sie Ihre Aurora-Instances aus und suchen Sie dann im Überwachungsbereich nach den Metriken „VolumeReadIOPs“ und „VolumeWriteIOPs“.

Weitere Informationen zu den Preisen für I/O-Vorgänge finden Sie auf der Seite mit den Aurora-Preisen. Wenn Sie Ihre Datenbank-Cluster für die Aurora-Standardkonfiguration konfigurieren, werden Ihnen Lese- und Schreib-E/A-Vorgänge in Rechnung gestellt. Wenn Sie Ihre Datenbank-Cluster für Amazon Aurora I/O-Optimized konfigurieren, fallen Ihnen keine Gebühren für Lese- und Schreibvorgänge an.

Aurora bietet Ihnen die Flexibilität, Ihre Datenbankausgaben zu optimieren, indem Sie je nach Ihren Anforderungen an Preisleistung und Preisvorhersehbarkeit zwischen zwei Konfigurationsoptionen wählen. Die beiden Konfigurationsoptionen sind Aurora Standard und Aurora I/O-Optimized. Keine der beiden Optionen erfordert E/A im Voraus oder Speicherbereitstellung, und beide können E/A-Vorgänge skalieren, um Ihre anspruchsvollsten Anwendungen zu unterstützen.

Aurora Standard ist eine Datenbank-Cluster-Konfiguration, die kostengünstige Preise für die überwiegende Mehrheit der Anwendungen mit geringer bis mäßiger E/A-Auslastung bietet. Mit Aurora Standard zahlen Sie für Datenbank-Instances, Speicher und Pay-per-Request-E/A.

Aurora I/O-Optimized ist eine Datenbank-Cluster-Konfiguration, die eine verbesserte Preisleistung für E/A-intensive Anwendungen wie Zahlungsverarbeitungssysteme, E-Commerce-Systeme und Finanzanwendungen bietet. Wenn Ihre E/A-Ausgaben 25 % Ihrer gesamten Aurora-Datenbankausgaben übersteigen, können Sie mit Aurora I/O-Optimized bis zu 40 % der Kosten für E/A-intensive Workloads sparen. Aurora I/O-Optimized bietet vorhersehbare Preise für alle Anwendungen, da keine Gebühren für Lese- und Schreib-E/A-Vorgänge anfallen. Somit ist diese Konfiguration ideal für Workloads mit hoher E/A-Variabilität.

Aurora I/O-Optimized ist die ideale Wahl, wenn Sie vorhersehbare Kosten für jede Anwendung benötigen. Es bietet eine verbesserte Preisleistung für E/A-intensive Anwendungen, die einen hohen Schreibdurchsatz erfordern oder analytische Abfragen zur Verarbeitung großer Datenmengen ausführen. Kunden, deren I/O-Ausgaben 25 % ihrer Aurora-Rechnung übersteigen, können mit Aurora I/O-Optimized bis zu 40 % der Kosten für I/O-intensive Workloads sparen.

Sie können die in der AWS-Managementkonsole verfügbare Ein-Klick-Funktion nutzen, um den Speichertyp Ihrer vorhandenen Datenbank-Cluster so zu ändern, dass er Aurora I/O-Optimized ist. Sie können auch die AWS-Befehlszeilenschnittstelle (AWS CLI) oder das AWS-SDK aufrufen, um diese Änderung vorzunehmen.

Sie können Ihre vorhandenen Datenbank-Cluster alle 30 Tage auf Aurora I/O-Optimized umstellen. Sie können jederzeit wieder zu Aurora Standard wechseln.

Ja, Aurora I/O-Optimized funktioniert mit vorhandenen Aurora Reserved Instances. Aurora berücksichtigt automatisch den Preisunterschied zwischen Aurora Standard und Aurora I/O-Optimized mit Reserved Instances. Mit den Rabatten für Reserved Instances mit Aurora I/O-Optimized können Sie noch mehr Einsparungen bei Ihren E/A-Ausgaben erzielen.

Der Preis für Backtrack, Snapshot, Export oder kontinuierlichen Backup ändert sich mit Aurora I/O-Optimized nicht.

Ja, die Gebühren für die E/A-Vorgänge, die für die regionsübergreifende Datenreplikation erforderlich sind, fallen weiterhin an. Aurora I/O-Optimized berechnet keine Gebühren für Lese- und Schreib-E/A-Vorgänge, was sich von der Datenreplikation unterscheidet.

Für die optimierten Lesevorgänge von Amazon Aurora für Aurora PostgreSQL fallen neben dem Preis für Intel-basierte R6id- und Graviton-basierte R6gd-Instances keine zusätzlichen Kosten an. Weitere Informationen finden Sie auf der Seite mit der Preisübersicht für Aurora.

Es gibt ein unteres Speicherplatzlimit von 10 GB. Basierend auf Ihrer Datenbanknutzung wächst Ihr Aurora-Speicher automatisch in 10-GB-Schritten auf bis zu 256 TiB. Die Datenbankleistung wird dadurch nicht beeinträchtigt. Es besteht keine Notwendigkeit, Speicher im Voraus bereitzustellen. Aurora bietet automatische horizontale Skalierung mit der unbegrenzte Datenbank von Amazon Aurora PostgreSQL, die den Speicher auf über 256 TiB skaliert. Weitere Informationen finden Sie unter Nutzung der unbegrenzten Datenbank von Aurora PostgreSQL.

Es gibt drei Möglichkeiten, die mit Ihrer Amazon Aurora-Datenbank verbundenen Datenverarbeitungsressourcen zu skalieren: mithilfe von Amazon Aurora Serverless, der unbegrenzten Datenbank von Aurora PostgreSQL oder manueller Skalierung. Egal für welche Option Sie sich entscheiden, Sie zahlen nur für das, was Sie nutzen.

Sie können Aurora Serverless, eine On-Demand-Konfiguration mit automatischer Skalierung für Aurora, verwenden, um Datenbank-Datenverarbeitungsressourcen basierend auf der Anwendungsnachfrage zu skalieren. Damit können Sie Ihre Datenbank in der Cloud ausführen, ohne sich Gedanken über die Verwaltung der Datenbankkapazität machen zu müssen. Sie können den gewünschten Kapazitätsbereich der Datenbank angeben und Ihre Datenbank wird basierend auf den Anforderungen Ihrer Anwendung skaliert. Lesen Sie mehr im Benutzerhandbuch zu Aurora Serverless.

Mit der unbegrenzten Datenbank von Aurora PostgreSQL können Sie Ihre Datenverarbeitungsressourcen basierend auf Ihren Workload-Anforderungen automatisch horizontal skalieren, um umfangreiche Anwendungen zu unterstützen. Es hilft Ihnen, Ihre Anwendungen über den Schreibdurchsatz und die Speichergrenzen einer einzelnen Datenbank-Instance hinaus zu skalieren und gleichzeitig die Einfachheit des Betriebs in einer einzigen Datenbank beizubehalten. 

Sie können Ihre mit Ihrer Datenbank verknüpften Datenverarbeitungsressourcen auch manuell skalieren, indem Sie den gewünschten DB-Instance-Typ in der AWS-Managementkonsole auswählen. Ihre angeforderte Änderung wird während Ihres angegebenen Wartungsfensters angewendet. Sie können auch das Flag „Sofort anwenden“ verwenden, um den DB-Instance-Typ sofort zu ändern.

Automatisierte fortlaufende Backups sind in Amazon-Aurora-DB-Instances immer aktiviert. Backups wirken sich nicht auf die Leistung der Datenbank aus.

Ja. Das Erstellen von Snapshots wirkt sich nicht auf die Leistung aus. Die Wiederherstellung von Daten aus DB-Snapshots erfordert die Erstellung einer neuen DB-Instance.

Amazon Aurora macht Ihre Daten automatisch über drei Availability Zones (AZs) in einer Region hinweg dauerhaft und versucht automatisch, Ihre Datenbank in einer fehlerfreien AZ ohne Datenverlust wiederherzustellen. Im unwahrscheinlichen Fall, dass Ihre Daten im Amazon-Aurora-Speicher nicht verfügbar sind, können Sie aus einem DB-Snapshot wiederherstellen oder eine zeitpunktbezogene Wiederherstellung auf eine neue Instance durchführen. Beachten Sie, dass der späteste wiederherstellbare Zeitpunkt bei einer zeitpunktbezogenen Wiederherstellung bis zu fünf Minuten zurückliegt.

Sie können vor dem Löschen Ihrer DB-Instance einen abschließenden 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 Aurora 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. Nach dem Löschen der DB-Instance werden nur DB-Snapshots beibehalten (d. h. automatisierte Backups für zeitpunktbezogene Wiederherstellung werden nicht beibehalten).

Ja. Aurora bietet Ihnen die Möglichkeit, Snapshots Ihrer Datenbanken zu erstellen, die Sie später zum Wiederherstellen einer Datenbank verwenden können. Sie können einen Snapshot für ein anderes AWS-Konto freigeben und der Besitzer des Empfängerkontos kann Ihren Snapshot verwenden, um eine Datenbank wiederherzustellen, die Ihre Daten enthält. Sie können Ihre Snapshots sogar öffentlich zugänglich machen, sodass jeder eine Datenbank mit Ihren (öffentlichen) Daten wiederherstellen kann.

Sie können dieses Feature nutzen, um Daten zwischen Ihren unterschiedlichen Umgebungen (Produktion, Entwicklung/Tests, Staging usw.) zu teilen, die unterschiedliche AWS-Konten nutzen, sowie Sicherungen all Ihrer Daten in einem getrennten Konto aufzubewahren, falls einmal in Ihr AWS-Konto eingebrochen werden sollte.

Die Freigabe von Snapshots für verschiedene Konten ist kostenlos. Möglicherweise werden Ihnen aber die Snapshots selbst sowie die Datenbanken, die Sie über freigegebene Snapshots wiederherstellen, in Rechnung gestellt. Weitere Informationen zu den Aurora-Preisen.

Die automatische Freigabe von DB-Snapshots wird nicht unterstützt. Um einen Snapshot freizugeben, müssen Sie manuell eine Kopie des Snapshots erstellen und diese Kopie dann freigeben.

Sie können manuelle Snapshots für bis zu 20 AWS-Konto-IDs freigeben. Wenn Sie den Snapshot für mehr als 20 Konten freigeben möchten, können Sie den Snapshot entweder öffentlich freigeben oder sich an den Support wenden, damit Ihr Kontingent erhöht wird.

Sie können Ihre Aurora-Snapshots für jede AWS-Region freigeben, in der Aurora verfügbar ist.

Nein. Auf Ihre freigegebenen Aurora-Snapshots kann nur von Konten in derselben Region wie das freigebende Konto zugegriffen werden.

Ja, Sie können verschlüsselte Aurora-Snapshots freigeben.

Amazon Aurora trennt automatisch Ihr Datenbank-Volume in 10 GB-Segmente, die auf vielen unterschiedlichen Datenträgern untergebracht sind. Jeder 10 GB-Block Ihrer Datenbank wird sechsfach und in drei AZs repliziert. Amazon Aurora ist so konzipiert, dass es transparent den Verlust von bis zu zwei Kopien der Daten ohne Beeinträchtigung der Schreibverfügbarkeit, und bis zu drei Kopien ohne Beeinträchtigung der Verfügbarkeit von Leseleistung verarbeiten kann.

Außerdem behebt der Speicher von Amazon Aurora Probleme automatisch. Datenblocks und Datenträger werden laufend auf Fehler untersucht und automatisch repariert.

Anders als andere Datenbanken muss Amazon Aurora nach einem Datenbankabsturz und bevor es die Datenbank für Operationen zur Verfügung stellt, nicht das Redo Protokoll aus dem letzten Datenbank-Prüfpunkt wiedergeben (was normalerweise 5 Minuten dauert) und rückmelden, dass alle Änderungen angewendet wurden. Das reduziert in den meisten Fällen die Dauer des Neustarts auf weniger als 60 Sekunden.

Amazon Aurora löst den Puffercache der Datenbank vom Datenbankprozess und macht diesen sofort zum Zeitpunkt des Neustarts verfügbar. Das verhindert eine Drosselung des Zugriffs bis zur Neuauffüllung des Caches zur Vermeidung von Brownouts.

Die Amazon-Aurora-MySQL-kompatible Edition und Amazon-Aurora-PostgreSQL-kompatible Edition unterstützen Amazon-Aurora-Replikate, die dasselbe zugrunde liegende Volume wie die primäre Instance in derselben AWS-Region verwenden. Durch die primäre Instance ausgeführte Updates sind in allen Amazon-Aurora-Replikaten sichtbar.

Mit Amazon-Aurora-MySQL-kompatible Edition können Sie auch unter Anwendung der Binlog-basierten MySQL-Replizierungs-Engine regionsübergreifende MySQL-Lesereplikate erstellen. Bei MySQL-Lesereplikaten werden Daten aus Ihrer primären Instance auf Ihrem Replikat als Transaktionen wiedergegeben. Für die meisten Anwendungsfälle, auch die Skalierung der Lesevorgänge und hohe Verfügbarkeit, empfehlen wir die Nutzung von Amazon-Aurora-Replikaten.

Sie können diese beiden Replikattypen je nach Anwendungsbedarf flexibel miteinander kombinieren:

Sie haben zwei weitere Replikationsoptionen, zusätzlich zu den oben aufgeführten. Sie können Aurora Global Database für eine schnellere physische Replikation zwischen Aurora-Clustern in verschiedenen Regionen verwenden. Und für Replikation zwischen Aurora und Datenbanken, die nicht auf Aurora-MySQL-kompatible Edition basieren (sogar außerhalb von AWS), können Sie Ihre eigene, selbstverwaltete Binlog-Replikation aufsetzen.

Ja, Sie können regionsübergreifende Aurora-Replikate entweder mit logischer oder physischer Replikation einrichten. Die physische Replikation, Amazon Aurora Global Database genannt, verwendet eine dedizierte Infrastruktur, die Ihre Datenbanken vollständig für Ihre Anwendung verfügbar macht. Sie kann bis zu fünf sekundäre Regionen mit einer typischen Latenzzeit von unter einer Sekunde replizieren. Sie steht sowohl für Aurora-MySQL-kompatible Edition als auch für Aurora-PostgreSQL-kompatible Edition zur Verfügung.

Für globale Lesezugriffe mit niedriger Latenz und Disaster Recovery empfehlen wir die Verwendung von Amazon Aurora Global Database.
Aurora unterstützt die native logische Replikation in jeder Datenbank-Engine (Binlog für MySQL- und PostgreSQL-Replikationsslots für PostgreSQL), so dass Sie auf Aurora- und Nicht-Aurora-Datenbanken replizieren können, sogar über Regionen hinweg.

Aurora-MySQL-kompatible Edition bietet auch ein einfach zu benutzendes logisches, regionenübergreifendes Reproduktionsfeature, das bis zu fünf sekundäre AWS-Regionen unterstützt. Sie basiert auf einer Einzel-Thread-MySQL-binlog-Replizierung; die Verzögerung bei der Replizierung wird durch die Änderungs-/Anwendungsrate und Verzögerungen bei der Netzwerkkommunikation zwischen den spezifischen ausgewählten Regionen beeinflusst.

Ja, Sie können bis zu 15 Aurora-Replikate zu jedem regionsübergreifenden Cluster hinzufügen, und sie teilen sich den gleichen zugrundeliegenden Speicherplatz wie das regionsübergreifende Replikat. Das regionsübergreifende Replikat fungiert als primäres Replikat im Cluster; die Aurora-Replikate im Cluster liegen normalerweise mit einer Verzögerung im Zehntel-Millisekundenbereich hinter dem primären Replikat.

Ja, Sie können Ihr regionsübergreifendes Replikat über die Amazon-RDS-Konsole zum neuen primären machen. Für die logische (Binlog-)Replikation dauert der Promotion-Prozess in der Regel einige Minuten, abhängig von Ihrem Arbeitsaufkommen. Die regionsübergreifende Replizierung wird beendet, sobald Sie diesen Prozess starten.

Mit Amazon Aurora Global Database können Sie eine sekundäre Region hochstufen, um vollständige Lese-/Schreib-Workloads in weniger als einer Minute aufzunehmen.

Ja. Sie können jeder Instance auf dem Cluster ein Beförderungs-Prioritätskontingent zuweisen. Sollte die primäre Instance ausfallen, befördert Amazon RDS das Replikat mit der höchsten Priorität zur neuen primären Instance. Wenn zwei oder mehr Aurora-Replikate die gleiche Priorität aufweisen, befördert Amazon RDS das größte Replikat. Weisen zwei oder mehr Aurora-Replikate die gleiche Priorität und Größe auf, befördert Amazon RDS ein beliebiges Replikat in der gleichen Beförderungsstufe.

Weitere Informationen zur Failover-Logik finden Sie im Amazon-Aurora-Benutzerhandbuch.

Ja, Sie können das Prioritätskontingent für eine Instance jederzeit bearbeiten. Das Bearbeiten eines Prioritätskontingent löst keinen Failover aus.

Sie können den Replikaten, die Sie nicht zur primären Instance hochstufen möchten, niedrigere Prioritätskontingente zuweisen. Wenn jedoch die Replikate auf dem Cluster mit höherer Priorität beschädigt oder aus irgendeinem Grund nicht verfügbar sind, stuft Amazon RDS das Replikat mit der niedrigeren Priorität hoch.

Sie können Amazon-Aurora-Replikate hinzufügen. Aurora-Replikate in der gleichen AWS-Region teilen sich den gleichen zugrunde liegenden Speicherplatz wie die primäre Instance. Jedes Aurora-Replikat kann ohne Datenverlust als primär hochgestuft werden. Damit kann man sie bei einem Ausfall der primären DB-Instance zur Verbesserung der Fehlertoleranz verwendet werden.

Zur Verbesserung der Datenbankverfügbarkeit können Sie einfach 1 bis 15 Replikate in einer der 3 AZs erstellen. Amazon RDS fügt diese automatisch zur Auswahl für einen Failover der primären Instance bei einem Datenbankausfall hinzu. Sie können die Amazon Aurora Global Database verwenden, wenn Sie möchten, dass Ihre Datenbank mehrere AWS-Regionen umfasst. Dadurch werden Ihre Daten repliziert, ohne die Datenbankleistung zu beeinträchtigen, und die Notfallwiederherstellung nach regionalen Ausfällen wird ermöglicht.

Der Failover wird von Amazon Aurora automatisch durchgeführt, sodass Ihre Anwendungen den Datenbankbetrieb schnellstmöglich und ohne Verwaltungsaufwand wieder aufnehmen können.

• Wenn Sie ein Aurora-Replikat in derselben oder einer anderen AZ haben, wechselt Amazon Aurora den anerkannten Canonical Name Record (CNAME) für Ihre DB-Instance, sodass auf das fehlerfreie Replikat verwiesen wird, das zur neuen primären Instance hochgestuft wird. Das gesamte Failover ist in der Regel innerhalb von 30 Sekunden abgeschlossen. Für eine verbesserte Ausfallsicherheit und schnellere Failovers sollten Sie die Verwendung von Amazon-RDS-Proxy in Betracht ziehen, das automatisch eine Verbindung mit der Failover-DB-Instance herstellt und dabei die Anwendungsverbindungen aufrechterhält. Proxy macht Failover für Ihre Anwendungen transparent und reduziert die Failover-Zeiten um bis zu 66 % 
• Aurora Serverless v2 funktioniert wie bereitgestellt für den Failover und sonstige hochverfügbare Features. Weitere Informationen finden Sie unter Aurora Serverless v2 und hohe Verfügbarkeit.
  
• Verfügen Sie über keine Aurora-Replikate (d. h. über eine einzelne Instance), versucht Aurora Serverless zuerst, eine DB-Instance in der Availability Zone der ursprünglichen Instance zu erstellen. Dieser Austausch der ursprünglichen Instance wird nach bestem Bemühen durchgeführt, ist aber nicht immer erfolgreich, z. B. wenn ein Problem vorliegt, das sich allgemein auf die Availability Zone auswirkt.

Bei Verbindungsunterbrechung muss Ihre Anwendung versuchen, die Verbindung zur Datenbank wiederherzustellen. Notfallwiederherstellung über Regionen hinweg ist ein manueller Prozess, bei dem Sie eine sekundäre Region fördern, um Workloads zum Lesen/Schreiben aufzunehmen.

Amazon Aurora erkennt automatisch, dass ein Problem mit Ihrer primären Instance vorliegt, und löst ein Failover aus. Wenn Sie den Cluster-Endpunkt verwenden, werden Ihre Lese-/Schreibverbindungen automatisch an ein Amazon-Aurora-Replikat weitergeleitet, das zur primären Instance hochgestuft wird.

Außerdem wird der Lesedatenverkehr Ihrer Amazon-Aurora-Replikate kurz unterbrochen. Wenn Sie den Cluster-Leser-Endpunkt verwenden, um Ihren Lesedatenverkehr an das Aurora-Replikat zu leiten, werden die schreibgeschützten Verbindungen an das neu hochgestufte Aurora-Replikat weitergeleitet, bis der alte Primärknoten wieder als Replikat hergestellt wurde.

Ja, Sie können binlog-Replikation zwischen einer Aurora-MySQL-kompatible Version-Instance und einer externen MySQL-Datenbank aufsetzen. Die andere Datenbank kann auf Amazon RDS, als selbst-verwaltete Datenbank auf AWS oder komplett außerhalb von AWS ausgeführt werden.

Wenn Sie Aurora-MySQL-kompatible Edition 5.7 verwenden, sollten Sie erwägen, eine GTID-basierte binlog-Replikation aufzusetzen. Dadurch erhalten Sie vollständige Einheitlichkeit, sodass Ihre Replikation keine Transaktionen verpasst oder Konflikte erstellen lässt, selbst nach einem Failover oder Ausfallzeit.

Da Amazon-Aurora-Replikate dasselbe Daten-Volume verwenden wie die primäre Instance in derselben AWS-Region, gibt es praktisch keine Verzögerung bei der Replizierung. Wir beobachten normalerweise Verzögerungen im Zehntel-Millisekundenbereich.

Bei der regionsübergreifenden Replikation kann die Binlog-basierte logische Replikationsverzögerung basierend auf der Änderungs-/Anwendungsrate sowie Verzögerungen bei der Netzwerkkommunikation unbegrenzt anwachsen. Unter normalen Umständen liegt die Verzögerung bei der Replizierung üblicherweise jedoch unter einer Minute. Regionsübergreifende Replikate, die physische Replikation der Amazon Aurora Global Database verwenden, haben eine typische Verzögerung von weniger als einer Sekunde.

Amazon Aurora Global Database ist ein Feature, das es einer einzelnen Amazon-Aurora-Datenbank ermöglicht, mehrere AWS-Regionen abzudecken. Es repliziert Ihre Daten ohne Auswirkungen auf die Datenbankleistung, ermöglicht schnelle lokale Lesezugriffe in jeder Region mit einer typischen Latenzzeit von weniger als einer Sekunde und bietet Notfallwiederherstellung nach regionalem Ausfall. Im unwahrscheinlichen Fall einer regionalen Verschlechterung oder eines Ausfalls kann eine sekundäre Region in weniger als einer Minute in die volle Lese-/Schreibfähigkeit versetzt werden. Dieses Feature steht sowohl für Aurora-MySQL-kompatible Edition als auch für Aurora-PostgreSQL-kompatible Edition zur Verfügung.

Sie können eine Aurora Global Database mit nur wenigen Klicks in der Amazon-RDS-Managementkonsole erstellen. Alternativ können Sie auch das AWS Software Development Kit (SDK) oder das AWS Command-Line Interface (CLI) nutzen. Sie können eine gemischte Konfiguration von bereitgestellten oder Serverless Instance Class-Typen zwischen Ihrer primären und sekundären Region verwenden. Sie können Ihre primäre Region auch als Aurora E/A-optimierte Clusterkonfiguration und Ihre sekundären Regionen als Aurora Standard oder umgekehrt konfigurieren. Weitere Informationen finden Sie unter Erstellen einer Amazon Aurora Global Database.

Sie können bis zu fünf sekundäre Regionen für eine Amazon Aurora Global Database erstellen.

Ja. Wenn Ihr Ziel die Analyse der Datenbankaktivität ist, sollten Sie stattdessen Aurora Advanced Auditing, allgemeine Protokolle und langsame Abfrageprotokolle verwenden, um die Leistung Ihrer Datenbank nicht zu beeinträchtigen.

Nein. Wenn Ihre primäre Region nicht mehr verfügbar ist, können Sie den verwalteten regionsübergreifenden Aurora Global Database Failover-Vorgang verwenden, um eine sekundäre Region so heraufzustufen, dass sie die volle Lese- und Schreibfunktion übernimmt. Sie können auch den Aurora Global Database Writer-Endpunkt verwenden, um zu vermeiden, dass Sie Änderungen am Anwendungscode vornehmen müssen, um eine Verbindung mit der neu heraufgestuften Region herzustellen. Weitere Informationen finden Sie unter Verbindung mit einer Amazon Aurora Global Database.

Ja. Alle Amazon-Aurora-DB-Instances müssen in einer VPC erstellt werden. Mit Amazon VPC können Sie eine virtuelle Netzwerkarchitektur definieren, die weitgehend einem herkömmlichen Netzwerk entspricht, wie Sie es in Ihrem Rechenzentrum betreiben. Dadurch haben Sie die uneingeschränkte Kontrolle über den Zugriff auf Ihre Amazon-Aurora-Datenbanken.

Ja. Amazon Aurora verwendet SSL (AES-256), um die Verbindung zwischen der Datenbank-Instance und der Anwendung abzusichern. Amazon Aurora ermöglicht die Verschlüsselung Ihrer Datenbanken mit Schlüsseln, die Sie mit dem AWS Key Management Service (AWS KMS) verwalten.

Bei einer mit Amazon Aurora ausgeführten Datenbank-Instance werden ruhende Daten sowie die automatischen Backups, Snapshots und Replikate desselben Clusters auf dem zugrunde liegenden Speicher verschlüsselt. Die Ver- und Entschlüsselung erfolgt problemlos. Weitere Informationen zur Verwendung von AWS KMS mit Amazon Aurora finden Sie im Amazon-RDS-Benutzerhandbuch.

Derzeit wird die Verschlüsselung einer bestehenden unverschlüsselten Aurora-Instance nicht unterstützt. Zum Verwenden der Amazon Aurora-Verschlüsselung für eine bestehende unverschlüsselte Datenbank müssen Sie eine neue DB-Instance mit aktivierter Verschlüsselung erstellen und Ihre Daten in diese Instance migrieren.

Der Zugriff auf Amazon-Aurora-Datenbanken muss über den Datenbank-Anschluss erfolgen, der bei der Erstellung der Datenbank eingegeben wurde. Dies sorgt für eine zusätzliche Sicherheitsebene für Ihre Daten. Schritt-für-Schritt-Anweisungen zur Verbindung mit Ihrer Amazon-Aurora-Datenbank finden Sie im Handbuch zur Konnektivität von Amazon Aurora.

Ja, die MySQL- und PostgreSQL-kompatiblen Editionen von Aurora sind HIPAA-komform. Sie können sie nutzen, um HIPAA-konforme Anwendungen zu erstellen und gesundheitsbezogene Informationen zu speichern, einschließlich geschützter Gesundheitsinformationen (PHI) im Rahmen eines mit AWS abgeschlossenen Business Associate Addendum (BAA). Wenn Sie bereits eine BAA mit AWS abgeschlossen haben, sind keine weiteren Maßnahmen erforderlich, um diese Services für das/die von Ihrer BAA abgedeckte(n) Konto/Konten zu nutzen. Weitere Informationen über die Verwendung von AWS zur Erstellung konformer Anwendungen finden Sie unter Anbieter im Gesundheitswesen.

Eine aktuelle CVE-Liste finden Sie in den Sicherheitsaktualisierungen für Amazon Aurora.

Aurora ist mit Amazon GuardDuty integriert, um Sie bei der Erkennung potenzieller Bedrohungen für in Aurora-Datenbanken gespeicherte Daten zu unterstützen. GuardDuty RDS Protection profiliert und überwacht Anmeldeaktivitäten für bestehende und neue Datenbanken in Ihrem Konto und nutzt maßgeschneiderte ML-Modelle, um verdächtige Logins zu Aurora-Datenbanken genau erkennen zu können. Weitere Informationen finden Sie unter Überwachung von Bedrohungen mit GuardDuty-RDS-Schutz und dem Benutzerhandbuch zum GuardDuty-RDS-Schutz.

Bei Amazon Aurora Serverless handelt es sich um eine On-Demand-Konfiguration mit automatischer Skalierung für Amazon Aurora. Mit Aurora Serverless können Sie Ihre Datenbank in der Cloud ausführen, ohne die Datenbankkapazität verwalten zu müssen. Die manuelle Verwaltung der Datenbankkapazität kann zeitaufwändig sein und zu einer ineffizienten Nutzung der Datenbankressourcen führen. Mit Aurora Serverless können Sie eine Datenbank erstellen, den gewünschten Kapazitätsbereich der Datenbank angeben und Ihre Anwendungen verbinden. Aurora passt die Kapazität innerhalb des von Ihnen angegebenen Bereichs automatisch an die Anforderungen Ihrer Anwendung an.

Die Abrechnung erfolgt pro Sekunde verbrauchter Datenbankkapazität bei aktiver Datenbank. Erhalten Sie weitere Informationen über Aurora Serverless und beginnen Sie mit wenigen Klicks in der Amazon-RDS-Managementkonsole.

Informationen zur Kompatibilität mit Aurora Serverless v2 finden Sie hier.

Ja, Sie können einen Snapshot eines bestehenden bereitgestellten Aurora-Clusters auf einem Aurora-Serverless-DB-Cluster wiederherstellen (und umgekehrt).

Sie können auf einen Aurora-Serverless-DB-Cluster mithilfe einer Client-Anwendung zugreifen, die in der gleichen VPC ausgeführt wird. Sie können einer Aurora Serverless DB keine öffentliche IP-Adresse zuweisen.

Obwohl sich Aurora Serverless automatisch auf Basis des aktiven Datenbank-Workloads skaliert, erfolgt die Kapazitätsskalierung in einigen Fällen möglicherweise nicht schnell genug, um auf plötzliche Workload-Veränderungen wie eine große Anzahl neuer Transaktionen zu reagieren. In diesen Fällen können Sie die Kapazität explizit in der AWS-Managementkonsole, der AWS CLI oder der Amazon RDS API auf einen bestimmten Wert festlegen.

Sobald ein Skalierungsvorgang eingeleitet wird, versucht Aurora Serverless, einen Skalierungspunkt zu finden, d. h. einen Zeitpunkt, an dem die Datenbank die Skalierung sicher abschließen kann. Aurora Serverless findet möglicherweise keinen Skalierungspunkt, wenn über längere Zeit Abfragen oder Transaktionen laufen oder vorübergehende Tabellen oder Tabellen den Vorgang unterbinden.

Ja, Sie können mit der Verwendung von Aurora Serverless v2 starten, um die Datenbank-Rechenkapazität in Ihrem vorhandenen Aurora-DB-Cluster zu verwalten. Ein Cluster, der sowohl bereitgestellte Instances als auch Aurora Serverless v2 enthält, wird als Cluster mit gemischter Konfiguration bezeichnet. Sie können eine beliebige Kombination aus bereitgestellten Instances und Aurora Serverless v2 in Ihrem Cluster haben.

Um Aurora Serverless v2 zu testen, fügen Sie Ihrem Aurora-DB-Cluster einen Reader hinzu und wählen Serverless v2 als Instance-Typ aus. Sobald der Reader erstellt und verfügbar ist, können Sie ihn für Workloads mit Lesezugriff verwenden. Sobald Sie bestätigt haben, dass der Reader wie erwartet funktioniert, können Sie ein Failover initiieren, um mit der Verwendung von Aurora Serverless v2 sowohl für Lese- als auch für Schreibvorgänge zu starten. Diese Option bietet eine minimale Ausfallzeit, um mit Aurora Serverless v2 zu starten.

Aurora Serverless v2 unterstützt alle Features von bereitgestelltem Aurora, einschließlich Lesereplikat, Multi-AZ-Konfiguration, Aurora Global Database, RDS-Proxy und Performance Insights.

Bei Aurora Serverless wird die Datenbankkapazität in Aurora Capacity Units (ACUs) gemessen. Sie zahlen eine Pauschale pro Sekunde der ACU-Nutzung. Die Datenverarbeitungskosten für die Ausführung Ihrer Workloads auf Aurora Serverless hängen von der ausgewählten Datenbank-Cluster-Konfiguration ab: Aurora Standard oder Aurora I/O-Optimized. Besuchen Sie die Preisseite von Aurora für Informationen zu Preisen und regionaler Verfügbarkeit.

Die unbegrenzte Datenbank von Aurora PostgreSQL bietet automatische horizontale Skalierung zur Verarbeitung von Millionen von Schreibtransaktionen pro Sekunde und verwaltet Petabytes an Daten, während gleichzeitig die einfache Bedienung innerhalb einer einzigen Datenbank erhalten bleibt. Sie können sich auf die Entwicklung umfangreicher Anwendungen konzentrieren, ohne komplexe Lösungen für die Skalierung Ihrer Daten auf mehrere Datenbank-Instances erstellen und warten zu müssen, um Ihre Workloads zu unterstützen. Die unbegrenzte Datenbank von Aurora PostgreSQL skaliert je nach Workload Ihrer Anwendung und Sie zahlen nur für das, was Ihre Anwendung verbraucht. Weitere Informationen finden Sie in der Anleitung zur Nutzung der unbegrenzten Datenbank von Aurora PostgreSQL.

Sie sollten die unbegrenzte Datenbank von Aurora PostgreSQL für Anwendungen verwenden, die horizontal skaliert werden müssen und mehr Schreibdurchsatz oder Datenspeicherkapazität benötigen, als eine einzelne Aurora-Datenbank-Instance unterstützt. Beispielsweise kann eine Buchhaltungsanwendung von einem Benutzer horizontal partitioniert werden, da die Buchhaltungsdaten der einzelnen Benutzer unabhängig von den anderen sind. Die unbegrenzte Datenbank von Aurora PostgreSQL wird automatisch skaliert, um Ihre größten und am schnellsten wachsenden Anwendungen zu unterstützen. 

Es gibt zwei bestehende Features für die Skalierung: Auto Scaling von Amazon Aurora mit Aurora-Replikate und Aurora Serverless v2.

Mit Aurora-Replikate können Sie die Lesekapazität Ihres Aurora-Clusters über die Grenzen hinaus erhöhen, die eine einzelne Datenbank-Instance bieten kann. Anwendungen, die ihren Lese- und Schreib-Workload trennen können, können von bis zu 15 Lesereplikate profitieren, um insgesamt einen höheren Lesedurchsatz zu erzielen. Für Aurora-Replikate muss die Anwendung ihre Daten nicht horizontal aufteilen. Alle Daten sind in jedem Replikat verfügbar. Aurora-Replikate erhöhen weder die Speicherkapazität eines Aurora-Clusters noch den Schreibdurchsatz.

Aurora Serverless v2 ist eine On-Demand-Konfiguration mit vertikaler Skalierung für Aurora, die eine automatische Skalierung der Datenbank-Datenverarbeitungsleistung und des Speichers basierend auf den Anwendungsanforderungen innerhalb der Kapazitätsbeschränkungen einer einzelnen Datenverarbeitungs-Instance ermöglicht. Aurora Serverless v2 wird sowohl für Schreib- als auch für Lese-Instances unterstützt. Es erhöht jedoch nicht die Speicherkapazität eines Aurora-Clusters. Wenn Ihre Anwendung für horizontale Skalierung konzipiert ist, können Sie mit der unbegrenzten Datenbank von Aurora PostgreSQL den Schreibdurchsatz und die Speicherkapazität Ihrer Datenbank über die Grenzen einer einzelnen Aurora-Writer-Instance hinaus skalieren

Die unbegrenzte Datenbank von Aurora PostgreSQL teilt Daten mithilfe von kundenspezifischen Werten in einer Tabellenspalte – auch Shard-Schlüssel genannt – auf mehrere Datenbank-Instances auf. Beispielsweise kann eine Tabelle, in der Benutzerinformationen gespeichert sind, mithilfe der Benutzer-ID-Spalte als Shard-Schlüssel aufgeteilt werden. Unter der Motorhaube ist die unbegrenzte Datenbank von Aurora PostgreSQL eine verteilte Bereitstellung von Serverless-Knoten. Knoten sind entweder Router oder Shards. Router verwalten die verteilte Natur der Datenbank. Jeder Shard speichert eine Teilmenge Ihrer Daten, wodurch eine parallele Verarbeitung ermöglicht wird, um einen hohen Schreibdurchsatz zu erzielen.

Wenn die Datenverarbeitungs- oder Speicheranforderungen steigen, skaliert Aurora zunächst automatisch jede Instance und den zugehörigen Speicher hoch und skaliert dann auf, um die Datenbank-Workload für verschiedene Shard-Schlüsselwerte zu bedienen. Zu jedem Zeitpunkt gehört ein Shard-Schlüsselwert einer einzelnen Serverless-Instance und wird von dieser bereitgestellt. Wenn Anwendungen eine Verbindung zur unbegrenzten Datenbank von Aurora PostgreSQL herstellen und eine Anfrage stellen, wird die Anfrage zuerst analysiert. Dann wird es entweder an die Datenverarbeitungs-Instance gesendet, der der in der Anfrage angegebene Shard-Schlüsselwert gehört, oder es wird eine Abfrage über mehrere Instances hinweg orchestriert.

Mehrere Datenverarbeitungs-Instances, die jeweils unterschiedliche Shard-Schlüsselwerte bereitstellen, können gleichzeitig Anwendungsanforderungen für dieselbe unbegrenzte Datenbank von Aurora PostgreSQL bearbeiten. Die unbegrenzte Datenbank von Aurora PostgreSQL bietet dieselbe Transaktionssemantik wie Aurora-PostgreSQL-Systeme mit nur einem Schreiber, wodurch die Verwaltung verschiedener Transaktions-Domains in Ihrer Anwendung entfällt.

Die unbegrenzte Datenbank von Aurora PostgreSQL unterstützt drei Arten von Tabellen, die Ihre Daten enthalten: Sharded-, Referenz- und Standardtabellen.

Sharded-Tabellen: Diese Tabellen sind auf mehrere Shards verteilt. Die Daten werden auf der Grundlage der Werte der angegebenen Spalten in der Tabelle, den so genannten Shard-Schlüsseln, auf die Shards aufgeteilt. Sie sind nützlich für die Skalierung der größten und I/O-intensivsten Tabellen in Ihrer Anwendung.

Referenztabellen: Diese Tabellen kopieren die Daten auf jedem Shard vollständig, sodass Join-Abfragen schneller ausgeführt werden können, da unnötige Datenverschiebungen vermieden werden. Sie werden häufig für selten geänderte Referenzdaten wie Produktkataloge und Postleitzahlen verwendet.

Standardtabellen: Diese Tabellen sind wie normale Aurora-PostgreSQL-Tabellen. Standardtabellen werden alle zusammen auf einem einzigen Shard platziert, sodass Join-Abfragen schneller ausgeführt werden können, da unnötige Datenverschiebungen vermieden werden. Sie können Sharded- und Referenztabellen aus Standardtabellen erstellen.

Weitere Informationen zu Überlegungen zur PostgreSQL-Kompatibilität finden Sie unter Anforderungen und Überlegungen zur unbegrenzten Datenbank von Aurora PostgreSQL.

Die ersten Schritte mit der unbegrenzten Datenbank von Aurora PostgreSQL finden in der Amazon-RDS-Konsole oder mit Amazon APIs statt, um einen neuen Aurora-PostgreSQL-Cluster mit der unterstützten Engine-Version zu erstellen. Weitere Informationen zu den ersten Schritten finden Sie im Benutzerhandbuch zur unbegrenzten Datenbank von Aurora PostgreSQL.

Ihre Anwendung stellt auf dieselbe Weise eine Verbindung zur unbegrenzten Datenbank von Aurora PostgreSQL her, wie sie eine Verbindung zu einem standardmäßigen Aurora-PostgreSQL-Cluster herstellen würde. Sie stellen einfach eine Verbindung zum Cluster-Endpunkt her. Weitere Informationen finden Sie unter Nutzung der unbegrenzten Datenbank von Aurora PostgreSQL.

Ja, möglicherweise müssen Sie Ihr Datenbankschema anpassen, um die unbegrenzte Datenbank von Aurora PostgreSQL verwenden zu können. Alle geteilten Tabellen müssen den Shard-Schlüssel enthalten, sodass diese Daten möglicherweise wieder aufgefüllt werden müssen. Beispielsweise kann eine Buchhaltungsanwendung ihre Daten anhand der Benutzer-ID-Spalte nach Benutzern aufteilen, da jeder Benutzer unabhängig von den anderen ist. Während die Benutzertabelle selbst dies natürlich enthält
Spalte, andere Tabellen möglicherweise nicht, z. B. eine Tabelle, die die Einzelposten von Rechnungen enthält. Da diese Tabellen auch nach Benutzern aufgeteilt werden müssen, um die Tabellen für eine optimale Abfrageleistung zusammenzustellen, muss die Benutzer-ID-Spalte zur Tabelle hinzugefügt werden.

Es gibt keine Benennungsbeschränkungen für die Spalte, die zum Teilen der Daten verwendet wird, aber die Spaltendefinition muss übereinstimmen. Sie müssen den Shard-Schlüssel zu Anwendungsabfragen hinzufügen und möglicherweise müssen Sie auch Ihre Abfragen und Transaktionen anpassen, um eine optimale Leistung zu erzielen. Zum Beispiel wäre das Suchen einer Rechnung mit der Rechnungs-ID langsam, wenn die Tabelle nur nach Benutzer-ID aufgeteilt ist, da die Abfrage auf allen Datenbank-Instances ausgeführt werden müsste. Wenn die Abfrage jedoch auch die Benutzer-ID angibt, wird die Abfrage an die einzelne Datenbank-Instance weitergeleitet, die alle Bestellungen für diese Benutzer-ID enthält, wodurch die Latenz der Abfrage reduziert wird.

Ja. Sie können eine Hochverfügbarkeitsoption wählen, wenn Sie die Datenverarbeitungsredundanz für Ihre Aurora-PostgreSQL-Limitless-Database auf einen Wert von über Null einstellen, sodass eine Verfügbarkeit von 99,99 % gewährleistet ist. Jede Datenverarbeitungs-Instance, die Daten aus Ihrer unbegrenzten Datenbank von Aurora PostgreSQL speichert und darauf zugreift, kann über eine oder zwei Standby-Instances verfügen, die Anfragen übernehmen können, wenn die primäre Datenbank nicht verfügbar ist. Die Router leiten den Datenverkehr automatisch um, um Ihre Anwendung so wenig wie möglich zu beeinträchtigen.

Die unbegrenzte Datenbank von Aurora PostgreSQL ist für die Cluster-Konfiguration Aurora I/O-Optimized mit PostgreSQL 16.4-Kompatibilität verfügbar. Weitere Informationen zur regionalen AWS-Verfügbarkeit der unbegrenzten Datenbank von Aurora PostgreSQL in AWS finden Sie auf der Aurora-Preisseite.

In der unbegrenzten Datenbank von Aurora PostgreSQL wird die Datenbankkapazität in ACUs gemessen. Sie zahlen eine Pauschale pro Sekunde der ACU-Nutzung. Es gelten die Tarife Speicherkonfigurationen von Aurora I/O-Optimized. Weitere Informationen finden Sie auf der Seite mit der Preisübersicht für Aurora.

Parallelabfrage von Amazon Aurora bezieht sich auf die Fähigkeit, die Datenverarbeitungslast einer einzelnen Abfrage auf Tausende von CPUs in der Speicherebene von Aurora zu verteilen. Ohne Parallel Query würde eine Abfrage, die gegen eine Amazon Aurora-Datenbank durchgeführt wird, vollständig innerhalb einer Instance des Datenbank-Clusters ausgeführt; dies wäre vergleichbar mit der Funktionsweise der meisten Datenbanken.

Parallel Query ist eine gute Lösung für analytische Workloads, die neue Daten und eine gute Abfrageleistung erfordern, selbst bei großen Tabellen. Solche Workloads sind oft operativer Art.

Mit Parallel Query können analytische Abfragen um bis zu 2 Größeneinheiten schneller durchgeführt werden. Sie erreichen so auch Operative Einfachheit und Datenfrische, da Sie eine Abfrage direkt über die aktuellen Transaktionsdaten in Ihrem Aurora-Cluster durchführen können. Parallel Query ermöglichst außerdem transaktionale und analytische Workloads auf derselben Datenbank, in dem es Aurora ermöglicht, einen hohen Transaktionsdurchsatz bei gleichzeitigen analytischen Abfragen aufrechtzuerhalten.

Die meisten Abfragen über große Datensätze, die sich nicht bereits im Pufferpool befinden, werden davon profitieren. Die erste Version von Parallel Query kann die Verarbeitung von mehr als 200 SQL-Funktionen, Equijoins und Projektionen nach unten drücken und ausdehnen.

Die Verbesserung der Leistung einer bestimmten Abfrage hängt davon ab, wie viel des Abfrageplans auf die Aurora-Speicherschicht übertragen werden kann. Kunden haben eine Verbesserung der Abfrage-Latenzzeit in Höhe von mehr als einer Größenordnung gemeldet.

Ja, aber wir gehen davon aus, dass diese Fälle selten sein werden.

Änderungen in der Abfragesyntax sind nicht erforderlich. Der Abfrageoptimierer entscheidet automatisch, ob er Parallel Query für Ihre spezifische Abfrage verwendet. Um zu überprüfen, ob eine Abfrage Parallel Query verwendet, können Sie den Ausführungsplan der Abfrage anzeigen, indem Sie den Befehl EXPLAIN ausführen. Wenn Sie die Heuristiken umgehen und Parallel Query zu Testzwecken erzwingen möchten, verwenden Sie die Sitzungsvariable aurora_pq_force.

Parallel Query kann sowohl auf globaler Ebene als auch auf Sitzungsebene mit dem Parameter aurora_pq dynamisch aktiviert und deaktiviert werden.

Nein. Es wird Ihnen nichts anderes berechnet, als das, was Sie bereits für Instances, E/A und Speicher bezahlen.

Nein, die E/A-Kosten für Parallel Query für Ihre Abfrage werden auf der Speicherebene gemessen und sind bei aktivierter Parallel Query gleich oder höher. Ihr Vorteil ist die Verbesserung der Abfrageleistung.

Es gibt zwei Gründe für potenziell höhere E/A-Kosten bei Parallel Query. Erstens, selbst wenn sich einige der Daten in einer Tabelle im Pufferpool befinden, erfordert Parallel Query, dass alle Daten auf der Speicherschicht gescannt werden, was zu E/A führt. Zweitens ist ein Nebeneffekt der Vermeidung von Konflikten im Pufferpool, dass das Ausführen einer Abfrage mit Parallel Query den Pufferpool nicht anlaufen lässt. Infolgedessen entstehen bei aufeinander folgenden Durchläufen derselben Abfrage mit Parallel Query die vollen E/A-Kosten.

Weitere Informationen finden Sie in der Dokumentation zur Parallelabfrage.

Nein. Aktuell können Sie Parallel Query mit Instances in der R*-Instance-Familie verwenden.

Parallel Query ist für die MySQL-5.7- und MySQL-8.0-kompatiblen Versionen von Amazon Aurora verfügbar.

Parallel Query ist mit Aurora Serverless v2 und Backtrack kompatibel.

Nein. Obwohl wir erwarten, dass Parallel Query in den meisten Fällen die Latenzzeiten verbessert, können Ihnen höhere E/A-Kosten entstehen. Wir empfehlen, dass Sie Ihren Workload mit ein- und ausgeschalteter Funktion jeweils gründlich testen. Wenn Sie überzeugt sind, dass Parallel Query die richtige Wahl ist, können Sie sich darauf verlassen, dass der Abfrageoptimierer automatisch entscheidet, welche Abfragen Parallel Query verwenden sollen. In den seltenen Fällen, in denen der Optimierer nicht die optimale Entscheidung trifft, können Sie die Einstellung überschreiben.

Aurora Parallel Query ist kein Data Warehouse und bietet nicht die in solchen Produkten übliche Funktionalität. Es wurde entwickelt, um die Abfrageleistung Ihrer relationalen Datenbank zu beschleunigen, und eignet sich für Anwendungsfälle wie die operative Analytik, wenn Sie schnelle analytische Abfragen auf neue Daten in Ihrer Datenbank durchführen müssen.

Wenn Sie ein Cloud-Data-Warehouse im Exabyte-Bereich benötigen, ziehen Sie Amazon Redshift in Betracht.

Amazon Aurora-optimierte Lesevorgänge (verfügbar für Aurora PostgreSQL) ist eine neue Preis-Leistungs-Option, die eine bis zu 8-fache Verbesserung der Abfragelatenz und eine Kostenersparnis von bis zu 30 % im Vergleich zu Instances ohne diese Funktion bietet. Sie ist ideal für Anwendungen mit großen Datenmengen, die die Speicherkapazität einer Datenbank-Instance überschreiten.

Optimized-Reads-Instances von Amazon Aurora verwenden lokale NVMe-basierte SSD-Blockspeicher, die auf Graviton-basierten r6gd- und Intel-basierten r6id-Instances verfügbar sind, um die Abfragelatenz von Anwendungen mit Datensätzen zu verbessern, die die Speicherkapazität einer Instance überschreiten. Optimierte Lesevorgänge umfassen Leistungsverbesserungen wie mehrstufiges Caching und temporäre Objekte.

Mehrstufiges Caching bietet eine bis zu achtmal verbesserte Abfragelatenz und Kosteneinsparungen von bis zu 30 % für leseintensive, E/A-intensive Anwendungen wie operative Dashboards, Anomalieerkennung und vektorbasierte Ähnlichkeitssuchen. Diese Vorteile werden durch die automatische Zwischenspeicherung von Daten, die aus dem Puffercache der In-Memory-Datenbank in den lokalen Speicher verdrängt werden, erzielt, um nachfolgende Zugriffe auf diese Daten zu beschleunigen. Mehrstufiges Caching ist nur für die Amazon-Aurora-PostgreSQL-Edition mit der E/A-optimierten Aurora Konfiguration verfügbar.

Temporäre Objekte ermöglichen eine schnellere Abfrageverarbeitung, indem temporäre Tabellen (die von Aurora PostgreSQL erstellt wurden) im lokalen Speicher platziert werden. Dadurch wird die Leistung von Abfragen verbessert, die Sortierungen, Hash-Aggregationen, Verbindungen mit hoher Last und andere datenintensive Operationen beinhalten.

Amazon Aurora-optimierte Lesevorgänge für Aurora PostgreSQL bietet Kunden mit latenzempfindlichen Anwendungen und großen Arbeitssätzen eine überzeugende Preis-Leistungs-Alternative, um ihre geschäftlichen SLAs zu erfüllen und noch mehr mit ihren Instances zu erreichen.

Amazon Aurora Optimized Reads sind auf Intel-basierten R6id- und Graviton-basierten R6gd-Instances verfügbar. Die regionale Verfügbarkeit für Aurora können Sie hier anzeigen.

Amazon Aurora Optimized Reads ist für die PostgreSQL-kompatible Edition von Aurora in R6id- und R6gd-Instances verfügbar. Unterstützte Engine-Versionen sind 15.4 und höher sowie 14.9 und höher auf Aurora PostgreSQL.

Amazon Aurora Optimized Reads ist in Aurora Serverless v2 (ASv2) nicht verfügbar.

Ja, Amazon Aurora Optimized Reads ist in beiden Konfigurationen verfügbar. Bei beiden Konfigurationen ordnen die Instances, die optimierte Lesevorgänge aktivieren, temporäre Tabellen automatisch dem NVMe-basierten lokalen Speicher zu, um die Leistung von analytischen Abfragen und Index-Neuaufbauten zu verbessern.

Für E/A-intensive Workloads, die einen hohen Anteil an Lesevorgängen aufweisen, können Optimized-Reads-fähige Instances auf Aurora PostgreSQL, die so konfiguriert sind, dass sie Aurora I/O-Optimized verwenden, automatisch Daten, die aus dem Speicher verdrängt wurden, auf NVMe-basiertem lokalem Speicher zwischenspeichern, um eine bis zu 8-fach verbesserte Abfragelatenz und eine Kostenersparnis von bis zu 30 % im Vergleich zu Instances ohne diese Funktion zu erzielen – für Anwendungen mit großen Datensätzen, die die Speicherkapazität einer Datenbank-Instance übersteigen.

Kunden können mit Amazon Aurora Optimized Reads über die AWS-Managementkonsole, die CLI und das SDK loslegen. Optimized Reads ist standardmäßig auf allen R6id- und R6gd-Instances verfügbar. Um diese Funktion zu nutzen, können Kunden einfach ihre bestehenden Aurora-Datenbank-Cluster so modifizieren, dass sie R6id- und R6gd-Instances enthalten, oder neue Datenbank-Cluster mit diesen Instances erstellen. Informationen zu den ersten Schritten finden Sie in der Dokumentation zu Amazon-Aurora-optimierte Lesevorgänge.

Ungefähr 90 % des verfügbaren lokalen Speichers auf den R6id- und R6gd-Instances stehen für optimierte Lesevorgänge zur Verfügung. Aurora reserviert 10 % des NVMe-Speichers, um die Auswirkungen der SSD-Schreibverstärkung zu reduzieren. Die Zuweisung des verfügbaren Speichers hängt davon ab, welche optimierte Lesevorgangs-Funktionen aktiviert sind.

Wenn Sie Optimized Reads mit den Funktionen Temporäre Objekte und Mehrstufiges Caching verwenden, entspricht der für temporäre Objekte verfügbare Speicherplatz im lokalen Speicher der doppelten Größe des auf diesen Instances verfügbaren Speichers. Dies entspricht der aktuellen Größe des temporären Objektspeichers in Aurora PostgreSQL. Der verbleibende lokale Speicherplatz steht für das Zwischenspeichern von Daten zur Verfügung.

Wenn optimierte Lesevorgänge nur mit der Feature Temporäre Objekte verwendet wird, steht der gesamte verfügbare lokale Speicherplatz für temporäre Objekte zur Verfügung. Wenn Sie beispielsweise eine r6gd.8xlarge-Instance mit den Features „Temporäre Objekte“ und „Mehrstufiges Caching“ verwenden, sind 534 GiB (2x Speicherkapazität) für temporäre Objekte und 1054 GiB für mehrstufigen Cache reserviert.

Wenn der lokale Speicher ausfällt, führt Aurora automatisch einen Host-Austausch durch. In einem Datenbank-Cluster mit mehreren Knoten löst dies ein regionsinternes Failover aus.

Bei einem Failover der Datenbank wird die Abfragelatenz nach dem Failover vorübergehend zunehmen. Dieser Anstieg der Latenzzeit wird sich im Laufe der Zeit verringern und schließlich die Abfragelatenz vor dem Failover wieder erreichen. Diese Aufholdauer kann beschleunigt werden, indem Cluster-Cache-Management (CCM) aktiviert wird. Mit CCM können Kunden eine bestimmte Aurora-PostgreSQL-Datenbank-Instance als Failover-Ziel bestimmen.

Wenn CCM aktiviert ist, spiegelt der lokale Speichercache des designierten Failover-Ziels den lokalen Speichercache der primären Instance genau wider, wodurch die Aufholzeit nach dem Failover reduziert wird. Die Aktivierung von CCM könnte sich jedoch auf die langfristige Effizienz des lokalen Speichercaches auswirken, wenn das designierte Failover-Ziel auch zur Bereitstellung eines Lese-Workloads verwendet wird, der von dem Workload auf der Writer-Instance getrennt ist.

Daher müssen Kunden, die Workloads ausführen, bei denen ein Reader als Standby-Failover bestimmt werden muss, CCM aktivieren, um die Wahrscheinlichkeit zu erhöhen, dass sie ihre Abfragelatenz nach dem Failover schnell wiederherstellen können. Kunden, die getrennte Workloads auf ihren designierten Failover-Zielen ausführen, sollten vor der Aktivierung von CCM ihre Anforderungen an die sofortige Wiederherstellung der Latenz nach dem Failover mit der langfristigen Effektivität der Cache-Leistung abwägen.

pgvector ist eine Open-Source-Erweiterung für PostgreSQL, die von der Amazon-Aurora-PostgreSQL-kompatiblen Edition unterstützt wird.

Sie können pgvector verwenden, um Milliarden von Einbettungen zu speichern, zu suchen, zu indizieren und abzufragen, die aus Modellen für Machine Learning (ML) und künstliche Intelligenz (KI) in Ihrer Datenbank generiert werden, wie beispielsweise aus Amazon Bedrock oder Amazon SageMaker. Eine Vektoreinbettung ist eine numerische Darstellung, die die semantische Bedeutung von Inhalten wie Text, Bildern und Videos darstellt.

Mit pgvector können Sie Einbettungen in Ihrer Aurora-PostgreSQL-Datenbank abfragen, um effiziente semantische Ähnlichkeitssuchen dieser als Vektoren dargestellten Datentypen in Kombination mit anderen tabellarischen Daten in Aurora durchzuführen. Dies ermöglicht den Einsatz von generativer KI und anderen KI/ML-Systemen für neue Arten von Anwendungen wie personalisierte Empfehlungen auf der Grundlage ähnlicher Textbeschreibungen oder Bilder, Bewerberabgleiche auf der Grundlage von Gesprächsnotizen, Chatbots und Empfehlungen für die nächstbeste Aktion im Kundenservice auf der Grundlage erfolgreicher Transkripte oder Chat-Sitzungsdialoge und vieles mehr. 

Lesen Sie unseren Blogbeitrag über Funktionen von Vektordatenbanken und erfahren Sie, wie man Einbettungen mit der pgvector-Erweiterung in einer Aurora-PostgreSQL-Datenbank speichert, einen interaktiven Chatbot zur Beantwortung von Fragen erstellt und die native Integration zwischen pgvector und Aurora Machine Learning für Stimmungsanalyse verwendet.

Ja. Aurora Machine Learning (ML) stellt ML-Modelle als SQL-Funktionen zur Verfügung, so dass Sie Standard-SQL verwenden können, um ML-Modelle aufzurufen, ihnen Daten zu übergeben und Vorhersagen als Abfrageergebnisse zurückzugeben. pgvector erfordert, dass Vektoreinbettungen in der Datenbank gespeichert werden. Dazu müssen Sie das ML-Modell auf Quelltext- oder -Image-Daten ausführen, um Einbettungen zu generieren, und dann die Einbettungen im Stapel in Aurora PostgreSQL verschieben.

Aurora ML kann dies zu einem Echtzeitprozess machen, der es ermöglicht, die Einbettungen in Aurora PostgreSQL auf dem neuesten Stand zu halten. Dazu werden periodische Aufrufe an Amazon Bedrock oder Amazon SageMaker ausgeführt, die die neuesten Einbettungen aus Ihrem Modell zurückgeben.

Ja. Es gibt zwei Methoden, um Amazon-Aurora-Datenbanken in Amazon Bedrock zu integrieren und so Anwendungen für generative KI zu unterstützen. Erstens bietet Amazon Aurora ML Zugriff auf die in Amazon Bedrock verfügbaren Basismodelle direkt über SQL für Aurora MySQL und Aurora PostgreSQL. Zweitens können Sie Aurora mit nur einem Klick als Ihren Vektorspeicher in den Amazon-Bedrock-Wissensdatenbanken konfigurieren und von Bedrock generierte Einbettungen in Aurora speichern. Amazon-Bedrock-Wissensdatenbanken unterstützen Aurora PostgreSQL als Vektorspeicher für Anwendungsfälle wie Retrieval Augmented Generation (RAG). Lesen Sie unseren Blog und unsere Dokumentation zur Verwendung von Aurora PostgreSQL als Wissensdatenbank für Amazon Bedrock.

PostgreSQL-optimierte Lesevorgänge für Amazon Aurora mit pgvector erhöht die Abfragen pro Sekunde für die Vektorsuche bei Workloads, die den verfügbaren Instance-Speicher übersteigen, um das bis zu 9-fache. Möglich wird dies durch die in Optimized Reads verfügbare mehrstufige Caching-Funktion, mit der Daten, die aus dem Puffercache der In-Memory-Datenbank entfernt wurden, automatisch im lokalen Speicher zwischengespeichert werden, um nachfolgende Zugriffe auf diese Daten zu beschleunigen.

Lesen Sie unseren Blog und unsere Dokumentation darüber, wie Sie die Abfrageleistung für PostgreSQL-optimierte Lesevorgänge für Amazon Aurora verbessern können.

Sie sollten die Zero-ETL-Integration von Amazon Aurora mit Amazon Redshift verwenden, wenn Sie nahezu in Echtzeit Zugriff auf Transaktionsdaten benötigen. Diese Integration ermöglicht es Ihnen, Amazon Redshift ML mit einfachen SQL-Befehlen zu nutzen.

Die Amazon Aurora-Zero-ETL-Integration mit Amazon SageMaker ermöglicht es, Daten aus Ihren Betriebsdatenbanken und Anwendungen nahezu in Echtzeit in Ihr Lakehouse zu bringen. Mit der Lakehouse-Architektur von SageMaker können Sie auf Ihren vorhandenen Dateninvestitionen ein offenes Lakehouse aufbauen, ohne Ihre Datenarchitektur zu ändern, und Ihre bevorzugten Analytiktools und Abfrage-Engines wie SQL, Apache Spark, BI und KI/ML-Tools verwenden.

Die Zero-ETL-Integration in Amazon Redshift ist in der Aurora-MySQL-kompatiblen Edition für Aurora MySQL 3.05.2 Version (kompatibel mit MySQL 8.0.32) und höher verfügbar. Die Zero-ETL-Integration in Amazon Redshift ist in der Aurora-PostgreSQL-kompatiblen Edition für Aurora PostgreSQL 16.4 und höher verfügbar.

Die Aurora Zero-ETL-Integration mit Amazon SageMaker ist in der Aurora-MySQL-kompatiblen Edition für Aurora MySQL 3.05.0 (kompatibel mit MySQL 8.0.32) und höher verfügbar. Die Aurora Zero-ETL-Integration mit Amazon SageMaker ist in der Aurora PostgreSQL-kompatiblen Edition für Aurora PostgreSQL 16.4 Version und höher und Aurora PostgreSQL 17.4 und höher verfügbar.

Weitere Informationen zur Verfügbarkeit von Aurora Zero-ETL-Integrationen in der AWS-Region finden Sie unter Unterstützte Features in Aurora nach AWS-Region und Aurora-DB-Engine.

Durch die Aurora-Zero-ETL-Integration mit Amazon Redshift und Amazon SageMaker müssen Sie keine komplexen Datenpipelines erstellen und verwalten. Sie können Daten aus mehreren Tabellen aus verschiedenen Aurora-Datenbank-Clustern zu einem einzelnen Amazon-Redshift-Datenbank-Cluster oder der Lakehouse-Architektur von SageMaker konsolidieren und Analytik und ML für Betriebsdaten aus Aurora nahezu in Echtzeit ausführen.

Die Zero-ETL-Integration von Aurora mit Amazon Redshift ist mit Aurora Serverless v2 kompatibel. Wenn Sie sowohl Aurora Serverless v2 als auch Amazon Redshift Serverless verwenden, können Sie Analytik zu Transaktionsdaten nahezu in Echtzeit erstellen, ohne die Infrastruktur für Daten-Pipelines verwalten zu müssen. 

Die Zero-ETL-Integration von Aurora mit Amazon Redshift ist mit Aurora Serverless v2 kompatibel.

Sie können beginnen, indem Sie die Amazon-RDS-Konsole verwenden, um die Zero-ETL-Integration zu erstellen, indem Sie die Aurora-Quelle und das Amazon-Redshift-Ziel angeben. Sobald die Integration erstellt wurde, wird die Aurora-Datenbank auf das Ziel repliziert und Sie können mit der Abfrage der Daten beginnen, sobald das erste Seeding abgeschlossen ist. Weitere Informationen finden Sie im Handbuch „Erste Schritte“ für Aurora Zero-ETL-Integrationen mit Amazon Redshift und Aurora Zero-ETL-Integration mit Amazon SageMaker.

Die fortlaufende Verarbeitung von Datenänderungen durch die Zero-ETL-Integration wird ohne zusätzliche Kosten angeboten. Sie zahlen für vorhandene Ressourcen, die zur Generierung und Verarbeitung der im Rahmen einer Zero-ETL-Integration erstellten Änderungsdaten verwendet werden. Zu diesen Ressourcen könnten gehören:

• Zusätzliche E/A und Speicher, die durch die Aktivierung von erweiterten Binärprotokolls verwendet werden
• Kosten für den Snapshot-Export für den ersten Datenexport zum Füllen Ihrer Datenbanken
• Zusätzlicher Speicher zum Speichern replizierter Daten
• Zusätzliche Datenverarbeitungsleistung für die Verarbeitung der Datenreplikation
• AZ-übergreifende Datenübertragungskosten für die Übertragung von Daten von der Quelle zum Ziel

Weitere Informationen finden Sie auf der Seite mit der Preisübersicht für Aurora.

Ja, Sie können die Konfiguration und Bereitstellung von Ressourcen, die für eine Zero-ETL-Integration von Aurora erforderlich sind, mithilfe von AWS CloudFormation verwalten und automatisieren. Weitere Informationen finden Sie unter CloudFormation-Vorlagen mit der Zero-ETL-Integration.

CloudWatch Database Insights ist eine Überwachungs- und Metriklösung, die die Fehlerbehebung bei Datenbanken vereinfacht und verbessert. Automatisiert die Telemetrieerfassung, einschließlich Metriken, Protokollen und Traces, sodass keine manuelle Einrichtung und Konfiguration erforderlich ist. Durch die Konsolidierung dieser Telemetrie in Amazon CloudWatch bietet CloudWatch Database Insights eine einheitliche Ansicht der Datenbankleistung und des Zustands.

Zu den wichtigsten Vorteilen von CloudWatch Database Insights gehören:

1. Mühelose Telemetrieerfassung: Sammelt automatisch Datenbankmetriken, Protokolle und Traces und minimiert so die Einrichtungszeit.
2. Kuratierte Einblicke: Bietet vorgefertigte Dashboards, Alarme und Einblicke zur Überwachung und Optimierung der Datenbankleistung, wobei für den Einstieg nur eine minimale Konfiguration erforderlich ist.
3. Einheitliche CloudWatch-Ansicht: Kombiniert Telemetrie aus mehreren Datenbanken in einer Ansicht für eine vereinfachte Überwachung.
4. KI/ML-Funktionen: Nutzt KI/ML zur Erkennung von Anomalien und reduziert so den Aufwand für die manuelle Fehlerbehebung.
5. Überwachung des Anwendungskontextes: Ermöglicht Benutzern, die Datenbankleistung mit der Anwendungsleistung zu korrelieren.
6. Ansichten auf Flotten- und Instance-Ebene: Bietet sowohl eine umfassende Flottenüberwachung als auch detaillierte Instance-Ansichten für die Ursachenanalyse.
7. Nahtlose AWS-Integration: Lässt sich in Amazon CloudWatch Application Signals und AWS X- Ray integrieren und ermöglicht so ein umfassendes Beobachtbarkeitserlebnis.

Amazon DevOps Guru für RDS ist eine neue, auf ML basierende Funktion für Amazon RDS, (einschließlich Amazon Aurora) die automatisch Leistungs- und Betriebsprobleme von Datenbanken erkennt und diagnostiziert. Damit können Sie Herausforderungen innerhalb von Minuten statt Tagen bewältigen.

Amazon DevOps Guru für RDS ist ein Feature von Amazon DevOps Guru, das betriebliche- und leistungsbasierte Herausforderungen für alle Amazon-RDS-Engines und Dutzende anderer Ressourcentypen erkennt. DevOps Guru für RDS erweitert die Fähigkeiten von DevOps Guru, um eine Vielzahl von datenbankbezogenen Herausforderungen in Amazon RDS zu erkennen, zu diagnostizieren und zu beheben, wie z. B. Überbeanspruchung von Ressourcen und Fehlverhalten von SQL-Abfragen.

Wenn ein Problem auftritt, ist Amazon DevOps Guru für RDS darauf ausgelegt, Entwickler und DevOps-Techniker sofort zu benachrichtigen und Diagnoseinformationen bereitzustellen. Es bietet den Kunden außerdem Details zum Ausmaß des Problems und intelligente Empfehlungen zur Behebung datenbankbezogener Leistungs-Bottleneck- und operativer Probleme.

Amazon DevOps Guru für RDS ist darauf ausgelegt, den manuellen Aufwand zu verringern und die Zeit (von Stunden und Tagen auf Minuten) zu verkürzen, um schwer zu findende Leistungsengpässe in Ihrem relationalen Datenbank-Workload zu erkennen und zu beheben.

Sie können DevOps Guru für RDS für jede Amazon Aurora Datenbank aktivieren und es wird Leistungsherausforderungen für Ihre Workloads automatisch erkennen, Ihnen eine Alarmmeldung zu jedem Vorfall schicken, die Ergebnisse erläutern und Aktionen zur Behebung der Herausforderungen empfehlen.
DevOps Guru für RDS macht die Datenbank-Verwaltung zugänglicher für Nicht-Experten und unterstützt Datenbank-Experten, so dass sie sogar noch mehr Datenbanken verwalten können.

Amazon DevOps Guru für RDS verwendet ML, um von Erkenntnissen zur Amazon-RDS-Leistung (PI) erfasste Telemetriedaten zu analysieren. DevOps Guru für RDS nutzt jedoch für seine Analyse keinerlei Daten, die in Ihrer Datenbank gespeichert sind. PI misst die Auslastung der Datenbank, bietet eine Metrik, die von Anwendungen in der Datenbank genutzte Zeit darstellt sowie ausgewählte Metriken, die von der Datenbank erstellt werden, wie zum Beispiel Serverstatus-Variablen in MySQL und pg_stat-Tabellen in PostgreSQL.

Um mit DevOps Guru für RDS zu beginnen, stellen Sie sicher, dass Performance Insights über die RDS-Konsole aktiviert ist, und aktivieren Sie dann einfach DevOps Guru für Ihre Amazon-Aurora-Datenbanken. Mit DevOps Guru können Sie Ihr gesamtes AWS-Konto als Analyseziel auswählen, spezifische AWS CloudFormation-Stacks hierfür definieren oder AWS-Tags nutzen, um eine Ressourcengruppe zu erstellen, die DevOps Guru analysieren soll.

Amazon DevOps Guru für RDS unterstützt Sie bei der Identifizierung einer breiten Spanne von Performance-Problemen, die die Anwendungs-Servicequalität beinträchtigen könnten wie zum Beispiel Pile-Ups, Connection Storms, SQL-Regressionen, CPU- und I/O-Konflikte und Speicherprobleme.

Erkenntnisse zur Amazon-RDS-Leistung ist ein Feature zum Einstellen und Überwachen der Datenbankleistung, das Amazon-RDS-Datenbankleistungs-Metriken erfasst und visualisiert. So können Sie die Auslastung Ihrer Datenbank schnell bewerten und ermitteln, wann und wo Sie eingreifen müssen. Amazon DevOps Guru für RDS ist darauf ausgelegt, diese Metriken zu überwachen und festzustellen, wenn Ihre Datenbank Performance-Probleme hat. Metriken werden analysiert, um Ihnen die Probleme und mögliche Lösungen darzulegen.

CloudWatch Database Insights überwacht Aurora-Ressourcen und -Anwendungen in Echtzeit und präsentiert Daten in anpassbaren Dashboards. Im Gegensatz dazu ist Amazon DevOps Guru ein Service für Machine Learning (ML), der CloudWatch-Metriken analysiert, um das Verhalten einer Anwendung im Laufe der Zeit zu verstehen, Anomalien zu erkennen und Einblicke und Empfehlungen zur Problemlösung zu geben. Darüber hinaus analysiert DevOps Guru Daten aus mehreren Quellen, darunter AWS Config, AWS CloudFormation und AWS X-Ray. Sie können CloudWatch-Dashboards verwenden, um Ihre DevOps-Guru-Erkenntnisse anhand der im AWS/DevOps-Guru-Namespace veröffentlichten Metriken zu überwachen. Auf diese Weise können Sie alle Erkenntnisse und Anomalien in einer einzigen Glasansicht in der CloudWatch-Konsole anzeigen.

RDS-Performance-Insights ist ein Feature zum Einstellen und Überwachen der Datenbankleistung, mit der Kunden die Auslastung Ihrer Datenbank bewerten und ermitteln können, wann und wo sie eingreifen müssen. CloudWatch Database Insights ist ein neues Datenbank-Beobachtbarkeitsfeature, die alle Funktionen von Performance Insights sowie die Überwachung auf Flottenebene, die Integration mit der Überwachung der Anwendungsleistung und die Korrelation von Datenbankmetriken mit Protokollen und Ereignissen übernimmt.

Sie sollten die Daten-API für neue moderne Anwendungen verwenden, insbesondere für solche, die mit AWS Lambda erstellt wurden und in einem Anforderungs-/Antwortmodell auf Aurora zugreifen müssen. Sie sollten Datenbanktreiber anstelle der Daten-API verwenden und persistente Datenbankverbindungen verwalten, wenn eine vorhandene Anwendung stark mit Datenbanktreibern gekoppelt ist, wenn es langlaufende Abfragen gibt oder wenn der Entwickler die Vorteile von Datenbankfeatures wie temporären Tabellen nutzen oder Sitzungsvariablen nutzen möchte.

Die Verfügbarkeit der Daten-API, der AWS-Region und der Datenbankversion für Aurora Serverless v2 und von Aurora bereitgestellte Instances finden Sie in unserer Dokumentation.

Die Daten-API ermöglicht es Ihnen, die moderne Anwendungsentwicklung zu vereinfachen und zu beschleunigen. Die Daten-API ist eine benutzerfreundliche, sichere HTTP-basierte API, die die Bereitstellung von Datenbanktreibern, die Verwaltung clientseitiger Verbindungspools oder die Einrichtung komplexer VPC-Netzwerke zwischen der Anwendung und der Datenbank überflüssig macht. Die Daten-API verbessert außerdem die Skalierbarkeit durch das automatische Pooling und gemeinsame Nutzung von Datenbankverbindungen, was den Datenverarbeitungsaufwand von Anwendungen reduziert, die häufig Verbindungen öffnen und schließen. 

Die Daten-API für Aurora Serverless v2 und von Aurora bereitgestellte Instances unterstützen Schreib-Instances von Aurora Global Database.

Benutzer können Daten-API-Abläuffe nur aufrufen, wenn sie dazu berechtigt sind. Administratoren können Benutzern die Berechtigung zur Nutzung der Daten-API gewähren, indem sie eine Richtlinie von AWS Identity and Access Management (IAM) beifügen, die ihre Berechtigungen definiert. Sie können die Richtlinie auch an eine Rolle beifügen, wenn Sie IAM-Rollen verwenden. Wenn Sie die Daten-API aufrufen, können Sie Anmeldeinformationen für den Aurora-DB-Cluster mithilfe eines Geheimnisses in AWS Secrets Manager übergeben. 

Die Preise für die Daten-API für Aurora Serverless v2 und von Aurora bereitgestellte Instances werden nach dem API-Anforderungs-Volume berechnet, wie auf der Preisseite von Aurora beschrieben. Die Daten-API für Aurora Serveless v2 und von Aurora bereitgestellte Instances verwendet AWS-CloudTrail-Datenebenenereignisse zur Protokollierung von Aktivitäten anstelle von Verwaltungsereignissen.

Wenn Sie diese Aktivität verfolgen möchten, können Sie die Protokollierung von Datenereignissen über die CloudTrail-Konsole, die CLI oder das SDK aktivieren. Hierfür fallen Gebühren an, die auf der Preisseite von CloudTrail aufgeführt sind. Außerdem fallen für die Nutzung von AWS Secrets Manager Gebühren an, die auf der Preisseite von AWS Secrets Manager aufgeführt werden. 

AWS CloudTrail erfasst AWS-API-Aktivitäten als Verwaltungsereignisse oder Datenereignisse. CloudTrail-Verwaltungsereignisse (auch bekannt als „Abläufe der Steuerebene“) zeigen Verwaltungsvorgänge an, die für Ressourcen in Ihrem AWS-Konto ausgeführt werden, z. B. das Erstellen, Aktualisieren und Löschen einer Ressource. CloudTrail-Datenereignisse (auch bekannt als „Datenebenenabläufe“) zeigen die Ressourcenvorgänge an, die auf oder innerhalb einer Ressource in Ihrem AWS-Konto ausgeführt werden.

Die Daten-API führt Abläufe auf Datenebene durch, da sie Abfragen für Daten in Ihrer Aurora-Datenbank durchführt. Daher werden die Daten-API-Aktivitäten als Datenereignisse protokolliert, da dies die korrekte Kategorisierung der Ereignisse ist. Gebühren fallen nur für CloudTrail-Datenereignisse an, wenn Sie die Protokollierung von Datenereignissen aktivieren.

Ja. Das kostenlose Kontingent für die Daten-API umfasst eine Million Anfragen pro Monat, aggregiert für alle AWS-Regionen, für die Nutzung im ersten Jahr. Nach einem Jahr müssen Kunden für die Daten-API bezahlen, wie auf der Preisseite von Aurora beschrieben.

Blau/Grün-Bereitstellungen von Amazon RDS sind in den Versionen von Amazon Aurora MySQL-Compatible Edition 5.6 und höher sowie in den Versionen von Amazon Aurora PostgreSQL-Compatible Edition 11.21 und höher, 12.16 und höher, 13.12 und höher, 14.9 und höher sowie 15.4 und höher verfügbar. Erfahren Sie mehr über verfügbare Versionen in der Dokumentation für Aurora.

Blau/Grün-Bereitstellungen von Amazon RDS sind in allen AWS-Regionen und in den AWS-GovCloud-Regionen verfügbar.

Mit Blau/Grün-Bereitstellungen von Amazon RDS können Sie Datenbankänderungen sicherer, einfacher und schneller durchführen. Blau/Grün-Bereitstellungen eignen sich ideal für Anwendungsfälle wie Haupt- oder Nebenversions-Upgrades der Datenbank-Engine, Betriebssystemaktualisierungen, Schemaänderungen in Grün-Umgebungen, die die logische Replikation nicht unterbrechen, wie das Hinzufügen einer neuen Spalte am Ende einer Tabelle oder Änderungen der Datenbankparametereinstellungen.

Sie können Blau/Grün-Bereitstellungen verwenden, um mit einer einzigen Umstellung mehrere Datenbankaktualisierungen gleichzeitig vorzunehmen. Auf diese Weise können Sie über Sicherheitspatches auf dem Laufenden bleiben, die Datenbankleistung verbessern und mit kurzen, vorhersehbaren Ausfallzeiten auf neuere Datenbankfeatures zugreifen. Wenn Sie nur ein Nebenversions-Upgrade in Aurora durchführen möchten, empfehlen wir Ihnen, Aurora Zero Downtime Patching (ZDP) zu verwenden.

Ihnen wird der gleiche Preis für die Ausführung Ihres Workloads bei Grün-Instances wie bei Blau-Instances berechnet. Die Kosten für die Ausführung in blauen und grünen Instances beinhalten unsere aktuellen Standardpreise für db.instances, Speicherkosten, Kosten für Lese-/Schreib-E/As und alle aktivierten Features, wie beispielsweise Kosten für Backups und Erkenntnisse zur Amazon-RDS-Leistung. Effektiv zahlen Sie ca. doppelt so viel für die Ausführung von Workloads auf der DB-Instance für die Lebensdauer der Blau/Grün-Bereitstellung.

Zum Beispiel: Sie haben einen Cluster von Aurora MySQL-Compatible Edition 5.7, der auf zwei r5.2xlarge-db.instances, einer primären Writer-Instance und einer Reader-Instance in der AWS-Region us-east-1 läuft. Jede der r5.2xlarge-DB-Instances ist für 40 GiB Speicherplatz konfiguriert und hat 25 Millionen E/A pro Monat. Sie erstellen einen Klon der blauen Instance-Topologie mit Blau/Grün-Bereitstellungen von Amazon RDS, lassen ihn 15 Tage lang (360 Stunden) laufen und jede grüne Instance hat während dieser Zeit 3 Millionen E/A-Lesevorgänge. Die blauen Instances löschen Sie dann nach erfolgreicher Umstellung. Die Blau-Instances (Writer und Reader) kosten 849,20 USD für 15 Tage bei der On-Demand-Rate von 1 179 USD/Std. (Instance + Speicher + E/A). Die Grün-Instances (Writer und Reader) kosten 840,40 USD für 15 Tage bei der On-Demand-Rate von 1 167 USD/Std. (Instance + Speicher + E/A). Die Gesamtkosten für die Nutzung von Blau/Grün-Bereitstellungen für diese 15 Tage betragen 1 689,60 USD. Das ist doppelt so teuer wie die Ausführung von Blau-Instances für diesen Zeitraum.

Blau/Grün-Bereitstellungen von Amazon RDS helfen Ihnen dabei, Datenbank-Änderungen sicherer, einfacher und schneller vorzunehmen. Das sind beispielsweise Upgrades an Haupt- und Nebenversionen, Schema-Änderungen, Instance-Skalierung, Änderungen an den Engine-Parametern und Wartungs-Aktualisierungen.

Bei Blau/Grün-Bereitstellungen von Amazon RDS ist die Blau-Umgebung Ihre aktuelle Produktionsumgebung. Die Grün-Umgebung ist Ihre Staging-Umgebung, die nach dem Abschluss der Umstellung Ihre neue Produktionsumgebung wird.

Wenn Blau/Grün-Bereitstellungen von Amazon RDS eine Umstellung einleiten, blockieren sie Schreibvorgänge sowohl zur Blau-, als auch zur Grün-Umgebung, bis die Umstellung abgeschlossen ist. Während der Umstellung macht die Staging-Umgebung (oder Grün-Umgebung) Boden auf das Produktionssystem gut. Dadurch wird gewährleistet, dass Daten zwischen der Staging- und Produktionsumgebung beständig sind. Sobald die Produktions- und Staging-Umgebung komplett synchronisiert wurden, fördern die Blau/Grün-Bereitstellungen die Staging-Umgebung als die neue Produktionsumgebung, indem der Datenverkehr an die kürzlich hochgestufte Umgebung umgeleitet wird.

Blau/Grün-Bereitstellungen von Amazon RDS aktivieren Schreibvorgänge in der Grün-Umgebung nach Abschluss der Umstellung. Dadurch wird gewährleistet, dass keine Daten während der Umschaltung verloren gehen.

Blau/Grün-Bereitstellungen von Amazon RDS löschen Ihre alte Produktionsumgebung nicht. Sie können bei Bedarf darauf für zusätzliche Validierungen und Tests von Leistung/Regression zugreifen. Wenn die alte Produktionsumgebung nicht mehr benötigt wird. können Sie sie löschen. Es fallen Standard-Fakturierungsgebühren bei alten Produktions-Instances an, bis Sie sie löschen.

Der Umstellungsschutz der Blau/Grün-Bereitstellungen von Amazon RDS blockiert Schreibvorgänge bei Ihrer Blau- und Grün-Umgebung bis Ihre Grün-Umgebung vor der Umschaltung aufholt. Die Blau/Grün-Bereitstellungen führen auch Zustandsprüfungen Ihrer primären Umgebung und den Replikaten in Ihrer Blau- und Grün-Umgebung durch. Sie führen auch Zustandsprüfungen der Replikate durch. Zum Beispiel, um festzustellen, ob das Replikat den Betrieb eingestellt hat oder ob irgendwelche Fehler aufgetreten sind. Sie erkennen lang laufende Transaktionen zwischen Ihren blauen und grünen Umgebungen. Sie können die maximal tolerierbare Ausfallzeit festlegen, die bis zu 30 Sekunden betragen kann. Wenn Ihre laufende Transaktion diesen Wert überschreitet, wird die Umstellung abgebrochen.

Wenn Ihre blaue Umgebung ein selbstverwaltetes logisches Replikat oder ein Subscriber ist, blockieren wir die Umstellung. Es wird empfohlen, zuerst die Replikation in die blaue Umgebung zu beenden, mit der Umstellung fortzufahren und dann die Replikation fortzusetzen. Wenn Ihre blaue Umgebung dagegen eine Quelle für ein selbstverwaltetes logisches Replikat oder einen Publisher ist, können Sie mit der Umstellung fortfahren. Sie müssen jedoch das selbstverwaltete Replikat aktualisieren, um es nach der Umstellung aus der grünen Umgebung zu replizieren.

Ja, Blau/Grün-Bereitstellungen von Amazon RDS unterstützen Aurora Global Database. Weitere Informationen finden Sie im Benutzerhandbuch von Blau/Grün-Bereitstellungen für Amazon Aurora Global Database.

Nein. Blau/Grün-Bereitstellungen von Amazon RDS unterstützen Amazon-RDS-Proxy oder regionenübergreifende Lesereplikate nicht. 

Nein. Es ist zu diesem Zeitpunkt nicht möglich, Blau/Grün-Bereitstellungen von Amazon RDS zu verwenden, um Änderungen rückgängig zu machen.

Mit Trusted-Language-Erweiterungen (TLE) für PostgreSQL können Entwickler leistungsstarke PostgreSQL-Erweiterungen erstellen und diese sicher in Amazon Aurora ausführen. Auf diese Weise verkürzt TLE die Zeit bis zur Markteinführung und entlastet Datenbankadministratoren bei der Zertifizierung von benutzerdefiniertem und Code von Drittanbietern für die Verwendung in produktiven Datenbank-Workloads. Sie können weitergehen, sobald Sie entschieden haben. dass eine Erweiterung Ihre Bedürfnisse erfüllt. Mit TLE können unabhängige Softwareanbieter (ISV) den Kunden neue PostgreSQL-Erweiterungen anbieten, die auf Aurora ausgeführt werden.

PostgreSQL-Erweiterungen werden im gleichen Prozess-Zeitraum ausgeführt, um eine hohe Leistung sicherzustellen. Jedoch könnten Erweiterungen Software-Fehler haben, die einen Absturz der Datenbank verursachen können.

TLE für PostgreSQL bietet mehrere Schutzebenen zur Minderung dieses Risikos. TLE wurde entwickelt, um den Zugriff auf System-Ressourcen einzuschränken. Die Rolle rds_superuser kann festlegen, wer zur Installation von bestimmten Erweiterungen berechtigt ist. Jedoch können diese Änderungen nur über die TLE-API durchgeführt werden. TLE soll die Auswirkung eines Erweiterungsfehlers auf eine einzelne Datenbank-Verbindung begrenzen. Neben diesen Schutzmaßnahmen soll TLE den Datenbank-Administratoren (DBAs) in der Rolle rds_superuser präzise Online-Kontrolle darüber zur Verfügung stellen, wer Erweiterungen installieren kann und sie können ein Berechtigungsmodel für die Ausführung erstellen. Nur Nutzer mit ausreichenden Zugriffsrechten können Erweiterungen ausführen und erstellen, und zwar mit dem Befehl „CREATE EXTENSION (ERWEITERUNG ERSTELLEN)“ auf einer TLE-Erweiterung. DBAs können „PostgreSQL-Hooks“ zulassen, die für höher entwickelte Systeme erforderlich sind, welche die interne Verhaltensweise der Datenbank ändern und üblicherweise die höheren Zugriffsrechte erfordern.

TLE für PostgreSQL ist für Amazon Aurora PostgreSQL ist als mit Amazon Aurora PostgreSQL kompatible Edition bei Versionen 14.5 und höher verfügbar. TLE wird als PostgreSQL-Erweiterung selbst implementiert und Sie können sie von der Rolle rds_superuser aus ähnlich wie bei anderen Erweiterungen aktivieren, die auf Aurora unterstützt werden.

Sie können TLE für PostgreSQL in PostgreSQL 14.5 oder höher in Amazon Aurora ausführen.

TLE für PostgreSQL ist derzeit in allen AWS-Regionen (mit Ausnahme der AWS-China-Regionen) und in den AWS-GovCloud-Regionen verfügbar.

TLE für PostgreSQL steht Aurora-Kunden ohne Zusatzkosten zur Verfügung.

Aurora und Amazon RDS unterstützen über 85 kuratierte PostgreSQL-Erweiterungen. AWS verwaltet die Sicherheitsrisiken für jede einzelne dieser Erweiterungen unter dem AWS-Modell der geteilten Verantwortung. Die Erweiterung, die TLE für PostgreSQL implementiert, ist Teil dieser Erweiterungen. Erweiterungen, die Sie schreiben oder von Drittanbietern erhalten und in TLE installieren, werden als Teil Ihres Anwendungscodes angesehen. Sie sind für die Sicherheit Ihrer Anwendungen verantwortlich, die TLE-Erweiterungen verwenden.

Sie können Entwicklerfunktionen erstellen, wie eine Bitmap-Komprimierung und differenzierten Datenschutz (wie öffentlich zugängliche statistische Anfragen, die die Privatsphäre der Einzelpersonen schützen).

TLE für PostgreSQL unterstützt derzeit JavaScript, PL/pgSQL, Perl, und SQL.

Nachdem die Rolle rds_superuser TLE für PostgreSQL aktiviert, können Sie TLE-Erweiterungen mit dem Befehl SQL CREATE EXTENSION von einem beliebigen PostgreSQL-Client wie psql bereitstellen. Das ist so ähnlich wie die Erstellung einer benutzerdefinierten Funktion, die in einer prozeduralen Sprache wie PL/pgSQL oder PL/Perl geschrieben wurde. Sie können kontrollieren, welche Benutzer die Berechtigung zur Bereitstellung von TLE-Erweiterungen haben und bestimmte Erweiterungen verwenden dürfen.

TLE für PostgreSQL greift auf Ihre PostgreSQL-Datenbank ausschließlich über die TLE-API zu. Zu den von TLE unterstützen vertrauenswürdigen Sprachen gehören alle Funktionen der Programmierschnittstelle des PostgreSQL-Servers (SPI) und die Unterstützung für PostgreSQL-Hooks, einschließlich des Hooks „Passwort überprüfen“.

Sie können mehr über das Projekt TLE für PostgreSQL auf der offiziellen TLE-GitHub-Website erfahren.