Azure SQL Managed Instance の接続アーキテクチャ

適用対象:Azure SQL Managed Instance

この記事では、Azure SQL Managed Instance の接続アーキテクチャと、コンポーネントからマネージド インスタンスに通信トラフィックがどのように転送されるかについて説明します。

概要

SQL Managed Instance のインスタンスは、マネージド インスタンス専用の Azure 仮想ネットワーク内とサブネット内に配置されます。 このデプロイでは、以下が提供されます。

  • セキュリティで保護された仮想ネットワークローカル (VNet ローカル) IP アドレス。
  • オンプレミス ネットワークを SQL Managed Instance に接続する機能。
  • SQL Managed Instance をリンク サーバーまたは別のオンプレミス データ ストアに接続する機能。
  • SQL Managed Instance を Azure リソースに接続する機能。

注意

2022 年 11 月の機能ウェーブでは、SQL Managed Instance の既定の接続構造が変更されました。 この記事では、現在のアーキテクチャと、機能ウェーブにまだ登録されていないインスタンスのアーキテクチャに関する情報を提供します。 詳細については、2022 年 11 月の機能ウェーブに関する記事を参照してください。

2022 年 11 月の機能ウェーブ

2022 年 11 月の機能ウェーブでは、SQL Managed Instance の接続アーキテクチャに次の変更が導入されました。

  • 管理エンドポイントを削除しました。
  • 必須のネットワーク セキュリティ グループ規則を簡略化しました (必須の規則を 1 つ削除)。
  • ポート 443 での AzureCloud への送信を含まないように、必須のネットワーク セキュリティ グループ規則を変更しました。
  • ルート テーブルを簡略化しました (必須ルートを 13 から 5 に削減)。

接続アーキテクチャの概要

SQL Managed Instance は、仮想クラスターと類似の構成属性でグループ化され参加している分離された一連の専用仮想マシン上でホストされるサービス コンポーネントで構成されています。 サービス コンポーネントには、お客様の仮想ネットワーク サブネット内にデプロイされるものもあれば、Microsoft が管理するセキュリティで保護されたネットワーク環境で動作するものもあります。

Diagram that shows the high-level connectivity architecture for Azure SQL Managed Instance after November 2022.

お客様のアプリケーションは、SQL Managed Instance に接続できます。また、クエリを実行して、仮想ネットワーク、ピアリングされた仮想ネットワーク、または VPN か Azure ExpressRoute によって接続されたネットワーク内のデータベースを更新できます。

次の図は、SQL Managed Instance に接続するエンティティを示しています。 マネージド インスタンスと通信するために必要なリソースも示されています。 図の一番下にある通信プロセスは、SQL Managed Instance にデータ ソースとして接続するお客様のアプリケーションとツールを表しています。

Diagram that shows entities in the connectivity architecture for Azure SQL Managed Instance after November 2022.

SQL Managed Instance は、データ プレーンとコントロール プレーンという 2 つのプレーンで動作する、シングルテナントのサービスとしてのプラットフォーム オファリングです。

"データ プレーン" は、互換性、接続、ネットワーク分離のため、お客様のサブネット内にデプロイされます。 データ プレーンは、Azure Storage、認証のためのMicrosoft Entra ID (旧称 Azure Active Directory)、テレメトリ収集サービスなどの Azure サービスに依存します。 SQL Managed Instance を含むサブネットからそれらのサービスに向かって送信されるトラフィックが表示されます。

"コントロール プレーン" には、自動化されたエージェントを介したデプロイ、管理、コア サービス メンテナンスの機能が用意されています。 これらのエージェントは、サービスを運用するコンピューティング リソースに排他的にアクセスできます。 ssh またはリモート デスクトップ プロトコルを使ってこれらのホストにアクセスすることはできません。 コントロール プレーンの通信はすべて暗号化され、証明書を使って署名されます。 通信相手の信頼性を確認するために、SQL Managed Instance では、証明書失効一覧を使ってこれらの証明書が確認されます。

通信の概要

アプリケーションは、3 種類のエンドポイントを経由して SQL Managed Instance に接続できます。 これらのエンドポイントは対応するシナリオが異なり、ネットワーク特性や動作も異なります。

Diagram that shows the scope of visibility for VNet-local, public, and private endpoints to an Azure SQL Managed Instance.

VNet ローカル エンドポイント

VNet ローカル エンドポイントは、SQL Managed Instance に接続するための既定の手段です。 VNet ローカル エンドポイントは、サブネットのアドレス プールにある (したがって VNet ローカルの) IP アドレスまたは仮想ネットワークにローカルなエンドポイントに解決される、<mi_name>.<dns_zone>.database.windows.net という形式のドメイン名です。 VNet ローカル エンドポイントを使用して、すべての標準接続シナリオで SQL マネージド インスタンスを接続できます。

VNet ローカル エンドポイントはリダイレクト接続の種類をサポートしています。

VNet ローカル エンドポイントに接続する場合、基となる IP アドレスが変わることがあるため、常にそのドメイン名を使います。

パブリック エンドポイント

パブリック エンドポイントは、インターネットから到達可能なパブリック IP アドレスに解決される、<mi_name>.public.<dns_zone>.database.windows.net という形式の省略可能なドメイン名です。 パブリック エンドポイントの場合、ポート 3342 上の TDS トラフィックのみが SQL Managed Instance に到達できます。統合シナリオ (フェールオーバー グループ、Managed Instance リンク、他の同様のテクノロジなど) には使用できません。

パブリック エンドポイントに接続する場合、基となる IP アドレスが変わることがあるため、常にそのドメイン名を使います。

パブリック エンドポイントは常にプロキシ接続の種類で動作します。

パブリック エンドポイントの設定方法については、「Azure SQL Managed Instance のパブリック エンドポイントを構成する」を参照してください。

プライベート エンドポイント

プライベート エンドポイントは、現在 Azure SQL Managed Instance へのトラフィックを実施する別の Virtual Network 内にあるオプションの固定 IP アドレスです。 1 つの Azure SQL Managed Instance は、複数の仮想ネットワークに複数のプライベート エンドポイントを持つことができます。 プライベート エンドポイントの場合、ポート 1433 上の TDS トラフィックのみが SQL Managed Instance に到達できます。統合シナリオ (フェールオーバー グループ、Managed Instance リンク、他の同様のテクノロジなど) には使用できません。

プライベート エンドポイントに接続する場合、IP アドレス経由で Azure SQL Managed Instance に接続することはサポートされていないため、常にドメイン名を使用します。

プライベート エンドポイントは、常にプロキシ接続の種類で動作します。

プライベート エンドポイントの詳細と構成方法については、「Azure Private Link for Azure SQL Managed Instance」で説明します。

仮想クラスターの接続アーキテクチャ

このセクションでは、SQL Managed Instance の仮想クラスター接続アーキテクチャについて詳しく説明します。 次の図は、仮想クラスターの概念上のレイアウトを示しています。

VNet ローカル エンドポイントのドメイン名は、内部ロード バランサーのプライベート IP アドレスに解決されます。 このドメイン名はパブリック ドメイン ネーム システム (DNS) ゾーンに登録されており、パブリックに解決できますが、その IP アドレスはサブネットのアドレス範囲に属し、既定ではその仮想ネットワークの内部からのみ到達できます。

ロード バランサーは、SQL Managed Instance のゲートウェイにトラフィックを送信します。 同じクラスター内で複数のマネージド インスタンスを実行できるため、ゲートウェイは、接続文字列の内容どおりに、SQL Managed Instance のホスト名を使って、トラフィックを適切な SQL Engine サービスにリダイレクトします。

クラスターを作成すると、zone-id の値が自動的に生成されます。 新しく作成されたクラスターで 2 番目のマネージド インスタンスがホストされる場合は、プライマリ クラスターとゾーン ID が共有されます。

サービス支援サブネット構成

サービスのセキュリティ、管理容易性、可用性を向上させるために、SQL Managed Instance では、Azure 仮想ネットワーク インフラストラクチャの一部の要素に対してネットワーク インテント ポリシーを適用します。 このポリシーによってサブネット、関連付けられたネットワーク セキュリティ グループとルート テーブルを構成することで、SQL Managed Instance の最小要件が満たされていることを確認します。 このプラットフォーム メカニズムは、ネットワーク要件をユーザーに透過的に伝達します。 このポリシーの主要な目的は、ネットワークの誤った構成を防ぎ、SQL Managed Instance の通常の動作とサービス レベル アグリーメントのコミットメントを確保することです。 マネージド インスタンスを削除すると、ネットワーク インテント ポリシーも削除されます。

サービス支援サブネット構成は、仮想ネットワーク サブネット委任機能の上に構築されます。これにより、自動ネットワーク構成管理を実現し、サービス エンドポイントを有効にすることができます。

サービス エンドポイントを使用することで、バックアップおよび監査ログを保持するストレージ アカウントの仮想ネットワーク ファイアウォール規則を構成することができます。 サービス エンドポイントが有効になっている場合でも、お客様には、ストレージ アカウントにアクセスするために Azure Private Link を使用することをお勧めします。 Private Link はサービス エンドポイントよりも高度な分離を実現できます。

重要

コントロール プレーン構成の特性に起因し、サービス支援サブネット構成では、国内のクラウドでサービス エンドポイントが有効になりません。

ネットワークの要件

SQL Managed Instance がデプロイされるサブネットは、次の特性を持っている必要があります。

  • 専用サブネット: SQL Managed Instance に使われるサブネットは、SQL Managed Instance サービスのみに委任できます。 このサブネットはゲートウェイ サブネットにすることはできません。このサブネットには SQL Managed Instance リソースのみをデプロイできます。
  • サブネットの委任: SQL Managed Instance のサブネットは Microsoft.Sql/managedInstances リソース プロバイダーに委任する必要があります。
  • ネットワーク セキュリティ グループ: ネットワーク セキュリティ グループは SQL Managed Instance サブネットに関連付けする必要があります。 SQL Managed Instance がリダイレクト接続用に構成されている場合は、ネットワーク セキュリティ グループを使ってポート 1433 およびポート 11000 から 11999 上のトラフィックをフィルター処理することで、SQL Managed Instance のデータ エンドポイントへのアクセスを制御できます。 管理トラフィックのフローが中断されないように、サービスにより、必要に応じて規則が自動的にプロビジョニングされ、最新の状態が保たれます。
  • ルート テーブル: ルート テーブルは SQL Managed Instance サブネットに関連付けられている必要があります。 このルート テーブルにエントリを追加できます。たとえば、仮想ネットワーク ゲートウェイ経由でトラフィックをオンプレミスにルーティングしたり、ファイアウォールなどの仮想ネットワーク アプライアンスを介して送信する既定の 0.0.0.0/0 ルートを追加したりできます。 Azure SQL Managed Instance は、ルート テーブル内の必要なエントリを自動的にプロビジョニングおよび管理します。
  • 十分な IP アドレス: SQL Managed Instance サブネットには、少なくとも 32 個の IP アドレスが必要です。 詳細については、SQL Managed Instance 用のサブネットのサイズの決定に関する記事を参照してください。 SQL Managed Instance のネットワーク要件を満たすように既存のネットワークを構成した後、そのネットワークにマネージド インスタンスをデプロイできます。 それ以外の場合は、新しいネットワークとサブネットを作成します。
  • Azure のポリシーで許可する:Azure Policy を使って SQL Managed Instance サブネットまたは仮想ネットワークを含むスコープ内のリソースの作成または変更を防ぐ場合、そのようなポリシーで SQL Managed Instance による内部リソースの管理を妨げてはなりません。 正常な動作のために、次のリソースをポリシーの拒否効果から除外する必要があります。
    • リソース名が \_e41f87a2\_ で始まる場合、種類 Microsoft.Network/serviceEndpointPolicies のリソース
    • 種類 Microsoft.Network/networkIntentPolicies のすべてのリソース
    • 種類 Microsoft.Network/virtualNetworks/subnets/contextualServiceEndpointPolicies のすべてのリソース
  • 仮想ネットワーク上のロック: 専用サブネットの仮想ネットワーク、その親リソース グループ、またはサブスクリプションに対するロックによって、SQL Managed Instance の管理とメンテナンスの操作が妨げられる可能性があります。 リソースのロックを使う場合は、特に注意してください。
  • レプリケーション トラフィック: 2 つのマネージド インスタンス間の自動フェールオーバー グループのレプリケーション トラフィックは、ハブ ネットワーク経由でルーティングするのではなく、直接やり取りするようにします。
  • カスタム DNS サーバー: 仮想ネットワークがカスタム DNS サーバーを使うように構成されている場合、その DNS サーバーはパブリック DNS レコードを解決できる必要があります。 Microsoft Entra 認証などの機能を使うには、さらに完全修飾ドメイン名 (FQDN) 解決が必要になる可能性があります。 詳細については、Azure SQL Managed Instance でのプライベート DNS 名の解決に関する記事をご覧ください。

サービス支援サブネット構成を使用した必須のセキュリティ規則

受信管理トラフィックのフローを確保するには、次の表に記載されている規則が必要です。 これらの規則はネットワーク インテント ポリシーによって適用されるので、お客様が展開する必要はありません。 接続アーキテクチャと管理トラフィックの詳細については、「接続アーキテクチャの概要」を参照してください。

名前 [ポート] プロトコル ソース Destination (公開先) アクション
healthprobe-in Any Any AzureLoadBalancer subnet Allow
internal-in Any Any subnet subnet Allow

送信管理トラフィックのフローを確保するには、次の表に記載されている規則が必要です。 接続アーキテクチャと管理トラフィックの詳細については、「接続アーキテクチャの概要」を参照してください。

名前 [ポート] プロトコル ソース Destination (公開先) アクション
AAD-out 443 TCP subnet AzureActiveDirectory Allow
OneDsCollector-out 443 TCP subnet OneDsCollector Allow
internal-out Any Any subnet subnet Allow
StorageP-out 443 Any subnet Storage.primaryRegion Allow
StorageS-out 443 Any subnet Storage.secondaryRegion Allow

サービス支援サブネット構成を使用した必須ルート

管理トラフィックが宛先に直接ルーティングされるようにするには、次の表に記載されているルートが必要です。 これらのルートはネットワーク インテント ポリシーによって適用されるので、お客様が展開する必要はありません。 接続アーキテクチャと管理トラフィックの詳細については、「接続アーキテクチャの概要」を参照してください。

名前 アドレス プレフィックス 次のホップ
AzureActiveDirectory AzureActiveDirectory インターネット*
OneDsCollector OneDsCollector インターネット*
Storage.primaryRegion Storage.primaryRegion インターネット*
Storage.secondaryRegion Storage.secondaryRegion インターネット*
subnet-to-vnetlocal subnet 仮想ネットワーク

Note

* "ネクスト ホップ" 列の値が "インターネット" である場合、トラフィックを仮想ネットワークの外部にルーティングすることがゲートウェイに指示されます。 ただし、宛先アドレスが Azure サービスである場合、トラフィックは Azure クラウドの外部ではなく Azure ネットワークを介してサービスに直接ルーティングされます。 仮想ネットワークが存在する Azure リージョン、または Azure サービスのインタンスがデプロイされている Azure リージョンに関係なく、Azure サービス間のトラフィックはインターネットを経由しません。 詳細については、Azure 仮想ネットワーク トラフィックのルーティングに関する記事を参照してください。

また、オンプレミスのプライベート IP 範囲が宛先として含まれるトラフィックを、仮想ネットワーク ゲートウェイまたは仮想ネットワーク アプライアンス経由でルーティングするルート テーブルにエントリを追加することもできます。

ネットワークの制約

送信接続には TLS 1.2 が適用されます: 2020 年 1 月以降、Microsoft はすべての Azure サービスのサービス内トラフィックに TLS 1.2 を適用しています。 その結果、SQL Managed Instance については、SQL Server へのレプリケーションとリンク サーバー接続に使われる送信接続に対して、TLS 1.2 が適用されることになりました。 SQL Managed Instance で 2016 より前のバージョンの SQL Server を使っている場合は、必ず TLS 1.2 固有の更新プログラムを適用してください。

現在、SQL Managed Instance では、次の仮想ネットワーク機能は "サポートされていません"。

  • ポート 25 の外部 SMTP リレーへのデータベース メール: ポート 25 を介した外部電子メール サービスへのデータベース メールの送信は、Microsoft Azure の特定のサブスクリプションの種類でのみ使用できます。 他のサブスクリプションの種類のインスタンスは、外部 SMTP リレーに接続するために別のポート (587 など) を使用する必要があります。 そうしないと、インスタンスがデータベース メールの配信に失敗する可能性があります。 詳細については、Azure でのアウトバウンド SMTP 接続問題のトラブルシューティングに関するページを参照してください。
  • Microsoft ピアリング: SQL Managed Instance が存在する仮想ネットワークと直接または推移的にピアリングされた ExpressRoute 回線で Microsoft ピアリングを有効にすると、仮想ネットワーク内の SQL Managed Instance コンポーネント間のトラフィック フローと、それに依存するサービスに影響が及びます。 結果として可用性の問題が生じます。 Microsoft ピアリングが既に有効になっている仮想ネットワークへの SQL Managed Instance デプロイは、失敗することが予想されます。
  • 仮想ネットワーク ピアリング – グローバル: Azure リージョン間での仮想ネットワーク ピアリング接続は、2020 年 9 月 9 日より前に作成されてサブネットに配置された SQL Managed Instance のインスタンスでは機能しません。
  • 仮想ネットワーク ピアリング – 構成: SQL Managed Instance を含むサブネットを含む仮想ネットワーク間で仮想ネットワーク ピアリングを確立する場合、このようなサブネットでは、異なるルート テーブルとネットワーク セキュリティ グループ (NSG) を使用する必要があります。 仮想ネットワーク ピアリングに参加している 2 つ以上のサブネットでルート テーブルと NSG を再利用すると、それらのルート テーブルまたは NSG を使用するすべてのサブネットで接続の問題が発生し、SQL Managed Instance の管理操作が失敗します。
  • AzurePlatformDNS:AzurePlatformDNS サービス タグを使用してプラットフォーム DNS 解決をブロックすると、SQL Managed Instance をレンダリングできなくなります。 SQL Managed Instance では、エンジン内部の DNS 解決にお客様による定義の DNS がサポートされていますが、プラットフォームの操作については、プラットフォーム DNS への依存性があります。
  • NAT ゲートウェイ: Azure Virtual Network NAT を使って、特定のパブリック IP アドレスでの送信接続を制御すると、SQL Managed Instance をレンダリングできなくなります。 現時点では、SQL Managed Instance サービスは基本的なロード バランサーの使用に制限されており、Azure Virtual Network NAT を使った受信フローと送信フローを同時に実行することができません。
  • Azure Virtual Network の IPv6:SQL Managed Instance はデュアル スタックの IPv4 または IPv6 仮想ネットワークにデプロイできないことが予想されています。 ネットワーク セキュリティ グループまたはルート テーブルを、SQL Managed Instance サブネットへの IPv6 アドレス プレフィックスを含むユーザー定義ルート (UDR) に関連付けると、SQL Managed Instance は利用不可と表示されます。 また、Managed Instance サブネットに関連付けられているネットワーク セキュリティ グループまたは UDR に IPv6 アドレス プレフィックスを追加すると、SQL Managed Instance は利用不可と表示されます。 既に IPv6 プレフィックスが与えられているネットワーク セキュリティ グループと UDR を含むサブネットに SQL Managed Instance はデプロイできないことが想定されます。
  • Microsoft サービス用に予約された名前を使う Azure DNS プライベート ゾーン: windows.netdatabase.windows.netcore.windows.netblob.core.windows.nettable.core.windows.netmanagement.core.windows.netmonitoring.core.windows.netqueue.core.windows.netgraph.windows.netlogin.microsoftonline.comlogin.windows.netservicebus.windows.netvault.azure.net のドメイン名は予約名です。 Microsoft サービス用に予約された名前を使う Azure DNS プライベート ゾーンが関連付けられている仮想ネットワークに SQL Managed Instance をデプロイすると、失敗します。 予約された名前を使う Azure DNS プライベート ゾーンとマネージド インスタンスを含む仮想ネットワークを関連付けると、SQL Managed Instance は利用不可と表示されます。 Private Link の構成の詳細については、「Azure プライベート エンドポイントの DNS 構成」を参照してください。

次のステップ