You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/purview/concept-best-practices-network.md
+5-4Lines changed: 5 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -203,26 +203,27 @@ For performance and cost optimization, we highly recommended deploying one or mo
203
203
### If Microsoft Purview isn't available in your primary region
204
204
205
205
> [!NOTE]
206
-
> Follow recommendations under this section if Microsoft Purview is not supported in your primary Azure region.
206
+
> 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)
207
207
208
208
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.
209
209
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:
210
210
211
-
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:
211
+
**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:
212
212
- Deploy a Microsoft Purview account in your secondary region (e.g. Australia East).
213
213
- Deploy all Microsoft Purview private endpoints including account, portal and ingestion in your primary region (e.g. Australia Southeast).
214
214
- 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.
215
215
- 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.
216
-
- 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)
216
+
- 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).
217
217
218
-
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:
218
+
**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:
219
219
220
220
- Deploy a Microsoft Purview account in your secondary region (e.g. Australia East).
221
221
- Deploy Microsoft Purview portal private endpoint in primary region (e.g. Australia Southeast) for user access to Microsoft Purview governance portal.
222
222
- 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.
223
223
- 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.
224
224
- 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).
225
225
- This option is recommended if you have data sources in both primary and secondary regions and users are connected through primary region.
226
+
- 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).
0 commit comments