Amazon Redshift Serverless（アマゾン レッドシフト サーバーレス）は、クラスタを自分で立てて管理することなく、使った分だけの課金でデータウェアハウス（DWH）を動かせる提供形態です。従来のプロビジョニング型が「ノードを何台か常時起動しておく」構成だったのに対し、Serverless はクエリが走った時間だけコンピュートを起動し、待機中は課金を止めます。この記事で扱うのは、データ層と計算層を分ける namespace と workgroup の考え方、RPU 秒課金の仕組みと支出の上限を決める設定、AWS CLI と Terraform での構築コード、S3・データレイクとの連携、VPC 設計やパッチ適用で実際に詰まる箇所、そしてプロビジョニング型から移すべきかの判断です。数値と設定名はすべて AWS 公式ドキュメントで実測し、該当箇所から出典へ直接たどれるようにしました。Redshift そのものの定義やアーキテクチャは既存記事へ譲り、本記事は Serverless 固有の実装に絞ります。
まとめ：Redshift Serverlessはクラスタ管理を外した従量課金のDWH
先に要点を示します。Redshift Serverless は、ノード数やクラスタの起動停止を運用者が管理せずに済むDWHです。データの入れ物である namespace と、計算資源である workgroup を分けて持ち、クエリが来たときだけ workgroup が RPU（Redshift Processing Unit）を起動して処理します。課金は RPU 時間の秒単位で、待機中は発生しません。1 RPU あたり 16GB のメモリが割り当てられ、基準となる base capacity の既定値は 128 RPU、設定できる範囲は 4〜512 RPU が基準です（AWS公式ドキュメント「Compute capacity for Amazon Redshift Serverless」／2026年9月時点）。
費用の目安は、AWS の料金ページに「Redshift Serverless begins at $1.50 per hour」と記載があり、これは最小構成の 4 RPU を 1 時間動かした場合の額に相当します（Amazon Redshift pricing／2026年9月時点・リージョンにより異なる）。1 RPU 時あたりに直すと 0.375ドル前後という水準になります。
向くのは、負荷の山谷が大きい分析ワークロードや、開発・検証環境のように使う時間が限られる用途です。逆に、ほぼ一定の負荷が24時間走り続ける本番DWHでは、予約割引を効かせたプロビジョニング型のほうが安く収まる場面もあります。まずは Serverless で立ち上げ、稼働パターンが読めてから形態を見直す、という進め方が現実的でしょう。
作業の順番も先に示します。①namespace と workgroup を分けて構成を決める、②base capacity と max capacity を置いて費用の振れ幅を挟む、③使用制限で月次の上限を先に決める、④S3 のデータレイクを外部スキーマで繋ぐ、⑤SYS_SERVERLESS_USAGE で実消費を測って形態を見直す——この5手です。以降の章はこの順番に対応します。
namespaceとworkgroupの役割を分けてServerlessの構成を読む
Serverless の位置づけを理解するには、従来型との対比が近道になります。Redshift 全般の仕組みそのものは別記事に譲り、ここでは「運用者が何をしなくてよくなるか」と「代わりに何を決めるのか」に絞ります。
プロビジョニング型クラスタとServerlessの起動と容量の違い
プロビジョニング型では、ノードタイプと台数を選んでクラスタを起動し、その台数分を常時課金します。容量が足りなくなればノードを追加し、要らなくなれば縮小する、という容量計画が運用者の仕事でした。Serverless はこの計画作業を裏側へ隠します。運用者が指定するのは base capacity という基準値だけで、実際のスケールは負荷に応じて自動で上下します。使わない時間帯にクラスタを止め忘れて課金が続く、という事故も起きません。Redshift の基本アーキテクチャや料金全体像、Snowflake・BigQuery との比較を先に押さえたい場合は、Amazon Redshiftの特徴とアーキテクチャの解説を読むと、Serverless が省いた部分の輪郭がつかめます。そもそもDWHという製品分類が自社に要るのかから考えたいなら、データウェアハウス（DWH）の仕組みと製品比較が入口になります。
namespace（データ層）とworkgroup（コンピュート層）の分離
Serverless の設計で最初に押さえるべきは、リソースが2つの層に分かれている点です。namespace はデータ層で、データベース・スキーマ・テーブル・ユーザー・スナップショットといった「中身」を保持します。ここはコンピュートが動いていない間も残り続ける層です。一方の workgroup は計算層で、RPU の容量や VPC・サブネット・セキュリティグループといった「実行環境」を束ねます。クエリを受けて処理し、負荷に応じてスケールするのが workgroup 側です。1つの namespace に対して用途別に複数の workgroup を紐づけ、本番用と分析用でコンピュートを分離する、といった構成も組めます（AWS公式「Workgroups and namespaces」）。
既定のbase capacityは128 RPU・4 RPUで扱えるデータ量の上限
base capacity の既定値が 128 RPU である点は、初回作成時に見落としやすい設定です。公式ドキュメントでは、4 RPU の構成が Redshift マネージドストレージ 32TB まで、8〜24 RPU が 128TB までを想定した容量帯とされ、128TB を超えるデータ量なら 32 RPU 以上が求められます。4 RPU 構成にはメモリ 64GB・1テーブルあたり100列という目安も示されており、列数の多いテーブルを置くとクエリ実行中にメモリを使い切る挙動につながります。刻み幅も一定ではなく、4 から 8 までは 4 刻み、8 から 512 までは 8 刻み、512 から 1,024 までは 32 刻みです。1,024 RPU まで上げられるのはバージニア北部・オハイオ・オレゴン・アイルランド・フランクフルトの5リージョンで、それ以外は 512 RPU が上限になります（2026年9月時点）。
RPU秒課金の内訳を分解してRedshift Serverlessの料金を見積もる
Serverless のコストは、ほぼ RPU の消費量で決まります。仕組みを分解すると、どこを絞れば費用が下がるかが見えてきます。
RPUの単価とbase capacityの刻み幅を押さえて費用を読む
課金の単位は RPU 時間で、1 RPU は 16GB のメモリに相当します。料金ページの記載から逆算すると、us-east-1 では 1 RPU 時あたり 0.375ドル前後が目安となり、消費した分を秒単位で計上する方式です。設定値のうち base capacity は処理の基準容量で、負荷が跳ねたときの上限を抑えたい場合は max capacity を併せて設定し、想定を超えるスケールと課金を頭打ちにします。この2つは AWS CLI の create-workgroup でも --base-capacity と --max-capacity として指定でき、コンソールと同じ値をコードから固定できます。
| 項目 | 内容 |
|---|---|
| RPU単価の目安 | 約0.375ドル/RPU時（2026年9月時点） |
| base capacity既定値 | 128 RPU |
| base capacity範囲 | 4〜512 RPU（一部5地域は1,024） |
| 1 RPUのメモリ | 16GB |
| 課金単位 | RPU秒（待機中は非課金） |
| 最小課金 | 60秒ぶん |
| ストレージ | RMSとしてGB/月で別建て |
最小課金60秒・キャンセルしたクエリ・ストレージ課金の扱いを知る
秒課金には細かい規定があり、見積もりの前提として押さえておくと請求書を読み違えません。AWS公式「Billing for Amazon Redshift Serverless」によると、最小課金は 60 秒ぶんで、そこから先が秒単位の計上になります。クエリを途中でキャンセルしても、走っていた時間は課金対象です。開いたままのトランザクションを閉じ忘れると RPU を消費し続けるため、明示的な BEGIN には対になる COMMIT か ROLLBACK を必ず置きます。計上のタイミングにも癖があり、トランザクションが完了・ロールバック・停止したあとで初めて記録されるため、2日走る処理の RPU 消費は完了後にまとめて計上されます。
ストレージはコンピュートと切り離され、Redshift マネージドストレージ（RMS）として GB/月で課金されます。24時間未満で消える復旧ポイントには料金がかかりません。データレイクへのクエリ（Redshift Spectrum）については、Serverless の場合に別枠のスキャン課金が発生せず、ローカルのデータに対するクエリと同じくトランザクション時間で計上される点も、プロビジョニング型との差になります。
予約（Serverless Reservations）で最大45%の割引を得る
長期でほぼ一定量を使うなら、予約による割引が効きます。料金ページには Serverless Reservations について「reducing compute costs by up to 45%」と記され、AWS の支払いアカウント階層で管理し、複数アカウント間で共有できる形と説明されています。オンデマンドと予約は併用できるため、定常分だけを予約で押さえ、突発的な山はオンデマンドで吸収する組み方が現実的です。旧来の「1年で最大24%」といった数値は改定されている可能性があるため、見積もり時は必ず料金ページの現行値を当たってください。
AWS CLIとTerraformでnamespaceとworkgroupを作る
立ち上げ自体は難しくありません。コンソールなら数分で動き始め、再現性が要る本番ではコードに寄せます。
コンソールでnamespaceとworkgroupを作る初回の流れ
初回起動では、AWS マネジメントコンソールの Redshift Serverless から「作業を開始」に進み、namespace 名と管理者ユーザー、base capacity、配置する VPC とサブネットを指定します。この操作で namespace と workgroup が対で作られ、接続用のエンドポイントが払い出される流れです。あとはクエリエディタや BI ツールから接続し、テーブルを作ってデータを入れれば分析を始められます。既存の S3 にあるデータをそのまま読みたい場合は、COPY でロードするほか、外部テーブル経由で直接参照する選択肢もあります。
AWS CLIでnamespaceとworkgroupを作成するコマンド
手作業の再現に困ったら、まず CLI で同じ構成を組み直せるようにしておくと検証が速くなります。AWS CLI リファレンスの create-workgroupに沿った最小構成が次のコマンドです。管理者パスワードは直接書かず、Secrets Manager に管理させる --manage-admin-password を付けています。
# 1) データ層（namespace）を作る
aws redshift-serverless create-namespace \
--namespace-name analytics-ns \
--db-name analytics \
--admin-username admin \
--manage-admin-password
# 2) 計算層（workgroup）を base 8 RPU・max 64 RPU で作る
aws redshift-serverless create-workgroup \
--workgroup-name analytics-wg \
--namespace-name analytics-ns \
--base-capacity 8 \
--max-capacity 64 \
--subnet-ids subnet-aaaaaaaa subnet-bbbbbbbb subnet-cccccccc \
--security-group-ids sg-0123456789abcdef0 \
--no-publicly-accessible
# 3) 払い出されたエンドポイントを確認する
aws redshift-serverless get-workgroup \
--workgroup-name analytics-wg \
--query "workgroup.endpoint.address"Terraformでnamespaceとworkgroupを定義してIaC管理する
本番や複数環境では、コンソール手作業ではなくコードで定義を固定します。Terraform では aws_redshiftserverless_namespace と aws_redshiftserverless_workgroup の2リソースが対応し、base capacity・サブネット・セキュリティグループ・管理者認証情報を宣言する形になります。namespace と workgroup を別リソースとして書けるため、データ層は据え置いたままコンピュートの容量だけを変更する差分適用がしやすい構造です。Terraform Registry の aws_redshiftserverless_workgroupには price_performance_target ブロックも定義されており、level に 1（LOW_COST）・25（ECONOMICAL）・50（BALANCED）・75（RESOURCEFUL）・100（HIGH_PERFORMANCE）のいずれかを与えます。コンソールのスライダーを数値でコード化できるのは、レビューと再現の面で効きます。
resource "aws_redshiftserverless_namespace" "analytics" {
namespace_name = "analytics-ns"
db_name = "analytics"
admin_username = "admin"
manage_admin_password = true
log_exports = ["connectionlog", "useractivitylog"]
}
resource "aws_redshiftserverless_workgroup" "analytics" {
namespace_name = aws_redshiftserverless_namespace.analytics.namespace_name
workgroup_name = "analytics-wg"
base_capacity = 8
max_capacity = 64
subnet_ids = var.subnet_ids
security_group_ids = var.security_group_ids
publicly_accessible = false
price_performance_target {
enabled = true
level = 25
}
}IaC でインフラを宣言的に管理する考え方そのものや、サーバーレス構成をどこまでコード化するかの線引きは、サーバーレスアーキテクチャの構成パターンとAWS実装の解説で扱っています。Redshift Serverless 単体ではなく、周辺の Lambda や Step Functions まで含めた構成を考えるときの土台になります。
使用制限と価格性能ターゲットでRedshiftの支出上限を決める
従量課金は放置すると想定外の請求につながります。歯止めになるのが usage limits（使用制限）と価格性能ターゲットの2つです。
usage limitで日次・週次・月次のRPU時間に上限を置く
AWS公式「Setting usage limits, including setting RPU limits」によると、workgroup の Limits タブから RPU 時間の上限を日次・週次・月次のいずれかの周期で設定できます。上限に達したときの動作は3種類で、システムビュー SYS_QUERY_HISTORY に記録するだけの log、Amazon SNS で通知する alert、そしてクエリ処理そのものを止める deactivate です。前の2つは情報提供にとどまり、実際に課金を止めるのは3つ目だけという違いを押さえておきます。上限は1つの workgroup に対して複数（最大4件）まで置ける仕様です。CLI で作る場合は次のようになります。
aws redshift-serverless create-usage-limit \
--resource-arn arn:aws:redshift-serverless:ap-northeast-1:123456789012:workgroup/analytics-wg \
--usage-type serverless-compute \
--amount 200 \
--period monthly \
--breach-action deactivate--amount は時間ベースの場合に1時間あたりに消費する RPU で表す数値、--period の既定は monthly、--breach-action の既定は log です（AWS CLI リファレンスの create-usage-limit）。まずは log か alert で実消費の輪郭をつかみ、上振れの傾向が見えてから deactivate へ切り替える段取りが安全です。
価格性能ターゲットをコスト寄りに振って自動スケールの効きを抑える
もう1つの調整軸が価格性能ターゲットです。公式ドキュメントには、この設定が新規 workgroup すべてで既定有効・初期値 Balanced と明記されています。スライダーは「Optimizes for cost」「Balanced」「Optimizes for performance」の3点に加え、その間の2段を選べる構成で、コスト寄りに振ると追加課金の生じない範囲でのスケールアップを優先し、必要なら実行時間が伸びる代わりにスケールダウンを試みます。設定は workgroup ごとに独立しているため、本番用の workgroup は Balanced、社内アドホック分析用は コスト寄り、といった振り分けが可能です。base capacity をいくつにすべきか判断が付かない段階では、この自動調整に任せつつ max capacity で天井を固定する組み合わせが現実的な落としどころになります。
Redshift SpectrumでS3のデータレイクを直接クエリする
Serverless は単体で完結させるより、周辺のストレージや基盤と組み合わせて使うのが実務の姿です。
CREATE EXTERNAL SCHEMAでS3のファイルを直接参照する
大量の生データを Redshift の中に取り込みきる必要はありません。Redshift Spectrum を使えば、S3 上のファイルを外部テーブルとして定義し、ロードせずに直接クエリできます。入口になるのが AWS公式「CREATE EXTERNAL SCHEMA」で、AWS Glue データカタログを参照する形なら次のように書きます。
CREATE EXTERNAL SCHEMA spectrum_logs
FROM DATA CATALOG
DATABASE 'logs_db'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftSpectrumRole'
CREATE EXTERNAL DATABASE IF NOT EXISTS;
SELECT event_date, COUNT(*) AS cnt
FROM spectrum_logs.access_log
WHERE event_date >= '2026-09-01'
GROUP BY 1
ORDER BY 1;カタログ側の整備には AWS Glueの機能とWorkflowsの仕組みの解説が対応し、クローラでスキーマを起こしてから外部スキーマを張る流れになります。S3 のファイルへ直接 SQL を投げるだけなら、Redshift を挟まず Amazon Athenaの使い方・料金とRedshiftとの違いの解説で扱っている選択肢のほうが軽く済む場面もあります。
頻繁に集計する整形済みデータとS3へ残す履歴データの置き分け
頻繁に集計する整形済みデータは namespace 内に置き、履歴やログのような大容量データは S3 のデータレイクへ残す置き分けが、ストレージ費用を抑える定石です。データレイクとDWH・レイクハウスの役割の違いはデータレイクの実装視点の解説で整理しており、どのデータをどちらへ置くかの判断材料になります。両者を1つの層に統合する構えを検討しているならデータレイクハウスのアーキテクチャの解説が、ロード元・退避先となる S3 側のストレージクラスや料金はAmazon S3の仕組みと料金の解説が参考になるはずです。分析対象がトランザクション処理寄りなのか集計寄りなのかで置き場所が変わるため、OLTPとOLAP・DWHの違いとAWSのDB選定の比較で先に線を引いておくと迷いが減ります。
データ分析基盤の中でRedshift Serverlessが担う層
Serverless はそれ単体が目的ではなく、収集・蓄積・変換・可視化という分析基盤の「クエリ・集計エンジン」を担う部品です。ETL で整えたデータを受け、BI ツールへ結果を返す層に位置づけると、全体像の中での役割がはっきりします。収集からダッシュボードまでの5層アーキテクチャの中でDWHがどこに入るかは、データ分析基盤の構築とアーキテクチャの解説で俯瞰できる構成です。出口側のBIを同じくサーバーレスで揃えるならAmazon QuickSightの機能・SPICE・料金の解説が、AWS ではなく Google Cloud 側で同種の構成を組む場合はBigQueryの仕組み・料金とできないことの解説が比較対象になります。基盤全体を設計してから Serverless を組み込むと、後からの手戻りを減らせます。
VPC・IPアドレス・自動パッチ適用で実装時に詰まる箇所を潰す
ここからは、料金表や機能一覧には出てこない実装時の制約です。AWS公式「Considerations when using Amazon Redshift Serverless」に列挙された条件のうち、構築が止まりやすい3点を取り上げます。
サブネットは2つ以上・EVR利用時は3つ以上のAZにまたがる構成
workgroup を作るときのサブネット指定には本数の下限があります。Enhanced VPC Routing（EVR）を使わない構成では、2つ以上のサブネットが2つのアベイラビリティゾーンにまたがっている必要があり、EVR を有効にする構成では3つ以上のサブネットが3つ以上のゾーンにまたがることが求められます。既存 VPC のサブネットが1ゾーンに寄っていると、この時点で作成が通りません。加えて、指定したサブネットが Redshift Serverless のサポート対象ゾーン ID に載っているかも確認が要ります。VPC コンソールのサブネット一覧でゾーン ID の対応を先に見ておくと、作成時のエラーで手戻りせずに済みます。
各サブネットに空きIPアドレスを3つ以上確保しておく必要がある
見落としが多いのが空き IP アドレスの条件です。EVR なしの場合、base capacity が 4 RPU でも 1,024 RPU でも一律で、各サブネットに3つ以上の空き IP が要ります。RPU を更新する操作のときにも同じ本数が必要で、余裕を持たせずに切ったサブネットは容量変更で詰まる原因です。EVR ありの場合は容量に応じて必要数が増え、4 RPU と 8 RPU で9アドレス（最小 CIDR は /27）、16 RPU と 32 RPU で13アドレス、64 RPU で21アドレスといった具合に段階的に上がります。既存の共有 VPC に相乗りする案件では、この本数が確保できるかを設計の初期に確かめておくと安全です。
自動パッチ適用は14日以内・アイドルが無いと短時間の停止が起きる
Serverless には従来のメンテナンスウィンドウがなく、新しい更新はリリースから14日以内にアイドル時間を見計らって適用されます。更新処理そのものは通常15分ほどで終わりますが、14日のあいだに15分のアイドルが一度も発生しない場合、エンドポイントが短時間使えなくなる可能性があると明記されています。24時間走り続けるバッチを積んでいると、この条件に引っかかる構成です。アプリケーション側で接続の再試行を実装し、深夜帯などに意図的な無負荷時間を確保しておくのが実務上の備えです。バージョンの追従度合いは workgroup のトラック設定（current または trailing）で選べるため、検証環境を current、本番を trailing に置いて先行検知する運用も組めます。
スナップショット復元でプロビジョニング型のクラスタから移行する
すでにプロビジョニング型で運用している場合、Serverless へ移すかは費用と負荷パターンで決めます。移行そのものは作り直しではなく、スナップショットの復元で済みます。
スナップショットを取ってServerlessのnamespaceへ復元する
AWS公式「Migrating a provisioned cluster to Amazon Redshift Serverless」の手順は明快です。既存クラスタでスナップショットを作成し、Redshift コンソールのスナップショット一覧から「Restore snapshot」→「Restore to serverless namespace」を選び、復元先の namespace を指定します。この操作は復元先のデータベースをすべて置き換えるため、既存データが入った namespace を指定しない配慮が必要です。まずは検証用の namespace へ復元して既存クエリの実行時間と RPU 消費を実測し、本番切り替えの判断材料にすると安全に進められます。異種DB間の移行や継続的なレプリケーションが要る案件では、AWS Database Migration Service（DMS）の使い分けと料金の解説で扱う経路のほうが合う場合もあります。
インターリーブソートキーは復元時に複合キーへ自動で変換される点
移行時に静かに変わる仕様が1つあります。プロビジョニング型のスナップショットを Serverless の namespace へ復元すると、インターリーブソートキーは複合ソートキーへ自動的に変換されます。インターリーブ前提でクエリ性能を設計していたテーブルは、移行後に実行計画が変わる可能性があるということです。移行前に該当テーブルを洗い出し、検証用 namespace で実行時間を突き合わせておくと、本番切り替え後の性能劣化を先に見つけられます。あわせて、移行前のクラスタが必要とする処理量に対して、選ぶ RPU 量が見合っているかも公式の注記どおり確かめておきます。
接続先エンドポイントとポート番号5439をアプリ側で切り替える
アプリケーション側の変更は接続先の差し替えが中心です。Serverless のエンドポイントは workgroup 名・アカウント番号・リージョンを組み合わせたホスト名で払い出され、ポート番号を省略すると 5439 が既定になります。別のポートを使いたい場合は 5431〜5455 または 8191〜8215 の範囲から選び、AWS CLI か API で変更する形です。ドライバは Redshift JDBC ドライバのバージョン2系が推奨で、パスワード認証のほか、GetCredentials を用いた IAM 認証も選べます。IAM 認証では既定でログイン時にデータベースユーザーが自動作成され、IAM のタグや IdP のグループに応じてロールが割り当てられる挙動になります。
SYS_SERVERLESS_USAGEで消費RPUを実測して費用を監視する
Serverless は「気づいたら請求が伸びていた」を起こしやすい形態です。請求書を待たずに手元で測る経路を用意しておきます。
charged_secondsを合計して実際の課金RPU秒を確かめる
費用の実測に使うのがシステムビュー SYS_SERVERLESS_USAGE です。AWS公式のリファレンスによると、1分粒度でコンピュート消費とマネージドストレージ使用量を記録し、費用計算に使うべき列は charged_seconds だと明示されています。この列はトランザクション終了後に計算されるため、実行中は 0 のまま推移する点も併記されています。compute_seconds はアカウントに割り当てられた base RPU 容量を反映した値で、請求と一致するとは限りません。日次の課金 RPU 時間と概算額は次のクエリで出せます。
SELECT
DATE_TRUNC('day', start_time) AS usage_day,
SUM(charged_seconds) / 3600.0 AS charged_rpu_hours,
ROUND(SUM(charged_seconds) / 3600.0 * 0.375, 2) AS est_usd
FROM sys_serverless_usage
WHERE start_time >= DATEADD(day, -7, GETDATE())
GROUP BY 1
ORDER BY 1;保持期間は7日・CloudWatchとCURで長期の推移を見る
このビューが保持するのは直近7日ぶんで、参照できるのはスーパーユーザーだけです。週次より長い推移を追うなら、結果を別テーブルへ日次で退避するか、CloudWatch のメトリクスと Cost and Usage Report 側で押さえます。スナップショットのストレージ使用量については ServerlessUniqueSnapshotStorage というメトリクスが CloudWatch へ送られるため、コンピュートとストレージを分けて監視できる仕組みです。無料トライアル（初回利用者向けに300ドル・90日間の期限つきクレジット）を使っている期間は、請求コンソール側に明細が出ずクレジット残高とこのビューでしか消費を追えないため、検証段階こそ手元のクエリで測る価値があります。ストリーミング取り込みまで含めた基盤で消費を追うなら、Amazon Kinesisの仕組みと料金の解説と併せて全体の費用配分を見ると全体像がつかめます。
Redshift Serverlessを採用すべき条件と見送るべき場面
ここは言い切ります。Serverless はすべてのDWH用途で正解になるわけではありません。向く条件と、あえて選ばない場面を分けて示します。
Serverlessの採用が向く条件｜負荷の山谷が大きい分析用途
効果が出るのは、負荷に波がある使い方です。日中だけ分析が集中する、月末にバッチが跳ねる、開発環境で数時間だけ使う、といったパターンでは、待機中に課金されない特性がそのまま費用の削減につながります。容量計画やクラスタの起動停止管理から手を離したいチーム、DWH専任の運用担当を置けない体制でも、base capacity と使用制限を決めるだけで動かせる手軽さも利点です。この線引きや、分析基盤の設計から実装までを外部に相談したい場合は、データ分析基盤構築・MLOps構築支援で受託の相談を受け付けています。
Serverlessを見送るべき場面｜一定負荷が常時走る本番DWH
逆に見送ったほうがよい場面もあります。ほぼ一定量のクエリが24時間走り続ける本番DWHでは、常時稼働を前提にプロビジョニング型で予約割引を効かせたほうが、総額で安くなるケースが少なくありません。RPU が高止まりする重いワークロードを長時間動かすなら、Serverless の秒課金がかえって割高になり得ます。前章で触れた自動パッチ適用の条件も、無停止を求める用途では引っかかります。まずは Serverless で稼働パターンを実測し、消費が読めて安定したら予約付きプロビジョニング型へ移す、という二段構えが費用の面で堅実です。
よくある質問
Redshift Serverless の課金や移行など、導入前に迷いやすい点をまとめます。
Redshift Serverlessは使わない時間も課金されますか？
クエリが走らない待機時間は RPU 課金が発生しません。課金対象はクエリ処理に RPU を消費した時間で、最小60秒ぶんを起点に秒単位で計上されます。キャンセルしたクエリも走った時間ぶんは課金対象です。namespace に保存したデータのストレージ料金は、コンピュートの稼働とは別に GB/月で発生します。
base capacityはいくつに設定すればよいですか？
既定値は 128 RPU で、小規模な検証なら最小の 4 RPU まで下げられます。ただし 4 RPU 構成はマネージドストレージ 32TB・1テーブル100列が目安の上限で、これを超えるなら 8 RPU 以上へ上げます。判断が付かない段階では価格性能ターゲットの自動調整に任せ、max capacity で天井を固定するのが無難です。
プロビジョニング型からデータを移せますか？
移せます。既存クラスタのスナップショットを取得し、Serverless の namespace へ復元すればテーブルとデータを引き継げます。復元は対象 namespace のデータベースを置き換える操作なので、まず検証用 namespace へ復元して実行時間と RPU 消費を確かめてから、本番のエンドポイントを切り替えてください。インターリーブソートキーが複合ソートキーへ変換される点も事前に確認しておきます。
redshiftのプロビジョニング型とServerlessはどちらが安いですか？
負荷に波があるなら Serverless、ほぼ一定量が常時流れるなら予約付きプロビジョニング型が費用面で有利になります。判断材料は SYS_SERVERLESS_USAGE の charged_seconds で、日次の課金 RPU 時間を数週間ぶん並べれば稼働パターンが見えるはずです。まず Serverless で消費量を実測し、安定して読める段階になってから形態を見直す進め方をおすすめします。
コストが想定より膨らむのを防ぐ方法はありますか？
usage limits で RPU 時間の上限を日次・週次・月次から選んで設定し、超過時の動作を log・alert・deactivate から選びます。実際に課金を止めるのは deactivate だけなので、通知だけでは歯止めになりません。加えて価格性能ターゲットをコスト寄りに振り、max capacity で天井を決めておくと上振れを抑えられます。
関連記事
- Amazon Redshiftとは｜特徴・料金・アーキテクチャ：Serverless の土台となる Redshift 全般の仕組みと他DWHとの比較を押さえられます。
- BigQueryとは｜サーバーレスDWHの料金と採用判断：同じサーバーレスDWHをGoogle Cloud側で比較検討するときの対になります。
- Amazon Athenaとは｜料金とRedshiftとの違い：S3へ直接SQLを投げる軽い選択肢との使い分けを整理できます。
- データレイクとは｜DWH・レイクハウスとの違い：Spectrum で併用する S3 データレイクの位置づけを実装視点で理解できます。
- Amazon S3とは｜仕組み・料金・採用判断：Serverless のデータロード元・退避先となる S3 の費用と特性を解説しています。
- データ分析基盤の構築とは｜5層アーキテクチャ：Serverless を組み込む分析基盤全体の設計像をつかめます。
