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.
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.