The Cloud has become a standard for most companies when it comes to deploying their production architectures. In order to make that possible, Microsoft and the other Cloud Solution Providers (CSP) provide a large number of services that a customer can consume to implement those architectures. However, creating a service and using many of the defaults within a given wizard can be very different from what is required to deploy a production architecture. This is primarily because of security and privacy requirements, some of them defined by the customer themselves, others because of industry compliance needs.
No matter who is defining the security and privacy requirements, one of the most common requirements for databases is that they be isolated such that only those users and applications that need access to the data can get access to that data. When I talk about isolation, I am specifically referring to network isolation so that the traffic to the database can be completely controlled and locked down.
In this article, I want to focus on that isolation of your databases and what resources you will need to implement for the different flavors of database that you might be using within Azure. Please keep in mind that for those customers that are migrating their databases by using Infrastructure as a Service (IaaS), there is really nothing new to learn. Your Cloud Architects and Engineers will be able to implement your solutions using the exact same capabilities for your databases that they use for all other infrastructure based deployments. (NIC Cards, Network Security Groups, Application Security Groups and potential 3rd-Party solutions)
However, when it comes to Platform as a Service (PaaS) based databases the isolation implementation pattern might look a little different depending on which flavor of database the customer might be using. When considering the available PaaS database platforms, there are usually two different styles of network isolation available: Private Endpoints and Virtual Network Integrations. Implementing both of them will deliver the same result for your database, which is to say that your PaaS database will become an isolated part of one of your virtual networks. However, how each is implemented looks different from the perspective of your Cloud Architect or Engineer and can be viewed differently by your Security organization. With that being said, before looking at how they are both deployed within the scope of your Azure subscription and your Azure Virtual Network, it is definitely important to understand what the differences are between the two.
What and Why?
Some of you might be wondering why there are different types of isolation deployment models for different PaaS database flavors. It all comes down to how the specific PaaS database flavor is implemented by Microsoft within Azure. For example, the MySQL, MariaDB, and Azure SQL implementations deploy databases on top of a server. As such, this allows for a NIC card to be deployed and attached to the underlying server thereby providing an endpoint that can be given an IP address and associated with your VNet and Subnet. Unlike in an IaaS model, you will not have complete control over that server or its networking. The Private Endpoint deployment model allows you to take a PaaS service which Microsoft manages and makes it look like it is a part of your network architecture.
In contrast, the flexible server models for MySQL and PostgreSQL do not have an underlying server that can be used for this network isolation. That is where virtual network integration is leveraged. The flexible server models deploy Platform databases as containers and then make sure that those containers are made a part of your virtual network through software defined networking. No NIC Card, No Server, just a database that sits within your network architecture. However, when this integration occurs, it does take control over an entire subnet, so you will need to be careful with your IP allocation for that subnet depending on your database use case and how much you expect it to grow over time.
Demonstrations
Conclusion
Hopefully this combination of documentation links, demonstrations, and my own personal take on things will help you better prepare for what you will need to think about when deploying PaaS based Databases in Azure in a production architecture. Microsoft has made the process very easy to deploy both a public and private version of each flavor of their supported databases, but it is also extremely important to understand what that means and how those deployments will work or affect your overall cloud architecture. In this instance, the isolation of your missions critical databases is always going to be important. It is great to know that you can implement a PaaS Database in Azure, have Microsoft be responsible for all the underlying infrastructure and you can still get a very secure implementation where you can control who and what applications have access to your data.
As always, please feel free to drop a comment, question or suggestion down below.
