Many new Azure cloud projects are started in one Azure region, most often as near as possible where they are located. In some cases, this is enforced by local data protection laws, for example within the European Union or in Switzerland. Availability in one region is most often enough for starting a new project, especially when considering Availability Zones, Auto-Scale for App Services or Virtual Machines. When Microsoft is doing maintenance within a region, each Availability Zone in this region is maintained sequentially. This adds added availability within a region.
In some cases, due to business or regulatory requirements, a higher resilience scenario is required. In such situations an adaptation of an existing Azure cloud infrastructure Architecture is necessary. Luckily, for almost all regions, Azure provides a regions pair to implement high(er) availability and resilience options.
Azure Regions Pairs and the special case of Azure Switzerland-West region
Microsoft organizes Azure regions into Azure Geographies. This is a grouping based on several similarities regarding compliance or other functionalities. For example, “United States” is one Azure Geography containing many regions, but “Europe” is also an Azure Geography but contains only two regions. An Azure Region is usually paired with another region within an Azure Geography, Only Poland Central and Sweden Central do not have an Azure Region to pair with.
A good overview about Azure Geographies can be found here: Azure Geographies Regions listed here are only the public available regions. A more complete overview is available at Azure Speed. And provides many more interesting features for Azurites.
When for a cloud project the main region is West-Europe the region pair will be automatically North-Europe. When for this project an auto-failover scenario of the SQL Databases is necessary an Azure Cloud Developer can immediately set up the North-Europe cloud environment and configure the fail-over configuration for this project. But when the main region is Switzerland-North this scenario is not immediately available. For example, when adding a Virtual Machine resource, Azure Switzerland-West will not be visible for selection as possible region for this new resource. The main reason for this is that Azure Switzerland West is a Restricted Access region.
Several regions within Azure are restricted access for different reasons. When focusing on the Azure Switzerland-West region, there are several reasons why it is restricted. One official reason is capacity. For example, Azure Switzerland West does not support Availability Zones. Availability Zones can only be created when an Azure Region has three independent, near to each other, data centers. Most often these Azure regions are only used for Fail-over scenarios.
Another possible reason, why Azure Switzerland-West is Restricted Access could be the capacity of data center space in the Geneva area. A lot of other competitors, not only hyper scalers but also universities and other data center companies fie for data center real estate.
Not be able to configure the second region with Availability Zones can be restrictive for certain resilience scenarios, this does not mean Azure Switzerland-West is not a viable option. Since the start of Azure Switzerland-West, a lot of services are provided in this region and there will be more expected to come in the next few years. Specific High-Availability scenarios are still possible and even using specific services in Azure Switzerland-West can add resiliency, but need to be evaluated in a case-by-case scenario. For example, service like Azure Container Apps, or a certain AI (Bot) Services are not available in the Azure Switzerland-West region. Additionally, there is a harder limit on the amount of resources you can get, compared to Azure Switzerland-North.
Preparations before requesting access to Azure Switzerland-West
What steps need to be done before using the Azure Switzerland West region?
The first step is looking at the possible High-Availability and Resilience scenarios. The Microsoft Azure Well-Architected Framework is a very important and helpful resource to start with. It is based on the five pillars of architectural excellence: Reliability, Security, Cost optimization, Operational excellence, and Performance efficiency. For this situation the “Resilience” pillar is good starting point. If resilience and high availability are new topics for you, another good starting point to get more in-depth information and training can be found on Microsoft Learn.
In the Azure documentation, several different scenarios are explained, but not all scenarios are available for the Azure Switzerland-West region. For example, when using Azure App Services an Active-Active Architecture is not possible. This region is meant for failover scenarios and using it to run it as a second productive environment next to Azure Switzerland-North is not possible, only when (app) services fail in Azure Switzerland-North. But an Active-Passive or even an Active-Cold Architecture are valid scenarios and will increase the resilience of a project. Other good examples to use with Azure Switzerland-West, are geo-replication of SQL Server and Storage Accounts and considering Auto-Failover groups for SQL Servers.
The second step is to check if the services are available in the Azure Switzerland-West region. The Azure Products by Region website will provide this information. Especially check the availability of certain Virtual Machine sizes in this region, not all Virtual Machine sizes are available in every region, or if a Service Tier is supported in that region.
I always read the very tiny footnotes when I make an architectural overview for Azure. They contain very important, and sometimes surprising, information.
Footnotes, for example, contain information of restricted availability of specific tiers, or something is only available under specific circumestances, like only in Premium Tier.
With possible resilience scenarios considered, the available services checked for the region, the third step is estimating growth potential. From my experience, this can be hard because so many factors are involved. The best approach is to look per service to what extent the expected growth in an optimistic scenario could be. Try to decide if a service will be scale-out rather than scale-up, or if storage spaces are enough for the next year or the next three years. This part is an estimation, you will not be held accountable by Microsoft. But they will ask you for this information when you apply for access to Azure Switzerland-West.
The final step is to apply for access to Azure Switzerland-West: Azure region access request process
Requesting Access
Officially, the time to get access after application is two weeks. My experience is rather 4 weeks when everything runs smoothly. Keep in mind that you need to apply separately for each service!! This is a lot of effort especially when you have a lot of services.
Important first action: Get the subscription team to have the region available for your tenant!
When opening a support request, this request will go to a Microsoft sub-contractor who handles these kinds of requests. Do not get distracted when you get asked about what services you want to deploy. If you answer that question, you will be on a wild goose chase with different companies and/or different teams within those companies. Every service has its own team or sub-contractor. With a big project you easily generate 15+ support requests that you need to handle at the same time, but they can’t help you and you run into problems because the region is not available to you.
After that you are already able to deploy the services that are available in that region. If you come to limitations, for example certain plans for a service or certain VM types are not available, then it is time to follow the wild goose again and ask if those types are even available in that region (you probably know they are available because of your previous steps, but it’s good to ask for the actual status), and if they are available, that they make them available to you. The so called “wild goose” are the capacity teams and their responsibility is to make the capacity available to you. You need to be prepared when you open those requests, you need to know what growth rates you will have in, for example, SQL Server in the future, because they will limit you to those. If you need a specific plan, be prepared to have the exact name on hand. If you follow those little tips, you will save yourself a lot of time, nerves and get through that orderly.
Considerations
The above-mentioned preparations are a good start for enabling more resilience and availability for an Azure cloud project. But there are other related considerations:
- Multi-region resilience will increase costs, so evaluating if multi-region availability and resilience are really necessary for a project can prevent cost increases from the start. As mentioned before, using auto-scale and availability zones can increase resilience a lot but only costs a fraction of the price and sometimes only by demand.
- When starting a multi-region resilience for a project, hidden costs should be made visible. These costs are:
- Integrating CI/CD for multi-region: what are the costs to add support for releases to the other region? which scenarios are suitable?
- In case of a fail over, what business continuity management processes are in place? Which process can be automated?
- From a Cloud Governance perspective: Are RTO, RPO and MAO evaluated for the company?
- When considering an Active-Passive Architecture for Azure App Services, or a similar scenario for other services, evaluate if the passive infrastructure can be deployed with a lower service tier and automatically can be scaled-up when a disaster occurs. This lowers costs while the infrastructure is in passive mode and not used.
- Using Storage accounts to have applications “in wait” to be deployed, instead of having Azure App Service running while they are in passive mode, can reduce costs as well.
- Certain services, like Azure API Management are well known to take time to deploy or start. Identifying these “slow start” services will prevent surprises when a disaster occurs.
- Not all Azure services provide multi-region support. Check all documentation for selected multi-region support. For example, Azure API Management Service only supports this in the much more expensive premium tier multi-region support. Take into account to setup an additional Service-to-Service VPN infrastructure to the second region from your own IT infrastructure. This will add costs and implementation time.
Conclusion
Adding more resilience to a new or existing cloud architecture can be a daunting endeavor, but with good preparation and evaluation it can harden your cloud infrastructure and (cloud based) product.