Announcing the AWS Digital Sovereignty Lens for the Well-Architected Framework
TL;DR · AI 摘要
Announcing the AWS Digital Sovereignty Lens for the Well-Architected Framework AWS Architecture Blog Announcing the AWS...
核心要点
- 主题聚焦:Announcing the AWS Digital Sovereignty Lens for
- 来源:AWS Architecture Blog,建议结合原文判断细节。
- AI 分析暂不可用,本条为保底评分与摘要。
宣布 AWS 数字主权镜像用于 Well-Architected 框架 | AWS 架构博客
宣布 AWS 数字主权镜像
2026 年 10 月:本文已更新以确保准确性。
今天,我们推出 AWS 数字主权镜像,这是 Well-Architected 框架的新镜像,为客户提供更全面的指导,帮助其在 AWS 上设计、构建和运营符合主权要求的工作负载。
客户告诉我们,数字主权带来了现有架构指导无法完全解决的独特挑战。主权要求并非以单一简报的形式出现,而是来自隐私、法律、合规和安全等多个团队。这些要求有时会相互冲突。例如,本地化指令要求在境内存储数据,而韧性要求可能需要跨司法管辖区进行复制。
主权还依赖于计算、存储、网络、身份、加密和运营等多个层面的协调选择。某一层的决策可能削弱另一层的控制措施。第三方依赖关系,从软件库到外部 API,本身也存在司法管辖区暴露风险。
该镜像基于我们 2022 年作出的 AWS 数字主权承诺,我们致力于在不牺牲能力、性能、创新和规模的前提下,为您提供云中的主权控制和功能。
定义主权工作负载的五个问题
该镜像将主权视为架构问题。它通过五个问题帮助您确定哪些问题适用于您的工作负载,以及适用的程度:
- 工作负载位于何处?(本地性)
- 谁可以访问它?(访问控制)
- 当条件变化时,它是否能持续运行?(连续性)
- 它能否转移到其他地方?(可移植性和互操作性)
- 能否证明已实施主权控制?(透明性和可审计性)
前四个问题可能相互权衡或影响彼此。例如,限制技术选择到少数供应商的指令可能会限制您的恢复和退出选项。您决定哪个问题优先,接受哪些风险以及原因。第五个问题则承担不同角色,它询问哪些控制措施和证据能证明其他四个问题已得到解决。
镜像包含的内容
如果您进行过 Well-Architected 审查,镜像的结构会很熟悉:支柱、问题和最佳实践。该镜像涵盖六个支柱中的四个,包含 21 个问题和 37 项最佳实践:
- 运营卓越支柱 涵盖主权治理、合规自动化、持续可审计性、合规监控与修复以及监管变更。它回答第五个问题(定义主权工作负载的五个问题):能否证明已实施主权控制?
- 安全支柱 涵盖安全基础、访问控制、控制验证、威胁检测、操作员访问、数据保护和事件响应。它回答前两个问题:工作负载位于何处?谁可以访问它?
- 可靠性支柱 涵盖连续性规划、第三方风险、可移植性与互操作性以及超出技术故障的中断。它回答第三和第四个问题:是否能持续运行?能否转移?
- 性能效率支柱 涵盖主权部署选择和软件依赖性评估,权衡所有五个问题之间的关系。
对于剩余的两个支柱——成本优化和可持续性,现有的Well-Architected指导原则同样适用于主权工作负载。
什么是主权控制?
主权控制基于构建者已使用的功能,包括服务控制策略(SCPs)、资源控制策略(RCPs)、AWS身份与访问管理(IAM)策略、防火墙规则和备份策略。没有任何单一控制措施能单独满足数据驻留、数据主权或连续性要求。它们通过纵深防御策略层层叠加。AWS Control Tower将这些控制措施归类于其数字主权类别下,涵盖数据驻留、细粒度访问限制、加密和弹性。
该框架还涵盖您自行构建的控制措施。这些包括使用AWS CloudFormation Guard验证基础设施模板,使用IAM访问分析器验证访问策略,以及使用AWS Config检测配置漂移。
并非所有主权控制都是技术性的。确定哪些人员可以提供运营支持、从哪些地点提供支持以及在何种权限下提供支持属于运营控制。定期审查这些访问权限是另一项控制措施。技术控制与运营控制相结合,可持续证明您的主权立场。
这就是“按设计实现主权”的实际含义。AWS构建了主权基础架构,例如Nitro系统,该系统强制实施访问限制,确保包括AWS员工在内的任何人都无法访问在Amazon Elastic Compute Cloud(Amazon EC2)中运行的客户数据。您的控制措施则在这些基础架构之上,通过操作控制强化的熟悉策略工具,表达司法管辖要求。
主权要求的出现场景
主权要求不仅限于公共部门工作负载。该框架描述了七种常见的出现场景。其中四种场景展示了其范围:
- 您正在将工作负载扩展到新的司法管辖区,并需要在部署前识别适用的义务。
- 法规限制了谁可以为您的工作负载提供运营支持、从何处提供支持以及在何种权限下提供支持。
- 驻留限制限制了您的灾难恢复选项,您需要确保恢复路径保持在经批准的司法管辖区边界内。
- 您正在采用生成式AI等新兴技术,并需要确认新的数据流和依赖项不会削弱现有的主权控制。
如果一个或多个场景与您的工作负载匹配,该框架就适用于您。
如何使用该框架
该框架与AWS Well-Architected工具配合使用。将其作为自定义框架导入,选择一个工作负载并运行审查。审查将识别高风险和中风险问题,您需要通过有针对性的改进计划进行优先处理和解决。这将主权决策建立在证据基础上,而非假设。
进行首次审查时,请包含工程、法律、合规和安全团队的成员。他们可以将适用的义务与工作负载证据联系起来,优先处理风险,并就补救计划达成一致。记录假设、接受的风险、负责人和后续行动。当法规、工作负载、依赖项或运营条件发生变化时,重复审查。
入门指南
Digital Sovereignty Lens(数字主权框架)今天已发布在AWS Well-Architected自定义框架GitHub仓库中。下载框架定义,将其导入AWS Well-Architected工具,并运行您的首次审查。
To learn how AWS builds sovereign-by-design infrastructure and controls, visit AWS Digital Sovereignty . For help addressing technical and operational sovereignty requirements, consider engaging AWS Digital Sovereignty Competency Partners .
In 2022, we pledged control without compromise. The Digital Sovereignty Lens is how you architect for it.
About the authors
'\"