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

Amazon Redshift 自 2025 年 11 月 1 日起不再支援建立新的 Python UDF。如果您想要使用 Python UDF，請在該日期之前建立 UDF。現有 Python UDF 將繼續正常運作。如需詳細資訊，請參閱部落格文章。

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

Amazon Redshift 中的行為變更

隨著 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 的相關資訊，請參閱部落格文章。

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

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

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

自 2026 年 1 月 31 日開始，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 中的日誌檔案。

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

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

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

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

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

查詢監控變更在 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 管理主控台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。如需詳細資訊，請參閱設定連線的安全選項。

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