当知识可以被”编译” —— LLM Wiki 企业级实践的三道坎

摘要：传统 RAG 在每次查询时重新检索、重新拼装答案——源文档像被反复”解释执行”的脚本。LLM Wiki 换了一条路：在文档入库时预先”编译”为结构化知识页，此后持续维护、增量更新。经过四个月的实践，我们逐渐遇到了企业级落地中三个绕不开的”坎”。本文拆解这些挑战的根因，介绍基于 Amazon Bedrock、AWS Step Functions 与 Amazon S3 的解法，并给出生产环境中的量化验证。

---

一、引言：解释执行 vs 编译执行

在企业中搭建基于 RAG（Retrieval-Augmented Generation，检索增强生成）的知识问答系统时，我们经常会遇到一些熟悉的问题：

• 同一个问题多次提问，答案并不完全一致；
• 多份文档对同一政策存在不同表述时，模型可能在查询时重新组合这些信息；
• 源文档更新后，旧版本中的结论仍有可能被检索命中。

这些现象背后有一个共同特点：知识的理解和组装发生在查询时。

每次用户提问，系统都需要重新检索文档，再由模型根据当前上下文理解和组织答案。此前问答中已经完成的综合、关联和判断，很难沉淀下来。

如果借用编程语言的概念，可以把传统 RAG 理解为一种”解释执行”：原始文档类似源码，每次查询都要重新读取和解释。

2026 年 4 月，Andrej Karpathy 发布了 LLM Wiki，提出了另一种思路：让 LLM 在文档进入系统时，先把源文档整理成一组结构化、互相关联、持续维护的 Wiki 页面。新文档到来时，系统更新已有页面、创建新的知识实体，并维护引用与关联；用户查询时，主要读取已经生成好的 Wiki。

这更接近一种“编译执行”：把理解文档的智能开销从查询期前移到编译期，再让后续查询复用这份结果。

过去四个月，我们尝试将这一范式用于企业合规知识问答。目前系统持续处理 127 份中英文政策与操作类文档，并维护 204 个活跃 Wiki 页面，通过聊天机器人向内部用户提供带页面级引用的问答。

随着这一范式从个人知识管理扩展到企业生产场景，三个问题逐渐显现：

• 当写入者从单个任务变成多个并发任务时，如何保证编译正确性？
• 当 Wiki 页面越来越多时，如何保证查询完整性？
• 当领域专家开始人工修改编译产物时，如何保证这些修正能够持续存续？

本文将它们称为 LLM Wiki 企业级实践的”三道坎”。下面分别介绍我们观察到的现象、根因、解决方案以及量化结果。

二、实践对象：一条知识编译流水线

我们的实践场景是企业合规知识问答。

管理员持续上传政策、法规和操作指引类 PDF。系统将这些源文档编译成政策、操作指引、概念和升级路径等结构化 Wiki 页面；内部用户通过聊天机器人提问，答案主要来自这些 Wiki 页面，并附带页面级引用。

整个系统构建在亚马逊云科技上，采用事件驱动的 Serverless 架构：

• Amazon S3 保存源文档和知识产物；
• Amazon EventBridge 与 Amazon SQS 负责事件触发和任务解耦；
• AWS Step Functions 编排完整的知识编译流程；
• AWS Lambda 承载解析、索引和查询逻辑；
• Amazon DynamoDB 保存目录、任务状态与规划占位等元数据；
• Amazon Bedrock 承担规划、页面生成和查询阶段的模型推理。

整个知识编译流程可以概括为：

[图 1：知识编译流水线（Ingest → Compile → Serve）]

本文接下来讨论的”三道坎”，分别涉及知识规划与发布、Wiki 查询，以及人工修正后的持续重编译。

三、第一道坎：并发编译让 38% 的页面重复了

3.1 现象：同一个知识，为什么被”编译”了两次？

个人场景中的 LLM Wiki 通常是串行工作的：一次处理一份源文档。

企业场景很难维持这个假设。管理员可能一次上传几十份甚至上百份文档，这些任务会同时进入知识编译流水线。

第一次进行较大规模的批量导入时，我们处理了 65 份 PDF。随后审计发现，生成的 245 个 Wiki 页面中，有 93 页（38%）存在语义重复。这不仅增加了页面数量，更严重的是，重复页面之后还会分别接受新的增量更新，内容逐渐分叉。最终，同一个问题可能因为命中了不同页面而得到不同答案。

3.2 根因：并发冲突发生在语义空间，而不是存储层

问题发生在 Plan 阶段。

Plan 的任务是读取全库目录，然后判断当前文档中的知识应该创建新页面，还是更新已有页面。页面去重依赖一个重要前提：规划任务能够看到此前已经做出的知识划分。

假设任务 A 和任务 B 同时基于同一份目录快照进行规划：A 判断需要创建 tax；B 此时还看不到 A 的决定，于是根据自己的源文档独立判断需要创建 tax-policy。

从存储层看，tax 和 tax-policy 有不同的唯一标识，并没有发生直接的写冲突；但从 Wiki 的语义空间看，它们可能表达的是同一份知识。

传统的锁依赖可以通过唯一标识区分的锁定对象，而这里真正发生竞争的是高维语义空间中的知识实体。两个不同的唯一标识可能对应彼此高度接近、甚至语义等价的知识，因此这种冲突在进入存储层之前就已经发生，传统的锁很难直接识别。

这也意味着，Plan 与普通的无状态 LLM 调用不同：它既读取知识结构，也改变知识结构。前一个 Plan 的输出，本身就是后一个 Plan 应该看到的输入。

3.3 串行规划知识，并发编译知识

对于批量导入，我们最终将 Plan 作为串行的知识规划阶段，而 Parse 和 Generate 等编译环节仍然保持并发。

文档解析完成后，任务按照顺序读取最新的 Wiki Index，完成规划并立即写入 planned 占位；规划完成后，各任务再并发进入 Generate 阶段。

[图 2：串行规划、并发编译——Parse 并发 → Plan 串行 → Generate 并发]

Plan 准备创建新页面时，会先在目录中写入一个轻量占位：

{
  "slug": "tax-policy",
  "type": "concept",
  "status": "planned",
  "summary": "(待生成) 税务政策：适用范围与合规要求"
}

这个页面此时还没有真正生成，但已经成为知识结构的一部分。

因此，如果任务 A 规划出 tax，后续任务 B 在进入 Plan 时就能够看到这一决定，并判断自己的内容应该更新 tax，而不是再次创建 tax-policy。

这里串行化的只是知识结构发生变化的决策点，而不是整个知识编译过程。真正耗时的页面生成仍然并发执行，因此不需要为了保证规划一致性而牺牲整条流水线的并行能力。

在当前规模下，串行规划带来的延迟仍然可控：单次 Plan 约 20 秒，日常增量通常只有数份文档，几乎不会形成明显排队；即使一次导入 200 份文档，Plan 阶段的串行等待也约为一小时，仍适合通过批处理任务完成。

一次上百份文档的批量导入验证了这套设计：全程零人工干预、零任务失败；编译完成后的目录审计中未发现语义重复页面。最热的一张页面汇聚了十多份源文档的贡献，各任务依次将知识合并到同一页面，而不是相互覆盖。

这也给我们留下了一条很实用的经验：LLM 工作流中的并发边界，不一定应该按照”模型调用”划分，而应该按照状态依赖划分。 页面内容可以并行生成，但知识应该被划分到哪些页面，需要看到此前已经生效的规划结果。

3.4 人工审核：内容版本成为新的并发边界

Plan 串行解决了知识实体的重复创建，但 Generate 仍然保持并发。两个任务可能同时基于页面版本 V1 生成草稿，而人工审核可能让这些草稿在数小时甚至数天后才真正生效。

假设草稿 A 和 B 都基于 V1 生成。A 先被批准，页面更新为 V2；如果随后直接批准 B，A 刚加入的知识就会被旧草稿静默覆盖。

因此，我们把乐观并发控制下沉到内容版本。草稿生成时记录页面的基线版本，批准时重新比较当前版本：

def approve(draft):
    if current_version(draft.page_key) != draft.base_version:
        # → rebase → 重新审核
        raise StaleDraft("页面已被更新，请重新生成草稿")
    # 最后一道原子保护
    s3.put_object(Key=draft.page_key, Body=draft.content,
                  IfMatch=draft.base_etag)

最终写入通过 Amazon S3 条件写保证原子性：更新已有页面时，使用 If-Match 校验草稿基线的 ETag。

此时仲裁对象已经从目录中的知识身份变成了页面内容本身——判断”页面是否还是草稿基于的那个版本”，最可靠的裁判就是页面自己。即使两个草稿几乎同时通过前置检查，也只有基于当前版本的写入能够成功，另一个会显式进入冲突处理，而不是覆盖已有内容。

端到端测试中，两个针对同一主题的草稿均基于 V1 生成。第一个批准后页面更新为 V2，第二个被检测为 stale；重新基于 V2 生成并批准后，最终页面同时保留了两份源文档贡献的知识。

这让知识编译中的并发边界变得清晰：Plan 负责决定”知识应该落到哪一页”，内容版本控制则决定”一个草稿是否仍然有资格写入这一页”。对不同层次的竞争使用不同的一致性机制，可以更好地兼顾准确性与吞吐量。

四、第二道坎：答案在 Wiki 里，系统却找不到

4.1 问题不在模型，而在目录

LLM Wiki 的查询通常分成两步：第一步，让 LLM 阅读全库目录，根据每个页面的一行摘要选择相关页面；第二步，再读取这些页面的全文生成答案。

随着 Wiki 页面数量增加，我们遇到了一个看似奇怪的问题：答案明明已经写进 Wiki，系统却找不到。

例如，用户询问某个物流计划的具体费率。答案位于某张 Wiki 页面的第三节，但这张页面在目录中的摘要只是：”介绍该计划的资格要求与操作流程。”

“费率”这个信息并没有出现在摘要中。查询阶段看到的是目录，而不是全部页面正文。因此，无论模型的理解能力多强，只要目录没有暴露这条信息，它就不知道应该打开哪一页。

4.2 一行摘要天然是一种有损压缩

这个问题并不能简单通过”把摘要写得更好”解决。

把几千字的页面压缩成一行，本身就是一种有损压缩。摘要通常能够保留页面主题，却很容易丢掉具体数字、小众术语和隐藏在正文深处的操作细节。而企业合规场景中的问题，恰恰经常针对这些信息。

随着页面数量和单页信息量增加，这种损失会逐渐成为查询阶段的召回瓶颈。

4.3 解法：在目录导航旁边增加全文检索

我们的解决思路很直接：保留原有目录导航，再增加一条能够直接看到正文的检索路径。

我们为 Wiki 正文建立了 BM25 全文索引。索引由 AWS Lambda 在页面发布后增量维护，不需要额外的向量数据库。查询时，两路检索并行执行：

• 目录路径：Amazon Bedrock 根据目录摘要选择相关页面；
• 全文路径：BM25 使用用户原始问题搜索 Wiki 正文，返回 top-2 页面，并应用分数阈值和存在性过滤。

最终候选集合为：

Candidates = Directory Selection ∪ BM25 Top-K

结果总数封顶为 7 页。

这里一个重要的工程选择是：取并集，而不是让 BM25 改写原有目录路径的结果。

我们最初尝试把 BM25 命中的页面作为提示重新交给 LLM，让模型综合两路信息再次选页。实际评测发现，这种方式并不稳定。模型有时会因为 BM25 的字面匹配结果而重新排序甚至删除原本正确的目录选择。

因此，我们最终选择了更简单的方式：让两路独立运行，最后做确定性的并集。目录路径的结果保持不变，全文路径只负责补充候选页面。

这样做的价值并不只是提高平均分，更重要的是：新增的召回路径不会主动删除原来的候选结果。

4.4 量化结果：150 题评测，命中率 70% → 92.7%

我们在当前 204 个活跃页面上构建了一套 150 题的评测集，覆盖 125 个不同页面，包含三类问题：

• 常规题（n=80）：来自真实用户流量——系统实际回答过、且答案来源页仍然存活的问题；
• 摘要盲区题（n=40）：构造题——从页面正文深处提取事实出题，并以程序化检查确保关键信息不出现在该页的目录摘要和标题中；
• 术语题（n=30）：构造题——使用正文中出现、但摘要中缺席的小众术语直接提问。

两臂在同一语料上运行，结果如下：

问题类型	纯目录选页	目录 ∪ BM25
摘要盲区题（n=40）	24/40（60.0%）	37/40（92.5%）
术语题（n=30）	18/30（60.0%）	27/30（90.0%）
常规题（n=80）	63/80（78.8%）	75/80（93.8%）
合计（n=150）	105/150（70.0%）	139/150（92.7%）

两臂整体命中率的 95% Wilson 得分区间分别为 [62.2%, 76.8%] 与 [87.3%, 95.9%]，两个区间没有重叠。逐题核对确认，并集没有让任何一题变差，下界保证兑现。

分桶结果与根因判断一致：纯目录选页在摘要盲区和术语题上的命中率只有 60%——这正是一行摘要压缩掉的信息；值得注意的是，真实流量的常规题同样从 78.8% 提升到 93.8%，说明用户的真实问题中也大量存在目录摘要覆盖不到的长尾信息。

4.5 Prompt Caching：让全目录输入仍然可控

目录导航还有另一个现实问题：随着页面增加，每次查询都需要把完整目录发送给模型。当前 204 个页面对应的目录约为 2.8 万 token。

幸运的是，这部分内容具有一个非常适合缓存的特征：它是一个高度稳定的 prompt 前缀。目录只有在 Wiki 发布新页面时才会变化，而用户问题位于目录之后。

因此，我们利用 Amazon Bedrock Prompt Caching，在目录与用户问题之间设置缓存点。在 30 次连续查询测试中：

• Prompt Cache 命中率为 100%；
• 选页调用的计费成本下降约 90%；
• 该阶段时延从约 3.0 秒下降到 2.3 秒。

这里还有一个容易忽略的实现细节：缓存依赖稳定的 prompt 前缀。因此目录构建必须保持确定性，例如固定排序，并避免在前缀中加入时间戳等动态字段。

这让”完整目录 + 全文旁路”的查询方式在当前规模下仍然保持了可控的成本。

五、第三道坎：如何让人工修正活过下一次编译

5.1 专家改对的内容，下一次编译又改回去了

LLM Wiki 有一个很吸引人的分工方式：人负责选择知识源，LLM 负责维护 Wiki。在个人知识管理中，这种模式已经很有价值。

但进入企业场景后，人工审核很难完全消失。模型生成的页面不可能始终正确。领域专家发现问题后，会直接修改页面。而这些人工确认过的内容，通常也是整个知识库中置信度最高的信息。

问题是：Wiki 页面仍然是编译产物。当下一份相关源文档进入系统时，Generate 阶段会重新生成整个页面。于是可能发生这样的情况：专家上周修正的内容，在本周重编译后消失了。

页面整体看起来仍然合理，而且已经更新到最新版本，因此这种覆盖很难被及时发现。

5.2 为什么文本 diff 不够

一个自然的想法是保存人工修改产生的 diff，然后在下一次编译之后重新应用。但随后我们发现这并不可靠：LLM 重写页面时可能改变措辞、移动段落，甚至重新组织章节。原本基于行号或上下文的 patch 很容易失去锚点。

真正需要保存的并不是”这几个字符发生了什么变化”，而是”专家希望这个事实保持为什么”。

因此，我们把人工修改从文本层提升到了语义层。

5.3 Pin：保存修正意图，而不是文本差异

每次人工修改后，系统生成一条结构化的 pin：

{
  "page": "concept/tax-policy",
  "kind": "correction",
  "claim": "免税门槛按单票货件金额计算，而非按卖家账户累计",
  "anchor": "## 注册门槛",
  "provenance": "human",
  "status": "active"
}

其中最重要的是 claim。它记录的是专家确认过的事实，而不是原始文本的位置或措辞。

下一次页面重新编译之后，系统会逐条检查 pin：

• 如果新的页面仍然满足 claim，即使措辞已经完全变化，也不需要额外处理；
• 如果新的源文档与 claim 发生冲突，系统不会自动覆盖，而是将冲突送入人工审核；
• 如果原来的章节已经不存在，则把该 pin 标记为 orphan，提示审核者重新确认位置。

同时，我们规定：源文档下架触发的重新编译，不自动删除人工新增的知识。 源文档和人工知识因此拥有不同的 provenance，可以分别管理生命周期。

5.4 受控实验：12 个 pin，0 个静默丢失

我们设计了一组受控实验，覆盖三类情况：人工修正应该继续存活；新源文档与人工修正发生冲突；原来的锚定章节被删除。

实验共包含 12 个 pin。重新编译后：

• 8 个应该存活的 pin 全部得到保留，包括页面措辞被完全重写的情况；
• 4 个与新源发生冲突的 pin 全部进入人工裁决；
• 静默丢失为 0。

在复核过程中，系统出现的少量不确定判断也统一进入人工审核，而不是自动覆盖。对于企业知识系统，这种失败方式更加可控：无法确定时暴露冲突，而不是静默选择一个答案。

5.5 人工应该审核产物，而不是计划

这套机制还改变了我们对 Human Review 的理解。

早期版本中，审核发生在 Plan 之后。审核者看到的是：”这份文档准备新建 3 页、更新 2 页。”实践中，这类规划大多数看起来都很合理。真正的问题——事实错误、口径偏差、遗漏——通常只有页面生成完成之后才能发现。

因此，我们后来把审核门移动到了 Generate 之后。系统先完整生成草稿，审核者直接查看最终页面的逐行 diff。批准的内容，就是随后真正发布到 Wiki 的内容。

这使 Human Review 从”审核模型准备做什么”，变成了审核模型实际生成了什么。对于需要人工把关的知识编译系统，这个位置更加有效。

六、三道坎的量化结果

截至 2026 年 8 月，三个问题的改造结果如下：

维度	改造前	改造后	主要新增代价
编译正确性	65 份 PDF 生成 245 页，其中 93 页（38%）存在语义重复	Plan 串行读取最新 Wiki Index；上百份文档批量导入零任务失败、目录审计未发现语义重复页面	Plan 阶段增加串行等待；Generate 仍保持并发
查询完整性	150 题评测目录选页命中 70.0%；摘要盲区题 60.0%	目录 ∪ BM25 达到 92.7%；摘要盲区题 92.5%	每次查询至多额外读取 2 页
人工修正存续	重编译可能覆盖人工修改	12 个 pin 实验中 8 个存活、4 个冲突显式上报、静默丢失 0	对包含 pin 的页面增加语义复核

回看这三个方案，我们发现它们有一个共同特点：正常路径保持简单，只为边界情况增加低成本旁路。

知识规划只在 Plan 阶段串行；BM25 只负责补充目录摘要无法覆盖的信息；pin 复核只发生在包含人工修正的页面上。我们没有为了处理边界情况，把整个主流程变得更重。

另一个共同变化是：系统逐渐把”静默错误”转变成了”显式冲突”。

过期草稿无法直接覆盖新版本；人工 claim 与新源发生冲突时会进入审核，而不是被重新生成的页面悄悄删除。对于合规知识问答，这种可见性本身就是重要的工程属性。

七、落地思考：LLM Wiki 并不是 RAG 的替代品

解决了上述三个问题，并不意味着所有企业知识库都应该采用 LLM Wiki。四个月实践之后，我们更倾向于根据知识本身的性质选择架构，而不是根据技术的新旧选择。

维度	更适合 LLM Wiki	更适合传统 RAG
知识性质	强权威、强一致：政策、合规、SOP、产品事实	宽泛探索、调研、开放问答
正确性要求	强调可追溯、可审核和回答一致性	更关注覆盖范围和信息发现
语料形态	精选文档、相对稳定、周期性更新	海量文档、高频甚至实时更新
维护方式	有明确 owner，可以投入人工审核	希望文档进入系统后立即可查

LLM Wiki 的”编译”本身存在成本。每份新文档需要进行一次模型编译，有些场景还需要人工审核。如果语料达到数万甚至数百万份，或者文档变化速度已经超过审核吞吐能力，那么编译本身就可能成为瓶颈。此时，RAG 的”无需预编译、文档进入后即可检索”仍然具有明显优势。

因此，我们更愿意把两者理解为不同的知识执行模式：RAG 更适合”广而新”的知识，LLM Wiki 更适合”少而精、准而深”的知识。

它们也不必互斥。我们的实践采用 Wiki-first、RAG fallback：已经进入 Wiki 的知识优先读取经过编译和审核的页面；Wiki 尚未覆盖的问题，再回退到通用检索路径，并向用户明确不同来源的置信度差异。

7.1 人的位置从查询期移动到了编译期

这个架构还有一个容易被忽略的变化。

传统知识问答中，用户往往承担最终验证责任：系统给出答案，人判断它是否可信。在知识编译模式下，人工验证可以前移。领域专家在页面进入知识库之前审核一次，此后所有引用该页面的问题都能够复用这次审核结果。对于被频繁查询的政策和 SOP，一次编译期审核可以服务后续大量查询。

因此，LLM Wiki 不只是把模型计算从查询期移动到了编译期，也把一部分人的判断移动到了编译期。

7.2 安全与治理

在企业场景中，我们还采用了几项基础治理措施：

• 为知识编译流程使用最小权限 IAM 角色；
• 对批准、取消、编辑和下架等人工操作保留 append-only 审计记录；
• 对不同敏感级别的知识，在条件允许时优先考虑编译阶段的数据隔离，而不是完全依赖查询阶段的过滤。

尤其是最后一点。如果两个受众本身不应该访问同一批知识，让它们在编译阶段进入不同知识空间，可以减少查询过滤逻辑出错时产生的数据泄漏风险。

八、总结：把智能花在编译期

当知识可以被”编译”，知识库的角色也随之发生变化。它不再只是原始文档的索引，而开始成为一个持续维护的知识产物。

传统 RAG 在每次查询时重新检索、理解和组合知识；LLM Wiki 则尝试把其中一部分工作前移到编译阶段，让后续查询复用已经完成的知识组织结果。

但过去四个月的实践也说明：从个人知识管理走向企业生产系统之后，这条路径并不是平的。我们遇到了三道坎：

1. 知识规划具有状态依赖，需要在 Plan 阶段保证顺序可见性；页面生成仍可并发，最终发布再通过版本控制避免旧草稿覆盖新内容；
2. 一行目录摘要造成的信息损失，需要通过全文检索旁路补充完整性；
3. 人工修正需要从文本 diff 提升为语义 claim，才能在持续重编译中保持存续性。

值得注意的是，这三个问题最终都没有依赖”换一个更强的模型”解决。Amazon Bedrock 提供了知识理解和生成能力，而真正让整个编译流程逐渐可靠起来的，是 Amazon DynamoDB 的状态管理、Amazon S3 条件写、版本控制、确定性检索、事件驱动编排和人工审核等经典工程机制。

这可能也是我们四个月实践中最重要的认识：LLM 让知识可以被编译，而让编译可靠的，仍然是系统工程。

对于正在评估这一范式的团队，我们建议首先判断自己的知识是否具有”少而精、强一致、值得审核”的特点。如果答案是肯定的，那么并发一致性、长尾召回和人工修正的生命周期，很可能也会逐渐成为实际系统需要面对的问题。

希望本文的实践与数据，能够帮助类似场景减少一些重复探索。

说明：本文数据来自特定生产场景及预先构建的固定评测集，实际效果会受到领域、语料规模、模型选择和问题分布等因素影响。

➡️ 下一步行动：

相关产品：

• Amazon Bedrock —— 基础模型调用与 Prompt Caching
• Amazon S3 —— 源文档与知识产物存储、发布阶段条件写
• Amazon DynamoDB —— 目录、任务状态与流水线元数据管理
• AWS Step Functions —— 知识编译工作流编排
• AWS Lambda —— 事件驱动的解析、索引和查询计算

相关文章：

• 大规模视频合并与转码
• Amazon Bedrock AgentCore 数据持久化文件系统：Session Storage 和 Amazon EFS / S3 Files
• 给 Openclaw瘦身-利用Nova MME 和 S3 Vector实现Skill按需召回
• 用 LiteLLM WebSearch Interception 集成 AWS 托管的 Amazon Bedrock AgentCore Web Search 能力
• 通过 LiteLLM 实现 Amazon Bedrock 成本管控：实时限额、多维监控与平台级兜底

九、参考资料

• LLM Wiki — Andrej Karpathy 提出的 LLM Wiki 范式原始设计文档。介绍了由 LLM 编译和维护的个人知识库的三层结构及核心操作，是本文实践的出发点。
• Amazon S3 Conditional Writes — 本文人工审核后发布阶段使用的 S3 功能：基于 ETag 的 If-Match 条件写检测过期草稿，避免旧草稿覆盖新版本。
• Amazon Bedrock Prompt Caching — 本文目录缓存机制所使用的 Amazon Bedrock 功能，可大幅降低稳定前缀的重复计费。

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

本篇作者

---

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