Maintaining Amazon Redshift Endpoint Consistency Across Cluster Operations

Understanding Redshift Cluster Endpoints

Amazon Redshift cluster endpoints follow a predictable structure:

<cluster-identifier>.<account-specific-string>.<region>.redshift.amazonaws.com:5439

The JDBC connection URL format is:

jdbc:redshift://endpoint:port/database

The ODBC connection URL format is:

Driver={Amazon Redshift (x64)};Server=endpoint;Database=database_name;UID=user_name;PWD=[PASSWORD];Port=port_number

The critical insight is that the <account-specific-string> portion remains consistent for your AWS account and region. This means your JDBC and ODBC connection URLs remain unchanged in the following scenarios:

1. Recreating a cluster with the same identifier in the same region
2. Resizing the cluster (elastic or classic resize)
3. Changing node types (e.g., DC2 to RA3 migration)

Scenario 1: Recreating a Cluster with the Same Identifier

When you restore a cluster from a snapshot using the same cluster identifier within the same AWS region, the endpoint URL remains identical. To safely accomplish this, rename your existing cluster first rather than deleting it.

When This Is Useful:

• Disaster recovery from snapshots
• Testing cluster configurations before applying to production
• Creating a new cluster from an older snapshot while preserving the endpoint
• Avoiding updates to downstream applications and services

Step-by-Step Process:

Step 1: Document Current Configuration

Record the following from your existing cluster:

• Cluster identifier (e.g., my-redshift-cluster)
• Current endpoint URL
• VPC, subnet group, and security group settings
• Parameter group and maintenance window
• Node type and number of nodes

Step 2: Create a Manual Snapshot

Create a snapshot of your current cluster:

1. Navigate to the Amazon Redshift console
2. Select your cluster
3. Choose Actions > Create snapshot
4. Provide a descriptive snapshot identifier (e.g., pre-recreation-snapshot-2026-03-30)
5. Wait for snapshot completion

Step 3: Rename the Existing Cluster

Instead of deleting the cluster, rename it to a temporary identifier:

1. Select your cluster in the Redshift console
2. Choose Edit
3. Change the cluster identifier to a temporary name (e.g., my-redshift-cluster-old)
4. Choose Save changes
5. Wait for the modification to complete (typically takes a few seconds)

Step 4: Restore from Snapshot with the Original Identifier

1. Navigate to Snapshots in the Redshift console
2. Select your snapshot
3. Choose Restore snapshot > Restore to provisioned cluster
4. Critical: Enter the original cluster identifier (e.g., my-redshift-cluster)
5. Configure settings (VPC, subnet group, security groups should match original)
6. Choose Restore cluster from snapshot

Step 5: Verify Endpoint Consistency

Once the new cluster status is "Available":

1. Navigate to the cluster details page
2. Compare the endpoint URL with your documented original endpoint
3. Verify they are identical
4. Test connectivity without updating application configurations

Step 6: Delete the Renamed Cluster (Optional)

After verifying the new cluster works correctly:

1. Select the renamed cluster (e.g., my-redshift-cluster-old)
2. Choose Actions > Delete
3. Optionally create a final snapshot
4. Confirm deletion

Benefits of the Rename Approach:

• Zero data loss risk: Original cluster remains available during the process
• Instant rollback capability: If issues occur, simply delete the new cluster and rename the old one back
• Validation period: Test the new cluster thoroughly before removing the old one
• Minimal downtime: Applications can continue using the old cluster until cutover

Scenario 2: Resizing and Node Type Changes

Amazon Redshift maintains the same endpoint during resize operations and node type changes.

Elastic Resize:

Elastic resize allows you to add or remove nodes, or change node types with minimal downtime (typically 10-15 minutes). The cluster endpoint remains unchanged throughout the process.

To perform elastic resize:

1. Navigate to your cluster in the Redshift console
2. Choose Actions > Resize
3. Select Elastic resize
4. Specify new node type or number of nodes
5. Choose Resize cluster

The cluster remains available for read operations during most of the resize process, and the endpoint URL does not change.

Classic Resize:

Classic resize creates a new cluster, migrates data, and then replaces the original cluster while maintaining the same identifier and endpoint.

To perform classic resize:

1. Navigate to your cluster in the Redshift console
2. Choose Actions > Resize
3. Select Classic resize
4. Specify new configuration
5. Choose Resize cluster

The cluster endpoint remains unchanged after the resize completes.

Important Considerations

Same Region Requirement: Endpoint consistency is maintained only within the same AWS region. Cross-region migrations result in different endpoints.

DNS Propagation: Allow 2-5 minutes for DNS changes to propagate after cluster creation or identifier changes.

VPC and Network Configuration: Maintain the same VPC, subnet group, and security group settings to ensure network connectivity. If you restore to a different subnet, connection issues may occur.

Serverless vs Provisioned: This guidance applies to provisioned clusters. Redshift Serverless uses a different endpoint structure based on workgroup names (format: <workgroup-name>.<account-id>.<region>.redshift-serverless.amazonaws.com).

Cost Considerations: When using the rename approach, you will temporarily have two clusters running, which doubles your costs during the transition period. Plan accordingly and delete the old cluster promptly after validation.

Cluster Identifier Naming: Cluster identifiers must be unique within your AWS account and region. The rename approach works because it frees up the original identifier for reuse.

Benefits

• Zero application updates: JDBC and ODBC URLs remain unchanged
• Reduced downtime: No need to coordinate connection string updates across teams
• Simplified disaster recovery: Restore from snapshots without reconfiguration
• Flexible scaling: Resize or change node types without connectivity concerns
• Lower operational risk: Eliminate configuration errors from manual updates

Testing Recommendations

Before implementing in production:

1. Test the process in a non-production AWS account
2. Document the original endpoint before any changes
3. Verify endpoint consistency after each operation
4. Test application connectivity without configuration changes
5. Validate query performance after resize or recreation
6. Monitor CloudWatch metrics during and after the transition

Conclusion

Amazon Redshift's endpoint consistency across cluster operations—including recreation with the same identifier, elastic resize, classic resize, and node type changes—significantly simplifies cluster management. By understanding and leveraging this behavior, particularly using the safe rename-and-restore approach, you can perform necessary cluster operations without the operational overhead of updating connection configurations across your data ecosystem.

This approach is particularly valuable for organizations with complex data architectures where Redshift clusters serve multiple applications, ETL processes, and analytics tools. The ability to maintain endpoint consistency reduces coordination requirements, minimizes downtime, and lowers the risk of connection errors during critical operations.

Related Resources

• Renaming a cluster
• Resizing a cluster
• Restoring a cluster from a snapshot
• Configuring connections in Amazon Redshift
• Migrate my Amazon Redshift cluster to an RA3 node type
• Resize an Amazon Redshift cluster