Verwenden von Amazon Aurora Serverless v1 - Amazon Aurora
Region und Versionsverfügbarkeit für Aurora Serverless v1Vorteile von Aurora Serverless v1Anwendungsfälle für Aurora Serverless v1Einschränkungen von Aurora Serverless v1Anforderungen an die Konfiguration von Aurora Serverless v1Verwenden vonTLS/SSLmit Aurora Serverless v1

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

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 Pricing unter My SQL -Compatible Edition oder Postgre SQL -Compatible 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 v2-Cluster können Sie auswählen, ob das Cluster-Volume verschlüsselt werden soll.

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.

Themen
Wichtig

Aurora verfügt über zwei Generationen serverloser Technologie: Aurora Serverless v2 und Aurora Serverless v1. Wenn Ihre Anwendung auf My SQL 8.0 oder Postgre SQL 13 ausgeführt werden kann, empfehlen wir Ihnen, sie zu verwenden. Aurora Serverless v2 Aurora Serverless v2skaliert schneller und detaillierter. Aurora Serverless v2hat auch mehr Kompatibilität mit anderen Aurora-Funktionen wie Reader-DB-Instances. Wenn Sie also bereits mit Aurora vertraut sind, müssen Sie nicht so viele neue Verfahren oder Einschränkungen für Aurora Serverless v2 erlernen wie für Aurora Serverless v1.

Weitere Informationen über Aurora Serverless v2 finden Sie unter Verwenden von Aurora Serverless v2.

Region und Versionsverfügbarkeit 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 Unterstützte Regionen und Aurora-DB-Engines für Aurora Serverless Version 1.

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:

  • 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

    • RDSProxy

    • Logs anzeigen im AWS Management Console

  • 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 CDC Aurora-DB-Cluster unterstützen 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 einem Aurora Serverless v1 DB-Cluster keine IAM Rolle zuordnen. 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 Daten aus Amazon S3 in einen Aurora SQL Postgre-DB-Cluster importieren.

    • 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.

  • Auf Aurora My SQL basierende DB-Cluster, die ausgeführt werden, unterstützen Folgendes Aurora Serverless v1 nicht:

    • Aufrufen von AWS Lambda Funktionen aus Ihrem Aurora My SQL DB-Cluster heraus. 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 My SQL oder RDS for My istSQL.

    • Replizieren von Daten mit auf binären Protokollen basierender Replikation. Diese Einschränkung gilt unabhängig davon, ob Ihr auf Aurora My SQL basierender DB-Cluster die Quelle oder das Ziel der Replikation Aurora Serverless v1 ist. Um Daten von einer My Aurora Serverless v1 SQL DB-Instance außerhalb von Aurora, z. B. einer auf Amazon laufenden Instance, in einen DB-Cluster zu replizierenEC2, sollten Sie die Verwendung von AWS Database Migration Service. 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'@'%').

  • Bei Ausführung von Aurora SQL Postgre-basierten DB-Clustern gelten Aurora Serverless v1 die folgenden Einschränkungen:

    • Aurora SQL Postgre-Abfrageplanverwaltung (apg_plan_managementErweiterung) wird nicht unterstützt.

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

    • Ausgehende Kommunikation, wie sie von Amazon RDS für SQL Postgre-Erweiterungen aktiviert wurde, wird nicht unterstützt. Beispielsweise können Sie mit der Erweiterung postgres_fdw/dblink nicht auf externe Daten zugreifen. Weitere Informationen zu RDS SQL Postgre-Erweiterungen finden Sie unter Postgre SQL bei Amazon RDS im RDSBenutzerhandbuch.

    • 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 Wartungszeitfenster 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, Mai SQL — 3306

    • Aurora Postgret — SQL 5432

  • Erstellen Sie Ihren Aurora Serverless v1 DB-Cluster in einer virtuellen privaten Cloud (VPC), die auf dem VPC Amazon-Service basiert. Wenn Sie in Ihrem einen Aurora Serverless v1 DB-Cluster erstellenVPC, verbrauchen Sie zwei (2) der fünfzig (50) Interface- und Gateway Load Balancer-Endpunkte, die Ihnen zugewiesen sind. VPC Diese Endpunkte werden automatisch für Sie erstellt. Um Ihr Kontingent zu erhöhen, können Sie sich an uns wenden. AWS Support Weitere Informationen finden Sie unter VPCAmazon-Kontingente.

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

  • 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. Dazu müssen Sie Ihre Lambda-Funktion so konfigurieren, dass sie in demselben VPC Aurora Serverless v1 DB-Cluster ausgeführt wird. Weitere Informationen zur Arbeit mit AWS Lambda finden Sie unter Konfiguration einer Lambda-Funktion für den Zugriff auf Ressourcen in einem Amazon VPC im AWS Lambda Entwicklerhandbuch.

Verwenden vonTLS/SSLmit Aurora Serverless v1

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

Es gelten jedoch die folgenden Einschränkungen:

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

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

  • Sowohl für My SQL Client- als auch für SQL Postgre-Client-Dienstprogramme haben Sitzungsvariablen, die Sie möglicherweise in anderen Umgebungen verwenden, keine Auswirkung, wenn SieTLS/SSLzwischen Client und verwenden. Aurora Serverless v1

  • Wenn Sie für My SQL Client eine Verbindung mit dem VERIFY_IDENTITY ModusTLS/SSLherstellen, müssen Sie derzeit den My SQL mysql 8.0-kompatiblen Befehl verwenden. Weitere Informationen finden Sie unter Verbindung zu einer DB-Instance herstellen, auf der die My SQL Database-Engine ausgeführt wird.

Abhängig vom Client, den Sie für die Verbindung mit dem Aurora Serverless v1 DB-Cluster verwenden, müssen Sie möglicherweise nichtTLS/angeben, SSL um eine verschlüsselte Verbindung herzustellen. Um beispielsweise den SQL Postgre-Client zu verwenden, um eine Verbindung zu einem Aurora Serverless v1 DB-Cluster herzustellen, auf dem Aurora SQL Postgre-Compatible Edition ausgeführt wird, stellen Sie wie gewohnt eine Verbindung her. 

psql -h endpoint -U user

Nachdem Sie Ihr Passwort eingegeben haben, zeigt Ihnen der SQL Postgre-Client die Verbindungsdetails an, einschließlich derTLS/SSL-Version und der 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 standardmäßig das Transport Layer Security/Secure Sockets Layer (TLS/SSL) -Protokoll, um Verbindungen zu verschlüsseln, sofernSSL/nicht von der Client-Anwendung deaktiviert TLS wird. Die SSL VerbindungTLS/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 zuTLS/SSLverschlüsselt Aurora Serverless v1 ist. Postgre SQL pg_stat_ssl und pg_stat_activity Tabellen sowie die zugehörige ssl_is_used Funktion zeigen nicht den SSL StatusTLS/für die Kommunikation zwischen der Client-Anwendung undAurora Serverless v1. Ebenso kann der SSL StatusTLS/nicht aus der SQL status My-Anweisung abgeleitet werden.

Die Aurora-Cluster-Parameter force_ssl für Postgre SQL und require_secure_transport My wurden SQL früher für Aurora Serverless Version 1 nicht unterstützt. Diese Parameter sind jetzt für Aurora Serverless v1 verfügbar. Rufen Sie den DescribeEngineDefaultClusterParametersAPIVorgang 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 My SQL Client zu verwenden, um eine Verbindung zu einem Aurora Serverless v1 DB-Cluster herzustellen, auf dem Aurora My SQL -Compatible Edition ausgeführt wird, geben Sie SSL in Ihrer AnfrageTLS/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. Bald wird der My SQL Monitor geöffnet. 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 Herstellen einer Verbindung mit Aurora My SQL Database mit My SQL Client finden Sie unter Verbindung zu einer DB-Instance herstellen, auf der die My SQL Database-Engine ausgeführt wird.

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

Beschreibung des Modus „TLS/SSL“ mysql- psql

Connect, ohneTLS/zu verwendenSSL.

DISABLED

disable

Versuchen Sie SSL zunächst, die Verbindung mitTLS/herzustellen, greifen Sie aber SSL gegebenenfalls auf non- zurück.

PREFERRED

bevorzugen (Standard)

Erzwingen Sie die Verwendung vonTLS/SSL.

REQUIRED

require

Erzwingen SieTLS/SSLund überprüfen Sie die CA.

VERIFY_CA

verify-ca

Erzwingen SieTLS/SSL, überprüfen Sie die CA und verifizieren Sie den CA-Hostnamen.

VERIFY_IDENTITY

verify-full

Aurora Serverless v1 nutzt Platzhalter-Zertifikate. Wenn Sie die Option „Verify CA“ oder „Verify CA and CA Hostname“ angeben, wenn SieTLS/verwendenSSL, 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. Um dies mit dem SQL Postgre-Client zu tun:

Für LinuxmacOS, oderUnix:

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

Weitere Informationen zur Arbeit mit der Aurora SQL Postgres-Datenbank mithilfe des Postgres-Clients finden Sie unter Verbindung zu einer DB-Instance herstellen, auf der die SQL Postgre-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 Client-/Verbindungen zu Ihrer Datenbank zu sichern. SSL 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 v1DB-Cluster, die auf Aurora My basieren, SQL unterstützen dieselben Cipher Suites wie die von Aurora My SQL bereitgestellten DB-Cluster. Weitere Informationen über diese Verschlüsselungssammlungen finden Sie unter Konfiguration von Cipher Suites für Verbindungen zu Aurora My SQL DB-Clustern.

Aurora Serverless v1DB-Cluster, die auf Aurora Postgre basieren, unterstützen SQL keine Cipher Suites.