Upgrading consumer redshift cluster

When performing an elastic resize from ra3.xplus to ra3.4xlarge on your Amazon Redshift cluster, most of your configurations will be preserved. Here's what you can expect:

a. Endpoint: The cluster endpoint will remain the same after an elastic resize. During the resize operation, Amazon Redshift will update the endpoint to point to the new cluster once the resize nears completion.

b. JDBC URL: Since the endpoint remains unchanged, your JDBC URL will continue to work without modification.

c. ODBC URL: Similar to the JDBC URL, your ODBC URL will remain valid as it uses the same endpoint.

d. Cluster namespace ARN: This will be preserved during an elastic resize.

e. Parameter group: Your parameter group association will be maintained.

f. VPC: The VPC configuration will remain unchanged.

g. Security group: Security group associations will be preserved.

h. Associated IAM roles: IAM role associations will be maintained.

i. Datashare configuration: Your datashare configurations will be preserved.

During the elastic resize process, Amazon Redshift creates a snapshot, provisions a new target cluster with the latest data from the snapshot, and transfers data to the new cluster in the background. During this period, your cluster will be in read-only mode. When the resize nears completion, connections to the source cluster are dropped, and the endpoint is updated to point to the new cluster.

It's worth noting that while elastic resize is generally reliable, in the rare case of a failure, rollback happens automatically in most cases without requiring manual intervention. Also, elastic resize doesn't sort tables or reclaim disk space, so it's not a substitute for vacuum operations.
Sources
Resizing a cluster - Amazon Redshift
Amazon Redshift DC2 to RA3 Migration best practices | AWS re:Post

When you resize your Redshift cluster from ra3.xplus to ra3.4xlarge using elastic resize, most critical configurations remain unchanged.

Configurations that remain unchanged (preserved): ✓ Your connection endpoint ✓ JDBC connection string ✓ ODBC connection string ✓ Cluster namespace ARN ✓ VPC setup ✓ Security group settings ✓ IAM roles ✓ Datashare configuration

Please verify your Parameter group settings - You may need to set up a new parameter group if your current one isn't compatible with ra3.4xlarge nodes. The cluster might use the default parameter group if compatibility issues arise.

The cluster will experience a brief downtime (typically a few minutes) during the cutover phase. During resize, the cluster enters read-only mode briefly. Existing connections to the cluster will be dropped during the cutover phase. You'll need to reconnect applications after the resize completes.

It's recommended to perform this operation during a maintenance window and always ensure you have a valid snapshot before proceeding.

Great question, and it’s excellent that you’re thinking ahead about the impact of an elastic resize before actually initiating it. That kind of foresight is what prevents unnecessary downtime or confusion post-upgrade, especially when dealing with production Redshift clusters or data sharing environments.

When you perform an Elastic Resize operation from ra3.xplus to ra3.4xlarge, Redshift keeps your cluster identity intact. The process is designed to scale compute capacity horizontally or vertically without requiring a full cluster recreation, so most metadata and connection attributes remain consistent. Let’s walk through each point:

a. Endpoint, b. JDBC URL, c. ODBC URL These remain unchanged during an elastic resize. Redshift retains the same cluster endpoint and port, so your applications and BI tools can continue using the existing connection strings without modification. There is typically a brief connection interruption during the resize window, but it is transient and automatically recovers once the resize completes.

d. Cluster Namespace ARN This does not change. The namespace is tied to your Redshift Serverless or provisioned cluster identity, not the node type. Because you’re performing an elastic resize rather than a full cluster restore or snapshot-based rebuild, your ARN references remain stable.

e. Parameter Group Your parameter group association is preserved. Redshift automatically carries over the linked parameter group and its settings. That said, it’s always a good practice to confirm that your parameter group values remain optimal for the new node type, especially for parameters like wlm_json_configuration, query_group, or concurrency controls that might perform differently with increased compute.

f. VPC, g. Security Group Both remain exactly as configured. Elastic resize does not alter networking or security boundaries. Your VPC subnet group, route tables, and associated security groups stay linked to the cluster. It’s still wise to validate that your cluster subnet group has enough IP capacity if the resize adds nodes, since Redshift will allocate new ENIs within the same subnet group.

h. IAM Roles IAM role associations persist through the resize. The cluster’s service-linked roles and any attached IAM roles (for COPY, UNLOAD, or integration with S3, Glue, or Lake Formation) remain attached automatically.

i. Data Share Configuration Your Redshift Data Shares, including consumers and producers, are preserved. The namespace and cluster identifiers that back data sharing relationships remain constant, so consumer clusters continue to have uninterrupted access once the resize completes.

A few best practices before you start:

Run aws redshift describe-resize or use the console to monitor progress in real time.

Pause noncritical ETL or analytical workloads during the resize window to avoid unnecessary retry storms.

If you have automated clients or pipelines, validate reconnection logic in case of the brief endpoint reconnection.

Take a fresh snapshot before initiating the resize, even though the process is nondestructive. It’s always smart to have a rollback point when changing node configurations.

In short, your cluster identity and integrations remain fully intact. The only disruption you’ll notice is a short pause in availability during the transition, after which your new RA3.4xlarge nodes will resume processing with greater throughput and potentially better query parallelism.

If your workload involves consistent high concurrency or mixed analytical and ETL queries, I’d also recommend reviewing your WLM configuration post-upgrade, since the added compute can allow for more simultaneous slots or better workload isolation.

This is one of those operations that looks more intimidating than it is. Redshift’s elastic resize was specifically designed for this kind of seamless scale-up or scale-down, minimizing reconfiguration work.

If you’d like, I can walk you through how to run a low-risk test resize in a staging environment first, including connection validation scripts and CloudWatch metrics to track query latency pre- and post-upgrade. That can give you a clear picture of performance gains and any downstream adjustments to consider.