之前我们多次提到过Resource Manager，也知道Resource Manager是Microsoft Azure提供的一种新型资源管理模式。在Service Management模式（Classic）中，我们通常会在一个订阅里面部署多个项目所需的资源，而且每个项目可能隶属于不同的部门或者团队。这种情况下，我们很难给每个项目核算成本。当然，通过账单也能进行大致的区分，但这需要手工操作。因为在Service Management模式中，即没有“组”的概念也没有“标签”的概念。从系统设计的角度来说，就是缺少对资源实体进行详细描述和分类的属性。市面上很多第三方云管理平台/工具就是在填补这个缺口——为云资源增加额外的描述和属性，从而实现更细致的云资源管理。
在Resource Manager模式中，所有资源都是以资源组（Resource Group）为单位进行管理的。用户首先要创建一个Resource Group，然后将资源（虚拟机、虚拟网络、存储等）创建到指定的资源组（Resource Group）中。当用户删除某个Resource Group时，包含在Resource Group中的所有资源默认会被一同删除！一个即方便又危险的操作。在Classic模式中，经常会遇到因为资源没有删除干净导致产生无谓的费用。
Resource Manager不仅仅是改变了资源管理模式，更重要的是对整个IaaS层进行了重构。我们通过两张图来对比Classic模式和Resource Manager模式：
原来的Service Management模式中，IaaS层是这样的
在Resource Manager模式中，IaaS层是这样的
很明显，在Resource Manager模式中，组件看起来更多了，例如：网卡，安全组，IP地址等都已经成为可以定制和复用的IaaS组件。想想在Classic模式中配置一个多网卡的虚拟机可是一个比较费劲的操作，不但要使用PowerShell而且也不是三五行脚本就能搞定的。在Resource Manager模式中，虚拟机的endpoint已经不存在了，取而代之的是Security Group（安全组）。虽然业界主流的云计算平台都是用安全组来管理虚拟机的网络通讯，但是Microsoft Azure的endpoint也有其独特的优势：endpoint在处理NAT端口映射的时候非常方便，例如：我们可以把一个Linux虚拟机的tcp 22端口（SSH）映射到公网的tcp 2222端口，这样在一定程度上可以降低SSH服务被攻击的风险；NAT端口映射也为多个虚拟机共享一个公网IP地址（云服务）提供了方便。不过endpoint也有很多被吐槽的缺点：例如：端口映射数量有限制、不能批量添加端口映射等，而且endpoint是将Security Group，ACL，Load Balancer，NAT融合到一起，虽然在一定程度上简化了操作复杂度，但是也由此带来了灵活度不足和过于庞大的概念体系。当然，在Resource Manager模式中，还是可以继续使用NAT端口映射的，只不过要在Load Balancer（负载均衡器）上进行配置。
