Amazon Redshift unterstützt ab dem 1. November 2025 nicht mehr die Erstellung neuer Python-UDFs. Wenn Sie Python-UDFs verwenden möchten, erstellen Sie die UDFs vor diesem Datum. Bestehende Python-UDFs funktionieren weiterhin wie gewohnt. Weitere Informationen finden Sie im Blog-Posting.

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.

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.

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 Transport Layer Security (TLS)-Version treten am 31. Januar 2026 in Kraft.

Ab dem 31. Januar 2026 wird Amazon Redshift die minimale Transport Layer Security (TLS)-Version 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 beträgt das AWS-Kontingent für Amazon Redshift Serverless Base Redshift Processing Units (RPUs) entweder 3.200 RPUs oder das 1,5-fache Ihrer maximalen aggregierten Basis-RPUs aus den letzten sechs Monaten.

Ä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 stellen Informationen zu Verbindungen und Benutzeraktivitäten in Ihrer Datenbank in Amazon-S3-Buckets und CloudWatch bereit. 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 so zu aktualisieren, dass sie stattdessen den Redshift SERVICE-PRINCIPAL innerhalb der S3-Bucket-Richtlinien für die Prüfprotokollierung 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 unter dem folgenden Link an den AWS-Support: AWS 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 unter dem folgenden Link an den AWS-Support: AWS 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. Query CPU time (max_query_cpu_time) und Query CPU usage (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 finden 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, Cluster zu entschlüsseln, nicht mehr verfügbar, wenn Sie die AWS-Managementkonsole, die AWS CLI oder die API verwenden, um einen bereitgestellten Cluster ohne Angabe eines KMS-Schlüssels zu erstellen. Der Cluster wird automatisch mit einem AWS-eigener Schlüssel verschlüsselt.

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 Operationen der CreateCluster- und der RestoreFromClusterSnapshot-API sowie im 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.