Classic Resize Redshift Cluster status on modifying

This can be related to the amount of data in your cluster. It might be best if you open Support Ticket and request for Chat option to get this looked into.

The duration of the "modifying" state in classic resize depends on several factors, including:

1. The amount of data in the cluster
2. The workload on the source cluster
3. The number and size of tables being transferred
4. How evenly data is distributed across nodes and slices
5. The node configuration in source and target cluster

To reduce the time that's required for a classic resize, complete the following tasks:

1. Fix skewed tables, and choose an appropriate distribution key.
2. Remove unused tables. To identify unused tables, run the unscanned_table_summary.sql script from the GitHub website. Note: The unscanned table summary shows only the history from the past few days. To capture usage data over a longer period of time, use the SystemTablePersistence utility from the GitHub website.

Classic v/s Elastic Resize

• Elastic resize – You can add nodes to or remove nodes from your cluster. You can also change the node type, such as from DC2 nodes to RA3 nodes. An elastic resize typically completes quickly, taking ten minutes on average. For this reason, we recommend it as a first option. When you perform an elastic resize, it redistributes data slices, which are partitions that are allocated memory and disk space in each node. Elastic resize is appropriate when you:
  • Add or reduce nodes in an existing cluster, but you don't change the node type – This is commonly called an in-place resize. When you perform this type of resize, some running queries complete successfully, but others can be dropped as part of the operation.
  • Change the node type for a cluster – When you change the node type, a snapshot is created and data is redistributed from the source cluster to a cluster comprised of the new node type. On completion, running queries are dropped. Like the in-place resize, it completes quickly.
• Classic resize – You can change the node type, number of nodes, or both, in a similar manner to elastic resize. Classic resize takes more time to complete, but it can be useful in cases where the change in node count or the node type to migrate to doesn't fall within the bounds for elastic resize. This can apply, for instance, when the change in node count is really large.

For more information on resizing cluster refer the link

In your case dc2.large 4 nodes to dc2.large 5 nodes, elastic resize can not be a option because for dc2.large instance type you can either resize to 2x (8 nodes) or half (2 nodes) using elastic resize. Since your requirement is to go from 4 to 5 node, classic resize is only the option.

If your cluster is still stuck in 'Modifying' state, please reach out to AWS support.