Amazon Redshift 將不再支援從修補程式 198 開始建立新的 Python UDFs。現有 Python UDF 將繼續正常運作至 2026 年 6 月 30 日。如需詳細資訊，請參閱[部落格文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon Redshift 中的行為變更
隨著 Amazon Redshift 不斷發展和改進，也會導入某些行為變更，以增強效能、安全和使用者體驗。此頁面可作為完整的資源，讓您隨時掌握這些重要更新、採取行動，並避免潛在的工作負載中斷。
## 即將發生的行為變更
以下說明即將發生的行為變更。
**Topics**
+ [純量 Python UDF 將於 2026 年 6 月 30 日之後終止支援](#python-udf-jun2026)
+ [2026 年 2 月 27 日之後的具體化檢視 (MV) Auto-REFRESH 行為變更](#autorefresh-feb272026)
+ [Amazon Redshift 在 2026 年 2 月 16 日之後，即不支援透過資料共用存取取用者資訊的函式](#datasharing-feb2026)
+ [最低 Transport Layer Security (TLS) 版本變更自 2026 年 1 月 31 日開始生效](#tls-changes-jan2026)
+ [Amazon Redshift 在 2025 年 10 月 30 日之後，即不支援建立新的純量 Python UDF](#python-udf-oct2025)
### 純量 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 建置](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html)。
+ 您可以在單獨的服務界限中隔離自訂程式碼執行。這樣做可簡化維護、監控、預算編列和許可管理的工作。
如需有關建立和使用 Lambda UDF 的資訊，請參閱《Amazon Redshift 資料庫開發人員指南》**中的[純量 Lambda UDF](https://docs.aws.amazon.com/redshift/latest/dg/udf-creating-a-lambda-sql-udf)。如需將現有 Python UDF 轉換為 Lambda UDF 的相關資訊，請參閱[部落格文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。
### 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 年 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\$1CONNECTION\$1LOG 系統資料表 [1] 中的 sslversion 欄。
對於 Amazon Redshift Serverless 工作群組：查看 SYS\$1CONNECTION\$1LOG 系統資料表 [2] 中的 ssl\$1version 欄。
若要在此變更生效後持續存取 Amazon Redshift 資料倉儲，請遵循下列步驟：
1. 更新您的用戶端以支援 TLS 1.2 或更高版本
1. 安裝可支援 TLS 1.2\$1 的最新驅動器版本
如果可能的話，建議您使用最新版本的 Amazon Redshift 驅動器 [3]。
[1] [https://docs.aws.amazon.com/redshift/latest/dg/r\$1STL\$1CONNECTION\$1LOG.html](https://docs.aws.amazon.com/redshift/latest/dg/r_STL_CONNECTION_LOG.html)
[2] [https://docs.aws.amazon.com/redshift/latest/dg/SYS\$1CONNECTION\$1LOG.html](https://docs.aws.amazon.com/redshift/latest/dg/SYS_CONNECTION_LOG.html)
[3] [https://docs.aws.amazon.com/redshift/latest/mgmt/configuring-connections.html](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 建置](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html)。
+ 您可以在單獨的服務界限中隔離自訂程式碼執行。這樣做可簡化維護、監控、預算編列和許可管理的工作。
如需有關建立和使用 Lambda UDF 的資訊，請參閱《Amazon Redshift 資料庫開發人員指南》**中的[純量 Lambda UDF](https://docs.aws.amazon.com/redshift/latest/dg/udf-creating-a-lambda-sql-udf)。如需將現有 Python UDF 轉換為 Lambda UDF 的相關資訊，請參閱[部落格文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。
## 近期行為變更
**Topics**
+ [Amazon Redshift 在 2025 年 8 月 26 日之後使用最新的 IANA 時區資料庫](#timezone-changes-aug2025)
+ [Amazon Redshift Serverless RPU 變更於 2025 年 8 月 15 日之後生效](#serverless-rpu-aug2025)
+ [資料庫稽核記錄變更於 2025 年 8 月 10 日之後生效](#audit-logging-aug2025)
+ [無伺服器工作群組的虛擬私有雲端點變更於 2025 年 6 月 27 日之後生效](#VPCE-jun2025)
+ [查詢監控變更在 2025 年 5 月 2 日之後生效](#query-monitoring-changes-may2025)
+ [安全變更在 2025 年 1 月 10 日之後生效](#security-changes-jan2025)
### Amazon Redshift 在 2025 年 8 月 26 日之後使用最新的 IANA 時區資料庫
自 2025 年 8 月 26 日起，Amazon Redshift 採用最新的 IANA 時區資料庫修補程式來計算時區。此變更會更改特定時區和時段的日期和時間轉換運作方式。此更新會影響明確的時區轉換，例如使用 [CONVERT\$1TIMEZONE](https://docs.aws.amazon.com/redshift/latest/dg/CONVERT_TIMEZONE.html) 函式或 [TIMEZONE](https://docs.aws.amazon.com/redshift/latest/dg/r_TIMEZONE.html) 和 [AT TIME ZONE](https://docs.aws.amazon.com/redshift/latest/dg/r_AT_TIME_ZONE.html) 命令執行的轉換，以及在類型轉換操作期間進行的隱含轉換，特別是在 [TIMESTAMP](https://docs.aws.amazon.com/redshift/latest/dg/r_Datetime_types.html#r_Datetime_types-timestamp) 和 [TIMESTAMPTZ](https://docs.aws.amazon.com/redshift/latest/dg/r_Datetime_types.html#r_Datetime_types-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 時區資料庫網站上的[時區資料庫](https://www.iana.org/time-zones)。
### 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 稽核記錄的儲存貯體許可](db-auditing.md#db-auditing-bucket-permissions)。
為了避免任何記錄中斷，請在 2025 年 8 月 10 日之前檢閱並更新 S3 儲存貯體政策，以在相關聯區域中授予 Redshift service-principal 的存取權。如需資料庫稽核記錄的詳細資訊，請參閱 [Amazon S3 中的日誌檔案](db-auditing.md#db-auditing-manage-log-files)。
如有問題或疑慮，請透過以下連結聯絡 AWS Support： [AWS Support](https://aws.amazon.com/support)。
### 無伺服器工作群組的虛擬私有雲端點變更於 2025 年 6 月 27 日之後生效
從 2025 年 6 月 27 日開始，Amazon Redshift 將變更無伺服器工作群組的虛擬私有雲端點 (VPCE) 支援。在此日期之前，Amazon Redshift 會在建立工作群組期間將端點部署到單一可用區域 (AZ)，並隨著時間擴展 VPCE 支援至最多三個 AZ。在此日期之後，Amazon Redshift 會在建立工作群組期間指定的最多三個可用區域中部署 VPCE。
如需詳細資訊，請參閱[使用 Amazon Redshift Serverless 時的考量](serverless-usage-considerations.md)。
如有問題或疑慮，請透過以下連結聯絡 AWS Support： [AWS Support](https://aws.amazon.com/support)。
**Topics**
+ [Amazon Redshift 在 2025 年 8 月 26 日之後使用最新的 IANA 時區資料庫](#timezone-changes-aug2025)
+ [Amazon Redshift Serverless RPU 變更於 2025 年 8 月 15 日之後生效](#serverless-rpu-aug2025)
+ [資料庫稽核記錄變更於 2025 年 8 月 10 日之後生效](#audit-logging-aug2025)
+ [無伺服器工作群組的虛擬私有雲端點變更於 2025 年 6 月 27 日之後生效](#VPCE-jun2025)
+ [查詢監控變更在 2025 年 5 月 2 日之後生效](#query-monitoring-changes-may2025)
+ [安全變更在 2025 年 1 月 10 日之後生效](#security-changes-jan2025)
### 查詢監控變更在 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 的查詢監控指標](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html#cm-c-wlm-query-monitoring-metrics-serverless)。
### 安全變更在 2025 年 1 月 10 日之後生效
安全是我們對於 Amazon Web Services (AWS) 的首要任務。為達成此任務，我們進一步強化 Amazon Redshift 環境的安全狀態，藉由導入增強型安全預設值來協助您遵守資料安全方面的最佳實務，而不需進行額外設定，同時降低設定錯誤的潛在風險。為了避免任何潛在的中斷，請檢閱佈建叢集和無伺服器工作群組建立組態、指令碼和工具，並於生效日期之前進行必要的變更，以符合新的預設設定。
#### 預設停用公開存取
在 2025 年 1 月 10 日之後，所有新建立的佈建叢集，以及從快照還原的叢集，都將預設為停用[公開存取](rs-security-group-public-private.md)。根據預設，此版本僅允許來自相同虛擬私有雲端 (VPC) 內用戶端應用程式的叢集連線。若要從另一個 VPC 中的應用程式存取您的資料倉儲，請設定[跨 VPC](managing-cluster-cross-vpc.md) 存取。此變更將反映在 `CreateCluster` 和 `RestoreFromClusterSnapshot` API 操作中，以及對應的 SDK 和 AWS CLI 命令中。如果您從 Amazon Redshift 主控台建立佈建叢集，則叢集的公開存取會預設為停用。
假如您仍需要公開存取，則需要覆寫預設值，並在執行 `CreateCluster` 或 `RestoreFromClusterSnapshot` API 操作時將 `PubliclyAccessible` 參數設為 true。使用可公開存取的叢集時，我們建議您使用安全群組或網路存取控制清單 (ACL) 來限制存取。如需詳細資訊，請參閱[VPC security groups (VPC 安全群組)](managing-vpc-security-groups.md)及[設 Amazon Redshift 叢集或 Amazon Redshift Serverless 工作群組的安全群組通訊設定](rs-security-group-public-private.md)。
#### 預設加密
在 2025 年 1 月 10 日之後，Amazon Redshift 將透過啟用加密作為所有新建立 Amazon Redshift 佈建叢集的預設設定，來進一步強化資料和叢集安全。這項變更不適用於從快照還原的叢集。
透過此變更，使用 AWS 管理主控台 AWS CLI或 API 建立佈建叢集而不指定 KMS 金鑰時，將無法再使用解密叢集的功能。叢集會自動使用 加密 AWS 擁有的金鑰。
如果您使用自動化指令碼建立未加密的叢集，或利用未加密的叢集進行資料共用，則可能會受到此更新的影響。為了確保順暢轉換，請更新建立未加密叢集的指令碼。此外，如果您定期建立新的未加密取用者叢集並將其用於資料共用，請檢閱您的組態，以確保生產者和取用者叢集都已加密，防止資料共用活動中斷。如需詳細資訊，請參閱[Amazon Redshift 資料庫加密](working-with-db-encryption.md)。
#### 強制執行 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`。如需詳細資訊，請參閱[設定連線的安全選項](connecting-ssl-support.md)。
請注意，您仍然可以修改叢集或工作群組設定來變更預設行為，以因應您的特定使用案例需要。