![[アップデート] Amazon Redshift Serverless 2-AZ サブネット構成を試してみました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-63f1274931b942e9a92e601c1127ad73/cfe87ec6d62fa2fc3c474ed4cb2f6c2e/amazon-redshift)
[アップデート] Amazon Redshift Serverless 2-AZ サブネット構成を試してみました
2025.07.25クラウド事業本部コンサルティング部の石川です。本日から拡張 VPC ルーティング (EVR) を使用しない場合に、Amazon Redshift Serverless 2-AZ サブネット構成をサポートしました。これで、既存のRedshift ProvisionedからRedshift Serverlessへのリプレースするのにネットワーク構成を変更せずに済むようになりそうです。本記事では、このアップデートの特長を解説し、実際に2-AZサブネット構成を試してみます。
2-AZ サブネット構成をサポートとは
Amazon Redshift Serverless ワークグループを作成するには、Amazon VPC サブネットネットワーク内に 3 つの AZ が必要でしたが、拡張 VPC ルーティング (EVR) を使用しない場合に、2 つのアベイラビリティゾーン (AZ) を持つサブネット構成をサポートするようになりました。
このアップデートにより、Amazon VPC サブネットネットワークに 3 つの AZ が不要になります。特に、Redshift Provisioned（RA3インスタンスやDC2インスタンス）からRedshift Serverlessへ、ネットワーク構成を変更することなく移行できるようになります。
Redshift Serverless は、サーバーのプロビジョニングや管理の手間を省き、自動スケーリングを実現するフルマネージド型データウェアハウスサービスです。ベース RPU サイズ（4～1024 RPU）、ワークグループの RPU 使用量、AI 駆動型スケーリングと最適化の有効化の有無に関係なく適用されます。
拡張 VPC ルーティング (EVR) を使用できないとは
2-AZ サブネット構成をサポートの前提条件として、「拡張 VPC ルーティング (EVR) を使用できない」があります。2-AZ サブネット構成を採用できるかを判断するため、拡張 VPC ルーティング (EVR)とは何か、そして、そのメリット・デメリットについて理解します。
拡張 VPC ルーティング (EVR) とは
拡張 VPC ルーティング (EVR)とは、Redshiftクラスターが外部のデータソース（主にAmazon S3など）と通信する際、そのトラフィックを必ずAmazon VPC内のネットワークのみを経由させる仕組みです。これを有効化することで、RedshiftのCOPYやUNLOADコマンドによるデータの送受信などが、VPCのルートテーブル、セキュリティグループ、NACL（ネットワークACL）などで制御できるようになります。
- EVR無効時：一部通信がAWSグローバルネットワークを経由する場合がある
- EVR有効時：通信は常にVPC内部経由、細かなネットワーク制御や監査が可能
拡張 VPC ルーティング (EVR) のメリット
| 項目 | 内容 |
|---|---|
| セキュリティ強化 | 通信がプライベートネットワーク（VPC）内で完結。NAT GatewayやVPCエンドポイントを使うことで、インターネット非経由でS3などにアクセス可能。 |
| トラフィック制御 | VPCのルートテーブルやセキュリティグループ、NACLによるきめ細かなネットワーク制御が可能。 |
| ロギング・監査性 | VPC Flow Logsを利用して通信ログを取得可能。RedshiftがS3へどのようなアクセスを行ったか監査できる。 |
| プライベート構成対応 | S3やDynamoDBのVPCエンドポイントと組み合わせて、完全な非公開環境を実現可能。 |
| 企業コンプライアンス | 厳格なネットワーク分離が必要なシナリオや、内部ポリシー・法令遵守要件に有効。 |
拡張 VPC ルーティング (EVR) のデメリット
| 項目 | 内容 |
|---|---|
| 要追加リソース | NAT GatewayやS3 Gateway型VPCエンドポイントの設定が追加で必要。 |
| 設定不備時は通信失敗 | 正しいルートテーブルやIAMロール設定がなければUNLOAD/COPYでエラーになりやすい。 |
| 一時停止要件 | 既存クラスターでEVR設定をON/OFF切り替え時、一時的にサービス停止が発生する可能性がある。 |
| IPアドレス割当が増える場合がある | EVR有効時は従来通り多めのIPアドレス割り当てが必要になる（Serverlessの場合等）。 |
上記以外に、機能的なデメリットがあります。
Redshift SpectrumはEVR非対応
拡張VPCルーティング（EVR）を有効にしているAmazon Redshiftから、IPアドレス制限をかけているS3バケットへのRedshift Spectrum経由アクセスは基本的にできません。
この回避策としては、IPアドレスやVPCエンドポイント制限ではなく、Redshift用のIAMロール・サービスプリンシパル単位でS3へのアクセスをバケットポリシーで制御することで、Redshift Spectrumからもアクセスできます。
RPUの増加に伴い、サブネット内のプライベートIPアドレスを確保する必要がある
Redshift Serverless のワークグループ作成時に指定する RPU によって生成される プライベートIPアドレス の数が変わる、それに関連して配置可能なサブネットのサイズも変動します。大規模なRedshift Serverless では、消費するプライベートIPアドレスの数を考慮する必要があります。
現在では、拡張 VPC ルーティング (EVR)を使用しない場合は、サブネットあたり1つのIPがアドレスで済むようになりました。
補足: 拡張 VPC ルーティング (EVR) の歴史的経緯と、AWSサービス間の通信
拡張 VPC ルーティング (EVR) が導入された当初は、境界型ネットワークが主流であり、データのやり取りにインターネットを経由しないことを強く求められました。その後、現在ではAWSサービス間でパブリックIPアドレスを使った通信は、インターネットを経由せず、AWSのプライベートかつ独自のグローバルネットワーク内で完結することがAWS公式FAQで明確に保証されています。
以下、Amazon VPC のよくある質問の「接続」2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスがパブリックな AWS のサービスエンドポイントと通信する場合、トラフィックはインターネットを経由しますか? より引用
2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスがパブリックな AWS のサービスエンドポイントと通信する場合、トラフィックはインターネットを経由しますか?
いいえ。パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。
さらに、データセンターとリージョンを相互接続する AWS グローバルネットワークを流れるすべてのデータは、安全性が保証された施設を離れる前に、物理レイヤーで自動的に暗号化されます。すべての VPC クロスリージョンピアリングトラフィックや、カスタマーまたはサービス間のトランスポート層セキュリティ (TLS) 接続などといった追加の暗号化レイヤーもあります。
2-AZ サブネット構成を試す！
2-AZ サブネット構成のRedshift Serverlessを構築
従来は、サブネットを3つ選択（3−AZサブネット）を選択する必要がありましたが、現在はサブネットを2つ選択（2−AZサブネット）でもエラーにならなくなりました。また、[Enhanced VPC routing]は、選択せずに無効化しています。
プライベートIPアドレスの数を確認する
2-AZ（2サブネット）において、Redshift ServerlessのRPUの違いによって、プライベートIPアドレスについて確認します。
なお、Redshift Privisionedは、ENI（Elastic Network Interface）が割り当てられていますが、Redshift Serverlessは、VPC Endpoint Interfaceが割り当てられています。
2-AZ（2サブネット）、4RPUの場合、EVRなし
エンドポイントに割り当てられている２つのプライベートIPアドレスの他に１つプライベートIPアドレスが確保されています。
2-AZ（2サブネット）、32RPUの場合、EVRなし
32RPUに変更しましたが、プライベートIPアドレスに変更はありません。
補足: 拡張 VPC ルーティング (EVR) を有効はどうなるか
マネジメントコンソールから、2-AZ（2サブネット）、4RPUの場合、EVRあり、という条件で、Redshift Serverless を作成すると、設定したにも関わらず workgroupが作成されませんでした。
最後に
Amazon Redshift Serverlessが2-AZサブネット構成をサポートしたことにより、ネットワーク設計の選択肢が広がり、3-AZに比べたサブネット設計上の制約が緩和されました。特に、EVRを利用しない環境ではこれまで以上に簡易かつ効率的な環境構築が可能となっています。一方で、EVRの有効化には依然として制限や注意点があり、用途やセキュリティ要件に応じて使い分ける必要があります。今後もサービスの進化に伴いさらなる柔軟性や機能追加が期待されるため、最新情報のキャッチアップと適切な設計判断が重要です。
ここ一年で、Redshift Serverlessは、DC2インスタンスの後継として様々な改善がありました。Redshift Serverlessをリプレースの第一候補として、検討していただければ幸いです。
