We are happy to announce the availability of the Microsoft Azure service resiliency guidance page. We created this page because our customers have asked us for clear guidance on what to do when they experienced a service disruption. Since a service disruption can be localized (perhaps an issue on a specific host or even code within a virtual machine) or more general (impacting any number of machines within a region) it is important to understand both the scope of the impact and what you can do if you are experiencing such an event. In general, it is good practice to check to see if the service disruption you are experiencing is localized to a subset of your application, all of your subscription, or the greater region as a whole. In some cases, you may decide you want to initiate your own failover (either within a region, or to a different region, depending on the scope of impact you are experiencing). To help you understand the impact of a failover, and to help you with your options, we have published a list (by service) of failover options that you can consult and consider as part of your disaster recovery processes.

We have started with some of our most fundamental services: Virtual Networks, Virtual Machines, Storage (blobs, queues, tables, and files), Key Vault, Cloud Services, and SQL Databases. Each has its own article so that you can search for them easily, though to help (since we know there are a lot of services available) we have also created an index page to help you find the guidance that’s most suited to your service usage. You can find the current list on the Microsoft Azure service resiliency guidance page.

As always, we are interested in your feedback on this page (and the service guidance pages), as well as what we can do to improve them for you and what other resiliency materials you would find helpful. If you have any comments or questions, feel free to leave them in the comments section below or you can email us on the resiliency team at resiliencyfeedback@microsoft.com.

This is a cross post from the Azure Blog.