Amazon Redshift ne prendra plus en charge la création de nouveaux UDFs Python à partir du patch 198. Les fonctions Python définies par l’utilisateur existantes continueront de fonctionner normalement jusqu’au 30 juin 2026. Pour plus d’informations, consultez le billet de blog .

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Changements de comportement dans Amazon Redshift

Alors qu’Amazon Redshift continue d’évoluer et de s’améliorer, certains changements de comportement sont introduits afin d’améliorer les performances, la sécurité et l’expérience utilisateur. Cette page constitue une ressource complète qui vous permet de rester informé de ces mises à jour critiques, de prendre des mesures et d’éviter d’éventuelles perturbations de vos charges de travail.

Changements de comportement à venir

Ce qui suit décrit les changements de comportement à venir.

Fin du support pour le pilote ODBC 1.x Amazon Redshift le 30 juin 2026

À compter du 30 juin 2026, Amazon Redshift cessera de prendre en charge le pilote ODBC 1.x. Cela s’applique à la fois aux clusters alloués par Amazon Redshift et aux groupes de travail sans serveur.

Cela peut vous affecter si vous utilisez une version quelconque du pilote ODBC 1.x pour vous connecter à Amazon Redshift. Pour vérifier si vous utilisez un pilote ODBC 1.x, exécutez la requête suivante :

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%');

Pour continuer à bénéficier du support technique pour les connexions de vos pilotes ODBC à Amazon Redshift, veuillez effectuer la migration vers le dernier pilote ODBC 2.x d'Amazon Redshift avant le 30 juin 2026.

Avant de migrer vers le pilote ODBC 2.x dans un environnement de production, nous vous recommandons de procéder à une validation de principe approfondie afin de vérifier que le nouveau pilote répond à toutes vos exigences fonctionnelles.

Nous vous recommandons d'utiliser la dernière version du pilote ODBC 2.x Amazon Redshift et de définir la ApplicationNamepropriété pour identifier votre application lors de la connexion à Amazon Redshift.

Les fonctions scalaires Python définies par l’utilisateur ne seront plus prises en charge après le 30 juin 2026

Amazon Redshift ne prendra plus en charge les fonctions scalaires Python définies par l’utilisateur après le 30 juin 2026. En guise d’alternative, nous vous recommandons d’utiliser les fonctions Lambda définies par l’utilisateur.

Les fonctions Lambda définies par l’utilisateur présentent les avantages suivants par rapport aux fonctions Python :

Pour plus d’informations sur la création et l’utilisation des fonctions Lambda définies par l’utilisateur, consultez la section Fonctions scalaires Lambda définies par l’utilisateur dans le Guide du développeur de base de données Amazon Redshift. Pour plus d’informations sur la conversion des fonctions Python définies par l’utilisateur existantes en fonctions Lambda définies par l’utilisateur, consultez le billet de blog.

Modification du Auto-REFRESH comportement de la vue matérialisée (MV) après le 27 février 2026

À compter du 27 février 2026, les requêtes Auto REFRESH pour les vues matérialisées Amazon Redshift sont exécutées en tant que requêtes utilisateur plutôt que sous forme de processus autonomes en arrière-plan. Par conséquent, les requêtes Auto REFRESH sont désormais exécutées avec la même priorité que les autres requêtes utilisateur.

Cette modification améliore la fraîcheur des vues matérialisées grâce à l'activation de l'actualisation automatique, ce qui les aide à rester mieux informées des dernières modifications apportées à leurs tables de base par rapport au comportement précédent.

Remarque : La fonctionnalité de modification du comportement MV Auto REFRESH n'est activée que pour les clusters provisionnés Amazon Redshift sur la version ACTUELLE du correctif P198 et versions ultérieures. Il est actuellement désactivé sur Serverless.

Amazon Redshift ne prendra pas en charge les fonctions permettant d’accéder aux informations des consommateurs via l’unité de partage des données après le 16 février 2026

À compter du 16 février 2026, Amazon Redshift ne prendra plus en charge l’utilisation de user_is_member_of et des fonctions associées permettant d’accéder aux informations relatives aux utilisateurs, aux rôles ou aux groupes des consommateurs via l’unité de partage des données.

La version minimale du protocole TLS (Transport Layer Security) change à compter du 31 janvier 2026

À compter du 31 janvier 2026, Amazon Redshift appliquera la version 1.2 comme version minimale du protocole TLS (Transport Layer Security). Les connexions entrantes qui utilisent les versions 1.0 ou 1.1 du protocole TLS (Transport Layer Security) seront rejetées. Cela s’applique à la fois aux clusters alloués par Amazon Redshift et aux groupes de travail sans serveur. Les entrepôts de données Amazon Redshift n’utilisant pas le protocole TLS ne seront pas affectés par cette modification.

Cette mise à jour peut vous affecter si vous utilisez les versions TLS 1.0 ou 1.1 pour vous connecter à Amazon Redshift.

Pour vérifier la version de TLS que vous utilisez actuellement, vous pouvez :

Pour un cluster alloué Amazon Redshift : consultez la colonne sslversion dans la table système STL_CONNECTION_LOG [1].

Pour un groupe de travail Amazon Redshift sans serveur : consultez la colonne ssl_version dans la table système SYS_CONNECTION_LOG [2].

Pour conserver un accès ininterrompu à votre entrepôt de données Amazon Redshift après cette modification, veuillez suivre les étapes ci-dessous :

Dans la mesure du possible, nous vous recommandons d’utiliser la dernière version du pilote Amazon Redshift [3].

[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 ne prendra pas en charge la création de nouvelles fonctions scalaires Python définies par l’utilisateur après le 30 octobre 2025

Amazon Redshift ne prendra plus en charge la création de nouvelles fonctions Python définies par l’utilisateur après le 30 octobre 2025. Les fonctions Python définies par l’utilisateur existantes continueront de fonctionner normalement. Nous vous recommandons fortement de migrer vos fonctions Python définies par l’utilisateur existantes vers des fonctions Lambda définies par l’utilisateur avant cette date.

Les fonctions Lambda définies par l’utilisateur présentent les avantages suivants par rapport aux fonctions Python :

Pour plus d’informations sur la création et l’utilisation des fonctions Lambda définies par l’utilisateur, consultez la section Fonctions scalaires Lambda définies par l’utilisateur dans le Guide du développeur de base de données Amazon Redshift. Pour plus d’informations sur la conversion des fonctions Python définies par l’utilisateur existantes en fonctions Lambda définies par l’utilisateur, consultez le billet de blog.

Changements de comportement récents

Amazon Redshift utilise la base de données de fuseaux horaires IANA à jour après le 26 août 2025

À compter du 26 août 2025, Amazon Redshift calcule les fuseaux horaires en adoptant les derniers correctifs de la base de données des fuseaux horaires de l’IANA. Cette modification modifie le fonctionnement des conversions de date et d’heure pour certains fuseaux horaires et certaines périodes. Cette mise à jour concerne les conversions de fuseaux horaires explicites, telles que celles effectuées avec la fonction CONVERT_TIMEZONE ou les commandes TIMEZONE et AT TIME ZONE, ainsi que les conversions implicites qui se produisent lors des opérations de changement de type, en particulier entre les formats TIMESTAMP et TIMESTAMPTZ.

Voici une liste des mises à jour pour les combinaisons de fuseaux horaires et de périodes :

Pour plus d’informations sur la base de données des fuseaux horaires de l’IANA, consultez Base de données des fuseaux horaires sur le site Web de la base de données des fuseaux horaires de l’IANA.

Les modifications apportées aux unités de traitement Redshift (RPU) Amazon Redshift sans serveur entreront en vigueur après le 15 août 2025

À compter du 15 août 2025, le quota de AWS comptes pour les unités de traitement Redshift de base (RPU) Amazon Redshift sans serveur est égal à 3 200 RPU ou à 1,5 fois le maximum des RPU de base agrégées des six mois précédents.

Modifications apportées à la journalisation des audits de base de données en vigueur après le 10 août 2025

À compter du 10 août 2025, Amazon Redshift apporte une modification à la journalisation des audits de base de données, ce qui nécessite votre intervention. Amazon Redshift enregistre les informations relatives aux connexions et aux activités des utilisateurs dans votre base de données dans des compartiments Amazon S3 et. CloudWatch Après le 10 août 2025, Amazon Redshift cessera de consigner les audits de base de données dans vos compartiments Amazon S3 dotés d’une stratégie de compartiment spécifiant un utilisateur Redshift IAM. Nous vous recommandons de mettre à jour vos politiques pour utiliser le Redshift à la SERVICE-PRINCIPAL place, dans le cadre des politiques du compartiment S3 pour la journalisation des audits. Pour plus d’informations sur la journalisation, consultez Autorisations du compartiment pour la journalisation des audits Amazon Redshift.

Pour éviter toute interruption de journalisation, passez en revue et mettez à jour vos stratégies relatives aux compartiments S3 afin d’accorder l’accès au principal de service Redshift dans la région associée avant le 10 août 2025. Pour plus d’informations sur la journalisation des audits de base de données, consultez Fichiers journaux dans Amazon S3.

Pour toute question ou préoccupation, contactez le AWS support via le lien suivant : AWS Support.

Modifications apportées au point de terminaison du cloud privé virtuel pour les groupes de travail sans serveur à compter du 27 juin 2025

À compter du 27 juin 2025, Amazon Redshift apporte une modification à la prise en charge des points de terminaison du cloud privé virtuel (VPCE) pour les groupes de travail sans serveur. Avant cette date, Amazon Redshift se déploie avec des points de terminaison dans une seule zone de disponibilité (AZ) lors de la création du groupe de travail, et étend la prise en charge des points de terminaison du cloud privé virtuel (VPCE) jusqu’à trois zones de disponibilité au fil du temps. Après cette date, Amazon Redshift déploie les points de terminaison du cloud privé virtuel (VPCE) dans un maximum de trois des zones de disponibilité spécifiées lors de la création du groupe de travail.

Pour de plus amples informations, veuillez consulter Considérations relatives à l’utilisation d’Amazon Redshift sans serveur.

Pour toute question ou préoccupation, contactez le AWS support via le lien suivant : AWS Support.

Les modifications apportées à la surveillance des requêtes entreront en vigueur après le 2 mai 2025

À compter du 2 mai 2025, nous ne proposerons plus les métriques Temps UC de la requête (max_query_cpu_time) et Utilisation UC de la requête (max_query_cpu_percentage) dans l’onglet Limites de requête pour les groupes de travail Redshift sans serveur existants et nouvellement créés. Après cette date, nous supprimerons automatiquement toutes les limites de requête basées sur ces métriques dans tous les groupes de travail Redshift sans serveur.

Les limites de requête sont conçues pour intercepter les requêtes intempestives. Cependant, le temps UC de la requête (max_query_cpu_time) et l’utilisation UC de la requête (max_query_cpu_percentage) peuvent varier au cours de la durée de vie de la requête et ne constituent donc pas une méthode toujours efficace pour intercepter les requêtes intempestives. Pour détecter les requêtes intempestives, nous vous recommandons de tirer parti des métriques de surveillance des requêtes qui fournissent des informations cohérentes et exploitables. Voici quelques exemples :

Pour obtenir la liste complète des métriques prises en charge, consultez Métriques de surveillance des requêtes pour Amazon Redshift sans serveur.

Changements de sécurité en vigueur après le 10 janvier 2025

Chez Amazon Web Services (AWS), la sécurité est notre priorité principale. À cette fin, nous renforçons encore le niveau de sécurité des environnements Amazon Redshift en introduisant des paramètres de sécurité améliorés qui vous aident à respecter les bonnes pratiques en matière de sécurité des données sans nécessiter de configuration supplémentaire et à réduire le risque de mauvaise configuration. Pour éviter toute interruption potentielle, passez en revue les configurations, les scripts et les outils de création de clusters alloués et de groupes de travail sans serveur afin d’apporter les modifications nécessaires et les aligner sur les nouveaux paramètres par défaut avant la date d’entrée en vigueur.

Accès public désactivé par défaut

Après le 10 janvier 2025, l’accessibilité publique sera désactivée par défaut pour tous les clusters alloués nouvellement créés et pour les clusters restaurés à partir d’instantanés. Dans cette version, par défaut, les connexions aux clusters ne seront autorisées qu’à partir d’applications clientes au sein d’un même cloud privé virtuel (VPC). Pour accéder à votre entrepôt de données depuis les applications d’un autre VPC, configurez l’accès inter-VPC. Cette modification se reflétera dans les opérations d’API CreateCluster et RestoreFromClusterSnapshot, ainsi que dans les commandes SDK et AWS CLI correspondantes. Si vous créez un cluster alloué à partir de la console Amazon Redshift, l’accès public au cluster est désactivé par défaut.

Si vous avez toujours besoin d’un accès public, vous devrez remplacer la valeur par défaut et définir le paramètre PubliclyAccessible sur true lorsque vous exécutez des opérations d’API CreateCluster ou RestoreFromClusterSnapshot. Dans le cas d’un cluster publiquement accessible, nous vous recommandons d’utiliser des groupes de sécurité ou des listes de contrôle d’accès (ACL) réseau pour restreindre l’accès. Pour plus d’informations, consultez Groupes de sécurité VPC et Configuration des paramètres de communication des groupes de sécurité pour un cluster Amazon Redshift ou un groupe de travail Amazon Redshift sans serveur.

Chiffrement par défaut

Après le 10 janvier 2025, Amazon Redshift améliorera encore la sécurité des données et des clusters en activant le chiffrement comme paramètre par défaut pour tous les clusters alloués Amazon Redshift nouvellement créés. Cela ne s’applique pas aux clusters restaurés à partir d’instantanés.

Avec cette modification, la possibilité de déchiffrer les clusters ne sera plus disponible lors de l'utilisation de l'API AWS Management Console AWS CLI, ou pour créer un cluster provisionné sans spécifier de clé KMS. Le cluster sera automatiquement chiffré avec un Clé détenue par AWS.

Cette mise à jour peut avoir un impact sur vous si vous créez des clusters non chiffrés à l’aide de scripts automatisés ou si vous exploitez le partage de données avec des clusters non chiffrés. Pour garantir une transition fluide, mettez à jour vos scripts qui créent des clusters non chiffrés. En outre, si vous créez régulièrement de nouveaux clusters de consommateurs non chiffrés et que vous les utilisez pour le partage de données, revoyez vos configurations pour vous assurer que les clusters de producteurs et de consommateurs sont tous deux chiffrés, afin d’éviter toute interruption de vos activités de partage de données. Pour de plus amples informations, veuillez consulter Chiffrement de base de données Amazon Redshift.

Application des connexions SSL

Après le 10 janvier 2025, Amazon Redshift appliquera les connexions SSL par défaut pour les clients se connectant à des clusters alloués et restaurés récemment créés. Cette modification par défaut s’appliquera également aux groupes de travail sans serveur.

Avec cette modification, un nouveau groupe de paramètres par défaut nommé default.redshift-2.0 sera introduit pour tous les clusters nouvellement créés ou restaurés, le paramètre require_ssl étant défini sur true par défaut. Tout nouveau cluster créé sans groupe de paramètres spécifié utilisera automatiquement le groupe de paramètres default.redshift-2.0. Lors de la création d’un cluster via la console Amazon Redshift, le nouveau groupe de paramètres default.redshift-2.0 est automatiquement sélectionné. Cette modification se reflétera également dans les opérations de RestoreFromClusterSnapshot l'API CreateCluster et dans le SDK et AWS CLI les commandes correspondants. Si vous utilisez des groupes de paramètres existants ou personnalisés, Amazon Redshift continuera à respecter la valeur require_ssl spécifiée dans votre groupe de paramètres. Vous avez toujours la possibilité de modifier la valeur require_ssl de vos groupes de paramètres personnalisés selon vos besoins.

Pour les utilisateurs d’Amazon Redshift sans serveur, la valeur par défaut de require_ssl dans les config-parameters sera remplacée par true. Toute demande de création de nouveaux groupes de travail avec la valeur require_ssl définie sur false sera rejetée. Vous pouvez modifier la valeur require_ssl sur false après la création du groupe de travail. Pour de plus amples informations, veuillez consulter Configuration des options de sécurité des connexions.

Notez que vous aurez toujours la possibilité de modifier les paramètres du cluster ou du groupe de travail pour modifier le comportement par défaut, si cela s’avère nécessaire pour vos cas d’utilisation spécifiques.