-> Starting July 2023, we will apply delivery method optimizations such that tenants with a free or trial subscription may receive a text message or voice call.

-Some users with phone numbers that have country codes belonging to India, Indonesia and New Zealand may receive their verification codes via WhatsApp. Like RCS, these messages are similar to SMS, but have more Microsoft branding and a verified checkmark. Only users that have WhatsApp will receive verification codes via this channel. To determine whether a user has WhatsApp, we silently attempt delivering them a message via the app using the phone number they already registered for text message verification and see if it's successfully delivered. If users don't have any internet connectivity or uninstall WhatsApp, they'll receive their verification codes via SMS. The phone number associated with Microsoft's WhatsApp Business Agent is: *+1 (217) 302 1989*.

- * Microsoft may limit repeated authentication attempts that are performed by the same user or organization in a short period of time. This limitation does not apply to Microsoft Authenticator or verification codes. If you have hit these limits, you can use the Authenticator App, verification code or try to sign in again in a few minutes.

- * Microsoft may limit or block voice or text message authentication attempts that are performed by the same user, phone number, or organization due to high number of voice or text message authentication attempts. If you are experiencing this error, you can try another method, such as Authenticator App or verification code, or reach out to your admin for support.

-description: Learn three common disaster recovery patterns for Azure App Service.

-keywords: app service, azure app service, hadr, disaster recovery, business continuity, high availability, bcdr

-# Strategies for business continuity and disaster recovery in Azure App Service

-Most organizations have a business continuity plan to maintain availability of their applications during downtime and the preservation of their data in a regional disaster. This article covers some common strategies for web apps deployed to App Service.

-For example, when you create a web app in App Service and choose an Azure region during resource creation, it's a single-region app. When the region becomes unavailable during a disaster, your application also becomes unavailable. If you create an identical deployment in a secondary Azure region, your application becomes less susceptible to a single-region disaster, which guarantees business continuity, and any data replication across the regions lets you recover your last application state.

-For IT, business continuity plans are largely driven by two metrics:

-

-Normally, maintaining an SLA around RTO is impractical for regional disasters, and you would typically design your disaster recovery strategy around RPO alone (i.e. focus on recovering data and not on minimizing interruption). With Azure, however, it's not only practical but could even be straightforward to deploy App Service for automatic geo-failovers. This lets you disaster-proof your applications further by taking care of both RTO and RPO.

-Depending on your desired RTO and RPO metrics, three disaster recovery architectures are commonly used, as shown in the following table:

-

-|.| Active-Active regions | Active-Passive regions | Passive/Cold region|

-|-|-|-|-|

-|RTO| Real-time or seconds| Minutes| Hours |

-|RPO| Real-time or seconds| Minutes| Hours |

-|Cost | $$$| $$| $|

-|Scenarios| Mission-critical apps| High-priority apps| Low-priority apps|

-|Ability to serve multi-region user traffic| Yes| Yes/maybe| No|

-|Code deployment | CI/CD pipelines preferred| CI/CD pipelines preferred| Backup and restore |

-|Creation of new App Service resources during downtime | Not required | Not required| Required |

-## Active-Active architecture

-In this disaster recovery approach, identical web apps are deployed in two separate regions and Azure Front door is used to route traffic to both the active regions.

-With this example architecture:

-Steps to create an active-active architecture for your web app in App Service are summarized as follows:

-1. Create two App Service plans in two different Azure regions. Configure the two App Service plans identically.

-1. Create two instances of your web app, with one in each App Service plan.

-1. Create an Azure Front Door profile with:

- - An endpoint.

- - Two origin groups, each with a priority of 1. The equal priority tells Azure Front Door to route traffic to both regions equally (thus active-active).

- - A route.

-1. [Limit network traffic to the web apps only from the Azure Front Door instance](app-service-ip-restrictions.md#restrict-access-to-a-specific-azure-front-door-instance).

-1. Setup and configure all other back-end Azure service, such as databases, storage accounts, and authentication providers.

-1. Deploy code to both the web apps with [continuous deployment](deploy-continuous-deployment.md).

-[Tutorial: Create a highly available multi-region app in Azure App Service](tutorial-multi-region-app.md) shows you how to set up an *active-passive* architecture. The same steps with minimal changes (setting priority to ΓÇ£1ΓÇ¥ for both origin groups in Azure Front Door) give you an *active-active* architecture.

-## Active-passive architecture

-In this disaster recovery approach, identical web apps are deployed in two separate regions and Azure Front door is used to route traffic to one region only (the *active* region).

-With this example architecture:

- - **Preferred** The secondary App Service plan has the same pricing tier as the primary, with the same number of instances or fewer. This approach ensures parity in both feature and VM sizing for the two App Service plans. The RTO during a geo-failover only depends on the time to scale out the instances.

- - **Less preferred** The secondary App Service plan has the same pricing tier type (such as PremiumV3) but smaller VM sizing, with lesser instances. For example, the primary region may be in P3V3 tier while the secondary region is in P1V3 tier. This approach still ensures feature parity for the two App Service plans, but the lack of size parity may require a manual scale-up when the secondary region becomes the active region. The RTO during a geo-failover depends on the time to both scale up and scale out the instances.

- - **Least-preferred** The secondary App Service plan has a different pricing tier than the primary and lesser instances. For example, the primary region may be in P3V3 tier while the secondary region is in S1 tier. Make sure that the secondary App Service plan has all the features your application needs in order to run. Differences in features availability between the two may cause delays to your web app recovery. The RTO during a geo-failover depends on the time to both scale up and scale out the instances.

-Steps to create an active-passive architecture for your web app in App Service are summarized as follows:

-1. Create two App Service plans in two different Azure regions. The secondary App Service plan may be provisioned using one of the approaches mentioned previously.

-1. Configure autoscaling rules for the secondary App Service plan so that it scales to the same instance count as the primary when the primary region becomes inactive.

-1. Create two instances of your web app, with one in each App Service plan.

-1. Create an Azure Front Door profile with:

- - An endpoint.

- - An origin group with a priority of 1 for the primary region.

- - A second origin group with a priority of 2 for the secondary region. The difference in priority tells Azure Front Door to prefer the primary region when it's online (thus active-passive).

- - A route.

-1. [Limit network traffic to the web apps only from the Azure Front Door instance](app-service-ip-restrictions.md#restrict-access-to-a-specific-azure-front-door-instance).

-1. Setup and configure all other back-end Azure service, such as databases, storage accounts, and authentication providers.

-1. Deploy code to both the web apps with [continuous deployment](deploy-continuous-deployment.md).

-[Tutorial: Create a highly available multi-region app in Azure App Service](tutorial-multi-region-app.md) shows you how to set up an *active-passive* architecture.

-## Passive/cold region

-In this disaster recovery approach, you create regular backups of your web app to an Azure Storage account.

-With this example architecture:

-Steps to create a passive-cold region for your web app in App Service are summarized as follows:

-1. Create an Azure storage account in the same region as your web app. Choose Standard performance tier and select redundancy as Geo-redundant storage (GRS) or Geo-Zone-redundant storage (GZRS).

-1. Enable RA-GRS or RA-GZRS (read access for the secondary region).

-1. [Configure custom backup](manage-backup.md) for your web app. You may decide to set a schedule for your web app backups, such as hourly.

-1. Verify that the web app backup files can be retrieved the secondary region of your storage account.

-#### What if my web app's region doesn't have GZRS or GRS storage?

-[Azure regions that don't have a regional pair](../reliability/cross-region-replication-azure.md#regions-with-availability-zones-and-no-region-pair) don't have GRS nor GZRS. In this scenario, utilize zone-redundant storage (ZRS) or locally redundant storage (LRS) to create a similar architecture. For example, you can manually create a secondary region for the storage account as follows:

-Steps to create a passive-cold region without GRS and GZRS are summarized as follows:

-1. Create an Azure storage account in the same region of your web app. Choose Standard performance tier and select redundancy as zone-redundant storage (ZRS).

-1. [Configure custom backup](manage-backup.md) for your web app. You may decide to set a schedule for your web app backups, such as hourly.

-1. Verify that the web app backup files can be retrieved the secondary region of your storage account.

-1. Create a second Azure storage account in a different region. Choose Standard performance tier and select redundancy as locally redundant storage (LRS).

-1. By using a tool like [AzCopy](../storage/common/storage-use-azcopy-v10.md#use-in-a-script), replicate your custom backup (Zip, XML and log files) from primary region to the secondary storage. For example:

- ```

- azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'

- ```

- You can use [Azure Automation with a PowerShell Workflow runbook](../automation/learn/automation-tutorial-runbook-textual.md) to run your replication script [on a schedule](../automation/shared-resources/schedules.md). Make sure that the replication schedule follows a similar schedule to the web app backups.

-## Important considerations

-## Next steps

-[Tutorial: Create a highly available multi-region app in Azure App Service](tutorial-multi-region-app.md)

-You'll need two instances of a web app that run in different Azure regions for this tutorial. You'll use the [region pair](../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) East US/West US as your two regions and create two empty web apps. Feel free to choose you're own regions if needed.

- - CREATE USER "AutomationAccount"

- - FROM EXTERNAL PROVIDER WITH OBJECT_ID= `ObjectID`

-## Install and connect to your AKS cluster

-Once the External-IP is available, open a web browser to the External-IP address of your service and you see the application running as follows:

-<!-- screenshot for Seattle -->

-With two services opened in your browser, you should see that changing the inventory in one region is almost instantly reflected in the other region. The inventory data is stored in the Redis Enterprise instances that are replicating data across regions.

-You did it! Click on the buttons and explore the demo. To reset the count, add `/reset` after the url:

-To deliver a highly available service, the container data is replicated to another region. This data replication helps in the cases where disaster recovery is needed in face of a full regional outage. Internally, Azure Fluid Relay uses Azure Blob Storage cross-region replication to achieve that. The region where data is replicated is defined by the Azure regional pairs listed on the [Cross-region replication in Azure](../../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) page.

-# [In-process](#tab/in-process)

-### HTTP trigger, write one record

-### HTTP trigger, write to two tables

-### HTTP trigger, write records using IAsyncCollector

-# [Isolated process](#tab/isolated-process)

-### HTTP trigger, write one record

-### HTTP trigger, write records with mapping

-It is also possible to use an `out` parameter to accomplish the same thing:

-Starting in version 3.3.0, it is possible to use Azure Active Directory when authenticating the output binding:

-When using the Connection property, the `topicEndpointUri` must be specified as a child of the connection setting, and the `TopicEndpointUri` and `TopicKeySetting` properties should not be used. For local development, use the local.settings.json file to store the connection information:

-When deployed, use the application settings to store this information.

-## Authenticating the Event Grid output binding

-TypeScript samples are not documented for model v3.

-> Make sure that you set the value of the `TopicEndpointUri` configuration property to the name of an app setting that contains the URI of the custom topic. Don't specify the URI of the custom topic directly in this property.

-+ [Azure.Messaging.EventGrid][EventGridEvent2]

-[EventGridEvent]: /dotnet/api/azure.messaging.eventgrid.eventgridevent

-description: How to use geographical regions for redundancy and to fail over in Azure Functions.

-# Azure Functions geo-disaster recovery

-When entire Azure regions or datacenters experience downtime, your mission-critical code needs to continue processing in a different region. This article explains some of the strategies that you can use to deploy functions to allow for disaster recovery.

-## Basic concepts

-Functions run in a function app in a specific Azure region. There's no built-in redundancy available. To avoid loss of execution during outages, you can redundantly deploy the same functions to function apps in multiple regions.

-When you run the same function code in multiple regions, there are two patterns to consider:

-| Pattern | Description |

-| | |

-|**Active/active** | Functions in both regions are actively running and processing events, either in a duplicate manner or in rotation. We recommend using an active/active pattern in combination with [Azure Front Door](../frontdoor/front-door-overview.md) for your critical HTTP triggered functions. |

-|**Active/passive** | Functions run actively in region receiving events, while the same functions in a second region remain idle. When failover is required, the second region is activated and takes over processing. We recommend this pattern for your event-driven, non-HTTP triggered functions, such as Service Bus and Event Hubs triggered functions.

-To learn more about multi-region deployments, see the guidance in [Highly available multi-region web application](/azure/architecture/reference-architectures/app-service-web-app/multi-region).

-## Redundancy for HTTP trigger functions

-The active/active pattern is the best deployment model for HTTP trigger functions. In this case, you need to use [Azure Front Door](../frontdoor/front-door-overview.md) to coordinate requests between both regions. Azure Front Door can route and round-robin HTTP requests between functions running in multiple regions. It also periodically checks the health of each endpoint. When a function in one region stops responding to health checks, Azure Front Door takes it out of rotation, and only forwards traffic to the remaining healthy functions.

-

-## Redundancy for non-HTTP trigger functions

-Redundancy for functions that consume events from other services requires a different pattern, which works with the failover pattern of the related services.

-### Active/passive redundancy for non-HTTP trigger functions

-Active/passive provides a way for only a single function to process each message while providing a mechanism to fail over to a secondary region in a disaster. Function apps work with the failover behaviors of the partner services, such as [Azure Service Bus geo-recovery](../service-bus-messaging/service-bus-geo-dr.md) and [Azure Event Hubs geo-recovery](../event-hubs/event-hubs-geo-dr.md). The secondary function app is considered _passive_ because the failover service to which it's connected isn't currently active, so the function app remains _idle_.

-Consider an example topology using an Azure Event Hubs trigger. In this case, the active/passive pattern requires involve the following components:

-* Azure Event Hubs deployed to both a primary and secondary region.

-* [Geo-disaster enabled](../service-bus-messaging/service-bus-geo-dr.md) to pair the primary and secondary event hubs. This also creates an _alias_ you can use to connect to event hubs and switch from primary to secondary without changing the connection info.

-* Function apps are deployed to both the primary and secondary (failover) region, with the app in the secondary region essentially being idle because messages aren't being sent there.

-* Function app triggers on the *direct* (non-alias) connection string for its respective event hub.

-* Publishers to the event hub should publish to the alias connection string.

-

-Before failover, publishers sending to the shared alias route to the primary event hub. The primary function app is listening exclusively to the primary event hub. The secondary function app is passive and idle. As soon as failover is initiated, publishers sending to the shared alias are routed to the secondary event hub. The secondary function app now becomes active and starts triggering automatically. Effective failover to a secondary region can be driven entirely from the event hub, with the functions becoming active only when the respective event hub is active.

-Read more on information and considerations for failover with [Service Bus](../service-bus-messaging/service-bus-geo-dr.md) and [Event Hubs](../event-hubs/event-hubs-geo-dr.md).

-### Active/active redundancy for non-HTTP trigger functions

-You can still achieve active/active deployments for non-HTTP triggered functions. However, you need to consider how the two active regions interact or coordinate with one another. When you deploy the same function app to two regions with each triggering on the same Service Bus queue, they would act as competing consumers on de-queueing that queue. While this means each message is only being processed by either one of the instances, it also means there's still a single point of failure on the single Service Bus instance.

-You could instead deploy two Service Bus queues, with one in a primary region, one in a secondary region. In this case, you could have two function apps, with each pointed to the Service Bus queue active in their region. The challenge with this topology is how the queue messages are distributed between the two regions. Often, this means that each publisher attempts to publish a message to *both* regions, and each message is processed by both active function apps. While this creates the desired active/active pattern, it also creates other challenges around duplication of compute and when or how data is consolidated. Because of these challenges, we recommend using the active/passive pattern for non-HTTPS trigger functions.

-## Next steps

-* [Create Azure Front Door](../frontdoor/quickstart-create-front-door.md)

-* [Event Hubs failover considerations](../event-hubs/event-hubs-geo-dr.md#considerations)

-### [In-process model](#tab/in-process)

-### [Isolated worker model](#tab/isolated-worker)

-### Data service

-Data is imperative for maps. Use the Data service to upload and store geospatial data for use with spatial operations or image composition. By bringing customer data closer to the Azure Maps service, you reduce latency and increase productivity. For more information on this service, see [Data service].

-[Data service]: /rest/api/maps/data-v2

-| Data service | 50 | 50 | Not Available |

-Use the Azure Maps [Data service] to store and render overlays.

-5. Enter the following URL (replace {`Your-Azure-Maps-Subscription-key}` with your Azure Maps subscription key):

-## Upload pins and path data

-> [!NOTE]

-> The procedure in this section requires an Azure Maps account Gen1 (S1) or Gen2 pricing tier.

-In this section, you upload path and pin data to Azure Map data storage.

-To upload pins and path data:

-1. In the Postman app, select **New**.

-2. In the **Create New** window, select **HTTP Request**.

-3. Enter a **Request name** for the request, such as *POST Path and Pin Data*.

-4. Select the **POST** HTTP method.

-5. Enter the following URL (replace {`Your-Azure-Maps-Subscription-key}` with your Azure Maps subscription key):

- ```HTTP

- https://us.atlas.microsoft.com/mapData?subscription-key={Your-Azure-Maps-Subscription-key}&api-version=2.0&dataFormat=geojson

- ```

-6. Select the **Body** tab.

-7. In the dropdown lists, select **raw** and **JSON**.

-8. Copy the following JSON data as data to be uploaded, and then paste them in the **Body** window:

-

- ```JSON

- {

- "type": "FeatureCollection",

- "features": [

- {

- "type": "Feature",

- "properties": {},

- "geometry": {

- "type": "Polygon",

- "coordinates": [

- [

- [

- -73.98235,

- 40.76799

- ],

- [

- -73.95785,

- 40.80044

- ],

- [

- -73.94928,

- 40.7968

- ],

- [

- -73.97317,

- 40.76437

- ],

- [

- -73.98235,

- 40.76799

- ]

- ]

- ]

- }

- },

- {

- "type": "Feature",

- "properties": {},

- "geometry": {

- "type": "LineString",

- "coordinates": [

- [

- -73.97624731063843,

- 40.76560773817073

- ],

- [

- -73.97914409637451,

- 40.766826609362575

- ],

- [

- -73.98513078689575,

- 40.7585866048861

- ]

- ]

- }

- }

- ]

- }

- ```

-9. Select **Send**.

-10. In the response window, select the **Headers** tab.

-11. Copy the value of the **Operation-Location** key, which is the `status URL`. We'll use the `status URL` to check the status of the upload request in the next section. The `status URL` has the following format:

- ```HTTP

- https://us.atlas.microsoft.com/mapData/operations/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx?api-version=2.0

- ```

->[!TIP]

->To obtain your own path and pin location information, use [Data Upload].

-### Check pins and path data upload status

-To check the status of the data upload and retrieve its unique ID (`udid`):

-1. In the Postman app, select **New**.

-2. In the **Create New** window, select **HTTP Request**.

-3. Enter a **Request name** for the request, such as *GET Data Upload Status*.

-4. Select the **GET** HTTP method.

-5. Enter the `status URL` you copied in [Upload pins and path data](#upload-pins-and-path-data). The request should look like the following URL (replace {`Your-Azure-Maps-Subscription-key}` with your Azure Maps subscription key):

- ```HTTP

- https://us.atlas.microsoft.com/mapData/operations/{statusUrl}?api-version=2.0&subscription-key={Your-Azure-Maps-Subscription-key}

- ```

-6. Select **Send**.

-7. In the response window, select the **Headers** tab.

-8. Copy the value of the **Resource-Location** key, which is the `resource location URL`. The `resource location URL` contains the unique identifier (`udid`) of the drawing package resource.

- :::image type="content" source="./media/how-to-render-custom-data/resource-location-url.png" alt-text="Copy the resource location URL.":::

-### Render uploaded features on the map

-To render the uploaded pins and path data on the map:

-1. In the Postman app, select **New**.

-2. In the **Create New** window, select **HTTP Request**.

-3. Enter a **Request name** for the request, such as *GET Data Upload Status*.

-4. Select the **GET** HTTP method.

-5. Enter the following URL to the [Render service] (replace {`Your-Azure-Maps-Subscription-key}` with your Azure Maps subscription key and `udid` with the `udid` of the uploaded data):

- ```HTTP

- https://atlas.microsoft.com/map/static/png?subscription-key={Your-Azure-Maps-Subscription-key}&api-version=1.0&layer=basic&style=main&zoom=12&center=-73.96682739257812%2C40.78119135317995&pins=default|la-35+50|ls12|lc003C62|co9B2F15||'Times Square'-73.98516297340393 40.758781646381024|'Central Park'-73.96682739257812 40.78119135317995&path=lc0000FF|fc0000FF|lw3|la0.80|fa0.30||udid-{udId}

- ```

-6. The service returns the following image:

- :::image type="content" source="./media/how-to-render-custom-data/uploaded-path.png" alt-text="Render uploaded data in static map image.":::

-5. Enter the following URL to the [Render service] (replace {`Your-Azure-Maps-Subscription-key}` with your Azure Maps subscription key):

-5. Enter the following URL to the [Render service] (replace {`Your-Azure-Maps-Subscription-key}` with your Azure Maps subscription key):

-> [!div class="nextstepaction"]

-> [Data service]

-[Data service]: /rest/api/maps/data

-[Data Upload]: /rest/api/maps/data-v2/upload

-[Manage the pricing tier of your Azure Maps account]: how-to-manage-pricing-tier.md

-* `{udid}` ΓÇô A Unique Data ID (UDID) for an icon stored in the Azure Maps Data Storage platform.

-When it comes to path locations, Azure Maps requires the coordinates to be in `longitude latitude` format whereas Bing Maps uses `latitude,longitude` format. Also note that **there is a space, not a comma separating** longitude and latitude in Azure Maps. Azure Maps doesn't support encoded paths currently. Larger data sets can be uploaded as a GeoJSON fills into the Azure Maps Data Storage API. For more information, see [Upload pins and path data](./how-to-render-custom-data.md#upload-pins-and-path-data).

-* `{udid}` ΓÇô A Unique Data ID (UDID) for an icon stored in the Azure

- Maps Data Storage platform.

-When it comes to path locations, Azure Maps requires the coordinates to be in "longitude latitude" format. Google Maps uses "latitude,longitude" format. A space, not a comma, separates longitude and latitude in the Azure Maps format. Azure Maps doesn't support encoded paths or addresses for points. For more information on how to Upload larger data sets as a GeoJSON file into the Azure Maps Data Storage API, see [Upload pins and path data].

-[Upload pins and path data]: how-to-render-custom-data.md#upload-pins-and-path-data

-[Data Upload API]: /rest/api/maps/data-v2/upload

-[Data Upload]: /rest/api/maps/data-v2/upload

-| [Data v1]<br>[Data v2]<br>[Data registry] | Yes, except for `MapDataStorageService.GetDataStatus` and `MapDataStorageService.GetUserData`, which are nonbillable| One request = 1 transaction| <ul><li>Location Insights Data (Gen2 pricing)</li></ul>|

-[Data v1]: /rest/api/maps/data

-[Data v2]: /rest/api/maps/data-v2

-A rule gets created and stored in a particular region and is backed up to the [paired-region](../../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) within the same geography. The service is deployed to all three [availability zones](../../availability-zones/az-overview.md#availability-zones) within the region. For this reason, it's a *zone-redundant service*, which further increases availability.

-Azure NetApp Files volume replication is supported between various [Azure regional pairs](../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) and non-standard pairs. Azure NetApp Files volume replication is currently available between the following regions. You can replicate Azure NetApp Files volumes from Regional Pair A to Regional Pair B, and vice versa.

- az resourcemanagement private-link create --location WestUS --resource-group PrivateLinkTestRG --name NewRMPL --public-network-access enabled

-To learn more about private links, see [Azure Private Link](../../private-link/index.yml).

-description: Learn about key aspects and use cases of networking and interconnectivity in Azure VMware Solution.

-There are two ways to interconnectivity in the Azure VMware Solution private cloud:

-

-This article covers the key concepts that establish networking and interconnectivity, including requirements and limitations. In addition, this article provides you with the information you need to know to work with Azure VMware Solution to configure your networking.

-You can interconnect your Azure virtual network with the Azure VMware Solution private cloud implementation. You can manage your Azure VMware Solution private cloud, consume workloads in your private cloud, and access other Azure services.

-The diagram below shows the basic network interconnectivity established at the time of a private cloud deployment. It shows the logical networking between a virtual network in Azure and a private cloud. This connectivity is established via a backend ExpressRoute that is part of the Azure VMware Solution service. The interconnectivity fulfills the following primary use cases:

-> When connecting **production** Azure VMware Solution private clouds to an Azure virtual network, an ExpressRoute virtual network gateway with the Ultra Performance Gateway SKU should be used with FastPath enabled to achieve 10Gbps connectivity. Less critical environments can use the Standard or High Performance Gateway SKUs for slower network performance.

-> If connecting more than four Azure VMware Solution private clouds in the same Azure region to the same Azure virtual network is a requirement, use [AVS Interconnect](connect-multiple-private-clouds-same-region.md) to aggregate private cloud connectivity within the Azure region.

-In the fully interconnected scenario, you can access the Azure VMware Solution from your Azure virtual network(s) and on-premises. This implementation is an extension of the basic implementation described in the previous section. An ExpressRoute circuit is required to connect from on-premises to your Azure VMware Solution private cloud in Azure.

-The diagram below shows the on-premises to private cloud interconnectivity, which enables the following use cases:

-For full interconnectivity to your private cloud, you need to enable ExpressRoute Global Reach and then request an authorization key and private peering ID for Global Reach in the Azure portal. The authorization key and peering ID are used to establish Global Reach between an ExpressRoute circuit in your subscription and the ExpressRoute circuit for your private cloud. Once linked, the two ExpressRoute circuits route network traffic between your on-premises environments to your private cloud. For more information on the procedures, see the [tutorial for creating an ExpressRoute Global Reach peering to a private cloud](tutorial-expressroute-global-reach-private-cloud.md).

-> Customers should not advertise bogon routes over ExpressRoute from on-premises or their Azure VNet. Examples of bogon routes include 0.0.0.0/5 or 192.0.0.0/3.

- You need to follow these guidelines while advertising routes from your on-premises and Azure VNET to Azure VMware Solution over ExpressRoute:

-Now that you've covered Azure VMware Solution network and interconnectivity concepts, you may want to learn about:

-description: Learn about the key capabilities of Azure VMware Solution software-defined data centers and VMware vSphere clusters.

-Azure VMware Solution delivers VMware-based private clouds in Azure. The private cloud hardware and software deployments are fully integrated and automated in Azure. You deploy and manage the private cloud through the Azure portal, CLI, or PowerShell.

-As with other resources, private clouds are installed and managed from within an Azure subscription. The number of private clouds within a subscription is scalable. Initially, there's a limit of one private cloud per subscription. There's a logical relationship between Azure subscriptions, Azure VMware Solution private clouds, vSAN clusters, and hosts.

-The diagram below describes the architectural components of the Azure VMware Solution.

-Host remediation involves replacing the faulty node with a new healthy node in the cluster. Then, when possible, the faulty host is placed in VMware vSphere maintenance mode. VMware vMotion moves the VMs off the faulty host to other available servers in the cluster, potentially allowing zero downtime for live migration of workloads. If the faulty host can't be placed in maintenance mode, the host is removed from the cluster. Before the faulty host is removed, the customer workloads will be migrated to a newly added host.

-Azure VMware Solution monitors the following conditions on the host:

-Private cloud vCenter Server and NSX-T Data Center configurations are on an hourly backup schedule. Backups are kept for three days. If you need to restore from a backup, open a [support request](https://rc.portal.azure.com/#create/Microsoft.Support) in the Azure portal to request restoration.

-Now that you've covered Azure VMware Solution private cloud concepts, you may want to learn about:

-description: Learn how to configure Active Directory over LDAP or LDAPS for vCenter Server as an external identity source.

->[!NOTE]

->Run commands are executed one at a time in the order submitted.

-In this article, you learn how to:

-> * Assign additional vCenter Server Roles to Active Directory Identities

->[!NOTE]

->[Export the certificate for LDAPS authentication](#optional-export-the-certificate-for-ldaps-authentication) and [Upload the LDAPS certificate to blob storage and generate a SAS URL](#optional-upload-the-ldaps-certificate-to-blob-storage-and-generate-a-sas-url) are optional steps as now the certificate(s) will be downloaded from the domain controller(s) automatically through the parameter(s) **PrimaryUrl** and/or **SecondaryUrl** if the parameter **SSLCertificatesSasUrl** is not provided. You can still provide **SSLCertificatesSasUrl** and follow the optional steps to manually export and upload the certificate(s).

- - You'll need access to the Active Directory Domain Controller(s) with Administrator permissions.

- - Your Active Directory Domain Controller(s) must have LDAPS enabled with a valid certificate. The certificate could be issued by an [Active Directory Certificate Services Certificate Authority (CA)](https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx) or a [Third-party/Public CA](/troubleshoot/windows-server/identity/enable-ldap-over-ssl-3rd-certification-authority).

- - You need to have a valid certificate. To create a certificate, follow the steps shown in [create a certificate for secure LDAP](../active-directory-domain-services/tutorial-configure-ldaps.md#create-a-certificate-for-secure-ldap). Make sure the certificate meets the requirements that are listed after the steps you used to create a certificate for secure LDAP.

- >[!NOTE]

- >Self-sign certificates are not recommended for production environments.

- - Optional: The certificate(s) will be downloaded from the domain controller(s) automatically through the parameter(s) **PrimaryUrl** and/or **SecondaryUrl** if the parameter **SSLCertificatesSasUrl** is not provided. If you prefer to manually export and upload the certificate(s), please [export the certificate for LDAPS authentication](#optional-export-the-certificate-for-ldaps-authentication) and upload it to an Azure Storage account as blob storage. Then, you'll need to [grant access to Azure Storage resources using shared access signature (SAS)](../storage/common/storage-sas-overview.md).

->[!NOTE]

->For more information about LDAPS and certificate issuance, see with your security or identity management team.

-First, verify that the certificate used for LDAPS is valid. If you don't already have a certificate, follow the steps to [create a certificate for secure LDAP](../active-directory-domain-services/tutorial-configure-ldaps.md#create-a-certificate-for-secure-ldap) before you continue.

-1. Open the **Run command**, type **mmc** and select the **OK** button.

-1. Select the **File** menu option then **Add/Remove Snap-in**.

-1. Select the **Certificates** in the list of Snap-ins and select the **Add>** button.

-1. In the **Certificates snap-in** window, select **Computer account** then select **Next**.

-1. Keep the first option selected **Local computer...** , and select **Finish**, and then **OK**.

-1. Expand the **Personal** folder under the **Certificates (Local Computer)** management console and select the **Certificates** folder to list the installed certificates.

- :::image type="content" source="media/run-command/ldaps-certificate-personal-certficates.png" alt-text="Screenshot showing displaying the list of certificates." lightbox="media/run-command/ldaps-certificate-personal-certficates.png":::

-1. Double click the certificate for LDAPS purposes. The **Certificate** General properties will display. Ensure the certificate date **Valid from** and **to** is current and the certificate has a **private key** that corresponds to the certificate.

- :::image type="content" source="media/run-command/ldaps-certificate-personal-general.png" alt-text="Screenshot showing the properties of the certificate." lightbox="media/run-command/ldaps-certificate-personal-general.png":::

-1. On the same window, select the **Certification Path** tab and verify that the **Certification path** is valid, which it should include the certificate chain of root CA and optionally intermediate certificates and the **Certificate Status** is OK.

- :::image type="content" source="media/run-command/ldaps-certificate-cert-path.png" alt-text="Screenshot showing the certificate chain." lightbox="media/run-command/ldaps-certificate-cert-path.png":::

-Now proceed to export the certificate

-1. Still on the Certificates console, right select the LDAPS certificate and select **All Tasks** > **Export**. The Certificate Export Wizard prompt is displayed, select the **Next** button.

-1. In the **Export Private Key** section, select the second option, **No, do not export the private key** and select the **Next** button.

-1. In the **Export File Format** section, select the second option, **Base-64 encoded X.509(.CER)** and then select the **Next** button.

-1. In the **File to Export** section, select the **Browse...** button and select a folder location where to export the certificate, enter a name then select the **Save** button.

->[!NOTE]

->If more than one domain controller is LDAPS enabled, repeat the export procedure in the additional domain controller(s) to also export the corresponding certificate(s). Be aware that you can only reference two LDAPS server in the `New-LDAPSIdentitySource` Run Command. If the certificate is a wildcard certificate, for example ***.avsdemo.net** you only need to export the certificate from one of the domain controllers.

-> Make sure to copy each SAS URL string(s), because they will no longer be available once you leave the page.

-> Another alternative method for consolidating certificates is saving the certificate chains in a single file as mentioned in [this VMware KB article](https://kb.vmware.com/s/article/2041378), and generate a single SAS URL for the file that contains all the certificates.

-## Configure NSX-T DNS for resolution to your Active Directory Domain

-A DNS Zone needs to be created and added to the DNS Service, follow the instructions in [Configure a DNS forwarder in the Azure portal](./configure-dns-azure-vmware-solution.md) to complete these two steps.

-After completion, verify that your DNS Service has your DNS zone included.

- :::image type="content" source="media/run-command/ldaps-dns-zone-service-configured.png" alt-text="Screenshot showing the DNS Service that includes the required DNS zone." lightbox="media/run-command/ldaps-dns-zone-service-configured.png":::

-Your Azure VMware Solution Private cloud should now be able to resolve your on-premises Active Directory domain name properly.

-In your Azure VMware Solution private cloud, you'll run the `New-LDAPSIdentitySource` cmdlet to add an AD over LDAP with SSL as an external identity source to use with SSO into vCenter Server.

-1. Browse to your Azure VMware Solution private cloud and then select **Run command** > **Packages** > **New-LDAPSIdentitySource**.

-1. Provide the required values or change the default values, and then select **Run**.

- | **GroupName** | The group in the external identity source that gives the cloudadmin access. For example, **avs-admins**. |

- | **SSLCertificatesSasUrl** | Path to SAS strings with the certificates for authentication to the AD source. If you're using multiple certificates, separate each SAS string with a comma. For example, **pathtocert1,pathtocert2**. |

- | **Credential** | The domain username and password used for authentication with the AD source (not cloudadmin). The user must be in the **username@avslab.local** format. |

- | **BaseDNGroups** | Where to look for groups, for example, **CN=group1, DC=avsldap,DC=local**. Base DN is needed to use LDAP Authentication. |

- | **BaseDNUsers** | Where to look for valid users, for example, **CN=users,DC=avsldap,DC=local**. Base DN is needed to use LDAP Authentication. |

- | **PrimaryUrl** | Primary URL of the external identity source, for example, **ldaps://yourserver.avslab.local.:636**. |

- | **SecondaryURL** | Secondary fall-back URL if there's primary failure. For example, **ldaps://yourbackupldapserver.avslab.local:636**. |

- | **DomainAlias** | For Active Directory identity sources, the domain's NetBIOS name. Add the NetBIOS name of the AD domain as an alias of the identity source. Typically the **avsldap\** format. |

- | **DomainName** | The FQDN of the domain, for example **avslab.local**. |

- | **Name** | User-friendly name of the external identity source. For example, **avslab.local**, is how it will be displayed in vCenter. |

- | **Specify name for execution** | Alphanumeric name, for example, **addexternalIdentity**. |

- | **Timeout** | The period after which a cmdlet exits if taking too long to finish. |

-1. Check **Notifications** or the **Run Execution Status** pane to see the progress and successful completion.

->[!NOTE]

->We recommend you use the [Add Active Directory over LDAP with SSL](#add-active-directory-over-ldap-with-ssl) method.

-You'll run the `New-LDAPIdentitySource` cmdlet to add AD over LDAP as an external identity source to use with SSO into vCenter Server.

-1. Provide the required values or change the default values, and then select **Run**.

- | **Name** | User-friendly name of the external identity source, for example, **avslab.local**. This is how it will be displayed in vCenter. |

- | **DomainName** | The FQDN of the domain, for example **avslab.local**. |

- | **DomainAlias** | For Active Directory identity sources, the domain's NetBIOS name. Add the NetBIOS name of the AD domain as an alias of the identity source. Typically the **avsldap\** format. |

- | **PrimaryUrl** | Primary URL of the external identity source, for example, **ldap://yourserver.avslab.local:389**. |

- | **SecondaryURL** | Secondary fall-back URL if there's primary failure. |

- | **BaseDNUsers** | Where to look for valid users, for example, **CN=users,DC=avslab,DC=local**. Base DN is needed to use LDAP Authentication. |

- | **BaseDNGroups** | Where to look for groups, for example, **CN=group1, DC=avslab,DC=local**. Base DN is needed to use LDAP Authentication. |

- | **Credential** | The domain username and password used for authentication with the AD source (not cloudadmin). The user must be in the **username@avslab.local** format. |

- | **GroupName** | The group to give cloudadmin access in your external identity source, for example, **avs-admins**. |

- | **Retain up to** | Retention period of the cmdlet output. The default value is 60 days. |

- | **Specify name for execution** | Alphanumeric name, for example, **addexternalIdentity**. |

- | **Timeout** | The period after which a cmdlet exits if taking too long to finish. |

-1. Check **Notifications** or the **Run Execution Status** pane to see the progress.

-## Add existing AD group to cloudadmin group

-> Nested groups are not supported, and their use may cause loss of access.

-You'll run the `Add-GroupToCloudAdmins` cmdlet to add an existing AD group to a cloudadmin group. Users in the cloudadmin group have privileges equal to the cloudadmin (cloudadmin@vsphere.local) role defined in vCenter Server SSO.

- | **GroupName** | Name of the group to add, for example, **VcAdminGroup**. |

- | **Specify name for execution** | Alphanumeric name, for example, **addADgroup**. |

-## List external identity

-You'll run the `Get-ExternalIdentitySources` cmdlet to list all external identity sources already integrated with vCenter Server SSO.

- :::image type="content" source="media/run-command/run-command-overview.png" alt-text="Screenshot showing how to access the run commands available." lightbox="media/run-command/run-command-overview.png":::

- :::image type="content" source="media/run-command/run-command-get-external-identity-sources.png" alt-text="Screenshot showing how to list external identity source. ":::

- | **Specify name for execution** | Alphanumeric name, for example, **getExternalIdentity**. |

- :::image type="content" source="media/run-command/run-packages-execution-command-status.png" alt-text="Screenshot showing how to check the run commands notification or status." lightbox="media/run-command/run-packages-execution-command-status.png":::

-## Assign more vCenter Server Roles to Active Directory Identities

-After you've added an external identity over LDAP or LDAPS, you can assign vCenter Server Roles to Active Directory security groups based on your organization's security controls.

-1. After you sign in to vCenter Server with cloudadmin privileges, you can select an item from the inventory, select **ACTIONS** menu and select **Add Permission**.

- :::image type="content" source="media/run-command/ldaps-vcenter-permission-assignment-1.png" alt-text="Screenshot displaying hot to add permission assignment." lightbox="media/run-command/ldaps-vcenter-permission-assignment-1.png":::

- 1. *Domain*. Select the Active Directory that was added previously.

- 1. *User/Group*. Enter the name of the desired user or group to find then select once is found.

- 1. *Role*. Select the desired role to assign.

- 1. *Propagate to children*. Optionally select the checkbox if permissions should be propagated down to children resources.

- :::image type="content" source="media/run-command/ldaps-vcenter-permission-assignment-2.png" alt-text="Screenshot displaying assign the permission." lightbox="media/run-command/ldaps-vcenter-permission-assignment-3.png":::

- :::image type="content" source="media/run-command/ldaps-vcenter-permission-assignment-3.png" alt-text="Screenshot displaying the add completion of permission assignment." lightbox="media/run-command/ldaps-vcenter-permission-assignment-3.png":::

-1. Users should now be able to sign in to vCenter Server using their Active Directory credentials.

-You'll run the `Remove-GroupFromCloudAdmins` cmdlet to remove a specified AD group from the cloudadmin role.

-1. Provide the required values or change the default values, and then select **Run**.

- | **GroupName** | Name of the group to remove, for example, **VcAdminGroup**. |

- | **Specify name for execution** | Alphanumeric name, for example, **removeADgroup**. |

-You'll run the `Remove-ExternalIdentitySources` cmdlet to remove all existing external identity sources in bulk.

-1. Provide the required values or change the default values, and then select **Run**.

- | **Specify name for execution** | Alphanumeric name, for example, **remove_externalIdentity**. |

-1. Rotate the password of account used for authentication with the AD source in the domain controller.

- | **DomainName** | The FQDN of the domain, for example **avslab.local**. |

-> If you do not provide a DomainName, all external identity sources will be removed. The command **Update-IdentitySourceCredential** should be run only after the password is rotated in the domain controller.

-Now that you've learned about how to configure LDAP and LDAPS, you can learn more about:

-description: Configure the on-premises VMware HCX Connector for your Azure VMware Solution private cloud.

-Once you've [installed the VMware HCX add-on](install-vmware-hcx.md), you're ready to configure the on-premises VMware HCX Connector for your Azure VMware Solution private cloud.

-In this tutorial, you'll learn how to do the following tasks:

-* Pair your on-premises VMware HCX Connector with your Azure VMware Solution HCX Cloud Manager

-* Configure the network profile, compute profile, and service mesh

-* Check the appliance status and validate that migration is possible

-After you complete these steps, you'll have a production-ready environment for creating virtual machines (VMs) and migration.

- - NSX-T Data Center or vSphere Distributed Switch (vDS) on-premises for HCX Network Extension (vSphere Standard Switch not supported)

- - One or more active stretched network segments

-In your data center, you can connect or pair the VMware HCX Cloud Manager in Azure VMware Solution with the VMware HCX Connector.

-> As per the [Azure VMware Solution limits](/azure/azure-resource-manager/management/azure-subscription-service-limits#azure-vmware-solution-limits) the maximum site pairs is 25 and maximum service meshes is 10 in a single HCX manager system, this includes inbound and outbound site pairings.

-1. Under **Infrastructure**, select **Site Pairing** and select the **Connect To Remote Site** option (in the middle of the screen).

-1. Enter the Azure VMware Solution HCX Cloud Manager URL or IP address that you noted earlier `https://x.x.x.9` and the credentials for a user that holds the CloudAdmin role in your private cloud. Then select **Connect**.

- You'll see a screen showing that your VMware HCX Cloud Manager in Azure VMware Solution and your on-premises VMware HCX Connector are connected (paired).

- :::image type="content" source="media/tutorial-vmware-hcx/site-pairing-complete.png" alt-text="Screenshot showing the site pairing of the HCX Manager in Azure VMware Solution and the VMware HCX Connector.":::

-VMware HCX Connector deploys a subset of virtual appliances (automated) that requires multiple IP segments. When you create your network profiles, you use the IP segments you identified during the [planning phase](plan-private-cloud-deployment.md#define-vmware-hcx-network-segments). You'll create four network profiles:

- > * Azure VMware Solution connected via VPN should set Uplink Network Profile MTU's to 1350 to account for IPSec overhead.

- > * Azure VMWare Solution defaults to 1500 MTU and is sufficient for most ExpressRoute implementations.

- > * If your ExpressRoute provider does not support jumbo frame, MTU may need to be lowered in ExpressRoute setups as well.

- > * Changes to MTU should be performed on both HCX Connector (on-premises) and HCX Cloud Manager (Azure VMware Solution) network profiles.

- :::image type="content" source="media/tutorial-vmware-hcx/example-configurations-network-profile.png" alt-text="Screenshot showing the details for a new network profile." lightbox="media/tutorial-vmware-hcx/example-configurations-network-profile.png":::

-For an end-to-end overview of this procedure, view the [Azure VMware Solution: HCX Network Profile](https://www.youtube.com/embed/O0rU4jtXUxc) video.

- :::image type="content" source="media/tutorial-vmware-hcx/compute-profile-create.png" alt-text="Screenshot that shows the selections for starting to create a compute profile." lightbox="media/tutorial-vmware-hcx/compute-profile-create.png":::

- :::image type="content" source="media/tutorial-vmware-hcx/name-compute-profile.png" alt-text="Screenshot that shows the entry of a compute profile name and the Continue button." lightbox="media/tutorial-vmware-hcx/name-compute-profile.png":::

- :::image type="content" source="media/tutorial-vmware-hcx/select-service-resource.png" alt-text="Screenshot that shows selected service resources and the Continue button." lightbox="media/tutorial-vmware-hcx/select-service-resource.png":::

- :::image type="content" source="media/tutorial-vmware-hcx/deployment-resources-and-reservations.png" alt-text="Screenshot that shows a selected data storage resource and the Continue button." lightbox="media/tutorial-vmware-hcx/deployment-resources-and-reservations.png":::

- :::image type="content" source="media/tutorial-vmware-hcx/select-management-network-profile.png" alt-text="Screenshot that shows the selection of a management network profile and the Continue button." lightbox="media/tutorial-vmware-hcx/select-management-network-profile.png":::

- :::image type="content" source="media/tutorial-vmware-hcx/select-uplink-network-profile.png" alt-text="Screenshot that shows the selection of an uplink network profile and the Continue button." lightbox="media/tutorial-vmware-hcx/select-uplink-network-profile.png":::

- :::image type="content" source="media/tutorial-vmware-hcx/select-vmotion-network-profile.png" alt-text="Screenshot that shows the selection of a vMotion network profile and the Continue button." lightbox="media/tutorial-vmware-hcx/select-vmotion-network-profile.png":::

- :::image type="content" source="media/tutorial-vmware-hcx/select-replication-network-profile.png" alt-text="Screenshot that shows the selection of a replication network profile and the Continue button." lightbox="media/tutorial-vmware-hcx/select-replication-network-profile.png":::

- > If you are not migrating virtual machines on layer-2 (L2) extended networks, you can skip this step.

- :::image type="content" source="media/tutorial-vmware-hcx/select-layer-2-distributed-virtual-switch.png" alt-text="Screenshot that shows the selection of distributed virtual switches and the Continue button." lightbox="media/tutorial-vmware-hcx/select-layer-2-distributed-virtual-switch.png":::

- :::image type="content" source="media/tutorial-vmware-hcx/review-connection-rules.png" alt-text="Screenshot that shows the connection rules and the Continue button." lightbox="media/tutorial-vmware-hcx/review-connection-rules.png":::

- :::image type="content" source="media/tutorial-vmware-hcx/compute-profile-done.png" alt-text="Screenshot that shows compute profile information." lightbox="media/tutorial-vmware-hcx/compute-profile-done.png":::

->[!IMPORTANT]

->Make sure port UDP 4500 is open between your on-premises VMware HCX Connector 'uplink' network profile addresses and the Azure VMware Solution HCX Cloud 'uplink' network profile addresses. (500 UDP was previously required in legacy versions of HCX. See https://ports.vmware.com for latest information)

- :::image type="content" source="media/tutorial-vmware-hcx/create-service-mesh.png" alt-text="Screenshot of selections to start creating a service mesh." lightbox="media/tutorial-vmware-hcx/create-service-mesh.png":::

- You can have up to eight VLANs per appliance, but you can deploy another appliance to add another eight VLANs. You must also have IP space to account for the more appliances, and it's one IP per appliance. For more information, see [VMware HCX Configuration Limits](https://configmax.vmware.com/guest?vmwareproduct=VMware%20HCX&release=VMware%20HCX&categories=41-0,42-0,43-0,44-0,45-0).

- :::image type="content" source="media/tutorial-vmware-hcx/monitor-service-mesh.png" alt-text="Screenshot that shows the button for viewing tasks.":::

- :::image type="content" source="media/tutorial-vmware-hcx/service-mesh-green.png" alt-text="Screenshot that shows green indicators on services." lightbox="media/tutorial-vmware-hcx/service-mesh-green.png":::

- :::image type="content" source="media/tutorial-vmware-hcx/interconnect-appliance-state.png" alt-text="Screenshot that shows selections for checking the status of the appliance." lightbox="media/tutorial-vmware-hcx/interconnect-appliance-state.png":::

- >After establishing the service mesh, you may notice a new datastore and a new host in your private cloud. This is perfectly normal behavior after establishing a service mesh.

- >:::image type="content" source="media/tutorial-vmware-hcx/hcx-service-mesh-datastore-host.png" alt-text="Screenshot showing the HCX service mesh datastore and host." lightbox="media/tutorial-vmware-hcx/hcx-service-mesh-datastore-host.png":::

-The HCX interconnect tunnel status should indicate **UP** and in green. You're ready to migrate and protect Azure VMware Solution VMs using VMware HCX. Azure VMware Solution supports workload migrations (with or without a network extension). So you can still migrate workloads in your vSphere environment, along with on-premises creation of networks and deployment of VMs onto those networks. For more information, see the [VMware HCX Documentation](https://docs.vmware.com/en/VMware-HCX/https://docsupdatetracker.net/index.html).

-For an end-to-end overview of this procedure, view the [Azure VMware Solution: Service Mesh](https://www.youtube.com/embed/COY3oIws108) video.

-Now that you've configured the HCX Connector, you can also learn about:

-description: Learn how to use the information gathered in the planning stage to deploy and configure the Azure VMware Solution private cloud.

-Once you've [planned your deployment](plan-private-cloud-deployment.md), you'll deploy and configure your Azure VMware Solution private cloud.

-In this how-to, you'll:

-> * Validate the network connect

-After you're finished, follow the recommended next steps at the end to continue with the steps of this getting started guide.

-You should have connectivity between the Azure Virtual Network where the ExpressRoute terminates and the Azure VMware Solution private cloud.

- 1. Navigate to a VM that is in the running state, and under **Settings**, select **Networking** and select the network interface resource.

- :::image type="content" source="../virtual-network/media/diagnose-network-routing-problem/view-nics.png" alt-text="Screenshot showing virtual network interface settings.":::

- 1. On the left, select **Effective routes**. You'll see a list of address prefixes that are contained within the `/22` CIDR block you entered during the deployment phase.

-1. If you want to log into both vCenter Server and NSX-T Manager, open a web browser and log into the same virtual machine used for network route validation.

- You can identify the vCenter Server and NSX-T Manager console's IP addresses and credentials in the Azure portal. Select your private cloud and then **Manage** > **VMware credentials**.

- :::image type="content" source="media/tutorial-access-private-cloud/ss4-display-identity.png" alt-text="Screenshot showing the private cloud vCenter and NSX Manager URLs and credentials." border="true":::

-description: Learn the features and benefits of Azure VMware Solution to deploy and manage VMware-based workloads in Azure. Azure VMware Solution SLA guarantees that Azure VMware management tools (vCenter Server and NSX Manager) will be available at least 99.9% of the time.

-Azure VMware Solution provides you with private clouds that contain VMware vSphere clusters built from dedicated bare-metal Azure infrastructure. Azure VMware Solution is available in Azure Commercial and in Azure Government. The minimum initial deployment is three hosts, but more hosts can be added, up to a maximum of 16 hosts per cluster. All provisioned private clouds have VMware vCenter Server, VMware vSAN, VMware vSphere, and VMware NSX-T Data Center. As a result, you can migrate workloads from your on-premises environments, deploy new virtual machines (VMs), and consume Azure services from your private clouds. For information about the SLA, see the [Azure service-level agreements](https://azure.microsoft.com/support/legal/sla/azure-vmware/v1_1/) page.

-Azure VMware Solution is a VMware validated solution with ongoing validation and testing of enhancements and upgrades. Microsoft manages and maintains the private cloud infrastructure and software. It allows you to focus on developing and running workloads in your private clouds to deliver business value.

- The new node sizes increase memory and storage options to optimize your workloads. The gains in performance enable you to do more per server, break storage bottlenecks, and lower transaction costs of latency-sensitive workloads. The availability of the new nodes allows for large latency-sensitive services to be hosted efficiently on the Azure VMware Solution infrastructure.

-Frequency of 2.7Ghz and Turbo of 4.0Ghz.

-## Data Residency and Customer Data

-Once youΓÇÖve deployed Azure VMware Solution into your subscription, [Azure Monitor logs](../azure-monitor/overview.md) are generated automatically.

-## Azure VMware Solution Responsibility Matrix - Microsoft vs Customer

-Azure VMware Solution implements a shared responsibility model that defines distinct roles and responsibilities of the two parties involved in the offering: Customer and Microsoft. The shared role responsibilities are illustrated in more detail in following two tables.

-The shared responsibility matrix table shows the high-level responsibilities between a customer and Microsoft for different aspects of the deployment and management of the private cloud and the customer application workloads.

-description: Learn how to plan your Azure VMware Solution deployment.

-Planning your Azure VMware Solution deployment is critical for a successful production-ready environment for creating virtual machines (VMs) and migration. During the planning process, you'll identify and gather what's needed for your deployment. As you plan, make sure to document the information you gather for easy reference during the deployment. A successful deployment results in a production-ready environment for creating virtual machines (VMs) and migration.

-In this how-to article, you'll do the following tasks:

-> * Request a host quota for eligible Azure plan

-Identify the subscription you plan to use to deploy Azure VMware Solution. You can create a new subscription or use an existing one.

->The subscription must be associated with a Microsoft Enterprise Agreement (EA), a Cloud Solution Provider (CSP) Azure plan or an Microsoft Customer Agreement (MCA). For more information, see [Eligibility criteria](request-host-quota-azure-vmware-solution.md#eligibility-criteria).

-Identify the resource group you want to use for your Azure VMware Solution. Generally, a resource group is created specifically for Azure VMware Solution, but you can use an existing resource group.

-The resource name is a friendly and descriptive name in which you title your Azure VMware Solution private cloud, for example, **MyPrivateCloud**.

-It's crucial to request a host quota early, so after you've finished the planning process, you're ready to deploy your Azure VMware Solution private cloud.

-Before requesting a host quota, make sure you've identified the Azure subscription, resource group, and region. Also, make sure you've identified the size hosts and determine the number of clusters and hosts you'll need.

-After the support team receives your request for a host quota, it takes up to five business days to confirm your request and allocate your hosts.

-Azure VMware Solution requires a /22 CIDR network, for example, `10.0.0.0/22`. This address space is carved into smaller network segments (subnets) and used for Azure VMware Solution management segments, including: vCenter Server, VMware HCX, NSX-T Data Center, and vMotion functionality. The diagram highlights Azure VMware Solution management IP address segments.

->[!IMPORTANT]

->The /22 CIDR network address block shouldn't overlap with any existing network segment you already have on-premises or in Azure. For details of how the /22 CIDR network is broken down per private cloud, see [Routing and subnet considerations](tutorial-network-checklist.md#routing-and-subnet-considerations).

-Like with any VMware vSphere environment, the VMs must connect to a network segment. As the production deployment of Azure VMware Solution expands, there's often a combination of L2 extended segments from on-premises and local NSX-T Data Center network segments.

-Azure VMware Solution requires an Azure Virtual Network and an ExpressRoute circuit. Define whether you want to use an *existing* OR *new* ExpressRoute virtual network gateway. If you decide to use a *new* virtual network gateway, you'll create it after creating your private cloud. It's acceptable to use an existing ExpressRoute virtual network gateway. For planning purposes, make a note of which ExpressRoute virtual network gateway you'll use.

-VMware HCX Connector deploys a subset of virtual appliances (automated) that require multiple IP segments. When you create your network profiles, you use the IP segments. Identify the following listed items for the VMware HCX deployment, which supports a pilot or small product use case. Depending on the needs of your migration, modify as necessary.

- >[!NOTE]

- >Preparing for large environments, instead of using the management network used for the on-premises VMware vSphere cluster, create a new /26 network and present that network as a port group to your on-premises VMware vSphere cluster. You can then create up to 10 service meshes and 60 network extenders (-1 per service mesh). You can stretch **eight** networks per network extender by using Azure VMware Solution private clouds.

-Optionally, you can extend network segments from on-premises to Azure VMware Solution. If you do extend network segments, identify those networks now following these guidelines:

-Now that you've gathered and documented the information needed, continue to the next tutorial to create your Azure VMware Solution private cloud.

-description: Learn how to create ExpressRoute Global Reach peering to a private cloud in Azure VMware Solution.

-After you deploy your Azure VMware Solution private cloud, you'll connect it to your on-premises environment. ExpressRoute Global Reach connects your on-premises environment to your Azure VMware Solution private cloud. The ExpressRoute Global Reach connection is established between the private cloud ExpressRoute circuit and an existing ExpressRoute connection to your on-premises environments.

-After you're finished, follow the recommended next steps at the end to continue with the steps of this getting started guide.

- :::image type="content" source="media/expressroute-global-reach/start-request-auth-key-on-premises-expressroute.png" alt-text="Select Authorizations and enter the name for the authorization key."lightbox="media/expressroute-global-reach/start-request-auth-key-on-premises-expressroute.png":::

- :::image type="content" source="./media/expressroute-global-reach/expressroute-global-reach-tab.png" alt-text="Screenshot showing the ExpressRoute Global Reach tab in the Azure VMware Solution private cloud." lightbox="./media/expressroute-global-reach/expressroute-global-reach-tab.png":::

- :::image type="content" source="./media/expressroute-global-reach/on-premises-cloud-connections.png" alt-text="Screenshot showing the dialog for entering the connection information." lightbox="./media/expressroute-global-reach/on-premises-cloud-connections.png":::

->:::image type="content" source="./media/expressroute-global-reach/on-premises-connection-disconnect.png" alt-text="Screenshot showing how to disconnect or delete an on-premises connection in Azure VMware Solution." lightbox="./media/expressroute-global-reach/on-premises-connection-disconnect.png":::

-<!-- LINKS - external-->

-<!-- LINKS - internal -->

-description: Learn about the network requirements for network connectivity and network ports on Azure VMware Solution.

-# Networking planning checklist for Azure VMware Solution

-Azure VMware Solution offers a VMware private cloud environment accessible for users and applications from on-premises and Azure-based environments or resources. The connectivity is delivered through networking services such as Azure ExpressRoute and VPN connections. It requires specific network address ranges and firewall ports to enable the services. This article provides you with the information you need to properly configure your networking to work with Azure VMware Solution.

-## Prerequisite

-Ensure that all gateways, including the ExpressRoute provider's service, supports 4-byte Autonomous System Number (ASN). Azure VMware Solution uses 4-byte public ASNs for advertising routes.

-> The ExpressRoute circuit is not part of a private cloud deployment. The on-premises ExpressRoute circuit is beyond the scope of this document. If you require on-premises connectivity to your private cloud, you can use one of your existing ExpressRoute circuits or purchase one in the Azure portal.

-When deploying a private cloud, you receive IP addresses for vCenter Server and NSX-T Manager. To access those management interfaces, you'll need to create more resources in your subscription's virtual network. You can find the procedures for creating those resources and establishing [ExpressRoute private peering](tutorial-expressroute-global-reach-private-cloud.md) in the tutorials.

-The private cloud logical networking comes with pre-provisioned NSX-T Data Center configuration. A Tier-0 gateway and Tier-1 gateway are pre-provisioned for you. You can create a segment and attach it to the existing Tier-1 gateway or attach it to a new Tier-1 gateway that you define. NSX-T Data Center logical networking components provide East-West connectivity between workloads and North-South connectivity to the internet and Azure services.

->[!INCLUDE [disk-pool-planning-note](includes/disk-pool-planning-note.md)]

-The Azure VMware Solution private cloud is connected to your Azure virtual network using an Azure ExpressRoute connection. This high bandwidth, low latency connection allows you to access services running in your Azure subscription from your private cloud environment. The routing is Border Gateway Protocol (BGP) based, automatically provisioned, and enabled by default for each private cloud deployment.

-Azure VMware Solution private clouds require a minimum of a `/22` CIDR network address block for subnets, shown below. This network complements your on-premises networks. Therefore, the address block shouldn't overlap with address blocks used in other virtual networks in your subscription and on-premises networks. Within this address block, management, provisioning, and vMotion networks get provisioned automatically.

->[!NOTE]

->Permitted ranges for your address block are the RFC 1918 private address spaces (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), except for 172.17.0.0/16.

->[!IMPORTANT]

->In addition, the following IP schemas are reserved for NSX-T Data Center usage and should not be used:

-Example `/22` CIDR network address block: `10.10.0.0/22`

-| Private cloud management | Management Network (i.e. vCenter, NSX-T) | `/26` | `10.10.0.0/26` |

-| HCX Uplink | Uplinks for HCX IX and NE appliances to remote peers | `/26` | `10.10.3.0/26` |

-| Reserved | Reserved | `/26` | `10.10.3.64/26` |

-| Reserved | Reserved | `/26` | `10.10.3.128/26` |

-| Reserved | Reserved | `/26` | `10.10.3.192/26` |

-| Private Cloud DNS server | On-premises DNS Server | UDP | 53 | DNS Client - Forward requests from Private Cloud vCenter Server for any on-premises DNS queries (check DNS section below) |

-| On-premises DNS Server | Private Cloud DNS server | UDP | 53 | DNS Client - Forward requests from on-premises services to Private Cloud DNS servers (check DNS section below) |

-| Private Cloud management network | On-premises Active Directory | TCP | 389/636 | These ports are open to allow communications for Azure VMware Solutions vCenter Server to communicate to any on-premises Active Directory/LDAP server(s). These port(s) are optional - for configuring on-premises AD as an identity source on the Private Cloud vCenter. Port 636 is recommended for security purposes. |

-| Private Cloud management network | On-premises Active Directory Global Catalog | TCP | 3268/3269 | These ports are open to allow communications for Azure VMware Solutions vCenter Server to communicate to any on-premises Active Directory/LDAP global catalog server(s). These port(s) are optional - for configuring on-premises AD as an identity source on the Private Cloud vCenter Server. Port 3269 is recommended for security purposes. |

-| On-premises network | Private Cloud vCenter Server | TCP (HTTPS) | 443 | This port allows you to access vCenter Server from an on-premises network. The default port that the vCenter Server system uses to listen for connections from the vSphere Client. To enable the vCenter Server system to receive data from the vSphere Client, open port 443 in the firewall. The vCenter Server system also uses port 443 to monitor data transfer from SDK clients. |

-| HCX Manager | Interconnect (HCX-IX) | TCP (HTTPS) | 8123 | HCX Bulk Migration Control |

-| Interconnect (HCX-IX), Network Extension (HCX-NE) at Source| Interconnect (HCX-IX), Network Extension (HCX-NE) at Destination| UDP | 4500 | Required for IPSEC<br> Internet key exchange (IKEv2) to encapsulate workloads for the bidirectional tunnel. Network Address Translation-Traversal (NAT-T) is also supported. |

-| On-premises Interconnect (HCX-IX) | Cloud Interconnect (HCX-IX) | UDP | 500 | Required for IPSEC<br> Internet key exchange (ISAKMP) for the bidirectional tunnel. |

-There can be more items to consider when it comes to firewall rules, this is intended to give common rules for common scenarios. Note that when source and destination say "on-premises," this is only important if you have a firewall that inspects flows within your datacenter. If you do not have a firewall that inspects between on-premises components, you can ignore those rules as they would not be needed.

-[Full list of VMware HCX port requirements](https://ports.esp.vmware.com/home/VMware-HCX)

-ΓÇá This Azure region is a [restricted one](../../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies). To use it, you need to request access to it by opening a [support request](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/newsupportrequest).

-In all regions (except Brazil South and Southeast Asia), Azure Data Factory data is stored and replicated in the [paired region](../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) to protect against metadata loss. During regional datacenter failures, Microsoft may initiate a regional failover of your Azure Data Factory instance. In most cases, no action is required on your part. When the Microsoft-managed failover has completed, you'll be able to access your Azure Data Factory in the failover region.

-Azure Stack Edge services uses [Azure Regional Pairs](../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) when storing and processing customer data in all the geos where the service is available. For the Southeast Asia (Singapore) region, the service is currently paired with Hong Kong Special Administrative Region. The Azure region pairing implies that any data stored in Singapore is replicated in Hong Kong SAR. Singapore has laws in place that require that the customer data not leave the country/region boundaries.

-If it's important for you to keep all data within certain geographical areas, check the location of the [geo-paired region](../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) for the region where you're creating your instance, to ensure that it meets your data residency requirements. For regions with built-in data residency requirements, customer data is always kept within the same region.

-If you [set up private links](how-to-set-up-private-links.md) to your Azure Data Manager for Energy resource in the primary region, then you must create a secondary private endpoint to the same resource in the [paired region](../reliability/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies).

-When an Azure region experiences a prolonged outage, you might be interested in failover options to an alternate region for business continuity. Many Azure regions have geo-pairs, and some don't. For a list of regions that have paired regions, see [Azure cross-region replication pairings for all geographies](../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies).

-Azure Firewall Policy is replicated to a paired Azure region. For example, if one Azure region goes down, Azure Firewall policy becomes active in the paired Azure region. The paired region is automatically selected based on the region where the policy is created. For more information, see [Cross-region replication in Azure: Business continuity and disaster recovery](../reliability/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies).

-description: This article gives an overview of best practices, single region availability, and optimization options for Azure HDInsight business continuity planning.

-keywords: hadoop high availability

-# Azure HDInsight business continuity

-Azure HDInsight clusters depend on many Azure services like storage, databases, Active Directory, Active Directory Domain Services, networking, and Key Vault. A well-designed, highly available, and fault-tolerant analytics application should be designed with enough redundancy to withstand regional or local disruptions in one or more of these services. This article gives an overview of best practices, single region availability, and optimization options for business continuity planning.

-## General best practices

-This section discusses a few best practices for you to consider during business continuity planning.

-* Determine the minimal business functionality you will need if there is a disaster and why. For example, evaluate if you need failover capabilities for the data transformation layer (shown in yellow) *and* the data serving layer (shown in blue), or if you only need failover for the data service layer.

- :::image type="content" source="media/hdinsight-business-continuity/data-layers.png" alt-text="data transformation and data serving layers":::

-* Segment your clusters based on workload, development lifecycle, and departments. Having more clusters reduces the chances of a single large failure affecting multiple different business processes.

-* Make your secondary regions read-only. Failover regions with both read and write capabilities can lead to complex architectures.

-* Transient clusters are easier to manage when there is a disaster. Design your workloads in a way that clusters can be cycled and no state is maintained in clusters.

-* Often workloads are left unfinished if there is a disaster and need to restart in the new region. Design your workloads to be idempotent in nature.

-* Use automation during cluster deployments and ensure cluster configuration settings are scripted as far as possible to ensure rapid and fully automated deployment if there is a disaster.

-* Use Azure monitoring tools on HDInsight to detect abnormal behavior in the cluster and set corresponding alert notifications. You can deploy the pre-configured HDInsight cluster-specific management solutions that collect important performance metrics of the specific cluster type. For more information, see [Azure Monitoring for HDInsight](./hdinsight-hadoop-oms-log-analytics-tutorial.md).

-* Subscribe to Azure health alerts to be notified about service issues, planned maintenance, health and security advisories for a subscription, service, or region. Health notifications that include the issue cause and resolute ETA help you to better execute failover and failbacks. For more information, see [Azure Service Health documentation](../service-health/index.yml).

-## Single region availability

-A basic HDInsight system has the following components. All components have their own single region fault tolerance mechanisms.

-* Compute (virtual machines): Azure HDInsight cluster

-* Metastore(s): Azure SQL Database

-* Storage: Azure Data Lake Gen2 or Blob storage

-* Authentication: Azure Active Directory, Azure Active Directory Domain Services, Enterprise Security Package

-* Domain name resolution: Azure DNS

-There are other optional services that can be used, such as Azure Key Vault and Azure Data Factory.

-### Azure HDInsight cluster (compute)

-HDInsight offers an availability SLA of 99.9%. To provide high availability in a single deployment, HDInsight is accompanied by many services that are in high availability mode by default. Fault tolerance mechanisms in HDInsight are provided by both Microsoft and Apache OSS ecosystem high availability services.

-The following services are designed to be highly available:

-#### Infrastructure

-* Active and Standby Headnodes

-* Multiple Gateway Nodes

-* Three Zookeeper Quorum nodes

-* Worker Nodes distributed by fault and update domains

-#### Service

-* Apache Ambari Server

-* Application timeline severs for YARN

-* Job History Server for Hadoop MapReduce

-* Apache Livy

-* HDFS

-* YARN Resource Manager

-* HBase Master

-Refer documentation on [high availability services supported by Azure HDInsight](./hdinsight-high-availability-components.md) to learn more.

-It doesn't always take a catastrophic event to impact business functionality. Service incidents in one or more of the following services in a single region can also lead to loss of expected business functionality.

-### HDInsight metastore

-HDInsight uses [Azure SQL Database](https://azure.microsoft.com/support/legal/sla/azure-sql-database/v1_4/) as a metastore, which provides an SLA of 99.99%. Three replicas of data persist within a data center with synchronous replication. If there is a replica loss, an alternate replica is served seamlessly. [Active geo-replication](/azure/azure-sql/database/active-geo-replication-overview) is supported out of the box with a maximum of four data centers. When there is a failover, either manual or data center, the first replica in the hierarchy will automatically become read-write capable. For more information, see [Azure SQL Database business continuity](/azure/azure-sql/database/business-continuity-high-availability-disaster-recover-hadr-overview).

-### HDInsight Storage

-HDInsight recommends Azure Data Lake Storage Gen2 as the underlying storage layer. [Azure Storage](https://azure.microsoft.com/support/legal/sla/storage/v1_5/), including Azure Data Lake Storage Gen2, provides an SLA of 99.9%. HDInsight uses the LRS service in which three replicas of data persist within a data center, and replication is synchronous. When there is a replica loss, a replica is served seamlessly.

-### Azure Active Directory

-[Azure Active Directory](https://azure.microsoft.com/support/legal/sla/active-directory/v1_0/) provides an SLA of 99.9%. Active Directory is a global service with multiple levels of internal redundancy and automatic recoverability. For more information, see how [Microsoft in continually improving the reliability of Azure Active Directory](https://azure.microsoft.com/blog/advancing-azure-active-directory-availability/).

-### Azure Active Directory Domain Services (AD DS)

-[Azure Active Directory Domain Services](https://azure.microsoft.com/support/legal/sl) to learn more.

-### Azure DNS

-[Azure DNS](https://azure.microsoft.com/support/legal/sla/dns/v1_1/) provides an SLA of 100%. HDInsight uses Azure DNS in various places for domain name resolution.

-## Multi-region cost and complexity optimizations

-Improving business continuity using cross region high availability disaster recovery requires architectural designs of higher complexity and higher cost. The following tables detail some technical areas that may increase total cost of ownership.

-### Cost optimizations

-|Area|Cause of cost escalation|Optimization strategies|

-|-||--|

-|Data Storage|Duplicating primary data/tables in a secondary region|Replicate only curated data|

-|Data Egress|Outbound cross region data transfers come at a price. Review Bandwidth pricing guidelines|Replicate only curated data to reduce the region egress footprint|

-|Cluster Compute|Additional HDInsight cluster/s in secondary region|Use automated scripts to deploy secondary compute after primary failure. Use Autoscaling to keep secondary cluster size to a minimum. Use cheaper VM SKUs. Create secondaries in regions where VM SKUs may be discounted.|

-|Authentication |Multiuser scenarios in secondary region will incur additional Azure AD DS setups|Avoid multiuser setups in secondary region.|

-### Complexity optimizations

-|Area|Cause of complexity escalation|Optimization strategies|

-|-||--|

-|Read Write patterns |Requiring both primary and secondary to be Read and Write enabled |Design the secondary to be read only|

-|Zero RPO & RTO |Requiring zero data loss (RPO=0) and zero downtime (RTO=0) |Design RPO and RTO in ways to reduce the number of components that need to fail over.|

-|Business functionality |Requiring full business functionality of primary in secondary |Evaluate if you can run with bare minimum critical subset of the business functionality in secondary.|

-|Connectivity |Requiring all upstream and downstream systems from primary to connect to the secondary as well|Limit the secondary connectivity to a bare minimum critical subset.|

-## Next steps

-To learn more about the items discussed in this article, see:

-* [Azure HDInsight business continuity architectures](./hdinsight-business-continuity-architecture.md)

-* [Azure HDInsight highly available solution architecture case study](./hdinsight-high-availability-case-study.md)

-* [What is Apache Hive and HiveQL on Azure HDInsight?](./hadoop/hdinsight-use-hive.md)

-By default, DPS provides automatic failover by replicating data to a [secondary region](../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) for a DPS instance. For some regions, you can avoid data replication outside of the region by disabling disaster recovery when creating a DPS instance. The following regions support this feature:

-Some application scenarios prefer or require the use of the same port by multiple application instances on a single VM in the backend pool. Common examples of port reuse include:

-If you want to reuse the backend port across multiple rules, you must enable Floating IP in the rule definition.

-When you enable Floating IP, Azure changes the IP address mapping to the Frontend IP address of the Load Balancer frontend instead of backend instance's IP. Without Floating IP, Azure exposes the VM instances' IP. Enabling Floating IP changes the IP address mapping to the Frontend IP of the load Balancer to allow for more flexibility. Learn more [here](load-balancer-multivip-overview.md).

-* Changing the IdleTimeout parameter for IPv6 is **currently not supported**. The default is four minutes.

-High availability and disaster recovery properties | **Disaster recovery region** | Defaulted to the [cross-region replication pair](../reliability/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) of the Target location. In an unlikely event when the chosen Target location doesn't yet have such a pair, the specified Target location itself is chosen as the default disaster recovery region.

- High availability and disaster recovery properties | **Disaster recovery region** | Defaulted to the [cross-region replication pair](../reliability/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) of the Target Location. In the unlikely event that the chosen Target Location doesn't yet have such a pair, the specified Target Location itself is chosen as the default disaster recovery region.

- High availability and disaster recovery properties | **Disaster recovery region** | Defaulted to the [cross-region replication pair](../reliability/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) of the Target Location. In the unlikely event that the chosen Target Location doesn't yet have such a pair, the specified Target Location itself is chosen as the default disaster recovery region.

- High availability and disaster recovery properties | **Disaster recovery region** | Defaulted to the [cross-region replication pair](../reliability/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) of the Target Location. In the unlikely event that the chosen Target Location doesn't yet have such a pair, the specified Target Location itself is chosen as the default disaster recovery region.

-You can have a source server in any [Azure Database for MySQL region](https://azure.microsoft.com/global-infrastructure/services/?products=mysql). A source server can have a replica in its [paired region](../../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) or the universal replica regions. The following picture shows which replica regions are available depending on your source region.

- | Paired recovery regions | See [Azure cross-region replication pairings](/azure/reliability/cross-region-replication-azure#azure-cross-region-replication-pairings-for-all-geographies). |

-[Azure paired regions]: /azure/availability-zones/cross-region-replication-azure#azure-cross-region-replication-pairings-for-all-geographies

-| where type == 'microsoft.orbital/spacecrafts/contacts' and todatetime(properties.reservationStartTime) >= now()

-| sort by todatetime(properties.reservationStartTime)

-| extend Contact_Profile = tostring(split(properties.contactProfile.id, "/")[-1])

-| extend Spacecraft = tostring(split(id,ΓÇ»"/")[-3])

-| project Contact = tostring(name), Groundstation = tostring(properties.groundStationName), Spacecraft, Contact

-| where todatetime(properties.reservationStartTime) >= now()

-| sort by Contact_Profile

-| project Contact = tostring(name), Groundstation = tostring(properties.groundStationName), Spacecraft, Contact_Profile, Reservation_Start_Time = todatetime(properties.reservationStartTime), Reservation_End_Time = todatetime(properties.reservationEndTime), Status=properties.status, Provisioning_Status=properties.provisioningState

-### List Contacts from Past ΓÇÿxΓÇÖ Days ΓÇô sorted by reservation start time

-```kusto

-Many regions also have a [*paired region*](./cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies). Paired regions support certain types of multi-region deployment approaches. Some newer regions have [multiple availability zones and don't have a paired region](./cross-region-replication-azure.md#regions-with-availability-zones-and-no-region-pair). You can still deploy multi-region solutions into these regions, but the approaches you use might be different.

-The [shared responsibility model](./overview.md#shared-responsibility) describes how responsibilities are divided between the cloud provider (Microsoft) and you. Depending on the type of services you use, you might take on more or less responsibility for operating the service.

-description: Learn about Cross-region replication in Azure.

-# Cross-region replication in Azure: Business continuity and disaster recovery

-Many organizations require both high availability provided by availability zones that are also supported with protection from large-scale phenomena and regional disasters. Azure regions are designed to offer protection against local disasters with availability zones. But they can also provide protection from regional or large geography disasters with disaster recovery by making use of another region that uses *cross-region replication*.

-Architecting cross-regional replication for your services and data can be decided on a per-service basis. You'll necessarily take a cost-benefit analysis approach based on your organization's strategic and business requirements. Primary and ripple benefits of cross-region replication are complex, extensive, and deserve elaboration. These benefits include:

-Although it is not possible to create your own regional pairings, you can nevertheless create your own disaster recovery solution by building your services in any number of regions and then using Azure services to pair them. For example, you can use Azure services such as [AzCopy](../storage/common/storage-use-azcopy-v10.md) to schedule data backups to an Azure Storage account in a different region. Using [Azure DNS and Azure Traffic Manager](../networking/disaster-recovery-dns-traffic-manager.md), you can design a resilient architecture for your applications that will survive the loss of the primary region.

-You are not limited to using services within your regional pairs. Although an Azure service can rely upon a specific regional pair, you can host your other services in any region that satisfies your business needs. For example, an Azure GRS storage solution can pair data in Canada Central with a peer in Canada East while using Azure Compute resources located in East US.

-## Azure cross-region replication pairings for all geographies

-Regions are paired for cross-region replication based on proximity and other factors.

->To learn more about your region's architecture, please contact your Microsoft sales or customer representative.

-Azure continues to expand globally with Qatar as the first region with no regional pair and achieves high availability by leveraging [availability zones](../reliability/availability-zones-overview.md) and [locally redundant or zone-redundant storage (LRS/ZRS)](../storage/common/storage-redundancy.md#zone-redundant-storage). Regions without a pair will not have [geo-redundant storage (GRS)](../storage/common/storage-redundancy.md#geo-redundant-storage). Such regions follow [data residency](https://azure.microsoft.com/global-infrastructure/data-residency/#overview) guidelines allowing the option to keep data resident within the same region. Customers are responsible for data resiliency based on their Recovery Point Objective or Recovery Time Objective (RTO/RPO) needs and may move, copy, or access their data from any location globally. In the rare event that an entire Azure region is unavailable, customers will need to plan for their Cross Region Disaster Recovery per guidance from [Azure services that support high availability](../reliability/availability-zones-service-support.md#azure-services-with-availability-zone-support) and [Azure Resiliency ΓÇô Business Continuity and Disaster Recovery](https://azure.microsoft.com/mediahandler/files/resourcefiles/resilience-in-azure-whitepaper/resiliency-whitepaper-2022.pdf).

-> [Learn about Azure Functions support for availability zone redundancy](./reliability-functions.md)

-> [!div class="nextstepaction"]

-> [Azure Functions geo-disaster recovery](../azure-functions/functions-geo-disaster-recovery.md)

-Reliability consists of two principles: resiliency and availability. The goal of resiliency is to return your application to a fully functioning state after a failure occurs. The goal of availability is to provide consistent access to your application or workload be users as they need to.

-For more detailed information on reliability and reliability principles in Microsoft Azure services, see [Microsoft Azure Well-Architected Framework: Reliability](/azure/architecture/framework/#reliability).

-You should define your applicationΓÇÖs reliability requirements at the beginning of planning. If you know which applications don't need 100% high availability during certain periods of time, you can optimize costs during those non-critical periods. Identify the type of failures an application can experience, and the potential effect of each failure. A recovery plan should cover all critical services by finalizing recovery strategy at the individual component and the overall application level. Design your recovery strategy to protect against zonal, regional, and application-level failure. And perform testing of the end-to-end application environment to measure application reliability and recovery against unexpected failure.

-Regions and Availability Zones are a big part of the reliability equation. Regions feature multiple, physically separate availability zones. These availability zones are connected by a high-performance network featuring less than 2ms latency between physical zones. Low latency helps your data stay synchronized and accessible when things go wrong. You can use this infrastructure strategically as you architect applications and data infrastructure that automatically replicate and deliver uninterrupted services between zones and across regions. Choose the best region for your needs based on technical and regulatory considerationsΓÇöservice capabilities, data residency, compliance requirements, latencyΓÇöand begin advancing your reliability strategy.

-Microsoft Azure services support availability zones and are enabled to drive your cloud operations at optimum high availability while supporting your disaster recovery and business continuity strategy needs. Choose the best region for your needs based on technical and regulatory considerationsΓÇöservice capabilities, data residency, compliance requirements, latencyΓÇöand begin advancing your reliability strategy. For more information, see [Azure regions and availability zones](availability-zones-overview.md).

-## Shared responsibility

-Building reliabile systems on Azure is a shared responsibility. Microsoft is responsible for the reliability of the cloud platform, which includes its global network and datacenters. Azure customers and partners are responsible for the reliability of their cloud applications, using architectural best practices based on the requirements of each workload. For more information, see [Business continuity management program in Azure](business-continuity-management-program.md).

-Microsoft Azure services are available globally to drive your cloud operations at an optimal level. You can choose the best region for your needs based on technical and regulatory considerations: service capabilities, data residency, compliance requirements, and latency.

-> [!div class="nextstepaction"]

-> [Business continuity management in Azure](business-continuity-management-program.md)

-> [!div class="nextstepaction"]

-> [Availability zone migration guidance](availability-zones-migration-overview.md)

-> [!div class="nextstepaction"]

-> [Availability of service by category](availability-service-by-category.md)

-> [!div class="nextstepaction"]

-> [Microsoft commitment to expand Azure availability zones to more regions](https://azure.microsoft.com/blog/our-commitment-to-expand-azure-availability-zones-to-more-regions/)

-> [!div class="nextstepaction"]

-> [Build solutions for high availability using availability zones](/azure/architecture/high-availability/building-solutions-for-high-availability)

-This article describes reliability support in [Azure App Service](../app-service/overview.md), and covers intra-regional resiliency with [availability zones](#availability-zone-support). For a more detailed overview of reliability in Azure, see [Azure reliability](/azure/architecture/framework/resiliency/overview).

-To explore how Azure App Service can bolster the resiliency of your application workload, see [Why use App Service?](../app-service/overview.md#why-use-app-service)

-#### To deploy a zone-redundant App Service using a dedicated environment

-## Next steps

-> [!div class="nextstepaction"]

-> [Reliability in Azure](/azure/availability-zones/overview)

-This article describes reliability support in Azure Batch and covers both intra-regional resiliency with [availability zones](#availability-zone-support) and links to information on [cross-region resiliency with disaster recovery](#disaster-recovery-cross-region-failover).

-## Disaster recovery: cross region failover

-### Single-region geography disaster recovery

-> [!div class="nextstepaction"]

-[Azure Architecture Center's guide on availability zones](/azure/architecture/high-availability/building-solutions-for-high-availability).

-> [!div class="nextstepaction"]

-> [Reliability in Azure](./overview.md)

-This article describes reliability support in Azure Functions and covers both intra-regional resiliency with [availability zones](#availability-zone-support) and links to information on [cross-region resiliency with disaster recovery](#disaster-recovery-cross-region-failover). For a more detailed overview of reliability in Azure, see [Azure reliability](/azure/architecture/framework/resiliency/overview).

-## Disaster recovery: cross region failover

-When an entire Azure region, viz. all of the component availability zones experience downtime, your mission-critical code needs to continue processing in a different region. See [Azure Functions geo-disaster recovery and high availability](../azure-functions/functions-geo-disaster-recovery.md) for guidance on how to set up a cross region failover.

-> [!div class="nextstepaction"]

->[Azure Architecture Center's guide on availability zones](/azure/architecture/high-availability/building-solutions-for-high-availability).

-> [!div class="nextstepaction"]

-> [Reliability in Azure](./overview.md)

-This article describes reliability support in Azure HDInsight, and covers [availability zones](#availability-zone-support). For a more detailed overview of reliability in Azure, see [Azure reliability](/azure/architecture/framework/resiliency/overview).

-This article describes high availability in Azure Database for PostgreSQL - Flexible Server, which includes [availability zones](#availability-zone-support) and [cross-region resiliency with disaster recovery](#disaster-recovery-cross-region-failover). For a more detailed overview of reliability in Azure, see [Azure reliability](/azure/architecture/framework/resiliency/overview).

-## Disaster recovery: cross-region failover

-### Cross-region disaster recovery in multi-region geography

-In the case of a region-wide disaster, Azure can provide protection from regional or large geography disasters with disaster recovery by making use of another region. For more information on Azure disaster recovery architecture, see [Azure to Azure disaster recovery architecture](../site-recovery/azure-to-azure-architecture.md).

-### Multi-region geography disaster recovery

-### Single-region geography disaster recovery

-Microsoft and its customers operate under the [Shared Responsibility Model](./overview.md#shared-responsibility). Shared responsibility means that for customer-enabled DR (customer-responsible services), you must address DR for any service they deploy and control. To ensure that recovery is proactive, you should always pre-deploy secondaries because there's no guarantee of capacity at time of impact for those who haven't preallocated.

-+ Business continuity and disaster recovery (BCDR) requirements dictate creating multiple search services in [regional pairs](../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies). For example, if you're operating in North America, you might choose East US and West US, or North Central US and South Central US, for each search service.

-In this article, learn how to request a semantic answer, unpack the response, and what content characteristics are most conducive to producing high-quality answers.

-+ Search documents in the index must contain text having the characteristics of an answer, and that text must exist in one of the fields listed in the [semantic configuration](semantic-how-to-query-request.md#2create-a-semantic-configuration). For example, given a query "what is a hash table", if none of the fields in the semantic configuration contain passages that include "A hash table is ...", then it's unlikely an answer will be returned.

-Cognitive Search uses a machine reading comprehension model to pick the best answer. The model produces a set of potential answers from the available content, and when it reaches a high enough confidence level, it will propose one as an answer.

-The approach for listing fields in priority order has changed, with "semanticConfiguration" replacing "searchFields". If you're currently using "searchFields", update your code to the 2021-04-30-Preview API version and use "semanticConfiguration" instead.

-### [**Semantic Configuration (recommended)**](#tab/semanticConfiguration)

-To return a semantic answer, the query must have the semantic "queryType", "queryLanguage", "semanticConfiguration", and the "answers" parameters. Specifying these parameters doesn't guarantee an answer, but the request must include them for answer processing to occur.

-The "semanticConfiguration" parameter is required. It's defined in a search index, and then referenced in a query, as shown below.

-+ "queryType" must be set to "semantic.

-+ "queryLanguage" must be one of the values from the [supported languages list (REST API)](/rest/api/searchservice/preview-api/search-documents#queryLanguage).

-+ A "semanticConfiguration" determines which string fields provide tokens to the extraction model. The same fields that produce captions also produce answers. See [Create a semantic configuration](semantic-how-to-query-request.md#2create-a-semantic-configuration) for details.

-+ For "answers", parameter construction is `"answers": "extractive"`, where the default number of answers returned is one. You can increase the number of answers by adding a `count` as shown in the above example, up to a maximum of 10. Whether you need more than one answer depends on the user experience of your app, and how you want to render results.

-### [**searchFields**](#tab/searchFields)

-To return a semantic answer, the query must have the semantic "queryType", "queryLanguage", "searchFields", and the "answers" parameter. Specifying the "answers" parameter doesn't guarantee that you'll get an answer, but the request must include this parameter if answer processing is to be invoked at all.

-The "searchFields" parameter is crucial to returning a high-quality answer, both in terms of content and order (see below).

-```json

-{

- "search": "how do clouds form",

- "queryType": "semantic",

- "queryLanguage": "en-us",

- "searchFields": "title,locations,content",

- "answers": "extractive|count-3",

- "count": "true"

-}

-```

-+ A query string must not be null and should be formulated as question.

-+ "queryType" must be set to "semantic.

-+ "queryLanguage" must be one of the values from the [supported languages list (REST API)](/rest/api/searchservice/preview-api/search-documents#queryLanguage).

-+ "searchFields" determines which string fields provide tokens to the extraction model. The same fields that produce captions also produce answers. See [Set searchFields](semantic-how-to-query-request.md#2buse-searchfields-for-field-prioritization) for details.

-+ For "answers", parameter construction is `"answers": "extractive"`, where the default number of answers returned is one. You can increase the number of answers by adding a `count` as shown in the above example, up to a maximum of 10. Whether you need more than one answer depends on the user experience of your app, and how you want to render results.

-Answers are provided in the `"@search.answers"` array, which appears first in the query response. Each answer in the array will include:

-If an answer is indeterminate, the response will show up as `"@search.answers": []`. The answers array is followed by the value array, which is the standard response in a semantic query.

-When designing a search results page that includes answers, be sure to handle cases where answers are not found.

-+ **"score"** is a confidence score that reflects the strength of the answer. If there are multiple answers in the response, this score is used to determine the order. Top answers and top captions can be derived from different search documents, where the top answer originates from one document, and the top caption from another, but in general you will see the same documents in the top positions within each array.

-> Captions and answers are extracted verbatim from text in the search document. The semantic subsystem uses language understanding to determine what part of your content have the characteristics of a caption or answer, but it doesn't compose new sentences or phrases. For this reason, content that includes explanations or definitions work best for semantic ranking.

-+ [Postman app](https://www.postman.com/downloads/) using the [2021-04-30-Preview REST APIs](/rest/api/searchservice/preview-api/search-documents). See this [Quickstart](search-get-started-rest.md) for help with setting up your requests.

-+ [Azure.Search.Documents 11.4.0-beta.5](https://www.nuget.org/packages/Azure.Search.Documents/11.4.0-beta.5) in the Azure SDK for .NET Preview.

-> [!IMPORTANT]

-> A semantic configuration is required for the 2021-04-30-Preview REST APIs, Search explorer, and some versions of the beta SDKs. If you're using the 2020-06-30-preview REST API, skip this step and use the ["searchFields" approach for field prioritization](#2buse-searchfields-for-field-prioritization) instead.

-A *semantic configuration* specifies how fields are used in semantic ranking. It gives the underlying models hints about which index fields are most important for semantic ranking, captions, highlights, and answers.

-Add a semantic configuration to your [index definition](/rest/api/searchservice/preview-api/create-or-update-index). The following tabbed sections provide instructions for the REST APIs, Azure portal, and the .NET SDK Preview.

-You can add or update a semantic configuration at any time without rebuilding your index. When you issue a query, add the semantic configuration (one per query) that specifies which semantic configuration to use for the query.

-1. Review the properties needed in the configuration. A semantic configuration has a name and at least one each of the following properties:

- + **Title field** - A title field should be a concise description of the document, ideally a string that is under 25 words. This field could be the title of the document, name of the product, or item in your search index. If you don't have a title in your search index, leave this field blank.

- + **Content fields** - Content fields should contain text in natural language form. Common examples of content are the body of a document, the description of a product, or other free-form text.

- + **Keyword fields** - Keyword fields should be a list of keywords, such as the tags on a document, or a descriptive term, such as the category of an item.

- You can only specify one title field but you can specify as many content and keyword fields as you like. For content and keyword fields, list the fields in priority order because lower priority fields may get truncated.

-1. For the above properties, determine which fields to assign.

- A field must be searchable and retrievable.

- A field must be a [supported data type](/rest/api/searchservice/supported-data-types) and it should contain strings. If you happen to include an invalid field, there's no error, but those fields aren't used in semantic ranking.

- | Data type | Example from hotels-sample-index |

- |--|-|

- | Edm.String | HotelName, Category, Description |

- | Edm.ComplexType | Address.StreetNumber, Address.City, Address.StateProvince, Address.PostalCode |

- | Collection(Edm.String) | Tags (a comma-delimited list of strings) |

- > [!NOTE]

- > Subfields of Collection(Edm.ComplexType) fields aren't currently supported by semantic search and aren't used for semantic ranking, captions, or answers.

-1. Formulate a [Create or Update Index](/rest/api/searchservice/preview-api/create-or-update-index?branch=main) request.

-> To see an example of creating a semantic configuration and using it to issue a semantic query, check out the

-[semantic search Postman sample](https://github.com/Azure-Samples/azure-search-postman-samples/tree/master/semantic-search).

-## 2b - Use searchFields for field prioritization

-This step is only for solutions using the 2020-06-30-Preview REST API or a beta SDK that doesn't support semantic configurations. Instead of setting field prioritization in the index through a semantic configuration, set the priority at query time, using the searchFields parameter of a query.

-Using searchFields for field prioritization was an early implementation detail that won't be supported once semantic search exits public preview. We encourage you to use semantic configurations if your application requirements allow it.

-```http

-POST https://[service name].search.windows.net/indexes/[index name]/docs/search?api-version=2020-06-30-Preview     

-{   

- "search": " Where was Alan Turing born?",   

- "queryType": "semantic",ΓÇ»

- "searchFields": "title,url,body",ΓÇ»

- "queryLanguage": "en-us"ΓÇ»

-}

-```

-Field order is critical because the semantic ranker limits the amount of content it can process while still delivering a reasonable response time. Content from fields at the start of the list are more likely to be included; content from the end could be truncated if the maximum limit is reached. For more information, see [Preprocessing during semantic ranking](semantic-search-overview.md#how-inputs-are-prepared).

-+ If you're specifying just one field, choose a descriptive field where the answer to semantic queries might be found, such as the main content of a document.

-+ For two or more fields in `searchFields`:

- + The first field should always be concise (such as a title or name), ideally a string that is under 25 words.

- + If the index has a URL field that is human readable such as `www.domain.com/name-of-the-document-and-other-details` (rather than machine focused, such as `www.domain.com/?id=23463&param=eis`), place it second in the list (or first if there's no concise title field).

- + Follow the above fields with other descriptive fields, where the answer to semantic queries may be found, such as the main content of a document.

-When setting `searchFields`, choose only fields of the following [supported data types](/rest/api/searchservice/supported-data-types):

-| Data type | Example from hotels-sample-index |

-|--|-|

-| Edm.String | HotelName, Category, Description |

-| Edm.ComplexType | Address.StreetNumber, Address.City, Address.StateProvince, Address.PostalCode |

-| Collection(Edm.String) | Tags (a comma-delimited list of strings) |

-If you happen to include an invalid field, there's no error, but those fields won't be used in semantic ranking.

-1. Set "captions" to specify whether semantic captions are included in the result. If you're using a semantic configuration, you should set this parameter. While the ["searchFields" approach](#2buse-searchfields-for-field-prioritization) automatically included captions, "semanticConfiguration" doesn't.

-The string is composed of tokens, not characters or words. The maximum token count is 256 unique tokens. For estimation purposes, you can assume that 256 tokens are roughly equivalent to a string that is 256 words in length.

-You can see the full [list of regional pairs here](../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies).

-description: Learn about forced tunneling and split tunneling via UDRs for VPN Gateway site-to-site connections

-In some cases, you may want specific subnets to send and receive Internet traffic directly, without going through an on-premises location for inspection and auditing. One way to achieve this is to specify routing behavior using [custom user-defined routes](../virtual-network/virtual-networks-udr-overview.md#user-defined) (UDRs). After configuring forced tunneling, specify a custom UDR for the subnet(s) for which you want to send Internet traffic directly to the Internet (not to the on-premises location). In this type of configuration, only the subnets that have a specified UDR send Internet traffic directly to the Internet. Other subnets continue to have Internet traffic force-tunneled to the on-premises location.

-You can also create this type of configuration when working with peered VNets. A custom UDR can be applied to a subnet of a peered VNet that traverses through the VNet containing the VPN Gateway S2S connection.

-## Considerations

-Forced tunneling is configured using Azure PowerShell. You can't configure forced tunneling using the Azure portal.

-* Each virtual network subnet has a built-in, system routing table. The system routing table has the following three groups of routes:

-

- * **Local VNet routes:** Directly to the destination VMs in the same virtual network.

- * **On-premises routes:** To the Azure VPN gateway.

- * **Default route:** Directly to the Internet. Packets destined to the private IP addresses not covered by the previous two routes are dropped.

-* In this scenario, forced tunneling must be associated with a VNet that has a route-based VPN gateway. Your forced tunneling configuration overrides the default route for any subnet in its VNet. You need to set a "default site" among the cross-premises local sites connected to the virtual network. Also, the on-premises VPN device must be configured using 0.0.0.0/0 as traffic selectors.

-* ExpressRoute forced tunneling isn't configured via this mechanism, but instead, is enabled by advertising a default route via the ExpressRoute BGP peering sessions. For more information, see the [ExpressRoute Documentation](../expressroute/index.yml).

-## Forced tunneling

-The following example shows all Internet traffic being forced through the VPN gateway back to the on-premises location for inspection and auditing. Configure [forced tunneling](site-to-site-tunneling.md) by specifying a default site.

-**Forced tunneling example**

-## Forced tunneling and UDRs

-You may want Internet-bound traffic from certain subnets (but not all subnets) to traverse from the Azure network infrastructure directly out to the Internet. This scenario can be configured using a combination of forced tunneling and virtual network custom user-defined routes. For steps, see [Forced tunneling and UDRs](site-to-site-tunneling.md).

-**Forced tunneling and UDRs example**

-* **Frontend subnet**: Internet-bound traffic is tunneled directly to the Internet using a custom UDR that specifies this setting. The workloads in the Frontend subnet can accept and respond to customer requests from the Internet directly.

-* **Mid-tier and Backend subnets**: These subnets continue to be force tunneled because a default site has been specified for the VPN gateway. Any outbound connections from these two subnets to the Internet are forced or redirected back to an on-premises site via S2S VPN tunnels through the VPN gateway.

-* See [How to configure forced tunneling for VPN Gateway S2S connections](site-to-site-tunneling.md).

-description: Learn how to split or force tunnel traffic for VPN Gateway site-to-site connections using PowerShell.

-# Configure forced tunneling for site-to-site connections

-The steps in this article help you configure forced tunneling for site-to-site (S2S) IPsec connections. For more information, see [About forced tunneling for VPN Gateway](about-site-to-site-tunneling.md).

-The following steps help you configure a forced tunneling scenario by specifying a default site. Optionally, using custom UDR, you can route traffic by specifying that Internet-bound traffic from the Frontend subnet goes directly to the Internet, rather than to the on-premises site.

-* You specify the default site for your VPN gateway using PowerShell, which forces all Internet traffic back to the on-premises location. The default site can't be configured using the Azure portal.

-* The Mid-tier and Backend subnets continue to have Internet traffic force tunneled back to the on-premises site via the VPN gateway because a default site is specified.

-## Configure forced tunneling

-Configure forced tunneling by assigning a default site to the virtual network gateway. If you don't specify a default site, Internet traffic isn't forced through the VPN gateway and will, instead, traverse directly out to the Internet for all subnets (by default).

-To assign a default site for the gateway, you use the **-GatewayDefaultSite** parameter. Be sure to assign this properly.

-1. First, declare the variables that specify the virtual network gateway information and the local network gateway for the default site, in this case, DefaultSiteHQ.

-1. Next, set the virtual network gateway default site using [Set-AzVirtualNetworkGatewayDefaultSite](/powershell/module/az.network/set-azvirtualnetworkgatewaydefaultsite).

-At this point, all Internet-bound traffic is now configured to be force tunneled to *DefaultSiteHQ*. Note that the on-premises VPN device must be configured using 0.0.0.0/0 as traffic selectors.

-## Create route tables and routes

-## Assign routes

-## Establish S2S VPN connections