Changements de comportement dans Amazon Redshift - Amazon Redshift
Changements de comportement à venirChangements de comportement récents

Amazon Redshift ne prendra plus en charge la création de nouveaux Python UDFs à compter du 1er novembre 2025. Si vous souhaitez utiliser Python UDFs, créez la version UDFs antérieure à cette date. Le Python existant UDFs continuera à fonctionner normalement. 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.

Scalar Python UDFs atteindra la fin du support après le 30 juin 2026

Amazon Redshift mettra fin à la prise en charge de Python UDFs après le 30 juin 2026. Comme alternative, nous vous recommandons d'utiliser Lambda UDFs.

Lambda présente UDFs les avantages suivants par rapport à Python : UDFs

  • Lambda UDFs peut se connecter à des services externes et APIs depuis la logique UDF.

  • Lambda utilise les ressources de UDFs calcul Lambda. Lambda, qui consomme beaucoup de calcul ou de mémoire, UDFs n'a aucun impact sur les performances des requêtes d'Amazon Redshift ni sur la simultanéité des ressources.

  • Lambda UDFs supporte l'exécution de code Python. Lambda UDFs prend en charge plusieurs environnements d'exécution Python en fonction des cas d'utilisation spécifiques. Pour plus d’informations, consultez Création avec Python dans le Guide du développeur AWS Lambda.

  • Vous pouvez isoler l’exécution de code personnalisé dans une limite de service distincte. Cela simplifie la maintenance, la surveillance, la budgétisation et la gestion des autorisations.

Pour plus d'informations sur la création et l'utilisation de Lambda UDFs, consultez Scalar UDFs Lambda dans le manuel Amazon Redshift Database Developer Guide. Pour plus d'informations sur la conversion de Python existant UDFs en Lambda UDFs, consultez le billet de blog.

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 :

  1. Mettez à jour votre client pour prendre en charge le protocole TLS 1.2 ou une version ultérieure

  2. Installer la dernière version de pilote avec prise en charge du protocole TLS 1.2+

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 d'un nouveau UDFs Python scalaire après le 30 octobre 2025

Amazon Redshift ne prendra plus en charge la création de nouveaux Python UDFs après le 30 octobre 2025. Le Python existant UDFs continuera à fonctionner normalement. Nous vous recommandons vivement de migrer votre Python existant UDFs vers Lambda UDFs avant cette date.

Lambda présente UDFs les avantages suivants par rapport à Python : UDFs

  • Lambda UDFs peut se connecter à des services externes et APIs depuis la logique UDF.

  • Lambda utilise les ressources de UDFs calcul Lambda. Lambda, qui consomme beaucoup de calcul ou de mémoire, UDFs n'a aucun impact sur les performances des requêtes d'Amazon Redshift ni sur la simultanéité des ressources.

  • Lambda UDFs supporte l'exécution de code Python. Lambda UDFs prend en charge plusieurs environnements d'exécution Python en fonction des cas d'utilisation spécifiques. Pour plus d’informations, consultez Création avec Python dans le Guide du développeur AWS Lambda.

  • Vous pouvez isoler l’exécution de code personnalisé dans une limite de service distincte. Cela simplifie la maintenance, la surveillance, la budgétisation et la gestion des autorisations.

Pour plus d'informations sur la création et l'utilisation de Lambda UDFs, consultez Scalar UDFs Lambda dans le manuel Amazon Redshift Database Developer Guide. Pour plus d'informations sur la conversion de Python existant UDFs en Lambda UDFs, consultez le billet de blog.

Changements de comportement récents

Amazon Redshift utilise la base de données de fuseaux horaires de l' up-to-dateIANA 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 :

  • Les fuseaux horaires respectent désormais correctement l’heure d’été (DST) après 2038. Auparavant, aucun fuseau horaire n’était observé après 2038.

  • Le fuseau horaire America/Toronto, et les fuseaux horaires qui y sont liés, changent pour l’heure d’été en 1947-1950 à 2 heures du matin, heure locale, au lieu de minuit.

  • Amazon Redshift reflète désormais correctement l’heure moyenne locale (LMT) pour les périodes avant la standardisation pour tous les fuseaux horaires. Cette période est spécifique à un fuseau horaire, la plupart des fuseaux horaires passant à la normalisation avant le milieu du XIXe siècle.

  • EET, CET, WET et MET sont désormais traités comme des fuseaux horaires normaux plutôt que comme des abréviations.

  • Les noms de fuseaux horaires suivants n’existent plus dans Amazon Redshift :

    • Asia/Riyadh87

    • Asia/Riyadh88

    • Asia/Riyadh89

    • Mideast/Riyadh87

    • Mideast/Riyadh88

    • Mideast/Riyadh89

    • US/Pacific-New

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 Amazon Redshift sans serveur (RPUs) est égal à 3 200 RPUs ou 1,5 fois le plus élevé de votre base RPUs agrégée maximale 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 stratégies pour utiliser plutôt Redshift SERVICE-PRINCIPAL, dans les stratégies de 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 : AWSSupport.

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 le support VPCE jusqu'à trois au fil du temps. AZs Après cette date, Amazon Redshift se déploie VPCEs 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 : AWSSupport.

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 :

  • Durée d’exécution des requêtes (max_query_execution_time) : pour garantir que les requêtes sont terminées dans les délais prévus.

  • Nombre de lignes renvoyées (max_scan_row_count) : pour surveiller l’échelle des données traitées.

  • Durée de la file d’attente des requêtes (max_query_queue_time) : pour identifier les requêtes qui passent du temps à dans la file d’attente.

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 accessible au public, nous vous recommandons d'utiliser des groupes de sécurité ou des listes de contrôle d'accès réseau (ACLs) 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 ConsoleAWS CLI, ou pour créer un cluster provisionné sans spécifier de clé KMS. Le cluster sera automatiquement chiffré avec unClé 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.