如果您的下一笔企业交易取决于一个您的架构无法回答的问题怎么办？https://t.co/bH5TrUAVtp

5 个多租户 SaaS 架构最佳实践

概述

您正在进行一次大型企业交易的采购评审。您和您的团队已经做了充分的准备工作，并且认为一切顺利。但就在这时，买方问道：

• “数据到底存储在哪里？”

• “谁持有加密密钥？”

• “您的审计日志能证明这一点吗？”

您的架构团队对前两个问题有扎实的答案，但在第三个问题上卡住了。对方皱起了眉头。

业务需求已经发生了变化，许多在 2025 年还属于“锦上添花”的架构实践，如今对企业客户来说已成为硬性要求。最显著的是，AI 工作负载成本的高速增长以及主权数据法规的严格执行，拉大了一个“已交付的产品”与“可卖给多个客户的产品”之间的差距。

ISV 应关注的五项最佳实践是：

• 将租户上下文定义为基础设施属性

• 将分层隔离直接映射到定价

• 强制实施每租户成本归属

• 生成持续合规证据

• 按租户治理 AI 工作负载

不妨将多租户 SaaS 架构的最佳实践视为“交易就绪性检查”。这里列出的每一项实践，都代表了当今企业买家在与您坐到谈判桌前时希望看到的一项具体能力。如果您遵循了这些实践，您就准备好与这些买家达成交易了。通过使用 AWS Well-Architected SaaS Lens 等工具作为审查机制，您可以将多租户架构转变为解决当今企业买家所面临问题的方案。

1. 在 IAM 层定义租户上下文

仅依靠存储在数据库列中的租户 ID 来强制隔离，是一种有风险的租户管理实践。查询中一个不正确的键值就可能返回另一个租户的数据。企业买家正在寻找更健壮、更安全的解决方案。

与其完全依赖应用层，不如在身份与访问管理（IAM）层定义租户上下文。通过请求头中的签名令牌传播租户上下文，您的应用程序代码可以提取这些声明，并将其用作授权过程中的参数。在 AWS 中，这通过显式的 sts:AssumeRole API 调用实现，输入会话标签以生成 AWS Security Token Service（STS）临时凭证，从而允许您直接在 IAM 策略中进行过滤。这有助于使您的租户边界既天生可审计，又防篡改。 这种方法从设计上就是安全的，并且更有可能在一次通过中通过买方的安全审查。

这是您的第一个测试，检验您能否通过企业买方的安全审查：如果一位工程师没有阅读授权文档并引入了一个编码错误，您的租户隔离边界是否依然成立？如果您的边界完全依赖应用程序逻辑，答案很可能是否定的。

您仍然可能会遇到需要行级或应用级控制的共享数据库资源的情况，这在较低层级中很常见。

直接在基础设施中强制实施上下文

AWS 提供了构建这种边界的服务，ISV 负责设计实现方案：

• Amazon Cognito：使用自定义声明安全地将租户 ID 和定价层级携带到您的 JSON Web Tokens（JWT）中，然后使用 Amazon API Gateway 中的 AWS Lambda 授权方进行验证。

• AWS Security Token Service AssumeRole：使用 AssumeRole 注入会话标签，以在每次请求的基础上应用动态的、会话级别的权限。

• AWS IAM：使用会话标签实现基于属性的访问控制（ABAC）。将租户 ID 作为主体标签引用，以强制实施授权。

您的团队交易就绪性检查

• 在当前架构中，是什么在默认情况下阻止了跨租户数据读取？

• 如果我们的一位初级工程师编写了一个完全开放的新服务，会发生什么？

• 我们今天是否在任何 IAM 策略中使用了租户 ID？

2. 将数据隔离策略与定价策略匹配

在基础设施层建立了租户上下文之后，您现在可以根据该上下文所告诉您的信息——具体来说，就是租户属于哪个定价层级——来实施不同的隔离边界。

对所有产品使用相同的架构模式，可能会使您难以证明不同定价层级的合理性，并可能造成不必要的管理开销。您是否为大型企业客户配置不足？是否为中小型企业过度配置？

分层隔离使您能够更精细地调整性能和价格。例如：

• 您的企业级可以包括硬隔离，例如为单租户架构使用专用的 AWS 账户或 Amazon VPC 边界。

• 中端市场客户可以使用桥接模式，例如专用的独立数据库 schema 或容器命名空间。

• 中小型企业租户可以在严格的强制行级数据实施的共享池模型中共享。

您的架构应该在统一的应用程序代码库中正确支持这三个不同的商业层级。虽然您的基础设施配置层自然需要不同的模块来部署企业级 silo 与中小型企业池，但通过分叉您的核心应用程序逻辑来支持顶级客户是不可持续的。

在 AWS 上构建分层隔离架构

您可以使用几个关键的 AWS 原语来构建您的层级：

• AWS Organizations 和 AWS Control Tower Account Factory：使用这些服务为您的企业级自动执行每租户账户配置。

• Amazon Elastic Kubernetes Service（Amazon EKS）：通过评估使用命名空间（用于共享池中的中小型企业）、节点组（用于中端市场桥接）或每租户完整集群（用于企业级 silo）之间的权衡，将您的计算隔离映射到您的定价层级。

• AWS Key Management Service（AWS KMS）：对于需要“自备密钥”（BYOK）能力的顶级客户，您可以使用客户托管密钥来强制实施严格、可验证的加密控制。

AWS Well-Architected SaaS Lens 中的 Core Isolation（核心隔离）概念深入探讨了如何选择、设计和实现这些模式。

您的团队交易就绪性检查

• 如果我们最大的客户明天要求一个新的专用账户，我们需要做什么才能交付？

• 我们是否在向租户收取我们实际上并未强制实施隔离级别的费用？

• 当客户签署合同时，我们的入职管道是否会自动知道该配置哪个隔离层级？

3. 将成本归属到租户、功能和层级

保持成本感知架构有助于您保护和最大化收入。它使您的会计团队能够按需从 AWS 提取每租户成本数据，与收入数据结合后，可以帮助您最大化投资价值。您将拥有保护利润率所需的可见性。

构建成本感知架构需要实施一些具体实践：

• 通过严格执行的标签实现每租户成本归属

• 将 AWS Cost and Usage Reports（CUR）与内部租户元数据关联

• 将 AWS Cost Categories 映射到损益（P&L）科目

如今，对更好的每租户数据的需求主要由运行 AI 工作负载的现实所驱动。如果您的成本归属存在缺口，每租户成本细分很快就会暴露出来。在高密度共享资源环境中，一个运行繁重推理管道的租户很容易消耗比其余共享池租户总和更多的计算资源。如果您无法隔离并归属该租户的消耗量，您将无法准确地对其进行定价和设限。

在 AWS 基础设施中构建成本感知能力

将成本归属视为一项基本工程要求。以下 AWS 服务可以提供帮助：

• AWS Organizations：使用标签策略在您的账户中强制执行严格的标签规则。确保没有适当的租户、层级或功能标识符，就不会配置任何基础设施。

• AWS Cost Explorer：激活租户成本分配标签，以便您的业务和财务团队可以在控制台中轻松按租户跟踪支出。

• Amazon Athena：查询您的 CUR 数据以进行更细粒度的分析。您可以将原始 AWS 账单数据与您的专有租户数据库关联，以计算精确的利润率。

• AWS Billing Conductor：如果您的商业模式涉及根据底层 AWS 消耗直接向多个租户计费，请使用 Billing Conductor 来管理这些参数。

您的团队交易就绪性检查

• 我们当前 AWS 支出中未打标签的百分比是多少？

• 我们的会计团队能否在没有工程部门帮助的情况下，为前 10% 的客户生成服务成本报告？

• 我们哪些功能的交付成本超过了其定价层级所支持的范围？

4. 生成持续的合规证据流

来自 GDPR 等区域数据驻留指令和行业标准的压力，正促使公司自动化证据收集和审计跟踪。能够持续生成证据的架构可以在审计时降低运营开销。

PCI DSS 和类似标准通常要求审计日志至少保留 12 个月。在签署需要满足这些标准的企业合同之前，您需要设计存储和查询路径。从一开始就构建合规流有助于与新客户保持势头。

在 AWS 上自动化证据收集

AWS 提供经过 SOC 审计的基础设施以及其他符合标准资格的服务（例如符合 HIPAA 资格的服务），但合规性最终取决于您如何配置和运营您的服务和负载。

您可以使用几个关键服务来自动化证据生成：

• AWS CloudTrail：使用 CloudTrail 创建用于长期保留的 Amazon S3 存储库，并使用 Amazon Athena 提供可查询的审计证据。

• AWS Config：部署直接映射到您所需标准（如 CIS、NIST 和 PCI DSS）的一致性包。

• AWS Security Hub：在审计周期开始之前，根据行业标准监控您的安全态势。

• AWS Audit Manager：自动化特定框架的证据收集，以实现更高效的审计响应。

您的团队交易就绪性检查

• 为了响应审计员的要求，我们生成某个特定租户所有操作记录需要多长时间？

• 我们的哪些控制措施是自动生成证据的，哪些需要我们的工程师截图控制台？

• 为年度合规审计做准备，是否要求我们放慢或暂停新功能的开发？

5. 按租户治理 AI 工作负载

AI 工作负载考验了此列表中其他实践的弹性。建立严格的 AI 数据边界，是将定制能力从可用的原型转变为可销售、生产就绪且企业买家信任的功能的关键。

正确的 AI 工作负载治理需要多项重要能力：

• 租户范围内的模型访问

• 每租户使用配额

• 训练和推理的数据边界强制实施

• 提示词和输出的审计

在没有租户范围治理的情况下引入 AI 功能，通常会带来结构性挑战。例如，在共享的多租户数据上训练 AI 在许多司法管辖区被视为合规问题。未经明确同意就在共享租户数据上训练模型，会在您的多租户架构中产生新的合同和监管负担，而大多数现有数据管道并未为此设计。在 AI 功能发布之前，必须建立谨慎的隔离和治理机制。

在 AWS 上管理 AI 边界

您可以使用几种不同的 AWS 服务来治理 AI 工作负载：

• Amazon Bedrock：使用详细的模型调用日志记录来跟踪每个租户的 AI 使用情况，利用 IAM 和 STS 会话标签、带有 AWS Lambda 授权方的 API Gateway 以及每租户资源策略。

• Amazon Bedrock Guardrails：强制实施特定于租户的安全策略，例如 PII 编辑和主题限制。

• Amazon Bedrock Knowledge Bases：通过为每个租户配置独立的知识库（带有 IAM 策略）来实现租户范围内的向量存储。

• AWS PrivateLink：帮助确保推理流量不经过公共互联网。

• Amazon CloudWatch：为租户范围内的使用监控创建自定义指标。

您的团队交易就绪性检查

• 租户 A 的提示词能否到达租户 B 的会话？我们能否证明它不能？

• 我们能否将每租户的 AI 工作负载基础设施成本与一般计算支出放在同一份报告中？

• 当租户要求将其数据从微调管道中排除时，我们是否有相应政策？

最佳实践推动获客与留存

这些最佳实践都不是新事物，但忽视它们的成本会不断累积。现在比以往任何时候都更重要的是，制定一个严格的计划来管理您的多租户 SaaS 应用程序，以跟上新的 AI 工作负载、法规和不断扩大的客户需求。

这里详述的结构性最佳实践旨在按顺序构建。建立基础设施级的租户上下文可以实现分层隔离。实施分层隔离可以实现每租户成本归属。准确的归属可以生成持续合规证据，而保持持续证据可以实现正确的 AI 工作负载治理。将这些实践一起构建，您将获得能够满足任何新买家需求的架构。

要评估您的多租户系统，请使用 AWS Well-Architected SaaS Lens 作为客观审查机制。一旦您的基础设施经过验证并达到企业就绪状态，您就可以与 AWS ISV Accelerate 等联合销售计划对接，以支持您的更广泛销售策略。

从 Well-Architected SaaS Lens 审查开始，看看您的架构今天表现如何。

了解更多关于面向独立软件供应商的 AWS。