Badly worded factor in Resource group guidance about onboarding-guidance

[JackStromberg]

Hi theMichaelB,

Apologies for the late response. A resource group is not a definition of how resources communicate, but rather a logical grouping of what lifecycle they share. For example, if I deploy SharePoint, I may place all of the VMs, network interfaces, disks, etc. in the same Resource Group as likely they will all remain deployed or all be removed at the same time.

If I place two VMs in the same resource group, that does not mean they can communicate to each other; the underlying network configuration or VNets deployed, will dictate how those resources should communicate. When it comes to PaaS resources, those resources are typically not deployed directly to a VNet and are rather exposed with a public facing IP. Since those are multitenant and are public facing, those will not have the isolated restrictions bound to a VNet. A notable exception to PaaS resources communicating by default is Azure SQL, which when deployed comes with an ACL denying all traffic to its public facing endpoint.

Please let me know if this helps,
Jack

[theMichaelB]

Jack,

My point is that the above text implies some level of connectivity based on resource group membership. Which, as you say, doesn't exist.

Someone who is not familiar with resource groups could read that and imagine there is some connectivity magic going on in the background of an RG. I think that sentence would be better changed to explicitely state that a RG has no bearing on resource communication at all.

[JackStromberg]

Hey Michael,

Thanks for the feedback. I agree with you and have gone ahead and updated the document. The original document owner was speaking in terms of PaaS resources, but I agree, we should simply clarify the resource group has no bearing on connectivity.

Please let me know what you think,
Jack