Amazon Redshift ne prendra plus en charge l'utilisation des UDF Python après le 30 juin 2026. Nous allons commencer à l'appliquer par étapes. Pour plus d'informations sur les détails de la fin de vie et des options de migration de Python, consultez le billet de blog qui a été publié le 30 juin 2025.

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.

Améliorations apportées aux vues matérialisées (MV) Amazon Redshift à partir de la version du correctif P206

I. Améliorations apportées à l'actualisation automatique des vues matérialisées Amazon Redshift

Amélioration de l'intervalle de rafraîchissement automatique des MV

Nous introduisons une nouvelle fonctionnalité qui vous permet de configurer l'intervalle de rafraîchissement automatique d'un MV Amazon Redshift. Cela vous permet de contrôler avec précision la fréquence d'actualisation de chaque MV. L'intervalle d'actualisation est par défaut de 5 minutes. Par conséquent, vos machines virtuelles à actualisation automatique existantes peuvent être actualisées plus ou moins fréquemment en fonction de votre charge de travail. Reportez-vous à la section Actions recommandées ci-dessous pour plus de détails.

Inspection des intervalles de rafraîchissement

Vous pouvez consulter l'intervalle de rafraîchissement configuré pour vos machines virtuelles à l'aide des vues système suivantes :

Les colonnes autorefresh_interval et has_default_autorefresh_interval dans les vues du système STV_MV_INFO, SVV_MV_INFO sont autodescriptifs. Remarque : Les deux vues du système contiennent les mêmes informations. L'intervalle de rafraîchissement automatique par défaut après cette amélioration est de 5 minutes.

Actions recommandées

II. Modifications apportées à Vacuum of Amazon Redshift avec des vues matérialisées dépendantes

Voici la liste des modifications ayant un impact sur les opérations de Vacuum sur les tables de base des machines virtuelles Amazon Redshift Managed Storage (RMS) :

Actions recommandées

Amazon Redshift copie le cliché existant le plus récent lorsque la copie d'instantanés entre régions est activée après le 30 octobre 2026

Lorsque vous activez la copie d'instantanés entre régions sur un cluster ou un espace de noms sans serveur, Amazon Redshift copie désormais automatiquement les instantanés existants les plus récents, qu'il s'agisse de snapshots automatiques créés par le système ou de snapshots manuels créés par l'utilisateur, vers la destination AWS Région en quelques minutes. Auparavant, seuls les instantanés créés après l'activation étaient copiés dans la région de destination, ce qui signifiait que les clients devaient attendre le prochain instantané programmé avant de bénéficier d'une protection après sinistre dans la région de destination.

Cela peut vous affecter si vous activez la copie d'instantanés entre régions sur des clusters qui possèdent déjà des instantanés existants. L'instantané le plus récent est copié immédiatement et les frais de transfert de données entre régions commencent quelques minutes après l'activation plutôt qu'après la sauvegarde planifiée suivante.

Ce comportement s'applique à la fois aux clusters provisionnés par Amazon Redshift et à Amazon Redshift Serverless.

Aucune action n’est requise. Il s'agit d'une amélioration de la fonctionnalité existante de copie de clichés entre régions qui permet une protection plus rapide en cas de reprise après sinistre.

Le type de données SUPER prend en charge les chaînes individuelles plus grandes à partir du patch 206

À compter du patch 206, Amazon Redshift prend en charge des chaînes individuelles pouvant atteindre 16 000 000 octets dans le type de données SUPER (utilisé pour stocker des données semi-structurées). Cette limite s'applique également aux opérations sur les chaînes en mémoire. Pour utiliser cette fonctionnalité, créez un groupe de paramètres de base de données et définissez enable_large_strings_opt_in paramètre pour Yes. Associez ensuite le groupe de paramètres à votre entrepôt de données. Pour les clusters provisionnés, vous devez redémarrer le cluster pour appliquer le changement de paramètre.

Cette modification peut vous affecter si vous utilisez des types de données SUPER pour stocker des documents JSON volumineux. Cela peut également vous affecter si vos charges de travail dépendent de VARCHAR(MAX) dans des vues, des fonctions définies par l'utilisateur (UDF) ou des procédures stockées qui traitent des chaînes de plus de 65 535 octets.

Lorsque vous définissez enable_large_strings_opt_in pour Yes, résolution des opérations en mémoire VARCHAR(MAX) pour VARCHAR(16000000). Ces opérations incluent CAST, des vues, des UDF et des procédures stockées. Ils peuvent ensuite traiter des chaînes de plus de 65 535 octets. Cette modification n'affecte pas le stockage persistant des colonnes VARCHAR. CREATE TABLE avec VARCHAR(MAX) continue de créer VARCHAR(65535) colonnes. Lorsque vous définissez le paramètre sur No, Amazon Redshift préserve le comportement existant de votre entrepôt de données. Pour vérifier l'état actuel de votre entrepôt de données, exécutez SELECT is_large_string_enabled();.

Lorsque vous définissez enable_large_strings_opt_in pour Yes:

Lorsque vous définissez enable_large_strings_opt_in pour No:

Pour plus d'informations sur les versions des correctifs, consultez Versions de cluster pour Amazon Redshift.

AWS KMS application des autorisations clés pour les API Amazon Redshift Serverless après le 17 août 2026

Amazon Redshift Serverless effectue désormais un nouveau contrôle d'autorisation qui nécessite que le principal IAM appelant certaines API Amazon Redshift Serverless ait des informations explicites AWS KMS autorisations sur la clé gérée par le client qui chiffre l'espace de noms cible. Auparavant, Amazon Redshift effectuait AWS KMS opérations en votre nom à l'aide du rôle de service Amazon Redshift sans vérifier si le principal IAM appelant était lui-même autorisé à utiliser cette clé.

Une fois la nouvelle vérification d'autorisation activée, les appels d'API provenant de mandants ne disposant pas des AWS KMS les autorisations échoueront avec un ValidationException: "Insufficient KMS permissions." Cela peut vous affecter si vos espaces de noms Amazon Redshift Serverless sont chiffrés à l'aide d'une clé gérée par le client et si vous utilisez les principes IAM pour appeler les API concernées répertoriées ci-dessous.

Pour éviter toute interruption, vérifiez quels principaux IAM de vos comptes appellent les API répertoriées ci-dessous par rapport aux espaces de noms chiffrés à l'aide d'une clé gérée par le client, et assurez-vous que ces principaux disposent des AWS KMS autorisations sur la clé. Vous pouvez accorder ces autorisations par le biais d'un AWS KMS une politique clé, une politique IAM basée sur l'identité, ou AWS KMS subvention.

Cette modification n'affecte pas les espaces de noms chiffrés par défaut AWS-clé possédée. Si vos responsables IAM disposent déjà des AWS KMS autorisations répertoriées ci-dessous, aucune action n'est nécessaire.

Les API concernées et les autorisations requises sur la clé gérée par le client de l'espace de noms sont répertoriées ci-dessous :

Pour plus d'informations, voir Contrôler l'accès à AWS KMS clés dans le AWS Key Management Service Guide du développeur. Pour plus d'informations sur le chiffrement des bases de données Amazon Redshift, consultez Chiffrement de base de données Amazon Redshift.

Amazon Redshift applique le verrouillage des utilisateurs après plusieurs tentatives de connexion infructueuses, à commencer par le patch 208

À partir du patch 208 d'Amazon Redshift, afin de renforcer la sécurité de votre entrepôt de données, Amazon Redshift verrouille automatiquement un utilisateur de base de données lorsqu'il dépasse le nombre configuré de tentatives de connexion échouées consécutives. La fonctionnalité est activée par défaut avec un seuil de 5 tentatives infructueuses (configurable de 2 à 50) et s'applique à la fois aux clusters provisionnés et aux groupes de travail sans serveur.

Cela peut vous affecter si vous vous connectez à l'aide de connexions à la base de données (basées sur un mot de passe). Une fois verrouillé, les tentatives de connexion sont rejetées, même avec le mot de passe correct, jusqu'à ce qu'un administrateur ou un superutilisateur le déverrouille. Identités fédérées qui s'authentifient via IAM ou AWS IAM Identity Center n'est pas concerné, car il utilise des jetons éphémères plutôt que des mots de passe statiques.

Pour gérer ce comportement :

Pour plus d'informations, voir AFFICHER LE VERROUILLAGE DES UTILISATEURS, MODIFIER L'UTILISATEUR, et max_failed_login_attempts.

Iceberg DELETE sur les tables Lake Formation nécessite l'autorisation DELETE à partir du patch 202

À partir du patch 202 d'Amazon Redshift, les opérations Iceberg DELETE sur les tables gérées par Lake Formation (LF) nécessitent l'autorisation DELETE Lake Formation. Les opérations UPDATE et MERGE nécessitent à la fois les autorisations INSERT et DELETE. Toutes les opérations Iceberg DML nécessitent l'autorisation ALTER.

Cela peut vous affecter si vous effectuez des opérations DELETE, UPDATE ou MERGE sur des tables Iceberg gérées par AWS Formation lacustre.

Auparavant, les administrateurs ne disposant que de l'autorisation INSERT (et aucune autorisation DELETE) pouvaient effectuer des opérations de suppression sur LF-managed Tables Iceberg. À partir du patch 202, les opérations DELETE nécessitent l'autorisation DELETE Lake Formation. Les administrateurs qui s'appuient uniquement sur l'autorisation INSERT pour effectuer des suppressions recevront une erreur d'autorisation jusqu'à ce que l'autorisation DELETE soit explicitement accordée. Les tables S3 ne sont pas concernées par cette modification.

Pour continuer à effectuer des opérations DELETE après cette modification, vérifiez les autorisations que vous accordez à Lake Formation pour les tables Iceberg et assurez-vous que les personnes principales effectuant des opérations de suppression disposent de l'autorisation DELETE Lake Formation. Vous pouvez vérifier les subventions existantes à l'aide du AWS Console Lake Formation ou aws lakeformation list-permissions AWS CLI commande.

Si vous devez revenir temporairement au comportement précédent, contactez AWS Support permettant de désactiver cette modification sur votre cluster sans nécessiter de déploiement de code.

Pour plus d'informations sur les versions des correctifs, consultez Versions de cluster pour Amazon Redshift.

Amazon Redshift Serverless préserve les intégrations d'événements ETL et S3 sans aucun événement lors de la restauration des snapshots à partir du patch 202

À compter du patch 202 d'Amazon Redshift, lorsque vous restaurez un espace de noms Amazon Redshift Serverless à partir d'un snapshot ou d'un point de restauration vers le même espace de noms sans serveur, les intégrations d'événements Zero-ETL et S3 associées à l'espace de noms et snapshot/recovery les points sont maintenus automatiquement. Aucune action supplémentaire n'est requise.

Cela peut vous affecter si vous restaurez un instantané ou un point de restauration dans des espaces de noms Amazon Redshift Serverless pour lesquels aucune intégration d'événements ETL ou S3 n'est configurée.

Auparavant, la restauration d'un snapshot ou d'un point de restauration vers un espace de noms sans serveur marquait les intégrations d'événements Zero-ETL et S3 associées comme échouées, ce qui vous obligeait à les recréer manuellement une fois la restauration terminée. À partir du patch 202, ces intégrations sont maintenues par défaut et reprennent leur fonctionnement une fois la restauration terminée.

Cette fonctionnalité s'applique à Amazon Redshift Serverless uniquement lorsqu'il est restauré dans le même espace de noms sans serveur. La restauration d'un snapshot dans un autre espace de noms ne permet pas de maintenir les intégrations. Les restaurations de snapshots sur des clusters provisionnés ne permettent pas de maintenir des intégrations d'événements ETL ou S3 nulles.

Pour ne pas conserver les intégrations lors d'une restauration, décochez la case Maintenir les intégrations case sur la page de restauration dans le Console de gestion AWS. Si vous utilisez AWS CLI, réglez --no-maintain-integration paramètre lors de l'appel du restauration à partir d'un instantané ou restauration à partir d'un point de restauration Fonctionnement de l'API. Lorsque vous vous désabonnez, les intégrations entrent dans FAILED état après la restauration. Vous pouvez ensuite supprimer les intégrations ayant échoué et les recréer.

Pour plus d'informations sur les versions des correctifs, consultez Versions de cluster pour Amazon Redshift.

Fin du support pour le pilote ODBC 1.x Amazon Redshift le 31 décembre 2026

À compter du 31 décembre 2026, Amazon Redshift mettra fin à la prise en charge des pilote ODBC 1.x. Sur la base des commentaires des clients, nous avons prolongé la date de fin de support initiale du 30 septembre 2026 au 31 décembre 2026, afin de laisser plus de temps pour la migration. 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 n'importe quelle version 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 de l'assistance technique pour vos connexions au pilote ODBC Amazon Redshift, veuillez effectuer la migration vers la dernière version Pilote ODBC 2.x Amazon Redshift avant le 30 décembre 2026.

Avant de migrer vers le pilote ODBC 2.x dans un environnement de production, nous vous recommandons de réaliser une validation de concept complète 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 en réglant le ApplicationName propriété permettant d'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.

Vue matérialisée (MV) Auto-REFRESH Changement de comportement 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 s'exécutent désormais avec la même priorité que les autres requêtes utilisateur.

Cette modification améliore la fraîcheur des vues matérialisées lorsque l'option RAFRAÎCHISSEMENT automatique est activée, ce qui leur permet de rester plus au courant des dernières modifications apportées à leurs tables de base par rapport au comportement précédent.

Remarque : La fonctionnalité de modification du comportement de MV Auto REFRESH n'est activée que pour les clusters provisionnés Amazon Redshift sur la version ACTUELLE du correctif P198 et les 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.

Les modifications apportées à la version du protocole TLS (Minimum Transport Layer Security) entreront en vigueur le 31 octobre 2026

À compter du 31 octobre 2026, Amazon Redshift appliquera une version minimale de TLS (Transport Layer Security) 1.2. 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

Les instructions DDL Iceberg ne peuvent pas être exécutées dans un bloc de transactions à partir du patch 206

À partir du patch 206, Amazon Redshift prend en charge les transactions à relevés multiples sur les tables Apache Iceberg. Dans le cadre de cette modification, les instructions du langage de définition des données (DDL) Iceberg ne peuvent plus être exécutées dans un bloc de transactions. Ces déclarations incluent CREATE TABLE ... USING ICEBERG, CREATE TABLE ... USING ICEBERG AS SELECT, ALTER TABLE sur une table Iceberg, et CREATE MATERIALIZED VIEW ... USING ICEBERG. Auparavant, un bloc de transaction contenant une seule de ces instructions réussissait. Maintenant, l'instruction échoue avec une erreur telle que Iceberg DDL is not allowed in multi-statement transaction: create an "iceberg" table, et Amazon Redshift annule la transaction.

Cette modification peut vous affecter si vous exécutez une instruction Iceberg DDL de l'une des manières suivantes :

Pour éviter les erreurs, exécutez les instructions DDL Iceberg en tant qu'instructions de validation automatique autonomes. Pour plus d'informations, voir Sémantique des transactions dans le Guide du développeur de la base de données Amazon Redshift.

Amazon Redshift prend des instantanés automatisés des clusters de producteurs interrompus pour le partage de données à compter du 30 septembre 2026

À compter du 30 septembre 2026, Amazon Redshift prend des instantanés automatisés d'un cluster de producteurs de partage de données en pause. Comme les consommateurs peuvent écrire à un producteur en pause, ces instantanés capturent les écritures liées au partage de données et fournissent un point de restauration.

Cela peut vous affecter si vous interrompez le partage de données entre les clusters de producteurs.

Auparavant, Amazon Redshift ne prenait pas de captures instantanées automatiques de ces clusters lorsqu'ils étaient en pause. Par conséquent, la capture d'écran automatique la plus récente disponible pour la restauration était celle prise lors de la pause du cluster. Les instantanés automatisés continuent désormais à être créés pendant la période de pause.

Ces instantanés suivent le calendrier de capture automatique et la période de conservation existants du cluster, et aucune action n'est requise. Pour un cluster suspendu qui n'est pas un producteur de partage de données, Amazon Redshift ne prend pas de captures instantanées automatiquement pendant la pause du cluster.

Pour plus d’informations, consultez Instantanés automatiques.

Modèle de facturation amélioré pour les instantanés manuels sur les instances Amazon Redshift Serverless et Amazon Redshift RG à compter du 8 juin 2026

À compter du 8 juin 2026, Amazon Redshift annonce un modèle de facturation amélioré pour les instantanés manuels sur les instances Amazon Redshift Serverless et Amazon Redshift RG. Grâce à cette amélioration, les instantanés manuels sont désormais mesurés en fonction de blocs de données uniques stockés dans tous les instantanés manuels actifs de votre compte. Les blocs de données partagés qui apparaissent dans plusieurs instantanés ne sont comptabilisés qu'une seule fois et facturés aux tarifs de capture manuels existants pour votre région.

Cela peut vous affecter si vous utilisez des instantanés manuels sur des groupes de travail Amazon Redshift Serverless ou des clusters Amazon Redshift RG. Cela se traduit par une réduction des coûts liés aux instantanés manuels pour les clients qui gèrent plusieurs instantanés.

Aucune action n’est requise. Le modèle de facturation amélioré s'applique automatiquement aux instantanés manuels existants et nouveaux.

Pour plus d'informations sur la tarification des snapshots, consultez Tarification d'Amazon Redshift.

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 affecte les conversions de fuseaux horaires explicites, telles que celles effectuées avec CONVERT_TIMEZONE fonction ou FUSEAU HORAIRE et DANS LE FUSEAU HORAIRE commandes, ainsi que les conversions implicites qui se produisent lors des opérations de moulage de type, en particulier entre HORODATAGE et HORODATAGE formats.

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 AWS le quota de compte pour les unités de traitement Redshift de base (RPU) Amazon Redshift sans serveur est le plus élevé des deux montants suivants : 3 200 RPU ou 1,5 fois le maximum des RPU de base agrégés 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 SERVICE-PRINCIPAL au lieu de cela, dans le cadre des politiques 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 AWS support sur le lien suivant : AWS soutien.

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 plus d’informations, consultez Considérations relatives à l’utilisation d’Amazon Redshift sans serveur.

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

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 du Console de gestion AWS, AWS CLI, ou une API 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 plus d’informations, consultez 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é. Ce changement se reflétera également dans le CreateCluster et RestoreFromClusterSnapshot les opérations d'API et le SDK correspondant et AWS CLI commandes. 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 plus d’informations, consultez 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.