Modifiche del comportamento in Amazon Redshift - Amazon Redshift
Prossime modifiche del comportamentoModifiche recenti del comportamento

Amazon Redshift non supporterà più la creazione di nuove UDF Python a partire dal 1º novembre 2025. Se desideri utilizzare le UDF Python, creale prima di tale data. Le UDF Python esistenti continueranno a funzionare normalmente. Per ulteriori informazioni, consulta il post del blog.

Modifiche del comportamento in Amazon Redshift

Man mano che Amazon Redshift continua a evolversi e migliorare, vengono introdotte alcune modifiche del comportamento per ottimizzare le prestazioni, la sicurezza e l’esperienza utente. Questa pagina è una risorsa completa per rimanere al corrente su questi aggiornamenti critici, intraprendere azioni ed evitare potenziali interruzioni dei carichi di lavoro.

Prossime modifiche del comportamento

Di seguito vengono descritte le prossime modifiche del comportamento.

Le UDF Python scalari non saranno più supportate dopo il 30 giugno 2026

Amazon Redshift terminerà il supporto delle UDF Python dopo il 30 giugno 2026. In alternativa consigliamo di utilizzare le UDF Lambda.

Le UDF Lambda presentano i vantaggi seguenti rispetto alle UDF Python:

  • Le UDF Lambda possono connettersi ad API e servizi esterni dall’interno della logica UDF.

  • Le UDF Lambda utilizzano risorse di calcolo Lambda. Le UDF Lambda a uso intensivo di calcolo o memoria non influiscono sulle prestazioni delle query o sulla simultaneità delle risorse di Amazon Redshift.

  • Le UDF Lambda supportano l’esecuzione di codice Python. Le UDF Lambda supportano più runtime Python a seconda dei casi d’uso specifici. Per ulteriori informazioni, consulta Compilazione con Python nella Guida per gli sviluppatori di AWS Lambda.

  • Puoi isolare l’esecuzione di codice personalizzato in un limite di servizio separato. Ciò semplifica la manutenzione, il monitoraggio, la definizione del budget e la gestione delle autorizzazioni.

Per informazioni sulla creazione e sull’utilizzo di UDF Lambda, consulta UDF Lambda scalari nella Guida per sviluppatori di database di Amazon Redshift Database. Per informazioni sulla conversione delle UDF Python esistenti in UDF Lambda, consulta il post del blog.

Amazon Redshift non supporterà le funzioni che accedono alle informazioni sui consumer tramite la condivisione dei dati dopo il 16 febbraio 2026

A partire dal 16 febbraio 2026, Amazon Redshift non supporterà più l’utilizzo di user_is_member_of e delle funzioni correlate che accedono alle informazioni su utenti, ruoli o gruppi consumer tramite la condivisione dei dati.

Modifiche alla versione minima del protocollo Transport Layer Security (TLS) in vigore dal 31 gennaio 2026

A partire dal 31 gennaio 2026, Amazon Redshift applicherà la versione minima del protocollo Transport Layer Security (TLS) 1.2. Le connessioni in entrata che utilizzano TLS versione 1.0 o 1.1 verranno rifiutate. Ciò vale sia per i cluster con provisioning Amazon Redshift che per i gruppi di lavoro serverless. I data warehouse Amazon Redshift che non utilizzano TLS non saranno interessati da questa modifica.

Questo aggiornamento potrebbe influire su di te se utilizzi TLS versione 1.0 o 1.1 per connetterti ad Amazon Redshift.

Per verificare quale versione di TLS stai utilizzando attualmente, puoi:

Per Amazon Redshift con provisioning: controlla la colonna sslversion nella tabella di sistema STL_CONNECTION_LOG [1].

Per il gruppo di lavoro Amazon Redshift serverless: controlla la colonna ssl_version nella tabella di sistema SYS_CONNECTION_LOG [2].

Per mantenere l’accesso ininterrotto al data warehouse Amazon Redshift dopo questa modifica, segui la procedura descritta:

  1. Aggiorna il client per supportare TLS 1.2 o versione successiva

  2. Installa la versione più recente del driver con il supporto di TLS 1.2 o versione successiva

Consigliamo di utilizzare la versione più recente del driver Amazon Redshift [3], se possibile.

[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 non supporterà la creazione di nuove UDF Python scalari dopo il 30 ottobre 2025

Amazon Redshift non supporterà più la creazione di nuove UDF Python dopo il 30 ottobre 2025. Le UDF Python esistenti continueranno a funzionare normalmente. Consigliamo vivamente di migrare le UDF Python esistenti nelle UDF Lambda prima di tale data.

Le UDF Lambda presentano i vantaggi seguenti rispetto alle UDF Python:

  • Le UDF Lambda possono connettersi ad API e servizi esterni dall’interno della logica UDF.

  • Le UDF Lambda utilizzano risorse di calcolo Lambda. Le UDF Lambda a uso intensivo di calcolo o memoria non influiscono sulle prestazioni delle query o sulla simultaneità delle risorse di Amazon Redshift.

  • Le UDF Lambda supportano l’esecuzione di codice Python. Le UDF Lambda supportano più runtime Python a seconda dei casi d’uso specifici. Per ulteriori informazioni, consulta Compilazione con Python nella Guida per gli sviluppatori di AWS Lambda.

  • Puoi isolare l’esecuzione di codice personalizzato in un limite di servizio separato. Ciò semplifica la manutenzione, il monitoraggio, la definizione del budget e la gestione delle autorizzazioni.

Per informazioni sulla creazione e sull’utilizzo di UDF Lambda, consulta UDF Lambda scalari nella Guida per sviluppatori di database di Amazon Redshift Database. Per informazioni sulla conversione delle UDF Python esistenti in UDF Lambda, consulta il post del blog.

Modifiche recenti del comportamento

Amazon Redshift utilizza il database dei fusi orari di IANA aggiornato dopo il 26 agosto 2025

A partire dal 26 agosto 2025, Amazon Redshift calcola i fusi orari adottando le ultime patch del database dei fusi orari di IANA. Questa modifica cambia il funzionamento delle conversioni di data e ora per determinati fusi orari e periodi di tempo. Questo aggiornamento influisce sulle conversioni esplicite di fuso orario, come quelle eseguite con la funzione CONVERT_TIMEZONE o i comandi TIMEZONE e AT TIME ZONE, nonché sulle conversioni implicite che si verificano durante le operazioni di casting del tipo, in particolare tra i formati TIMESTAMP e TIMESTAMPTZ.

Di seguito è riportato un elenco di aggiornamenti per le combinazioni di fuso orario e periodo di tempo:

  • I fusi orari ora rispettano correttamente l’ora legale dopo il 2038. In precedenza, dopo il 2038 nessun fuso orario avrebbe osservato l’ora legale.

  • Il fuso orario America/Toronto e i fusi orari a esso collegati hanno cambiato l’ora legale nel 1947-1950 alle ore 2:00 locali anziché a mezzanotte.

  • Amazon Redshift ora riflette correttamente l’ora media locale per i periodi precedenti alla standardizzazione per tutti i fusi orari. Questo periodo è specifico per un fuso orario e la maggior parte dei fusi orari passa alla standardizzazione prima della metà del XIX secolo.

  • EET, CET, WET e MET vengono ora considerati fusi orari normali anziché abbreviazioni.

  • I seguenti nomi di fusi orari non esistono più in Amazon Redshift:

    • Asia/Riyadh87

    • Asia/Riyadh88

    • Asia/Riyadh89

    • Mideast/Riyadh87

    • Mideast/Riyadh88

    • Mideast/Riyadh89

    • US/Pacific-New

Per ulteriori informazioni sul database dei fusi orari di IANA, consulta Time Zone Database sul sito web di IANA.

Modifiche delle RPU di Amazon Redshift serverless in vigore dopo il 15 agosto 2025

A partire dal 15 agosto 2025, la quota dell’account AWS per le unità di elaborazione Redshift (RPU) di base di Amazon Redshift serverless è la maggiore tra 3.200 RPU o 1,5 volte il numero massimo di RPU di base aggregate dei sei mesi precedenti.

Le modifiche della registrazione di log di audit dei database entreranno in vigore dopo il 10 agosto 2025

A partire dal 10 agosto 2025, Amazon Redshift apporterà una modifica alla registrazione di log di audit dei database, che richiede il tuo intervento. Amazon Redshift registra log di informazioni sulle connessioni e sulle attività degli utenti nel database nei bucket Amazon S3 e in CloudWatch. Dopo il 10 agosto 2025, Amazon Redshift interromperà la registrazione di log di audit dei database nei bucket Amazon S3 che dispongono di una policy di bucket che specifica un UTENTE IAM Redshift. Consigliamo di aggiornare le policy per utilizzare invece il PRINCIPALE DEL SERVIZIO Redshift, all’interno delle policy di bucket S3 per la registrazione di log di audit. Per ulteriori informazioni sulla registrazione di log di audit, consulta Autorizzazioni del bucket per la registrazione di verifica di Amazon Redshift.

Per evitare interruzioni della registrazione, esamina e aggiorna le policy di bucket S3 per concedere l’accesso al principale del servizio di Redshift nella Regione associata prima del 10 agosto 2025. Per ulteriori informazioni sulla registrazione di log di audit dei database, consulta File di log in Amazon S3.

Per domande o dubbi, contatta l’assistenza di AWS al seguente link: Supporto di AWS.

Modifiche degli endpoint del cloud privato virtuale per i gruppi di lavoro serverless in vigore dopo il 27 giugno 2025

A partire dal 27 giugno 2025, Amazon Redshift apporterà una modifica al supporto degli endpoint del cloud privato virtuale (VPCE) per gruppi di lavoro serverless. Prima di questa data, Amazon Redshift viene implementato con gli endpoint in un’unica zona di disponibilità (AZ) durante la creazione di gruppi di lavoro ed espande il supporto VPCE fino a tre AZ nel tempo. Dopo tale data, Amazon Redshift distribuisce VPCE in un massimo di tre delle zone di disponibilità specificate durante la creazione dei gruppi di lavoro.

Per ulteriori informazioni, consulta Considerazioni su quando utilizzare Amazon Redshift Serverless.

Per domande o dubbi, contatta l’assistenza di AWS al seguente link: Supporto di AWS.

Modifiche del monitoraggio delle query in vigore dopo il 2 maggio 2025

A partire dal 2 maggio 2025 non offriremo più le metriche Tempo di CPU delle query (max_query_cpu_time) e Utilizzo di CPU delle query (max_query_cpu_percentage) della scheda Limiti delle query per i gruppi di lavoro Redshift serverless esistenti e quelli appena creati. Dopo tale data rimuoveremo automaticamente tutti i limiti di query basati su queste metriche in tutti i gruppi di lavoro Redshift serverless.

I limiti delle query sono progettati per catturare le query con un eccessivo tempo di esecuzione. Tuttavia Tempo di CPU delle query (max_query_cpu_time) e Utilizzo di CPU delle query (max_query_cpu_percentage) possono variare durante la durata della query e non sono quindi un metodo sempre efficace per catturare le query con un eccessivo tempo di esecuzione. Per catturare le query con un eccessivo tempo di esecuzione, consigliamo di sfruttare le metriche di monitoraggio delle query che forniscono informazioni coerenti e fruibili. Alcuni esempi includono:

  • Tempo di esecuzione delle query (max_query_execution_time): per garantire che le query vengano completate entro i tempi previsti.

  • Numero di righe restituite (max_scan_row_count): per monitorare la scala dei dati in fase di elaborazione.

  • Tempo di coda delle query (max_query_queue_time): per identificare le query che trascorrono tempo in coda.

Per un elenco completo delle metriche supportate, consulta Metriche di monitoraggio delle query per Amazon Redshift serverless.

Modifiche della sicurezza in vigore dopo il 10 gennaio 2025

La sicurezza è la massima priorità in Amazon Web Services (AWS). A tal fine stiamo rafforzando ulteriormente la postura di sicurezza degli ambienti Amazon Redshift introducendo impostazioni di sicurezza predefinite avanzate che ti aiutano a rispettare le best practice in materia di sicurezza dei dati senza richiedere configurazioni aggiuntive e a ridurre il rischio di potenziali errori di configurazione. Per evitare potenziali interruzioni, esamina le configurazioni, gli script e gli strumenti per la creazione di cluster con provisioning e gruppi di lavoro serverless e apporta le modifiche necessarie per allinearli alle nuove impostazioni predefinite prima della data di entrata in vigore.

Accesso pubblico disabilitato per impostazione predefinita

Dopo il 10 gennaio 2025, l’accessibilità pubblica sarà disabilitata per impostazione predefinita per tutti i cluster con provisioning appena creati e per i cluster ripristinati dagli snapshot. Con questa versione, per impostazione predefinita, le connessioni ai cluster saranno consentite solo dalle applicazioni client all’interno dello stesso cloud privato virtuale (VPC). Per accedere al data warehouse dalle applicazioni in un altro VPC, configura l’accesso tra VPC. Questa modifica si rifletterà nelle operazioni API CreateCluster e RestoreFromClusterSnapshot, nonché nell’SDK e nei comandi AWS CLI corrispondenti. Se crei un cluster con provisioning dalla console Amazon Redshift, l’accesso pubblico al cluster è disabilitato per impostazione predefinita.

Se hai ancora bisogno dell’accesso pubblico, devi sovrascrivere l’impostazione predefinita e impostare il parametro PubliclyAccessible su true quando esegui le operazioni API CreateCluster o RestoreFromClusterSnapshot. Con un cluster accessibile pubblicamente, consigliamo di utilizzare gruppi di sicurezza o le liste di controllo degli accessi (ACL) alla rete per limitare l’accesso. Per ulteriori informazioni, consulta Gruppi di sicurezza VPC e Configurazione delle impostazioni di comunicazione dei gruppi di sicurezza per i cluster Amazon Redshift o per un gruppo di lavoro di Amazon Redshift serverless.

Crittografia per impostazione predefinita

Dopo il 10 gennaio 2025, Amazon Redshift migliorerà ulteriormente la sicurezza dei dati e dei cluster abilitando la crittografia come impostazione predefinita per tutti i cluster con provisioning Amazon Redshift appena creati. Ciò non si applica ai cluster ripristinati da snapshot.

Con questa modifica, la capacità di decrittografare i cluster non sarà più disponibile quando utilizzi la Console di gestione AWS, AWS CLI o l’API per creare un cluster con provisioning senza specificare una chiave KMS. Il cluster verrà automaticamente crittografato con Chiave di proprietà di AWS.

Questo aggiornamento potrebbe influire su di te se stai creando cluster non crittografati utilizzando script automatici o sfruttando la condivisione dei dati con cluster non crittografati. Per garantire una transizione lineare, aggiorna gli script che creano cluster non crittografati. Inoltre, se crei regolarmente nuovi cluster consumer non crittografati e li utilizzi per la condivisione dei dati, esamina le configurazioni per assicurarti che i cluster producer e consumer siano entrambi crittografati, evitando interruzioni delle attività di condivisione dei dati. Per ulteriori informazioni, consulta Crittografia dei database di Amazon Redshift.

Applicazione delle connessioni SSL

Dopo il 10 gennaio 2025, Amazon Redshift applicherà per impostazione predefinita le connessioni SSL per i client che si connettono a cluster con provisioning appena creati e ripristinati. Questa modifica predefinita si applicherà anche ai gruppi di lavoro serverless.

Con questa modifica verrà introdotto un nuovo gruppo di parametri predefinito denominato default.redshift-2.0 per tutti i cluster appena creati o ripristinati, con il parametro require_ssl impostato su true di default. Tutti i nuovi cluster creati senza un gruppo di parametri specificato utilizzeranno automaticamente il gruppo di parametri default.redshift-2.0. Quando crei un cluster tramite la console Amazon Redshift, il nuovo gruppo di parametri default.redshift-2.0 viene selezionato automaticamente. Questa modifica si rifletterà anche nelle operazioni API CreateCluster e RestoreFromClusterSnapshot, nonché nell’SDK e nei comandi AWS CLI corrispondenti. Se utilizzi gruppi di parametri esistenti o personalizzati, Amazon Redshift continua a rispettare il valore require_ssl specificato nel gruppo di parametri. Continui ad avere la possibilità di modificare il valore require_ssl nei gruppi di parametri personalizzati in base alle esigenze.

Per gli utenti di Amazon Redshift serverless, il valore predefinito di require_ssl in config-parameters viene modificato e impostato su true. Qualsiasi richiesta di creazione di nuovi gruppi di lavoro con require_ssl impostato su false viene rifiutata. Non puoi modificare il valore require_ssl e impostarlo su false dopo la creazione del gruppo di lavoro. Per ulteriori informazioni, consulta Configurazione delle opzioni di sicurezza per le connessioni.

Tieni presente che continuerai ad avere la possibilità di modificare le impostazioni del cluster o del gruppo di lavoro per modificare il comportamento predefinito, in base alle esigenze dei casi d’uso specifici.