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.
Amazon verwenden Aurora Serverless v1
Wichtig
AWS hat den end-of-life Termin bekannt gegeben für Aurora Serverless v1: 31. März 2025. Wir empfehlen dringend, alle zu aktualisieren Aurora Serverless v1 DB-Cluster zu Aurora Serverless v2 vor diesem Datum. Das Upgrade kann eine Änderung der Hauptversionsnummer der Datenbank-Engine beinhalten. Daher ist es wichtig, diesen Switchover vor dem end-of-life Datum zu planen, zu testen und zu implementieren. Ab dem 8. Januar 2025 können Kunden keine neuen Produkte mehr erstellen Aurora Serverless v1 Cluster oder Instances mit entweder dem AWS Management Console oder demCLI. Informationen zum Upgrade-Verfahren finden Sie unter Aurora Serverless v1 to Aurora Serverless v2, finden Sie unter Upgrade von einem Aurora Serverless v1 Cluster zu Aurora Serverless v2.
Aurora Serverless v2 skaliert schneller und detaillierter. Aurora Serverless v2 hat auch mehr Kompatibilität mit anderen Aurora-Funktionen wie Reader-DB-Instances. Sie können mehr erfahren über Aurora Serverless v2 in Die Verwendung von Aurora Serverless v2 erlauben.
Amazon Aurora Serverless v1 (Amazon Aurora Serverless Version 1) ist eine On-Demand-Autoscaling-Konfiguration für Amazon Aurora. Ein Aurora Serverless v1 Ein DB-Cluster ist ein DB-Cluster, der die Rechenkapazität je nach den Anforderungen Ihrer Anwendung nach oben und unten skaliert. Dies steht im Gegensatz zu den von Aurora bereitgestellten DB-Clustern, für die Sie die Kapazität manuell verwalten. Aurora Serverless v1 bietet eine relativ einfache, kostengünstige Option für seltene, intermittierende 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
Aurora Serverless v1 Cluster verfügen über dasselbe verteilte und hochverfügbare Speichervolumen mit hoher Kapazität, das von bereitgestellten DB-Clustern verwendet wird.
Für ein Aurora Serverless v1 Cluster, das Cluster-Volume ist 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 dieselben Operationen auf einem ausführen können Aurora Serverless v1 das können Sie auf verschlüsselten Snapshots. Weitere Informationen finden Sie unter Aurora Serverless v1 und Schnappschüsse.
Themen
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 Version und regionalen Verfügbarkeit bei Aurora und Aurora Serverless v1, finden Sie unter Aurora Serverless v1.
Vorteile von Aurora Serverless v1
Aurora Serverless v1 bietet die folgenden Vorteile:
-
Einfacher als bereitgestellt — Aurora Serverless v1 beseitigt einen Großteil der Komplexität bei der Verwaltung von DB-Instances und -Kapazitäten.
-
Skalierbar — Aurora Serverless v1 Skaliert die Rechen- und Speicherkapazität nahtlos nach Bedarf, ohne dass die Client-Verbindungen unterbrochen werden.
-
Kostengünstig — wenn Sie Aurora Serverless v1, zahlen Sie nur für die Datenbankressourcen, die Sie verbrauchen, und zwar pro Sekunde.
-
Hochverfügbarer Speicher — Aurora Serverless v1 verwendet dasselbe fehlertolerante, verteilte Speichersystem mit Sechs-Wege-Replikation wie Aurora zum Schutz vor Datenverlust.
Anwendungsfälle für Aurora Serverless v1
Aurora Serverless v1 ist für die folgenden Anwendungsfälle konzipiert:
-
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, Sie zahlen nur für die Datenbankressourcen, die Sie pro Sekunde verbrauchen.
-
Neue Anwendungen – Sie stellen eine neue Anwendung bereit und sind sich nicht sicher, welche Instance-Größe Sie benötigen. Indem Sie Aurora Serverless v1, können Sie einen Datenbank-Endpunkt erstellen und die Datenbank automatisch an die Kapazitätsanforderungen Ihrer Anwendung anpassen lassen.
-
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, Sie müssen nicht mehr für Spitzen- oder Durchschnittskapazitäten sorgen.
-
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, Ihre Datenbank skaliert die Kapazität automatisch, um den Anforderungen der Spitzenlast der Anwendung gerecht zu werden, und wird wieder herunterskaliert, wenn der Aktivitätsschub 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, Ihre Datenbank wird automatisch heruntergefahren, wenn sie nicht verwendet wird.
-
Mehrinstanzenfähige Anwendungen — 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ür Aurora Serverless v1: 31. März 2025. Wir empfehlen dringend, alle zu aktualisieren Aurora Serverless v1 DB-Cluster zu Aurora Serverless v2 vor diesem Datum. Das Upgrade kann eine Änderung der Hauptversionsnummer der Datenbank-Engine beinhalten. Daher ist es wichtig, diesen Switchover vor dem end-of-life Datum zu planen, zu testen und zu implementieren. Ab dem 8. Januar 2025 können Kunden keine neuen Produkte mehr erstellen Aurora Serverless v1 Cluster oder Instances mit entweder dem AWS Management Console oder demCLI.
Sie können Folgendes erfahren Aurora Serverless v2 in Die Verwendung von Aurora Serverless v2 erlauben. Informationen zum Upgrade-Verfahren finden Sie unter Aurora Serverless v1 to Aurora Serverless v2, finden Sie unter Upgrade von einem Aurora Serverless v1 Cluster zu Aurora Serverless v2.
-
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
-
Anzeige von Protokollen in der AWS Management Console
-
-
Verbindungen zu einem Aurora Serverless v1 DB-Cluster werden automatisch geschlossen, wenn sie länger als einen Tag geöffnet bleiben.
-
Alle Aurora Serverless v1 DB-Cluster haben die folgenden Einschränkungen:
-
Sie können nicht exportieren Aurora Serverless v1 Schnappschüsse zu Amazon S3 S3-Buckets.
-
Sie können Data Capture () CDC nicht verwenden AWS Database Migration Service und ändern mit Aurora Serverless v1 DB-Cluster. Nur bereitgestellte CDC Aurora-DB-Cluster unterstützen AWS DMS als Quelle.
-
Sie können keine Daten in Textdateien in Amazon S3 speichern oder Textdateidaten laden Aurora Serverless v1 von S3.
-
Sie können einer IAM Rolle keine Rolle zuordnen Aurora Serverless v1 DB-Cluster. Sie können jedoch Daten laden in Aurora Serverless v1 von Amazon S3 mithilfe der
aws_s3Erweiterung mit deraws_s3.table_import_from_s3Funktion und demcredentialsParameter. 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 werden ausgeführt Aurora Serverless v1 unterstützen Folgendes nicht:
-
Aufrufen von AWS Lambda Funktionen aus Ihrem Aurora My SQL DB-Cluster heraus. AWS Lambda Funktionen können jedoch Aufrufe an Ihr Aurora Serverless v1 DB-Cluster.
-
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 Aurora SQL My-basierter DB-Cluster Aurora Serverless v1 ist die Quelle oder das Ziel der Replikation. Um Daten in eine zu replizieren Aurora Serverless v1 Ziehen Sie die Verwendung eines DB-Clusters aus einer My SQL DB-Instance außerhalb von Aurora in Betracht, z. B. einerEC2, die auf Amazon läuft AWS Database Migration Service. Weitere Informationen finden Sie im AWS Database Migration Service -Benutzerhandbuch.
-
Erstellen von Benutzern mit hostbasiertem Zugriff (
'). Das liegt daran Aurora Serverless v1 verwendet eine Router-Flotte zwischen dem Client und dem Datenbank-Host für eine nahtlose Skalierung. Die IP-Adresse, die Aurora Serverless Der DB-Cluster sieht, ist die des Router-Hosts und nicht Ihr Client. Weitere Informationen finden Sie unter Aurora Serverless v1 Anwendung ansehen.username'@'IP_address'Verwenden Sie stattdessen den Platzhalter (
').username'@'%'
-
-
Auf Aurora Postgre SQL basierende DB-Cluster werden ausgeführt Aurora Serverless v1 haben 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/dblinknicht 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 FORqueryNOTIFY-Befehle verhindern außerdem eine Skalierung und werden nicht empfohlen.Weitere Informationen finden Sie unter Autoscaling für Aurora Serverless v1.
-
-
Sie können das bevorzugte automatische Backup-Fenster nicht für ein Aurora Serverless v1 DB-Cluster.
-
Sie können das Wartungsfenster für ein festlegen Aurora Serverless v1 DB-Cluster. Weitere Informationen finden Sie unter Anpassen des bevorzugten DB-Cluster-Wartungsfensters.
Konfigurationsanforderungen für Aurora Serverless v1
Wenn Sie ein erstellen Aurora Serverless v1 Beachten Sie beim DB-Cluster die folgenden Anforderungen:
-
Verwenden Sie diese spezifischen Portnummern für jede DB-Engine:
-
Aurora, Mai SQL —
3306 -
Aurora Postgret — SQL
5432
-
-
Erstelle deine Aurora Serverless v1 DB-Cluster in einer virtuellen privaten Cloud (VPC), die auf dem VPC Amazon-Service basiert. Wenn Sie ein erstellen Aurora Serverless v1 DB-Cluster in IhremVPC, Sie verbrauchen 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 Kontakt aufnehmen. Support Weitere Informationen finden Sie unter VPCAmazon-Kontingente.
-
Sie können keine geben Aurora Serverless v1 DB-Cluster eine öffentliche IP-Adresse. Sie können auf eine zugreifen Aurora Serverless v1 DB-Cluster nur innerhalb einesVPC.
-
Erstellen Sie Subnetze in verschiedenen Availability Zones für die DB-Subnetzgruppe, die Sie für Ihre Aurora Serverless v1 DB-Cluster. Anders ausgedrückt: In einer Availability Zone kann sich nur ein Subnetz befinden.
-
Änderungen an einer Subnetzgruppe, die von einem verwendet wird Aurora Serverless v1 DB-Cluster werden nicht auf den Cluster angewendet.
-
Sie können auf eine zugreifen Aurora Serverless v1 DB-Cluster von AWS Lambda. Dazu müssen Sie Ihre Lambda-Funktion so konfigurieren, dass sie genauso läuft VPC wie Ihre 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 einem Amazon VPC im AWS Lambda Entwicklerhandbuch.
Verwenden vonTLS/SSLmit Aurora Serverless v1
Standardmäßig Aurora Serverless v1 verwendet das Transport Layer Security/Secure Sockets Layer (TLS/SSL (Transport Layer) -Protokoll, um die Kommunikation zwischen Clients und Ihrem Aurora Serverless v1 DB-Cluster. Es unterstützt die SSL VersionenTLS//1.0, 1.1 und 1.2. Sie müssen Ihre nicht konfigurieren Aurora Serverless v1 DB-Cluster zur Verwendung vonTLS/SSL.
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 ein auf Aurora My SQL basierendes System erstellen Aurora Serverless v1 DB-Cluster, verwenden Sie die
REQUIREKlausel nicht für SSL Berechtigungen. Diese verhindert, dass Benutzer eine Verbindung mit der Aurora-DB-Instance herstellen können. -
Sowohl für die Dienstprogramme My SQL Client als auch für Postgre SQL Client haben Sitzungsvariablen, die Sie möglicherweise in anderen Umgebungen verwenden, keine Auswirkung, wenn SieTLS/SSLzwischen Client und Aurora Serverless v1.
-
Wenn Sie für My SQL Client eine Verbindung mit dem
VERIFY_IDENTITYModusTLS/SSLherstellen, müssen Sie derzeit den My SQLmysql8.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, mit dem Sie eine Verbindung herstellen Aurora Serverless v1 DB-Cluster: Möglicherweise müssen SieTLS/nicht angebenSSL, um eine verschlüsselte Verbindung herzustellen. Um beispielsweise den SQL Postgre-Client zu verwenden, um eine Verbindung zu einem herzustellen Aurora Serverless v1 DB-Cluster, auf dem Aurora SQL Postgre-Compatible Edition ausgeführt wird, stellen Sie wie gewohnt eine Verbindung her.
psql -hendpoint-Uuser
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 v1 verwendet die Transport Security/Secure Sockets Layer (TLS/SSL) protocol to encrypt connections by default unless SSL/TLS is disabled by the client application. The TLS/SSL Layer-Verbindung, die bei der Router-Flotte endet. Kommunikation zwischen der Router-Flotte und Ihrem Aurora Serverless v1 Der DB-Cluster findet innerhalb der internen Netzwerkgrenze des Dienstes statt.
Sie können den Status der Client-Verbindung überprüfen, um zu überprüfen, ob die Verbindung zu Aurora Serverless v1 istTLS/SSLverschlüsselt. Postgre SQL pg_stat_ssl und pg_stat_activity Tabellen und ihre ssl_is_used Funktion zeigen nicht den SSL StatusTLS/für die Kommunikation zwischen der Client-Anwendung und Aurora 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 My wurden SQL früher nicht unterstützt require_secure_transport für Aurora Serverless v1. Diese Parameter sind jetzt verfügbar für Aurora
Serverless v1. 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 herzustellen Aurora Serverless v1 DB-Cluster, 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
mysql -hendpoint-P 3306 -uuser-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 v1 unterstü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 TLS /-Modus 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 verwendet Platzhalterzertifikate. 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
Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Linux, macOS, oder Unix:
psql 'host=endpointuser=usersslmode=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 Cipher Suites für Verbindungen zu Aurora Serverless v1 DB-Cluster
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 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 Konfigurieren von Cipher-Suites für Verbindungen mit Aurora-MySQL-DB-Clustern.
Aurora Serverless v1 DB-Cluster, die auf Aurora Postgre basieren, unterstützen SQL keine Cipher Suites.
