SaaS组织的动力来自于跨租户共享基础设施资源带来的规模经济。同时，现实世界中的一些因素可能会导致SaaS架构，其中环境中的一些或所有租户都需要专用的（孤立的）基础设施。法规遵从性、嘈杂的邻居、分层策略、遗留技术，这些都是您为租户提供自己的基础设施的首要考虑因素。这被称为孤立或全栈隔离SaaS。
这种方法经常被误认为是托管服务提供商（MSP），即公司的产品是为单个客户一次性安装和管理的。这种方法虽然有效，但并不符合SaaS原则。SaaS模式的关键是采用价值体系，所有租户都通过单一、统一的体验进行管理和运营。这意味着每个租户都在运行同一版本的软件，他们都在同一时间进行部署，他们都是通过同一流程登录的，他们都通过适用于所有租户的单一操作体验进行管理。
这种方法不能提供共享基础架构模型（池）的成本效率。它的分布式特性也会使操作和部署更加复杂。尽管如此，如果做得好，全栈模型仍然可以实现敏捷性、创新性和运营效率目标，这是SaaS思维的核心。
图7中的图表提供了完整堆栈隔离（筒仓）模型的更清晰视图。该模型中的每个租户环境都很简单。您将看到，我们为每个租户提供了一个单独的VPC。这些VPC包含每个租户将使用的完全隔离堆栈。计算和存储结构可以由AWS服务的任何组合组成。关键是每个租户环境都具有相同的基础结构配置和相同版本的产品。因此，添加新租户就像为每个租户提供具有相同基础设施占地面积的另一个VPC一样简单。
您还将注意到，该模型使用Amazon Route 53将传入流量路由到适当的VPC。路由依赖于将子域分配给每个租户的模型。这是SaaS环境中非常常见的模式。这种路由也可以通过检查租户JWT令牌的内容、确定其租户上下文以及通过注入的租户标头触发路由规则来实现。然而，这种方法可能会推高帐户限制，并且可能需要调整以解决租户身份的运行时解析的延迟问题。尽管如此，对于某些SaaS环境来说，它仍然是一个有效的选项。
图7：全堆（筒仓）隔离
虽然本示例说明了VPC每租户模型，但也有其他架构可用于实现全栈模型。一些组织可能选择使用每个租户的帐户模型，其中每个租户环境都部署在单独的配置帐户中。您选择的选项将根据您需要支持的租户数量和您所针对的总体管理经验而有所不同。在某些情况下，您需要支持的租户数量可能超过AWS帐户中可以创建的VPC数量。
统一的入职、管理和运营
当我们研究这种体验的入职、管理和运营时，全栈隔离（筒仓）模型的真正SaaS元素就出现了。为了实现SaaS的全部价值主张，该模型必须引入一组可用于管理和操作所有租户环境的服务。
图8中的图表提供了这些额外服务层的视图。我们在这里介绍的是一组完全独立的服务，这些服务是围绕SaaS提供商的管理和管理经验需求构建的。
图8：管理全栈隔离环境
虽然租户环境的堆栈是由域、遗留和其他需求形成的，但我们的管理经验的堆栈完全由目标和使用模式驱动，这些目标和使用方式可能与租户的目标和使用情况截然不同。
这种管理非常符合经典的无服务器SaaS应用程序模型。您将看到，我们的管理环境有两个切入点。一个是Admin应用程序，它使用AmazonCloudFront和AmazonS3来提供SaaS管理员用来管理和配置租户环境的应用程序体验。您还将看到这里突出显示的注册和API体验。这表示通过公共API请求触发租户登录的能力。该API也可以是SaaS提供商的开发者API体验的一部分。
最后，我们还强调了一组微服务，它们代表了用于协调入职、管理和运营体验的共享服务。基于Lambda的管理、规模和成本效率模型，我们选择Lambda作为微服务的模型。这些服务可以与其他AWS计算服务一起实现。
在图的右侧，您将看到代表每个租户环境的各个VPC。在这个VPC每租户模型中，您需要为管理平面打开一个有效路径，以便能够配置和访问这些租户环境的资源。AWS为此提供了许多选项，包括AWS PrivateLink、VPC对等和Amazon EventBridge。您选择的选项将取决于您正在建立的管理经验的性质。
