是否建议为您组织中的每个应用程序订阅一个订阅？答案

【问题标题】：Is it recommended to have one subscription for every application in your organisation?是否建议为您组织中的每个应用程序订阅一个订阅？
【发布时间】：2019-08-28 18:00:25
【问题描述】：

对于大型企业，我们设计了一个 Azure 订阅层次结构：产品和非产品的订阅，每个都有： - 每个订阅 1 个 VNET。 - 层（Web、应用程序、数据库）的资源组 (RG) - RG 有自己的子网和 NSG。

问题是，有很多应用程序。这意味着，例如，所有生产数据库服务器（用于不同的应用程序）都位于同一 RG 的同一子网中（默认情况下可以相互通信）。

为防止不相关的应用程序对话，建议为每个应用程序创建 1 个订阅。由于拥有 1000 个订阅、VNET 和 IP 范围，这将导致复杂性增加和资源重复。这是推荐的吗？有没有更好的方法来管理它？

提前致谢！

【问题讨论】：

标签： azure subscription

【解决方案1】：

您应该考虑设计 Azure 脚手架的方式如下：

订阅数量应始终是应用程序生命周期中预期的独立解决方案和环境（作为标准开发、测试和生产）数量的函数
所有相关数据以及它们各自的应用程序理想情况下都应该驻留在一个订阅中，因此您应该考虑多个资源组
在 VNET 中托管解决方案是通过安全实现设计的一种选择，并且当您最终找到可能导致使用 VPN（S2S 或 P2S）甚至 Azure ExpressRoute 将 colo DC 与 Azure 结合起来的解决方案时，总是会受到称赞
在您提到超过 1000 个应用程序的情况下，考虑到上述想法，您应该开始合理化您希望如何分配订阅以及相应的资源组。请注意，Azure Management Groups 证明对监督和管理此类复杂的解决方案非常有用。
应强制实施为 NSG 和 WAF 控制入口/出口的构建逻辑，以控制流量和应用程序利用

如果您现在可以改进您的问题（或添加后续问题）并询问具体细节以进入下一阶段，那就太好了。

【讨论】：

主要目标是控制（限制）不同服务器组之间的流量。传统方式是创建不同的子网，并使用防火墙根据端口、方向和IP范围（子网）控制流量。但同时，我想限制创建的子网数量。不想为 1000 个不同的子网管理具有 1000 个规则的防火墙规则库。
因此，一种方法是为 Dev、Test 和 Prod 创建管理组。在每一个中，我们都有订阅。订阅具有对等互连的 VNET，因此我们可以控制例如 Dev 和 Prod 订阅之间的流量。然后在每个订阅中，例如在 prod 订阅中，我们可以创建不同的资源组，每个资源组都有自己的子网和 NSG。这些适用于 Web、App 和 DB 层。这样，我们可以控制例如之间的流量。应用和数据库层。
我们仍然有多个不同的应用程序。我们希望限制不同应用程序之间的流量。因此，例如，我们可以创建多个生产订阅（每个应用一个），以及类似的多个开发订阅和多个测试订阅。这导致了很多订阅。作为上述的替代方案，我们可以将所有生产应用程序放在同一个订阅中，在各自的层中（对于开发和测试订阅也是如此）。例如，我们在同一个 RG 中的所有应用程序的所有数据库服务器，在同一个订阅中（在同一个子网上）。
如果这些应用程序作为容器化应用程序托管，那么标签（读取为选择器）非常有用，并且可以创建网络策略来控制入口/出口。
如果这些应用程序不是作为容器化应用程序托管的，那么应该部署 ASG 和 NSG 来控制流量的入口/出口。但这里更重要的情况是，如果有机会，让你的脚手架合理化。