Amazon Redshift Provisioned と Serverless の使い分け ── 選択基準と判断材料

本記事では、Redshift の採用を前提として、Provisioned と Serverless の使い分けについて整理します。 課金モデル・同時接続数・運用負荷の違いと、実務で選択を迷うポイントを順に説明します。 Provisioned と Serverless それぞれの特性を把握することで、データウェアハウス構成の選択を判断しましょう。

Redshift の位置付け ── 2 つのデプロイオプションが並立する理由

Amazon Redshift は、ペタバイト規模のデータウェアハウス (DWH) 向けに設計された列指向データベースサービスです。SQL クエリによる大規模集計・レポーティングを主用途とし、Athena (S3 へのアドホッククエリ) や RDS (OLTP) とは異なる位置付けです。

Redshift のデプロイオプションは、現在 Provisioned クラスター と Serverless の 2 種類が存在します。両者はクエリエンジンを共有しており、SQL 構文・JDBC/ODBC 接続・外部スキーマ連携といったアプリケーション層の互換性はほぼ保たれています。

ただし両者は 「キャパシティを固定して持つか、必要時にだけ動的に呼び出すか」 という設計思想が根本的に異なります。この違いから、課金モデル・同時接続のスケール・運用負荷といった実務上の差がすべて派生します。

選択を誤ると「常時起動のクラスターに払い続ける」あるいは「予期しない RPU 課金で月末の請求額が急増する」という結果につながります。

Provisioned クラスターの仕組み ── ノード構成と課金モデル

ノードタイプとクラスター構成

Provisioned クラスターは、リーダーノード 1 台 + コンピュートノード N 台の固定構成で動作します。ノードタイプは RA3 シリーズが現在の主力です。

RA3 はコンピュートとストレージを分離した設計です。データの格納先は S3 ベースの Amazon Redshift Managed Storage (RMS) で、ノード数を増やすことでコンピュート性能をスケールでき、ストレージはノード数に依存せず独立して拡張できます。

Provisioned の課金モデル

Provisioned の課金単位は ノード時間 です。東京リージョン (ap-northeast-1) における RA3 の料金 (オンデマンド) は次のとおりです (最新の正確な値は 公式料金ページ で確認してください)。

クラスターを一時停止 (Pause) すると、コンピュートノードへの課金は停止します。ただしストレージ (RMS) への課金は継続します。リーダーノードは無料です。

Reserved Instance を購入すると、オンデマンド比で割引が適用されます。1 年 All Upfront で約 34%、3 年 All Upfront で約 63% の削減になります (東京リージョン ra3.xlplus、2026-05-04 確認)。長期間の本番稼働では Reserved Instance の活用が実務上の標準です。

Provisioned の強み

Provisioned が強みを発揮するのは、クエリ実行量が多く、稼働時間が長い 場合です。具体的には次のような条件が当てはまります。

• 日中の業務時間帯に継続的な ETL クエリやレポーティングが稼働している
• 数十〜数百の同時接続が発生し、ワークロード管理 (WLM) で優先度制御が必要
• 過去からの蓄積データに対して複雑な結合・集計を繰り返し実行している
• データを Redshift のマネージドストレージに長期保存し、一貫した性能を求めている

Reserved Instance を適用した場合、長時間稼働のワークロードでは Serverless より総コストを低く抑えられます。

Serverless の仕組み ── RPU と自動スケーリング

RPU (Redshift Processing Unit) とは

Redshift Serverless は、クラスターを明示的に構成・管理せずに Redshift を利用できるオプションです。ユーザーが設定するのは RPU (Redshift Processing Unit) の最大値と基本キャパシティです。Redshift はクエリの負荷に応じて、この範囲内で自動的にスケールします。

RPU は vCPU・メモリ・ネットワーク帯域をまとめた単位で、1 RPU は約 16 GB のメモリに相当します。東京リージョンでは 4 RPU から 512 RPU の範囲で設定できます (2026 年 5 月時点。リージョンによっては最大 1024 RPU に対応)。最大 RPU の設定はコスト上限の役割を兼ねます。

公式の推奨はワークロード特性により異なりますが、中規模バッチ処理の出発点として 32 RPU 前後を設定し、スキャンデータ量や並列実行数が増えた段階で引き上げる流れが選択肢の 1 つになります。

RPU 課金の仕組み

Serverless の課金単位は RPU 秒 です。東京リージョン (ap-northeast-1) における単価は $0.494 / RPU 時間 です (最新の正確な値は 公式料金ページ で確認してください)。

クエリが実行されていない時間帯は、設定によりサービスを自動的にアイドル状態にでき、RPU 課金を停止できます。このアイドル移行の設定 (基本キャパシティ) は、コスト最適化の重要なパラメータです。

長期的な利用が見込める場合は、Serverless にも Reserved Serverless Capacity (RSC) という RPU 時間コミット型の割引契約があります。1 年契約で最大 24%、3 年契約で最大 45% の割引が適用されます。Provisioned の Reserved Instance がノード単位の契約であるのに対し、RSC は RPU 時間にコミットする点が異なります。

ストレージは Provisioned の RMS と同様に S3 ベースで、別途 GB 単位での課金が発生します。東京リージョンのストレージ単価は $0.0261 / GB-月 です (2026-05-04 確認、最新値は公式で要確認)。

Serverless の強み

Serverless が適しているのは、クエリ実行が不規則で、ピーク時と閑散期の差が大きい 場合です。

• 週次・月次のバッチ分析など、実行頻度が低い
• 開発・検証環境や PoC (概念実証) 段階で、稼働実績が読めない
• データエンジニア・アナリストがアドホックなクエリを散発的に実行する
• クラスターサイズの見積もりをせずに始めたい

ノードタイプの選定・ノード数の決定・WLM の設定といった運用設計が不要なため、初期の立ち上げコストが低い点も Serverless の特徴です。

使い分けの判断基準 ── 4 つの軸で比較する

Provisioned と Serverless の選択に影響する主要な軸を整理します。

実務上の選択フロー

次の順で確認すると選択が絞れます。

1. 月の総クエリ実行時間を見積もる: 常時 8 時間以上クエリが実行される見込みなら、Provisioned の Reserved Instance が総コスト面で有利になりやすい
2. 同時接続数のピークを確認する: Serverless の最大 2,000 接続は接続プーリング (複数クライアントのデータベース接続を束ねて再利用する仕組み) を使わない構成だと上限に到達することがあります。高同時接続の BI ツール (Tableau Server 等) を接続する場合は Provisioned + WLM の設計を検討します
3. Reserved Instance の購入可否を確認する: 1 年以上の継続利用が見込めるなら Provisioned + Reserved Instance の組み合わせが選択肢に入る
4. 開発・検証フェーズか本番フェーズかを確認する: 開発・検証フェーズでは Serverless のほうが立ち上げが早く、ノード選定の試行錯誤を省ける

設定の見落としで請求が伸びる 5 点 ── 基本キャパシティ・RPU 上限・Pause 中ストレージ

1. Serverless の「基本キャパシティ」設定を見落とす

Serverless のコスト最適化で最も重要なのが 基本キャパシティ (Base Capacity) の設定です。設定できる最小値は 4 RPU で、デフォルト値は 128 RPU です。

デフォルト値 (128 RPU) のまま放置すると、クエリ実行時の課金が大きくなります。使用頻度の低い環境ではこの値を小さく調整することで、アクティブ時のコストを抑えられます。PoC や開発環境であれば 4〜8 RPU から始める形が現実的です。

基本キャパシティを低く (4 RPU 程度) に設定した場合、クエリが実行されない時間帯にアイドル状態へ移行し、RPU 課金が停止します。

アイドル状態からの最初のクエリ実行には数秒〜十数秒の コールドスタート遅延 が発生します。インタラクティブなダッシュボードで遅延が問題になる場合は、基本キャパシティを 8 RPU 程度に設定してウォームスタートを維持することを検討します。

2. RPU 最大値が「実行上限」になることを見落とす

Serverless の最大 RPU 設定は、コスト上限と性能上限の両方 として機能します。最大 RPU が小さすぎると、大規模クエリ実行中にキャパシティが不足して実行時間が延びたり、タイムアウトが発生したりします。

RPU の適切な見積もりには、実際にクエリを実行して SVL_QUERY_REPORT や SYS_QUERY_HISTORY ビューで消費メモリと実行時間を計測することが基本です。

3. Provisioned のクラスター停止中でもストレージ課金は続く

コスト削減目的で Provisioned クラスターを Pause すると、コンピュートノードへの課金は止まりますが、マネージドストレージ (RMS) への課金は継続します。RMS の課金は $0.0261 / GB-月 (東京リージョン、2026-05-04 確認) で、大量データを保持したまま長期 Pause にしている場合はストレージ費用が積み上がります。

長期間使用しない場合はスナップショットを取得して削除するか、Serverless への移行を検討します。

4. Cross-AZ のネットワーク費用に注意する

Redshift (Provisioned / Serverless 両方) のノードは同一 AZ に配置されます。Redshift に接続するアプリケーションや ETL ツールが別 AZ に存在する場合、クロス AZ のデータ転送コストが発生します。

特に大量データを Glue / EMR から Redshift にロードする構成では、データソースと Redshift を同一 AZ に揃えることでネットワーク費用を抑えられます。

5. Provisioned と Serverless のデータ共有は明示的な設定が必要

同一 AWS アカウント内で Provisioned クラスターと Serverless ネームスペースの間でデータを参照したい場合、Redshift Data Sharing を明示的に設定する必要があります。Data Sharing は無料で利用できますが、生産者側と消費者側の双方で設定が必要で、設定漏れがあるとクロスアクセスが機能しません。

月いくらになるか ── 東京リージョンの 2 シナリオ試算

月間コストの概算例を示します。実際のスキャン量・データ量・稼働パターンによって大きく変わるため、参考値として使ってください。JPY 換算は 1 USD = 160 円 (2026-05-04 時点の実勢レート) で計算しています。

Provisioned (ra3.xlplus × 2 ノード、平日 8 時間稼働)

稼働時間: 22 日 × 8 時間 = 176 時間 / 月
コンピュート: $1.278 × 2 ノード × 176 時間 ≒ $450
ストレージ (500 GB): $0.0261 × 500 GB ≒ $13
月合計概算: 約 $463 (≒ 約 74,000 円 / 月、1 USD = 160 円換算)

Reserved Instance (1 年) を購入すると、上記コンピュート費用をさらに 34% 程度削減できます (3 年契約では 63% 程度)。

Serverless (最大 32 RPU、月 10 時間クエリ実行)

コンピュート: $0.494 × 32 RPU × 10 時間 ≒ $158
ストレージ (500 GB): $0.0261 × 500 GB ≒ $13
月合計概算: 約 $171 (≒ 約 27,400 円 / 月、1 USD = 160 円換算)

Serverless が経済的になるのは、総クエリ実行時間が短い場合 です。稼働時間の見積もりと最大 RPU の設定が、Serverless のコスト管理の核心です。

まとめ ── 2 つの選択軸

Provisioned と Serverless の選択は、突き詰めると 「キャパシティを固定して持つか、必要時にだけ動的に呼び出すか」という運用パターンと、Reserved Instance での割引購入を契約形態に組み込めるか の組み合わせで決まります。

「月の総クエリ実行時間」「同時接続数のピーク」「Reserved Instance 購入の可否」という 3 つの判断材料も、この 2 軸の派生として読めます。

Provisioned は常時・高頻度のクエリ実行環境向けで、Reserved Instance を組み合わせると長期間の総コストを抑えられます。Serverless はクラスター管理不要・実行分のみ課金のため、実行頻度が低い分析環境や開発フェーズに適しています。

両オプションは SQL 互換性が高く、Data Sharing を使えば同一アカウント内での並走も可能なため、用途ごとに使い分ける構成も選択肢として残ります。

参考文献

• Amazon Redshift の概要 — Amazon Redshift 公式ドキュメント
• Amazon Redshift Serverless の概要 — Amazon Redshift 公式ドキュメント
• Comparing Provisioned and Serverless — Amazon Redshift 公式ドキュメント
• Amazon Redshift ノードタイプ — Amazon Redshift 公式ドキュメント
• Redshift Serverless のキャパシティ管理 — Amazon Redshift 公式ドキュメント
• Amazon Redshift Pricing
• Amazon Redshift Data Sharing — Amazon Redshift 公式ドキュメント

Author

tgeas

大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。

profile