View a markdown version of this page

Amazon Redshift 中的行為變更 - Amazon Redshift
即將發生的行為變更近期行為變更

Amazon Redshift 將不再支援在 2026 年 6 月 30 日之後使用 Python UDFs。我們將開始分階段強制執行。如需 Python 生命週期結束和遷移選項的詳細資訊，請參閱 2025 年 6 月 30 日發佈的部落格文章。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Amazon Redshift 中的行為變更

隨著 Amazon Redshift 不斷發展和改進，也會導入某些行為變更，以增強效能、安全和使用者體驗。此頁面可作為完整的資源，讓您隨時掌握這些重要更新、採取行動，並避免潛在的工作負載中斷。

即將發生的行為變更

以下說明即將發生的行為變更。

自 2026 年 6 月 8 日起，Amazon Redshift Serverless 和 Amazon Redshift RG 執行個體上手動快照的增強型計費模型

從 2026 年 6 月 8 日開始，Amazon Redshift 宣布在 Amazon Redshift Serverless 和 Amazon Redshift RG 執行個體上手動快照的增強型計費模式。透過此增強功能，現在會根據儲存在帳戶中所有作用中手動快照的唯一資料區塊來計量手動快照。出現在多個快照中的共用資料區塊只會計算一次，以您區域的現有手動快照費率計費。

如果您在 Amazon Redshift Serverless 工作群組或 Amazon Redshift RG 叢集上使用手動快照，則可能會受到此影響。這可降低維護多個快照的客戶手動快照成本。

無需採取任何動作。增強型帳單模型會自動套用到現有和新的手動快照。

如需快照定價的詳細資訊，請參閱 Amazon Redshift 定價。

Lake Formation 資料表上的 Iceberg DELETE 需要從修補程式 202 開始的 DELETE 許可

從 Amazon Redshift 修補程式 202 開始，Lake Formation (LF) 受管資料表上的 Iceberg DELETE 操作需要 DELETE Lake Formation 許可。UPDATE 和 MERGE 操作需要 INSERT 和 DELETE 許可。所有 Iceberg DML 操作都需要 ALTER 許可。

如果您針對 AWS Lake Formation 管理的 Iceberg 資料表執行 DELETE、UPDATE 或 MERGE 操作，則可能會受到此影響。

先前，只有 INSERT 許可 （且沒有 DELETE 許可） 的主體可以在 LF 受管 Iceberg 資料表上執行刪除操作。從修補程式 202 開始，DELETE 操作需要 DELETE Lake Formation 許可。完全依賴 INSERT 許可來執行刪除的委託人會收到許可錯誤，直到明確授予 DELETE 許可為止。S3 資料表不受此變更影響。

若要在此變更後繼續執行 DELETE 操作，請檢閱 Iceberg 資料表的 Lake Formation 許可授予，並確保執行刪除操作的委託人已授予 DELETE Lake Formation 許可。您可以使用 AWS Lake Formation 主控台或 aws lakeformation list-permissions AWS CLI 命令來驗證現有的授權。

如果您需要暫時還原到先前的行為，請聯絡 AWS Support，在叢集上停用此變更，而不需要部署程式碼。

如需修補程式版本的詳細資訊，請參閱 適用於 Amazon Redshift 的叢集版本。

從修補程式 202 開始，Amazon Redshift Serverless 會在快照還原時保留零 ETL 和 S3 事件整合

從 Amazon Redshift 修補程式 202 開始，當您將 Amazon Redshift Serverless 命名空間從快照或復原點還原至相同的無伺服器命名空間時，會自動維護與命名空間和快照/復原點相關聯的零 ETL 和 S3 事件整合。不需要其他動作。

如果您將快照或復原點還原至已設定零 ETL 或 S3 事件整合的 Amazon Redshift Serverless 命名空間，則可能會受到此影響。

先前，將快照或復原點還原至標記為關聯的零 ETL 和 S3 事件整合失敗的無伺服器命名空間，要求您在完成還原後手動重新建立它們。從修補程式 202 開始，這些整合預設為維護，並在還原完成後繼續操作。

此功能僅適用於還原至相同無伺服器命名空間的 Amazon Redshift Serverless。將快照還原至不同的命名空間不會維護整合。佈建叢集上的快照還原不會維持零 ETL 或 S3 事件整合。

若要在還原期間選擇退出維護整合，請取消勾選還原頁面上的維護整合方塊 AWS Management Console。如果您使用的是 AWS CLI，請在呼叫 restore-from-snapshot 或 restore-from-recovery-point API 操作時設定 --no-maintain-integration 參數。當您選擇退出時，整合會在還原後進入 FAILED 狀態。然後，您可以刪除失敗的整合並重新建立它們。

如需修補程式版本的詳細資訊，請參閱 適用於 Amazon Redshift 的叢集版本。

2026 年 9 月 30 日終止對 Amazon Redshift ODBC 1.x 驅動程式的支援

從 2026 年 9 月 30 日開始，Amazon Redshift 將停止支援 ODBC 1.x 驅動程式。根據客戶的意見回饋，我們已將原始end-of-support日期從 2026 年 6 月 30 日延長至 2026 年 9 月 30 日，以提供額外的遷移時間。這同時適用於 Amazon Redshift 佈建叢集和無伺服器工作群組。

如果您使用任何版本的 ODBC 1.x 驅動程式連線至 Amazon Redshift，則可能會受到此影響。若要驗證您是否使用 ODBC 1.x 驅動程式，請執行下列查詢：

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

若要繼續取得 Amazon Redshift ODBC 驅動程式連線的技術支援，請在 2026 年 9 月 29 日之前遷移至最新的 Amazon Redshift ODBC 2.x 驅動程式。

在生產環境中遷移至 ODBC 2.x 驅動程式之前，我們建議您進行徹底的概念驗證，以確認新驅動程式符合您的所有功能需求。

我們建議您使用最新版本的 Amazon Redshift ODBC 2.x 驅動程式，並設定 ApplicationName 屬性，以在連線至 Amazon Redshift 時識別您的應用程式。

純量 Python UDF 將於 2026 年 6 月 30 日之後終止支援

Amazon Redshift 將於 2026 年 6 月 30 日之後終止對 Python UDF 的支援。我們建議您使用 Lambda UDF 作為替代方案。

相較於 Python UDF，Lambda UDF 具備以下優點：

  • Lambda UDF 可以從 UDF 邏輯內連線至外部服務和 API。

  • Lambda UDF 使用 Lambda 運算資源。大量運算或記憶體密集型 Lambda UDF 不會影響 Amazon Redshift 的查詢效能或資源並行。

  • Lambda UDF 支援執行 Python 程式碼。Lambda UDF 支援多個 Python 執行時期，取決於特定使用案例。如需詳細資訊，請參閱《AWS Lambda 開發人員指南》中的使用 Python 建置。

  • 您可以在單獨的服務界限中隔離自訂程式碼執行。這樣做可簡化維護、監控、預算編列和許可管理的工作。

如需有關建立和使用 Lambda UDF 的資訊，請參閱《Amazon Redshift 資料庫開發人員指南》中的純量 Lambda UDF。如需將現有 Python UDF 轉換為 Lambda UDF 的相關資訊，請參閱部落格文章。

2026 年 2 月 27 日之後的具體化檢視 (MV) Auto-REFRESH 行為變更

自 2026 年 2 月 27 日起，Amazon Redshift 具體化視觀表的 Auto REFRESH 查詢會以使用者查詢的形式執行，而非背景自律程序。因此，Auto REFRESH 查詢現在會以與其他使用者查詢相同的優先順序執行。

此變更可改善啟用 Auto REFRESH 的具體化視觀表的新鮮度，協助他們掌握基本資料表相較於先前行為的最新變更。

注意：MV Auto REFRESH 行為變更功能僅適用於修補程式版本 P198 及更新版本的 CURRENT 軌道上的 Amazon Redshift 佈建叢集。它目前在 Serverless 上已停用。

Amazon Redshift 在 2026 年 2 月 16 日之後，即不支援透過資料共用存取取用者資訊的函式

自 2026 年 2 月 16 日起，Amazon Redshift 將不再支援使用透過資料共用存取取用者使用者、角色或群組資訊的 user_is_member_of 和相關函數。

最低 Transport Layer Security (TLS) 版本變更自 2026 年 7 月 30 日開始生效

從 2026 年 7 月 30 日開始，Amazon Redshift 將強制執行最低 Transport Layer Security (TLS) 版本 1.2。使用 TLS 1.0 或 1.1 版的傳入連線將遭到拒絕。這同時適用於 Amazon Redshift 佈建叢集和無伺服器工作群組。不是使用 TLS 的 Amazon Redshift 資料倉儲則不受此變更影響。

如果您使用 TLS 1.0 或 1.1 版連線到 Amazon Redshift，則可能會受此更新影響。

若要確認您目前使用的 TLS 版本，您可以：

對於 Amazon Redshift 佈建：查看 STL_CONNECTION_LOG 系統資料表 [1] 中的 sslversion 欄。

對於 Amazon Redshift Serverless 工作群組：查看 SYS_CONNECTION_LOG 系統資料表 [2] 中的 ssl_version 欄。

若要在此變更生效後持續存取 Amazon Redshift 資料倉儲，請遵循下列步驟：

  1. 更新您的用戶端以支援 TLS 1.2 或更高版本

  2. 安裝可支援 TLS 1.2+ 的最新驅動器版本

如果可能的話，建議您使用最新版本的 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 在 2025 年 10 月 30 日之後，即不支援建立新的純量 Python UDF

Amazon Redshift 自 2025 年 10 月 30 日起不再支援建立新的 Python UDF。現有 Python UDF 將繼續正常運作。我們強烈建議您在此日期之前，將現有的 Python UDF 移轉至 Lambda UDF。

相較於 Python UDF，Lambda UDF 具備以下優點：

  • Lambda UDF 可以從 UDF 邏輯內連線至外部服務和 API。

  • Lambda UDF 使用 Lambda 運算資源。大量運算或記憶體密集型 Lambda UDF 不會影響 Amazon Redshift 的查詢效能或資源並行。

  • Lambda UDF 支援執行 Python 程式碼。Lambda UDF 支援多個 Python 執行時期，取決於特定使用案例。如需詳細資訊，請參閱《AWS Lambda 開發人員指南》中的使用 Python 建置。

  • 您可以在單獨的服務界限中隔離自訂程式碼執行。這樣做可簡化維護、監控、預算編列和許可管理的工作。

如需有關建立和使用 Lambda UDF 的資訊，請參閱《Amazon Redshift 資料庫開發人員指南》中的純量 Lambda UDF。如需將現有 Python UDF 轉換為 Lambda UDF 的相關資訊，請參閱部落格文章。

近期行為變更

Amazon Redshift 在 2025 年 8 月 26 日之後使用最新的 IANA 時區資料庫

自 2025 年 8 月 26 日起，Amazon Redshift 採用最新的 IANA 時區資料庫修補程式來計算時區。此變更會更改特定時區和時段的日期和時間轉換運作方式。此更新會影響明確的時區轉換，例如使用 CONVERT_TIMEZONE 函式或 TIMEZONE 和 AT TIME ZONE 命令執行的轉換，以及在類型轉換操作期間進行的隱含轉換，特別是在 TIMESTAMP 和 TIMESTAMPTZ 格式之間。

以下是時區和時段組合的更新清單：

  • 時區現在可正確遵守 2038 年之後的日光節約時間 (DST)。先前在 2038 年之後就沒有遵守 DST 的時區。

  • America/Toronto 時區和與其連結的時區會在 1947 到 1950 年於當地時間凌晨 2 點進行 DST 切換，而不是在午夜。

  • Amazon Redshift 現在可正確反映所有時區標準化之前時段的當地標準時間 (LMT)。此為時區專屬時段，大多數時區會在 19 世紀中期之前切換到標準化。

  • EET、CET、WET 和 MET 現在視為正常時區，而不是縮寫。

  • Amazon Redshift 中不再有下列時區名稱：

    • Asia/Riyadh87

    • Asia/Riyadh88

    • Asia/Riyadh89

    • Mideast/Riyadh87

    • Mideast/Riyadh88

    • Mideast/Riyadh89

    • US/Pacific-New

如需 IANA 時區資料庫的詳細資訊，請參閱 IANA 時區資料庫網站上的時區資料庫。

Amazon Redshift Serverless RPU 變更於 2025 年 8 月 15 日之後生效

自 2025 年 8 月 15 日起，Amazon Redshift Serverless 基礎 Redshift 處理單元 (RPUs) AWS 的帳戶配額為前六個月的 3，200 個 RPUs 或最大彙總基礎 RPUs 1.5 倍。

資料庫稽核記錄變更於 2025 年 8 月 10 日之後生效

從 2025 年 8 月 10 日開始，Amazon Redshift 將變更資料庫稽核記錄，這點需要您採取行動。Amazon Redshift 會將您資料庫中連線和使用者活動的相關資訊記錄到 Amazon S3 儲存貯體和 CloudWatch。在 2025 年 8 月 10 日之後，Amazon Redshift 會停止對具有指定 Redshift IAM USER 之儲存貯體政策的 Amazon S3 儲存貯體進行資料庫稽核記錄。我們建議您更新政策，改為在 S3 儲存貯體政策內使用 Redshift SERVICE-PRINCIPAL 進行稽核記錄。如需有關稽核記錄的資訊，請參閱 Amazon Redshift 稽核記錄的儲存貯體許可。

為了避免任何記錄中斷，請在 2025 年 8 月 10 日之前檢閱並更新 S3 儲存貯體政策，以在相關聯區域中授予 Redshift service-principal 的存取權。如需資料庫稽核記錄的詳細資訊，請參閱 Amazon S3 中的日誌檔案。

如有問題或疑慮，請透過以下連結聯絡 AWS Support： AWS Support。

無伺服器工作群組的虛擬私有雲端點變更於 2025 年 6 月 27 日之後生效

從 2025 年 6 月 27 日開始，Amazon Redshift 將變更無伺服器工作群組的虛擬私有雲端點 (VPCE) 支援。在此日期之前，Amazon Redshift 會在建立工作群組期間將端點部署到單一可用區域 (AZ)，並隨著時間擴展 VPCE 支援至最多三個 AZ。在此日期之後，Amazon Redshift 會在建立工作群組期間指定的最多三個可用區域中部署 VPCE。

如需詳細資訊，請參閱使用 Amazon Redshift Serverless 時的考量。

如有問題或疑慮，請透過以下連結聯絡 AWS Support： AWS Support。

查詢監控變更在 2025 年 5 月 2 日之後生效

自 2025 年 5 月 2 日起，我們將不再針對現有和新建立的 Redshift Serverless 工作群組，於查詢限制索引標籤中提供查詢 CPU 時間 (max_query_cpu_time) 和查詢 CPU 用量 (max_query_cpu_percentage) 指標。在此日期之後，我們將根據所有 Redshift Serverless 工作群組中的這些指標自動移除所有查詢限制。

查詢限制的設計在於攔截失控的查詢。不過，查詢 CPU 時間 (max_query_cpu_time) 和查詢 CPU 用量 (max_query_cpu_percentage) 在查詢的生命週期內可能會有所不同，因此不一定是攔截失控查詢的有效方法。若要攔截失控的查詢，建議您利用查詢監控指標來提供一致且可行的資訊。一些範例包括：

  • 查詢執行時間 (max_query_execution_time)：確保查詢在預期的時間範圍內完成。

  • 傳回資料列計數 (max_scan_row_count)：監控正在處理的資料規模。

  • 查詢佇列時間 (max_query_queue_time)：識別花時間佇列的查詢。

如需支援指標的完整清單，請參閱 Amazon Redshift Serverless 的查詢監控指標。

安全變更在 2025 年 1 月 10 日之後生效

安全是我們對於 Amazon Web Services (AWS) 的首要任務。為達成此任務，我們進一步強化 Amazon Redshift 環境的安全狀態，藉由導入增強型安全預設值來協助您遵守資料安全方面的最佳實務，而不需進行額外設定，同時降低設定錯誤的潛在風險。為了避免任何潛在的中斷，請檢閱佈建叢集和無伺服器工作群組建立組態、指令碼和工具，並於生效日期之前進行必要的變更，以符合新的預設設定。

預設停用公開存取

在 2025 年 1 月 10 日之後，所有新建立的佈建叢集，以及從快照還原的叢集，都將預設為停用公開存取。根據預設，此版本僅允許來自相同虛擬私有雲端 (VPC) 內用戶端應用程式的叢集連線。若要從另一個 VPC 中的應用程式存取您的資料倉儲，請設定跨 VPC 存取。此變更將反映在 CreateCluster 和 RestoreFromClusterSnapshot API 操作中，以及對應的 SDK 和 AWS CLI 命令中。如果您從 Amazon Redshift 主控台建立佈建叢集，則叢集的公開存取會預設為停用。

假如您仍需要公開存取，則需要覆寫預設值，並在執行 CreateCluster 或 RestoreFromClusterSnapshot API 操作時將 PubliclyAccessible 參數設為 true。使用可公開存取的叢集時，我們建議您使用安全群組或網路存取控制清單 (ACL) 來限制存取。如需詳細資訊，請參閱VPC security groups (VPC 安全群組)及設 Amazon Redshift 叢集或 Amazon Redshift Serverless 工作群組的安全群組通訊設定。

預設加密

在 2025 年 1 月 10 日之後，Amazon Redshift 將透過啟用加密作為所有新建立 Amazon Redshift 佈建叢集的預設設定，來進一步強化資料和叢集安全。這項變更不適用於從快照還原的叢集。

透過此變更，使用 AWS Management Console AWS CLI或 API 建立佈建叢集而不指定 KMS 金鑰時，將無法再使用解密叢集的功能。叢集會自動使用 加密 AWS 擁有的金鑰。

如果您使用自動化指令碼建立未加密的叢集，或利用未加密的叢集進行資料共用，則可能會受到此更新的影響。為了確保順暢轉換，請更新建立未加密叢集的指令碼。此外，如果您定期建立新的未加密取用者叢集並將其用於資料共用，請檢閱您的組態，以確保生產者和取用者叢集都已加密，防止資料共用活動中斷。如需詳細資訊，請參閱Amazon Redshift 資料庫加密。

強制執行 SSL 連線

在 2025 年 1 月 10 日之後，Amazon Redshift 預設會對連線至新建立的佈建和還原叢集的用戶端強制執行 SSL 連線。此預設變更也會套用至無伺服器工作群組。

此變更生效後，所有新建立或還原的叢集都會導入名為 default.redshift-2.0 的新預設參數群組，且 require_ssl 參數會預設為 true。在未指定參數群組的情況下建立的任何新叢集，都會自動使用 default.redshift-2.0 參數群組。透過 Amazon Redshift 主控台建立叢集時，系統會自動選取新的 default.redshift-2.0 參數群組。此變更也會反映在 CreateCluster和 RestoreFromClusterSnapshot API 操作，以及對應的 SDK 和 AWS CLI 命令中。如果您使用現有或自訂參數群組，Amazon Redshift 將繼續遵守您的參數群組中指定的 require_ssl 值。您仍然可以視需要選擇變更自訂參數群組中的 require_ssl 值。

對於 Amazon Redshift Serverless 使用者，config-parameters 中的預設值 require_ssl 會變更為 true。任何建立新工作群組且將 require_ssl 設定為 false 的請求，都將遭拒。建立工作群組之後，您可以將 require_ssl 值變更為 false。如需詳細資訊，請參閱設定連線的安全選項。

請注意，您仍然可以修改叢集或工作群組設定來變更預設行為，以因應您的特定使用案例需要。