This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .
The first two installments of this mini-series discussed a couple of basic and advanced scenarios involving private endpoints. Today we’ll look at some ways private endpoints cannot be used to implement scenarios where one might expect otherwise.
-1. DAC doesn’t work over a private endpoint
The SQL Server dedicated administrator connection (DAC) is a special way to access SQL Server to diagnose and resolve issues when you can’t connect via standard ports (on Azure SQL Managed Instance, port 1433 for private and VNet-local endpoints and port 3342 for public endpoint).
On managed instances, DAC listens on port 1434. Because private endpoints to managed instances only allow connections on port 1433, this means that you cannot use a private endpoint to establish a DAC connection. It also makes sense from a security perspective—we don’t want to expose a dedicated administrator’s connection pathway in every virtual network where a managed instance is made available.
So, if you need DAC, remember, you cannot access it via private endpoints. You'll need to be in the virtual network to do so.
-2. Instances can’t replicate data over private endpoints
Azure SQL Managed Instance offers a number of data replication mechanisms. Of those, auto-failover groups and Managed Instance link feature establish connections on port 5022. Because private endpoints, again, only carry traffic to port 1433, we cannot establish a failover group nor a Managed Instance link via a private endpoint. The only supported way to do so is by connecting the two networks, e.g., via virtual network peering, as described in each mechanism’s respective documentation.
-3. For high-performance networking, use VNet-local endpoint
Managed instances offer two connection types: proxy and redirect. Proxy is backwards-compatible while redirect is more performant but requires newer drivers. Redirect mode allows SQL clients and applications to connect directly to the primary SQL replica by sending them the address and port from the range 11000-11999. Because a private endpoint always resolves to the same end IP address and port, we cannot use it to establish redirected connections.
If high-performance connectivity is called for, use the VNet-local endpoint and ensure that the port range 11000-11999 is open for inbound connections.
-4. Too many private endpoints
In keeping with the requirements of Azure networking and individual services, you should be careful not to exceed the limits pertinent to private endpoints. For Azure SQL Managed Instance, you cannot have more than 250 private endpoints to a single managed instance. This number is 200 for storage accounts, 64 for key vaults, and other services have their own limitations, as well.
Conversely, you can only have so many private endpoints in one virtual network (up to 1000), and each subscription can hold at most 64000 private endpoints.
If you find yourself designing a system that dynamically creates private endpoints to your Azure SQL Managed Instance or need to place many private endpoints to, for example, Azure Storage, you should be mindful of those limitations and design accordingly.
Closing thoughts
This ends our mini-series of things you can and cannot do with private endpoints to Azure SQL Managed Instance. As always, feel free to ask questions, propose scenarios, and share your thoughts in the comments below!
Some useful links to continue reading:
- The original GA announcement post, Private endpoints GA for Azure SQL Managed Instance (microsoft.com)
- Part 1 of this series, Scenarios with private endpoints to Azure SQL Managed Instance
- Part 2 of this series, Advanced scenarios with private endpoints to Azure SQL Managed Instance
- A five-minute video on Private Link and private endpoints (there’s lots more on SQL MI’s YouTube channel)
- Official documentation at Azure Private Link and private endpoints
- Our SQLBits 2023 talk, Secure networking with Azure and Azure SQL Managed Instance