Amazon Redshift unterstützt die Verwendung von Python-UDFs nach dem 30. Juni 2026 nicht mehr. Wir werden damit beginnen, es schrittweise durchzusetzen. Weitere Informationen zum Ende der Lebensdauer von Python und zu den Migrationsoptionen finden Sie im Blogbeitrag, der am 30. Juni 2025 veröffentlicht wurde.

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.

Verhaltensänderungen in Amazon Redshift

Im Zuge der Weiterentwicklung und Verbesserung von Amazon Redshift werden bestimmte Verhaltensänderungen eingeführt, um Leistung, Sicherheit und Benutzerkomfort zu verbessern. Diese Seite dient als umfassende Ressource, mit der Sie über diese wichtigen Updates auf dem Laufenden bleiben, Maßnahmen ergreifen und mögliche Unterbrechungen Ihrer Workloads vermeiden können.

Bevorstehende Verhaltensänderungen

Im Folgenden werden bevorstehende Verhaltensänderungen beschrieben.

AWS KMS Durchsetzung wichtiger Berechtigungen für Amazon Redshift Serverless APIs nach dem 17. August 2026

Amazon Redshift Serverless führt jetzt eine neue Autorisierungsprüfung durch, bei der der IAM-Principal, der bestimmte Amazon Redshift Serverless APIs aufruft, über explizite AWS KMS Berechtigungen für den vom Kunden verwalteten Schlüssel verfügen muss, der den Ziel-Namespace verschlüsselt. Bisher führte Amazon Redshift AWS KMS Operationen in Ihrem Namen mithilfe der Amazon Redshift-Servicerolle durch, ohne zu überprüfen, ob der aufrufende IAM-Principal selbst autorisiert war, diesen Schlüssel zu verwenden.

Nachdem die neue Autorisierungsprüfung aktiviert wurde, schlagen API-Aufrufe von Principals, denen die erforderlichen AWS KMS Berechtigungen fehlen, fehl mit einemValidationException: "Insufficient KMS permissions." Sie könnten davon betroffen sein, wenn Sie Amazon Redshift Serverless-Namespaces mit einem vom Kunden verwalteten Schlüssel verschlüsselt haben und IAM-Principals verwenden, um die unten aufgeführten betroffenen APIs aufzurufen.

Um Unterbrechungen zu vermeiden, überprüfen Sie, welche IAM-Principals in Ihren Konten die unten aufgeführten APIs für Namespaces aufrufen, die mit einem vom Kunden verwalteten Schlüssel verschlüsselt wurden, und stellen Sie sicher, dass diese Principals über die erforderlichen AWS KMS Berechtigungen für den Schlüssel verfügen. Sie können diese Berechtigungen über eine AWS KMS Schlüsselrichtlinie, eine auf IAM-Identität basierende Richtlinie oder eine Erteilung gewähren. AWS KMS

Diese Änderung wirkt sich nicht auf Namespaces aus, die mit dem Standardschlüssel -owned verschlüsselt sind. AWS Wenn Ihre IAM-Principals bereits über die unten aufgeführten erforderlichen AWS KMS Berechtigungen verfügen, sind keine Maßnahmen erforderlich.

Die betroffenen APIs und die erforderlichen Berechtigungen für den vom Kunden verwalteten Schlüssel des Namespaces sind unten aufgeführt:

Weitere Informationen finden Sie unter Steuern des Zugriffs auf AWS KMS Schlüssel im AWS Key Management Service Entwicklerhandbuch. Weitere Informationen zur Amazon Redshift-Datenbankverschlüsselung finden Sie unterVerschlüsselung von Amazon-Redshift-Datenbanken.

Amazon Redshift erzwingt ab Patch 204 eine Benutzersperrung nach mehreren fehlgeschlagenen Anmeldeversuchen

Ab Amazon Redshift Patch 204 sperrt Amazon Redshift zur Verbesserung der Sicherheitslage Ihres Data Warehouse automatisch einen Datenbankbenutzer, sobald die konfigurierte Anzahl aufeinanderfolgender fehlgeschlagener Anmeldeversuche überschritten wurde. Die Funktion ist standardmäßig mit einem Schwellenwert von 5 Fehlversuchen (konfigurierbar von 2 bis 50) aktiviert und gilt sowohl für bereitgestellte Cluster als auch für serverlose Arbeitsgruppen.

Dies kann sich auf Sie auswirken, wenn Sie eine Verbindung über Datenbankverbindungen (kennwortbasiert) herstellen. Einmal gesperrt, werden Anmeldeversuche auch mit dem richtigen Passwort abgewiesen, bis ein Administrator oder Superuser das Passwort entsperrt. Verbundidentitäten, die sich über IAM oder AWS IAM Identity Center authentifizieren, sind nicht betroffen, da sie kurzlebige Token anstelle von statischen Passwörtern verwenden.

Um dieses Verhalten zu verwalten:

Weitere Informationen finden Sie unter SHOW USER LOCKOUT, ALTER USER und max_failed_login_attempts. https://docs.aws.amazon.com/redshift/latest/dg/max_failed_login_attempts.html

Verbessertes Abrechnungsmodell für manuelle Snapshots auf Amazon Redshift Serverless- und Amazon Redshift RG-Instances ab dem 08. Juni 2026

Ab dem 08. Juni 2026 kündigt Amazon Redshift ein erweitertes Abrechnungsmodell für manuelle Snapshots auf Amazon Redshift Serverless- und Amazon Redshift RG-Instances an. Mit dieser Erweiterung werden manuelle Snapshots jetzt anhand eindeutiger Datenblöcke abgerechnet, die in allen aktiven manuellen Snapshots in Ihrem Konto gespeichert sind. Gemeinsam genutzte Datenblöcke, die in mehreren Snapshots vorkommen, werden nur einmal gezählt. Die Abrechnung erfolgt zu den für Ihre Region geltenden Tarifen für manuelle Snapshots.

Dies kann sich auf Sie auswirken, wenn Sie manuelle Snapshots in Amazon Redshift Serverless Workgroups oder Amazon Redshift RG-Clustern verwenden. Dies führt zu niedrigeren Kosten für manuelle Snapshots für Kunden, die mehrere Snapshots verwalten.

Es ist keine Aktion erforderlich. Das erweiterte Abrechnungsmodell gilt automatisch sowohl für bestehende als auch für neue manuelle Snapshots.

Weitere Informationen zu Snapshot-Preisen finden Sie unter Amazon Redshift-Preise.

Iceberg DELETE für Lake Formation-Tabellen erfordert ab Patch 20.2 die DELETE-Berechtigung

Ab Amazon Redshift Patch 202 benötigen Iceberg DELETE-Operationen an von Lake Formation (LF) verwalteten Tabellen die DELETE Lake Formation-Berechtigung. Für UPDATE- und MERGE-Operationen sind sowohl INSERT- als auch DELETE-Berechtigungen erforderlich. Für alle Iceberg DML-Operationen ist die ALTER-Berechtigung erforderlich.

Dies kann sich auf Sie auswirken, wenn Sie DELETE-, UPDATE- oder MERGE-Operationen für Iceberg-Tabellen ausführen, die von Lake Formation verwaltet werden. AWS

Bisher konnten Principals, die nur über die INSERT-Berechtigung (und keine DELETE-Berechtigung) verfügten, Löschvorgänge an LF-managed Iceberg-Tabellen ausführen. Ab Patch 202 benötigen DELETE-Operationen die DELETE Lake Formation-Berechtigung. Principals, die sich bei Löschvorgängen ausschließlich auf die INSERT-Berechtigung verlassen, erhalten einen Berechtigungsfehler, bis die DELETE-Berechtigung explizit erteilt wird. S3-Tabellen sind von dieser Änderung nicht betroffen.

Um nach dieser Änderung weiterhin DELETE-Operationen ausführen zu können, überprüfen Sie Ihre Lake Formation-Berechtigungen für Iceberg-Tabellen und stellen Sie sicher, dass Principals, die Löschvorgänge durchführen, die DELETE Lake Formation-Berechtigung erteilt wurde. Sie können bestehende Berechtigungen mithilfe der AWS Lake Formation-Konsole oder des aws lakeformation list-permissions AWS CLI Befehls überprüfen.

Wenn Sie vorübergehend zum vorherigen Verhalten zurückkehren müssen, wenden Sie sich an den AWS Support, um diese Änderung auf Ihrem Cluster zu deaktivieren, ohne dass eine Codebereitstellung erforderlich ist.

Weitere Informationen zu Patch-Versionen finden Sie unterCluster-Versionen für Amazon Redshift.

Amazon Redshift Serverless behält Zero-ETL- und S3-Event-Integrationen bei der Snapshot-Wiederherstellung ab Patch 202 bei

Ab Amazon Redshift Patch 202 werden Zero-ETL- und S3-Eventintegrationen, die dem Namespace und dem Punkt zugeordnet sind, automatisch beibehalten, wenn Sie einen Amazon Redshift Serverless-Namespace von einem Snapshot oder einem Recovery-Punkt in demselben serverlosen Namespace wiederherstellen. snapshot/recovery Es sind keine zusätzlichen Maßnahmen erforderlich.

Dies kann sich auf Sie auswirken, wenn Sie einen Snapshot oder einen Recovery-Punkt in Amazon Redshift Serverless-Namespaces wiederherstellen, für die Zero-ETL- oder S3-Eventintegrationen konfiguriert sind.

Bisher markierte die Wiederherstellung eines Snapshots oder Wiederherstellungspunkts in einem serverlosen Namespace die zugehörigen Zero-ETL- und S3-Event-Integrationen als fehlgeschlagen, sodass Sie sie nach Abschluss der Wiederherstellung manuell neu erstellen mussten. Ab Patch 202 werden diese Integrationen standardmäßig beibehalten und funktionieren nach Abschluss der Wiederherstellung wieder.

Diese Funktion gilt nur für Amazon Redshift Serverless, wenn sie im gleichen serverlosen Namespace wiederhergestellt wird. Beim Wiederherstellen eines Snapshots in einem anderen Namespace werden die Integrationen nicht beibehalten. Bei Snapshot-Wiederherstellungen auf bereitgestellten Clustern werden keine Zero-ETL- oder S3-Eventintegrationen beibehalten.

Um die Aufrechterhaltung von Integrationen während einer Wiederherstellung abzulehnen, deaktivieren Sie das Kontrollkästchen Integrationen verwalten auf der Wiederherstellungsseite in der. AWS-Managementkonsole Wenn Sie den verwenden, legen Sie den --no-maintain-integration Parameter fest AWS CLI, wenn Sie den API-Vorgang „Restore-From-Snapshot“ oder „Restore-From-Recovery-Point“ aufrufen. https://docs.aws.amazon.com/redshift-serverless/latest/APIReference/API_RestoreFromRecoveryPoint.html Wenn Sie sich abmelden, gehen Integrationen in den Zustand nach der Wiederherstellung über. FAILED Anschließend können Sie die fehlgeschlagenen Integrationen löschen und neu erstellen.

Weitere Informationen zu Patch-Versionen finden Sie unter. Cluster-Versionen für Amazon Redshift

Ende der Unterstützung für den Amazon Redshift ODBC 1.x-Treiber am 30. September 2026

Ab dem 30. September 2026 stellt Amazon Redshift die Unterstützung für den ODBC 1.x-Treiber ein. https://docs.aws.amazon.com/redshift/latest/mgmt/configure-odbc-connection.html Aufgrund von Kundenfeedback haben wir das ursprüngliche Datum für das Ende des Supports vom 30. Juni 2026 auf den 30. September 2026 verlängert, um zusätzliche Zeit für die Migration zu haben. Dies gilt sowohl für von Amazon Redshift bereitgestellte Cluster als auch für Serverless-Arbeitsgruppen.

Dies kann sich auf Sie auswirken, wenn Sie eine beliebige Version des ODBC 1.x-Treibers verwenden, um eine Verbindung zu Amazon Redshift herzustellen. Führen Sie die folgende Abfrage aus, um zu überprüfen, ob Sie einen ODBC 1.x-Treiber verwenden:

SELECT *
FROM SYS_CONNECTION_LOG
WHERE 
(driver_version ilike 'Amazon Redshift ODBC Driver 1%'
OR driver_version ilike 'Redshift ODBC Driver 01%'
OR driver_version ilike 'Redshift ODBC Driver 1,%'
)
OR
(application_name ilike 'Amazon Redshift ODBC Driver 1%');

Um weiterhin technischen Support für Ihre Amazon Redshift ODBC-Treiberverbindungen zu erhalten, migrieren Sie bitte vor dem 29. September 2026 auf den neuesten Amazon Redshift ODBC 2.x-Treiber.

Bevor Sie in einer Produktionsumgebung auf den ODBC 2.x-Treiber migrieren, empfehlen wir, einen gründlichen Machbarkeitsnachweis durchzuführen, um sicherzustellen, dass der neue Treiber alle Ihre funktionalen Anforderungen erfüllt.

Wir empfehlen, die neueste Version des Amazon Redshift ODBC 2.x-Treibers zu verwenden und die ApplicationName Eigenschaft so einzustellen, dass Ihre Anwendung identifiziert wird, wenn Sie eine Verbindung zu Amazon Redshift herstellen.

Skalare Python-UDFs werden nach dem 30. Juni 2026 nicht mehr unterstützt

Amazon Redshift wird die Unterstützung für Python-UDFs nach dem 30. Juni 2026 einstellen. Als Alternative empfehlen wir, Lambda-UDFs zu verwenden.

Lambda-UDFs bieten die folgenden Vorteile gegenüber Python-UDFs:

Informationen zur Erstellung und Verwendung von Lambda-UDFs finden Sie unter Scalar Lambda UDFs im Datenbankentwicklerhandbuch von Amazon Redshift. Informationen zur Konvertierung vorhandener Python-UDFs in Lambda-UDFs finden Sie im Blogbeitrag.

Auto-REFRESH Verhaltensänderung bei Materialized View (MV) nach dem 27. Februar 2026

Ab dem 27. Februar 2026 werden Auto REFRESH-Abfragen für materialisierte Amazon Redshift-Ansichten als Benutzerabfragen und nicht als autonome Hintergrundprozesse ausgeführt. Daher werden Auto REFRESH-Abfragen jetzt mit derselben Priorität wie andere Benutzerabfragen ausgeführt.

Diese Änderung verbessert die Aktualität materialisierter Ansichten, wenn Auto REFRESH aktiviert ist, sodass sie im Vergleich zum vorherigen Verhalten besser über die neuesten Änderungen an ihren Basistabellen auf dem Laufenden bleiben.

Hinweis: Die Funktion MV Auto REFRESH zur Verhaltensänderung ist nur für Amazon Redshift Provisioned Cluster auf dem CURRENT Track der Patch-Version P198 und neuer aktiviert. Sie ist derzeit auf Serverless deaktiviert.

Amazon Redshift unterstützt nach dem 16. Februar 2026 keine Funktionen mehr, die durch Datenaustausch auf Verbraucherinformationen zugreifen

Ab dem 16. Februar 2026 unterstützt Amazon Redshift die Verwendung von user_is_member_of und verwandten Funktionen, die über Datenaustausch auf Benutzer-, Rollen- oder Gruppeninformationen von Verbrauchern zugreifen, nicht mehr.

Änderungen der Mindestversion von Transport Layer Security (TLS), die ab dem 30. August 2026 in Kraft treten

Ab dem 30. August 2026 wird Amazon Redshift eine Mindestversion von Transport Layer Security (TLS) von 1.2 durchsetzen. Eingehende Verbindungen, die die TLS-Versionen 1.0 oder 1.1 verwenden, werden zurückgewiesen. Dies gilt sowohl für von Amazon Redshift bereitgestellte Cluster als auch für Serverless-Arbeitsgruppen. Data Warehouses von Amazon Redshift, die TLS nicht verwenden, sind von dieser Änderung nicht betroffen.

Dieses Update kann Auswirkungen auf Sie haben, wenn Sie die TLS-Versionen 1.0 oder 1.1 verwenden, um eine Verbindung zu Amazon Redshift herzustellen.

Um zu überprüfen, welche TLS-Version Sie derzeit verwenden, können Sie Folgendes tun:

Für Amazon Redshift Provisioned: Überprüfen Sie die Spalte sslversion in der STL_CONNECTION_LOG-Systemtabelle [1].

Für Amazon Redshift Serverless Workgroup: Überprüfen Sie die Spalte ssl_version in der SYS_CONNECTION_LOG-Systemtabelle [2].

Um den ununterbrochenen Zugriff auf Ihr Data Warehouse von Amazon Redshift nach dieser Änderung aufrechtzuerhalten, folgen Sie bitte den unten aufgeführten Schritten:

Wir empfehlen, die neueste Version des Amazon-Redshift-Treibers [3] zu verwenden, wenn dies möglich ist.

[1] https://docs.aws.amazon.com/redshift/latest/dg/r_STL_CONNECTION_LOG.html

[2] https://docs.aws.amazon.com/redshift/latest/dg/SYS_CONNECTION_LOG.html

[3] https://docs.aws.amazon.com/redshift/latest/mgmt/configuring-connections.html

Amazon Redshift unterstützt die Erstellung neuer skalarer Python-UDFs nach dem 30. Oktober 2025 nicht mehr

Amazon Redshift unterstützt die Erstellung neuer Python-UDFs nach dem 30. Oktober 2025 nicht mehr. Bestehende Python-UDFs funktionieren weiterhin normal. Wir empfehlen dringend, dass Sie Ihre vorhandenen Python-UDFs vor diesem Datum zu Lambda-UDFs migrieren.

Lambda-UDFs bieten die folgenden Vorteile gegenüber Python-UDFs:

Informationen zur Erstellung und Verwendung von Lambda-UDFs finden Sie unter Scalar Lambda UDFs im Datenbankentwicklerhandbuch von Amazon Redshift. Informationen zur Konvertierung vorhandener Python-UDFs in Lambda-UDFs finden Sie im Blogbeitrag.

Kürzlich erfolgte Verhaltensänderungen

Amazon Redshift verwendet die aktuelle IANA-Zeitzonendatenbank nach dem 26. August 2025

Ab dem 26. August 2025 berechnet Amazon Redshift Zeitzonen mithilfe der neuesten IANA-Zeitzonendatenbank-Patches. Diese Änderung ändert die Funktionsweise von Datums- und Uhrzeitumrechnungen für bestimmte Zeitzonen und Zeiträume. Dieses Update betrifft explizite Zeitzonenkonvertierungen, wie sie beispielsweise mit der Funktion CONVERT_TIMEZONE oder den Befehlen TIMEZONE und AT TIME ZONE durchgeführt werden, sowie implizite Konvertierungen, die bei Typumwandlungsvorgängen auftreten, insbesondere zwischen den Formaten TIMESTAMP und TIMESTAMPTZ.

Nachfolgend finden Sie eine Liste von Aktualisierungen für Kombinationen aus Zeitzone und Zeitraum:

Weitere Informationen zur IANA-Zeitzonendatenbank finden Sie unter Zeitzonendatenbank auf der Website der IANA-Zeitzonendatenbank.

RPU-Änderungen bei Amazon Redshift Serverless treten nach dem 15. August 2025 in Kraft

Ab dem 15. August 2025 ist das AWS Kontingent für Amazon Redshift Serverless-Basis-RPUs (Redshift Processing Units, RPUs) entweder 3.200 RPUs oder das 1,5-fache Ihrer maximalen aggregierten Basis-RPUs aus den letzten sechs Monaten je nachdem, welcher Wert höher ist.

Änderungen der Datenbank-Prüfprotokollierung treten nach dem 10. August 2025 in Kraft

Ab dem 10. August 2025 nimmt Amazon Redshift eine Änderung an der Datenbank-Prüfprotokollierung vor, die Ihr Eingreifen erfordert. Amazon Redshift protokolliert Informationen über Verbindungen und Benutzeraktivitäten in Ihrer Datenbank in Amazon S3-Buckets und. CloudWatch Nach dem 10. August 2025 wird Amazon Redshift die Datenbank-Prüfprotokollierung in Ihren Amazon-S3-Buckets einstellen, für die eine Bucket-Richtlinie gilt, die einen Redshift IAM-BENUTZER spezifiziert. Wir empfehlen, Ihre Richtlinien zu aktualisieren, um SERVICE-PRINCIPAL stattdessen Redshift innerhalb der S3-Bucket-Richtlinien für die Auditprotokollierung zu verwenden. Weitere Informationen zur Prüfprotokollierung finden Sie unter Bucket-Berechtigungen für die Amazon-Redshift-Prüfungsprotokollierung.

Um Unterbrechungen der Protokollierung zu vermeiden, überprüfen und aktualisieren Sie Ihre S3-Bucket-Richtlinien, um dem Redshift-Serviceprinzipal in der zugehörigen Region vor dem 10. August 2025 Zugriff zu gewähren. Weitere Informationen zur Datenbankprüfprotokollierung finden Sie unter Protokolldateien in Amazon S3.

Bei Fragen oder Bedenken wenden Sie sich AWS unter dem folgenden Link an den AWS Support: Support.

Änderungen an den Virtual-Private-Cloud-Endpunkten für Serverless-Arbeitsgruppen treten nach dem 27. Juni 2025 in Kraft.

Ab dem 27. Juni 2025 nimmt Amazon Redshift eine Änderung zur Unterstützung von Virtual Private Cloud Endpoint (VPCE) für Serverless-Arbeitsgruppen vor. Vor diesem Datum wurde Amazon Redshift bei der Erstellung von Arbeitsgruppen mit Endpunkten in einer einzigen Availability Zone (AZ) bereitgestellt und die VPCE-Unterstützung im Laufe der Zeit auf bis zu drei AZs erweitert. Nach diesem Datum stellt Amazon Redshift VPCEs in bis zu drei der Availability Zones bereit, die bei der Erstellung der Arbeitsgruppe angegeben wurden.

Weitere Informationen finden Sie unter Überlegungen zur Verwendung von Amazon Redshift Serverless.

Bei Fragen oder Bedenken wenden Sie sich AWS unter dem folgenden Link an den AWS Support: Support.

Änderungen bei der Abfrageüberwachung treten nach dem 2. Mai 2025 in Kraft.

Ab dem 2. Mai 2025 werden wir die Metriken „CPU-Zeit abfragen“ (max_query_cpu_time) und „CPU-Auslastung abfragen“ (max_query_cpu_percentage) auf der Registerkarte Abfragegrenzwerte nicht mehr sowohl für bestehende als auch für neu erstellte Redshift-Serverless-Arbeitsgruppen anbieten. Nach diesem Datum werden wir automatisch alle Abfragelimits, die auf diesen Metriken basieren, für alle Redshift-Serverless-Arbeitsgruppen entfernen.

Abfragegrenzwerte sind so konzipiert, dass sie außer Kontrolle geratene Abfragen abfangen. „CPU-Zeit abfragen“ (max_query_cpu_time) und „CPU-Auslastung abfragen“ (max_query_cpu_percentage) können jedoch während der Lebensdauer der Abfrage variieren und sind daher keine durchweg effektive Methode, um außer Kontrolle geratene Abfragen abzufangen. Um außer Kontrolle geratene Abfragen zu erkennen, empfehlen wir Ihnen, Metriken zur Abfrageüberwachung zu nutzen, die konsistente und umsetzbare Informationen liefern. Hier einige Beispiele:

Eine vollständige Liste der unterstützten Metriken finden Sie unter Abfrageüberwachungsmetriken für Amazon Redshift Serverless.

Sicherheitsänderungen, die nach dem 10. Januar 2025 wirksam werden

Sicherheit hat bei Amazon Web Services (AWS) oberste Priorität. Zu diesem Zweck verbessern wir die Sicherheitslage von Amazon-Redshift-Umgebungen weiter, indem wir verbesserte Sicherheitsstandards einführen, die Ihnen helfen, bewährte Verfahren für die Datensicherheit einzuhalten, ohne dass eine zusätzliche Einrichtung erforderlich ist, und das Risiko potenzieller Fehlkonfigurationen zu verringern. Um mögliche Unterbrechungen zu vermeiden, überprüfen Sie die Konfigurationen, Skripte und Tools zur Erstellung von Clustern und Serverless-Arbeitsgruppen, um vor dem Datum des Inkrafttretens die notwendigen Änderungen vorzunehmen, um sie an die neuen Standardeinstellungen anzupassen.

Standardmäßig ist der öffentliche Zugriff deaktiviert

Nach dem 10. Januar 2025 wird der öffentliche Zugriff standardmäßig für alle neu erstellten bereitgestellten Cluster und für Cluster, die aus Snapshots wiederhergestellt wurden, deaktiviert. Mit dieser Version sind Verbindungen zu Clustern standardmäßig nur von Client-Anwendungen innerhalb derselben Virtual Private Cloud (VPC) zulässig. Um über Anwendungen in einer anderen VPC auf Ihr Data Warehouse zuzugreifen, konfigurieren Sie den VPC-übergreifenden Zugriff. Diese Änderung wird sich in den Operationen der CreateCluster- und der RestoreFromClusterSnapshot-API sowie in den entsprechenden SDKs und AWS CLI -Befehlen widerspiegeln. Wenn Sie einen bereitgestellten Cluster über die Amazon-Redshift-Konsole erstellen, ist der öffentliche Zugriff für den Cluster standardmäßig deaktiviert.

Falls Sie weiterhin öffentlichen Zugriff benötigen, müssen Sie die Standardeinstellung überschreiben und den Parameter PubliclyAccessible auf „true“ setzen, wenn Sie CreateCluster- oder RestoreFromClusterSnapshot-API-Operationen ausführen. Bei einem öffentlich zugänglichen Cluster empfehlen wir, dass Sie Sicherheitsgruppen oder Network Access Control Lists (ACLs) verwenden, um den Zugriff einzuschränken. Weitere Informationen erhalten Sie unter VPC-Sicherheitsgruppen und Konfigurieren der Kommunikationseinstellungen von Sicherheitsgruppen für einen Amazon-Redshift-Cluster oder eine Amazon-Redshift-Serverless-Arbeitsgruppe.

Standardmäßige Verschlüsselung

Nach dem 10. Januar 2025 wird Amazon Redshift die Daten- und Clustersicherheit weiter verbessern, indem Verschlüsselung als Standardeinstellung für alle neu erstellten, von Amazon Redshift bereitgestellten Cluster aktiviert wird. Dies gilt nicht für Cluster, die aus Snapshots wiederhergestellt wurden.

Mit dieser Änderung ist die Möglichkeit zum Entschlüsseln von Clustern nicht mehr verfügbar, wenn Sie die AWS-Managementkonsole, oder API verwenden AWS CLI, um einen bereitgestellten Cluster ohne Angabe eines KMS-Schlüssels zu erstellen. Der Cluster wird automatisch mit einem verschlüsselt. AWS-eigener Schlüssel

Dieses Update kann sich auf Sie auswirken, wenn Sie unverschlüsselte Cluster mithilfe automatisierter Skripts erstellen oder die gemeinsame Nutzung von Daten mit unverschlüsselten Clustern nutzen. Um einen reibungslosen Übergang zu gewährleisten, aktualisieren Sie Ihre Skripts, die unverschlüsselte Cluster erstellen. Wenn Sie regelmäßig neue unverschlüsselte Verbraucher-Cluster erstellen und diese für die gemeinsame Nutzung von Daten verwenden, überprüfen Sie außerdem Ihre Konfigurationen, um sicherzustellen, dass sowohl die Produzenten- als auch die Verbraucher-Cluster verschlüsselt sind, um Unterbrechungen Ihrer Datenaustauschaktivitäten zu vermeiden. Weitere Informationen finden Sie unter Verschlüsselung von Amazon-Redshift-Datenbanken.

Erzwingen von SSL-Verbindungen

Nach dem 10. Januar 2025 wird Amazon Redshift standardmäßig SSL-Verbindungen für Clients erzwingen, die eine Verbindung zu neu erstellten, bereitgestellten und wiederhergestellten Clustern herstellen. Diese Standardänderung gilt auch für Serverless-Arbeitsgruppen.

Mit dieser Änderung wird eine neue Standardparametergruppe mit dem Namen default.redshift-2.0 für alle neu erstellten oder wiederhergestellten Cluster eingeführt, wobei der Parameter require_ssl standardmäßig auf true festgelegt ist. Alle neuen Cluster, die ohne eine angegebene Parametergruppe erstellt werden, verwenden automatisch die Parametergruppe default.redshift-2.0. Beim Erstellen eines Clusters über die Amazon-Redshift-Konsole wird die neue default.redshift-2.0-Parametergruppe automatisch ausgewählt. Diese Änderung wird sich auch in den CreateCluster und RestoreFromClusterSnapshot API-Vorgängen sowie den entsprechenden SDK und AWS CLI Befehlen widerspiegeln. Wenn Sie vorhandene oder benutzerdefinierte Parametergruppen verwenden, berücksichtigt Amazon Redshift weiterhin den in Ihrer Parametergruppe angegebenen require_ssl-Wert. Sie haben weiterhin die Möglichkeit, den require_ssl-Wert in Ihren benutzerdefinierten Parametergruppen nach Bedarf zu ändern.

Für Benutzer von Amazon Redshift Serverless wird der Standardwert von require_ssl in den config-parameters auf true geändert. Alle Anfragen zur Erstellung neuer Arbeitsgruppen mit der require_ssl-Einstellung auf false werden abgelehnt. Sie können denrequire_ssl -Wert nicht zu false ändern, nachdem die Arbeitsgruppe erstellt wurde. Weitere Informationen finden Sie unter Konfigurieren von Sicherheitsoptionen für Verbindungen.

Beachten Sie, dass Sie weiterhin die Möglichkeit haben, Cluster- oder Arbeitsgruppeneinstellungen zu ändern, um das Standardverhalten zu ändern, falls dies für Ihre speziellen Anwendungsfälle erforderlich ist.