Azure-docs: Contradiction on VNET Endpoint

[codeputer]

I believe this article about Azure SQL and endpoint contradicts this article: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-vnet-service-endpoint-rule-powershell

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 2eb5097c-fc6e-f0a5-07a6-a84e05aa0bb6
• Version Independent ID: 1004e6b8-344f-6fdc-391a-35c540f4bf9d
• Content: Virtual Network service endpoints and rules for Azure SQL Database
• Content Source: articles/sql-database/sql-database-vnet-service-endpoint-rule-overview.md
• Service: sql-database
• GitHub Login: @MightyPen
• Microsoft Alias: dmalik

[Mike-Ubezzi-MSFT]

@codputer Thanks for the feedback. Is it possible for you to highlight the contradiction, as I am actively investigating this. I want to move this on to the content owner for correction but would like to highlight the issue. Regards, Mike

[codeputer]

Use Virtual Network service endpoints and rules for Azure SQL Database: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-vnet-service-endpoint-rule-overview

Point C – (See below) which I believe is now possible, as I thought there was a recent announcement that this is now possible.

Point A & B are about the Azure SQL firewall rules – which protect the Azure SQL DB from all of Azure connecting to the DB.

Then point C argues that Azure SQL should be on a subnet, removing the connectivity of all of Azure, to only those computers that are on the subnet. This is a combination of IAAS resources ( a VNET) to limit traffic to a PAAS service.

C. Cannot yet have SQL Database on a subnet
If your Azure SQL Database server was a node on a subnet in your virtual network, all nodes within the virtual network could communicate with your SQL Database. In this case, your VMs could communicate with SQL Database without needing any virtual network rules or IP rules.
However as of September 2017, the Azure SQL Database service is not yet among the services that can be assigned to a subnet.

[MightyPen]

@codputer @Mike-Ubezzi-MSFT @DhruvMsft
I'll take a look at this Azure SQL VNet documentation issue during the week of Monday 2018/04/30, with PM Dhruv M. Thanks.
(MightyPen = GeneMi at MS.)

[MightyPen]

The PM and I are supposed to meet today (2018/08/29) to discuss this GitHub Issue about VNet.

[MightyPen]

@codeputer @Mike-Ubezzi-MSFT
Please reassign this Issue 7827 to DhruvMsft .

[CarlRabeler]

@Mike-Ubezzi-MSFT please assign to oslake
@oslake per Joachim

[dcbrown16]

@Mike-Ubezzi-MSFT @oslake so this issue has been open forever, but I think the current fix is that we need to update the part about SQL DB not being available on VNets with a mention of Managed Instances (which are on a VNet).
Maybe just point here: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-managed-instance

[srdan-bozovic-msft]

@codeputer @Mike-Ubezzi-MSFT
It's not just about _Point C_, the whole article is not relevant in SQL MI context as service endpoints couldn't be used to access SQL MI.

I would propose to add sentence to the existing _Note_ at the begining of the text stating this.

This article doesn't apply to Azure SQL Database Managed Instance, Azure SQL Database deployment model, that runs inside Virtual Network.

[CarlRabeler]

updated article to indicate that it does not apply to a managed instance

[CarlRabeler]

@Mike-Ubezzi-MSFT please close as article has been updated. @VanMSFT for his awareness

[Mike-Ubezzi-MSFT]

We will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.