Amazon RedshiftにGraviton3EベースのRGインスタンスが登場しました

2026年5月12日の AWS News Blog で以下が発表されました。

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/

石川さんの記事（2024/10）で紹介された ra3.large を含む RA3 ファミリーに対し、次世代のノードタイプとして Graviton ベースの RG インスタンスが登場した形です。

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

本記事では東京リージョンで RG インスタンスを起動し、基本動作と統合データレイクエンジンの挙動を確認しました。

RGインスタンスとは

アーキテクチャ

RG インスタンスは以下の特徴を持つ新世代ノードタイプです。

• Graviton3E（Enhanced）プロセッサ採用 — Amazon Redshift として初の Graviton ベースノードです。Graviton3E は EC2 の C7gn（ネットワーク最適化）や Hpc7g（HPC）で採用実績のある、Graviton3 世代の強化版プロセッサです
• ストレージ・コンピュート分離は RA3 と同様 — Redshift Managed Storage（RMS）を利用します
• 統合データレイクエンジン内蔵 — S3 上の Parquet / Iceberg データへのクエリを、Spectrum 外部フリートを経由せずクラスタノード上で直接実行します

パフォーマンス

公式ブログでは以下の数値が示されています。

コスト構造の変化

• RG の統合データレイクエンジンで実行されるクエリでは、Redshift Spectrum の $5/TB スキャン課金が発生しません
• データレイククエリはクラスタノード上の統合エンジンで実行されます（Spectrum 外部フリート不要）

スペック比較

公式ドキュメントから確認したスペック表です。

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

注目ポイント：

• rg.4xlarge はスライス数が 8（ra3.4xlarge の 4 から倍増）で、並列処理能力が向上しています
• RG はシングルノード非対応です。最小構成は 2 ノードになります
• ra3.16xlarge 相当の RG は現時点で未発表です

RGインスタンスを起動してみた

東京リージョン（ap-northeast-1）で rg.xlarge を起動しました。

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 '****'

接続確認は同一 VPC 内の踏み台 EC2（t4g.micro、SSM Session Manager）から行いました。実際の環境では、必要に応じて --cluster-subnet-group-name や --vpc-security-group-ids を指定してください。

起動時の注意点

シングルノードで起動しようとするとエラーになります。

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

現時点で提供されている RG インスタンスはシングルノード非対応で、最小構成は 2 ノードです。

起動結果

今回の環境では約 1 分 40 秒で available になりました。

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
}

起動後の確認：

DB接続でシステム情報を確認

踏み台 EC2 から psql で接続し、システム情報を確認しました。

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

i686-pc-linux-gnu と表示されますが、Redshift の version() はアーキテクチャを正確に反映しない仕様です。実際は Graviton3E（ARM/aarch64）で動作しています。

stv_node_storage_capacity

SELECT * FROM stv_node_storage_capacity;

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

capacity は MB 単位で表示されており、32,000,000 MB ≒ 32 TB です。公式スペック通りでした。

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 ノード × 2 スライス/ノード = 計 4 スライスです。公式スペック通りでした。

統合データレイクエンジンを試す

S3 上の Parquet ファイルに対して、従来と同じ外部テーブル構文でクエリできることを確認しました。なお、本記事では基本動作確認を目的としており、RA3 との性能比較や Iceberg テーブルの検証は扱いません。

手順

1. IAM ロールをクラスタにアタッチ
2. S3 にサンプル Parquet を配置
3. 外部スキーマ・テーブル作成
4. クエリ実行

IAMロールのアタッチ

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

外部スキーマ・テーブル作成とクエリ

-- 外部スキーマ作成（Glue Data Catalog 連携）
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;

-- S3 上の Parquet を外部テーブルとして定義
CREATE EXTERNAL TABLE datalake_test.cities (
  id INT,
  name VARCHAR(100),
  population BIGINT
)
STORED AS PARQUET
LOCATION 's3://bucket-name/cities/';

-- データレイククエリ実行
SELECT * FROM datalake_test.cities ORDER BY population DESC;

結果

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

S3 上の Parquet ファイルに対するクエリが成功しました。今回試した範囲では、従来の 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

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)

DWH テーブルと S3 データレイクのデータを、従来と同じ SQL で JOIN できました。

svl_s3query_summary

今回確認した範囲では、外部テーブルクエリの統計確認に従来の svl_s3query_summary ビューを利用できました。

後片付け

検証後はクラスタを削除します。RG インスタンスは時間課金のため、不要になったら速やかに削除してください。

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

--skip-final-cluster-snapshot を指定すると最終スナップショットは作成されません。必要なデータがある場合は、最終スナップショットを取得してから削除してください。

あわせて、検証用に作成した S3 オブジェクト、Glue Data Catalog のデータベース/テーブル、踏み台 EC2 も不要であれば削除します。

費用情報

オンデマンド料金（ノードあたり）

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

rg.xlarge 2ノード構成の月額試算（東京リージョン、インスタンス料金のみ）

RG の最小構成は 2 ノードです。ra3.xlplus と同スペック帯の rg.xlarge で、インスタンス料金のみを比較します。

同じ 4 vCPU × 2 ノード構成で、インスタンス料金は月額約 $560 の削減になります。RMS、S3、Glue Data Catalog、KMS などの料金は別途発生します。

公式計算例（US East、4ノード、大規模構成）

公式料金ページの Pricing Examples セクションから引用します。条件: 4 ノード、40 TB RMS、20 TB データレイクスキャン/月、オンデマンド。

RMS 料金

RG / RA3 共通です。料金はリージョンにより異なるため、最新情報は料金ページを確認してください。

移行パス

RA3 から RG への移行方法として、公式ブログでは以下が案内されています。

• Elastic Resize — 対応構成であればインプレース移行が可能。公式ブログでは 10-15 分のダウンタイムと記載
• Snapshot and Restore — RA3 スナップショットから RG クラスタを作成。構成変更を伴う移行に適する

今回試した範囲では、既存の外部テーブル・スキーマ・クエリ構文はそのまま利用できました。利用可能な移行方式と所要時間はクラスタ構成により異なるため、本番移行前に検証環境での確認を推奨します。

RA3→RG 移行時の注意点

• RG はシングルノード非対応のため、ra3.large/ra3.xlplus のシングルノード環境から移行する場合は、最小 2 ノード構成への変更が必要です
• ra3.16xlarge 相当の RG は現時点で未発表です

まとめ

Amazon Redshift に Graviton3E ベースの RG インスタンスが登場し、東京リージョンで起動・接続・データレイククエリの動作を確認できました。従来の外部テーブル構文がそのまま使え、Redshift Spectrum の $5/TB スキャン課金が発生しない点が最大の変化です。

RGインスタンスが向いているケース

• データレイク（S3）を頻繁にクエリする環境
• Redshift Spectrum のスキャン課金を削減したい環境
• BI やアプリケーションから多数の分析クエリが発生する環境
• RA3 からのコスト最適化を検討している環境（vCPU あたり 30% 低コスト）
• 既に Redshift クラスタを運用している環境で、Athena や Spectrum で実行していたデータレイククエリの一部を RG に寄せれば、スキャン課金を削減できる余地がある（ただし RG クラスタの固定費とのトレードオフは要試算）

引き続きRA3が適しているケース

• シングルノードで最小コスト運用したい場合（ra3.large: $0.639/h 東京）
• rg.4xlarge を超える大規模ノードサイズが必要な場合（ra3.16xlarge: 48 vCPU / 384 GiB）
• 開発・検証環境で最小構成を求める場合

GA 直後のため今後ラインナップが拡充される可能性もあります。データレイク統合を検討中の方はぜひ試してみてください。

参考リンク

• 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
• 先行記事: Amazon Redshift 新しい最小インスタンス ra3.large がリリースされました！