What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
AWS now applies more secure defaults when you create or restore Amazon Redshift resources: provisioned clusters are private and encrypted by default, and relevant new clusters and Serverless workgroups require SSL connections. The change applies to new and restored resources, not automatically to existing warehouses. It may affect provisioning scripts, restores, network access, older clients, and data-sharing configurations.
What changed in Redshift’s default security?
AWS announced the changes on November 18, 2024, with defaults scheduled to take effect after January 10, 2025. AWS announced on January 28, 2025 that they had been implemented in all Regions where Redshift is available. The changes concern three separate controls:
| Control | New default | Scope and detail |
|---|---|---|
| Network access | Private access | New provisioned clusters and clusters restored from snapshots default to PubliclyAccessible=false. AWS describes access from the same VPC as the default path; access from another VPC requires cross-VPC configuration. [AWS Security Blog] |
| Encryption at rest | Encryption enabled | New provisioned clusters are encrypted by default. If you do not specify a KMS key, Redshift uses an AWS-owned key. The console no longer offers creation of unencrypted clusters. [AWS Security Blog] |
| Connections in transit | SSL required | New or restored clusters created without a specified parameter group use default.redshift-2.0, where require_ssl=true. AWS says the same default applies to new Serverless workgroups. Existing and custom parameter groups retain their configured value. [AWS Security Blog] |
AWS says administrators can still change cluster or workgroup settings. These defaults are not proof that every Redshift deployment is secure, nor do they quantify a reduction in security incidents.
Will the change affect an existing cluster?
AWS says the defaults do not automatically change existing warehouses. An existing cluster or workgroup keeps its current configuration, including the settings in its parameter group. AWS nevertheless recommends that customers review existing configurations. [AWS Security Blog]
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitches#1 Best Overall
The practical distinction is between a resource already running and one created or restored after the change. A restore from snapshot is in scope for the new provisioned-cluster defaults, so do not assume that restoring a previously configured cluster reproduces every setting without review.
What should Redshift administrators check?
1. Provisioning templates and scripts
Review calls to CreateCluster and RestoreFromClusterSnapshot, plus CLI, API, and CloudFormation configurations. Look for assumptions that a new cluster will be public, unencrypted, or use a particular parameter group. Confirm that the intended encryption key and parameter-group behavior are explicit where required. [AWS Security Blog]
Rank #2
2. Network routes and access rules
Confirm that applications can reach a private cluster through the intended VPC, routing, and security-group path. A client in another VPC needs cross-VPC connectivity configured. Redshift does not automatically set every network rule: the required security-group and route settings depend on whether traffic comes from the internet or a private security group and on your network requirements. If you explicitly enable public access, restrict inbound access with suitable security groups or network ACLs. [AWS network access documentation] [AWS Security Blog]
3. SSL support in applications and tools
Check JDBC and ODBC drivers, connection pools, and older client tools for SSL/TLS support before using a parameter group that requires SSL. A client that cannot establish an encrypted connection may fail to connect under the default parameter group. If a custom parameter group is selected, verify its require_ssl setting rather than assuming the default applies. [AWS Security Blog]
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute4. Data-sharing arrangements
Review producer and consumer cluster encryption together. AWS specifically recommends checking combinations involving unencrypted clusters and ensuring both sides are encrypted to reduce the risk of disruption. Also include data-sharing assumptions in provisioning and restore reviews. [AWS Security Blog]
5. Restores and Serverless workgroups
Include snapshot restores in change testing because restored provisioned clusters are covered by the defaults. Check new Serverless workgroups as well: AWS says their default parameter-group behavior requires SSL. Validate connectivity and client compatibility before directing production workloads to either resource type. [AWS Security Blog]
Rank #4
How should you choose among the available settings?
| Decision | Default or safer starting point | When to configure differently |
|---|---|---|
| Private or public access | Keep the cluster private and provide access through the intended VPC path. | Enable public access only when a workload requires it, and restrict inbound traffic with network controls. [AWS Security Blog] [AWS network access documentation] |
| AWS-owned key or selected KMS key | If you do not specify a KMS key for a new provisioned cluster, AWS uses an AWS-owned key. | Specify a KMS key when your organization’s key-management requirements call for one. [AWS Security Blog] |
| Default or custom parameter group | Without a specified group, relevant new or restored clusters use default.redshift-2.0 with SSL required; new Serverless workgroups also get the SSL-required default. |
Use a custom group only with an intentional, reviewed require_ssl setting and compatible clients. [AWS Security Blog] |
Are these defaults a complete Redshift security review?
No. They establish defaults for public access, encryption at rest on new provisioned clusters, and encrypted connections for relevant new resources. AWS Security Hub’s Foundational Security Best Practices catalogue separately lists Redshift checks for public access, encrypted connections, encryption at rest, restricted ingress, enhanced VPC routing, and other operational controls. Treat those checks as broader review context rather than as additional defaults introduced by this change. [AWS Security Hub Redshift controls]
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
