云计算的理念与责任分担

云计算是一种不拥有IT资源，只在需要时按需租用、按实际使用量付费的使用方式。从提出需求到开始使用的时间很短，一旦退还资源，计费也随即停止。事先确定所需数量并采购设备、连电源和空调都由本公司自行管理，都是本地部署（on-premises）的做法，由于必须提前确定数量，因此会出现资源过度配置或容量不足的问题。签约期间内无法变更资源数量的说法，与云计算之后可自由增减的前提正好相反。

按量付费（Pay-as-you-go）是无需预付款也无需长期承诺、只按实际使用量付费的原则。可以根据实际需求而非预测进行伸缩，从而降低资源过度配置的风险。以固定期限承诺使用量来换取更低单价的是承诺节省（Save when you commit）；使用量越多单价越低的是用得越多越便宜（Pay less by using more）；整合为按月固定收费、不产生超额费用的是统一定价（Flat rate），指的都是其他原则。

用得越多越便宜（Pay less by using more）是指在 S3 和数据传输等场景下采用阶梯式收费体系，使用量越多，每GB的单价就越低的原则。以固定期限承诺使用量来降低单价的是承诺节省（Save when you commit），Savings Plans 就属于这一类。按实际使用量逐次付费的是按量付费（Pay-as-you-go），整合为按月固定费用、不产生超额费用的是统一定价（Flat rate）。这4项原则目的各不相同，并非互斥，而是可以组合使用。

承诺节省（Save when you commit）是指像 Savings Plans 那样，以1年或3年的期限承诺特定的使用量水平，以换取计算或机器学习相关服务费用折扣的原则。月费固定、不产生超额费用的是统一定价（Flat rate），并非顺延机制。使用量越多单价越低的阶梯式体系属于用得越多越便宜（Pay less by using more）。不附带承诺、随时可以停止的是按量付费（Pay-as-you-go）的性质，与以承诺为前提的这项原则恰好相反。

截至2026年8月，在官方考试指南列表中被列为 Foundational 的，是 AWS Certified Cloud Practitioner（CLF-C02）和 AWS Certified AI Practitioner（AIF-C01）这两项。Developer - Associate（DVA-C02）与 Data Engineer - Associate（DEA-C01）都属于 Associate 级别，Advanced Networking - Specialty（ANS-C01）属于 Specialty 级别。名称末尾带级别名称的认证可以据此判断，但 Cloud Practitioner 和 AI Practitioner 的名称中并不带级别名称，需要记住这两项就是 Foundational。

CLF-C02 是 AWS Certified Cloud Practitioner 的考试代码。CLF 代表 Cloud Practitioner，末尾的 C02 表示改版的代数。AWS Certified AI Practitioner 的代码是 AIF-C01，AWS Certified Developer - Associate 是 DVA-C02，AWS Certified Data Engineer - Associate 是 DEA-C01。认证名称有时会更改，但考试代码在改版之前不会变化，因此判断教材是否为现行版本时，看考试代码最为可靠。

AWS Certified Solutions Architect - Professional 的考试代码是 SAP-C02。SAA-C03 同样属于 Solutions Architect，但属于 Associate 级别；SOA-C03 是 CloudOps Engineer - Associate 的代码；SCS-C03 是 Security - Specialty 的代码。开头3个字母相似容易混淆，可以记成 SAA 对应 Associate、SAP 对应 Professional。

CLF-C02 的 Exam Guide 规定，Cloud Concepts 占24%，Security and Compliance 占30%，Cloud Technology and Services 占34%，Billing, Pricing, and Support 占12%。因此比例最大的是 Cloud Technology and Services，最小的是 Billing, Pricing, and Support。虽然作为入门认证容易让人以为概念部分占比最高，但实际上考查服务知识的知识域占比最大，其次是安全。学习时间的分配可以直接参照这一比例。

SAA-C03 的 Exam Guide 规定，Design Secure Architectures 占30%，Design Resilient Architectures 占26%，Design High-Performing Architectures 占24%，Design Cost-Optimized Architectures 占20%。占比最大的是安全架构的设计。这4个知识域的名称可以与 Well-Architected 的支柱对应记忆，依次是安全性、可靠性、性能效率、成本优化。

运维方向的 Associate 认证名称由 SysOps Administrator 改为 CloudOps Engineer，考试代码也由 SOA-C02 变为 SOA-C03。旧代码的最后应考日为2025年9月29日，新代码自2025年9月30日开始。Data Engineer - Associate 与 Machine Learning Engineer - Associate 并非运维方向的后继认证，而是分别在数据和机器学习领域新设立的认证。DevOps Engineer - Professional 是早已存在的 Professional 级别认证，级别也不同。

AWS 官方将 AWS 一方的责任称为「Security of the Cloud」，并将其定义为保护运行 AWS 云中所提供全部服务的基础设施，即硬件、软件、网络和设施的安全。应对在实例中部署的应用软件的漏洞，是选择 EC2 时用户自身的责任。选择数据的加密选项以及通过 IAM 赋予权限，无论选择哪种服务都仍属于用户的工作，两者都属于「Security in the Cloud」（云中的安全）一侧。

官方明确指出「客户的责任由客户所选择的 AWS 云服务决定」。也就是说，根据所选服务的不同，作为安全责任一部分、需要用户进行的配置工作量也会随之变化。支持计划决定的是获得技术支持的方式，并不会改变责任的边界。区域和可用区涉及的是资源部署位置，使用期限和使用金额涉及的是计费，都不是决定责任范围大小的因素。

官方指出，在像 EC2 这样需要配置的服务中，用户需要负责「客户机操作系统的管理（包括更新和安全补丁）、在实例上安装的应用软件和实用程序、安全组的设置」。因此对操作系统应用补丁属于用户的责任。在 EC2 中，AWS 运营的范围止步于物理基础设施和虚拟化层，并不包括实例内部的操作系统。支持计划是获得技术支持的合同，并不会转移责任的归属。

对于抽象化或托管式服务，官方指出「由 AWS 运营基础设施层、操作系统和平台，客户通过访问端点来存储和获取数据」。留给用户的是自身数据的管理（包括加密选项）、资产的分类，以及通过 IAM 工具应用适当的权限。无论操作系统的更新还是平台的运营，用户都不需要进行，但数据分类和权限设置无论使用哪种服务都不会脱离用户。

责任共享模型的边界并非固定，而是随所选服务而变化。像 EC2 那样由用户管理客户机操作系统的服务中，补丁应用是用户的责任；而像 S3、DynamoDB 那样由 AWS 运营操作系统和平台的服务中，则由 AWS 负责。因此「始终是 AWS」和「始终是用户」都是错误的。区域只是部署位置的选择，并不会改变责任的分担。掌握这一点后，即使遇到未见过的服务，也只需判断它更接近 EC2 还是更接近 S3，就能推测出边界所在。

设施作为运行 AWS 云服务的基础设施的一部分，被明确列入「Security of the Cloud」，无论使用哪种服务都始终是 AWS 的责任。用户无法自行对此范围进行审计或进入检查，而是通过 AWS 公开的第三方认证和审计报告来确认。这属于三种控制分类中的继承控制（Inherited Controls），是用户完全从 AWS 那里继承而来的部分。会随所选服务而变化的是操作系统和中间件层，而非物理层。

官方明确指出，自身数据的管理（包括加密选项）、资产的分类，以及通过 IAM 工具应用适当的权限，即使使用抽象化的服务，也仍会留给用户。无论选择哪种服务都不会脱离，因此可作为思考边界时的固定点。物理服务器的更换和骨干网络的保护，都属于设施与硬件层面的工作，始终由 AWS 一侧负责。托管服务底层的操作系统由 AWS 运营，因此对其应用补丁并非用户的工作。

官方将继承控制定义为用户完全从 AWS 继承而来的控制，物理和环境方面的控制属于此类。分别独立应用于基础设施层与用户层两者的是共享控制（Shared Controls），完全属于用户责任、服务与可用区的安全属于此类的是客户特定控制（Customer Specific Controls）。继承的方向是从 AWS 流向用户的单向关系，并不存在 AWS 沿用用户设置的关系。

官方列举的共享控制包括补丁管理、配置管理、意识与培训这3项。它们的共同特点是同一项工作会在基础设施层和用户层两边并行进行，例如补丁管理，AWS 会应用于自身的基础设施，用户则分别应用于客户机操作系统和应用程序。出入管理、电源冗余、硬件采购与报废属于物理和环境方面的控制，属于用户从 AWS 那里继承的一方。服务与可用区的安全是客户特定控制的示例。

DynamoDB 是抽象化服务，由 AWS 运营基础设施层、操作系统直至平台。在 EC2 中原本由用户负责的客户机操作系统补丁应用，迁移后就变成了 AWS 一侧的工作。另一方面，数据分类与加密选项的选择、通过 IAM 赋予权限，无论选择哪种服务都仍留给用户。物理设施的保护本来就始终是 AWS 的责任，迁移也不会使其转移给用户。可以整理为「会变化的部分是操作系统和平台层，不变的部分是数据和权限」，这样理解就不会混淆。

现行的支柱是卓越运营、安全性、可靠性、性能效率、成本优化、可持续性，共6项。可持续性是2021年新增的第6项支柱，如果缺少这一项，说明是新增之前的旧信息。互操作性与可移植性并未被列为框架的支柱，官方列表中都不存在这两个说法。支柱数量陈旧的解说文章，其服务名称和考试代码也很可能同样过时，可以作为判断教材新旧的标志。

卓越运营是关注系统的运行与监控，以及流程与规程持续改进的支柱，具体包括部署自动化、通过故障复盘更新规程、以小而频繁的方式进行变更等。信息与系统的保护属于安全性，资源分配优化与资源类型选择属于性能效率，消除不必要支出与资源适配属于成本优化，分别是其他支柱所关注的重点。

安全性支柱关注信息与系统的保护，核心在于数据的完整性与访问控制。加密以及基于最小权限的访问控制正符合这一点。停止未使用的资源并调整实例规模属于成本优化，将部署自动化并通过复盘更新规程属于卓越运营，测量并降低对环境的影响属于可持续性所关注的内容。责任共享模型中留给用户一侧的大部分工作，都会归入这一安全性支柱来处理。

可靠性是关注工作负载完成预期功能，以及能否从故障中迅速恢复的支柱，分散部署到多个可用区、自动恢复、验证备份与恢复流程都属于这一范畴。其特点不仅在于避免出故障，还包括出故障后能尽快恢复。资源分配优化属于性能效率，运行与监控及流程改进属于卓越运营，将环境影响降到最低属于可持续性所关注的内容。

性能效率是关注IT资源分配优化，以及选择符合工作负载需求的资源类型的支柱，为满足要求而重新选择资源类型的举措正好符合这一点。成本优化看似是类似的工作，但其目的在于消除支出上的浪费，而这里的动机是满足延迟要求，关注点并不相同。可靠性关注的是抗故障能力，卓越运营关注的是流程的改进，二者都不是这里的主要着眼点。

成本优化是关注消除不必要的支出、使资源与业务需求相匹配的支柱，具体包括停止未使用的资源、将过大的实例调整为合适规模、按需切换计费模式等判断。其重点并非单纯追求便宜，而是关注支出是否物有所值。信息与系统的保护属于安全性，完成预期功能与恢复属于可靠性，将环境影响降到最低属于可持续性所关注的内容。

可持续性是关注将云工作负载运行对环境造成的影响降到最低的支柱，是2021年新增的第6个、也是最新的支柱，这一支柱是否存在，正是区分教材新旧的分界点。资源分配优化与资源类型选择属于性能效率，运行与监控及流程的持续改进属于卓越运营，完成预期功能与从故障中恢复属于可靠性所关注的内容，分别指向其他支柱。

遗漏的是可持续性（Sustainability），即关注将云工作负载运行对环境影响降到最低的支柱。由于它是2021年新增的第6项支柱，在此之前撰写的解说文章仍停留在5项。卓越运营、性能效率、可靠性都是新增之前就已存在的支柱，因此即便文章只写了5项，也依然会包含它们。像支柱数量这种基础内容都过时的文章，其他描述也很可能同样陈旧，需要格外留意。

现行的支柱是卓越运营、安全性、可靠性、性能效率、成本优化、可持续性，共6项，其中并不包含互操作性。不同系统之间能否互联互通，虽然是设计上的重要关注点，但 Well-Architected 框架并未为此单独设立支柱。成本优化、卓越运营、性能效率都属于6项支柱之中正式的一员。如果把框架中不存在的词误记为支柱，在排除选项时就容易产生混淆。

消除不必要的支出、使资源与业务需求相匹配是成本优化的关注点，并非可靠性的关注点。可靠性是关注工作负载完成预期功能，以及能否从故障中迅速恢复的支柱。其余3项都符合官方的描述组合。支柱的名称接近日常用语，如果只凭字面印象来对应，很容易张冠李戴，配合表示关注点的一句话一起记忆，遇到这类题目就不容易出错。

区域是 AWS 拥有多个可用区的世界范围内的物理地点，拥有诸如 us-east-1 或 ap-northeast-1 这样的名称，选择时需要考虑数据所在地及相关法规、与用户的距离，以及费用。由一个或多个独立数据中心构成的故障隔离单位，指的是可用区。CloudFront 缓存并分发内容的据点是边缘节点（Edge Location），部署在通信运营商网络内部的是 Wavelength Zones。

可用区被定义为由一个或多个独立数据中心构成，每个数据中心都配备冗余的电源、网络和连接，并分别位于不同的设施内。它并不等同于单栋数据中心，而是指一个整体的集合，并且要点在于它与其他可用区位于不同的建筑物中。边缘节点与源站之间的层是区域边缘缓存（Regional Edge Cache），部署在靠近用户的城市、可运行应用程序的是 Local Zones 的说明，两者指的都是不同的机制。

官方指出，每个区域由「至少3个相互独立、在物理上彼此分离的可用区」构成。区域总数和可用区总数会持续增加，记住具体数字意义不大，但「每个区域至少有多少个可用区」这一构成规则相对稳定，可以直接作为设计的前提使用。位于同一设施内的说法，与「分别位于不同设施」这一定义相矛盾。可用区也不是由用户申请增设，也不是每个区域只有1个。

边缘节点是 CloudFront 用于分发内容的全球性数据中心网络。请求会被路由到延迟最低的边缘节点，并从那里进行分发。它并非用于提高可用性的冗余单位，而是为了从更靠近用户的位置重新分发内容而设置的缓存据点，这一点是要点所在。隔离故障是可用区的作用，划分IP地址范围是子网的作用，在通信运营商设施内运行则是 Wavelength Zones 的作用。

请求会被路由到延迟最低的边缘节点，如果那里已有内容，就会立即分发。如果没有，则会从 S3 存储桶或HTTP服务器等源站获取内容并进行分发，同时保留到缓存中。这样一来，第二次及以后的请求就能直接从更近的据点返回。缓存不存在既不会导致错误，用户也不会被晾在一边等待。转发到可用区是故障隔离的机制，与内容分发的流程是两回事。

区域边缘缓存是位于边缘节点与源站之间的缓存层，作用是减少在边缘找不到内容时前往源站获取的次数。汇总可用区的管理单位是区域（Region），部署在通信运营商网络内的可用区是 Wavelength Zones，两者都是不同的概念。用户终端一侧的缓存并非 AWS 的机制，而是浏览器或操作系统自身具备的功能。

可用区是位于不同设施、配备冗余电源和网络的故障隔离单位。如果将担任同一角色的资源分散部署在多个可用区中，即使其中一个可用区整体停止，也能靠其余部分继续处理。这就是多可用区（Multi-AZ）架构，是可用性设计的出发点。从最近据点进行分发是边缘节点的作用，数据所在地是选择区域时的判断依据，通过承诺使用量降低单价是计费模式的问题，都不是分散部署可用区的动机。

Local Zones 是一种能够让应用程序在更靠近终端用户或工作负载的 AWS 基础设施上运行的机制，部署在与区域相距较远的城市中。它与边缘节点类似，都涉及「更近的位置」，但不同之处在于，它是实际运行应用程序本身的场所，而非分发内容的缓存。区域内的故障隔离是可用区，专用分发据点是边缘节点，源站前方的中间缓存是区域边缘缓存，分别指向不同的机制。

Wavelength Zones 是部署在通信运营商网络内部的可用区。它与 Local Zones 相同，都是为了让应用程序本身在靠近用户的位置运行的机制，与作为分发内容缓存据点的边缘节点在目的上有所不同。部署在边缘节点与源站之间的是区域边缘缓存，在区域内部隔离故障的单位是可用区，划分 VPC 的IP地址范围的是子网。

可用区是分别位于不同设施的故障隔离单位，因此要应对整个可用区停止的情况，只能跨可用区进行部署。由于每个区域至少由3个相互独立的可用区构成，因此可以在同一区域内实现向多个可用区的分散部署。即使在同一可用区内增加服务器台数，一旦该可用区宕机也会全部失效，无法满足要求。CloudFront 是加快分发速度的机制，如果源站停止，动态处理仍然无法继续。更改计费方案是费用层面的问题，与可用性无关。