重要
Azure Cache for Redis は、すべての SKU の提供終了タイムラインを発表しました。 できるだけ早く既存の Azure Cache for Redis インスタンスを Azure Managed Redis に移行することをお勧めします。
提供終了の詳細については、以下を参照してください。
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 インジェクションの制限事項
- 多くの場合、仮想ネットワーク構成を作成して維持すると、エラーが発生しやすくなります。 トラブルシューティングも困難です。 仮想ネットワークの構成が正しくないと、次の問題が発生する可能性があります:
- キャッシュ インスタンスからの妨害されたメトリックの送信
- レプリカ ノードがプライマリ ノードからデータをレプリケートできない
- データ損失の可能性
- スケーリングなどの管理操作の失敗
- 断続的または完全な SSL/TLS エラー
- セキュリティおよび信頼性の向上などの重要な更新を含め、更新プログラムを適用できない
- 最も深刻なシナリオでは、可用性の損失
- VNet の挿入されたキャッシュを使用する場合、証明書の失効リスト、公開キー基盤、Azure Key Vault、Azure Storage、Azure Monitor などのキャッシュの依存関係にアクセスできるように、VNet を最新の状態に保つ必要があります。
- VNet に挿入されたキャッシュは、Premium レベルの Azure Cache for Redis でのみ使用でき、他の層では使用できません。
- 既存の Azure Cache for Redis インスタンスを Virtual Network に挿入することはできません。 キャッシュを "作成する" ときは、このオプションを選ぶ必要があります。
- Azure portal では、リソース作成時の VNET インジェクションの構成はサポートされていません
仮想ネットワーク サポートの設定
az redis create を参照してください。
Azure Cache for Redis 仮想ネットワークに関する FAQ
次の一覧は、Azure Redis Cache ネットワークに関してよく寄せられる質問への回答です。
- Azure Cache for Redis と仮想ネットワークの誤った構成に関してよく見られる問題を教えてください
- 仮想ネットワークで自分のキャッシュの動作を確認するにはどうすればよいですか?
- 仮想ネットワークで自分の Azure Cache for Redis インスタンスに接続しようとすると、リモート証明書が無効であるというエラーが表示されるのはなぜですか?
- Standard または Basic キャッシュで仮想ネットワークを使用できますか?
- Azure Cache for Redis インスタンスの作成が失敗するサブネットと成功するサブネットがあるのはなぜですか?
- サブネット アドレス空間の要件には何がありますか
- ピアリングされた仮想ネットワークからキャッシュに接続できますか?
- Azure Lighthouse が有効になっているキャッシュでは、VNet インジェクションはサポートされていますか?
- キャッシュが仮想ネットワークでホストされている場合、すべてのキャッシュ機能が動作しますか?
- Azure Lighthouse が有効になっているキャッシュでは、VNet インジェクションはサポートされていますか?
Azure Cache for Redis と仮想ネットワークの誤った構成に関してよく見られる問題を教えてください
Azure Cache for Redis が仮想ネットワークでホストされている場合は、以下の表に含まれるポートが使用されます。
重要
以下の表に含まれるポートがブロックされている場合、キャッシュが正常に動作しない可能性があります。 仮想ネットワークで Azure Cache for Redis を使用する場合の構成の誤りに関する最も一般的な問題は、これらのポートのうち 1 つ以上がブロックされていることです。
送信ポートの要件
Azure Cache for Redis にはネットワーク接続要件があります。これはキャッシュを機能させるのに必要な他の依存関係サービスへの送信接続を行うため、またはノード間通信で Redis サブネット内部への接続を行うために必要となるものです。
| 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 |
| 12000 | 送信 | TCP | Azure Monitor に対する Redis の依存関係 | (Redis サブネット) | AzureMonitor 1 |
| 53 | 送信 | TCP/UDP | DNS (インターネット/仮想ネットワーク) に対する Redis の依存関係 | (Redis サブネット) | 168.63.129.16 および 169.254.169.254 2 およびサブネットのカスタム DNS サーバー 3 |
| 123 | 送信 | UDP | NTP に対するオペレーティング システムの依存関係 | (Redis サブネット) | * |
| 1688 | 送信 | TCP | ライセンス認証のためのオペレーティング システムの依存関係 | (Redis サブネット) | * |
| 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 にはネットワーク接続要件があります。これはキャッシュを機能させるのに必要な他の依存関係サービスへの送信接続を行うため、またはノード間通信で Redis サブネット内部への接続を行うために必要となるものです。
Azure Cache for Redis を仮想ネットワーク内で使用する場合は、適切に機能させるために、次の送信接続項目がすべて必要です。
| ホスト名 | Protocol | 送信ポート | 目的 | サービス タグ |
|---|---|---|---|---|
| *.vault.azure.net | HTTPS | 443 | Azure Key Vault | AzureKeyVault |
| *.table.core.windows.net | HTTPS | 443 | Azure Storage | Storage |
| *.blob.core.windows.net | HTTPS | 443 | Azure Storage | Storage |
| *.queue.core.windows.net | HTTPS | 443 | Azure Storage | Storage |
| *.file.core.windows.net | HTTPS | 443 | Azure Storage | Storage |
| ocsp.digicert.com | HTTP | 80 | Azure 公開キー インフラストラクチャ | 該当なし |
| crl4.digicert.com | HTTP | 80 | Azure 公開キー インフラストラクチャ | 該当なし |
| ocsp.msocsp.com | HTTP | 80 | Azure 公開キー インフラストラクチャ | 該当なし |
| mscrl.microsoft.com | HTTP | 80 | Azure 公開キー インフラストラクチャ | 該当なし |
| crl3.digicert.com | HTTP | 80 | Azure 公開キー インフラストラクチャ | 該当なし |
| cacerts.digicert.com | HTTP | 80 | Azure 公開キー インフラストラクチャ | 該当なし |
| oneocsp.microsoft.com | HTTP | 80 | Azure 公開キー インフラストラクチャ | 該当なし |
| crl.microsoft.com | HTTP | 80 | Azure 公開キー インフラストラクチャ | 該当なし |
| cacerts.geotrust.com | HTTP | 80 | Azure 公開キー インフラストラクチャ | 該当なし |
| www.microsoft.com | HTTP | 80 | Azure 公開キー インフラストラクチャ | 該当なし |
| cdp.geotrust.com | HTTP | 80 | Azure 公開キー インフラストラクチャ | 該当なし |
| status.geotrust.com | HTTP | 80 | Azure 公開キー インフラストラクチャ | 該当なし |
| shoebox3.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| shoebox3-red.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| shoebox3-black.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| azredis.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| azredis-red.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| azredis-black.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| global.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| gcs.prod.monitoring.core.windows.net | HTTPS | 443 | Azure Monitor | AzureMonitor |
| *.prod.warm.ingest.monitor.core.windows.net | HTTPS | 443 | Azure Monitor | AzureMonitor |
| *.servicebus.windows.net | HTTPS | 443 | Azure Monitor | EventHub |
| *.update.microsoft.com | HTTPS | 443 | オペレーティング システム更新サービス | AzureCloud |
| *.windowsupdate.com | HTTP/HTTPS | 80、443 | オペレーティング システム更新サービス | 該当なし |
| *.delivery.mp.microsoft.com | HTTP/HTTPS | 80、443 | オペレーティング システム更新サービス | AzureCloud |
| go.microsoft.com | HTTP/HTTPS | 80、443 | ウイルス対策 | 該当なし |
| *.wdcp.microsoft.com | HTTPS | 443 | ウイルス対策 | AzureCloud |
| *.wdcpalt.microsoft.com | HTTPS | 443 | ウイルス対策 | AzureCloud |
| *.wd.microsoft.com | HTTPS | 443 | ウイルス対策 | AzureCloud |
| definitionupdates.microsoft.com | HTTPS | 443 | ウイルス対策 | 該当なし |
| azurewatsonanalysis-prod.core.windows.net | HTTPS | 443 | 内部診断 | AzureCloud |
| shavamanifestazurecdnprod1.azureedge.net | HTTPS | 443 | 内部診断 | 該当なし |
| shavamanifestcdnprod1.azureedge.net | HTTPS | 443 | 内部診断 | 該当なし |
| *.data.microsoft.com | HTTPS | 443 | 内部診断 | AzureCloud |
- 仮想ネットワーク用の DNS 構成では、前の表に記載されているすべてのエンドポイントとドメインを解決できるようにする必要があります。 これらの DNS 要件を満たすには、仮想ネットワークの有効な DNS インフラストラクチャを構成し、保守します。
仮想ネットワークで自分のキャッシュの動作を確認するにはどうすればよいですか?
重要
仮想ネットワークでホストされている Azure Cache for Redis インスタンスに接続する場合、キャッシュのクライアントは同じ仮想ネットワーク内か、同じ Azure リージョン内で仮想ネットワーク ピアリングが有効になっている仮想ネットワーク内に存在する必要があります。 グローバル仮想ネットワーク ピアリングは現在サポートされていません。 この要件は、すべてのテスト アプリケーションや診断 ping ツールに当てはまります。 クライアント アプリケーションがどこでホストされているかに関係なく、クライアントのネットワーク トラフィックが Azure Cache for Redis インスタンスに到達できるよう NSG または他のネットワーク層を構成する必要があります。
前のセクションで説明したようにポート要件を構成した後、変更が正しく反映されるようにするには、ほとんどの場合再起動が必要です。 そうしないと、接続の問題が発生する可能性があります。 次の手順に従うと、キャッシュが動作していることを確認できます。
- すべてのキャッシュ ノードを再起動します。 「受信ポートの要件」と「送信ポートの要件」に記載されているように、必要なすべてのキャッシュ依存関係に到達できない場合、キャッシュは正常に再起動できません。
- キャッシュ ノードが再起動したら (Azure portal のキャッシュの状態で報告されます)、次のテストを実行できます。
tcpingを使って、キャッシュと同じ仮想ネットワーク内にあるコンピューターから、ポート 6380 を使用してキャッシュ エンドポイントを ping します。 次に例を示します。tcping.exe contosocache.redis.cache.windows.net 6380tcpingツールからポートが開いていることがレポートされる場合、キャッシュは仮想ネットワーク内のクライアントからの接続に使用できます。別のテスト方法: キャッシュに接続してキャッシュのいくつかの項目を追加および取得するテスト キャッシュ クライアントを作成します。 テスト キャッシュ クライアントは、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
さらに、Azure Cache for Redis がホストされているサブネットが、SSL/TLS 機能のためにポート 80 経由の TCP 送信接続をブロックしている場合、クライアントで断続的な TLS 証明書の検証エラーが発生する可能性があります。
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 は、"Microsoft ピアリング パスからプライベート ピアリング パスにルートを正しくクロスアドバタイズしていない" ExpressRoute 構成ではサポートされません。 Microsoft ピアリングが構成された ExpressRoute 構成は、大規模な Microsoft Azure の IP アドレス範囲について Microsoft からルート アドバタイズを受信します。 これらのアドレス範囲がプライベート ピアリング パスで誤ってクロスアドバタイズされている場合、Azure Cache for Redis インスタンスのサブネットからのすべての発信ネットワーク パケットは、誤って顧客のオンプレミス ネットワーク インフラストラクチャに強制的にトンネリングされます。 このネットワーク フローでは、Azure Cache for Redis が機能しません。 この問題を解決するには、Microsoft ピアリング パスからプライベート ピアリング パスへのルートのクロスアドバタイズを停止します。
UDR の背景情報については、「仮想ネットワーク トラフィックのルーティング」を参照してください。
ExpressRoute の詳細については、「ExpressRoute の技術概要」を参照してください。
関連コンテンツ
Azure Cache for Redis の機能について説明します。