Premium Azure Cache for Redis インスタンスに対する仮想ネットワーク (VNet) サポートの構成

  • [アーティクル]

Azure Virtual Network のデプロイにより、セキュリティと分離が強化されると共に、サブネット、アクセス制御ポリシーや、アクセスをさらに制限する他の機能も提供されます。 Azure Cache for Redis インスタンスが仮想ネットワークで構成された場合、パブリックにアドレスを指定することはできません。 代わりに、インスタンスには仮想ネットワーク内の仮想マシンとアプリケーションからのみアクセスできます。 この記事では、Premium レベルの Azure Cache for Redis インスタンスに対する仮想ネットワークのサポートを構成する方法について説明します。

Note

クラシック デプロイ モデルは、2024 年 8 月に廃止されます。 詳細については、「Cloud Services (クラシック) のデプロイ モデルが 2024 年 8 月 31 日に廃止される」を参照してください。

重要

Azure Cache for Redis では、ネットワーク アーキテクチャが簡素化され、Azure 内のエンドポイント間の接続がセキュリティで保護される Azure Private Link の使用を推奨しています。 仮想ネットワーク内のサブネットでプライベート IP アドレスが割り当てられているプライベート エンドポイント経由で、仮想ネットワークから Azure Cache インスタンスに接続できます。 Azure Private Link はすべてのレベルで提供されており、Azure Policy のサポートと、簡略化された NSG ルール管理が含まれます。 詳細については、Private Link に関するドキュメントのページを参照してください。 VNet インジェクションされたキャッシュから Private Link に移行する方法については、「VNet インジェクション キャッシュから Private Link キャッシュに移行する」を参照してください。

VNet インジェクションの制限事項

  • 多くの場合、仮想ネットワーク構成を作成して維持すると、エラーが発生しやすくなります。 トラブルシューティングも困難です。 仮想ネットワークの構成が正しくないと、次の問題が発生する可能性があります:
    • キャッシュ インスタンスからの妨害されたメトリックの送信
    • レプリカ ノードがプライマリ ノードからデータをレプリケートできない
    • データ損失の可能性
    • スケーリングなどの管理操作の失敗
    • 最も深刻なシナリオでは、可用性の損失
  • VNet に挿入されたキャッシュは、Premium レベルの Azure Cache for Redis でのみ使用でき、他の層では使用できません。
  • VNet インジェクションされたキャッシュを使用する場合は、VNet を変更して、CRL や PKI、AKV、Azure Storage、Azure Monitor などの依存関係をキャッシュする必要があります。
  • 既存の Azure Cache for Redis インスタンスを Virtual Network に挿入することはできません。 キャッシュを 作成 するときは、このオプションを選択する必要があります。

仮想ネットワーク サポートの設定

Virtual Network (VNet) のサポートは、キャッシュの作成中に [New Azure Cache for Redis](新しい Azure Cache for Redis) ペインで構成します。

  1. Premium レベルのキャッシュを作成するには、Azure portal にサインインし、 [リソースの作成] を選択します。 これらは Resource Manager テンプレート、PowerShell、または Azure CLI を使用して作成することもできます。 Azure Cache for Redis インスタンスを作成する方法の詳細については、「キャッシュの作成」を参照してください。

    Screenshot that shows Create a resource.

  2. [新規] ページで、 [データベース] を選択します。 次に [Azure Cache for Redis] を選択します。

    Screenshot that shows selecting Azure Cache for Redis.

  3. [新規 Redis Cache] ページで、新しい Premium レベルのキャッシュの設定を構成します。

    設定 提案された値 説明
    DNS 名 グローバルに一意の名前を入力します。 キャッシュ名は 1 から 63 文字の文字列で、数字、英字、ハイフンのみを使用する必要があります。 名前の先頭と末尾には数字または文字を使用する必要があり、連続するハイフンを含めることはできません。 キャッシュ インスタンスのホスト名は \<DNS name>.redis.cache.windows.net です。
    サブスクリプション ドロップダウン リストからサブスクリプションを選択します。 この新しい Azure Cache for Redis インスタンスが作成されるサブスクリプション。
    リソース グループ ドロップダウン リストからリソース グループを選択するか、 [新規作成] を選択して新しいリソース グループの名前を入力します。 その中にキャッシュやその他のリソースを作成するリソース グループの名前。 すべてのアプリ リソースを 1 つのリソース グループに配置することで、それらをまとめて簡単に管理または削除できます。
    場所 ドロップダウン リストから場所を選択します。 キャッシュを使用する他のサービスの近くのリージョンを選択します。
    キャッシュの種類 Premium レベルの機能を構成するには、ドロップダウン リストから Premium レベルのキャッシュを選択します。 詳細については、Azure Cache for Redis の価格に関するページを参照してください。 価格レベルによって、キャッシュに使用できるのサイズ、パフォーマンス、および機能が決まります。 詳細については、Azure Cache for Redis の概要に関するページを参照してください。

  4. [ネットワーク] タブを選択するか、ページの下部にある [ネットワーク] ボタンを選択します。

  5. [ネットワーク] タブで、接続方法として [仮想ネットワーク] を選択します。 新しい仮想ネットワークを使用するには、まず Azure portal を使用した仮想ネットワークの作成に関するページまたは「Azure portal を使用した仮想ネットワーク (クラシック) の作成」の手順に従ってそれを作成します。 次に、 [New Azure Cache for Redis](新しい Azure Cache for Redis) ペインに戻り、Premium レベルのキャッシュを作成して構成します。

    重要

    Azure Cache for Redis を Resource Manager 仮想ネットワークにデプロイする場合、キャッシュは、Azure Cache for Redis インスタンス以外のリソースを含まない専用サブネット内に存在する必要があります。 Azure Cache for Redis インスタンスを、他のリソースを含む、または NAT Gateway が割り当てられた Resource Manager 仮想ネットワークのサブネットにデプロイしようとすると、そのデプロイは失敗します。 この失敗は、NAT Gateway と互換性のない基本ロード バランサーが Azure Cache for Redis で使用されているためです。

    設定 提案された値 説明
    Virtual Network ドロップダウン リストから仮想ネットワークを選択します。 ご自分のキャッシュと同じサブスクリプションと場所に存在する仮想ネットワークを選択します。
    サブネット ドロップダウン リストからサブネットを選択します。 サブネットのアドレスの範囲は CIDR 表記である必要があります (例: 192.168.1.0/24)。 仮想ネットワークのアドレス空間に含まれている必要があります。
    静的 IP アドレス (省略可能) 静的 IP アドレスを入力します。 静的 IP アドレスを指定しなかった場合は、IP アドレスが自動的に選択されます。

    重要

    Azure は、各サブネット内で一部の IP アドレスを予約し、これらのアドレスを使用することはできません。 サブネットの最初と最後の IP アドレスは、Azure サービスで使用される 3 つ以上のアドレスと共に、プロトコル準拠に予約されます。 詳細については、「これらのサブネット内の IP アドレスの使用に関する制限はありますか」をご覧ください。

    Azure 仮想ネットワーク インフラストラクチャによって使用される IP アドレスに加えて、サブネットの各 Azure Cache for Redis インスタンスは、シャードごとに 2 つの IP アドレスと、ロード バランサー用に 1 つの追加 IP アドレスを使用します。 クラスター化されていないキャッシュは、1 つのシャードを持つと見なされます。

  6. ページの下部にある [次へ: 詳細] タブを選択するか、ページの下部にある [次へ: 詳細] ボタンを選択します。

  7. Premium レベルのキャッシュ インスタンスの [詳細] タブで、非 TLS ポート、クラスタリング、およびデータ永続化の設定を構成します。

  8. ページの下部にある [次へ: タグ] タブを選択するか、ページの下部にある [次へ: タグ] ボタンを選択します。

  9. 必要に応じて、 [タグ] タブで、リソースを分類する場合は名前と値を入力します。

  10. [Review + create](レビュー + 作成) を選択します。 [確認および作成] タブが表示され、Azure によって構成が検証されます。

  11. 緑色の検証に成功のメッセージが表示された後、 [作成] を選択します。

キャッシュが作成されるまで、しばらく時間がかかります。 Azure Cache for Redis の [概要] ページで進行状況を監視できます。 [状態] に "実行中" と表示されている場合は、キャッシュを使用する準備ができています。 キャッシュが作成されたら、 [リソース] メニューの [仮想ネットワーク] を選択することで、仮想ネットワークの構成を表示できます。

Virtual network

Azure Cache for Redis 仮想ネットワークに関する FAQ

次の一覧は、Azure Redis Cache ネットワークに関してよく寄せられる質問への回答です。

Azure Cache for Redis と仮想ネットワークの誤った構成に関してよく見られる問題を教えてください

Azure Cache for Redis が仮想ネットワークでホストされている場合は、以下の表に含まれるポートが使用されます。

重要

以下の表に含まれるポートがブロックされている場合、キャッシュが正常に動作しない可能性があります。 仮想ネットワークで Azure Cache for Redis を使用する場合の構成の誤りに関する最も一般的な問題は、これらのポートのうち 1 つ以上がブロックされていることです。

送信ポートの要件

送信ポートには 9 個の要件があります。 これらの範囲内の送信要求は、a) キャッシュが機能するために必要な他のサービスに送信されるか、または b) ノード間通信のために Redis サブネットの内部に送信されます。 geo レプリケーションの場合は、プライマリ キャッシュとレプリカ キャッシュのサブネット間の通信のためのその他の送信要件が存在します。

Port Direction トランスポート プロトコル 目的 ローカル IP リモート IP
80、443 送信 TCP Azure Storage/PKI (インターネット) に対する Redis の依存関係 (Redis サブネット) * 4
443 送信 TCP Azure Key Vault と Azure Monitor に対する Redis の依存関係 (Redis サブネット) AzureKeyVault、AzureMonitor 1
53 送信 TCP/UDP DNS (インターネット/仮想ネットワーク) に対する Redis の依存関係 (Redis サブネット) 168.63.129.16 および 169.254.169.254 2 およびサブネットのカスタム DNS サーバー 3
8443 送信 TCP Redis の内部通信 (Redis サブネット) (Redis サブネット)
10221-10231 送信 TCP Redis の内部通信 (Redis サブネット) (Redis サブネット)
20226 送信 TCP Redis の内部通信 (Redis サブネット) (Redis サブネット)
13000-13999 送信 TCP Redis の内部通信 (Redis サブネット) (Redis サブネット)
15000-15999 送信 TCP Redis および geo レプリケーションの内部通信 (Redis サブネット) (Redis サブネット) (geo レプリカ ピア サブネット)
6379-6380 送信 TCP Redis の内部通信 (Redis サブネット) (Redis サブネット)

1 Resource Manager ネットワーク セキュリティ グループ (NSG) でサービス タグ AzureKeyVault と AzureMonitor を使用できます。

2 Microsoft が所有するこれらの IP アドレスは、Azure DNS を提供するホスト VM をアドレス指定するために使用されます。

3 この情報は、カスタム DNS サーバーのないサブネット、またはカスタム DNS を無視する新しい Redis キャッシュには必要ありません。

4 詳細については、「仮想ネットワーク接続に関するその他の要件」を参照してください。

geo レプリケーション ピア ポートの要件

Azure 仮想ネットワーク内のキャッシュ間で geo レプリケーションを使用している場合は、a) 受信 "および" 送信方向の両方でサブネット全体に対して、および b) 両方のキャッシュに対して、ポート 15000-15999 のブロックを解除します。 この構成を使用すると、将来 geo フェールオーバーが発生しても、サブネット内のすべてのレプリカ コンポーネントが相互に直接通信できます。

受信ポートの要件

受信ポートの範囲には、8 個の要件があります。 これらの範囲の受信要求は、同じ仮想ネットワークでホストされている他のサービスからの受信のものです。 または、Redis サブネット通信の内部のものです。

Port Direction トランスポート プロトコル 目的 ローカル IP リモート IP
6379, 6380 受信 TCP Redis へのクライアント通信、Azure 負荷分散 (Redis サブネット) (Redis サブネット)、(クライアント サブネット)、AzureLoadBalancer 1
8443 受信 TCP Redis の内部通信 (Redis サブネット) (Redis サブネット)
8500 受信 TCP/UDP Azure 負荷分散 (Redis サブネット) AzureLoadBalancer
10221-10231 受信 TCP Redis クラスターへのクライアント通信、Redis の内部通信 (Redis サブネット) (Redis サブネット)、(クライアント サブネット)、AzureLoadBalancer
13000-13999 受信 TCP Redis クラスターへのクライアント通信、Azure 負荷分散 (Redis サブネット) (Redis サブネット)、(クライアント サブネット)、AzureLoadBalancer
15000-15999 受信 TCP Redis クラスター、Azure 負荷分散、geo レプリケーションへのクライアント通信 (Redis サブネット) (Redis サブネット)、(クライアント サブネット)、AzureLoadBalancer、(geo レプリカ ピア サブネット)
16001 受信 TCP/UDP Azure 負荷分散 (Redis サブネット) AzureLoadBalancer
20226 受信 TCP Redis の内部通信 (Redis サブネット) (Redis サブネット)

1 NSG 規則を作成するために、サービス タグ AzureLoadBalancer (Resource Manager の場合) または AZURE_LOADBALANCER (クラシック デプロイ モデルの場合) を使用できます。

仮想ネットワーク接続に関するその他の要件

Azure Cache for Redis のネットワーク接続要件には、仮想ネットワークで最初から満たされていないものがある可能性があります。 仮想ネットワーク内で使用したときに正常に動作させるには、Azure Cache for Redis に次の項目すべてが必要になります。

  • 世界各国の Azure Key Vault エンドポイントに対する発信ネットワーク接続。 Azure Key Vault エンドポイントは、DNS ドメイン vault.azure.net で解決されます。
  • 世界各国の Azure Storage エンドポイントに対する発信ネットワーク接続 Azure Cache for Redis インスタンスと同じリージョン内にあるエンドポイントと、"他の" Azure リージョン内にあるストレージ エンドポイントが含まれます。 Azure Storage エンドポイントは、DNS ドメイン table.core.windows.net、blob.core.windows.net、queue.core.windows.net、および file.core.windows.net で解決されます。
  • ocsp.digicert.com、crl4.digicert.com、ocsp.msocsp.com、mscrl.microsoft.com、crl3.digicert.com、cacerts.digicert.com、oneocsp.microsoft.com および crl.microsoft.com への送信ネットワーク接続の問題。 この接続は、TLS/SSL 機能をサポートするために必要です。
  • 仮想ネットワークの DNS 構成は、前述したすべてのエンドポイントとドメインを解決できるようにする必要があります。 これらの DNS 要件を満たすには、仮想ネットワークの有効な DNS インフラストラクチャを構成し、保守します。
  • DNS ドメイン shoebox2-black.shoebox2.metrics.nsatc.net、north-prod2.prod2.metrics.nsatc.net、azglobal-black.azglobal.metrics.nsatc.net、shoebox2-red.shoebox2.metrics.nsatc.net、east-prod2.prod2.metrics.nsatc.net、azglobal-red.azglobal.metrics.nsatc.net、shoebox3.prod.microsoftmetrics.com、shoebox3-red.prod.microsoftmetrics.com、shoebox3-black.prod.microsoftmetrics.com、azredis-red.prod.microsoftmetrics.com、および azredis-black.prod.microsoftmetrics.com で解決される Azure Monitoring エンドポイントへの発信ネットワーク接続。

仮想ネットワークで自分のキャッシュの動作を確認するにはどうすればよいですか?

重要

仮想ネットワークでホストされている Azure Cache for Redis インスタンスに接続する場合、キャッシュのクライアントは同じ仮想ネットワーク内か、同じ Azure リージョン内で仮想ネットワーク ピアリングが有効になっている仮想ネットワーク内に存在する必要があります。 グローバル仮想ネットワーク ピアリングは現在サポートされていません。 この要件は、すべてのテスト アプリケーションや診断 ping ツールに当てはまります。 クライアント アプリケーションがどこでホストされているかに関係なく、クライアントのネットワーク トラフィックが Azure Cache for Redis インスタンスに到達できるよう NSG または他のネットワーク層を構成する必要があります。

前のセクションで説明したようにポート要件を構成した後、次の手順に従って、キャッシュが動作していることを確認できます。

  • すべてのキャッシュ ノードを再起動します。 「受信ポートの要件」と「送信ポートの要件」に記載されているように、必要なすべてのキャッシュ依存関係に到達できない場合、キャッシュは正常に再起動できません。
  • キャッシュ ノードが再起動したら (Azure portal のキャッシュの状態で報告されます)、次のテストを実行できます。

    • tcping を使って、キャッシュと同じ仮想ネットワーク内にあるコンピューターから、ポート 6380 を使用してキャッシュ エンドポイントを ping します。 例:

      tcping.exe contosocache.redis.cache.windows.net 6380

      tcping ツールからポートが開いていることがレポートされる場合、キャッシュは仮想ネットワーク内のクライアントからの接続に使用できます。

    • 別のテスト方法: キャッシュに接続してキャッシュのいくつかの項目を追加および取得するテスト キャッシュ クライアントを作成します。 テスト キャッシュ クライアントは、StackExchange.Redis を使用するコンソール アプリケーションなどが考えられます。 キャッシュと同じ仮想ネットワーク内にある VM にサンプル クライアント アプリケーションをインストールします。 次に、それを実行して、キャッシュへの接続を確認します。

仮想ネットワークで自分の Azure Cache for Redis インスタンスに接続しようとすると、リモート証明書が無効であるというエラーが表示されるのはなぜですか?

仮想ネットワークで Azure Cache for Redis インスタンスに接続しようとすると、次のような証明書の検証エラーが表示されます。

{"No connection is available to service this operation: SET mykey; The remote certificate is invalid according to the validation procedure.; …"}

IP アドレスでホストに接続していることが原因である可能性があります。 ホスト名を使用することをお勧めします。 つまり、次の文字列を使用してください。

[mycachename].redis.cache.windows.net:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

次の接続文字列のような IP アドレスは使用しないでください。

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

DNS 名を解決できない場合、StackExchange.Redis クライアントによって指定される sslHost のような構成オプションが、クライアント ライブラリに含まれている場合があります。 このオプションによって、証明書の検証に使用されるホスト名をオーバーライドできます。 例:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False;sslHost=[mycachename].redis.cache.windows.net

Standard または Basic キャッシュで仮想ネットワークを使用できますか?

仮想ネットワークは、Premium レベルのキャッシュでのみ使用できます。

Azure Cache for Redis インスタンスの作成が失敗するサブネットと成功するサブネットがあるのはなぜですか?

Azure Cache for Redis インスタンスを仮想ネットワークにデプロイする場合、キャッシュは、他のリソースの種類が含まれない専用サブネット内に配置する必要があります。 Azure Cache for Redis インスタンスを、他のリソース (Azure Application Gateway インスタンスや送信 NAT など) が含まれる Resource Manager 仮想ネットワーク サブネットにデプロイしようとすると、そのデプロイは通常失敗します。 新しい Azure Cache for Redis インスタンスを作成する前に、他の種類の既存のリソースを削除してください。

また、十分な数の使用可能な IP アドレスがサブネット内にある必要があります。

サブネット アドレス空間の要件には何がありますか

Azure は、各サブネット内で一部の IP アドレスを予約し、これらのアドレスを使用することはできません。 サブネットの最初と最後の IP アドレスは、Azure サービスで使用される 3 つ以上のアドレスと共に、プロトコル準拠に予約されます。 詳細については、「 これらのサブネット内の IP アドレスの使用に関する制限はありますか

Azure 仮想ネットワーク インフラストラクチャによって使用される IP アドレスに加えて、サブネットの各 Azure Cache for Redis インスタンスでは、クラスター シャードごとに 2 つの IP アドレスと、存在する場合は追加のレプリカ用の IP アドレスが使用されます。 ロード バランサー用に IP アドレスが追加で 1 つ使用されます。 クラスター化されていないキャッシュは、1 つのシャードを持つと見なされます。

ピアリングされた仮想ネットワークからキャッシュに接続できますか?

仮想ネットワークが同じリージョンに存在する場合は、仮想ネットワーク ピアリングまたは VPN Gateway VNET 間接続を使用してそれらを接続できます。

ピアリングされた Azure 仮想ネットワークが "異なる" リージョンにある場合、リージョン 1 のクライアント VM は、負荷分散された IP アドレスを使用してリージョン 2 のキャッシュにアクセスできませんが、これは Basic ロード バランサーによる制約のためです。 つまり、Standard ロード バランサーを使用したキャッシュである場合を除きますが、これは現時点では "可用性ゾーン" で作成されたキャッシュに限定されます。

仮想ネットワーク ピアリングの制約の詳細については、Virtual Network - ピアリングの要件と制約に関するページを参照してください。 解決策の 1 つは、仮想ネットワーク ピアリングではなく VPN Gateway VNet 間接続を使用することです。

キャッシュが仮想ネットワークでホストされている場合、すべてのキャッシュ機能が動作しますか?

キャッシュが仮想ネットワークの一部である場合は、仮想ネットワーク内のクライアントだけがキャッシュにアクセスできます。 そのため、次のキャッシュ管理機能は現時点では動作しません。

  • Redis コンソール: Redis コンソールはローカル ブラウザーで実行されます。これは通常、仮想ネットワークに接続されていない開発者用コンピューター上にあるため、キャッシュに接続できません。

Azure Lighthouse が有効になっているキャッシュで VNet インジェクションはサポートされていますか?

いいえ。サブスクリプションで Azure Lighthouse が有効になっている場合、Azure Cache for Redis インスタンスで VNet インジェクションを使用することはできません。 代わりに、プライベート リンクを使用してください。

ExpressRoute と Azure Cache for Redis の使用

お客様は、Azure ExpressRoute 回線を各自の仮想ネットワーク インフラストラクチャに接続することができます。 こうすることで、オンプレミスのネットワークを Azure に拡張できます。

既定では、新たに作成した ExpressRoute 回線は、仮想ネットワークで強制トンネリング (既定のルート 0.0.0.0/0 のアドバタイズ) を使用しません。 その結果、送信インターネット接続は仮想ネットワークから直接許可されます。 クライアント アプリケーションでは、Azure Cache for Redis インスタンスを含む他の Azure エンドポイントに接続できます。

お客様の一般的な構成では、強制トンネリング (デフォルト ルートのアドバタイズ) が使用され、送信インターネット トラフィックを強制的にオンプレミスにフローさせます。 このトラフィック フローでは、送信トラフィックがオンプレミスでブロックされると、Azure Cache for Redis との接続が切断されます。そのため、Azure Cache for Redis インスタンスがその依存関係と通信できなくなります。

解決策は、Azure Cache for Redis インスタンスを含むサブネット上で 1 つ以上のユーザー定義ルート (UDR) を定義することです。 UDR は、既定のルートに優先するサブネット固有のルートを定義します。

可能な場合、次の構成を使用します。

  • ExpressRoute 構成によって 0.0.0.0/0 をアドバタイズし、既定でオンプレミスの全送信トラフィックを強制的にトンネリングします。
  • Azure Cache for Redis インスタンスを含むサブネットに適用される UDR では、0.0.0.0/0 と、パブリック インターネットへの TCP/IP トラフィック用に動作するルートを定義します。 たとえば、次ホップの種類を internet に設定します。

これらの手順を組み合わせた結果として、サブネットレベルの UDR は ExpressRoute 強制トンネリングよりも優先されるので、Azure Cache for Redis インスタンスからの送信インターネット アクセスを確保できます。

ExpressRoute を使用してオンプレミス アプリケーションから Azure Cache for Redis インスタンスに接続することは、パフォーマンス上の理由から、一般的な使用シナリオではありません。 最適なパフォーマンスを得るには、Azure Cache for Redis クライアントが Azure Cache for Redis インスタンスと同じリージョンにある必要があります。

重要

ExpressRoute 構成でアドバタイズされたルートよりも優先するには、UDR に定義されているルートを詳細にする 必要があります 。 以下の例では、0.0.0.0/0 という広域なアドレス範囲を使用しているので、より具体的なアドレスの範囲を使用するルート アドバタイズによって誤ってオーバーライドされる可能性があります。

警告

Azure Cache for Redis は、"パブリック ピアリング パスからプライベート ピアリング パスにルートを正しくクロスアドバタイズしていない" ExpressRoute 構成ではサポートされません。 パブリック ピアリングが構成された ExpressRoute 構成は、大規模な Microsoft Azure の IP アドレス範囲について Microsoft からルート アドバタイズを受信します。 これらのアドレス範囲がプライベート ピアリング パスで誤ってクロスアドバタイズされている場合、Azure Cache for Redis インスタンスのサブネットからのすべての発信ネットワーク パケットは、誤って顧客のオンプレミス ネットワーク インフラストラクチャに強制的にトンネリングされます。 このネットワーク フローでは、Azure Cache for Redis が機能しません。 この問題を解決するには、パブリック ピアリング パスからプライベート ピアリング パスへのルートのクロスアドバタイズを停止します。

UDR の背景情報については、「仮想ネットワーク トラフィックのルーティング」を参照してください。

ExpressRoute の詳細については、「ExpressRoute の技術概要」を参照してください。

関連するコンテンツ

Azure Cache for Redis の機能について