Merge pull request #225462 from zeinab-mk/patch-34

cross region scenarios

Author: prmerger-automator[bot]

articles/purview/concept-best-practices-accounts.md

@@ -6,7 +6,7 @@ ms.author: zeinam
 ms.service: purview
 ms.subservice: purview-data-map
 ms.topic: conceptual
-ms.date: 12/12/2022
+ms.date: 01/28/2023
 ---
 
 # Microsoft Purview accounts architectures and best practices  
@@ -59,7 +59,7 @@ An exception applies to VM-based data sources and Power BI tenants.For more info
 
 ## Default Microsoft Purview account
 
-Having multiple Microsoft Purview accounts in a tenant poses the challenge of which Microsoft Purview account should all other services like PBI, Synapse connect to. 
+Having multiple Microsoft Purview accounts in a tenant poses the challenge of which Microsoft Purview account should all other services such as Power BI tenant or Azure Synapse connect to. 
 
 This is where default Microsoft Purview account will help. An Azure global administrator (or tenant admin) can designate a Microsoft Purview account as **default** Microsoft Purview account at the tenant level. At any point in time a tenant can have only 0 or 1 default accounts. Once this is set any user in your organization has clear understanding that this account is the "right" one, when connecting to Microsoft Purview.
 
@@ -79,7 +79,20 @@ Review [Microsoft Purview Pricing model](https://azure.microsoft.com/pricing/det
 
 Some organizations often have many business units (BUs) that operate separately, and, in some cases, they don't even share billing with each other. In those cases, the organization will end up creating a Microsoft Purview instance for each BU.
 
-For more information about cloud computing cost model in chargeback and showback models, see: [What is cloud accounting?](/azure/cloud-adoption-framework/strategy/cloud-accounting).  
+For more information about cloud computing cost model in chargeback and showback models, see: [What is cloud accounting?](/azure/cloud-adoption-framework/strategy/cloud-accounting). 
+
+## Selecting an Azure region
+
+Microsoft Purview is an Azure platform as a service solution. You can deploy a Microsoft Purview account inside your Azure subscription in any
+[supported Azure regions](https://azure.microsoft.com/explore/global-infrastructure/products-by-region/?products=purview&regions=all). 
+
+If Microsoft Purview is not available in your primary Azure region, consider the following factors when choosing a secondary region to deploy your Microsoft Purview account:
+
+- Review the latency between your primary Azure region where data sources are deployed and your secondary Azure region, where Microsoft Purview account will be deployed. For more information, see [Azure network round-trip latency statistics](../networking/azure-network-latency.md).
+
+- Review your data residency requirements. When you scan data sources in the Microsoft Purview Data Map, information related to your metadata is ingested and stored inside your data map in the Azure region where your Microsoft Purview account is deployed. For more information see, [Where is metadata stored](concept-best-practices-security.md#where-is-metadata-stored)
+
+- Review your network and security requirements if private network connectivity for user access or metadata ingestion is required. For more information see, [If Microsoft Purview isn't available in your primary region](concept-best-practices-network.md#if-microsoft-purview-isnt-available-in-your-primary-region)
 
 ## Other considerations and recommendations 
 

articles/purview/concept-best-practices-network.md

@@ -6,7 +6,7 @@ ms.author: zeinam
 ms.service: purview
 ms.subservice: purview-data-catalog
 ms.topic: conceptual
-ms.date: 01/13/2023
+ms.date: 01/28/2023
 ms.custom: fasttrack-edit
 ---
 
@@ -200,6 +200,32 @@ For performance and cost optimization, we highly recommended deploying one or mo
 
 :::image type="content" source="media/concept-best-practices/network-pe-multi-region.png" alt-text="Screenshot that shows Microsoft Purview with private endpoints in a scenario of multiple virtual networks and multiple regions."lightbox="media/concept-best-practices/network-pe-multi-region.png":::
 
+### If Microsoft Purview isn't available in your primary region
+
+> [!NOTE]
+> Follow recommendations under this section if Microsoft Purview is not supported in your primary Azure region. For more information, see [Selecting an Azure region](concept-best-practices-accounts.md#selecting-an-azure-region)
+
+If Microsoft Purview is not available in your primary Azure region, and secure connectivity for metadata ingestion or user access is required to access Microsoft Purview governance portal. 
+For example, if your primary Azure region for majority of your Azure data services is Australia Southeast, and you need to deploy a Microsoft Purview account in a closest supported Azure region, meanwhile all of your Azure services are deployed in the same Azure geography, you can choose Australia East region to deploy your Microsoft Purview account. To enable private network connectivity for ingestion and portal access, you can choose any of the following architectural designs:
+
+**Option 1: Deploy Microsoft Purview account in a secondary region and deploy all private endpoints in primary region where all your Azure data sources are located.** For the scenario above:
+- Deploy a Microsoft Purview account in your secondary region (e.g. Australia East).
+- Deploy all Microsoft Purview private endpoints including account, portal and ingestion in your primary region (e.g. Australia Southeast).
+- This is the recommended option, if Australia Southeast is the primary region for all your data sources and you have all network resources deployed in your primary region. 
+- Deploy all [Microsoft Purview self-hosted integration runtime]( manage-integration-runtimes.md) VMs in your primary region (e.g. Australia Southeast). This helps to reduce cross region traffic as the Data Map scans will happen in the local region where data sources are located and only metadata is ingested int your secondary region where your Microsoft Purview account is deployed.
+- If you use [Microsoft Purview Managed VNets](catalog-managed-vnet.md) for metadata ingestion, Managed VNet Runtime and all managed private endpoints will be automatically deployed in the region where your Microsoft Purview is deployed (e.g. Australia East).
+
+**Option 2: Deploy Microsoft Purview account in a secondary region and deploy private endpoints in primary or secondary region where most of your Azure data sources are located.** For the example above:
+
+- Deploy a Microsoft Purview account in your secondary region (e.g. Australia East).
+- Deploy Microsoft Purview portal private endpoint in primary region (e.g. Australia Southeast) for user access to Microsoft Purview governance portal.
+- Deploy Microsoft Purview account and ingestion private endpoints in your primary region (e.g. Australia southeast) to scan data sources locally in the primary region.
+- Deploy Microsoft Purview account and ingestion private endpoints in your secondary region (e.g. Australia East) to scan data sources locally in the secondary region.
+- Deploy [Microsoft Purview self-hosted integration runtime]( manage-integration-runtimes.md) VMs in both primary and secondary regions. This will help to keep data Map scan traffic in the local region and send only metadata to Microsoft Purview Data Map where is configured in your secondary region (e.g. Australia East).
+- This option is recommended if you have data sources in both primary and secondary regions and users are connected through primary region. 
+- If you use [Microsoft Purview Managed VNets](catalog-managed-vnet.md) for metadata ingestion, Managed VNet Runtime and all managed private endpoints will be automatically deployed in the region where your Microsoft Purview is deployed (e.g. Australia East).
+
+
 ### DNS configuration with private endpoints
 
 #### Name resolution for multiple Microsoft Purview accounts