Skip to main content

Triage and Remediation

Remediation

Using Console

In AWS, the EMR control doesn’t map directly to Redshift, but the equivalent for Redshift is: “Redshift clusters should use current-generation node types (e.g., RA3 instead of DS2/DC1/DC2).”
Below are step‑by‑step console instructions to migrate a Redshift cluster to latest‑generation instances.

1. Identify if your Redshift cluster is on an old generation

  1. Sign in to the AWS Management Console.
  2. Go to Amazon Redshift service.
  3. In the left pane, click Clusters.
  4. For each cluster:
    • Click the cluster identifier to open its details.
    • In the General information or Properties section, note the Node type (e.g., ds2.xlarge, dc1.large, dc2.large, etc.).
  5. If the node type is not RA3 (e.g., ra3.xlplus, ra3.4xlarge, ra3.16xlarge), it is not latest-generation.

2. Plan the migration (choose target RA3 node type)

  1. Estimate current cluster size and workload (concurrency, CPU, storage).
  2. From the Redshift pricing / documentation, decide an RA3 node type:
    • Common options: ra3.xlplus, ra3.4xlarge, ra3.16xlarge.
  3. Ensure your Region supports the RA3 node type you choose.

3. Create a snapshot (backup) of the existing cluster

  1. Still in the Clusters page, select your existing cluster.
  2. Click ActionsTake snapshot.
  3. Provide a Snapshot name.
  4. Click Create snapshot and wait until the status becomes Available.

4. Resize the existing cluster to a latest‑generation node type

You have two main console options: Elastic resize (faster, with some constraints) or Classic resize (slower, more flexible). The console will show what’s available.
  1. In Clusters, select the cluster.
  2. Click ActionsResize (or Modify depending on console version).
  3. In the resize wizard:
    • Under Node type, choose the RA3 node type (e.g., ra3.xlplus).
    • Adjust Number of nodes if needed.
    • Choose Elastic resize if it’s offered and supports your change; otherwise, use Classic resize.
  4. Review the impact:
    • Note possible performance impact or brief unavailability.
  5. Click Resize / Modify cluster to start the operation.
  6. Wait until the cluster status returns to Available and the new Node type shows the RA3 instance.

5. (Alternative) Create a new RA3 cluster and migrate

If you prefer not to resize in place:
  1. From Snapshots, select the snapshot you created.
  2. Click ActionsCreate cluster from snapshot.
  3. Set:
    • A new Cluster identifier.
    • Node type to an RA3 type.
    • Adjust Number of nodes as needed.
  4. Complete the wizard to create the new cluster.
  5. Update:
    • Any applications, BI tools, and connection strings to point to the new cluster endpoint.
  6. After verifying everything works, decommission the old cluster:
    • In Clusters, select the old cluster → ActionsDelete.
    • Optionally take a final snapshot before deletion.

6. Verify and document compliance

  1. In Clusters, confirm:
    • Node type is RA3 for all production clusters.
  2. Optionally, tag the clusters (e.g., Key=Compliance, Value=LatestGeneration) for tracking.
  3. Update your internal runbooks / standards to mandate RA3 for new Redshift clusters.
For Redshift, “latest generation” generally means RA3 node types (ra3.xlplus / ra3.4xlarge / ra3.16xlarge) instead of legacy dc2/ds2 nodes.
You can’t in‑place change the instance family; you must resize the cluster to a newer node type.
Below are step‑by‑step AWS CLI steps.

1. List your Redshift clusters and current node types

Identify clusters using old node types (e.g., ds2.xlarge, ds2.8xlarge, dc2.large, dc2.8xlarge).

2. Choose an appropriate latest‑gen node type

Common RA3 options:
  • ra3.xlplus – smaller/cheaper
  • ra3.4xlarge – mid‑range
  • ra3.16xlarge – largest
You must pick a compatible size for your workload and region.
(You can confirm supported node types in docs or via console; CLI has no direct “list node types” API.)

3. Check cluster details before change

Note:
  • NumberOfNodes
  • ClusterType (e.g., multi-node or single-node)
  • Any special settings you’ll need to preserve.

4. Resize the cluster to RA3 (classic resize)

Use modify-cluster with --node-type.
For example, change to ra3.xlplus:
Notes:
  • --number-of-nodes is required when the node type changes on multi-node clusters.
  • Use --cluster-type single-node if your cluster is single-node.
  • Remove --no-skip-final-cluster-snapshot and instead add --skip-final-cluster-snapshot only if you explicitly do NOT want a final snapshot.

5. Monitor resize progress

Wait until status is available.

6. Verify the cluster is on latest‑gen nodes

NodeType should now be one of the RA3 types.

7. (Optional) Automate remediation across all clusters

Example shell loop:
Adjust node counts and types per your requirements.
For Redshift this translates to: “Redshift clusters should use latest‑generation node types (RA3 instead of older DS*/DC*).”
Below is how to identify non‑latest clusters and remediate them with Python (boto3).

1. Prerequisites

  • boto3 installed:
  • AWS credentials configured (via aws configure, env vars, or IAM role).
  • Decide your target node type, e.g. ra3.4xlarge or ra3.xlplus.
  • Understand Redshift resize is disruptive and can take time; plan for a maintenance window.

2. Identify Clusters Using Old Node Types

This lets you confirm which clusters are using older generations (e.g., dc2.large, ds2.xlarge).

3. Plan the Target Node Type and Size

You must choose:
  • A target RA3 node type, e.g.:
    • ra3.xlplus
    • ra3.4xlarge
    • ra3.16xlarge
  • The target number of nodes.
Simple example mapping (adjust for your environment):

4. Perform a Classic Resize to RA3 With Python

Changing node type in Redshift is done via resize_cluster. This is disruptive and can take a while.

5. Integrate With a Compliance/Misconfiguration Check

To automatically remediate “EMR/Redshift nodes should use latest generation”:
  1. Periodically run a script or Lambda that:
    • Lists clusters.
    • Flags those where NodeType is not RA3.
    • Either:
      • Sends alerts, or
      • Triggers the resize logic above (ideally gated by tags or an allow‑list).
  2. Optionally, align this with AWS Config:
    • Use a custom AWS Config rule (Lambda) that checks Redshift node types.
    • If non‑RA3, mark non‑compliant and optionally trigger remediation via SSM or another Lambda using the same resize_cluster logic.

If you tell me your current node types and approximate cluster sizes, I can suggest more concrete RA3 mappings.
Changing node_type forces replacement of the Redshift cluster, which is an outage-prone operation and will destroy/recreate the cluster and its data unless you design a migration strategy (snapshots, restore to new cluster, cutover, etc.).To verify, terraform plan should show an in-place ~ change to node_type accompanied by -/+ (destroy/create) for aws_redshift_cluster.this, indicating the cluster will be replaced with the new, latest-generation node type.