Amazon Redshift 拡張VPCルーティングのよくある4つの疑問とベストプラクティスを整理してみた
クラウド事業本部の石川です。Amazon Redshiftの拡張VPCルーティング（Enhanced VPC Routing）について、最近の問い合わせや調査でよく出てきた4つの疑問を整理し、ベストプラクティスとしてまとめてみました。
Amazon Redshiftの拡張VPCルーティングは、Redshiftと他のAWSサービス（特にAmazon S3）との通信をVPC経由に強制するための機能です。デフォルトでは無効になっており、有効化には追加の設定が必要です。
最近、以下のような背景でこの機能に関する問い合わせが増えています。
- 2026年5月12日にリリースされた新しいGravitonベースの RGインスタンス の登場
- Redshift ServerlessでのVPC設計を踏まえた拡張VPCルーティング有効化の増加傾向
- Amazon VPC FAQで「パブリックIPアドレスを使用する場合でも、AWSのプライベートネットワークを使用する」と明記された影響
本記事では「結局、現場ではどう判断しているのか」という観点で、現場のRedshift運用者からよく聞かれる4つの疑問を整理し、後半でベストプラクティスとして体系化します。
拡張VPCルーティングとは
拡張VPCルーティングを 有効 にすると、RedshiftクラスターとAWSサービス（S3、DynamoDB、Glue Data Catalog等）間のトラフィックがすべて、ユーザーのVPCを経由するようになります。
無効時の挙動:
- COPY/UNLOADのS3アクセスはAWSバックボーンを経由（VPC外）
- VPCフローログに記録されない
- VPC Endpoint Policy / Security Groupでの制御不可
有効時の挙動:
- S3アクセスがVPC Endpointまたはインターネットゲートウェイ経由になる
- VPCフローログでS3アクセスを記録可能
- VPC Endpoint Policyで通信制御が可能
現場でよくある4つの疑問
Q1: 有効と無効、現場ではどっちが多いの？
結論から言うと、肌感としては 「無効6:有効4」程度の比率で、無効のままの環境がやや多い 印象です。パブリックアクセス設定ほど「無効が当たり前」というコンセンサスにはなっておらず、組織のセキュリティ要件に応じて判断が分かれます。
無効のままが多い理由
- デフォルトが無効 なので、明示的に変更しない限りそのまま
- 有効化には VPC S3 Endpoint（Gateway型）の作成 + ルートテーブル設定 が必要で、ひと手間ある
- COPY/UNLOADのクロスリージョンS3アクセスで NAT Gateway経由になりコストが跳ねる 事故が懸念される
- 「動いている設定は触らない」という運用文化
有効化されやすいケース
- 金融・医療・公共系などコンプライアンス要件が厳しい業界
- VPCフローログでS3トラフィックを監査したい要件がある
- パブリックアクセス無効化 + プライベートサブネット配置 + 拡張VPCルーティング有効化を「3点セット」で構成する設計思想
- Lake FormationやGlue Catalogと組み合わせ、データ境界をVPC内に閉じたい
ガバナンス成熟度に比例して有効率が上がるイメージで、エンタープライズ寄りの案件ほど有効化される傾向にあります。
Q2: 拡張VPCルーティング有効だとRedshift Spectrumは使えない？
結論: 使えます。 ただし、いくつか注意点があります。
注意点1: 必要なVPC Endpoint
拡張VPCルーティング有効時、SpectrumはS3とGlue Data Catalogにアクセスするため、以下のVPC Endpoint設定が必要です。
| 必要なEndpoint | 用途 |
|---|---|
| S3 VPC Endpoint（Gateway型） | S3データへのアクセス（同一リージョン） |
Glue Interface Endpoint（com.amazonaws.<region>.glue） |
Data Catalog参照 |
| ルートテーブル設定 | サブネット → Endpointの経路 |
| Endpoint Policy / バケットポリシー | アクセス許可 |
注意点2: Spectrum外部フリートの通信は対象外
ここが意外と知られていない重要なポイントです。
公式ドキュメントによると、Spectrumのクエリ実行に使われる「外部フリート」（Redshiftが管理する別のノード群）からS3への通信は、拡張VPCルーティングの対象外 です。つまり、拡張VPCルーティングを有効にしても、Spectrum経由のS3アクセスがすべてVPC経由になるわけではありません。
「Spectrumの通信もVPCに閉じたい」と考えている方は、この点を踏まえて設計する必要があります。後述の Q3のRGインスタンス で、この事情が大きく変わります。
よくあるハマりポイント
- クロスリージョンのS3はSpectrumから読めない（拡張VPCルーティングの有無に関係なくSpectrum自体の制約）
- Glue Data Catalogが別アカウントの場合、Lake Formation権限 + VPC Endpoint Policyの両方を整える必要あり
- VPC Endpoint Policyがデフォルトの「Full Access」でない場合、Spectrum用のS3アクセスを明示的に許可しないとクエリが落ちる
Q3: 先週リリースされた RGインスタンスではどうなる？
2026年5月12日にリリースされた RGインスタンス （Redshift Graviton）は、拡張VPCルーティングの考え方に重要な変化をもたらしています。
RGの最大の特徴: 統合データレイクエンジン
| 項目 | RA3 + Spectrum | RG |
|---|---|---|
| S3クエリの実行場所 | Spectrum外部フリート（別ノード群） | クラスタノード上で直接実行 |
| スキャン課金 | $5/TB | なし |
| 拡張VPCルーティングの効果範囲 | クラスタ → S3のみ（外部フリート分は対象外） | すべてのS3アクセスがVPC経由 |
RGでは 統合データレイクエンジン（Integrated Data Lake Engine） がクラスタノードに内蔵されており、S3上のParquet/Icebergデータへのクエリを Spectrum外部フリートを介さずに直接実行 します。
拡張VPCルーティング × RGの意味
これにより、Q2で課題となっていた「Spectrum外部フリートのS3通信はVPCに閉じない」という制限がRGでは解消されます。
- データレイククエリも クラスタノード で実行されるため、拡張VPCルーティング有効化で S3アクセスもVPC経由で完結
- VPCフローログでIceberg/ParquetへのアクセスもVPC側で観測可能
- VPC Endpoint Policyでデータレイク経路も統一的に制御可能
セキュリティ・監査要件が厳しい組織にとっては「RG + 拡張VPCルーティング有効 + S3 VPC Endpoint（Gateway型）」という構成パターンが、よりクリーンな選択肢になります。
Provisioned vs Serverless vs RG
| 項目 | Provisioned (DC2/RA3) | RG（Provisioned） | Serverless |
|---|---|---|---|
| 拡張VPCルーティング | オプション（デフォルト無効） | オプション（デフォルト無効） | オプション（デフォルト無効） |
| データレイククエリ | Spectrum外部フリート | クラスタノード（統合エンジン） | Spectrum外部フリート |
| VPC Endpoint事前準備 | 有効化時のみ必要 | 有効化時のみ必要 | 有効化時に必要（VPC設計上、有効化が推奨されやすい） |
なお、Serverless でも拡張VPCルーティングは オプション であり、デフォルトは無効です。aws redshift-serverless update-workgroup --enhanced-vpc-routing で有効/無効を変更でき、Provisioned と違ってクラスター再起動を伴いません。
Q4: VPC FAQに「パブリックIPでもAWSプライベートネットワーク経由」とあるが、もう気にしなくていい？
これは2026年現在のAmazon VPC FAQに明記されている内容で、設計判断に影響を与える情報です。
「パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。」
このFAQの存在を根拠に「拡張VPCルーティングは無効でも問題ない」と判断するケースが増えています。
「気にしなくてよい」観点 ← FAQの通り
| 観点 | 結論 |
|---|---|
| 通信経路がインターネット経由か | NO、AWSバックボーン経由 |
| 物理レイヤーの暗号化 | AWS側で自動暗号化 |
| 一般的なMITM・盗聴リスク | 実質ない |
| データセンター間の越境 | AWSグローバルネットワーク内で完結 |
「S3への通信がIPルーティングとしてパブリックインターネットを通る可能性がある = 危険」という感覚的な懸念であれば、FAQの通り過度に心配する必要はありません。
「依然として気にすべき」観点 ← FAQでは解決しない
ただし、監査・統制・可視化 の観点では別問題として残ります。
| 観点 | 無効 | 有効 |
|---|---|---|
| VPCフローログ記録 | 残らない | 残る |
| VPC Endpoint Policyで制御 | 不可 | 可能 |
| Security Groupで制御 | 不可 | 可能 |
S3バケットポリシーで aws:SourceVpce 条件 |
使えない | 使える |
| 「データがVPC内に閉じている」ことの技術的証明 | 困難 | 容易 |
| PCI DSS / FISC / 政府系の「VPC内通信限定」要件 | 満たせない場合あり | 満たせる |
つまり、拡張VPCルーティングを有効化する意義は 「通信経路の安全性」ではなく「可視化・統制の設計」 にシフトしているという理解が、現代的な判断軸になります。
4つの疑問を経て見えてきたのは、拡張VPCルーティングは「セキュリティ上の必須機能」ではなく「ガバナンス設計の選択肢」だということ。それを踏まえて、後半では実践的な判断基準を整理していきます。
設計・運用のベストプラクティス
判断フローチャート
拡張VPCルーティングを有効化すべきかどうかは、以下のフローで判断するのが分かりやすいです。
よくあるハマりポイント
ハマり1: COPY/UNLOADがVPC Endpoint未設定で失敗
拡張VPCルーティング有効化時、S3 VPC Endpoint（Gateway型）がないとCOPY/UNLOADが失敗します。エラーメッセージはネットワーク接続系になります。
[Amazon](500310) Invalid operation: Failed to connect to S3 endpoint.
(Endpoint: s3.ap-northeast-1.amazonaws.com, Port: 443)
ハマり2: ネットワークエラーとIAM権限エラーの見分け方
エラーの種類で原因の切り分けが可能です。
| エラー文字列 | 原因 |
|---|---|
Connection timed out, Failed to connect to endpoint, Could not resolve host |
VPC Endpoint未設定 or ルートテーブル誤設定 |
Access Denied, Forbidden, S3ServiceException |
IAMロール権限不足 or Endpoint Policy制限 |
ハマり3: クロスリージョンS3でNAT Gatewayコスト爆発
拡張VPCルーティング有効時、別リージョンのS3バケットへCOPY/UNLOADする場合、Gateway Endpointが使えずNAT Gateway経由になります。データ転送量に応じて料金が膨らむため、事前に確認が必要です。
無効時はAWSバックボーン経由で安く済むため、クロスリージョンが多い場合は無効化のままが有利になるケースもあります。
ハマり4: VPC Endpoint Policyのデフォルト変更でSpectrumが利用できない
VPC Endpoint PolicyをデフォルトのFull Accessから変更した場合、Spectrumが内部的に使用するS3バケット（クエリ結果一時保存等）へのアクセスが拒否され、Spectrumクエリが利用できません。Endpoint Policyを絞る場合は、Spectrumで使われるバケット・プレフィックスを許可することを忘れずに。
ハマり5: Serverless移行時にVPC Endpoint準備を忘れる
Provisioned（拡張VPCルーティング無効）からServerless + 拡張VPCルーティング有効構成に移行する際、VPC Endpointの事前準備を忘れるとCOPY/UNLOADが即座に失敗します。Workgroup作成前にEndpoint設定を完了させておくのが安全です。
結論
「無効のままが多い」現状は変化する可能性が高い
これまで「デフォルト無効」「ひと手間がある」「FAQで通信経路は保護されている」という理由で無効のままの環境が多かったですが、以下の動向で構成バランスが変わる可能性があります。
- Redshift Serverlessの普及: VPC設計と一体化しやすく、有効化される構成が増加傾向
- RGインスタンスの登場: 統合データレイクエンジンにより、拡張VPCルーティング有効時のメリットが拡大
- コンプライアンス要件の厳格化: 各業界規制で「VPC内通信」要件が増加傾向
新規構築や移行のタイミングでは「とりあえず無効」ではなく「明示的に判断する」設計プロセスが推奨されます。
判断軸は「セキュリティ」ではなく「可視性・統制」
VPC FAQの記述が示すように、拡張VPCルーティングの有効/無効は 「通信経路の安全性」の問題ではなくなっています 。判断軸は以下のように整理できます。
- 可視性: VPCフローログでデータレイクアクセスを観測したいか？
- 統制: VPC Endpoint Policyで通信経路を制御したいか？
- 証明性: 監査で「データがVPC内に閉じている」ことを示せる必要があるか？
これらが「Yes」のいずれかであれば有効化、すべて「No」であれば無効のままでも実害はありません。
今後期待される機能拡張
現時点では、Provisionedでの拡張VPCルーティングの設定変更にはクラスター再起動が伴う場合があり、運用負荷の要因になっています。Serverlessでは update-workgroup で比較的容易に変更が可能ですが、Provisioned側でも「無停止での有効/無効切り替え」が将来的にサポートされると、より柔軟な運用が可能になります。
また、RGインスタンスのリリースから日が浅く、統合データレイクエンジン経由のS3アクセスに対するVPCフローログの記録粒度や、Endpoint Policyでの制御挙動については、今後の検証で明確化されることが期待されます。
最後に
Amazon Redshiftの拡張VPCルーティングについて、現場でよくある4つの疑問とベストプラクティスを整理しました。
- 現場の比率は「無効6:有効4」程度。デフォルト無効が多い
- Spectrumは有効でも使えるが、外部フリートの通信は対象外という制約がある
- RGインスタンスの統合データレイクエンジンは、この制約を解消する革新的な変化
- VPC FAQの記述により「セキュリティ目的での有効化」の意義は薄れたが、可視性・統制目的では依然有効
「とりあえず有効」「とりあえず無効」ではなく、自社のガバナンス要件と運用負荷のバランスを踏まえて明示的に判断することが、これからのRedshift運用には求められます。
特にRedshift Serverlessや新しいRGインスタンスへの移行を検討している方は、移行のタイミングで構成全体を見直し、VPC Endpoint整備とセットで設計し直す機会としていただくのがおすすめです。この記事がどなたかのお役に立てば幸いです。
