Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。
# Amazon Redshift Serverless での請求
## コンピューティング性能に対する請求
Amazon Redshift Serverless の容量は、次の 2 つの方法で購入できます。
+ **オンデマンド容量を購入できます** – オンデマンドコンピューティング容量を選択した場合、リソースは従量制料金となります。これは、Amazon Redshift Serverless を使い始めたばかりの場合や、安定した使用パターンがまだ明確でない場合に最適です。オンデマンドは、最も高い柔軟性を提供します。詳細については、「[オンデマンドのコンピューティング容量に対する請求](serverless-billing-on-demand.md)」を参照してください。
+ **予約を購入できます** – 特定の期間 (1 年間など)、事前設定された量のコンピューティングリソースを購入する場合、予約には割引があります。これは、一定量の容量を着実に使用することがわかっている場合に最適です。容量のニーズをある程度予測できる場合、コスト削減に役立ちます。詳細については、「[サーバーレス予約に対する請求](serverless-billing-reserved.md)」を参照してください。
予約とオンデマンドリソースを一緒に使用できます。どちらか一方だけを使用する必要はありません。
料金の詳細については、「[Amazon Redshift の料金](https://aws.amazon.com/redshift/pricing/)」を参照してください。
# オンデマンドのコンピューティング容量に対する請求
**基本容量と課金への影響**
クエリを実行すると、所定の期間に使用された容量に基づいて、秒単位の RPU 時間で請求されます。クエリが実行されていない場合、コンピューティング容量に対して請求されません。Redshift Managed Storage (RMS) についても、保存されているデータ量に基づいて課金されます。
ワークグループを作成するときに、コンピューティングの**基本容量**を設定するオプションを使用できます。ワークグループレベルでワークロードの料金/パフォーマンス要件を満たすには、既存のワークグループの基本容量を増減して調整します。コンソールを使用して基本容量を変更するには、**[ワークグループの設定]** からワークグループを選択し、**[制限]** タブを選択します。
クエリ数が増えると、Amazon Redshift Serverless は自動的にスケールして一貫したパフォーマンスを保持します。
**最大 RPU 時間の使用制限**
Amazon Redshift Serverless のコストを予測できるようにしておくには、1 日、週、または月ごとに使用される **[Maximum RPU hours]** (RPU の最大時間) を設定します。これは、コンソールまたは API を使用して設定できます。制限に達した場合、ログエントリをシステムテーブルに書き込むか、アラートを受信するか、またはユーザークエリを無効にすることを指定できます。RPU の最大時間を設定すると、コストを管理することができます。RPU の最大時間の設定は、データウェアハウス内のデータにアクセスするクエリと、Amazon S3 内の外部テーブルなどの外部データにアクセスするクエリの両方について、ワークグループに適用されます。
以下に例を示します。
1 週間につき 100 時間の制限を設定すると仮定します。コンソールでこれを行うには、次の手順を実行します。
1. ワークグループを選択して、**[制限]** タブの **[使用制限を管理]** をクリックします。
1. 使用制限を追加して、**[毎週]** の頻度、**[100]** 時間の期間、アクションは **[ユーザークエリを無効にする]**] と選択します。
この例では、1 週間で 100 RPU 時間の制限に達すると、クエリは無効になります。
ワークグループに対して最大 RPU 時間を設定しても、ワークグループのパフォーマンスやコンピューティングリソースは制限されません。この設定は、クエリ処理への影響なしにいつでも調整できます。最大 RPU 時間を設定する目的は、コストとパフォーマンスの要件を満たすことです。サーバーレス料金の詳細については、[Amazon Redshift の料金](https://aws.amazon.com/redshift/pricing/)を参照してください。
Amazon Redshift Serverless のコストを予測可能な状態に維持するもう 1 つの方法には、AWS [コスト異常検出](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)を使用して、予期しない請求の発生可能性を低減し、コスト管理を向上することがあります。
**注記**
[Amazon Redshift 料金計算ツール](https://calculator.aws/#/addService/Redshift)は料金の見積もりに役立ちます。必要なコンピューティングリソースを入力すると、コストのプレビューが表示されます。
## コンピューティングリソースのコスト管理のための最大容量の設定
最大容量設定は、Amazon Redshift Serverless がスケールアップできる RPU の上限として機能します。これにより、コンピュートリソースのコスト制御につながります。ベース容量で利用可能なコンピューティングリソースの最小量を設定するのと同様に、最大容量で RPU 使用量の上限を設定します。これは、計画に沿った支出につながります。最大容量は各ワークグループ個別に適用され、コンピューティングの使用状況は常に制限されます。
### 最大容量と RPU 時間の使用制限との違い
最大 RPU 時間制限と最大容量を設定する目的は、ともにコスト管理にあります。ただし、実現方法は異なります。違いは次の点で説明されるとおりです。
+ **最大容量 – 最大容量の設定は、Amazon Redshift Serverless がスケーリングに使用する RPU の最大数を指定します。コンピューティングのオートスケーリングが必要な場合、最大容量の値を高く指定すると、クエリのスループットが向上します。最大容量の上限に達すると、ワークグループはそれ以上のリソースのスケールアップを行いません。
+ *最大 RPU 時間使用制限* – 最大容量とは異なり、この設定ではキャパシティの上限は設定されません。ただし、コスト抑制につながるその他のアクションが実行されます。ログへのエントリの追加、ユーザーへの通知、クエリの実行の停止などを選択できます。
最大容量のみを使用することも、最大 RPU 時間使用制限を超過した場合のアクションでこれを補完することもできます。
### 最大容量のユースケース
ワークグループごとに最大容量の設定が異なる場合があります。これにより、予算要件の強制に役立ちます。この仕組みを説明するために、次を想定します。
+ ベース容量が 256 RPU に設定されたワークグループがあります。毎月のほとんどの期間、ワークロードは 256 RPU をわずかに超える安定した状態にあります。
+ 最大容量は 512 RPU に設定されています。
アドホックな統計レポートを生成するために、3 日間にわたり、予想外に使用率が高くなったと仮定します。この場合、512 RPU を超えるコンピューティングコストを回避するために最大容量を設定しています。これにより、確実にコンピューティング容量がこの上限を超えないようにすることができます。
### 最大容量の使用に関する注意事項
最大容量を適切に設定するうえで、次の注意事項が役立ちます。
+ Amazon Redshift Serverless ワークグループごとに異なる最大容量を設定できます。
+ リソース使用率が非常に高い期間があり、最大容量が低い RPU レベルで設定されている場合、ワークロードの処理に遅延が発生し、最適なユーザーエクスペリエンスが得られない可能性があります。
+ 最大容量を設定しても、RPU の使用率が高い場合のクエリの実行が妨げられることはありません。最大容量を設定しても、クエリの実行を停止する可能性がある使用制限のようには機能しません。最大容量を設定すると、該当のワークグループが使用できるコンピュートリソースのみが制限されます。一定期間に使用された容量は、Amazon Redshift Serverless ダッシュボードで確認できます。概要データの確認の詳細については、「[ダッシュボードを使用して Amazon Redshift Serverless 概要データをチェックする](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-dashboard.html)」を参照してください。
+ 最大容量の設定の上限は 5632 RPU です。
### 最大容量の設定方法
最大容量は、コンソールで設定できます。既存のワークグループについては、**[ワークグループの設定]** で設定を変更できます。CLI を使用して、次のサンプルのようなコマンドを使用して設定することもできます。
```
aws redshift-serverless update-workgroup --workgroup-name myworkgroup --max-capacity 512
```
これにより、指定した名前のワークグループの最大容量設定を指定できます。設定を完了したら、コンソールで値を調べて検証できます。値は、CLI を使用して `get-workgroup` コマンドを実行しても確認できます。
最大容量設定を次のとおり `-1` に指定すると、無効にできます。
```
aws redshift-serverless update-workgroup --workgroup-name myworkgroup --max-capacity -1
```
## Amazon Redshift Serverless の使用状況とコストのモニタリング
Amazon Redshift Serverless の使用量と請求額を見積もるには、複数の方法があります。システムビューは、クエリのための設定を特にしなくても、クエリデータや使用状況のデータなどのシステムメタデータがタイムリーに表示できます。CloudWatch は、Amazon Redshift Serverless の使用状況のモニタリングにも活用でき、インサイトを提供し、アクションを設定するための追加機能も搭載されています。
### システムビューのクエリによる使用状況の可視化
SYS\$1SERVERLESS\$1USAGE システムテーブルをクエリして使用状況を追跡し、クエリの料金を取得します。
```
select trunc(start_time) "Day",
(sum(charged_seconds)/3600::double
precision) * as cost_incurred
from sys_serverless_usage
group by 1
order by 1
```
このクエリでは、Amazon Redshift Serverless で発生する 1 日あたりのコストを使用状況に基づいて提供します。
#### 使用量とコストを決定するための使用に関する注意事項
+ 実行するワークロードに対して秒単位の RPU 時間 (60 秒の最低料金) で課金されます。
+ sys\$1serverless\$1usage システムテーブルのレコードには、1 分間隔で発生したコストが表示されます。以下の列について理解することが重要です。
charged\$1seconds 列:
+ 時間間隔中に課金されたコンピュートユニット (RPU) 秒が提供されます。結果には、Amazon Redshift Serverless の最低料金が含まれます。
+ トランザクション完了後の compute-resource の使用量に関する情報があります。したがって、トランザクションが完了していない場合、この列の値は 0 になります。
compute\$1seconds 列:
+ コンピューティングの使用状況情報をリアルタイムで提供します。Amazon Redshift Serverless の最低料金は含まれていません。そのため、インターバル中に請求される請求秒数とはある程度異なる場合があります。
+ (トランザクションが終了していない場合でも) 各トランザクション中の使用状況情報を表示するため、提供されるデータはリアルタイムで表示されます。
+ compute\$1seconds が 0 であるが charged\$1seconds が 0 より大きい場合も、その逆の場合もあります。これはシステムビューでのデータの記録方法によって生じる通常の動作です。サーバーレスの使用状況の詳細をより正確に表すには、SYS\$1SERVERLESS\$1USAGE のデータを集計することをお勧めします。
テーブルとビューのモニタリングの詳細については、「[Amazon Redshift Serverless でのクエリとワークロードのモニタリング](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-monitoring.html)」を参照してください。
### CloudWatch を使用した使用状況の可視化
CloudWatch で利用可能なメトリクスを使用して、使用状況を追跡できます。CloudWatch 用に生成されるメトリックスには、現在時刻で使用された RPU の総秒数を示す `ComputeSeconds`、その時点の合計のコンピューティング性能を示す `ComputeCapacity` があります。使用量のメトリクスは、Redshift **Serverless dashboard** の Redshift コンソールでも検索できます。CloudWatch の詳細については、「[Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)」を参照してください。
# サーバーレス予約に対する請求
Amazon Redshift Serverless では、従量制料金モデルでクラスターをプロビジョニングおよび管理することなく、分析を実行およびスケールできます。サーバーレス予約を使用すると、コンピューティングコストをさらに最適化し、Redshift Serverless の既存および新規のワークロードのコスト予測可能性を向上させることができます。
Amazon Redshift は、AWS 支払者アカウントレベルでサーバーレス予約を管理し、複数の AWS アカウント間で予約を共有できるため、AWS アカウント内のすべての Redshift Serverless ワークロードでコンピューティングコストを最大 24% 削減できます。Amazon Redshift はサーバーレス予約を 1 時間ごとに請求し、1 秒あたりの予約数を計測して、Redshift Serverless が提供する柔軟性を維持しながら、24 時間 365 日、一貫した請求モデルを提供します。Amazon Redshift は、指定された RPU レベルを超える使用量に対して標準のオンデマンドレートで課金します。
**注記**
オンデマンド使用量を制限する場合は、**[最大容量]** 設定を使用して、ワークグループのリソース使用量の制限を設定できます。詳細については、「[Amazon Redshift Serverless での請求](serverless-billing.md)」を参照してください。
## サーバーレス予約の利点
サーバーレス予約は、Amazon Redshift Serverless の割引料金オプションです。サーバーレス予約では、1 年間、前払いなしのオンデマンド (OD) 料金の割引により、指定された数の Redshift 処理ユニット (RPU) にコミットできます。前払いにより、割引率が高くなります。サーバーレス予約を使用すると、コンピューティングコストを最適化し、Serverless の既存および新規のワークロードのコスト予測可能性を向上させることができます。
各サーバーレス予約は、AWS アカウントレベルで購入し、同じ支払者アカウント内の複数の Amazon Redshift Serverless ワークグループ間で共有できます。これにより、割引が柔軟に適用されます。ワークロードパターンが異なる複数のワークグループ間で予約を共有できます。
## サーバーレス予約の仕組み
RPU の予約は、ほんの数分で完了する簡単なプロセスです。これには、予約する RPU レベルと支払いタイプの指定が含まれます。Amazon Redshift Serverless で使用している標準の AWS 請求およびコスト管理ツールは、必要な予約レベルを決定し、使用状況を継続的にモニタリングするのに役立ちます。サーバーレス予約は AWS 支払者アカウントレベルで管理され、同じ支払者アカウントで共有できるため、AWS アカウント内のすべての Redshift Serverless ワークロードでコンピューティングコストを最大 24% 削減できます。サーバーレス予約は、1 時間ごとの請求と 1 秒ごとの計測により、Redshift Serverless が提供する柔軟性を維持しながら、24 時間 365 日、一貫した請求モデルを提供します。指定された RPU レベルを超える使用量は、標準の Redshift Serverless オンデマンド料金で課金されます。
同じ AWS アカウント内で複数のサーバーレス予約を購入できます。追加で購入したサーバーレス予約は、前の購入と合わせて考慮されます。例えば、2 つの予約を購入し、各予約で 100 RPU を選択した場合、合計 200 RPU が割引料金で提供されます。
**注記**
オンデマンド使用量に制限を設定する場合は、**[制限]** タブ、**[使用制限を管理]** の順に選択して、Amazon Redshift Serverless コンソールでワークグループの最大 RPU 数を設定できます。
サーバーレス予約を購入すると、予約はすぐに有効になり、Redshift コンソールのサーバーレス予約ダッシュボードに表示されます。
## RPU (Redshift 処理ユニット) の使用を分析して必要な予約レベルを決定する
Redshift Serverless 予約では、特定の数の Redshift 処理ユニット (RPU) に 1 年間コミットすることで、予測可能で低いコンピューティングコストを確保できるため、オンデマンド料金よりも割引率が高くなります。前払いなしオプションの場合は最大 20%、全額前払いの場合は最大 24% の割引となります。Redshift Serverless 予約は、AWS 支払いアカウントレベルで購入します。割引は AWS にリンクされたすべてのアカウントの Redshift Serverless ワークグループに自動的に適用されるため、複数のチームをサポートしながら予算を一元管理できます。Redshift Serverless は、使用量を秒単位の詳細度で計測し、各時間で平均して時間単位で請求するため、使用した容量に対してのみ料金が発生します。Redshift Serverless 予約は、アカウント間の柔軟な適用と期間ベースの節約を組み合わせることで、Redshift Serverless の俊敏性を犠牲にすることなく、予測可能な分析料金を実現します。
### 予約の RPU 使用状況の分析
RPU の使用状況は、Redshift Serverless ダッシュボードでの 7 日間表示と、Cost Explorer を使用した長期分析の 2 つの方法のいずれかで確認できます。次の手順は、RPU の使用状況を分析する方法を示しています。
**方法 1: Redshift Serverless ダッシュボード (7 日間表示）**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. Serverless ダッシュボードを開きます。
1. ワークグループを選択します。
1. 過去 1 時間から 1 週間までの RPU 容量の使用状況を表示します。
**方法 2: AWS Cost Explorer (長期分析）**
1. AWS マネジメントコンソールにサインインし、Cost Explorer コンソール ([https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/)) を開きます。
1. [詳細度] を**[時間単位]** に設定します。
1. **[使用タイプ]** 別にグループ化します。
1. 以下のフィルタを使用できます。
+ サービス: Redshift
+ リージョン: ローカルリージョン
+ 使用タイプ: **Redshift:ServerlessUsage** のフィルター
1. 選択したリージョンにおける時間単位のサーバーレス使用状況に関するコストと使用状況グラフを確認します。
## コンソールを使用したサーバーレス予約の購入
予約を購入するときは、割引対象となる RPU レベルを選択します。RPU レベルを選択する前に、ベース容量と時間の経過とともに使用するオンデマンド容量を知っておくことが役立ちます。このセクションでは、容量を決定し、サーバーレス予約を予約する方法について説明します。
開始するには、Redshift コンソールで **[サーバーレス]** を選択し、メニューから **[サーバーレス予約]** を選択します。
![\[Amazon Redshift console showing Serverless dashboard with Serverless reservations option highlighted.\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/images/capacity-reservations-menu-selection.png)
コンソールには、機能の説明と既存の予約のリストが表示されます。ここから予約を購入するか、レポートとモニタリングツールを使用して現在の使用状況を確認できます。これらは、RPU レベルと予約に適した RPU 数を決定するのに役立ちます。
予約を購入するには、次の手順を実行します。
1. **[サーバーレス予約を購入]** を選択します。
![\[Reservation overview showing 1 RPU total, 0 expiring, with option to purchase Serverless reservations.\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/images/capacity-reservations-list-purchase.png)
1. ウォークスルーが表示され、一連の選択肢が示されます。**[サーバーレス予約]** に予約する RPU レベルを入力します。このレベルが不明な場合は、このセクションの後で説明するツールを使用できます。
![\[Input field for entering reserved RPU capacity, with a range from 1 to any number.\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/images/capacity-reservations-RPU-level.png)
1. 支払いタイプを設定します。予約した RPU の前払い、または月払いを選択できます。前払いを選択すると、割引率が高くなります。
![\[Payment type options: All Upfront with 24% discount or No Upfront with 20% discount.\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/images/capacity-reservations-payment-type.png)
1. 選択が完了したら、**[サーバーレス予約を購入]**、**[確認]** の順に選択します。
予約を確認すると、予約のリストに表示されます。
![\[Serverless reservations table showing one payment-pending reservation with details.\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/images/capacity-reservations-list-created.png)
## 使用に関する注意事項
+ 予約を変更または削除することはできません。ただし、追加の予約を作成してカバー範囲を広げることができます。
+ Redshift Serverless は、ワークロードの予約した RPU を使用してからオンデマンド RPU を使用することで、コストを削減します。予約した RPU 数を超えると、超えた分の RPU に対して、Redshift Serverless オンデマンド料金で課金されます。
+ Amazon Redshift Serverless の無料クレジットは、サーバーレス予約には適用されず、オンデマンドで請求される RPU にのみ適用されます。
## サーバーレス予約の例
このシナリオでは、AWS 支払者/連結アカウントに 2 つの Amazon Redshift ワークグループがあります。
+ ワークグループ 1 では、ビジネスインテリジェンスチームの場合など、使用量が定常状態です。
+ ワークグループ 2 では、ETL オペレーションなど、ワークロードが予測不可能で、使用量が急増する場合があります。
これらのワークグループのコストを最適化するために、1 年間のサーバーレス予約を購入します。履歴データに基づいて、両方のワークグループは定常状態で 64 RPU を消費すると判断します。ただし、ワークグループ 2 は、短期間に 32 RPU から 48 RPU に増加したり、24 RPU に減少したりすることがあります。予約の RPU レベルを、過去の傾向に合わせて 64 RPU に設定して開始します。時間ごとの請求の詳細は次のとおりです。
+ 最初の 1 時間は、過去の使用状況の傾向と同様に、両方のワークグループが 32 RPU を使用し、アカウントの合計使用量が 64 RPU になります。この 1 時間では、すべての RPU がサーバーレス予約の割引料金で課金されます。64 RPU の使用レベルが 64 RPU のサーバーレス予約と等しいためです。
+ 2 時間目で、ワークグループ 1 は引き続き 32 RPU を使用します。一方、ワークグループ 2 は 48 RPU に急増し、アカウントの合計使用量は 80 RPU になります。この 1 時間では、64 RPU がサーバーレス予約の割引料金で課金され、16 RPU が Redshift Serverless オンデマンド料金で課金されます。
+ 3 時間目で、ワークグループ 1 は引き続き 32 RPU を消費し、ワークグループ 2 は 8 RPU に減少します。この 1 時間では、アカウントの合計が 40 RPU であっても、64 RPU のサーバーレス予約料金がアカウントに課金されます。
ワークグループの使用状況の推移と、オンデマンドおよびサーバーレス予約料金の請求の詳細については、次の図を参照してください。
![\[Graph showing total account usage, on-demand usage, and workgroup trends over three time periods.\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/images/capacity-reservation-example.png)
## AWS CLI または Amazon Redshift API を使用したサーバーレス予約の購入
`create-reservation` を使用して RPU 予約を作成します。このコマンドを以下に示します。
```
create-reservation
--capacity
--offering-id
```
`capacity` は、予約する RPU 数に設定します。
## ストレージの請求
プライマリストレージ容量は、Redshift マネージドストレージ (RMS) として請求されます。ストレージは GB /月単位で請求されます。ストレージの請求は、コンピューティング能力の請求とは別に行われます。ユーザースナップショットに使用されるストレージは、利用枠に応じて標準のバックアップ請求レートで請求されます。
データ転送と機械学習 (ML) の料金は、プロビジョニングされたクラスターと同じように、別々に適用されます。AWS リージョン間のスナップショットレプリケーションとデータ共有は、料金ページに記載されている概略の転送レートで請求されます。詳細については、[Amazon Redshift の料金](https://aws.amazon.com//redshift/pricing/)を参照してください。
### CloudWatch を使用した使用料請求の可視化
スナップショットストレージの使用状況を追跡するメトリクス `SnapshotStorage` が生成され、CloudWatch に送信されます。CloudWatch の詳細については、「[Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)」を参照してください。
## Amazon Redshift Serverless 無料トライアルの利用
Amazon Redshift Serverless は無料トライアルを提供しています。無料トライアルに参加する場合は、Redshift コンソールで無料トライアルのクレジット残高を表示し、[SYS\$1SERVERLESS\$1USAGE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_SERVERLESS_USAGE.html) システムビューで無料トライアルの使用を確認できます。無料トライアルの使用に関する請求の詳細は、請求コンソールに表示されないことに注意してください。使用状況は、無料トライアルの終了後にのみ、請求コンソールで確認できます。Amazon Redshift Serverless 無料トライアルの詳細については、「[Amazon Redshift Serverless 無料トライアル](https://aws.amazon.com//redshift/free-trial/)」を参照してください。
## 使用料の請求についての注記
+ **使用量の記録** - クエリやトランザクションは、トランザクションの完了、ロールバック、停止後にのみ測定、記録されます。例えば、トランザクションが 2 日間実行された場合、RPU の使用量はトランザクションの完了後に記録されます。`sys_serverless_usage` のクエリを実行することで、使用中の状況をリアルタイムでモニタリングできます。トランザクション記録は、RPU 使用量の変動として反映され、特定の時間や毎日の使用のコストに影響を与える可能性があります。
+ **明示的なトランザクションを記述する** - トランザクションを終了することは、重要な役割を果たすベストプラクティスです。開いているトランザクションを終了またはロールバックしない場合、Amazon Redshift Serverless は RPU を使用し続けます。例えば、`BEGIN TRAN`を明示的に記述する場合、それに対応した `COMMIT` や `ROLLBACK` の記述があることが重要です。
+ **クエリのキャンセル** - クエリを実行し、終了する前にキャンセルした場合は、クエリの実行時間に対して請求されます。
+ **スケーリング** - Amazon Redshift Serverless インスタンスは、パフォーマンスを一定に保つためにスケーリングを開始して、負荷の高い時間に対応する場合があります。Amazon Redshift Serverless の請求には、同じ RPU レートでの基本のコンピューティング性能とスケール処理容量の両方が含まれます。
+ **スケールダウン** - Amazon Redshift Serverless は、基本 RPU 容量からスケールアップして、負荷の高い時間を処理します。場合によっては、クエリの負荷が低下した後も、RPU 容量が一定期間高い設定のままになる場合があります。予想外のコストを防ぐため、コンソールで最大 RPU 時間を設定することを推奨します。
+ **システムテーブル** - システムテーブルのクエリを実行すると、クエリ時間が請求されます。
+ **Redshift Spectrum** - Amazon Redshift Serverless があり、クエリを実行する場合、データレイククエリには別途の料金は発生しません。Amazon S3 に保存されているデータに対するクエリの場合は、トランザクション時間ごとに、ローカルデータに対するクエリと同じ料金になります。
+ **フェデレーティッドクエリ** - フェデレーションクエリは、データウェアハウスまたはデータレイクでのクエリと同様に、特定の時間で使用される RPU に基づいて課金されます。
+ **ストレージ** - ストレージは GB/月単位で別途請求されます。
+ **最低料金** – リソース使用量は最低 60 秒として課金され、1 秒単位で計測されます。
+ **スナップショットの請求** - スナップショットの請求は変更されません。スナップショットの請求は、GB /月のレートで請求されるストレージに応じて課金されます。データウェアハウスを過去 30 分単位で、24 時間内の特定のポイントに、無料で復元できます。詳細については、[Amazon Redshift の料金](https://aws.amazon.com//redshift/pricing/)を参照してください。
+ **自動最適化は、追加のコンピューティングリソースを使用して実行されます** - Amazon Redshift Serverless は通常、ユーザークエリと共に自動最適化オペレーションを実行します。これらのオペレーションは自律管理と呼ばれ、料金は発生しません。
追加のコンピューティングリソースの割り当てを有効にすると、Amazon Redshift はユーザーアクティビティが高い期間でも、必要に応じて自律管理を実行します。このような場合は、自律管理の実行に費やされた時間に対して課金されます。詳細については、「*Amazon Redshift データベースデベロッパーガイド*」の「[データベースの自動最適化のための追加のコンピューティングリソースの割り当て](https://docs.aws.amazon.com/redshift/latest/dg/t_extra-compute-autonomics.html)」を参照してください。
### 請求を予測可能にするための Amazon Redshift Serverless のベストプラクティス
一貫した請求を維持するために役立つベストプラクティスと組み込みの設定を以下に示します。
+ 各トランザクションを必ず終了してください。`BEGIN` を使ってトランザクションを開始する場合、それを `END` することも重要です。
+ また、エラー処理のベストプラクティスに従ってエラーに適切に対応し、各トランザクションを終了します。オープントランザクションを最小化することで、不要な RPU の使用を回避できます。
+ `SESSION TIMEOUT` を使用して、開いているトランザクションとアイドルセッションを終了します。これにより、3600 秒 (1 時間）を超えてアイドル状態または非アクティブの状態のセッションがすべてタイムアウトします。これにより、21600 秒 (6 時間) を超えて開いたままの状態または非アクティブの状態のトランザクションがすべてタイムアウトします。このタイムアウト設定は、長時間実行されるクエリに対してセッションを開いたままにする場合など、特定のユーザーに対して明示的に変更できます。[CREATE USER](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_USER.html) のトピックに、ユーザーに対して `SESSION TIMEOUT` を調整する方法が記載されています。
+ `SESSION TIMEOUT` の値は、ユースケースで具体的に求められていないかぎり、ほとんどの場合では、延長しないことを推奨します。開いているトランザクションでセッションがアイドル状態のままの場合、セッションが閉じられるまで RPU が使用されることがあります。これによって不要なコストが発生します。
+ Amazon Redshift Serverless では、クエリの実行時間が最大 86,399秒 (24時間) です。Amazon Redshift Serverless がトランザクションに関連付けられたセッションを終了するまでの、オープントランザクションのアイドル状態の最大期間は 6 時間です。詳細については、「[Amazon Redshift Serverless オブジェクトのクォータ](amazon-redshift-limits.md#serverless-limits-account)」を参照してください。
## 接続プーリングを使用した Amazon Redshift Serverless の請求
Amazon Redshift Serverless は、接続プールによって送信される軽量ヘルスチェッククエリを含む、すべての受信クエリを請求可能なユーザーアクティビティとして扱います。この動作は、クエリのソースがアプリケーション、JDBC/ODBC ドライバー、または接続プーリングフレームワークのいずれであるかに関係なく適用されます。各ヘルスチェッククエリはコンピューティング使用量をトリガーし、クエリの目的やオリジンに関係なく料金が発生します。その結果、オープン接続プールを維持することで、実際のユーザーワークロードが実行されていなくてもコストが発生する可能性があります。
接続プーリングは、アプリケーションと Amazon Redshift Serverless エンドポイント間の永続的な接続のプールを維持します。これらの接続が正常で利用可能であることを確認するために、プーリングメカニズムは多くの場合、軽量または空のクエリ (例: `SELECT 1`) を定期的に送信します。これらの自動クエリは、接続ステータスを検証します。
接続プーリングを使用する場合は、意図しない料金を最小限に抑えるために、次のベストプラクティスを考慮してください。
+ 接続プーリング設定でヘルスチェックまたはキープアライブクエリの頻度を確認して最適化することで、ヘルスチェックの頻度を調整します。
+ システムのアイドル時間中に不要な接続チャーンやバックグラウンドクエリアクティビティを最小限に抑えるように接続プーリングを設定して、アイドルシステム設定を最適化します。
+ オーバーヘッドを削減できる場合は、アプリケーションレベルのプーリングを実装するか、接続ライフサイクル管理を改善します。
+ 接続プーリング設定で許可されている場合は、ハートビートクエリまたは検証クエリを無効にします。特定の接続文字列パラメータまたは設定ファイルをチェックして、これらの設定を調整します。
+ TCP キープアライブ設定のファインチューニング: ドライバーの内部ハートビートメカニズムを無効にすることができない場合は、オペレーティングシステムまたはアプリケーションレベルで Transmission Control Protocol (TCP) キープアライブ設定を調整して、接続タイムアウトの問題に対処します。詳細については、オペレーティングシステム、JDBC/ODBC ドライバー、または接続プールのドキュメントを参照してください。
+ データベース接続プーリングの最適化: 接続を管理し、接続オーバーヘッドを最小限に抑えるように接続プール (HikariCP、Apache データベース接続プール) を設定します。最大接続数、アイドルタイムアウト、検証クエリ (必要な場合) などのパラメータに焦点を当てます。この最適化により、Amazon Redshift Serverless のコンピューティング使用量を実際のワークロード需要に合わせて調整できるため、コスト削減につながる可能性があります。
## ゼロ ETL を使用した Amazon Redshift Serverless のコスト最適化
Amazon Redshift Serverless でゼロ ETL 統合を実行しながらコストを最適化するために、環境のサイズを適切に設定し、ワークロードのニーズに基づいて更新設定を調整できます。以下の調整を検討してください。
+ ワークロードで使用可能な場合は、8 RPU のより低い基本 RPU 容量を使用します。
+ ターゲット Redshift インスタンスの REFRESH\$1INTERVAL を設定し、鮮度とコストのバランスを取ることができます。間隔を短くすると、ほぼリアルタイムの更新が確保されますが、計算コストが増加します。間隔を長くすると (5 分以上)、レポートや履歴分析など、即時の鮮度が重要ではないワークロードの料金が削減されます。Redshift ターゲット REFRESH\$1INTERVAL を編集するには、[ALTER DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_DATABASE.html) の説明の更新間隔句を参照してください。
+ ゼロ ETL データの取り込み中に分析ワークロードを同時に実行することで、Amazon Redshift Serverless 環境の使用率を最大化します。これにより、コンピューティング性能が複数のビジネス目的にアクティブに対応できるようになります。