Behavior changes in Amazon Redshift
As Amazon Redshift continues to evolve and improve, certain changes in behavior are introduced to enhance performance, security, and user experience. This page serves as a comprehensive resource for you to stay informed about these critical updates, take actions, and avoid potential disruptions to your workloads.
Upcoming behavior changes
The following describes upcoming behavior changes.
Topics
Minimum Transport Layer Security (TLS) version changes effective after October 31, 2025
Beginning October 31, 2025, Amazon Redshift will enforce a minimum Transport Layer Security (TLS) version of 1.2. Incoming connections that use TLS versions 1.0 or 1.1 will be rejected. This applies to both Amazon Redshift provisioned clusters and serverless workgroups.
This update might impact you if you use TLS versions 1.0 or 1.1 to connect to Amazon Redshift.
To verify which TLS version you are currently using, you can:
For Amazon Redshift Provisioned: Check the sslversion column in the STL_CONNECTION_LOG system table [1].
For Amazon Redshift Serverless Workgroup: Check the ssl_version column in the SYS_CONNECTION_LOG system table [2].
To maintain uninterrupted access to your Amazon Redshift data warehouse after this change, please follow the steps listed below:
Update your client to support TLS 1.2 or higher
Install the latest driver version with TLS 1.2+ support
We recommend using the latest version of the Amazon Redshift driver [3] if possible.
[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
Database audit logging changes effective after August 10, 2025
Beginning August 10, 2025, Amazon Redshift is making a change to Database Audit Logging, which requires your action. Amazon Redshift logs information about connections and user activities in your database to Amazon S3 buckets and CloudWatch. After August 10, 2025, Amazon Redshift will discontinue database audit logging to your Amazon S3 buckets which have a bucket policy specifying a Redshift IAM USER. We recommend updating your policies to use the Redshift SERVICE-PRINCIPAL instead, within S3 bucket policies for audit logging. For information about audit logging, see Bucket permissions for Amazon Redshift audit logging.
To avoid any logging interruption, review and update your S3 bucket policies to grant access to the Redshift service-principal in the associated region prior to August 10, 2025. For information about database audit logging, see Log files in Amazon S3
For questions or concerns, contact Amazon support at the following link: Amazon Support
Query monitoring changes effective after May 2, 2025
Effective May 2, 2025, we will no longer offer the Query CPU time (max_query_cpu_time) and Query CPU usage (max_query_cpu_percentage)
metrics from the Query Limits tab for both existing and newly created Redshift Serverless workgroups. After this date, we will automatically remove all
query limits based on these metrics across all Redshift Serverless workgroups.
Query limits are designed to catch runaway queries. However, Query CPU time (max_query_cpu_time) and Query CPU usage
(max_query_cpu_percentage) can vary during the lifetime of the query, and are thus not a consistently effective method
to catch runaway queries. To catch runaway queries, we recommend that you leverage query monitoring metrics that provide consistent
and actionable information. Some examples include:
Query execution time (
max_query_execution_time): To ensure queries complete within expected timeframes.Return row count (
max_scan_row_count): To monitor the scale of data being processed.Query queue time (
max_query_queue_time): To identify queries that spend time queueing.
For a full list of supported metrics, see Query monitoring metrics for Amazon Redshift Serverless.
Security changes effective after January 10, 2025
Security is our top priority at Amazon Web Services (Amazon). To that end, we are further strengthening the security posture of Amazon Redshift environments by introducing enhanced security defaults which help you adhere to best practices in data security without requiring additional setup and reduce the risk of potential misconfiguration. To avoid any potential disruption, review your provisioned cluster and serverless workgroup creation configurations, scripts, and tools to make necessary changes to align with the new default settings before the effective date.
Public access disabled by default
After January 10, 2025, public accessibility will be disabled by default for all
newly created provisioned clusters, and for clusters restored from snapshots.
With this release, by default, connections to clusters will only be permitted from client applications within the same Virtual Private Cloud (VPC).
To access your data warehouse from applications in another VPC, configure
cross-VPC access.
This change will be reflected in the CreateCluster and RestoreFromClusterSnapshot API operations, and corresponding SDK and Amazon CLI commands.
If you create a provisioned cluster from the Amazon Redshift console, then the cluster has public access disabled by default.
In case you still need public access, you will need to override the default and
set the PubliclyAccessible parameter to true when you run CreateCluster or RestoreFromClusterSnapshot API operations.
With a publicly accessible cluster, we recommend that you must use security groups or network access control lists (ACLs) to restrict access.
For more information, see
VPC security groups and
Configuring security group
communication settings for an Amazon Redshift cluster or an Amazon Redshift Serverless workgroup.
Encryption by default
After January 10, 2025, Amazon Redshift will further enhance data and cluster security by enabling encryption as the default setting for all newly created Amazon Redshift provisioned clusters. This does not apply to clusters restored from snapshots.
With this change, the ability to decrypt clusters will no longer be available when using the Amazon Web Services Management Console, Amazon CLI, or API to create a provisioned cluster without specifying a KMS key. The cluster will automatically be encrypted with an Amazon owned key.
This update might impact you if you are creating unencrypted clusters using automated scripts or leveraging data sharing with unencrypted clusters. To ensure a seamless transition, update your scripts that create unencrypted clusters. Additionally, if you regularly create new unencrypted consumer clusters and use them for data sharing, review your configurations to ensure the producer and consumer clusters are both encrypted, preventing disruptions to your data sharing activities. For more information, see Amazon Redshift database encryption.
Enforcing SSL connections
After January 10, 2025, Amazon Redshift will enforce SSL connections by default for clients connecting to newly created provisioned and restored clusters. This default change will also apply to serverless workgroups.
With this change, a new default parameter group named default.redshift-2.0 will be introduced for all newly created or restored clusters,
with the require_ssl parameter set to true by default.
Any new clusters created without a specified parameter group will automatically utilize the default.redshift-2.0 parameter group.
When creating a cluster through the Amazon Redshift console, the new default.redshift-2.0 parameter group will be automatically selected.
This change will also be reflected in the CreateCluster and RestoreFromClusterSnapshot API operations, and the corresponding SDK and Amazon CLI commands.
If you use existing or custom parameter groups, Amazon Redshift will continue to honor the require_ssl value specified in your parameter group.
You continue to have the option to change the require_ssl value in your custom parameter groups as needed.
For Amazon Redshift Serverless users, the default value of require_ssl in the config-parameters will be changed to true.
Any requests to create new workgroups with require_ssl set to false will be rejected.
You can change the require_ssl value to false after the workgroup is created.
For more information, see Configuring security options for
connections.
Note that you will still have the ability to modify cluster or workgroup settings to change the default behavior, if needed for your specific use cases.