3行で

・グローバル VNet ピアリングは異なるリージョンでのピアリングを指す
・ Basic Load Balancer は同じリージョン内の分散のみサポートするためグローバルピアリング経由の通信はできない
・そのため、Basic Load Balancer が内部で利用されているサービスはグローバルピアリング経由の通信はできない

はじめに

VNet ピアリングをする際には、ピアリングしようとする2つの VNet が同一リージョンなのか異リージョンかは意識せずに設定ができます。

あまり難しいことを考えずに設定できる点がとてもありがたい仕様なのですが、異なるリージョン間の VNet アピリング( グローバル VNet ピアリング)は制約が存在します。

この制約を理解した上で設計・利用しないと、設定はできてしまうため「いざ、接続テスト！！！」という場面で転んでしまうため注意が必要です。

ドキュメントを読むとしっかり記載されているので、パブリッククラウドに慣れた注意深い人は利用前に”制約”、”制限”などのキーワードでググっているので引っかからない、、、、のですが、備忘兼ねて下記のドキュメントのポイントを本投稿では記載します。

制約の中身①( Basic Load Balancer そのものをユーザが利用するケース)

仮想ネットワーク内のリソースは、グローバルにピアリングされた仮想ネットワークの Basic 内部ロードバランサーのフロントエンド IP アドレスと通信することはできません。 Basic Load Balancer のサポートは、同じリージョン内でのみ存在します。

”Basic 内部ロードバランサーのフロントエンド IP アドレスと通信できない” という記載が少し難しいですが、Basic Load Balancer を介さずに直接アクセスできるもの( VM )は大丈夫、ということですね。
ただ、Basic Load Balancer のフロントエンド IP に通信できないのでグローバルピアリング経由では分散は機能はしないということに。

それでは困る方は、Standard Load Balancer を利用するようにしましょう。

制約の中身②( Basic Load Balancer を Azure サービス内部で利用しているケース)

自分で設計する範囲においてBasic Load Balancer を利用している場合は、Standard Load Balancer に変えることで制約から逃れることができますが、Azure サービス内部で Basic Load Balancer が利用されている所についてはこちらでは変えられないので仕様を許容できない場合は、処理パターンを変えなければなりません。（例えば、Push型からPull型に変えて通信の向きを変える）

Basic Load Balancer を使用するサービスは下記ドキュメントに記載されています。

・Basic Load Balancer の背後にある VM
・Basic Load Balancer を使用する仮想マシンスケールセット
・Redis Cache
・Application Gateway (v1) SKU
・Service Fabric
・API Management
・Active Directory Domain Service (ADDS)
・Logic Apps
・HDInsight
・Azure Batch
・App Service Environment

App Service Environment が対象になっているため、ASE上で使っているサービスも該当する点注意してください。

そのうち解消されると信じて利用者は待つしかないので、今はハマらないように耐えましょう・・・！