Graviton-based RG Instances Are Now Available in Amazon Redshift

The AWS News Blog announced the following on May 12, 2026.

Amazon Redshift RG instances deliver better performance, running data warehouse workloads up to 2.2x as fast as RA3 instances at 30% lower price per vCPU. Their integrated data lake query engine lets you run SQL analytics across your data warehouse and data lake from a single engine.

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

Graviton-based RG instances have arrived as the next-generation node type, following the RA3 family, which includes the ra3.large introduced in Ishikawa-san's article (October 2024).

https://dev.classmethod.jp/articles/20241002-amazon-redshift-ra3large/

In this article, I launched an RG instance in the Tokyo region and checked its basic behavior and the behavior of the integrated data lake engine.

What are RG instances?

Architecture

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

• Graviton processor — This is the first Graviton-based node in Amazon Redshift.
• Storage and compute separation is the same as RA3 — They use Redshift Managed Storage (RMS)
• Built-in integrated data lake engine — Queries against Parquet / Iceberg data on S3 run directly on the cluster nodes, without going through the Spectrum external fleet

Performance

The official blog presents the following figures.

Changes in the cost structure

• Queries executed by the RG integrated data lake engine are not subject to the Redshift Spectrum $5/TB scan charge
• Data lake queries are executed by the integrated engine on the cluster nodes (no Spectrum external fleet required)

Spec comparison

This is the spec table I confirmed from the official documentation.

https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html

Points of note:

• rg.4xlarge has 8 slices (double the 4 of ra3.4xlarge), which improves parallel processing capability
• RG does not support single-node configurations. The minimum configuration is 2 nodes
• An RG equivalent to ra3.16xlarge has not been announced as of now

Launching an RG instance

I launched an rg.xlarge in the Tokyo region (ap-northeast-1).

aws redshift create-cluster \
  --region ap-northeast-1 \
  --cluster-identifier rg-xlarge-test \
  --cluster-type multi-node \
  --node-type rg.xlarge \
  --number-of-nodes 2 \
  --master-username admin \
  --master-user-password '****'

I verified the connection from a bastion EC2 instance (t4g.micro, SSM Session Manager) in the same VPC. In a real environment, specify --cluster-subnet-group-name and --vpc-security-group-ids as needed.

Notes on launching

Attempting to launch as a single node results in an error.

InvalidParameterValue: single-node with rg.xlarge is not supported.

The RG instances currently offered do not support single-node configurations, and the minimum configuration is 2 nodes.

Launch result

In this environment, the cluster became available in about 1 minute 40 seconds.

aws redshift describe-clusters \
  --cluster-identifier rg-xlarge-test \
  --query "Clusters[0].{Status:ClusterStatus,Endpoint:Endpoint.Address,Nodes:NumberOfNodes}"

{
    "Status": "available",
    "Endpoint": "rg-xlarge-test.xxxxxxxxxxxx.ap-northeast-1.redshift.amazonaws.com",
    "Nodes": 2
}

Checks after launch:

Checking system information via DB connection

I connected with psql from the bastion EC2 and checked the system information.

version()

SELECT version();

PostgreSQL 8.0.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3), Redshift 1.0.292316

It displays i686-pc-linux-gnu, but Redshift's version() does not accurately reflect the architecture. It actually runs on Graviton (ARM/aarch64).

stv_node_storage_capacity

SELECT * FROM stv_node_storage_capacity;

 node | used | capacity
------+------+----------
    1 |   22 | 32000000
    0 |   47 | 32000000

Capacity is displayed in MB, and 32,000,000 MB ≒ 32 TB. It matched the official spec.

stv_slices

SELECT * FROM stv_slices;

 node | slice | localslice | type
------+-------+------------+------
    1 |     2 |          0 | D
    1 |     3 |          1 | D
    0 |     0 |          0 | D
    0 |     1 |          1 | D

2 nodes × 2 slices/node = 4 slices in total. It matched the official spec.

Trying the integrated data lake engine

I confirmed that Parquet files on S3 can be queried using the same external table syntax as before. Note that this article aims at basic operation checks, and does not cover performance comparison with RA3 or verification of Iceberg tables.

Steps

1. Attach an IAM role to the cluster
2. Place sample Parquet files in S3
3. Create an external schema and table
4. Run the query

Attaching the IAM role

aws redshift modify-cluster-iam-roles \
  --region ap-northeast-1 \
  --cluster-identifier rg-xlarge-test \
  --add-iam-roles arn:aws:iam::xxxxxxxxxxxx:role/service-role/AmazonRedshift-CommandsAccessRole-xxxxxxxx

Creating the external schema and table, and querying

-- Create external schema (Glue Data Catalog integration)
CREATE EXTERNAL SCHEMA IF NOT EXISTS datalake_test
FROM DATA CATALOG
DATABASE 'redshift_rg_test'
IAM_ROLE 'arn:aws:iam::xxxxxxxxxxxx:role/service-role/AmazonRedshift-CommandsAccessRole-xxxxxxxx'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

-- Define Parquet on S3 as an external table
CREATE EXTERNAL TABLE datalake_test.cities (
  id INT,
  name VARCHAR(100),
  population BIGINT
)
STORED AS PARQUET
LOCATION 's3://bucket-name/cities/';

-- Run data lake query
SELECT * FROM datalake_test.cities ORDER BY population DESC;

Results

 id |  name   | population
----+---------+------------
  1 | Tokyo   |   14000000
  2 | Osaka   |    8800000
  3 | Nagoya  |    2300000
  5 | Sapporo |    1900000
  4 | Fukuoka |    1600000
(5 rows)

The query against the Parquet files on S3 succeeded. Within the scope I tried, it worked as is with the same external schema/external table syntax as the conventional RA3 + Spectrum.

EXPLAIN

EXPLAIN SELECT * FROM datalake_test.cities WHERE population > 2000000;

                                              QUERY PLAN
----------------------------------------------------------------------------------------------------
 XN Seq Scan datalake_test.cities location:"s3://redshift-rg-datalake-test-xxxx/cities" format:PARQUET
   Filter: (population > 2000000)
(2 rows)

JOIN with a local table

CREATE TABLE local_regions (id INT, region VARCHAR(50));
INSERT INTO local_regions VALUES (1,'Kanto'),(2,'Kansai'),(3,'Chubu'),(4,'Kyushu'),(5,'Hokkaido');

SELECT c.name, c.population, r.region
FROM datalake_test.cities c
JOIN local_regions r ON c.id = r.id
ORDER BY c.population DESC;

  name   | population |  region
---------+------------+----------
 Tokyo   |   14000000 | Kanto
 Osaka   |    8800000 | Kansai
 Nagoya  |    2300000 | Chubu
 Sapporo |    1900000 | Hokkaido
 Fukuoka |    1600000 | Kyushu
(5 rows)

I was able to JOIN DWH table data and S3 data lake data using the same SQL as before.

svl_s3query_summary

Within the scope I checked, the conventional svl_s3query_summary view could be used to check statistics of external table queries.

Cleanup

Delete the cluster after verification. RG instances are billed hourly, so delete them promptly when no longer needed.

aws redshift delete-cluster \
  --region ap-northeast-1 \
  --cluster-identifier rg-xlarge-test \
  --skip-final-cluster-snapshot

If you specify --skip-final-cluster-snapshot, no final snapshot is created. If you have data you need, take a final snapshot before deleting.

In addition, delete the S3 objects, the Glue Data Catalog database/tables, and the bastion EC2 created for verification if they are no longer needed.

Cost information

On-demand pricing (per node)

https://aws.amazon.com/redshift/pricing/

Monthly estimate for a 2-node rg.xlarge configuration (Tokyo region, instance charges only)

The minimum RG configuration is 2 nodes. I compare instance charges only, using rg.xlarge, which is in the same spec range as ra3.xlplus.

With the same 4 vCPU × 2 nodes configuration, instance charges are reduced by about $560 per month. Charges for RMS, S3, Glue Data Catalog, KMS, and so on are incurred separately.

Official calculation example (US East, 4 nodes, large-scale configuration)

Quoted from the Pricing Examples section of the official pricing page. Conditions: 4 nodes, 40 TB RMS, 20 TB data lake scan/month, on-demand.

RMS pricing

It is the same for RG and RA3. Prices vary by region, so check the pricing page for the latest information.

Migration paths

The official blog describes the following methods for migrating from RA3 to RG.

• Elastic Resize — In-place migration is possible for supported configurations. The official blog states 10-15 minutes of downtime
• Snapshot and Restore — Create an RG cluster from an RA3 snapshot. Suitable for migrations involving configuration changes

Within the scope I tried, existing external tables, schemas, and query syntax worked as is. Available migration methods and the time required vary depending on the cluster configuration, so we recommend verifying in a test environment before a production migration.

Notes when migrating from RA3 to RG

• Because RG does not support single-node configurations, migrating from a single-node ra3.large/ra3.xlplus environment requires changing to a configuration of at least 2 nodes
• An RG equivalent to ra3.16xlarge has not been announced as of now

Summary

Graviton-based RG instances have arrived in Amazon Redshift, and I was able to confirm launching, connecting, and data lake query behavior in the Tokyo region. The biggest changes are that the conventional external table syntax can be used as is, and that the Redshift Spectrum $5/TB scan charge is not incurred.

Cases where RG instances are a good fit

• Environments that frequently query the data lake (S3)
• Environments that want to reduce Redshift Spectrum scan charges
• Environments where many analytical queries are issued from BI or applications
• Environments considering cost optimization from RA3 (30% lower cost per vCPU)
• In environments already running a Redshift cluster, shifting some of the data lake queries that were executed with Athena or Spectrum to RG may leave room to reduce scan charges (however, the trade-off with the fixed costs of the RG cluster needs to be estimated)

Cases where RA3 remains a good fit

• When you want to operate at minimum cost with a single node (ra3.large: $0.639/h in Tokyo)
• When you need node sizes larger than rg.4xlarge (ra3.16xlarge: 48 vCPU / 384 GiB)
• When you want a minimal configuration for development and test environments

Since this is right after GA, the lineup may be expanded in the future. If you are considering data lake integration, please give it a try.

References

• AWS News Blog: Amazon Redshift introduces AWS Graviton-based RG instances with an integrated data lake query engine
• Amazon Redshift RG Features
• Amazon Redshift Management Guide — Clusters and nodes
• Amazon Redshift Pricing
• AWS Pricing Calculator
• Previous article: The new minimum instance ra3.large for Amazon Redshift has been released!