The Azure SQL Database Managed Instance is a new implementation model of Azure SQL Database based on the VCore-based purchasing model.

Advantages of using Managed Instance

Easy lift and shift: Customers can lift and shift their on-premises SQL server to a Managed Instance that offers compatibility with SQL Server on-premises.

Fully managed PaaS: Azure SQL Database Managed Instance is designed for customers looking to migrate a large number of apps from on-premises self-built or ISV provided an environment to fully managed PaaS cloud environment.

New Business model: Competitive, transparent, and frictionless business model

Security: Managed Instance that offers compatibility with SQL Server on-premises and complete isolation of customer instances with native VNet support.

Managed Instance security isolation

Managed Instance provides additional security isolation from other tenants in the Azure cloud.

The managed instance security isolation includes:

• Native virtual network implementation and connectivity to our on-premises environment using Azure Express Route or VPN Gateway.
• SQL endpoint is exposed only through a private IP address, allowing safe connectivity from private Azure or hybrid networks.
• It is a Single-tenant environment with dedicated underlying infrastructure (compute, storage).

Structure of Managed Instance

When we create a managed instance, a virtual network will get created. It will have front end subnet, Gateway subnet, a managed instance subnet, and the node that we can deploy as part of managed instance creation will get implemented into the MI subnet. Each node consists of the SQL engine and SQL management. Within the same network, we can deploy multiple nodes also, and these various nodes will form a virtual cluster with Gateway servers.

The entire virtual cluster will have two endpoints. The first endpoint will be for client connections, and the second endpoint is public but will be used by Microsoft to manage this environment. They need to connect to this environment using some automated script or something like that and maintain it for that purpose.

There is an endpoint also for this entire environment to work correctly. It needs to connect to Azure storage and service bus also. So, when we are trying to restrict the traffic from our MI subnet to the outside. Make sure we allow all the traffic related to Microsoft otherwise, our environment might not work correctly.

Finally, in terms of client connections and applications to connect to the database, they can reside in Frontend subnet and connect to the database, or they can live in a peered network when we peer the network which our MI subnet then all the web apps or virtual machines can be able to connect to the database because both networks have peered. We can also join our on-premises applications to the database by creating either a virtual network gateway or express gateway.

All the connections, whether it forms the web apps, or the virtual machines, or on-premises applications, all of them are communicating with the database over a private connection.