私は Azure アーキテクチャを初めて使用し、Azure 上に構築されたアプリケーションの論理デプロイ バケットである Azure リソース グループが、定義時にリージョンに関連付けられる理由を理解しようとしています。
最初は、ディザスター リカバリーや地理的冗長性のためにグローバルな分散を提供するためだと思っていましたが、1 つのリソース グループにさまざまなリージョンの Web アプリを含めることができ、Traffic Manager を介してこれらの機能を提供できることに気付きました。個別のリソース グループを使用すると、どのリソースがどのリージョンにあるのかをより適切に識別できるようになると思いますが、組織的な目的以外では、リソース グループのリージョン定義が何を意味するのか理解できません。
（編集：より焦点を絞るために一般的なアドバイスクエリを削除しました）
Azure リソース グループのメタデータ (定義) は、どこかに格納する必要があります。したがって、場所。ただし、リソース グループ内のリソースは場所に依存せず、別のリージョンまたは場所に配置できます。リソース間の依存関係が存在する可能性があることに注意してください。西ヨーロッパの仮想マシンには、明らかに西ヨーロッパのストレージ アカウントも必要ですが、同じリソース グループ内の SQL データベースは米国西部に存在できます。
リソース グループは基本的に、アプリケーション内のどのリソースをまとめて管理するかを決定するためのものです。管理とは、それらをグループとして展開、管理、および監視することを意味するため、大まかに言えば、それらを個別のコンポーネントとして見ることはありません。
一般に、大規模なエコシステムでは、Azure リソース グループは、それらのコンポーネント (リソース) を個別のエンティティとして表示するのではなく、単一のエンティティの関連部分および相互依存部分として表示するため、1 つのリソース グループに配置します。そのため、Azure Resource Group Manager ツールを使用すると、アプリケーションのすべてのリソースを 1 回の調整された操作でデプロイ、更新、または削除できます。
展開用のテンプレートを使用すると、そのテンプレートは、テスト、ステージング、および運用などのさまざまな環境で機能します。グループ全体のロールアップされたコストを表示することで、組織の請求を明確にすることができます。
Azure Resource Manager の詳細については、こちらを参照してください。Azure リソース グループの背後にある考え方をよりよく理解するのに役立つと思います。
https://azure.microsoft.com/en-us/documentation/articles/resource-group-overview/
Azure のすべては物理的な場所/データセンターに関連しており、ARM も例外ではありません。少し前までは、すべてのデータセンターが ARM をサポートしていたわけではないため、ARM を選択する理由はさらに理にかなっています。現在、他の Azure リソースと同様に、多くの場合、エンド ユーザーとの距離や法的地理的要件に基づいて、決定を下すのはユーザーです。
リソース グループが作成された後、そのリソース グループがどのリージョンにあるかを判断する明白な方法はないようです。CDN メタデータの競合に関する問題に遭遇したとき、これはここでの議論に従って私を悲しませました. 私は最初からやり直さなければなりませんでした。次に、リージョンを使用してリソース グループに名前を付けます。例: my-resourcegroup-westus