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/)を参照してください。
# マルチ AZ 配置のセットアップ
マルチ AZ 配置をセットアップするには、**[マルチ AZ]** オプションを選択し、各アベイラビリティーゾーンにプロビジョニングするコンピューティングノードの数を指定します。Amazon Redshift は 2 つのアベイラビリティーゾーンに同等のコンピューティングリソースを自動的にデプロイし、通常の運用中はすべてのコンピューティングリソースを読み取りと書き込みの両方の処理にいつでも利用できます。そのため、マルチ AZ 配置は 1 つのエンドポイントを持つ単一のデータウェアハウスとして機能し、災害発生時にアプリケーションを変更する必要がなくなります。マルチ AZ 配置では、1 つのアベイラビリティーゾーンのみにあるコンピューティングリソースを使用して個別のクエリを処理しますが、複数の同時クエリの処理を両方のアベイラビリティーゾーンに自動的に分散して、同時実行性の高いワークロードの全体的なスループットを高めることができます。
既存のシングル AZ データウェアハウスをマルチ AZ データウェアハウスに変換したり、その逆を行うこともできます。2 つ目のアベイラビリティーゾーンに追加のコンピューティングリソースがプロビジョニングされる点以外は、すべて変わりません。既存のシングル AZ クラスターからマルチ AZ クラスターに移行する場合、単一クエリのパフォーマンスを維持しやすくするために、必要なクラスターノードの数を 2 倍にする必要がある場合があります。マルチ AZ データウェアハウスの場合、利用可能なコンピューティングリソースが 2 倍になるため、ほとんどのワークロードでクエリ処理全体のスループットが向上します。
アベイラビリティーゾーンで障害が発生した場合、Amazon Redshift は残りのアベイラビリティーゾーンのリソースを自動的に使用して運用を継続します。ただし、ユーザー接続については失われる可能性があるため、再確立する必要があります。また、障害が発生したアベイラビリティーゾーンで実行されていたクエリは失敗する可能性があり、再試行する必要があります。ただし、クラスターに再接続してクエリをすぐに再スケジュールできます。そうすることで、Amazon Redshift は残りのアベイラビリティーゾーンでクエリを処理します。障害発生時または障害発生後に発行されたクエリでは、マルチ AZ データウェアハウスの復旧中に実行時の遅延が発生する可能性があります。
**注記**
パフォーマンスと可用性を向上させるには、マルチ AZ クラスターで SNAPSHOT ISOLATION を使用することをお勧めします。詳細については、「[データベースの作成](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_DATABASE.html)」を参照してください。
## 制限事項
マルチ AZ データウェアハウスは、マルチ AZ データウェアハウスに適用される以下の制限を除いて、シングル AZ データウェアハウスと同じ機能を備えています。
+ 暗号化されていないマルチ AZ データウェアハウスを作成することはできません。マルチ AZ データウェアハウスを新規作成する場合、シングル AZ データウェアハウスをマルチ AZ データウェアハウスに変換する場合、またはシングル AZ データウェアハウスをマルチ AZ データウェアハウスに変換する場合は、必ず暗号化を追加してください。
+ いずれの RA3 インスタンスタイプに対しても、単一ノードのマルチ AZ 配置を作成することはできません。マルチ AZ 配置を作成しているときにノードを 2 つ以上選択します。
+ Amazon Redshift は、3 つ未満のアベイラビリティーゾーンをサポートできるサブネット設定をサポートしていません。つまり、設定されたサブネットグループには 3 つ以上のサブネットが必要です。
+ マルチ AZ 配置を別のアベイラビリティーゾーンに再配置することはできません。マルチ AZ 配置を使用している場合、再配置は Amazon Redshift によって自動的に決定および実行されます。
+ マルチ AZ 配置を一時停止または再開することはできません。
+ マルチ AZ 配置は、サポートされている 5431～5455 と 8191～8215 の範囲のポート以外では実行できません。
+ STL、SVCS、SVL、SVV、STV ビューはシステムモニタリングビュー (SYS\_\* ビュー) のみをサポートしているため、マルチ AZ 配置では使用できません。システムモニタリングビュー (SYS\_\* ビュー) を使用するようにモニタリングクエリを変更してください。
+ マルチ AZ が有効になっている既存のクラスターに Elastic IP アドレスをアタッチすることはできません。
+ Elastic IP アドレスがアタッチされたクラスターをシングル AZ からマルチ AZ に変換することはできません。
+ Amazon Redshift マルチ AZ 配置は以下の AWS リージョン で利用できます。
+ 米国東部 (オハイオ) (us-east-2)
+ 米国東部 (バージニア北部) (us-east-1)
+ 米国西部 (オレゴン) (us-west-2)
+ アフリカ (ケープタウン) (af-south-1)
+ アジアパシフィック (香港) (ap-east-1)
+ アジアパシフィック (台北) (ap-east-2)
+ アジアパシフィック (ハイデラバード) (ap-south-2)
+ アジアパシフィック (ジャカルタ) (ap-southeast-3)
+ アジアパシフィック (マレーシア) (ap-southeast-5)
+ アジアパシフィック (メルボルン) (ap-southeast-4)
+ アジアパシフィック (ムンバイ) (ap-south-1)
+ アジアパシフィック (大阪) (ap-northeast-3)
+ アジアパシフィック (ソウル) (ap-northeast-2)
+ アジアパシフィック (シンガポール) (ap-southeast-1)
+ アジアパシフィック (シドニー) (ap-southeast-2)
+ アジアパシフィック (ニュージーランド) (ap-southeast-6)
+ アジアパシフィック (タイ) (ap-southeast-7)
+ アジアパシフィック (東京) (ap-northeast-1)
+ カナダ (中部) (ca-central-1)
+ 中国 (北京) (cn-north-1)
+ 中国 (寧夏) (cn-northwest-1)
+ ヨーロッパ (フランクフルト) (eu-central-1)
+ 欧州 (アイルランド) (eu-west-1)
+ ヨーロッパ (ロンドン) (eu-west-2)
+ 欧州 (ミラノ) (eu-south-1)
+ 欧州 (パリ) (eu-west-3)
+ 欧州 (スペイン) (eu-south-2)
+ 欧州 (ストックホルム) (eu-north-1)
+ 欧州 (チューリッヒ) (eu-central-2)
+ イスラエル (テルアビブ) (il-central-1)
+ メキシコ (中部) (mx-central-1)
+ 中東 (バーレーン) (me-south-1)
+ 中東 (UAE) (me-central-1)
+ 南米 (サンパウロ) (sa-east-1)
+ AWS GovCloud (米国東部) (us-gov-east-1)
+ AWS GovCloud (米国西部) (us-gov-west-1)
+ パブリックアクセス可能なマルチ AZ データウェアハウスは、シングル AZ およびプライベートアクセス可能なマルチ AZ ウェアハウスよりも 1 つ少ない VPC セキュリティグループをサポートします。