Opportunity Name

Redshift Retype RA3 to Graviton

AWS Resource Type

Amazon Redshift (provisioned clusters)

Opportunity Description

Amazon Redshift RG instances are the AWS Graviton-based successor to the RA3 node family. For the RA3 sizes that have an RG migration path, RG is priced lower per node-hour while providing the same or greater vCPU, memory, and managed storage capacity. The change is a backend node-family swap: your JDBC/ODBC endpoints, SQL interface, and application code are unchanged.

This CloudFix Finder scans your Cost and Usage Report for on-demand RA3 clusters, confirms with the Redshift API that the corresponding RG configuration is actually a valid resize destination for each specific cluster, prices the target node type from the AWS Price List API, and reports the projected annual savings using your own effective (post-discount) rate rather than list price. It is a recommendation-only Finder — CloudFix does not resize your clusters.

Criteria for Identifying the Opportunity

Reserved-covered clusters are excluded deliberately, not incidentally. Retyping a cluster while a Reserved Node commitment is in force strands the upfront commitment, so the recommendation would be economically irrational. CloudFix reads this from the CUR rather than from a Redshift API because Reserved Nodes can be owned by a consolidated-billing payer account different from the account running the cluster — the CUR reflects how the usage is actually billed regardless of which account holds the reservation.

Supported migrations

Every supported migration preserves or increases capacity. This Finder does not reduce node counts — reducing capacity on an over-provisioned cluster is a separate right-sizing problem and is not in scope here.

Potential Savings

Savings are computed per cluster from your actual billed cost, not from a flat percentage:

discountRatio         = annualized amortized cost ÷ annualized public on-demand cost

                        (capped at 1.0; falls back to 1.0 if either figure is zero,

                         negative, or not a finite number)

targetEffectiveRate   = target node public hourly price (AWS Price List API) × discountRatio

projectedAnnualCost   = targetNodeCount × targetEffectiveRate × 8760

annualSavings         = annualized amortized cost − projectedAnnualCost

The discountRatio term carries your EDP, PPA, or private-rate discount forward onto the RG projection, so the number you see reflects what you would actually pay rather than list price. If you have no negotiated discount, the ratio is 1.0

The size of the saving depends on which migration pair applies. Using AWS-published us-east-1 on-demand rates at the time this Finder was built:

• ra3.4xlarge → rg.4xlarge — roughly 6.7%, at $3.26/node-hour against $3.04267/node-hour, and you gain +33% vCPU and RAM at the same time. A single-node cluster running continuously moves from $28,557.60 to $26,653.79 per year, a saving of $1,903.81.

• ra3.16xlarge → 4× rg.4xlarge — also roughly 6.7%. Per source node, $13.04/hour becomes $12.171/hour (4 × $3.04267), with +33% vCPU and RAM headroom.

• ra3.xlplus → rg.xlarge — roughly 30%, the largest of the three, because rg.xlarge is priced well below ra3.xlplus for identical vCPU, RAM, and managed storage.

What Happens When the Fixer Is Executed?

This is a recommendation-only Finder. CloudFix does not execute any change. There is no fixer runbook and no change template for this opportunity — the Finder uses read-only Redshift and Pricing API calls exclusively.

CloudFix produces a report containing the cluster ARN, region, current node type, current node count, and current annual cost, alongside the target node type, target node count, projected annual cost, and estimated annual savings. The report also shows the derived discount ratio, so you can verify the arithmetic yourself.

To apply the change manually:

1. Review the recommendation and confirm the target node type and node count. Pay particular attention to ra3.16xlarge recommendations, where the node count increases fourfold.

2. Take a manual snapshot of the cluster before you begin.

3. Test the resize against a non-production clone restored from that snapshot, and verify your workload's query performance on the RG node family.

4. Schedule the resize for a low-traffic window.

5. Run the resize from the Redshift console (Actions → Resize) or with aws redshift resize-cluster --cluster-identifier <name> --node-type <rg type> --number-of-nodes <count>. Elastic resize is used where AWS supports it for the source-to-target pair; classic resize is the slower fallback.

6. Monitor cluster status until it returns to available, then validate query performance and any workload management configuration.

Once the cluster is running on RG, the next Finder run detects the new node type at validation V3 and closes out the recommendation.

Is It Possible to Roll Back Once CloudFix Implements the Fixer?

Not applicable — CloudFix does not implement a fix for this opportunity, so there is nothing for CloudFix to roll back.

If you perform the resize yourself and want to reverse it, you can resize the cluster back to its original RA3 node type and node count, subject to the resize targets AWS offers for the cluster at that time. Taking a manual snapshot before the resize gives you a restore path if you need one.

Can CloudFix Implement the Fix Automatically Once I Accept the Recommendation?

No. This opportunity is recommendation-only. Accepting the recommendation records your intent in CloudFix but does not trigger any change to your Redshift cluster — you must run the resize yourself through the AWS Console, CLI, or SDK.

Does This Fix Require Downtime?

Yes — the cluster is not fully available for the duration of the resize.

• Elastic resize, where AWS supports it for the source-to-target pair, requires only a brief read-only window and typically completes within minutes.

• Classic resize is the slower fallback and involves a longer outage, the length of which depends on your data volume.

Data, snapshots, and cluster configuration are preserved either way. Schedule the resize during a maintenance window or a period of low query activity, take a manual snapshot first, and validate on a non-production clone before touching the production cluster.

Additional Resources

• Amazon Redshift clusters and node types

• Resizing clusters in Amazon Redshift

• resize-cluster (AWS CLI reference)

• DescribeNodeConfigurationOptions (Amazon Redshift API reference)

• Amazon Redshift pricing

• Amazon Redshift snapshots and backups

• AWS announcement: Amazon Redshift RG instances powered by AWS Graviton

• AWS blog: Amazon Redshift introduces AWS Graviton-based RG instances with an integrated data lake query engine