【Redshiftの役割（コスト最適化）】
目次
🔍 1. 結論
💎 一言でいうと Amazon Redshift（データウェアハウス）のコスト最適化は、「RA3ノードによるコンピュートとストレージの課金分離」 と、使わない時間帯の 「クラスターの一時停止 (Pause and Resume)」 に集約されます。
- 過去のデータが溜まるだけで計算能力（CPU）は不要な場合、RA3ノードを使えば無駄なサーバー増設を避けられる。
- 夜間や土日に分析を行わないなら、クラスターを一時停止してコンピュート課金を止める。
📈 2. SAAで出やすいポイント
- RA3 ノード (コンピュートとストレージの分離): 従来のRedshift（DS/DCノード）は、ストレージ（容量）がいっぱいになると、計算能力（CPU）が足りていても「新しいノードを追加購入」しなければならず、コストが高止まりしていました。RA3ノード は、使用頻度の低いデータを自動的に裏側の Redshift マネージドストレージ (実体はS3) に追い出すため、ストレージ容量のためだけに高額なノードを追加する必要がなくなり、コストが劇的に下がります。
- Pause and Resume (一時停止と再開): 開発環境や、平日の日中しかBIツールを使わない場合、スケジュール設定でRedshiftクラスターを「一時停止」できます。停止中は高額なコンピュート（CPU）の課金がストップし、ストレージ料金のみの請求となるため、大幅なコスト削減が可能です。
- Redshift Spectrum を使ったオフロード: 全てのデータをRedshiftのディスクに持つのではなく、過去数年分の「滅多に見ない古いデータ」は Amazon S3 (Glacier等) に逃がし、必要な時だけ Redshift Spectrum でS3に直接クエリを投げる（サーバーレス課金）構成にすると、DWH全体のコストが下がります。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑うアプローチ |
|---|---|
| 📈 「データ量は増えるが、クエリの処理能力(CPU)は増やさなくてよい」 | Redshift RA3 ノードに変更する |
| 🌙 「夜間や週末は誰も分析ダッシュボードを使用しない」 | Redshift クラスターの 一時停止 (Pause) をスケジュールする |
| 🗄️ 「古い履歴データをS3に置いてコストを下げ、Redshiftから検索したい」 | Redshift Spectrum |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「Redshiftのインスタンスを都度『終了 (Terminate)』してコストを抑える」 → Terminateするとクラスターごと消滅してしまい、再度構築してデータをロードするのに莫大な時間がかかります。「一時停止 (Pause)」が正解です。 – 同時実行スケーリングの使いすぎ: ユーザー増による渋滞解消（同時実行スケーリング）は1日1時間までは無料ですが、それ以上は分単位で課金されるため、「常にON」にしておくと想定外のコストになる点に注意が必要です。
💡 5. 覚え方
🧠 暗記ショートカット – RA3ノード = 「トランクルーム付きのマンション」。 – 荷物（データ）が増えたからといって、無駄に広い高級マンション（ノード追加）に引っ越す必要はない。溢れた荷物は安いトランクルーム（裏側のS3）に自動で預けてコストを抑える。
📚 6. 関連サービス
| アイコン | サービス名 | コスト最適化における連携 |
|---|---|---|
| 🪣 | Amazon S3 | RA3ノードの裏側のストレージ、およびRedshift Spectrumの保存先（圧倒的に安い） |
| 📊 | Amazon Athena | そもそも「たまにしか分析しない」なら、Redshiftを立てずにAthena(サーバーレス)を使った方が安い |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: DWHアーキテクチャのサイジング、Athenaとの使い分け学習時
- 関連ノート候補:
AWS_SAA_Redshift_RA3,AWS_SAA_Redshift_vs_Athena
8. HTMLファイル名:
AWS_コスト最適化設計_Redshift.html
