How do I resize an Amazon Redshift cluster, and how does that impact performance and billing? 

There are three ways to resize an Amazon Redshift cluster:

  • Elastic resize: To quickly add or remove nodes from an existing cluster, use elastic resize. Elastic resize operations usually take a few minutes to complete. The cluster will be unavailable during that time.
  • Classic resize: To change the node type, the number of nodes, or both, use classic resize. A classic resize copies tables to a new cluster. The source cluster will be in read-only mode until the resize operation finishes.
  • Snapshot, restore, and resize: To keep your cluster available during a classic resize, first make a copy of the existing cluster, then resize the new cluster. Keep in mind that all data written to the source cluster after the snapshot is taken must be manually copied to the target cluster after the migration.

Resize operation speed

Because the elastic resize operation doesn't create a new cluster, the operation usually completes quickly. The time required to complete a classic resize or a snapshot and restore operation might vary, based on the following factors:

  • The workload on the source cluster.
  • The number and size of the tables being transferred.
  • How evenly data is distributed across the compute nodes and slices.
  • The node configuration in the source and target clusters.

To reduce the time required for a classic resize or a snapshot and restore operation:

To check the status of your resize operation using the Amazon Redshift console, choose the Status tab on the cluster details page. The Status tab shows the average rate of transfer, the elapsed time, and the remaining time.


Billing for resized clusters

  • During the resize operation, you're billed for the clusters that are available to you. For example, during the resize operation, you're billed for the source configuration. After the resize is complete, you're no longer billed for the source configuration. Billing starts for the target configuration as soon as the cluster status changes to available. When using the snapshot and restore method, you temporarily have an additional cluster, which you're billed for until you clean up your environment.
  • Resizing smaller node types (large, xlarge) to larger node types (8xlarge) requires more storage per node. The more storage you have per node, the more metadata is written when you run COMMIT. This means that the base cost for a single commit operation is higher for larger nodes. If you run many small commit operations, you might see a decrease in performance. For better performance, group multiple changes into a single commit operation.
  • If you purchased Reserved Instances, then billing depends on your resized cluster configuration, reserved node types, and the number of reserved nodes that are purchased. For more information, see How Reserved Nodes Work.

Did this page help you? Yes | No

Back to the AWS Support Knowledge Center

Need help? Visit the AWS Support Center

Published: 2017-11-06

Updated: 2019-02-07