I Tried a Blue-Green Migration to Amazon Redshift RG Instances Using Snapshot Restore

I'm Ishikawa from the Cloud Business Division. AWS Graviton-based RG instances have been released for Amazon Redshift. I actually tried migrating from a ra3.xlplus 2-node cluster to an rg.xlarge 2-node cluster using the snapshot restore method (Blue-Green) in us-east-1.

https://aws.amazon.com/jp/about-aws/whats-new/2026/05/amazon-redshift-rg-instances-powered-by-graviton/

Amazon Redshift RG instances powered by Graviton processors became generally available on May 12, 2026. Like RA3, they use Redshift Managed Storage, but the compute is Graviton-based, and the cluster has a built-in integrated engine for data lake queries. It has been announced to be 30% cheaper per vCPU than RA3, with up to 2.4x faster performance on Apache Iceberg and up to 1.5x faster on Apache Parquet.

https://aws.amazon.com/jp/blogs/aws/amazon-redshift-introduces-aws-graviton-based-rg-instances-with-an-integrated-data-lake-query-engine/

This time, following the migration requirements from the ra3.xlplus 2-node cluster xlplus2 used in the previous verification blog to an RG-family rg.xlarge 2-node cluster (internal project name: dgm, a dg instance), I ran this verification to measure Method B (Blue-Green with snapshot restore + identifier switching) using a lightweight dataset.

Following the migration requirements from the ra3.xlplus 2-node cluster in the previous verification blog to an RG-family rg.xlarge 2-node cluster, I ran this verification to measure Method B (Blue-Green with snapshot restore + identifier switching) using a lightweight dataset.

What are RG instances?

RG instances are a new-generation node type with the following characteristics.

• Graviton processors — The first Graviton-based node for Amazon Redshift.
• Built-in integrated data lake engine — Queries against Parquet / Iceberg data on S3 run directly on the cluster nodes without going through the external Spectrum fleet.

https://dev.classmethod.jp/articles/amazon-redshift-rg-instances-graviton/

RG instances are offered in the following two sizes.

rg.xlarge has the same combination of 4 vCPU / 32 GiB as ra3.xlplus, and AWS's official recommended mapping is also one rg.xlarge node for each ra3.xlplus node. The xlplus2 (2 nodes) → dgm (2 nodes) configuration this time follows that recommendation.

https://docs.aws.amazon.com/redshift/latest/mgmt/managing-cluster-considerations.html

The biggest difference between RA3 and RG is how data lake queries are executed. RA3 goes through a separate fleet called Redshift Spectrum and incurs a scan charge of $5/TB. With RG, on the other hand, the "integrated data lake engine" runs on the cluster's own compute, so everything stays within the VPC boundary and no Spectrum scan charges are incurred.

Note that migrating from RA3 / DC2 to RG requires the source cluster to be on Patch 201 or later. In this verification, I confirmed in advance that this condition was met.

Trying it out

Prerequisites

• AWS Region: us-east-1 (N. Virginia)
• Source cluster: xlplus2 (ra3.xlplus × 2 nodes, database dev, master user awsuser)
• Target cluster: dgm-verify (newly created with rg.xlarge × 2 nodes)
• Benchmark data: TPC-H 10GB scale Iceberg tables (s3://rg2-iceberg-<AWS_ACCOUNT_ID>-us-east-1/tpch10g_iceberg/, registered in the tpch10g_iceberg database of the Glue Data Catalog)
• Verification date: 2026-05-17
• Verification query: TPC-H Q1-style aggregation (GROUP BY aggregation over 59 million rows of lineitem)

Comparing and selecting migration methods

The official ways to migrate from RA3 to RG can be broadly organized into the following three.

https://docs.aws.amazon.com/redshift/latest/mgmt/managing-cluster-considerations.html

The use case this time has the following characteristics.

• The node count is 2 → 2 and the slice count is 4 → 4, with no change (C is unnecessary)
• We want to confirm the data lake query performance improvement with actual Iceberg measurements before going to production (we want to secure a verification period)
• We want to keep the existing xlplus2 so that we can roll back immediately if problems arise
• We want to identify differences in inherited settings such as IAM roles and WLM before the production switchover

The option that best satisfies these conditions is Method B (Blue-Green with Snapshot Restore + identifier switching). Although Elastic Resize takes less time, no old cluster remains, which makes rollback difficult, and IAM role inheritance differences cannot be checked before switching. This time Method B is the primary choice, and this verification demonstrates everything from preparation to the verification phase (the identifier swap in actual operation is assumed to be performed separately).

Overall migration procedure

The steps performed in this verification are shown in the diagram.

Step 1: Restore dgm-verify from a snapshot

Restore an automated snapshot of xlplus2 as dgm-verify with an rg.xlarge 2-node configuration. Simply specifying --node-type rg.xlarge lets you restore with a different node type.

aws redshift restore-from-cluster-snapshot \
  --region us-east-1 \
  --cluster-identifier dgm-verify \
  --snapshot-identifier "rs:xlplus2-2026-05-17-05-53-51-821" \
  --node-type rg.xlarge \
  --number-of-nodes 2 \
  --cluster-subnet-group-name default \
  --no-publicly-accessible

{
    "Id": "dgm-verify",
    "Status": "creating",
    "NodeType": "rg.xlarge",
    "Nodes": 2,
    "VpcId": "vpc-7814de1d"
}

Partly because it was a relatively small dataset at 10GB scale, it took about 3 minutes to go from creating to available.

Step 2: Re-attach the IAM role

When I checked dgm-verify with describe-clusters right after the restore, IamRoles was an empty array. IAM roles are not inherited during snapshot restore, so they must be explicitly re-attached.

aws redshift describe-clusters \
  --region us-east-1 \
  --cluster-identifier dgm-verify \
  --query 'Clusters[0].IamRoles'

To reference the Iceberg tables on S3 through an external schema, I also add the IAM role xlplus2-s3-read, which was already created for xlplus2, to dgm-verify.

aws redshift modify-cluster-iam-roles \
  --region us-east-1 \
  --cluster-identifier dgm-verify \
  --add-iam-roles arn:aws:iam::<AWS_ACCOUNT_ID>:role/xlplus2-s3-read

{
    "Id": "dgm-verify",
    "Roles": [
        "arn:aws:iam::<AWS_ACCOUNT_ID>:role/xlplus2-s3-read"
    ],
    "Status": "modifying"
}

I polled until it became in-sync, and this too was reflected in about 30 seconds.

Step 3: Create the external schema

Create an external schema that references the same Glue database tpch10g_iceberg on both clusters. This is executed via the Redshift Data API.

On the xlplus2 side:

CREATE EXTERNAL SCHEMA IF NOT EXISTS tpch_iceberg
FROM DATA CATALOG
DATABASE 'tpch10g_iceberg'
IAM_ROLE 'arn:aws:iam::<AWS_ACCOUNT_ID>:role/xlplus2-s3-read';

The dgm-verify side could also be created with the same DDL without any problems. The CREATE EXTERNAL SCHEMA syntax is the same for both RA3 and RG, so external schemas and existing Spectrum queries can be reused as they are.

Step 4: Run the benchmark query

I ran a TPC-H Q1-style aggregation query three times on each cluster. The query is a GROUP BY aggregation over lineitem (Iceberg, 59 million rows, about 2.9 GB).

SELECT
  l_returnflag,
  l_linestatus,
  SUM(l_quantity)              AS sum_qty,
  SUM(l_extendedprice)         AS sum_base_price,
  SUM(l_extendedprice * (1 - l_discount))                       AS sum_disc_price,
  SUM(l_extendedprice * (1 - l_discount) * (1 + l_tax))         AS sum_charge,
  AVG(l_quantity)              AS avg_qty,
  AVG(l_extendedprice)         AS avg_price,
  AVG(l_discount)              AS avg_disc,
  COUNT(*)                     AS count_order
FROM tpch_iceberg.lineitem
WHERE l_shipdate <= DATE '1998-09-02'
GROUP BY l_returnflag, l_linestatus
ORDER BY l_returnflag, l_linestatus;

The following are the execution times (Duration, in nanoseconds) obtained from the Redshift Data API describe-statement, converted to seconds.

Based on the three-run average, the speedup was about 3.45x, and comparing the third run (warm state), it was about 3.95x faster. This exceeds the "up to 2.4x for Iceberg" figure announced by AWS.

Step 5: Verify data consistency

Beyond performance, I verify that both clusters return identical results.

SELECT l_returnflag, l_linestatus, COUNT(*) AS cnt
FROM tpch_iceberg.lineitem
WHERE l_shipdate <= DATE '1998-09-02'
GROUP BY 1,2
ORDER BY 1,2;

Result on the xlplus2 side:

l_returnflag | l_linestatus |    cnt
-------------+--------------+-----------
 A           | F            | 14804077
 N           | F            |   385998
 N           | O            | 29144351
 R           | F            | 14808183

Result on the dgm-verify side:

l_returnflag | l_linestatus |    cnt
-------------+--------------+-----------
 A           | F            | 14804077
 N           | F            |   385998
 N           | O            | 29144351
 R           | F            | 14808183

The total was 59,142,609 rows, and the counts for all 4 groups matched exactly. No data loss or duplication occurred due to the snapshot restore.

Discussion

Here is a summary of the findings from the verification.

• Significant speedup even with an equivalent configuration: Despite the equivalent configuration of 4 vCPU × 2 nodes, I observed an average of 3.45x and about 3.95x after warm-up for Iceberg queries, exceeding the announced figures. The effect of the integrated data lake engine, which doesn't go through Spectrum, is considered large.
• Snapshot Restore can migrate to a different node type: Just by specifying restore-from-cluster-snapshot --node-type rg.xlarge, I was able to build a 10GB-scale cluster in about 3 minutes. This is a practical enough duration for a migration rehearsal using the Blue-Green method.
• IAM roles are not inherited by snapshot restore: During verification, the biggest pitfall was that IAM roles are not inherited. Re-attaching them with modify-cluster-iam-roles is required for creating external schemas and accessing the Glue Data Catalog. It is worth explicitly listing this item in the rollback plan and risk table of the requirements document.
• No changes needed to external schema DDL: The CREATE EXTERNAL SCHEMA syntax is identical for RA3 and RG, and I could handle both Iceberg and Parquet just by specifying the Glue database. No application changes on the SQL side are required in this configuration.
• No Spectrum scan charges: Queries on the dgm-verify side run on the RG cluster's own compute, and the Spectrum $5/TB charge is not incurred. For data-lake-centric workloads, this is where the cost improvement has the greatest impact.

On the other hand, there were also points this verification could not cover.

• Snapshot restore time with large-scale data and workloads: It completed in about 3 minutes at 10GB scale, but at TB scale the restore time and behavior may change. You need to measure separately with your actual production data volume.
• Differences in concurrency scaling behavior: I measured the execution time of a single query, but the behavior of WLM / Concurrency Scaling under concurrent execution requires a separate workload replay test.
• Caveats for workloads that use Spectrum heavily: The official documentation states that "queries that use Spectrum heavily may become slower after migrating to RG, so consider increasing the node count or scaling up to rg.4xlarge." This time it was faster instead, but keep in mind that results may vary depending on workload characteristics.

Conclusion

In this guide, the migration procedure is explained using the AWS CLI (AWS commands) rather than the Management Console. This is because executing via commands is best for reproducing the verified migration procedure accurately and without discrepancies.

When I demonstrated Method B (Snapshot Restore + Blue-Green) from ra3.xlplus 2 nodes to rg.xlarge 2 nodes in us-east-1, the cluster could be restored in about 3 minutes, and I confirmed an average 3.45x speedup on the TPC-H Q1-style query along with complete data consistency. No application-side SQL changes are needed, and the external schema DDL works as is.

On the other hand, the fact that IAM roles are not inherited by snapshot restore is important practical information that should be explicitly stated in the migration procedure document. It is safest to always include the re-attachment step using modify-cluster-iam-roles.

If you operate workloads that also use a data lake on ra3.xlplus, I recommend first spinning up a lightweight verification cluster on rg.xlarge via Snapshot Restore and measuring your own workload-specific queries following the same flow as this article. I hope this article helps someone.

References

https://dev.classmethod.jp/articles/amazon-redshift-rg-instances-graviton/

https://dev.classmethod.jp/articles/20260516-amazon-redshift-benchmark-data/

https://dev.classmethod.jp/articles/20260517-amazon-redshift-rg-vs-ra3/

https://dev.classmethod.jp/articles/20241003-amazonredshift-dc2-to-ra3/