A key point to consider when providing the ability to failover to an alternate region is that all components in a solution need to be considered; it is not sufficient to simply have a second Batch account. For example, in most Batch applications, an Azure storage account is required, with the storage account and Batch account needing to be in the same region for acceptable performance.
Consider the following points when designing a solution that can failover:
Pre-create all required accounts in each region, such as the Batch account and storage account. There often is not any charge for having accounts created, only when there is data stored or the account is used.
Make sure quotas are set on the accounts ahead of time, so you can allocate the required number of cores using the Batch account.
Use templates and/or scripts to automate the deployment of the application in a region.
Keep application binaries and reference data up-to-date in all regions. Staying up-to-date will ensure the region can be brought online quickly without having to wait for the upload and deployment of files. For example, if a custom application to install on pool nodes is stored and referenced using Batch application packages, then when a new version of the application is produced, it should be uploaded to each Batch account and referenced by the pool configuration (or make the new version the default version).
In the application calling Batch, storage, and any other services, easily switchover clients or the load to the different region.
A best practice to ensure a failover will be successful is to frequently switchover to an alternate region as part of normal operation. For example, with two deployments in separate regions, switchover to the alternate region every month.
Source : Azure Documentation FAQ Link