現在、Azure で UI Web ロールと Web サービス Web ロール (WCF REST) を実行しています。各ロールには 2 つのインスタンスが含まれます (負荷分散と SLA 要件を満たすため)。UI Web ロールと Web サービス Web ロールは同じサブスクリプション内にありますが、デプロイは異なります。 コードベースをマージしたくありません (保守性など)。したがって、UI レイヤーは xyz.cloudapp.net にあり、Web サービス レイヤーは abc.cloudapp.net にあります。
現在の要件は、Web サービスの Web ロールを内部エンドポイントにすることです。つまり、UI レイヤーからのみアクセスできるようにします。内部エンドポイントの構成と別の展開からのアクセスに関する文献はあまり明確ではありません。
これが機能するには、2 つの異なる役割が 1 つの展開の一部である必要があると想定しています。展開に影響を与えずにこれを行うことはできますか? 正しい方向へのポインタは大歓迎です。
内部エンドポイントは単一のデプロイメント内でのみアクセス可能であり、ロードバランサーを介してルーティングされません（したがって、内部エンドポイントでアクセス可能なwcfサービスのインスタンスが2つある場合は、インスタンス間で呼び出しを分散する必要があります）。もちろん、これには、WebロールとwcfWebロールの両方を同じデプロイメントに配置する必要があります。
Webロールインスタンスからwcfサービスに到達するための安全な方法として、サービスバスを検討することをお勧めします。または...入力エンドポイントを介してwcfサービスを公開しますが、サービスは保護します。
WCFエンドポイントへのクレームベース認証を使用してアクセスを制限するためにACS（アクセス制御サービス）を使用することを検討しましたか？
WCFバインディングを介して提供できる保護スキームは多数あります。
内部エンドポイントは、同じデプロイメント内のロール間でのみ通信できます。2つの別々のデプロイメントがある場合（abc.cloudapp.netおよびxyz.cloudapp.net、内部エンドポイントは役に立ちません）。
あなたのニーズを満たすはずの仮想DMZと呼ぶのが好きなアプローチがあります：http://brentdacodemonkey.wordpress.com/?s=virtual+dmz
ACS および WCF バインディングを利用して、入力エンドポイントへのアクセス制御を作成できます (負荷分散されます)。もちろん、堅牢なものが必要ない場合は、標準の古い WCF 相互認証シナリオだけを使用できます。
そうは言っても、デビッドは優れた点を指摘しています。内部エンドポイントは、デプロイされた単一のサービスでのみアクセスできます。これは、そのサービスが分離境界 (仮想 LAN ブランチを考えてください) を表し、入力エンドポイントのみがその境界の外側からアドレス指定できるためです。