亚马逊AWS官方博客

Site-Builder：给 AI Agent 打造的应用上线平台

摘要：业务人员用 Agent 开发的 Web 轻应用，一句话部署到企业自有 AWS 账号。开源可自建，边缘统一鉴权，按站点隔离，100 个站点月成本约 10 美元。

一、Agent 时代，应用卡在”上线”这一步

借助 AI Agent 写出一个能跑的应用，门槛几乎归零了。即使是非开发人员也能指挥 AI 写出各种各样的工具。甚至因为更理解需求，业务人员自己”开发”的工具往往能精确解决一个特定场景的痛点。比如，财务想要一个费用核验和归类工具、HR 想要一个简历自动评审工具、市场想要一个活动报名网页，直接使用 Kiro，用自然语言描述清楚需求，很快就能得到一份可运行的全栈代码。在这个阶段，瓶颈变成了怎么把应用上线、共享给其他同事。在部署应用时卡住的地方有很多：

  • 域名从哪来、HTTPS 证书怎么配
  • 谁能访问这个应用、怎么按人放行
  • 数据放在哪、合规和审计怎么过
  • 高可用怎么实现、成本怎么算

这些都是”云和部署”的知识，业务人员不懂、也不需要懂。对财务、法务、HR、市场这类涉及敏感数据的内部应用，企业还有一层额外的要求：应用里的数据和业务逻辑要安全可控，谁能访问由业务人员自己决定。

二、选型时该看哪些维度

2026 年整合 Agent 开发 + App 自动部署的应用基本都是 SaaS 形态，比如飞书妙搭、腾讯 WorkBuddy 推出的网页应用生成、Netlify、Lovable、v0（Vercel）等。

2.1 第一组：基础能力

维度 为什么需要
全栈 + 数据库 内部工具几乎都要存数据：台账要记录，报名要收表，清单要勾选。只能托管静态页的方案功能不够丰富，需要全栈 + 数据库
部署到可分享 URL 的速度 业务人员的节奏是”改一句、看一眼”。从说”部署”到同事能打开链接，需要控制在分钟级，1～2 分钟更好
域名与 HTTPS 应用挂在企业自己的域名下，更有辨识度，内部分享同事放心打开，安全团队延用现有的域名规则放行
支持任意 Agent 如果应用上线要求专用 Agent 平台，使用成本和潜在的迁移就高；企业的 Agent 选型如果变化，平台要跟着换的话，之前已经部署的站点迁移会很麻烦。部署能力最好支持以 MCP 的形式暴露，任何 Agent 都能把“写完就上线”串成一步

主流方案大多已经具备前三项。第四项上，部分平台开放了 MCP，可以接入其它 Agent，但部署出去的应用仍然跑在它们的托管云环境上，不在企业自己手里。

2.2 第二组：进阶能力 – 企业内部应用需要进一步增强的

维度 为什么需要
访问控制与企业身份 内部应用要做好权限管理，身份最好来自企业现有的 IdP：入职有，离职没。平台如果要单独的账号体系，就多了一套要单独管、单独审计的身份。
运行在谁的云账号里 决定了数据驻留在哪、网络边界怎么划，以及合规审计能不能沿用企业现有的日志、告警和成本中心。内部应用涉及到敏感数据的，最好是部署在自己能完全控制的云账号里
代码与数据归属 “源码可导出”只解决了代码。运行时、数据库、身份如果还在供应商那里，迁出时要重建整套运行环境
平台本身能否自建（可审计、可修改） 安全团队要审构建、部署、鉴权整条链路，生成的代码只是其中一段。链路在别人手里，就只能信任对方的承诺，没法自己审计、修改或加固
计费与成本 对于低访问频率的内部应用，成本控制压力更大，需要高性价比的方案

2.3 对比目前主流方案

拿两组需求对照分析，目前的主流 SaaS 方案在”自主控制”上都存在空白：身份走服务提供商的体系，平台本身是一个黑盒。能做到的，最多是导出源码。托管 SaaS 的价值和收入都来自”替你运行”。把整个平台交给客户自己运行，盈利模型与这个模式天然相悖。

对于内部敏感应用，往往只能妥协，回到请运维人员手动部署的老路。业务人员缺少经验，没法指导 Agent 选择合适的组件来控制成本；每次上线又都要排期运维手动部署。原本期望的分钟级部署、高频迭代和内部快速推广，被高昂的运行成本和漫长的上线排期拖住，业务人员的”AI 热情”也就慢慢耗掉了。

本文介绍的 Site-Builder 专门针对这些痛点开发，是一个能让企业拿到手、在自己账号里完整部署、能审计能修改的 Agent 应用快速上线平台。Site-Builder 面向 Agent 开发的 Web 轻应用部署需求，比如表单收集、台账、清单、活动报名、数据看板，也支持带关联查询和统计聚合的数据类应用。但需要提前申明，它不是全能的应用托管平台：

  • 站点后端只支持 Node.js （可以进一步添加其它语言）；单次请求最长 30 秒、内存 512MB（平台的默认配置，改代码可以调整）；请求体不超过 1MB（CloudFront 边缘函数限制）
  • 全站不缓存，保证每个请求都经过鉴权，高流量场景的成本要单独评估

高并发、强 SLA、需要复杂网络接入或长时间计算的重量级生产系统，不在 Site-Builder 的适用范围内，这类系统仍应走企业正常的研发与发布流程。

三、业务人员视角：一次对话到上线

下文把部署上线的应用称为站点。对于业务人员的体验：在 Agent 客户端里导入建站 Skill、添加部署 MCP，用企业身份登录一次（支持企业 IdP，如飞书）。不限定 Agent，只要支持 Skill 和 MCP 即可。之后全程只有对话：

  1. 说需求。比如”帮我做一个部门活动报名页，同事填姓名和部门。用我常用的前端设计 Skill 做页面，使用 Superpowers brainstorming 和我沟通需求。完成开发后，使用 Site-Builder Skill 帮我部署。“。Agent 按 Skill 会问清三件事：站点做什么、要记录什么数据、谁能访问。在这个过程中，业务人员仍然可以使用熟悉的其它 Skill 和 MCP 来设计应用 （比如这里展示的 Superpowers brainstorming），Site-Builder Skill 在开发阶段也会参与进来，指导 Agent 做基础设施的选型。
  2. Agent 选档、生成、预览。支持三类应用：静态页面选 static，直接用 S3 托管，简单低成本；要存简单的表单数据，选 fullstack-nosql（DynamoDB）；数据有关联查询或统计聚合的复杂应用，选 fullstack-sql（Aurora DSQL）。这些选型都由 Agent 自动完成；它再按 Skill 里的应用规范生成前端、Express 后端和 site.json，用户可以先在本地跑起来看效果。
  3. 效果满意直接进入部署环节，“使用 Site-Builder 部署”。Agent 打包代码、调 MCP deploy_site 拿到上传地址，上传后调 confirm_upload 启动部署，再每 15 秒调一次 get_deploy_status，把校验代码 → 建库 → 打包构建 → 部署站点 → 上传前端 → 注册路由 → 冒烟测试逐段更新进度。部署完成后拿到 https://app-{site_id}.{企业域名}。
  4. 改权限、加协作者。“改成全组织都能打开”、“只给 a@company.com 访问”，这会走 update_site_permissions，约 1 分钟内全网生效，不用重新部署；“让同事 A 也能改这个站点”走 manage_collaborators。
  5. 看访问记录。“有人访问吗”走 get_site_analytics，返回 PV、独立访客、被拒次数和最近的访问明细。
  6. 迭代。改需求就改代码，用同一个 site_id 再部署一次，URL 不变。更新走 blue/green：新版本过不了健康检查，线上旧版本照常服务。

业务人员在整个过程中，只需要一次性配置 Skill 和 MCP。剩下的就是与 Agent 自然语言的沟通，完成业务的整个部署链路。

四、运维人员视角：一次部署，长期运行

对运维人员来说，Site-Builder 把”逐个应用的部署与维护”变成了”一次部署、长期运行”的平台运维。

  • 不再频繁部署应用：业务人员自己完成上线、更新和下线，运维不用为每个应用排期、手工部署，也不用处理一轮轮的版本发布请求。
  • 不用为每个应用维护高可用：底层都是亚马逊云科技托管的 Serverless 服务，高可用与扩缩容由服务本身承担；每个站点自动获得同样的 blue/green 更新和失败回滚，没有服务器要打补丁、要扩容。
  • 身份只对接一次：平台与企业 IdP（如飞书）对接一次，所有站点共用同一套登录，不用给每个应用单独配登录和账号体系；人员进出在 IdP 里完成。
  • 不需要给业务人员发 AK/SK：所有云基础设施的初始化部署操作由运维人员执行，业务人员电脑上不需要任何云的凭证。
  • 不用给业务人员做云培训：用什么服务、怎么建库、怎么隔离，由 Skill 指导 Agent 自动选型。
  • 统一的安全基线：每个站点都自动具备边缘鉴权、按站点隔离的权限和数据，日志和账单都在企业自己的账号里，审计有据可查。

运维人员要做的，只剩两件事：一次性把平台装进企业的亚马逊云科技账号，之后做少量的日常维护。

五、整体架构：五层 + 可选控制台 + 可选 MCP 交换层

Site-Builder 分为云上基础设施与用户侧的 Skill + MCP 两部分。业务人员只接触后者，前者由运维人员负责。

[图 1：平台五层架构]

各模块能力与所用到的亚马逊云科技服务：

  • [1] 建站 Skill：一份应用规范，Agent 按它生成代码，平台按它校验。内容是 site.json 格式、目录约定和代码红线。哪个 Agent 生成的都行，执行器只认这份规范。
  • [2] 部署 MCP（基于 Amazon Bedrock AgentCore Runtime 部署）：9 个工具全部秒级返回，把慢操作交给状态机异步跑。用户带 OAuth 身份调用：
    • deploy_site：发起部署，更新已有站点时带上 site_id，返回站点代码包的预签名上传地址和任务号 job_id
    • confirm_upload：确认代码包已上传，启动异步部署状态机
    • get_deploy_status：查询部署任务的进度与结果，成功时返回站点 URL，失败时返回原因
    • list_my_sites：列出自己是 owner 或协作者的全部站点，附带 URL、状态和自己的角色
    • undeploy_site：下线站点，删除路由、站点 Lambda 和前端资源；默认保留数据库，显式传 purge_data=true 才永久删除数据；仅 owner 或平台管理员可调用
    • update_site_permissions：在线修改访问策略，包括是否需要登录、全组织可见或指定邮箱名单；约 1 分钟内生效，不用重新部署
    • manage_collaborators：增删协作者或转移所有权，仅 owner 或平台管理员可调用
    • get_site_permissions：查询站点当前的访问策略、owner、协作者，以及调用者自己的角色
    • get_site_analytics：按日、周或月查询 PV、独立访客、被拒次数，以及最近的访问明细
  • [3] 异步执行器（Step Functions + CodeBuild + Lambda）：一个分支状态机，按三类站点类型走不同路径（详见第六节），任一步失败统一进 MarkFailed 终态；站点更新走 blue/green 原子切换。
  • [4] 路由 + 鉴权层（Amazon CloudFront + Lambda@Edge + DynamoDB）：所有鉴权在边缘完成，站点代码零 auth 逻辑。Edge 查路由表、验 RS256 会话、注入 x-user-email，未登录 302 跳转到登录页。
  • [5] 身份层（Amazon Cognito + Lambda）：Cognito 联邦到企业 IdP，以 email 为身份键，对具体 IdP 无感。
  • 会话签名（Amazon KMS 非对称 CMK）：会话 JWT 用 RS256 签名，签名器是 KMS，私钥永不出 KMS；验签在各处用公钥本地完成。
  • 数据（Amazon DynamoDB + Aurora DSQL + S3）：站点表（权限的真源）和路由表都用 DynamoDB，路由表里冗余一份权限字段，让 Edge 查一次就能完成路由和判权。全栈站点的业务库有两种引擎，fullstack-nosql 用 DynamoDB（每站点逐表精确 ARN 隔离），fullstack-sql 用 Aurora DSQL（per-site schema + 非 admin 角色隔离）。前端静态资源用 S3。

5.1 身份与权限

平台对 IdP 的唯一硬要求是：Cognito 能联邦到它，且能拿到用户的 email claim。部署时二选一：接入已有的 OIDC IdP（如飞书、Google），或者在没有任何 IdP 时由平台再建一个 Cognito 池当 IdP，由管理员建户、关闭自注册。飞书没有标准 OIDC 端点，经一个把它的 OAuth 包装成 OIDC 的适配器接入，对平台而言就是一个普通 OIDC IdP。

每个站点有两个角色：owner 与协作者。协作者能部署更新、改访问策略、查状态，但不能下线站点、不能增删协作者，owner 拥有所有这些权限；所有权转移后，原 owner 自动降级为协作者，防止转错人后自己无法访问。另外平台管理员能看到和管理全局任意站点。访问策略（是否需要登录才能访问、组织内所有人可访问还是按 email 名单设置可访问列表）在线修改，不需要重新部署。

5.2 控制台（console.{域名}，可选）

建站只需要在 Agent 里对话，控制台是方便管理员和 owner/协作者 管理站点：看自己的站点和部署历史、改访问策略、增删协作者、转移所有权、看访问统计、下线站点；管理员另有全局视图与管理员名单管理。不部署控制台，只是没有这个可视化界面，站点与 MCP 通道不受影响。

5.3 API Key 交换层（mcp.{域名}，可选）

有些 MCP 客户端只能配静态 Header（比如 API Key），走不了 OAuth。交换层做中转：验 X-API-Key，换成组件自身的机器 token，再原样透明转发到部署 MCP，只多带一个头告诉 MCP 以谁的身份行事。Key 在控制台里自助创建与吊销。配置里不写 [ApiKey] 段，这个组件就不会部署。

5.4 访问统计

Edge 处理页面请求时顺带写一行访问明细（只记页面级、只记 app- 前缀站点，被拒的请求也记），每天定时聚合，可按日 / 周 / 月查询 PV、独立访客与被拒次数。明细保留 90 天。

六、支持的站点类型与四条核心流程

应用规范（site.json 的 tier 字段）中定义了三类站点：

  • static：纯静态前端，无后端、无数据库；
  • fullstack-nosql：前端 + Lambda 后端 + DynamoDB（声明 1–10 张表，每表带主键）；
  • fullstack-sql：前端 + Lambda 后端 + Aurora DSQL（schema 写在 backend/schema.sql）。

全栈站点的后端是 Node.js（nodejs22.x）+ Lambda Web Adapter，约定监听 8080 端口。业务人员不需要关心技术细节，只有简单的”部署 / 更新 / 下线”三个动作。

下面每条流程都有明确的阶段和失败原因：部署任务会记下停在哪一步、为什么失败。出了问题，管理员的 Agent 就可以基于仓库里的代码和方案原理定位故障。

6.1 站点部署（首次）

通过 Step Functions 串起整个构建过程，按站点类型走不同路径：

[图 2：站点部署的 Step Functions 分支状态机]

[1] 校验代码（Validate）：按应用规范校验产物，不合规拒绝部署。

[2] 建库（二选一或跳过）：fullstack-nosql 走 ProvisionDynamoDB，建 1–10 张表；fullstack-sql 走 ProvisionDSQL，建 per-site schema 与非 admin PG 角色；static 无库，直接跳到 [5]。

[3] 打包构建（PackageBackend）：在 CodeBuild 里装依赖并打包。站点代码和它引入的第三方依赖都按不可信处理，所以安装时不执行任何脚本，构建环境也碰不到平台自己的代码包（详见第七节第 3 条防线）。

[4] 部署站点（DeployLambdaSite）：部署站点 Lambda。每个站点的 Lambda 有 blue、green 两个别名（alias），新代码总是部署到备用别名（当前没在对外服务的那个，首次部署用 blue），先通过健康检查才往下走，在线别名全程不动（细节见图 3）。

[5] 上传前端（UploadFrontend）：前端资源上传到私有 S3。

[6] 注册路由（RegisterRoute）：写 DynamoDB 路由表，这是唯一的部署提交点。它之前失败不影响线上，旧站点照常服务；它之后失败按持久化的整条旧路由补偿回滚。随后 SmokeTest 打 Edge 域名确认站点真的可访问，通过才 MarkSuccess。

成功后即得可分享 URL：https://app-{site_id}.{企业域名}。部署一个站点不涉及 CloudFront 变更，只写路由表：静态站点单账号实测约 30 秒；全栈站点多了打包和建库，时间更长。

6.2 站点更新（blue/green）

每个站点有两个 alias（blue / green），各带一个固定 Function URL。正在对外服务的那个是 在线别名，另一个是 备用别名；每次更新轮换，备用变在线，在线变备用。新版本先部署到备用别名，验证通过后再切换；切换只是改路由表里的一个字段，所以要么全切，要么不切。

[图 3：站点更新的 blue/green 原子切换时序]

[1] 读 api_target [2] 反推出在线别名是 blue，于是备用别名是 green。在线别名只从路由表反推，不另存一份，是为了避免两份记录不一致时把新代码部署到正在服务的别名上

[3] update_function_code 上传新代码 [4] publish_version 把它发布成一个不可变的版本，之后不会再被改动。

[5] 把备用别名指向新版本。这里先移别名，下一步再做健康检查。Function URL 绑定的是别名而不是具体版本，健康检查也是通过这个别名调用的，所以验证到的正是外部请求将来要走的那条路径。之所以没有先对新版本做健康检查再移别名，是避免移别名这一步有问题导致实际无法访问。

[6] 做健康检查（通过备用别名调用站点的 /api/health）[7] 返回 200 才继续。不通过则部署失败、路由不切换，线上仍是 blue，用户无感。

[8] 挂 Function URL 并授权 edge role [9] 清除 resource policy 里的非预期语句：给备用别名开放访问入口，只允许 Edge 调用，并清掉多余的授权。这两步都在健康检查之后：新版本没通过，就不该具备被外部调用的条件。访问入口写完还要读回核对：如果它被改成公开访问，备用别名就能绕过 Edge 直接从公网访问，跳过全部鉴权。

[10] 原子切换 api_target → green：把路由表里的 api_target 改成 green 的地址，一次写入完成切换。Edge 会缓存路由 60 秒，所以切换后约 1 分钟内全网生效。这是唯一的提交动作，此前线上一直是 blue；切换后 blue 变成备用别名，留作回滚。

如果路由表里的地址认不出是 blue 还是 green，直接拒绝更新，不去猜：猜错就可能把没验证过的代码直接推到线上。

6.3 站点下线（undeploy）

由 MCP 或控制台直接调用 API 删除资源，顺序为：删路由 → 删站点 Lambda → 删站点专属的 IAM 角色 → 清前端 S3 对象。数据库默认保留以防误删；只有显式传 purge_data=true，才会额外删除这个站点的数据：DynamoDB 表（删前先核对表确实属于这个站点），或 DSQL 里这个站点的 schema 和数据库角色。清理只能走这条路径，站点运行时用的角色本身没有删表或管理数据库的权限。

6.4 站点浏览（运行时，每个请求都走）

部署只发生一次，浏览发生无数次。

[图 4：站点浏览时边缘鉴权的多个节点]

[1] 请求到达：全站禁用缓存，所以每个请求都会经过 Edge 上的鉴权函数。这是刻意付出的代价：CloudFront 只在缓存未命中时才执行这个函数，一旦开了缓存，命中缓存的请求就会跳过鉴权。

[2] 查路由表：按请求域名的子域查 DynamoDB 路由表，查不到返回 404。查询结果在 Edge 上缓存 60 秒，查不到的子域也缓存，这也是改权限约 1 分钟生效的原因。缓存条数有上限，防止有人用大量随机子域名把 Edge 的内存撑爆。

[3] 剥伪造头 + 判权：先删掉客户端自带的身份头（x-user-email、x-user-name 等），防止有人自己填一个冒充别人。判断请求是不是平台自己的页面（登录、控制台），只看请求的域名，不看路由表里任何能被改写的字段。然后判断是否需要登录：只有 require_auth 明确设成 false 的站点才免登录，字段缺失或写错一律按”需要登录”处理。

[4] 验会话：用公钥验证会话 cookie。站点页面可能种下同名的假 cookie 挡在真会话前面，所以同名 cookie 逐个验，任一通过就放行，假 cookie 挡不住真会话。都不通过则跳转到登录页。

[5] 按名单放行 + 注入身份：allowed_users 为 "org" 时组织内所有人可访问，否则按 email 比对名单，owner 和协作者总能访问，不在名单返回 403。字段缺失时按空名单处理，而不是”全组织可见”。通过后注入可信的身份头 x-user-email 与 x-user-name，站点代码直接读它们就知道是谁在访问。

[6] 源站分流：API 请求（/api/*）转发到站点 Lambda，页面和静态文件从私有 S3 读取。两边都只接受 Edge 的签名访问，不对公网开放；静态桶只接受读请求。转发前删掉平台 cookie，站点代码永远拿不到用户的平台会话。

返回方向同理：站点响应里想设置平台 cookie 的，会被删掉，防止站点冒充平台签发会话。此外 Edge 顺带写一行页面级访问明细（见第五节”访问统计”）。

七、安全：一个前提、四道防线

所有站点代码都由 Agent 生成，Site-Builder 平台默认这些代码和依赖都不可信，四道防线都从这个前提出发。

  1. 租户隔离，不信任站点代码能守住边界。 每个站点有独立 IAM 角色，外加 PermissionsBoundary 限定最大能力面（boundary 本身不提供租户隔离）。DynamoDB 站点在 IAM 层隔离：运行时角色只授权本站点的逐表精确 ARN，禁止前缀通配。DSQL 站点在数据库层隔离：per-site schema + 非 admin PG 角色。一个站点越权访问另一个站点的数据，会在各自引擎的那一层被挡住。
  2. 边缘统一鉴权，不信任站点代码会做对鉴权。 站点代码里没有任何鉴权逻辑，全部判定在 Lambda@Edge 完成。
  3. 构建隔离，打包时不执行站点和依赖包里的任何脚本。 npm 装依赖时，默认会自动执行包里声明的安装脚本（如 preinstall、postinstall），而站点代码和依赖包都不可信。所以站点自己 package.json 里的安装脚本和私有源配置，在构建之前就被校验器拒掉；依赖包里的安装脚本，由 npm ci --ignore-scripts 跳过。万一还是有代码在构建环境里跑起来，构建用的角色也碰不到平台自己的代码包。
  4. 信任边界，只读权限冒充不了用户。 登录会话是一张签了名的凭证，能签名就能冒充任何人。签名的私钥锁在 Amaon KMS 里，只有登录服务能用；Edge 只拿公钥做验证，自己签不了。所以账号里只有读权限的人，就算看遍代码和配置，也伪造不出会话。真正能冒充用户的，只剩能调用签名或能改登录代码的少数高权限身份，所以平台的安全边界就是亚马逊云科技账号本身。密钥可以轮换，账号里谁有签名权限也可以用只读脚本定期核对。

八、成本分析

整套架构 Serverless 优先，AgentCore、Lambda、Lambda@Edge、Step Functions、DynamoDB、Aurora DSQL 都按用量计费，闲置时不产生计算费用。剩下有 KMS 密钥月费、存储这类小额固定项。主要成本项是 AgentCore Runtime、站点 Lambda 与 Edge 调用、CloudFront 流量、DSQL 存储与请求、KMS 签名调用（只发生在登录与换码路径上）。

整套架构 Serverless 优先，所有组件都按用量计费，闲置时不产生计算费用；固定项只有 KMS 密钥月费（两把共 $2）、Route 53 托管区这类小额费用。

下面按一个具体场景估算。价格取自亚马逊云科技官方定价页（us-east-1 按需价，2026 年 10 月），部分服务有免费额度。场景模型假设：

  • 持续活跃 100 个站点：40 个用 DynamoDB，60 个用 Aurora DSQL；
  • 每个站点每月 1000 次访问，每次访问约 1 个页面、4 个静态文件、4 次 API 调用；
  • 每月新增或更新 30 个站点（同时也有站点下线，维持 100 个活跃站点不变）；
  • 登录走飞书（经 Cognito 的 OIDC 联邦），月活 300 人，每人每月登录 10 次。
服务 场景模型费用（月）
Amazon Cognito $3.75
Lambda@Edge $1.28
Aurora DSQL $0.66
CloudWatch Logs $0.18
AgentCore Runtime $0.83
CodeBuild $0
DynamoDB $0.34
S3 $0.28
KMS $2.01
Lambda $0
Route 53 / ECR $0.54
CloudFront / Step Functions $0
合计 约 $10

说明：

  • 大部分请求类费用落在免费额度内：CloudFront（每月 1000 万次请求、1TB 流量）、Lambda（每月 100 万次调用）、Step Functions 在两档规模下都基本免费；DSQL 的计算在基准规模内免费。
  • 最大的一项是 Cognito：经飞书 OIDC 联邦登录的用户，Cognito 的免费额度是 50 个月活，超出部分每人每月 $0.015。这一项基本随月活人数线性增长。

相比按席位或 Credits 计费的 SaaS，这些成本明显更具性价比，也更加透明，归属在企业已有的成本中心内，可以用既有的 亚马逊云科技 成本工具做归因与预算。具体金额取决于站点数、访问量和月活人数，可以使用 Pricing Calculator 按实际规模进一步核算。

整套平台的代码与部署手册（site-builder/DEPLOY.md）都在仓库里：https://github.com/aws-samples/sample-site-builder。

➡️ 下一步行动：

相关产品：

相关文章：

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

彭金冬

亚马逊云科技解决方案架构师，负责电商行业客户的架构设计和技术支持，致力于帮助客户实现创新、提升效率。

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用