こういうお話がありました。

結論からいうと、LBとかじゃなくてホストサーバー上の設定なのでVNET（特に拒否の設定）指定ができちゃいます。

とはいえちょっと気になったので見てみることにします。こんなVNET to VNETなネットワークをAzure上で組んでみました。

ca1-srv1-vnet1 なインスタンスにIISを入れてHTTP（tcp/80）なエンドポイントを定義します。（LBは省略しました）

ネットワークACL（エンドポイントACL）を何も設定しない際に各インスタンスで内部のIPアドレスと外部のFQDN（図だとca1.cloudapp.net）にブラウザで接続してIISの既定のページが見れることは確認済みな状態とします。（Azure外のクライアントも当然OK）

※ようは疎通できてる状態

さて、以下の表のような感じでACLを定義したときに、それぞれのインスタンスから内部IPとFQDNでアクセスしてどうなるかを見てみました。

ACLの状態	ca1-srv1-vnet1		ca1-srv2-vnet1		ca2-src1-vnet1		ca3-srv1-vnet2		外部PC
	内部IP	FQDN	内部IP	FQDN	内部IP	FQDN	内部IP	FQDN	FQDN
vnet1のみ許可	OK	OK	OK	OK	OK	NG	OK	NG	NG
vnet1のみ拒否	OK	OK	NG	OK	NG	OK	OK	OK	OK
vnet2のみ許可	OK	OK	OK	OK	OK	NG	OK	NG	NG
vnet2のみ拒否	OK	OK	OK	OK	OK	OK	NG	OK	OK
外部PCのみ許可	OK	OK	OK	OK	OK	NG	OK	NG	OK
外部PCのみ拒否	OK	OK	OK	OK	OK	OK	OK	OK	NG
ca1のGIPのみ許可	OK	OK	OK	OK	OK	NG	OK	NG	NG
ca1のGIPのみ拒否	OK	NG	OK	NG	OK	OK	OK	OK	NG
ca2のGIPのみ許可	OK	OK	OK	OK	OK	OK	OK	NG	NG
ca2のGIPのみ拒否	OK	OK	OK	OK	OK	NG	OK	OK	OK
ca3のGIPのみ許可	OK	OK	OK	OK	OK	NG	OK	OK	NG
ca3のGIPのみ拒否	OK	OK	OK	OK	OK	OK	OK	NG	OK

 

※クラウドサービスのグローバルIPアドレスは一応インスタンス上からインターネットにアクセスした際に使用されるIPアドレスを確認して設定

本来ネットワークACLは許可だけが設定されたらそのルールにマッチしないものは拒否になるはずですが、VNETを許可した場合はその辺うまく動作してない様子。

例えばvnet1だけ許可した場合だと、vnet2にいるインスタンスからもアクセスできてしまっています。（期待値としては拒否してほしい）

ただ拒否設定の場合は想定どおりになるようなので、何とも不可思議な挙動です。（表中で怪しいところをわかりやすくしようと思ったけど、面倒くさくなったので放置）

但し、ネットワークACLのドキュメントを見る限りでは

仮想ネットワークに対して ACL を指定したり、仮想ネットワーク内にある特定のサブネットに対して ACL を指定したりすることはできません。

とあるので今のところこのあたりの挙動は想定外なのかもです。今後に期待。

また、ネットワークACLのパケットフィルタ処理はホストノード上で実行されるようです。

ACL を作成して仮想マシンのエンドポイントに適用するとき、パケット フィルターが VM のホスト ノードで実行されます。これは、リモート IP アドレスからのトラフィックのフィルター処理が、VM 上ではなく、ホスト ノードによって実行され、ACL ルールとの照合が行われることを意味します。これにより、パケット フィルターの処理で VM が重要な CPU サイクルを消費するのを防ぐことができます。

上位のFWとかルータじゃなかったのねー。

まぁとりあえず現状はVNETに対するACLは微妙にノンサポートという感じですので、もし制限したい場合はご注意ください。（意図せず外部はOKになったりする可能性があります）