Microsoft PurviewでAWS S3やAmazon Redshiftをスキャンしたいとき、「プライベート接続で閉域のまま実現できるのか？」「AWS IRはどこにインストールするのか？」といった疑問を持つ方は多いはずです。本記事では公式ドキュメントの内容を整理しつつ、S3とRedshiftそれぞれの“できる／できない”を、実際の構成パターンとあわせて詳しく解説します。
Microsoft PurviewとAWS連携の前提整理
まずは、本記事のゴールと前提を整理します。話題にするのは次の3点です。
- AWS IRとは何者か？インストールや構築は必要なのか？
- Amazon S3を「VPC内・PrivateLink（VPCエンドポイント）経由」でスキャンできるのか？
- Amazon Redshiftをプライベート接続でスキャンするとき、どの統合ランタイム（IR）を選ぶべきか？
ここでいう「プライベート接続」とは、一般公開されていないエンドポイント（VPC内限定、あるいはPrivateLinkのみ）に閉じた構成を指します。
先に結論：S3とRedshiftのプライベート接続可否
細かい説明に入る前に、「何ができて、何ができないのか」をざっくり俯瞰しておきましょう。
| データソース | 接続形態 | 利用できるIR | プライベート接続の可否 | ポイント |
|---|---|---|---|---|
| Amazon S3 | パブリックエンドポイント | Azure IR / AWS IR | ○（インターネット経由の意味で“可”） | Purview側はパブリック到達前提でスキャン |
| Amazon S3 | VPCエンドポイントのみ（閉域） | – | × | Purviewのプライベートエンドポイント非対応。Managed VNet IR / SHIRも利用不可 |
| Amazon Redshift | パブリックエンドポイント | Azure IR / AWS IR | ○ | インターネット経由で到達できればIR追加不要 |
| Amazon Redshift | VPC内のみ（非公開） | Kubernetes対応Self-hosted IR | ○ | 自社VPC内にKubernetes SHIRをデプロイする構成が公式推奨 |
この表から分かる通り、
- S3は「Purview側のプライベート接続」は現時点で不可
- Redshiftを非公開のままスキャンしたい場合は、Kubernetes Self-hosted IR（Kubernetes SHIR）が必須
というのが実情です。
AWS IRとは何か？インストールは「不要」
最初に誤解を解いておきたいのが「AWS IRってどこにインストールするの？」という疑問です。
AWS IRの正体：PurviewがAWS上に自動用意する実行環境
Microsoft Purviewの統合ランタイム（Integration Runtime, IR）は、スキャン処理を実行するための計算リソースです。公式ドキュメントでは、次の種類が列挙されています。
- Azure Integration Runtime（Azure IR）
- Managed Virtual Network Integration Runtime（Managed VNet IR）
- Self-hosted Integration Runtime（Windows SHIR）
- Kubernetes supported Self-hosted Integration Runtime（Kubernetes SHIR）
- AWS Integration Runtime（AWS IR）
このうちAWS IRは、「Microsoft PurviewがAWS上にホストするフルマネージドの計算基盤」です。ユーザー自身がインストーラをダウンロードして構築するものではありません。
UIには出てこないが、裏側で自動的に使われる
Microsoft Q&Aでも明示されていますが、AWS IRはユーザーが直接選択する項目として表示されないことがほとんどです。
- PurviewポータルからS3やRedshiftなどのAWSデータソースを登録
- スキャン作成時に「AzureAutoResolveIntegrationRuntime（AutoResolve IR）」を選択
- 実際には、Microsoft側が必要に応じてAWS IRをAWS上に立ち上げ、そこでスキャン処理を実行
つまり、
- AWS IRをユーザーがインストールすることはできない
- 「AutoResolve（Azure IR）」と表示されていても、AWSソースの場合は裏でAWS IRが動いている
という理解が正しいです。
Amazon S3スキャン：プライベートエンドポイント非対応の現実
S3マルチクラウドコネクタのアーキテクチャ
S3スキャンには「Amazon S3 Multicloud Scanning Connector」が使われます。公式ドキュメントでは、次のような流れが説明されています。
- Purviewから見ると、Microsoft側のAWSアカウントにスキャナがデプロイされる
- そのスキャナ用に、AWSアカウント側でAssumeRole可能なIAMロールを作成
- スキャナがS3バケットの中身を読み取り、メタデータと分類結果のみをAzure側へ送信
ここで重要なのは、スキャナはMicrosoftが管理するAWSアカウント上で動作する点です。そのため、S3との通信パスは基本的に「AWSのパブリックエンドポイント（あるいは内部的なAWSバックボーン）」で完結します。
既知の制限：Purview Private EndpointはS3スキャン非対応
S3コネクタの既知の制限として、公式に次の記載があります。
- 「Microsoft Purview private endpoints aren’t supported when scanning Amazon S3.」
つまり、Purviewアカウントにプライベートエンドポイントを張り、そこから閉域でS3に接続する構成はサポートされていません。統合ランタイムのサポートマトリクスでも、S3の行にはAzure IR / AWS IRのみがチェックされており、Self-hosted IR / Kubernetes SHIR / Managed VNet IRは対象外です。
このことから、「自社VPC内だけで完結させるS3スキャン」は現行仕様では実現できないと判断できます。
それでもセキュアに使うための設計ポイント
「プライベートエンドポイントは諦めるとしても、できるだけ安全に使いたい」という場合に、押さえておきたいポイントを整理します。
| 観点 | 設計ポイント | 補足 |
|---|---|---|
| 認証・権限 | AssumeRole（External ID付き）のIAMロールのみを許可 | Purview側でロールARNとExternal IDを指定し、そのロール経由でのみバケットにアクセスさせる |
| アクセス範囲 | バケットポリシーで対象バケット／パスを限定 | 読み取りが必要なプレフィックスにだけアクセスを許可し、不要なパスは明示的に拒否 |
| ネットワーク | インターネット経由だがAWS内トラフィックとして完結 | スキャナもS3もAWS内にあるため、ユーザーデータがAzureに転送されるのはメタデータと分類結果のみ |
| 監査 | CloudTrail / S3アクセスログでスキャンアクセスを監査 | いつ・どのロールが・どのオブジェクトにアクセスしたかを追跡可能 |
S3を「Purviewから完全閉域で触りたい」という要求は、現状の仕様では満たせません。しかし、IAMロールとバケットポリシーによる強力なガバナンスを組み合わせることで、リスクを現実的なレベルまで抑えた運用は可能です。
Amazon Redshift：プライベート接続ならKubernetes SHIR一択
Redshiftスキャンのサポート状況
Amazon Redshiftのスキャンは、2025年3月時点でもプレビュー機能として提供されています。
- メタデータ抽出（テーブル・ビュー・ストアドプロシージャなど）に対応
- フルスキャン／スコープ指定スキャンに対応（インクリメンタルスキャンは未対応）
統合ランタイムとしては、次の3種類がサポートされています。
- Azure IR
- AWS IR（裏側で自動利用）
- Kubernetes supported Self-hosted IR（Kubernetes SHIR）
ここでポイントになるのが「データソースがパブリックに到達可能かどうか」です。
Redshiftがパブリック到達可能な場合
Redshiftのエンドポイントがインターネットから到達可能な場合は、基本的にAzure IR / AWS IRで事足ります。
- Redshiftのパブリックエンドポイントを指定
- ユーザー名／パスワードによる基本認証を設定
- PurviewポータルでAutoResolve IRを選択してスキャン
このケースでは、追加のインフラ構築は不要で、SaaS的な体験でRedshiftのメタデータを収集できます。
RedshiftがVPC内のみに閉じている場合
問題は、多くの本番環境で採用されている「RedshiftはVPC内サブネットにあり、パブリックアクセス不可」という構成です。
この場合、公式ドキュメントは明確に次のように案内しています。
- 「データソースが公開到達不可なら、最新のKubernetes supported Self-hosted IRをセットアップせよ」
つまり、Redshiftをプライベート接続でスキャンしたい場合は、Kubernetes SHIR一択と考えてよい状況です。
Kubernetes SHIRでRedshiftをプライベート接続する構成例
典型的な構成イメージを、手順ベースで整理します。
- AWS上のVPCにEKS（または自己管理Kubernetesクラスター）を構築
- Redshiftクラスターと同一またはピアリングされたVPC／サブネットに配置
- そのクラスター上にKubernetes supported SHIRをデプロイ
- セキュリティグループ／ルートテーブルを調整し、Kubernetes SHIRからRedshift（TCP 5439など）へ到達可能にする
- PurviewポータルでRedshiftデータソースを登録し、スキャン作成時に該当のKubernetes SHIRを選択
こうすることで、スキャン処理（クエリ実行）は自社VPC内で完結し、外に出ていくのはメタデータと分類結果のみという構成を取ることができます。
Kubernetes SHIR運用の注意点
Kubernetes SHIRは強力ですが、Managed VNet IRやAWS IRのような「完全フルマネージド」ではありません。主な注意点は次の通りです。
- バージョンアップは自動ではなく、運用側の作業が必要
- ノード数／リソース要求・制限（Requests / Limits）を考慮したスケール設計が必要
- Podやノードの障害対策として、監視（ログ・メトリック収集）が不可欠
- ネットワーク変更（SGやルーティングの変更）の影響を受けるため、インフラチームとの連携が必須
その代わり、「Redshiftへの到達経路を完全に自社管理できる」というメリットが得られます。金融・公共などインターネットに出したくないRedshiftを扱う場合には、実質的に必須の選択肢になります。
IR選択の判断フロー
ここまでの内容を、設計時に使える判断フローとしてまとめます。
| 質問 | はい | いいえ |
|---|---|---|
| S3をスキャンしたいか？ | Azure IR / AWS IRでスキャン。 Purview Private Endpointは諦め、IAMロールで権限を絞る。 | 次の質問へ |
| Redshiftをスキャンしたいか？ | 次の質問へ | IR選択はAzure IR中心でOK（他のデータソースに合わせて再検討） |
| Redshiftはインターネットから到達可能か？ | Azure IR / AWS IRを利用（AutoResolve IRでOK） | Kubernetes SHIRをVPC内にデプロイ |
| Purviewアカウントを閉域化（Firewall有効＋Private Endpoint）したいか？ | 可能な限りManaged VNet IRやSHIRで対応。 ただしS3はPrivate Endpoint非対応である点に注意。 | Azure IR / AWS IR中心のシンプル構成も検討 |
シナリオ別構成パターン
パターン1：S3だけをサクッとスキャンしたい
S3の中身をざっと分類／棚卸ししたいだけで、ネットワーク要件も厳しくない場合は、もっともシンプルな構成で済ませられます。
- Purview：Azure IR（AutoResolve）をそのまま利用
- S3：パブリックエンドポイントでアクセス可能な状態
- IAMロール：最小権限でAssumeRoleを許可
この場合は、Purview側で特別なIR設定を行う必要はありません。S3コネクタのドキュメントに従ってロールとクレデンシャルを準備すればスキャンが開始できます。
パターン2：S3＋Redshift（パブリック）をまとめてガバナンス
S3とRedshiftの両方がパブリックエンドポイントで到達可能な構成なら、Purview側はAzure IR / AWS IRのみで完結します。
- S3：S3マルチクラウドコネクタ＋IAMロール
- Redshift：ユーザー名／パスワード＋AutoResolve IR
- Purview：追加IRなし（デフォルトのAzure IRを利用）
運用負荷が最も低く、Purviewを純粋なSaaSとして利用できる構成です。その一方で、インターネット到達可能なエンドポイントを持つことになるため、組織のセキュリティポリシーと相談が必要です。
パターン3：S3は割り切り、Redshiftだけを完全閉域にする
「S3はそこまで機微じゃないのでパブリックで構わないが、RedshiftはどうしてもVPC内に閉じたい」というケースもよくあります。この場合の現実解は次の通りです。
- S3：パブリックエンドポイント＋Azure IR / AWS IRでスキャン（IAMロールで制御）
- Redshift：VPC内のみで公開、Kubernetes SHIRをVPC内に配置
- Purview：S3向けはAzure IR、Redshift向けはKubernetes SHIR、というハイブリッド構成
Purviewのネットワークベストプラクティスでも、シナリオに応じてAzure IR／Managed VNet IR／Self-hosted IRを組み合わせることが推奨されています。
よくある誤解とその整理
「AWS IRを自分のAWSアカウントに入れて、VPC内からS3をスキャンしたい」
残念ながら、これは現状の仕様では不可能です。
- AWS IRはあくまでMicrosoftのAWSアカウント上にホストされるフルマネージドIR
- ユーザーが自分のAWSアカウントにインストールしたり、ネットワークを細かく制御したりすることはできない
VPC内で完結させたい場合は、S3ではなくRedshiftのように、Self-hosted IRもしくはKubernetes SHIRをサポートするデータソースである必要があります。
「S3もKubernetes SHIRで接続できるのでは？」
統合ランタイムのサポートマトリクスを見ると、S3はAzure IR / AWS IRのみと明記されており、Self-hosted IRやKubernetes SHIRはサポートされていません。
そのため、「自社VPC内のKubernetesクラスターから直接S3をスキャンし、Purviewに結果だけ送る」という構成は、少なくとも公式サポート外です。サポート対象の構成でないと、将来の仕様変更に耐えられないため、避けるべきです。
「Managed VNet IRを使えばS3もPrivate Linkでいけるのでは？」
Managed VNet IRは、Azure上のデータソース（例：Azure StorageやSnowflakeなど）に対してPrivate Link経由で接続する用途に非常に便利な機能です。
しかし、現時点の公式ドキュメントでは「S3スキャンにManaged VNet IRは使えない」と整理されています。S3コネクタ側の既知の制限に「Purview private endpoints aren’t supported」と明示されているため、Managed VNet IRを絡めたPrivate Link構成は採れません。
Redshiftプライベートスキャン時の実務的なポイント
必要権限の整理
Redshiftスキャンでは、メタデータ取得のために複数のシステムビュー／テーブルへのSELECT権限や、特定のシステム関数へのEXECUTE権限が必要です。
- svv_table_info / svv_external_tables などのシステムビュー
- information_schema.routines / parameters
- pg_views / pg_database / pg_description など
- pg_get_late_binding_view_cols などのシステム関数
運用上は、スキャン専用ユーザーを1つ作成し、そのユーザーに対して必要最小限の権限だけをまとめて付与しておくのが安全です。
スキャン頻度とコスト設計
Redshiftスキャンはメタデータ中心とはいえ、対象テーブル数が多いとクエリ数もそれなりに増えます。Kubernetes SHIRでプライベートスキャンを行う場合は、次の観点でチューニングするとよいでしょう。
- 本番：1日1回または数時間おきなど、ビジネス要件に合わせたスケジュール
- 開発／検証環境：テーブル構造変更時に手動トリガーする運用
- Kubernetesクラスター側：スキャン時間帯だけPodのリソースを厚めにし、終了後に縮退させる
またプレビュー機能である以上、仕様変更や制限事項の追加が起こり得るため、定期的に公式ドキュメントをチェックしておくことも重要です。
まとめ：Purview×AWSの「現実的な落としどころ」
最後に、本記事のポイントを整理します。
- AWS IRは、Microsoft PurviewがAWS上に自動的に用意するフルマネージド実行環境であり、ユーザーがインストールするものではない
- Amazon S3のスキャンは、Purviewのプライベートエンドポイント非対応であり、Azure IR / AWS IRのみサポートされている
- S3を完全閉域にする構成は取れないが、IAMロール＋バケットポリシーで権限を最小化しつつ運用するのが現実解
- Amazon RedshiftをVPC内に閉じたままスキャンしたいなら、Kubernetes対応Self-hosted IR（Kubernetes SHIR）が事実上一択
- Redshiftスキャンはプレビュー機能のため、本番適用時は慎重な検証と、継続的なドキュメント確認が必要
「全部を完全閉域で」「PurviewもS3もRedshiftもPrivateLinkで」という理想は、現行のMicrosoft PurviewとAWSの組み合わせではまだ実現できません。その一方で、どこを割り切り、どこを閉じるかを慎重に設計すれば、実務で十分通用するセキュアなアーキテクチャを構成できます。
自社のセキュリティポリシーとクラウド戦略を踏まえつつ、
- S3は「権限ガバナンスで割り切る」
- Redshiftは「Kubernetes SHIRでプライベート接続を担保する」
という設計を出発点に、Microsoft Purviewによるマルチクラウドなデータガバナンス基盤を検討してみてください。
コメント