Amazon Redshift コスト最適化入門｜ノードタイプ選択・一時停止・Serverless移行でDWH料金を最大70%削減する実践ガイド

「Redshiftを本番導入したら、翌月の請求額が想定の3倍になっていた」——これ、クラウドDWHを使い始めたインフラエンジニアによく聞く話です。

オンプレのデータウェアハウスは一度サーバーを購入すれば固定費ですが、Amazon Redshiftは使い方を誤ると月額数十万円の費用が平気で出てきます。ただし逆に言えば、設定次第で同じワークロードを大幅に安く動かすことも可能です。

この記事では、Amazon Redshiftのコスト構造を正確に理解したうえで、即効性のある削減施策（夜間停止・Reserved Nodes・ノードタイプ変更）から、Redshift Serverlessへの移行判断まで、現場で使える情報を体系的に解説します。

なぜRedshiftのコストは高くなりがちなのか

オンプレのDWHアプライアンス（Teradata、Netezzaなど）に慣れた方がRedshiftに移行すると、コスト構造の違いに戸惑うことがあります。

オンプレでは「サーバーを買ったら使わなくてもコストは変わらない」のが普通でした。一方、Redshiftのプロビジョニングクラスターは起動している時間だけ課金されます。週末も夜間も、クエリを実行しなくても時間課金が走り続けます。

コストが膨らむ主な原因は次の3つです。

・クラスターが24時間365日起動している: 分析バッチが日中だけなのに夜間・休日もフル稼働させている
・オーバースペックなノードタイプ選択: とりあえず大きいノードを選んで後で調整しなかった
・スナップショット保管料金の見落とし: 自動スナップショットの保持期間が想定より長く設定されていた

Redshiftの料金体系を正確に把握する

1. プロビジョニングクラスターの料金構造

プロビジョニングクラスターは「ノード時間課金」が基本です。料金はノードタイプ × 台数 × 稼働時間で決まります（2026年6月時点、東京リージョン（ap-northeast-1）の料金）。

2ノード構成のra3.4xlargeを1か月（720時間）動かすと、$1.235 × 2 × 720 ＝ 約$1,779（約27万円）になります。夜間・休日を停止するだけでこの数字がどう変わるかは後述します。

2. Redshift Serverlessの料金構造

Redshift Serverlessは実行したクエリで消費したコンピュートユニット（RPU: Redshift Processing Unit）に対して課金されます。

・RPU課金: $0.375 / RPU時間（東京リージョン、2026年6月時点）
・課金単位: クエリが実行されている時間のみ（アイドル時は課金なし）
・ストレージ: 別途$0.024/GB・月（S3に格納）

断続的にしか使わないワークロードではServerlessが有利ですが、常時クエリが走るようなバッチ処理ではプロビジョニングクラスターのほうが安くなることもあります。この判断基準は後で詳しく解説します。

ノードタイプの選び方がコストを決める（RA3 vs DC2）

Redshiftには大きく分けて「RA3」と「DC2」の2系統があります。どちらを選ぶかでコスト構造が根本的に変わります。

データ量1 TB未満の検証用途ならdc2.large（2ノード構成で月額約$360）が最安です。本番の大規模DWHではRA3が王道選択になります。

よくあるミスは、PoCをdc2.8xlargeで始めてそのまま本番にしてしまうケースです。「とりあえず大きいもので試した」ノードタイプを見直すだけで月額費用が半分以下になることがあります。

即効性のあるコスト削減施策

1. クラスターの夜間・休日停止

Redshiftのプロビジョニングクラスターは「一時停止（pause）」と「再開（resume）」ができます。停止中はコンピュート課金が発生しません（ストレージ料金は継続します）。

分析用クラスターが平日9時～19時だけ使われる場合、停止・再開を自動化すると稼働時間を約70%削減できます。

AWS CLIでの一時停止・再開コマンドです。

# AWS CLI — クラスターの一時停止
aws redshift pause-cluster \
  --cluster-identifier my-analytics-cluster \
  --region ap-northeast-1

# AWS CLI — クラスターの再開
aws redshift resume-cluster \
  --cluster-identifier my-analytics-cluster \
  --region ap-northeast-1

EventBridgeスケジューラーと組み合わせると、「平日19:00に停止 → 翌朝8:45に再開」の自動化が可能です。2ノード・ra3.4xlargeの場合、この設定だけで月額料金を約$1,779 → 約$519（約70%削減）にできます。

注意点として、クラスターの停止・再開にはそれぞれ数分かかります。バッチ処理の開始時刻より15分ほど前に再開スケジュールを組むのが現場での経験則です。

2. Reserved Nodes（リザーブドノード）の購入

1年以上Redshiftを安定運用するなら、Reserved Nodesを検討する価値があります。オンデマンド料金と比較した割引率は次のとおりです（2026年6月時点、ra3.4xlargeの参考値）。

夜間停止と組み合わせる場合、Reserved Nodesは「稼働している時間」にしか適用されない点に注意してください。停止中はコンピュート課金がゼロなので、Reserved Nodesの恩恵も受けられません。つまり、夜間停止+Reserved Nodesを組み合わせるより、常時稼働のクラスターに対してReserved Nodesを購入するほうが費用対効果が明確です。

3. 自動スナップショットの保持期間を見直す

Redshiftの自動スナップショットはデフォルト1日保持ですが、設定変更を忘れていると知らないうちにS3ストレージ料金が積み上がります。

# AWS CLI — スナップショット保持期間を1日に変更
aws redshift modify-cluster \
  --cluster-identifier my-analytics-cluster \
  --automated-snapshot-retention-period 1 \
  --region ap-northeast-1

# 保持期間の確認
aws redshift describe-clusters \
  --cluster-identifier my-analytics-cluster \
  --query "Clusters[0].AutomatedSnapshotRetentionPeriod" \
  --region ap-northeast-1

ストレージ料金は$0.095/GB・月（東京リージョン、2026年6月時点）です。圧縮済みデータで1 TBのスナップショットを30日間保持していると、単純計算で月$95の追加コストになります。

Redshift Serverlessへの移行判断基準

「Serverlessにすればもっと安くなるのでは？」という質問をよく受けます。答えは「ワークロード次第」です。

Serverlessが有利なのは、クエリ実行が1日のうち数時間だけで残りの時間はアイドル状態のケースです。アイドル時間の課金がないため、断続的なワークロードでは劇的にコストが下がります。

一方、プロビジョニングクラスターのほうが有利なのは次のケースです。

・常時クエリが走るバッチ処理: アイドル時間がほぼない場合、RPU課金の積み上がりがReserved Nodesより高くなる
・コンカレンシーが高いワークロード: 多数のユーザーが同時にクエリを実行する環境ではプロビジョニングが安定している
・長期間の安定運用: Reserved Nodesとの組み合わせでServerlessより安くなるケースがある

移行判断のシンプルな目安として、1日のクエリ実行時間が8時間未満ならServerlessを試す価値があります。それ以上なら、現行のプロビジョニングクラスターとReserved Nodesの組み合わせを優先して検討してください。

クエリチューニングでコンピュートを節約する

クラスターのスペックを落とすだけでなく、クエリの効率を上げることもコスト削減につながります。非効率なクエリは余計なCPUを消費し、同じ時間に処理できるスループットを下げます。

現場でよく効果がある3つのチューニングポイントです。

・ソートキー（Sort Key）の設計: よく絞り込む日付列や区分コードをソートキーにするとゾーンマップが効き、スキャン量が激減する
・分散キー（Dist Key）の設計: JOINするカラムを分散キーに揃えるとノード間のデータ転送が減り、大幅な高速化につながる
・WLM（ワークロード管理）の設定: 重いバッチクエリと軽いBIクエリを別キューに振り分けることで、軽いクエリが巨大バッチに引っかかって待たされる問題を解消できる

Redshift Advisorはクラスター内のクエリパターンを自動分析し、ソートキー・分散キーの変更提案を出してくれます。コンソールの「Advisor」タブから確認できます。

よくあるコスト爆発と対処法

Redshift Spectrumは便利な機能ですが、スキャンされたデータ量課金（$5/TB、2026年6月時点）を意識せずに大量データをS3から直接クエリすると、気づかないうちに高額になります。S3のパーティション設定でスキャン量を絞ることが費用管理の鍵です。

本記事のまとめ

Amazon Redshiftのコスト最適化は、「夜間停止 → ノードタイプ見直し → Reserved Nodes検討 → Serverless移行判断」の順で施策の優先度を付けると効率よく進められます。

オンプレのDWHはハードウェアを買った後は固定費でした。Redshiftはその発想を切り替えて「使わない時間は止める」「適切なサイズを選ぶ」ことを前提に設計するのが、クラウドネイティブなコスト管理の第一歩です。

Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。