简介这份PPT资料围绕基于AWS的SaaS平台架构展开面向正在从传统软件向SaaS转型的ISV架构师、技术负责人及云计算学习者系统梳理了SaaS模式兴起的动因与AWS平台的技术优势。内容涵盖身份管理、多租户三种模式Silo、Bridge、Pool的优劣对比、应用分层隔离、管理与监控、测量与计费、DevOps业务敏捷性以及大数据、物联网、人工智能等AWS服务在SaaS场景中的落地方式可帮助读者建立从架构选型到运维计费的完整认知框架。资源包内含1个pptx文件大小约1.21MB以图文并茂的幻灯片形式呈现便于直接用于内部技术分享或方案汇报。目前已有143人学习下载适合需要快速理解AWS SaaS架构设计思路、对比多租户隔离方案并规划平台演进路径的读者参考。1. 从一份 PPT 说起AWS SaaS 架构到底解决了什么问题很多做 ISV 的朋友第一次接触「基于 AWS 的 SaaS 平台架构」这个概念是在客户问出那句要命的话之后——「你们能不能按租户出账单」。这个问题背后牵扯的是身份体系、数据隔离、计量计费三条线任何一条没设计好后面改起来都是血泪经验。这份 PPT 把 AWS 对 SaaS 的理解拆成了两个视角运维管理角度身份、隔离、监控、计费和应用开发角度DevOps、大数据、IoT、AI本质上是在回答一个问题——多租户这件事到底怎么在云上落地。它适合三类人正在把单体软件改造成 SaaS 的 ISV 架构师、需要给多租户系统做隔离方案选型的后端负责人、以及要搭建租户计费体系的平台工程师。PPT 本身不是代码但它给出的分层模型和 AWS 服务映射关系可以直接当作架构评审的检查清单来用。下面我按「先立模型、再落实现、最后避坑」的顺序把这份材料里真正能抄作业的部分拆开讲。2. 多租户三种模式选型Pool、Silo、Bridge 的边界在哪2.1 三种模式的本质差异PPT 里把多租户归纳为三种模式这个分类是整个架构的地基选错了后面全是返工。Pool 模式是所有租户共享同一套基础设施数据存在一起靠 TenantID 区分。它的优势很直接成本低、集中化管理、配置简单、集中分析和计量都方便。但劣势同样致命——租户之间会互相影响一个租户跑个大查询可能拖垮所有人合规性上很难过审可用性是 All or nothing基础设施挂了全体租户一起挂。Silo 模式反过来每个租户一套独立环境。合规性没问题租户之间完全隔离可以针对单个租户做环境优化可用性也是租户级的。代价是成本高、灵活性低、管理和配置都复杂集中分析和计量反而不好做。Bridge 模式是中间态部分共享部分隔离比如计算层共享但数据库独立。PPT 里没有展开 Bridge 的细节但实际项目中这是最常见的折中方案。2.2 选型决策表维度PoolBridgeSilo单租户成本最低中等最高隔离强度弱逻辑隔离中部分物理隔离强完全物理隔离合规适配难视情况容易运维复杂度低中高租户级可用性不支持部分支持支持适用租户规模大量小租户混合少量大租户选型时我一般会问三个问题租户里有没有金融、医疗这类强合规行业有没有单租户体量大到能影响别人的团队运维人力能不能撑住 Silo 的复杂度三个问题里有一个答案是「是」就往 Silo 或 Bridge 靠。2.3 用标签体系落地租户识别不管选哪种模式租户上下文必须贯穿整个请求链路。PPT 里提到的「资源打标签」是最基础的落地手段。下面这段是给 AWS 资源打租户标签的常见写法import boto3 def tag_resource_with_tenant(resource_arn, tenant_id, env): 给 AWS 资源打租户标签用于后续计费和隔离策略 resource_arn: 资源唯一标识如 arn:aws:rds:... tenant_id: 租户唯一 ID env: 环境标识 prod/staging client boto3.client(resourcegroupstaggingapi) response client.tag_resources( ResourceARNList[resource_arn], Tags{ TenantID: tenant_id, # 租户标识计费隔离的核心键 Environment: env, # 环境区分避免测试资源混入账单 ManagedBy: saas-platform # 标记由平台统一管理 } ) return response[FailedResourcesMap]这段代码的关键在TenantID这个标签它是后面计费统一视图的关联键。Environment标签是为了防止 staging 环境的资源被算进生产账单。ManagedBy是给运维用的方便批量筛选平台管理的资源。返回值里的FailedResourcesMap一定要检查有些资源类型不支持标签静默失败会导致计费漏单。3. 身份管理落地UserID TenantID 怎么串成 SaaS ID3.1 SaaS ID 的构成逻辑PPT 里给了一个很清晰的公式用户 ID 租户 ID SaaS ID。这个公式看起来简单但它是整个身份体系的锚点。传统应用里用户 ID 是唯一的但在 SaaS 里同一个邮箱可能属于多个租户——bobabc.com 在租户 A 是 Admin在租户 B 可能只是 Viewer。所以身份不能只看 UserID必须带上 TenantID 和 Role 才能确定一个完整的会话上下文。PPT 里还提到了应用程序租户身份代理、身份信息提供者、MFA、AWS Cloud IAM 策略这几个组件。实际落地时常见做法是用 Amazon Cognito 做用户池在 token 的自定义声明里塞入 tenant_id 和 role后端每次请求都从 token 里解出这两个值来做鉴权。3.2 Cognito 自定义声明的配置步骤第一步在 Cognito 用户池里创建一个 Pre Token Generation Lambda 触发器。第二步在 Lambda 里根据用户属性查出所属租户列表。第三步把 tenant_id 和 role 写入 token 的 claims。def lambda_handler(event, context): Cognito Pre Token Generation 触发器 在签发 token 前注入租户上下文 user_attributes event[request][userAttributes] # 从用户属性中读取租户归属实际项目中通常查数据库 tenant_id user_attributes.get(custom:tenant_id, unknown) role user_attributes.get(custom:role, viewer) # 注入到 ID Token 的自定义声明中 event[response] { claimsOverrideDetails: { claimsToAddOrOverride: { tenant_id: tenant_id, # 租户标识后端鉴权核心 role: role, # 角色决定权限边界 saas_id: f{user_attributes[sub]}#{tenant_id} # 复合 ID } } } return eventclaimsToAddOrOverride里加的字段会出现在 ID Token 的 payload 中后端用 JWT 库解出来即可。saas_id用#拼接是为了避免 UserID 和 TenantID 里可能出现的分隔符冲突实际项目里也可以用 UUID。注意custom:前缀是 Cognito 自定义属性的固定格式漏了前缀读不到值。3.3 IAM 策略的租户维度隔离身份解出来之后还要落到 IAM 策略上做资源级隔离。PPT 里提到 AWS Cloud IAM 策略常见做法是用 IAM Policy 的 Condition 限制租户只能访问自己标签的资源{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: s3:GetObject, Resource: arn:aws:s3:::saas-data/*, Condition: { StringEquals: { s3:ExistingObjectTag/TenantID: ${aws:PrincipalTag/tenant_id} } } } ] }这段策略的意思是只有当 S3 对象的TenantID标签和当前请求者身份上的tenant_id标签一致时才允许读取。${aws:PrincipalTag/tenant_id}是动态变量从请求者的身份标签里取值。这样即使代码里写错了路径IAM 层也会兜住。前提是每个 IAM 角色都要打上tenant_id标签这一步容易漏。4. 数据隔离与计费从数据库分表到统一账单视图4.1 多租户数据库的三种隔离粒度PPT 里把数据隔离拆成了三个层次每个租户一个 DB 实例、每个租户一个数据库、每个租户一张表。这三种粒度的取舍逻辑和前面的 Pool/Silo 模式是对应的。每租户一个 DB 实例隔离最强成本最高适合 Silo 模式。每租户一个数据库共享实例但库级隔离是 Bridge 模式的典型做法。每租户一张表共享库共享连接池靠 TenantID 列区分是 Pool 模式的标准操作。PPT 里给了一个示例表结构Tenant 1 和 Tenant 2 的数据在同一张表里用 TenantID 列区分。实际选型时还要考虑连接池的问题。每租户一个库的话连接数会随租户数线性增长RDS 的 max_connections 很容易被打满。常见做法是引入 ProxySQL 或者用 RDS Proxy 做连接池复用。4.2 租户级计费的实现路径PPT 里提到了 Detailed Billing Report、资源打标签、API 计费、租户计费统一视图这几个组件。落地路径是这样的先用标签给所有资源打上 TenantID然后开启 AWS Cost Allocation Tags等 24 小时后标签会出现在 Cost Explorer 里最后用 Cost Explorer API 按标签维度拉取每个租户的成本。# 开启租户标签作为成本分配标签 aws ce update-cost-allocation-tags-status \ --cost-allocation-tags-status \ KeyTenantID,StatusActive \ KeyEnvironment,StatusActive # 按租户维度查询当月成本 aws ce get-cost-and-usage \ --time-period Start2025-01-01,End2025-01-31 \ --granularity MONTHLY \ --metrics BlendedCost \ --group-by TypeTAG,KeyTenantID第一条命令激活标签注意标签激活后不会追溯历史数据只能从激活时刻开始统计。第二条命令按 TenantID 分组拉成本返回结果里每个租户一条记录。BlendedCost是混合费率如果租户享受了预留实例折扣用UnblendedCost更准确。这个 API 有调用频率限制批量拉取时记得加分页和重试。4.3 统一账单视图的数据模型PPT 里提到「租户计费统一视图」实际落地时通常需要一张汇总表来关联资源消耗和租户信息。常见做法是在 Redshift 或 Athena 里建一张宽表把 Cost Explorer 的数据和租户元数据 join 起来CREATE TABLE tenant_billing_view AS SELECT c.tenant_id, t.tenant_name, t.plan_type, c.service_name, SUM(c.cost) AS total_cost, c.billing_period FROM cost_explorer_raw c JOIN tenant_metadata t ON c.tenant_id t.tenant_id WHERE c.billing_period 2025-01 GROUP BY c.tenant_id, t.tenant_name, t.plan_type, c.service_name, c.billing_period;cost_explorer_raw是从 Cost Explorer API 拉下来的原始数据tenant_metadata存的是租户的套餐类型、合同价等信息。join 之后就能算出每个租户的实际成本和毛利。plan_type字段是为了区分包年包月和按量付费的租户计费逻辑不一样。5. 避坑指南SaaS 架构落地时最容易翻车的五个点5.1 租户上下文在异步链路里丢失现象同步接口里 TenantID 传得好好的一到 SQS 消费或者 Lambda 异步触发就变成 null导致数据写错租户。原因租户上下文通常存在 ThreadLocal 或者请求作用域里异步线程拿不到。SQS 消息体里如果没显式带上 TenantID消费端就无从得知。解决所有异步消息的 payload 里强制包含 tenant_id 字段消费端第一件事就是从消息体里恢复租户上下文。Lambda 的话可以用 InvocationType 为 Event 的异步调用在 payload 里带上租户信息。5.2 标签激活后历史账单对不上现象刚给资源打完 TenantID 标签去 Cost Explorer 里按标签查发现只有最近几天的数据之前的全是「无标签」。原因AWS 的成本分配标签激活后只对激活之后产生的费用生效不会追溯历史。而且标签激活本身有最长 24 小时的延迟。解决上线前就把标签规范定好所有资源创建时就打标签。如果已经上线了接受历史数据缺失的事实从激活日期开始做租户计费。别想着补历史账单补出来的数对不上更麻烦。5.3 Pool 模式下单租户拖垮全库现象Pool 模式跑了一段时间某个大租户跑了一个全表扫描的报表查询数据库 CPU 直接打满所有租户的请求全部超时。原因Pool 模式共享数据库连接和计算资源没有租户级的资源配额限制。解决在应用层加租户级限流用 Redis 做令牌桶每个租户每秒最多 N 个请求。数据库层可以用 RDS 的 Resource Groups 或者 ProxySQL 的 query rule 做租户级查询超时。如果预算允许把大租户迁到独立的 Bridge 或 Silo 环境。5.4 Cognito 自定义属性读不到值现象Pre Token Generation Lambda 里user_attributes.get(custom:tenant_id)返回 Nonetoken 里没有租户信息。原因Cognito 自定义属性必须在用户池里先创建而且创建后不可修改名称。如果用户注册时没有写入这个属性读出来就是空的。解决在用户池的 Attributes 配置里提前创建custom:tenant_id和custom:role注册流程里强制写入。已经存在的用户需要跑一次批量更新用 AdminUpdateUserAttributes API 补上属性值。5.5 IAM 策略里的 PrincipalTag 不生效现象IAM 策略里写了${aws:PrincipalTag/tenant_id}条件但请求还是被拒绝。原因PrincipalTag 取的是发起请求的 IAM 角色或用户的标签如果角色本身没有打 tenant_id 标签这个变量解析出来是空字符串条件永远不匹配。解决确保每个租户对应的 IAM 角色都打了tenant_id标签。用aws iam tag-role命令批量打标。另外注意如果用的是 Cognito Identity Pool 换取的临时凭证标签要打在 Identity Pool 的角色上不是用户池上。6. 进阶技巧用 Serverless 做租户级弹性伸缩PPT 最后一页提到了 AWS Serverless 架构的三个特征事件驱动、持续扩展、按需付费。这三个特征放到多租户场景里最直接的用法就是给每个租户做独立的弹性伸缩策略。传统做法是所有租户共享一个 Auto Scaling Group扩容时一起扩缩容时一起缩。但租户的流量曲线往往不一样——A 租户是早高峰B 租户是晚高峰共享伸缩组就会导致资源浪费。用 Lambda 做租户级的事件处理每个租户一个并发配额天然就是隔离的。具体做法是给每个租户分配一个独立的 SQS 队列Lambda 的并发数按租户的套餐等级来配。免费版租户并发上限设 5企业版设 100。这样大租户跑批量任务不会挤占小租户的资源。# serverless.yml 片段按租户配置 Lambda 并发 functions: tenantProcessor: handler: handler.process reservedConcurrency: 100 # 企业版租户的并发上限 events: - sqs: arn: !GetAtt TenantQueue.Arn batchSize: 10 functionResponseType: ReportBatchItemFailuresreservedConcurrency是预留并发设了之后这个函数最多同时跑 100 个实例不会抢占其他函数的配额。ReportBatchItemFailures让 Lambda 只重试失败的那条消息而不是整批重试避免重复处理。这个配置在租户数量多的时候要小心Lambda 账户级并发上限默认是 1000租户多了要提前申请提额。验证租户隔离是否生效我一般会跑一个简单的压测用两个租户的凭证同时打请求观察 CloudWatch 里两个函数的 ConcurrentExecutions 指标是不是各自独立变化。如果一条涨另一条也涨说明隔离没做到位大概率是共享了同一个队列或者同一个并发池。从那以后我每次做多租户架构评审都会强制走一遍「租户上下文全链路追踪」——从 API Gateway 的请求头开始到 Lambda 的环境变量到 SQS 的消息体到数据库的 TenantID 列到 S3 的对象标签到 Cost Explorer 的成本标签每一环都确认 TenantID 没有断。断在哪一环哪一环就是未来的故障点。希望帮到你。本文还有配套的精品资源点击获取
