Verwenden von Amazon Aurora Serverless v1 - Amazon Aurora

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwenden von Amazon Aurora Serverless v1

Wichtig

AWS hat den end-of-life Termin bekannt gegeben fürAurora Serverless v1: 31. März 2025. Alle Aurora Serverless v1-Cluster, die bis zum 31. März 2025 nicht migriert wurden, werden während des Wartungsfensters zu Aurora Serverless v2 migriert. Wenn das Upgrade fehlschlägt, konvertiert Amazon Aurora den Serverless-v1-Cluster während des Wartungsfensters in einen bereitgestellten Cluster mit der entsprechenden Engine-Version. Falls zutreffend, registriert Amazon Aurora den konvertierten bereitgestellten Cluster bei Amazon RDS Extended Support. Weitere Informationen finden Sie unter Amazon RDS Extended Support mit Amazon Aurora.

Amazon Aurora Serverless v1 (Amazon Aurora Serverless Version 1) ist eine bedarfsabhängige Konfiguration der automatischen Skalierung für Amazon Aurora. Ein Aurora Serverless v1-DB-Cluster ist ein DB-Cluster, der die Rechenkapazität abhängig von den Anforderungen Ihrer Anwendung skaliert. Im Gegensatz dazu wird bei von Aurora bereitgestellten DB-Clustern die Kapazität manuell verwaltet. Aurora Serverless v1 bietet eine relativ einfache, kostengünstige Option für selten oder vorübergehend auftretende oder unvorhersehbare Workloads. Dies ist kosteneffektiv, weil es basierend auf den Anforderungen Ihrer Anwendung automatisch gestartet und die Rechenkapazität skaliert wird, sodass sie mit der Nutzung durch Ihre Anwendung übereinstimmt, und heruntergefahren wird, wenn es nicht verwendet wird.

Weitere Informationen zu den Preisen finden Sie unter Serverless-Preise unter MySQL-kompatible Edition oder PostgreSQL-kompatible Edition auf der Seite Amazon Aurora pricing.

Aurora Serverless v1-Cluster verfügen über die gleiche Art von verteiltem und hochverfügbarem Speicher-Volumen mit hoher Kapazität, das von bereitgestellten DB-Clustern verwendet wird.

Bei einem Aurora Serverless v1-Cluster ist das Cluster-Volume immer verschlüsselt. Sie können den Verschlüsselungsschlüssel auswählen, aber Sie können die Verschlüsselung nicht deaktivieren. Das bedeutet, dass Sie für Aurora Serverless v1 die gleichen Vorgänge ausführen können wie für verschlüsselte Snapshots. Weitere Informationen finden Sie unter Aurora Serverless v1 und Snapshots.

Verfügbarkeit von Regionen und Versionen für Aurora Serverless v1

Die Verfügbarkeit von Funktionen und der Support variieren zwischen bestimmten Versionen der einzelnen Aurora-Datenbank-Engines und in allen AWS-Regionen. Weitere Informationen zur Verfügbarkeit von Versionen und Regionen im Zusammenhang mit Aurora und Aurora Serverless v1 finden Sie unter Aurora Serverless v1.

Vorteile von Aurora Serverless v1

Aurora Serverless v1 bietet folgende Vorteile:

  • Einfacher als bereitgestellt – Aurora Serverless v1 eliminiert einen Großteil der Komplexität bei der Verwaltung von DB-Instances und -Kapazität.

  • Skalierbar – Aurora Serverless v1 skaliert Rechen- und Speicherkapazität nahtlos nach Bedarf, ohne dass die Client-Verbindungen gestört werden.

  • Kosteneffektiv – Wenn Sie Aurora Serverless v1 verwenden, zahlen Sie nur für die Datenbankressourcen, die Sie verbrauchen – auf Sekundenbasis.

  • Hochverfügbarer Speicher – Aurora Serverless v1 verwendet dasselbe fehlertolerante verteilte Speichersystem mit sechsfacher Replikation wie Aurora, um vor Datenverlust zu schützen.

Anwendungsfälle für Aurora Serverless v1

Aurora Serverless v1 ist auf die folgenden Anwendungsfälle ausgelegt:

  • Selten verwendete Anwendungen – Sie haben eine Anwendung, die mehrmals pro Tag oder Woche nur für ein paar Minuten verwendet wird, wie beispielsweise eine Blog-Website mit geringem Volumen. Mit Aurora Serverless v1 zahlen Sie nur für die Datenbankressourcen, die Sie verbrauchen – auf Sekundenbasis.

  • Neue Anwendungen – Sie stellen eine neue Anwendung bereit und sind sich nicht sicher, welche Instance-Größe Sie benötigen. Mit Aurora Serverless v1 können Sie einen Datenbankendpunkt erstellen und es der Datenbank überlassen, automatisch gemäß den Kapazitätsanforderungen Ihrer Anwendung zu skalieren.

  • Variable Workloads – Sie führen eine nur wenig benutzte Anwendung aus, mit Spitzen von 30 Minuten bis zu mehreren Stunden ein paarmal pro Tag oder mehrere Male pro Jahr. Beispiele sind Anwendungen für die Personalabteilung oder für die Erstellung von Budgets oder Betriebsberichten. Mit Aurora Serverless v1 müssen Sie nicht mehr Spitzen- oder durchschnittliche Kapazitäten bereitstellen.

  • Unvorhersehbare Workloads – Sie führen tägliche Workloads mit plötzlichen und unvorhersehbaren Aktivitätszuwächsen aus. Ein Beispiel dafür ist eine Verkehrs-Website, für die Aktivitätsspitzen entstehen, wenn es zu regnen beginnt. Mit Aurora Serverless v1 wird Ihre Datenbank automatisch auf die Kapazität skaliert, mit der die Spitzenlast Ihrer Anwendung erfüllt werden kann, und wieder herunterskaliert, wenn die Aktivitätsspitze vorbei ist.

  • Entwicklungs- und Testdatenbanken – Ihre Entwickler verwenden Datenbanken während der Arbeitszeit, benötigen sie jedoch nachts oder am Wochenende nicht. Mit Aurora Serverless v1 wird Ihre Datenbank automatisch heruntergefahren, wenn sie nicht verwendet wird.

  • Anwendungen für mehrere Mandanten – Mit Aurora Serverless v1 müssen Sie die Datenbankkapazität nicht für jede Anwendung in Ihrer Flotte einzeln verwalten. Aurora Serverless v1 verwaltet die individuelle Datenbankkapazität für Sie.

Einschränkungen von Aurora Serverless v1

Die folgenden Einschränkungen gelten für Aurora Serverless v1:

  • Wichtig

    AWS hat den end-of-life Termin bekannt gegeben fürAurora Serverless v1: 31. März 2025. Alle Aurora Serverless v1-Cluster, die bis zum 31. März 2025 nicht migriert wurden, werden während des Wartungsfensters zu Aurora Serverless v2 migriert. Wenn das Upgrade fehlschlägt, konvertiert Amazon Aurora den Serverless-v1-Cluster während des Wartungsfensters in einen bereitgestellten Cluster mit der entsprechenden Engine-Version. Falls zutreffend, registriert Amazon Aurora den konvertierten bereitgestellten Cluster bei Amazon RDS Extended Support. Weitere Informationen finden Sie unter Amazon RDS Extended Support mit Amazon Aurora.

  • Aurora Serverless v1 unterstützt die folgenden -Funktionen nicht:

    • Globale Aurora-Datenbanken

    • Aurora-Replikate

    • AWS Identity and Access Management (IAM) Datenbankauthentifizierung

    • Rückverfolgung in Aurora

    • Datenbankaktivitätsstreams

    • Kerberos-Authentifizierung

    • Performance Insights

    • RDS-Proxy

    • Logs anzeigen im AWS-Managementkonsole

  • Verbindungen zu einem Aurora Serverless v1-DB-Cluster werden automatisch geschlossen, wenn sie länger als einen Tag offen gehalten werden.

  • Alle Aurora Serverless v1-DB-Cluster haben die folgenden Einschränkungen:

    • Sie können keine Aurora Serverless v1-Snapshots in Amazon-S3-Buckets exportieren.

    • Sie können Data Capture (CDC) nicht mit Aurora Serverless v1 DB-Clustern verwenden AWS Database Migration Service und ändern. Nur bereitgestellte Aurora-DB-Cluster unterstützen CDC AWS DMS als Quelle.

    • Sie können Daten nicht als Textdateien in Amazon S3 speichern oder Daten aus Textdateien aus S3 in Aurora Serverless v1 laden.

    • Sie können eine IAM-Rolle nicht einem Aurora Serverless v1-DB-Cluster anfügen. Sie können jedoch Daten aus Amazon S3 in Aurora Serverless v1 laden, indem Sie die aws_s3-Erweiterung mit der Funktion aws_s3.table_import_from_s3 und dem Parameter credentials verwenden. Weitere Informationen finden Sie unter Importieren von Amazon S3 in einen Aurora-PostgreSQL-DB-Cluster.

    • Wenn Sie den Query Editor verwenden, wird ein Secrets-Manager-Secret für die DB-Anmeldeinformationen für den Zugriff auf die Datenbank erstellt. Wenn Sie die Anmeldeinformationen aus dem Query Editor löschen, wird das zugehörige Secret auch aus Secrets Manager gelöscht. Sie können dieses Secret nach dem Löschen nicht wiederherstellen.

  • Aurora-MySQL-basierte DB-Cluster, auf denen Aurora Serverless v1 ausgeführt wird, unterstützen Folgendes nicht:

    • Aufrufen von AWS Lambda Funktionen innerhalb Ihres Aurora MySQL-DB-Clusters. AWS Lambda Funktionen können jedoch Aufrufe an Ihren Aurora Serverless v1 DB-Cluster senden.

    • Wiederherstellen eines Snapshots aus einer DB-Instance, die nicht Aurora MySQL oder RDS für MySQL ist

    • Replizieren von Daten mit auf binären Protokollen basierender Replikation. Diese Einschränkung gilt unabhängig davon, ob Ihr Aurora-MySQL-basierter DB-Cluster Aurora Serverless v1 die Quelle oder das Ziel der Replikation ist. Um Daten aus einer MySQL-DB-Instance außerhalb von Aurora, z. B. aus einer in Amazon EC2 ausgeführten Instance, in einen Aurora Serverless v1-DB-Cluster zu replizieren, sollten Sie die Verwendung von AWS Database Migration Service erwägen. Weitere Informationen finden Sie im AWS Database Migration Service -Benutzerhandbuch.

    • Erstellen von Benutzern mit hostbasiertem Zugriff ('username'@'IP_address'). Das liegt daran, dass Aurora Serverless v1 eine Router-Flotte zwischen dem Client und dem Datenbankhost für eine nahtlose Skalierung verwendet. Die IP-Adresse, die der Aurora Serverless-DB-Cluster sieht, ist die des Router-Hosts und nicht die Ihres Clients. Weitere Informationen finden Sie unter Aurora Serverless v1-Architektur.

      Verwenden Sie stattdessen den Platzhalter ('username'@'%').

  • Aurora-PostgreSQL-basierte DB-Cluster, auf denen Aurora Serverless v1 ausgeführt wird, haben die folgenden Einschränkungen:

    • Aurora-PostgreSQL-Abfrageplan-Verwaltung (apg_plan_management-Erweiterung) wird nicht unterstützt.

    • Die in Amazon RDS PostgreSQL und Aurora PostgreSQL verfügbare logische Replikationsfunktion wird nicht unterstützt.

    • Ausgehende Kommunikation, z. B. Kommunikation, die von Amazon RDS für PostgreSQL-Erweiterungen ermöglicht wird, wird nicht unterstützt. Beispielsweise können Sie mit der Erweiterung postgres_fdw/dblink nicht auf externe Daten zugreifen. Weitere Informationen zu RDS PostgreSQL-Erweiterungen finden Sie unter PostgreSQL in Amazon RDS im RDS-Benutzerhandbuch.

    • Derzeit werden bestimmte SQL-Abfragen und -Befehle nicht empfohlen. Dazu gehören empfohlene Sperren auf Sitzungsebene, temporäre Beziehungen, asynchrone Benachrichtigungen (LISTEN) und Cursors with Hold (DECLARE name ... CURSOR WITH HOLD FOR query). NOTIFY-Befehle verhindern außerdem eine Skalierung und werden nicht empfohlen.

      Weitere Informationen finden Sie unter Automatische Skalierung für Aurora Serverless v1.

  • Sie können das bevorzugte automatisierte Backup-Fenster für einen Aurora Serverless v1-DB-Cluster nicht festlegen.

  • Sie können das Wartungsfenster für einen DB-Cluster von Aurora Serverless v1 einstellen. Weitere Informationen finden Sie unter Anpassen des bevorzugten DB-Cluster-Wartungsfensters.

Anforderungen an die Konfiguration von Aurora Serverless v1

Beachten Sie beim Erstellen eines Aurora Serverless v1-DB-Clusters die folgenden Anforderungen:

  • Verwenden Sie diese spezifischen Portnummern für jede DB-Engine:

    • Aurora MySQL – 3306

    • Aurora PostgreSQL – 5432

  • Erstellen Sie Ihr Aurora Serverless v1-DB-Cluster in einer Virtual Private Cloud (VPC), basierend auf dem Amazon-VPC-Service. Wenn Sie einen Aurora Serverless v1-DB-Cluster in Ihrer VPC erstellen, verbrauchen Sie zwei (2) der fünfzig (50) Interface- und Gateway Load Balancer-Endpunkte, die Ihrer VPC zugewiesen sind. Diese Endpunkte werden automatisch für Sie erstellt. Um Ihr Kontingent zu erhöhen, können Sie Kontakt aufnehmen Support. Weitere Informationen finden Sie unter Amazon VPC-Kontingente.

  • Sie können einem Aurora Serverless v1-DB-Cluster keine öffentliche IP-Adresse geben. Sie können nur von einer VPC aus auf einen Aurora Serverless v1-DB-Cluster zugreifen.

  • Erstellen Sie Subnetze in verschiedenen Availability Zones für die DB-Subnetzgruppe, die Sie für Ihren Aurora Serverless v1-DB-Cluster verwenden. Anders ausgedrückt: In einer Availability Zone kann sich nur ein Subnetz befinden.

  • Änderungen an einer Subnetzgruppe, die von einem Aurora Serverless v1-DB-Cluster verwendet wird, werden nicht auf den Cluster angewendet.

  • Sie können von aus auf einen Aurora Serverless v1 DB-Cluster zugreifen AWS Lambda. Hierfür müssen Sie Ihre Lambda-Funktion so konfigurieren, dass sie in derselben VPC ausgeführt wird wie Ihr Aurora Serverless v1-DB-Cluster. Weitere Informationen zur Arbeit mit AWS Lambda finden Sie unter Konfiguration einer Lambda-Funktion für den Zugriff auf Ressourcen in einer Amazon VPC im AWS Lambda Entwicklerhandbuch.

Verwenden mit TLS/SSL Aurora Serverless v1

Aurora Serverless v1Verwendet standardmäßig das TLS/SSL-Protokoll (Transport Layer Security/Secure Sockets Layer), um die Kommunikation zwischen Clients und Ihrem Aurora Serverless v1 DB-Cluster zu verschlüsseln. Es unterstützt die TLS/SSL Versionen 1.0, 1.1 und 1.2. Sie müssen Ihren Aurora Serverless v1-DB-Cluster nicht für die Verwendung von TLS/SSL konfigurieren.

Es gelten jedoch die folgenden Einschränkungen:

  • TLS/SSL Unterstützung für Aurora Serverless v1 DB-Cluster ist derzeit in China (Peking) nicht verfügbar AWS-Region.

  • Wenn Sie Datenbankbenutzer für einen Aurora-MySQL-basierten Aurora Serverless v1-DB-Cluster erstellen, verwenden Sie nicht die REQUIRE-Klausel für SSL-Berechtigungen. Diese verhindert, dass Benutzer eine Verbindung mit der Aurora-DB-Instance herstellen können.

  • Sowohl für MySQL Client- als auch für PostgreSQL Client-Dienstprogramme haben Sitzungsvariablen, die Sie möglicherweise in anderen Umgebungen verwenden, keine Auswirkung, wenn Sie TLS/SSL zwischen Client und verwenden. Aurora Serverless v1

  • Beim MySQL-Client müssen Sie beim Verbinden mit dem VERIFY_IDENTITY-Modus von TLS/SSL derzeit den MySQL 8.0-kompatiblen mysql-Befehl verwenden. Weitere Informationen finden Sie unter Verbinden mit einer DB-Instance, auf der die MySQL-Datenbank-Engine ausgeführt wird.

Je nach Client, den Sie für die Verbindung mit dem Aurora Serverless v1 DB-Cluster verwenden, müssen Sie möglicherweise nicht angeben, ob eine verschlüsselte Verbindung hergestellt werden TLS/SSL soll. Um beispielsweise den PostgreSQL-Client zum Verbinden mit einem Aurora Serverless v1-DB-Cluster zu verwenden, auf dem die Aurora-PostgreSQL-kompatible Edition ausgeführt wird, verbinden Sie sich wie gewohnt.

psql -h endpoint -U user

Nachdem Sie Ihr Passwort eingegeben haben, zeigt Ihnen der PostgreSQL-Client die Verbindungsdetails, einschließlich TLS/SSL Version und Chiffre.

psql (12.5 (Ubuntu 12.5-0ubuntu0.20.04.1), server 10.12) SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off) Type "help" for help.
Wichtig

Aurora Serverless v1verwendet die Transport Layer Security/Secure Sockets Layer (TLS/SSL) protocol to encrypt connections by default unless SSL/TLS is disabled by the client application. The TLS/SSLVerbindung endet bei der Routerflotte). Die Kommunikation zwischen der Router-Flotte und Ihrem Aurora Serverless v1-DB-Cluster erfolgt innerhalb der internen Netzwerkgrenze des Services.

Sie können den Status der Client-Verbindung überprüfen, um zu überprüfen, ob die Verbindung zu TLS/SSL verschlüsselt Aurora Serverless v1 ist. Das PostgreSQL pg_stat_ssl und die pg_stat_activity Tabellen und ihre ssl_is_used Funktion zeigen nicht den TLS/SSL Status für die Kommunikation zwischen der Client-Anwendung und. Aurora Serverless v1 Ebenso kann der TLS/SSL Status nicht aus der status MySQL-Anweisung abgeleitet werden.

Die Aurora-Clusterparameter force_ssl für PostgreSQL und require_secure_transport für MySQL wurden für Aurora Serverless v1 früher nicht unterstützt. Diese Parameter sind jetzt für Aurora Serverless v1 verfügbar. Rufen Sie den DescribeEngineDefaultClusterParametersAPI-Vorgang auf, um eine vollständige Liste der von Aurora Serverless v1 unterstützten Parameter zu erhalten. Weitere Informationen zu Parametergruppen und Aurora Serverless v1 finden Sie unter Parametergruppen für Aurora Serverless v1.

Um den MySQL-Client zu verwenden, um eine Verbindung zu einem Aurora Serverless v1 DB-Cluster herzustellen, auf dem Aurora MySQL-Compatible Edition ausgeführt wird, geben Sie TLS/SSL in Ihrer Anfrage an. Das folgende Beispiel umfasst den Amazon Root CA 1 Trust Store, der von Amazon Trust Services heruntergeladen wurde und für diese Verbindung erforderlich ist.

mysql -h endpoint -P 3306 -u user -p --ssl-ca=amazon-root-CA-1.pem --ssl-mode=REQUIRED

Geben Sie bei der Aufforderung Ihr Passwort ein. Kurz darauf öffnet sich der MySQL-Monitor. Sie können sich mit dem status-Befehl vergewissern, dass die Sitzung verschlüsselt ist.

mysql> status -------------- mysql Ver 14.14 Distrib 5.5.62, for Linux (x86_64) using readline 5.1 Connection id: 19 Current database: Current user: ***@******* SSL: Cipher in use is ECDHE-RSA-AES256-SHA ...

Weitere Informationen zum Verbinden mit der Aurora MySQL-Datenbank über den MySQL-Client finden Sie unter Verbinden mit einer DB-Instance, auf der die MySQL-Datenbank-Engine ausgeführt wird.

Aurora Serverless v1unterstützt alle TLS/SSL Modi, die für den MySQL-Client (mysql) und den PostgreSQL-Client (psql) verfügbar sind, einschließlich der in der folgenden Tabelle aufgeführten.

Beschreibung des Modus TLS/SSL mysql- psql

Verbinden ohne Verwendung von TLS/SSL

DISABLED

disable

Versuchen Sie TLS/SSL zunächst, die Verbindung über SSL herzustellen, greifen Sie aber gegebenenfalls auf eine Verbindung ohne SSL zurück.

PREFERRED

bevorzugen (Standard)

Verwendung von TLS/SSL erzwingen

REQUIRED

require

Erzwingen TLS/SSL und verifizieren Sie die CA.

VERIFY_CA

verify-ca

TLS/SSL erzwingen, CA überprüfen und CA-Hostnamen überprüfen

VERIFY_IDENTITY

verify-full

Aurora Serverless v1 nutzt Platzhalter-Zertifikate. Wenn Sie bei Verwendung von TLS/SSL die Option "CA überprüfen" oder "CA und CA-Hostnamen überprüfen" angeben, laden Sie zuerst den Amazon Root CA 1 Trust Store von Amazon Trust Services herunter. Danach können Sie diese PEM-formatierte Datei in Ihrem Client-Befehl identifizieren. Beim PostgreSQL-Client gehen Sie so vor:

Für Linux, macOS oder Unix:

psql 'host=endpoint user=user sslmode=require sslrootcert=amazon-root-CA-1.pem dbname=db-name'

Weitere Informationen zum Arbeiten mit der Aurora PostgreSQL-Datenbank unter Verwendung des Postgres-Clients finden Sie unter Herstellen einer Verbindung zu einer DB-Instance, in der die PostgreSQL-Datenbank-Engine ausgeführt wird.

Weitere Informationen zum Verbinden mit Aurora-DB-Clustern im Allgemeinen finden Sie unter Herstellen einer Verbindung mit einem Amazon Aurora-DB-Cluster.

Unterstützte Verschlüsselungssammlungen für Verbindungen mit Aurora Serverless v1-DB-Clustern

Durch die Verwendung von konfigurierbaren Chiffrier-Suiten können Sie mehr Kontrolle über die Sicherheit Ihrer Datenbankverbindungen haben. Sie können eine Liste von Cipher Suites angeben, denen Sie erlauben möchten, TLS/SSL Client-Verbindungen zu Ihrer Datenbank zu sichern. Mit konfigurierbaren Chiffrier-Suiten können Sie die Verbindungsverschlüsselung steuern, die Ihr Datenbankserver akzeptiert. Dadurch wird die Verwendung von Verschlüsselungsverfahren verhindert, die nicht sicher sind oder nicht mehr verwendet werden.

Aurora Serverless v1-DB-Cluster, die auf Aurora MySQL basieren, unterstützen dieselben Verschlüsselungssammlungen wie von Aurora MySQL bereitgestellte DB-Cluster. Weitere Informationen über diese Verschlüsselungssammlungen finden Sie unter Konfigurieren von Cipher-Suites für Verbindungen mit Aurora-MySQL-DB-Clustern.

Aurora Serverless v1-DB-Cluster, die auf Aurora PostgreSQL basieren, unterstützen keine Chiffrier-Suiten.