Designing A Multi-Region Web Application Solution With A Private Endpoint Database In Microsoft Azure

Introduction

Today, we will look into a multi-region solution for a web application to provide redundancy. We will see how it is recommended to be set up using the architecture proposed by Microsoft. We will also see how the database used by the web application will be available via a private endpoint and not accessible from the internet. This will give us a very robust, secure, and highly available web application solution using Microsoft Azure.

Reference diagram

We will start with the diagram provided by Microsoft. Details are available on the Microsoft website below:

https://learn.microsoft.com/en-us/azure/architecture/example-scenario/sql-failover/app-service-private-sql-multi-region

Components of the design

The diagram might seem very complex at the first glance, but it is quite simple to understand and set up. In the first region called the “Primary region” we set up an Azure app service to host our web application. We then integrate this app service into a new/existing virtual network and subnet in Azure and disallow direct access to the App service from the outside. We then set up a private link subnet in the same virtual network and set up a private endpoint to the database e.g., Azure SQL database. Direct access to the database from the internet is also removed. Hence, we can only talk to the database using the private endpoint from the App service.

We then replicate the same setup in another region called the “Secondary region”. We then set up virtual network peering between the virtual networks in both regions and set up database geo-replication between the two databases. This will ensure that any database changes in the primary region are replicated with the database in the secondary region in case we need to start using the secondary region.

Next, comes the final service in this architectural design. That is the Azure front door service. This is the point to which internet users will connect to access our application. We will only connect to our app services from the front door. Here, we will set the primary region which will handle our requests. Here, we will also set up our secondary region which we switch over in case of a failure of the primary region. We also enable WAF (Web Application Firewall) services here to provide extra security against attacks like SQL-Injection etc. 

Two things I would like to add to this diagram would be the below:

1. Azure monitor and diagnostic settings for the Database and Front door service to monitor transactions and status.
2. Application Insights for detailed instrumentation of the App services.

Summary

In today’s article, we looked at how we can design an architecture for a multi-region web application to provide redundancy. We also saw how the database used by the web application will be available via a private endpoint and will not be accessible directly from the internet. This gave us a very robust, secure, and highly available web application solution using Microsoft Azure services. This solution is only recommended for applications that require a very high availability level as we are setting it up in multi-regions to prevent any downtime. The costs will be high as we have a duplicated services architecture.