# 框架的支柱
构建软件系统与建楼很像。如果基础不牢固，结构问题将会破坏整栋大楼的完整性和功能。在设计技术解决方案时，如果忽视卓越运营、安全性、可靠性、性能效率、成本优化和可持续性这六大支柱，就很难构建一个能够满足您的期望和需求的系统。通过把这些支柱整合到架构中，您将能构建稳定而高效的系统，这将使您能够专注于设计的其他方面，例如功能性需求。
**Topics**
+ [卓越运营](operational-excellence.md)
+ [安全性](security.md)
+ [可靠性](reliability.md)
+ [性能效率](performance-efficiency.md)
+ [成本优化](cost-optimization.md)
+ [可持续性](sustainability.md)
# 卓越运营
卓越运营（OE）是一项承诺，即正确地构建软件，同时持续提供卓越的客户体验。卓越运营支柱包含组织团队、设计工作负载、大规模运营工作负载和随时间推移改进工作负载的最佳实践。
卓越运营支柱概述了各种设计原则、最佳实践和问题。有关具体实施的说明性指导，请参阅《[卓越运营支柱白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)》。
**Topics**
+ [设计原则](oe-design-principles.md)
+ [定义](oe-definition.md)
+ [最佳实践](oe-bp.md)
+ [资源](oe-resources.md)
# 设计原则
以下是在云中实现卓越运营的设计原则：
+ **围绕业务成果组织团队：**团队实现业务成果的能力来自领导力愿景、有效的运营和与业务协调的运营模式。领导层应致力于 CloudOps 转型并全身心地投入其中，采用合适的云运营模式，激励团队以非常高效的方式运营并实现业务成果。正确的运营模式会利用人员、流程和技术能力来扩大规模，优化工作效率，并通过敏捷性、响应能力和适应能力打造差异化优势。组织的长期愿景会转化为一系列目标，并且这些目标将传达给整个组织内云服务的利益相关方和使用者。各个层面的目标和运营 KPI 将保持一致。这种做法能够维持通过实施以下设计原则所获得的长期价值。
+ **实施可观测性以获得切实可行的洞察：**全面了解工作负载行为、性能、可靠性、成本和运行状况。建立关键绩效指标（KPI），利用可观测性遥测来作出明智的决策，并在业务结果面临风险时迅速采取行动。基于可操作的可观测性数据，主动提高性能和可靠性，降低成本。
+ **尽可能安全地实现自动化：**在云中，您可以将用于应用程序代码的工程规范应用于整个环境。您能够以代码形式定义整个工作负载及其运营（应用程序、基础设施、配置和程序），并对其进行更新。之后，您可以通过启动工作负载的运营来响应事件，从而实现运营的自动化。在云中，您可以通过配置防护机制（包括速率控制、错误阈值和审批）来实现自动化的安全。通过有效的自动化，您可以实现对事件的持续响应，限制人为错误并减少操作员的艰苦工作。
+ **频繁进行可逆的小规模更改：**将工作负载设计为可扩展且松耦合，以允许定期更新组件。自动部署技术加上小型增量更改可缩小影响范围，并能够在发生故障时更快地进行回滚。这将增强您的信心，在保持质量和快速适应市场条件变化的同时，为工作负载提供有益的更改。
+ **经常优化运营程序：**随着工作负载的发展变化，相应地改进运营。在使用运营程序时，要寻找机会改进它们。定期审查并验证所有程序是否有效，以及团队是否熟悉这些程序。在发现差距时，相应地更新程序。向所有利益相关方和团队传达程序更新。将运营游戏化，以分享最佳实践并向团队传授知识。
+ **预测故障：**通过推动故障场景来了解工作负载的风险状况及其对业务成果的影响，从而最大限度地提高运营成功率。测试程序的有效性以及团队对这些模拟故障作出的反应。制定明智的决策，管理通过测试确定的开放风险。
+ **从所有运营事件和指标中吸取经验教训：**从所有运营事件和故障中吸取经验教训，推动改进。在多个团队乃至组织范围中分享经验教训。经验教训应重点介绍有关运营如何促进取得业务成果的数据和轶事。
+ **使用托管服务：**尽可能使用 AWS 托管服务，减少运营负担。围绕与这些服务的交互制定操作程序。
# 定义
在云中实现卓越运营有四个领域的最佳实践：
+ **组织**
+ **准备**
+ **运营**
+ **改进**
组织领导层负责定义业务目标。组织必须了解各项要求和优先事项，并利用它们来组织和开展工作，为取得业务成果提供支持。您的工作负载必须发出所需信息以提供支持。实施多项服务来实现工作负载的集成、部署和交付，这将通过自动执行重复流程，为生产环境带来更多有益更改。
工作负载的运营可能存在固有风险。了解这些风险并作出明智的生产决策。您的团队必须能够支持您的工作负载。从预期业务成果中得出的业务和运营指标将有助于您了解工作负载的运行状况、运营活动以及对意外事件的响应。优先事项将随着业务需求和业务环境的变化而变化。将这些作为反馈环路，持续推动组织和工作负载运营的改进。
# 最佳实践
**注意**
所有卓越运营问题都将 OPS 前缀用作支柱的简写。
**Topics**
+ [组织](oe-organization.md)
+ [准备](oe-prepare.md)
+ [操作](oe-operate.md)
+ [改进](oe-evolve.md)
# 组织
团队必须对整个工作负载、他们在其中的角色以及共同的业务目标有一致的理解，以便确立优先事项以实现业务成功。明确优先事项可以让您的工作效益最大化。评估内部和外部客户需求，让包括业务、开发和运营团队在内的关键利益相关方参与进来，以便确定工作重心。评估客户需求将确保您充分了解实现业务成果所需的支持。确保了解组织治理规定的指导原则或义务，以及监管合规性要求和行业标准等可能需要遵循或重视的外部因素。验证您是否具有确定内部治理和外部合规性要求更改的机制。如果未确定要求，请验证您是否已对此决定进行尽职调查。定期审查优先事项，以便在需求发生变化时对其进行更新。
评估业务面临的威胁（例如业务风险和负债以及信息安全威胁），并在风险注册表中维护这些信息。评估风险的影响，在有冲突的利益或替代方法之间作出权衡。例如，新功能的加速上市可能会比成本优化更重要，或者您可以为非关系数据选择关系数据库来简化系统迁移工作，而无需重构。管理益处与风险，以便在确定工作重心时作出明智的决策。有些风险或选择可能在一段时间内可以接受，或许可以降低相关风险，或者允许风险继续存在可能会令人无法接受，在这种情况下，您将采取措施来化解风险。
您的团队必须了解他们在实现业务成果方面所发挥的作用。团队必须了解自己在其他团队获得成功的过程中所扮演的角色、其他团队在他们获得成功的过程中所扮演的角色，并制定共同的目标。了解责任分配、所有权归属、决策制定方式以及决策者，将有助于集中精力并最大限度地发挥团队的优势。团队的需求将由其所支持的客户、所在组织、团队的组成以及工作负载的特征决定。期望单个运营模式能够支持组织中的所有团队及其工作负载是不合理的。
确保每个应用程序、工作负载、平台和基础设施组件都有确定的负责人，并且每个流程和程序都有确定的负责人负责其定义，有负责人负责其性能。
了解每个组件、流程和程序的业务价值，了解为什么要配置这些资源或为什么要执行这些活动，以及为什么要拥有该所有权，这些都有助于确定团队成员的行动。清晰定义团队成员的责任以便他们可以适当地采取行动，并制定相关机制，确定责任和所有权。制定用于请求添加、更改和例外的机制，以免限制创新。在团队之间定义协议，描述团队之间如何开展合作以相互支持以及您的业务成果。
为团队成员提供支持，以便他们可以更有效地采取行动并为您的业务成果提供支持。参与其中的高层领导应设定期望并衡量是否成功。高层领导应是采用最佳实践和组织发展的发起人、倡导者和推动者。允许团队成员在成果面临风险时采取行动以尽可能减少影响，并鼓励他们在认为存在风险时向决策者和利益相关方上报，以便解决问题并避免意外事件。及时、清晰、可行地传达已知风险和计划内事件，以便团队成员可以及时采取适当行动。
鼓励进行试验，以加快学习速度，并使团队成员保持兴趣和参与热情。团队必须增强自己的技能组合，以采用新技术，并随需求和责任的变化继续提供支持。专门安排学习时间，以提供支持并鼓励参与其中。确保团队成员拥有取得成功和进行扩展所需的资源（包括工具和团队成员），以便为您的业务成果提供支持。利用跨组织的多样性来寻求多种独特的见解。利用这种见解提高创新能力、对您的假设提出质疑，并降低确认偏差的风险。在团队内部提升包容性、多样性和可达性有助于获取有益的见解。
如果存在适用于组织的外部法规或合规性要求，则应使用 [AWS 云合规性](https://aws.amazon.com/compliance/?ref=wellarchitected-wp)提供的资源来帮助培训团队，以便他们能够确定优先事项会受到的影响。Well-Architected Framework 强调学习、衡量和改进。它为您提供了一致的方法来评估架构，并实施将随着时间推移而扩展的设计。AWS 提供了 AWS Well-Architected Tool，可协助您在开发之前审查方法，在生产之前审查工作负载状态，以及在生产过程中审查工作负载状态。您可以将工作负载与最新的 AWS 架构最佳实践进行比较，监控整体状态，并深入了解潜在风险。AWS Trusted Advisor 是一种工具，让您可以访问一组核心检查，这些检查会提出优化建议，有助于确定您的优先事项。Business Support 和 Enterprise Support 客户可以访问其他检查，这些检查重点关注安全性、可靠性、性能、成本优化和可持续性，可进一步帮助他们确定优先事项。
AWS 有助于您就 AWS 及其服务对团队进行培训，让他们深入了解自己的选择会如何影响工作负载。使用由 AWS 支持 提供的资源（AWS 知识中心、AWS 讨论论坛和 AWS 支持 中心）和 AWS 文档来培训团队。请通过 AWS 支持 中心联系 AWS 支持，获取与 AWS 问题有关的协助。AWS 还分享了我们通过在 Amazon Builders' Library 中的 AWS 运营学到的最佳实践和模式。您可以通过 AWS Blog 和 The Official AWS Podcast，获得各种其他有用信息。AWSTraining and Certification 提供了一些培训，可以通过自定进度的数字课程，学习 AWS 的基础知识。您还可以报名参加讲师指导培训，进一步培养团队的 AWS 技能。
使用能够跨 AWS Organizations 等账户集中治理环境的工具或服务，协助管理运营模式。AWS Control Tower 等服务扩展了这一管理功能，让您能够定义账户设置的蓝图（支持您的运营模式），使用 AWS Organizations 进行持续治理以及自动预置新账户。托管服务提供商（如 AWS Managed Services、AWS Managed Services 合作伙伴或 AWS 合作伙伴网络中的托管服务提供商）会提供实施云环境的专业知识，并为您的安全性和合规性要求以及业务目标提供支持。将托管服务添加到您的运营模式可以节省您的时间和资源，并让内部团队保持精干，专注于凸显业务优势的战略成果，而不是开发新的技能和功能。
以下问题主要针对卓越运营方面的注意事项。（有关卓越运营问题的列表和最佳实践，请参阅[附录](a-organization.md)。）
| OPS 1：如何确定自己的优先事项？ |
| --- |
| 每个人员都必须了解自己在实现业务成功方面所发挥的作用。制定共同的目标，以便为资源设定优先事项。这可以让您的工作效益最大化。 |
| OPS 2：如何构建组织结构来为业务成果提供支持？ |
| --- |
| 您的团队必须了解他们在实现业务成果方面所发挥的作用。团队必须了解自己在其他团队获得成功的过程中所扮演的角色、其他团队在他们获得成功的过程中所扮演的角色，并制定共同的目标。了解责任分配、所有权归属、决策制定方式以及决策者，将有助于集中精力并最大限度地发挥团队的优势。 |
| OPS 3：组织文化如何为业务成果提供支持？ |
| --- |
| 为团队成员提供支持，以便他们可以更有效地采取行动并为您的业务成果提供支持。 |
您可能会发现，您需要在某个时间点侧重于一小部分优先事项。长期使用平衡的方法来确保培养所需能力和管理风险。定期审查优先事项，并根据需求变化进行更新。当责任和所有权不确定或未知时，您将面临以下风险：没有及时执行必要的活动，以及在处理这些需求时可能出现工作冗余和潜在冲突。组织文化会直接影响团队成员的工作满意度和保留率。提升团队成员的参与度和能力，取得业务成功。创新必须进行试验，才能将创意转化为成果。应认识到，取得非预期结果也算试验成功，因为这种试验发现了无法实现成功的途径。
# 准备
要为卓越运营做好准备，您必须了解工作负载及其预期行为。然后，您需要能够针对它们进行设计，以提供对其状态的洞察并构建程序来支持这些工作负载。
将工作负载设计成能够提供必要的信息，以便您了解其所有组件的内部状态（例如指标、日志、事件和跟踪数据），为可观测性和调查问题提供支持。可观测性不仅仅是简单的监控，它让您可以根据系统的外部输出全面了解系统的内部运作。可观测性源于指标、日志和跟踪数据，可提供对系统行为和动态的深刻洞察。通过有效的可观测性，团队可以识别模式、异常和趋势，从而能够主动解决潜在问题并保持最佳系统运行状况。要想确保监控活动与业务目标协调一致，确定关键绩效指标（KPI）至关重要。这种一致性可确保团队使用真正重要的指标作出数据驱动型决策，从而优化系统性能和业务成果。此外，可观测性使企业能够积极采取行动，而不是被动作出反应。团队可以了解其系统中的因果关系，以此预测和预防问题，而不仅仅是对问题作出反应。随着工作负载的发展变化，必须重新审视和完善可观测性策略，确保其仍然适用且有效。
采用的方法需能够改进将更改应用于生产环境的流程，并且支持重构、快速质量反馈和错误修复。这些方法可以加快有益更改进入生产环境的速度、减少产生的问题，并能够快速识别和修复通过部署活动引入的问题或在环境中发现的问题。
采用的方法需能够提供快速质量反馈，并在更改没有达到预期结果时实现快速恢复。使用这些实践可以减轻因部署更改而产生的问题的影响。制定计划以防更改不成功，这样在必要时能够更快速地响应，并测试和验证所做的更改。了解环境中的计划活动，以便管理更改风险，避免影响计划活动。强调频繁、小规模、可逆更改，以限制更改范围。这样可以加快故障排除和修复速度，并支持回滚更改。此外，还意味着能够更频繁地从有价值的更改中获益。
评估工作负载、流程和程序以及工作人员的运营准备就绪情况，了解与工作负载相关的运营风险。使用一致的流程（包括手动或自动化检查清单）来了解何时可运营工作负载或进行更改。这也有助于您发现必须制定计划予以解决的任何问题。准备好记录日常活动的运行手册和指导问题解决流程的行动手册。了解益处与风险，以便作出明智的决策，从而将更改应用于生产环境。
AWS 让您能够将整个工作负载（应用程序、基础设施、策略、治理和运营）视为代码。这意味着，您可以将用于应用程序代码的工程规范应用于堆栈的每个元素，并在团队或组织之间共享，提高开发工作的效益。使用云中的运营即代码功能和安全试验功能来开发工作负载、运营程序并进行故障演练。使用 CloudFormation，您可以实现一致的模板化沙盒开发、测试和生产环境，提高运营管理水平。
以下问题主要针对卓越运营方面的注意事项。
| OPS 4：如何在工作负载中实现可观测性？ |
| --- |
| 在工作负载中实现可观测性，以便您可以了解其状态并根据业务要求作出数据驱动型决策。 |
| OPS 5：如何减少缺陷、简化修复和改进生产流程？ |
| --- |
| 采用的方法需能够改进将更改应用于生产环境的流程，实现重构、快速质量反馈和错误修复。这些方法可以加快有益更改进入生产环境的速度、减少产生的问题，并能够快速识别和修复通过部署活动引入的问题。 |
| OPS 6：如何缓解部署风险？ |
| --- |
| 采用的方法需能够提供快速质量反馈，并在更改没有达到预期结果时实现快速恢复。使用这些实践可以减轻因部署更改而产生的问题的影响。 |
| OPS 7：如何知道您已经准备好支持某种工作负载？ |
| --- |
| 评估工作负载、流程及程序和工作人员的操作准备情况，以便了解与工作负载相关的操作风险。 |
投资实现运营活动即代码，以最大限度地提高运营人员的工作效率，最大限度地降低错误率，并实现自动响应。使用“故障演练”来预测故障，并在适当的时候创建程序。使用资源标签和 AWS Resource Groups，按照一致的标记策略应用元数据，以标识您的资源。标记您的资源，以便进行整理、成本核算、访问控制并有针对性地自动执行运营活动。利用云的弹性特点结合相应部署实践，推动开发活动和系统的预部署，以加快实施速度。当您对用于评估工作负载的检查清单进行更改时，请计划要对不再符合条件的活动系统执行哪些操作。
# 操作
可观测性让您可以专注于有意义的数据，并了解工作负载的交互和输出。通过专注于基本洞察并消除不必要的数据，您可以直截了当地来了解工作负载性能。这不仅对收集数据至关重要，对正确解读数据也至关重要。定义明确的基准，设置适当的警报阈值，并主动监控任何偏差。关键指标的改变，尤其是与其他数据关联时，可以精确定位特定的问题领域。借助可观测性，您可以更好地预见和应对潜在挑战，确保工作负载平稳运行并满足业务需求。
工作负载运营是否成功通过业务成果和客户结果的实现情况加以衡量。定义预期结果、确定成功的衡量方式，并确定将在这些计算中使用的指标，以确定工作负载和运营是否成功。运营状况包括工作负载的运行状况，以及为支持工作负载而执行之运营活动的运行状况和成败（例如，部署和意外事件响应）。设立改进、调查和介入的指标基准，收集和分析您的指标，然后验证您对运营成功的理解及其随时间变化的规律。使用收集的指标来确定您是否可以满足客户需求和业务需求，并确定需要改进的领域。
要实现卓越运营，您需要进行有效且高效的运营事件管理。这适用于计划内和计划外的运营事件。使用已确定的运行手册处理易于理解的事件，并使用行动手册来帮助调查和解决问题。根据对业务和客户的影响，对事件的响应进行优先级排序。确保在出现事件警报时，会有指定负责人运行相关流程。事先定义解决事件所需的人员，并配备一个上报流程，以便根据紧急程度和影响在必要时引入额外人员。确定并引入有权决定行动方案的人员，这些行动方案将对之前未解决的事件响应产生业务影响。
通过为目标受众（例如，客户、业务人员、开发人员、运营人员）定制的控制面板和通知来发布工作负载的运行状态，以便他们可以采取相应措施、管理预期，并在恢复正常运营时收到通知。
在 AWS 中，您可以为收集的工作负载指标和 AWS 自带指标生成控制面板视图。您可以利用 CloudWatch 或第三方应用程序来汇总和呈现运营活动的业务、工作负载和运营级别视图。AWS 通过日志记录功能（包括 AWS X-Ray、CloudWatch、CloudTrail 和 VPC 流日志）提供工作负载洞察，从而协助发现工作负载问题，以支持根本原因分析和修复。
以下问题主要针对卓越运营方面的注意事项。
| OPS 8：如何在组织中利用工作负载可观测性？ |
| --- |
| 利用可观测性确保最佳工作负载运行状况。利用相关的指标、日志和跟踪数据，全面了解工作负载的性能并有效地解决问题。 |
| OPS 9：如何了解自己的运营状况？ |
| --- |
| 定义、记录和分析运营指标以便了解运营事件，从而采取适当的行动。 |
| OPS 10：如何应对工作负载事件和运营事件？ |
| --- |
| 制定和验证用于响应事件的程序，以便尽可能减少其对工作负载的干扰。 |
您收集的所有指标都应该与业务需求及其支持的结果相符。为充分理解的事件开发脚本式响应，并自动执行响应以识别事件。
# 改进
学习、分享和不断改进，以保持卓越运营。将工作周期专用于持续进行渐进式改进。对影响客户的所有意外事件执行意外事件后分析。确定成因和预防措施，以限制或防止再次事件发生。视情况与受影响的团体沟通成因。定期评估并优先处理改进机会（例如，功能请求、问题修复和合规性要求），包括工作负载和运营程序。
将反馈环路纳入您的程序，以快速确定需要改进的领域，并从正在执行的运营中获取经验教训。
在团队中分享得到的经验教训和其中的效益。分析经验教训中的趋势，并对运营指标进行跨团队回顾性分析，以确定改进的机会和方法。实施更改以便改进，并评估结果以确定是否成功。
在 AWS 上，您可以将日志数据导出到 Amazon S3 或将日志直接发送到 Amazon S3，以便长期存储。使用 AWS Glue，您可以在 Amazon S3 中发现并准备日志数据以供分析，并将相关元数据存储在 AWS Glue Data Catalog 中。然后，Amazon Athena 通过与 AWS Glue 的原生集成，可用于分析日志数据，并使用标准 SQL 进行查询。使用像 Amazon Quick 这样的商业智能工具，您可以直观显示、浏览和分析您的数据。发现可能推动改进的相关趋势和活动。
以下问题主要针对卓越运营方面的注意事项。
| OPS 11：如何改进运营？ |
| --- |
| 分配专门的时间和资源用于近乎持续的渐进式改进，以便提高运营的有效性和效率。 |
运营的成功改进建立在以下基础上：频繁的小规模改进；提供安全的环境和时间来试验、开发和测试改进；以及鼓励人们从失败中获取经验教训的整体氛围。随着运营控制水平的提高，对于沙盒、开发、测试和生产环境的运营支持促进了开发，并提高了对生产环境中部署的变更结果成功与否的可预测性。
# 资源
请参阅以下资源，详细了解卓越运营的最佳实践。
## 文档
+ [DevOps 和 AWS](https://aws.amazon.com/devops/?ref=wellarchitected-wp)
## 白皮书
+ [卓越运营支柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html?ref=wellarchitected-wp)
## 视频
+ [Amazon 的 DevOps](https://www.youtube.com/watch?v=esEFaY0FDKc&ref=wellarchitected-wp)
# 安全性
安全性支柱包括保护数据、系统和资产以利用云技术来改善安全性的能力。
安全性支柱概述了设计原则、最佳实践和问题。有关具体实施的说明性指导，请参阅《[安全性支柱白皮书](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html?ref=wellarchitected-wp)》。
**Topics**
+ [设计原则](sec-design.md)
+ [定义](sec-def.md)
+ [最佳实践](sec-bp.md)
+ [资源](sec-resources.md)
# 设计原则
在云中，有很多原则可帮助您提高工作负载的安全性：
+ **实施强大的身份验证基础：**实施最低权限原则，并通过对每一次与 AWS 资源之间的交互进行适当授权来强制执行职责分离。集中进行身份管理，并努力消除对长期静态凭证的依赖。
+ **保持可追溯性：**实时监控和审查对环境执行的操作和更改并发送警报。为系统集成日志和指标收集功能，以自动调查并采取行动。
+ **在所有层面应用安全措施：**利用多种安全控制措施实现深度防御。应用到所有层面（例如网络边缘、VPC、负载均衡、每个实例和计算服务、操作系统、应用程序和代码）。
+ **自动化安全性最佳实践：**借助基于软件的自动化安全机制，您能够以更为快速且更具成本效益的方式实现安全扩展。创建安全架构，包括实施可在版本控制模板中以代码形式定义和管理的控制措施。
+ **保护传输中数据和静态数据：**按敏感程度对数据进行分类，并根据情况采用加密、令牌化和访问控制等适当机制。
+ **限制对数据的访问：**利用相关机制和工具来减少或消除对于直接访问或手动处理数据的需求。这样可以降低处理敏感数据时数据处理不当、被修改以及人为错误的风险。
+ **做好应对安全性事件的准备工作：**制定符合组织要求的事件管理和调查政策和流程，做好应对意外事件的准备工作。开展意外事件响应模拟演练，并使用具有自动化功能的工具来提高检测、调查和恢复的速度。
# 定义
在云中实现安全性有七个领域的最佳实践：
+ 安全基础知识
+ Identity and access management
+ 检测
+ 基础设施保护
+ 数据保护
+ 事件响应
+ 应用程序安全性
在构建任何工作负载之前，您需要确定可能影响安全性的实践。您需要控制谁可以执行什么操作。另外，您需要能够识别安全事件、保护系统和服务，并通过数据保护机制来保持数据的机密性和完整性。您应该具备一个定义明确且经过实践的流程来响应安全事件。这些工具和技术非常重要，因为它们有助于实现诸如避免财务损失或履行监管义务等目标。
借助 AWS 责任共担模式，组织能够利用云服务实现其安全性与合规性目标。AWS 负责保护用于支持云服务的基础设施的安全，作为 AWS 的客户，您能够专注于使用这些服务来实现目标。还可通过 AWS 云更好地访问安全数据，并以自动化方式响应安全事件。
# 最佳实践
**Topics**
+ [安全基础知识](sec-security.md)
+ [Identity and access management](sec-iam.md)
+ [检测](sec-detection.md)
+ [基础设施保护](sec-infrastructure.md)
+ [数据保护](sec-dataprot.md)
+ [事件响应](sec-incresp.md)
+ [应用程序安全性](sec-appsec.md)
# 安全基础知识
以下问题主要针对安全性方面的注意事项。（有关安全性问题的列表和最佳实践，请参阅[附录](a-security.md)。）
| SEC 1：如何安全地运行工作负载？ |
| --- |
| 为了安全地操作您的工作负载，您必须将纲领性最佳实践应用于每个安全领域。将您在组织和工作负载级别的卓越运营中定义的要求和流程应用于所有领域。 及时了解 AWS 提供的建议、行业资源以及威胁情报，可帮助改进您的威胁模型和控制目标。通过自动化安全流程、测试和验证，您可以扩大安全运营规模。 |
在 AWS 中，建议根据账户的功能和合规性或数据敏感性要求分割不同的工作负载。
# Identity and access management
身份和访问管理是信息安全计划的关键部分，可以确保只有经过授权和通过身份验证的用户和组件才能访问您的资源，并且只能以您要求的方式进行访问。例如，您应该定义一些主体（即可以在您的账户中执行操作的账户、用户、角色和服务）、创建与这些主体相匹配的策略，并实施严格的凭证管理。这些权限管理元素构成了身份验证和授权的核心。
在 AWS 中，权限管理主要由 AWS Identity and Access Management（IAM）服务提供支持，您可以使用该服务控制对 AWS 服务和资源的用户和编程访问。您应该应用细粒度的策略向用户、组、角色或资源分配权限。您还可以应用强密码原则（例如复杂程度）来避免重复使用并强制执行多重身份验证（MFA）。您可以将联合身份验证与现有的目录服务配合使用。对于需要系统接入 AWS 的工作负载，IAM 支持通过角色、实例配置文件、身份联合验证和临时凭证进行安全访问。
以下问题主要针对安全性方面的注意事项。
| SEC 2：如何管理人员和计算机的身份？ |
| --- |
| 在操作安全 AWS 工作负载时，您需要管理两类身份。了解您需要管理和授予访问权限的身份类型，有助于确保正确的身份能够在正确的条件下访问正确的资源。 人类身份：您的管理员、开发人员、操作员和最终用户需要身份才能访问您的 AWS 环境和应用程序。他们是您组织的成员或与您合作的外部用户，他们通过 Web 浏览器、客户端应用程序或交互式命令行工具与您的 AWS 资源进行交互。 机器身份：您的服务应用程序、操作工具和工作负载需要一个身份来向 AWS 服务发出请求以执行某种操作，例如读取数据。这些身份包括运行在您的 AWS 环境（例如 Amazon EC2 实例或 AWS Lambda 函数）中的计算机。您还可以为需要访问权限的外部各方管理计算机身份。此外，您还可以拥有位于 AWS 以外且需要访问您的 AWS 环境的计算机。 |
| SEC 3：如何管理人员和计算机的权限？ |
| --- |
| 管理权限以控制对需要访问 AWS 和工作负载的人员和机器身份的访问。权限用于控制哪些人可以在什么条件下访问哪些内容。 |
凭证不得在任何用户或系统之间共享。应使用最低权限原则授予用户访问权限，并采用密码要求和强制执行 MFA 等最佳实践。应使用临时凭证和有限权限凭证（例如 AWS Security Token Service 发放的凭证）来执行编程访问（包括对 AWS 服务的 API 调用）。
如果用户需要在 AWS 管理控制台之外与 AWS 交互，则需要编程式访问权限。授予编程式访问权限的方法取决于访问 AWS 的用户类型。
要向用户授予编程式访问权限，请选择以下选项之一。
****
| 哪个用户需要编程式访问权限？ | 目的 | 方式 |
| --- | --- | --- |
| IAM | （推荐）使用控制台凭证作为临时凭证来签署向 AWS CLI、AWS SDK 或 AWS API 发出的编程请求。 | 按照您希望使用的界面的说明进行操作。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/sec-iam.html) |
| 人力身份 （在 IAM Identity Center 中管理的用户） | 使用临时凭证签署向 AWS CLI、AWS SDK 或 AWS API 发出的编程请求。 | 按照您希望使用的界面的说明进行操作。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/sec-iam.html) |
| IAM | 使用临时凭证签署向 AWS CLI、AWS SDK 或 AWS API 发出的编程请求。 | 按照《IAM 用户指南》中[将临时凭证用于 AWS 资源](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html)中的说明进行操作。 |
| IAM | （不推荐使用）使用长期凭证签署向 AWS CLI、AWS SDK 或 AWS API 发出的编程请求。 | 按照您希望使用的界面的说明进行操作。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/sec-iam.html) |
AWS 提供了能够帮助您使用身份和访问管理的资源。为了帮助学习最佳实践，请浏览我们关于[管理凭证和身份验证](https://wellarchitectedlabs.com/Security/Quest_Managing_Credentials_and_Authentication/README.html?ref=wellarchitected-wp)、[控制人员访问](https://wellarchitectedlabs.com/Security/Quest_Control_Human_Access/README.html?ref=wellarchitected-wp)和[控制编程访问](https://wellarchitectedlabs.com/Security/Quest_Control_Programmatic_Access/README.html?ref=wellarchitected-wp)的动手实验室。
# 检测
您可以使用检测控制来发现潜在的安全威胁或意外事件。检测控制是治理框架的重要组成部分，并且可以用于支持质量流程、法律或合规性义务，还可以用于威胁识别和响应工作。检测控制分为多种不同类型。例如，编制资产清单及其详细属性，有助于更有效地制定决策（以及进行生命周期管理），从而帮助建立运营基准。您还可以通过内部审核（是指对信息系统相关的控制措施进行的检查）来确保实践符合策略和要求，并确保您已根据定义的条件设置了正确的自动化警报通知。这些控制措施都是重要的响应手段，可以帮助组织确定和了解异常活动的范围。
在 AWS 中，您可以通过处理可用于审核、自动化分析和触发警报的日志、事件以及监控来实施检测控制。CloudTrail 日志、AWS API 调用和 CloudWatch 可以提供对指标进行监控以及报警的功能，AWS Config 可以提供配置历史记录。Amazon GuardDuty 是一种托管的威胁检测服务，可以持续监控恶意或未经授权的行为，从而帮助您保护 AWS 账户和工作负载。还可以使用服务水平日志，例如，您可以使用 Amazon Simple Storage Service（Amazon S3）来记录访问请求。
以下问题主要针对安全性方面的注意事项。
| SEC 4：如何检测和调查安全事件？ |
| --- |
| 从日志和指标中捕获和分析事件以获得可见性。对安全事件和潜在威胁采取行动，从而保护您的工作负载。 |
日志管理对于架构完善的工作负载至关重要，这其中原因众多，包括安全性或取证、法律或法规要求。分析日志并相应地做出响应至关重要，以便您能够识别潜在的安全事件。借助 AWS 提供的功能，您能够定义数据留存生命周期或定义数据保存、存档或最终删除的位置，从而更轻松地管理日志。这样，您就能够以更简单且更具成本效益的方式进行可预测且可靠的数据处理。
# 基础设施保护
基础设施保护包括满足最佳实践和组织或监管义务所必需的控制方法（例如深度防御）。使用这些方法对于在云中或本地持续成功运营至关重要。
在 AWS 中，您可以通过使用 AWS 原生技术或使用 AWS Marketplace 提供的合作伙伴产品和服务来实施有状态和无状态数据包检查。您应该使用 Amazon Virtual Private Cloud（Amazon VPC）创建一个安全且可扩展的私有环境，您可以在其中定义拓扑结构，包括网关、路由表以及公有子网和私有子网。
以下问题主要针对安全性方面的注意事项。
| SEC 5：如何保护网络资源？ |
| --- |
| 任何以某种形式连接至网络（互联网或专用网络）的工作负载都需要多层防御，以帮助防御基于外部和内部网络的威胁。 |
| SEC 6：如何保护计算资源？ |
| --- |
| 工作负载中的计算资源需要多层防御，以帮助抵御外部和内部威胁。计算资源包括 EC2 实例、容器、AWS Lambda 函数、数据库服务、IoT 设备等。 |
在任何类型的环境中，我们都建议使用多层防御。在基础设施保护方面，许多概念和方法在跨云和本地模型中都有效。实施边界保护、监控入站点和出站点以及建立全面的日志记录、监控和警报机制对于制定有效的信息安全计划至关重要。
AWS 客户能够定制或加强 Amazon Elastic Compute Cloud（Amazon EC2）、Amazon Elastic Container Service（Amazon ECS）容器或 AWS Elastic Beanstalk 实例的配置，并将配置捆绑到不可变的亚马逊机器映像（AMI）。之后，无论是由 Auto Scaling 启动还是手动启动，使用此 AMI 启动的所有新虚拟服务器（实例）都会收到加强的配置。
# 数据保护
在构建任何系统之前，您应确定可能影响安全性的基本实践。例如，数据分类提供了一种基于敏感程度对组织数据进行分类的方法，加密通过让未经授权的用户无法获知数据的真正内容来保护数据。这些工具和技术非常重要，因为它们有助于实现诸如避免财务损失或履行监管义务等目标。
在 AWS 中，以下实践有助于保护数据：
+ 作为 AWS 客户，您拥有对自己的数据的完全控制权。
+ AWS 可帮助您更轻松地加密数据和管理密钥（包括定期密钥轮换），这些操作可以由 AWS 轻松自动执行，也可由您执行。
+ 我们还提供包含文件访问和更改等重要内容的详细日志记录。
+ AWS 设计的存储系统具有优异的韧性。例如，Amazon S3 Standard、S3 Standard–IA、S3 One Zone-IA 和 Amazon Glacier 都设计为可以在一年内实现 99.999999999% 的对象持久性。这一持久性级别相当于平均每年有 0.000000001% 的对象丢失。
+ 作为较大规模数据生命周期管理流程中的一部分，版本控制可以防止意外覆盖、删除数据和类似损害。
+ AWS 永远不会主动在区域之间移动数据。除非您明确使用相关功能或利用提供该功能的服务移动数据，否则放置在某个区域中的内容将保留在该区域中。
以下问题主要针对安全性方面的注意事项。
| SEC 7：如何对数据进行分类？ |
| --- |
| 分类提供了一种基于重要程度和敏感度对数据进行分类的方法，以帮助您确定适当的保护和保留控制措施。 |
| SEC 8：如何保护静态数据？ |
| --- |
| 通过实施多种控制措施来保护静态数据，以降低未经授权的访问或处理不当的风险。 |
| SEC 9：如何保护传输中数据？ |
| --- |
| 通过实施多种控制措施来保护传输中数据，以降低未经授权的访问或丢失的风险。 |
AWS 提供了多种加密静态数据和传输中数据的方法。我们将这些功能内置在我们的服务中，这样您可以更轻松地加密数据。例如，我们为 Amazon S3 实施了服务器端加密（SSE），这样您可以更轻松地以加密方式存储数据。您还可以将整个 HTTPS 加密和解密过程（通常称为 SSL 终端）交给弹性负载均衡（ELB）来完成。
# 事件响应
即使采用极为成熟的预防和检测控制机制，组织仍应制定相关流程来响应安全事件并缓解安全事件可能带来的影响。工作负载的架构会极大地影响团队在意外事件发生期间采取有效行动、隔离或约束系统并将运行状态恢复到已知良好状态的能力。在安全事件发生之前确保相关工具和访问权限部署到位，而后通过 GameDay 活动定期进行意外事件响应演练，将有助于确保您的架构能够及时进行调查和恢复。
在 AWS 中，以下实践有助于做出有效的意外事件响应：
+ 我们提供包含文件访问和更改等重要内容的详细日志记录。
+ 事件可以被自动处理，并且会启动通过使用 AWS API 自动做出响应的工具。
+ 您可以使用 AWS CloudFormation 预置工具和“洁净室”。这样您就可以在安全且隔离的环境中进行取证。
以下问题主要针对安全性方面的注意事项。
| SEC 10：如何预测、响应事件以及从意外事件中恢复？ |
| --- |
| 准备工作对于及时有效地调查、响应安全事件以及从安全事件中恢复至关重要，可以尽可能减少对组织的破坏。 |
确保您能够快速授予安全团队访问权限，而且系统可以自动隔离实例并自动捕获数据与状态信息用于取证。
# 应用程序安全性
应用程序安全（AppSec）介绍了如何设计、构建和测试所开发工作负载的安全属性的整个过程。组织中应该有经过适当培训的人员，了解构建和发布基础设施的安全属性，并使用自动化来发现安全问题。
在软件开发生命周期（SDLC）和发布后流程的常规部分采用应用程序安全测试，有助于确保您拥有一种结构化机制来发现、修复和防止应用程序安全问题进入生产环境。
在设计、构建、部署和操作工作负载时，应用程序开发方法应该包括安全控制机制。在此过程中，协调流程以持续减少缺陷并尽可能减少技术债务。例如，在设计阶段使用威胁建模有助于及早发现设计缺陷，这使得缺陷更易于修复，修复的成本更低，而不是等到以后再来缓解这些缺陷。
在 SDLC 中，越早的阶段，解决缺陷的成本和复杂性通常就会越低。解决问题最简单的方法就是从一开始就不要有问题，所以从威胁模型开始有助于您在设计阶段专注于实现正确的结果。随着 AppSec 计划日渐成熟，您可以增加使用自动化执行的测试数量，提高向构建者提出的反馈的准确性，并减少安全审查所需的时间。所有这些操作都可以提高所构建软件的质量，并加快将新功能推向生产环境的速度。
这些实施指南侧重于四个方面：组织和文化、管道*的*安全性、管道*中的*安全性以及依赖关系管理。每个方面都提供了一组可以实施的原则，并提供了有关如何设计、开发、构建、部署和操作工作负载的端到端视图。
在 AWS 中，可以使用很多方法来处理应用程序安全计划。其中有些方法依赖于技术，而有些方法侧重于应用程序安全计划的人员和组织方面。
以下问题主要针对应用程序安全方面的注意事项。
| SEC 11：如何在整个设计、开发和部署生命周期中纳入并验证应用程序的安全属性？ |
| --- |
| 开展员工培训、执行自动化测试、了解依赖项，并验证各种工具和应用程序的安全属性，有助于降低生产工作负载中出现安全问题的可能性。 |
# 资源
请参阅以下资源，详细了解安全方面的最佳实践。
## 文档
+ [AWS 云安全性](https://aws.amazon.com/security/?ref=wellarchitected-wp)
+ [AWS 合规性](https://aws.amazon.com/compliance/?ref=wellarchitected-wp)
+ [AWS 安全博客](http://blogs.aws.amazon.com/security/?ref=wellarchitected-wp)
+ [AWS 安全成熟度模型](https://maturitymodel.security.aws.dev/en/0.-introduction/)
## 白皮书
+ [安全支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html?ref=wellarchitected-wp)
+ [AWS 安全概述](https://d1.awsstatic.com/whitepapers/Security/AWS%20Security%20Whitepaper.pdf?ref=wellarchitected-wp)
+ [AWS 风险和合规性](https://d1.awsstatic.com/whitepapers/compliance/AWS_Risk_and_Compliance_Whitepaper.pdf?ref=wellarchitected-wp)
## 视频
+ [AWS 安全中心](https://youtu.be/Wvyc-VEUOns?ref=wellarchitected-wp)
+ [责任共担模式概述](https://www.youtube.com/watch?v=U632-ND7dKQ&ref=wellarchitected-wp)
# 可靠性
可靠性支柱涵盖相关工作负载按照计划正确而稳定执行其预期功能的能力。这包括在其全部生命周期内运行和测试工作负载的能力。本白皮书深入介绍了有关在 AWS 中实施可靠工作负载的最佳实践指导。
可靠性支柱概述了设计原则、最佳实践和问题。有关具体实施的说明性指导，请参阅《[可靠性支柱白皮书](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp)》。
**Topics**
+ [设计原则](rel-dp.md)
+ [定义](rel-def.md)
+ [最佳实践](rel-bp.md)
+ [资源](rel-resources.md)
# 设计原则
在云中实现可靠性有五个设计原则：
+ **自动从故障中恢复：**通过监控工作负载的关键性能指标（KPI），您可以在指标超过阈值时启动自动化响应机制。这些 KPI 应该是对业务价值（而不是服务运营的技术方面）的一种度量。这可实现自动发送故障通知和跟踪故障，以及启动解决或修复故障的自动恢复流程。借助更高级的自动化功能，可以在故障发生之前预测和修复故障。
+ **测试恢复程序：**在本地环境中，经常会通过执行测试来证明工作负载能够在特定场景中正常运作。通常不会利用测试来验证恢复策略。在云中，您可以测试工作负载的故障情况，并验证恢复程序。您可以采用自动化方式来模拟不同的故障，也可以重新建立之前导致故障的场景。此方式可以在实际的故障发生以前揭示您可以测试与修复的故障路径，从而降低风险。
+ **横向扩展以提高聚合工作负载的可用性：**使用多个小型资源取代一个大型资源，以降低单个故障对整个工作负载的影响。跨多个较小的资源分配请求，确保它们不共用常见故障点。
+ **无需预估容量：**本地工作负载出现故障的常见原因是资源饱和，即对工作负载的需求超过该工作负载的容量（这通常是拒绝服务攻击的目标）。在云中，您可以监控需求和工作负载利用率，并自动添加或删除资源，以保持更高效的水平来满足需求，而不会出现过度预置或预置不足的问题。虽然还有很多限制，但有些配额是可控的，其他配额也可以管理（请参阅“管理服务配额和限制”）。
+ **通过自动化管理变更：**使用自动化方式对基础设施进行变更。必须管理的变更包括对自动化的变更，可对其进行跟踪与审查。
# 定义
在云中实现可靠性有四个领域的最佳实践：
+ 基本原理
+ 工作负载架构
+ 变更管理
+ 故障管理
要实现可靠性，您必须从基础入手，而基础是服务配额和网络拓扑适应工作负载的环境。在设计时，分布式系统的工作负载架构必须能够预防与减少故障。工作负载必须处理需求或要求的变化，而且它的设计必须能够检测故障，并自动加以修复。
# 最佳实践
**Topics**
+ [基本原理](rel-found.md)
+ [工作负载架构](rel-workload-arch.md)
+ [变更管理](rel-chg-mgmt.md)
+ [故障管理](rel-failmgmt.md)
# 基本原理
基本要求是指其范围超出单个工作负载或项目的因素。在为任何系统设计架构之前，应确定影响可靠性的基本要求。例如，您必须为数据中心提供足够的网络带宽。
在您使用 AWS 时，这些基本要求中的大部分已经包含在内，并且可以根据需要进行处理。云环境在设计层面拥有几乎无限的资源，因此 AWS 要负责满足对联网和计算容量的需求，让您可以根据需求更改资源大小和分配。
以下问题主要针对可靠性的注意事项。（有关可靠性问题的列表和最佳实践，请参阅[附录](a-reliability.md)。）
| REL 1：如何管理服务配额和约束？ |
| --- |
| 对于基于云的工作负载架构，存在服务配额（也称为服务限制）。这些限额的存在是为了防止意外调配超出所需的资源，并限制 API 操作的请求率，以保护服务不被滥用。还存在资源限制，例如光缆的比特传输速率或物理磁盘的存储量。 |
| REL 2：如何规划网络拓扑？ |
| --- |
| 工作负载通常存在于多个环境中。其中包括多个云环境（可公开访问和私有），可能还包括您现有的数据中心基础架构。计划必须包括网络注意事项，例如系统内和系统间连接、公有 IP 地址管理、私有 IP 地址管理和域名解析。 |
# 工作负载架构
可靠的工作负载始于前期的软件和基础设施设计决策。您的架构选择将影响所有 Well-Architected 支柱的工作负载行为。针对可靠性，您必须遵循特定的模式。
使用 AWS 时，工作负载开发人员可以选择要使用的语言和技术。AWSSDK 通过为 AWS 服务提供特定于语言的 API，省去了复杂的编码过程。通过这些 SDK，以及语言选择，开发人员可以实现此处列出的可靠性最佳实践。开发人员还可以通过以下资料库阅读并了解亚马逊构建和运行软件的方法：[Amazon Builders' Library](https://aws.amazon.com/builders-library/?ref=wellarchitected-wp)。
以下问题主要针对可靠性的注意事项。
| REL 3：如何设计工作负载服务架构？ |
| --- |
| 使用服务导向型架构（SOA）或微服务架构构建高度可扩展的可靠工作负载。服务导向型架构（SOA）可通过服务接口使软件组件可重复使用。微服务架构则进一步让组件变得更小、更简单。 |
| REL 4：如何在分布式系统中进行交互设计以预防发生故障？ |
| --- |
| 分布式系统依靠通信网络来互连组件，例如服务器或服务。即使这些网络中出现数据丢失或延迟情况，您的工作负载也必须可靠运行。分布式系统组件的运行方式不得对其他组件或工作负载产生负面影响。这些最佳实践可以防止故障并缩短平均故障间隔时间 (MTBF)。 |
| REL 5：如何在分布式系统中进行交互设计，从而缓解或承受故障影响？ |
| --- |
| 分布式系统依赖于通信网络实现组件（例如服务器或服务）的互联。尽管这些网络中存在数据丢失或延迟，但是您的工作负载必须可靠运行。分布式系统组件的运行方式不得对其他组件或工作负载产生负面影响。这些最佳实践使工作负载能够承受压力或故障，从中更快地恢复，并且降低此类损坏的影响。其结果是缩短平均恢复时间（MTTR）。 |
# 变更管理
您必须提前为工作负载或其环境的更改做好准备，从而实现工作负载的可靠运行。此类更改包括，外部因素施加到工作负载上的更改（如需求高峰），以及内部更改（如功能部署和安全补丁）。
您可以使用 AWS 来监控工作负载的行为，并自动对 KPI 做出响应。例如，您的工作负载可以在某个工作负载的用户增加时，添加更多服务器。您可以控制谁有权进行工作负载变更并审核这些变更的历史记录。
以下问题主要针对可靠性的注意事项。
| REL 6：如何监控工作负载资源？ |
| --- |
| 日志和指标是深入了解工作负载运行状况的强大工具。您可以将工作负载配置为监控日志和指标，并在超过阈值或发生重大事件时发送通知。通过监控，您的工作负载可以发现超出低性能阈值和发生故障的情形，从而自动恢复以做出响应。 |
| REL 7：如何设计工作负载，以适应需求变化？ |
| --- |
| 可扩展工作负载提供了自动添加或删除资源的弹性，因此资源在任何给定时间点都非常符合当前需求。 |
| REL 8：如何实施更改？ |
| --- |
| 要部署新功能，必须对更改加以控制，以确保工作负载和操作环境正在运行已知的软件，并以可预测的方式进行修补和替换。如果这些更改不受控制，那么就很难预测这些更改的影响，也很难解决由此产生的问题。 |
当您构建工作负载来根据需求变化自动添加和删除资源时，这不仅可以提高可靠性，还可以确保业务成功不至于带来额外负担。有了监控功能后，当 KPI 偏离预期标准时，系统会自动向团队发送警报。通过自动记录环境变更，您可以审核并快速发现可能影响可靠性的操作。对变更管理的控制确保您可以实施可提供所需可靠性的规则。
# 故障管理
在任何具备一定复杂度的系统中，发生故障在意料之中。可靠性要求您的工作负载知晓故障的发生，并采取相应行动以避免对可用性产生影响。工作负载必须既能承受故障，又能自动解决问题。
您可以使用 AWS，发挥自动化优势对监控数据做出响应。例如，当特定指标超过阈值时，您可以启动自动操作来解决问题。此外，与其尝试诊断并修复作为生产环境一部分的失败资源，您可以将其替换为新的资源，并对被替换的失败资源进行分析。由于云让您能够以低成本构建整个系统的临时版本，您可以使用自动化测试来验证完整的恢复流程。
以下问题主要针对可靠性的注意事项。
| REL 9：如何备份数据？ |
| --- |
| 备份数据、应用程序和配置，以满足您对恢复时间目标 (RTO) 和恢复点目标 (RPO) 的要求。 |
| REL 10：如何使用故障隔离来保护工作负载？ |
| --- |
| 故障隔离可将组件或系统故障的影响限制在定义的界限内。通过适当的隔离，界限之外的组件不受故障影响。跨多个故障隔离界限运行工作负载，可以提高工作负载对故障的韧性。 |
| REL 11：如何将工作负载设计为可承受组件故障的影响？ |
| --- |
| 在构建具有高可用性和较短平均恢复时间（MTTR）要求的工作负载时必须考虑到韧性。 |
| REL 12：如何测试可靠性？ |
| --- |
| 在为工作负载采用韧性设计以应对生产压力以后，测试是确保其按设计预期运行，并且提供所预期韧性的唯一方式。 |
| REL 13：如何规划灾难恢复（DR）？ |
| --- |
| 拥有适当的备份和冗余工作负载组件是灾难恢复策略的开始。[RTO 和 RPO 是您恢复工作负载的目标](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)。根据业务需求设置这些目标。通过实施策略来实现这些目标，同时考虑工作负载资源和数据的位置和功能。中断概率和恢复成本也是关键因素，有助于了解为工作负载提供灾难恢复的业务价值。 |
请定期备份数据并测试备份文件，确保您可以从逻辑和物理错误中恢复。管理故障的关键在于自动且频繁地测试工作负载以致其出现故障，然后观察它们如何恢复。请定期执行此操作，并确保在工作负载发生重大变更后也会启动此测试。主动跟踪 KPI 及恢复时间目标（RTO）和恢复点目标（RPO）以评测工作负载的韧性（特别是在故障测试场景中）。跟踪 KPI 将有助于您发现和减少单点故障。目标是充分测试工作负载恢复流程，确保可以恢复所有数据并继续为客户提供服务，即使面对持续存在的问题也是如此。恢复流程应该与标准生产流程一样完备而有效。
# 资源
请参阅以下资源，详细了解可靠性的最佳实践。
## 文档
+ [AWS 文档](https://docs.aws.amazon.com/index.html?ref=wellarchitected-wp)
+ [AWS 全球基础设施](https://aws.amazon.com/about-aws/global-infrastructure?ref=wellarchitected-wp)
+ [AWS Auto Scaling: How Scaling Plans Work](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html?ref=wellarchitected-wp)
+ [什么是 AWS Backup？](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html?ref=wellarchitected-wp)
## 白皮书
+ [可靠性支柱：AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp)
+ [在 AWS 上实施微服务](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html?ref=wellarchitected-wp)
# 性能效率
性能效率支柱涉及高效地使用云资源以满足性能要求的能力，以及在需求变化和技术发展时保持该效率的能力。
性能效率支柱概述了设计原则、最佳实践和问题。有关具体实施的说明性指导，请参阅《[性能效率支柱白皮书](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html?ref=wellarchitected-wp)》。
**Topics**
+ [设计原则](perf-dp.md)
+ [定义](perf-def.md)
+ [最佳实践](perf-bp.md)
+ [资源](perf-resources.md)
# 设计原则
在云中实现性能效率有五个设计原则：
+ **普及先进技术：**通过将复杂的任务委派给云供应商，使您的团队更顺利地实施高级技术。与要求您的 IT 团队学习有关托管和运行新技术的知识相比，考虑将新技术作为服务使用是一种更好的选择。例如，NoSQL 数据库、媒体转码和机器学习都是需要专业知识才能使用的技术。在云中，这些技术会转变为团队可以使用的服务，让团队能够专注于产品开发，而不是资源预置和管理。
+ **数分钟内实现全球化部署：**您可以在全球多个 AWS 区域中部署工作负载，从而以最低的成本为客户提供更低的延迟和更好的体验。
+ **使用无服务器架构**：借助无服务器架构，您无需运行和维护物理服务器即可执行传统计算活动。例如，无服务器存储服务可以充当静态网站（从而无需再使用 Web 服务器），事件服务则可以实现代码托管。这不仅能够消除管理物理服务器产生的运营负担，还可以借由以云规模运行的托管服务来降低业务成本。
+ **提升实验频率**：利用虚拟资源和可自动化的资源，您可以使用不同类型的实例、存储或配置来快速进行比较测试。
+ **因对系统运作方式了如指掌而采用最合适的工具或系统**：了解如何使用云服务，并始终使用最适合工作负载目标的技术方法。例如，在选择数据库或存储方法时考虑数据访问模式。
# 定义
在云中实现性能效率包括五个方面的最佳实践：
+ **架构选择**
+ **计算和硬件**
+ **数据管理**
+ **网络和内容分发**
+ **流程和文化**
采用数据驱动型方法来构建高性能架构。收集架构各方面的数据，从总体设计到资源类型的选择与配置都包括在内。
定期审核您的选择，确保充分利用不断发展的 AWS 云的优势。监控可以确保您随时发现与预期性能的偏差。对架构作出权衡以便提高性能，例如使用压缩或缓存，或放宽一致性要求。
# 最佳实践
**Topics**
+ [架构选择](perf-arch.md)
+ [计算和硬件](perf-compute.md)
+ [数据管理](perf-data.md)
+ [网络和内容分发](perf-networking.md)
+ [流程和文化](perf-process.md)
# 架构选择
针对特定工作负载的最佳解决方案各不相同，而且解决方案通常会结合多种方法。Well-Architected 工作负载会使用多种解决方案，并且允许使用各种不同的功能来提高性能。
我们提供多种类型和配置的 AWS 资源，可让您更轻松地找到最能满足您需求的方法。此外，我们还提供了无法使用本地基础设施轻松实现的选项。例如，Amazon DynamoDB 之类的托管服务可以提供完全托管的 NoSQL 数据库，确保在任何规模下都只会有几毫秒的延迟。
以下问题主要针对性能效率方面的注意事项。（有关性能效率问题的列表和最佳实践，请参阅[附录](a-performance-efficiency.md)。）
| PERF 1：如何为工作负载选择合适的云资源和架构模式？ |
| --- |
| 一个工作负载通常需要采用多种方法才能实现更高效的性能。Well-Architected 系统会使用多种解决方案和功能来提高性能。 |
# 计算和硬件
适合特定工作负载的最佳计算方案会因应用程序设计、使用模式和配置设置而有所不同。架构可能会使用不同的计算方案来支持各种组件，并允许使用不同的功能来提高性能。为架构选择错误的计算方案可能会降低性能效率。
在 AWS 中，计算资源有三种形式：实例、容器和函数：
+ **实例**是虚拟化服务器，因此您只需通过一个按钮或一次 API 调用即可对其功能进行调整。因为云中的资源决策不是固定不变的，所以您可以尝试使用不同的服务器类型。在 AWS，这些虚拟服务器实例具有不同的系列和大小，并且可以提供各种功能，包括固态硬盘（SSD）和图形处理单元（GPU）。
+ **容器**是一种操作系统虚拟化方法，允许您在资源隔离的流程中运行应用程序及其依赖项。AWS Fargate 是适用于容器的无服务器计算引擎。如果您需要控制计算环境的安装、配置和管理，则可以使用 Amazon EC2。此外，您还可以从多个容器编排平台中进行选择：Amazon Elastic Container Service（ECS）或 Amazon Elastic Kubernetes Service（EKS）。
+ **函数**从您要应用的代码中抽象出运行环境。例如，AWS Lambda 允许您在不运行实例的情况下运行代码。
以下问题主要针对性能效率方面的注意事项。
| PERF 2：如何在工作负载中选择和使用计算资源？ |
| --- |
| 适合工作负载的更高效的计算解决方案会根据应用程序设计、使用模式和配置设置而有所不同。架构可以使用不同的计算解决方案来支持各种组件，并且可以开启各种不同的功能来提高性能。为架构选择错误的计算解决方案可能会降低性能效率。 |
# 数据管理
针对特定系统的最佳数据管理解决方案往往取决于数据类型（数据块、文件或对象）、访问模式（随机或连续）、所需吞吐量、访问频率（在线、离线、归档）、更新频率（WORM、动态）以及可用性与持久性限制等因素。Well-Architected 工作负载使用专门构建的数据存储，这些存储允许使用不同的功能来提高性能。
在 AWS 中，存储有三种形式：对象、数据块和文件：
+ **对象存储**提供了一个可扩展的耐用平台，允许从任何互联网位置访问数据，适用于用户生成的内容、活动存档、无服务器计算、大数据存储或备份以及恢复。Amazon Simple Storage Service（Amazon S3）是一种对象存储服务，提供行业领先的可扩展性、数据可用性、安全性和性能。Amazon S3 的耐用性可达到 99.999999999%（11 个 9），为全球各地的公司存储数百万个应用程序的数据。
+ **数据块存储**为每个虚拟主机提供高可用性、一致性、低延迟的数据块存储，类似于直连存储（DAS）或存储区域网络（SAN）。Amazon Elastic Block Store（Amazon EBS）旨在满足需要持久性存储的工作负载的需求，此类持久性存储可通过 EC2 实例访问，帮助您根据适合的存储容量、性能和成本对应用程序进行微调。
+ **文件存储**可以跨多个系统提供对共享文件系统的访问。Amazon Elastic File System（Amazon EFS）等文件存储解决方案非常适合大型内容存储库、开发环境、媒体存储或用户主目录等应用场景。Amazon FSx 让您可以经济高效地启动和运行热门文件系统，因此您可以利用应用广泛的开源和商业许可文件系统的丰富功能集和快速性能。
以下问题主要针对性能效率方面的注意事项。
| PERF 3：如何存储、管理和访问工作负载中的数据？ |
| --- |
| 针对某个系统的更高效存储解决方案往往取决于访问操作类型（数据块、文件或对象）、访问模式（随机或连续）、所需吞吐量、访问频率（在线、离线、归档）、更新频率（WORM、动态）以及可用性与持久性限制等因素。架构良好的系统使用多种存储解决方案，并且可以开启各种不同的功能，以便提高性能和高效地使用资源。 |
# 网络和内容分发
适合某个工作负载的最佳网络解决方案会因延迟、吞吐量要求、抖动和带宽而有所不同。物理约束（例如用户资源或本地资源）决定位置选项。这些约束可以通过边缘站点或资源置放来抵消。
在 AWS，网络资源以虚拟化形式存在，而且以多种类型和配置提供。这让您可以更轻松地找到贴合您需求的网络方案。AWS 提供多种产品功能（例如增强联网、Amazon EC2 联网优化实例、Amazon S3 传输加速和动态 Amazon CloudFront）来优化网络流量。AWS 还可以提供多种联网功能（例如 Amazon Route 53 延迟路由、Amazon VPC 端点、AWS Direct Connect 和 AWS Global Accelerator）来减少网络距离或抖动。
以下问题主要针对性能效率方面的注意事项。
| PERF 4：如何在工作负载中选择和配置网络资源？ |
| --- |
| 该问题涵盖在云端设计、配置和运行高效的联网和内容分发解决方案的指导和最佳实践。 |
# 流程和文化
在最初构建工作负载时，您可以采用一些原则和实践，协助您更好地运行高效、高性能的云工作负载。要采用能提高云工作负载性能效率的文化，请考虑以下关键原则和实践。
要打造这种文化，请考虑以下关键原则：
+ **基础设施即代码：**使用 AWS CloudFormation 模板之类的方法定义您的基础设施即代码。使用模板，您可以将基础设施与应用程序代码和配置一道放入源代码控制中。这让您能够将用于开发软件的实践应用到基础设施，从而能够快速迭代。
+ **部署管道：**使用持续集成/连续部署（CI/CD）管道（例如，源代码存储库、构建系统、部署和测试自动化）来部署基础设施。这让您能够以可重复、一致且低成本的方式进行迭代部署。
+ **明确定义的指标：**设置和监控指标以捕获关键性能指标（KPI）。我们建议您使用技术和业务指标。网站或移动应用程序的关键指标是首个字节捕获时间或渲染时间。其他常规的适用指标包括线程计数、垃圾回收速率以及等待状态。业务指标，如单次请求累计总成本，可以提醒您留意降低成本的方法。仔细考虑解读指标的方式。例如，您可以选择最大值或第 99 个百分位数，而不是平均值。
+ **自动性能测试：**作为部署过程的一部分，在快速运行测试成功通过后自动启动性能测试。自动化应创建新环境、设置初始条件（如测试数据），然后运行一系列基准和负载测试。这些测试的结果应回绑到构建中，以便您可以随着时间推移跟踪性能变化。对于长时间运行的测试，您可以使管道的这一部分与构建的剩余部分异步进行。或者，您也可以使用 Amazon EC2 竞价型实例来通宵运行性能测试。
+ **负载生成：**您应该创建复制综合或预先记录的用户旅程的一系列测试脚本。这些脚本应该是幂等的，而不是耦合，您可能需要包含*预热*脚本以便产生有效结果。测试脚本应尽可能再现生产中的使用行为。您可以使用软件或软件即服务（SaaS）解决方案来生成负载。考虑使用 [AWS Marketplace](https://aws.amazon.com/marketplace/) 解决方案和[竞价型实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)：它们是用于生成负载的经济高效的方法。
+ **性能可见性：**关键指标应该对您的团队可见，尤其是针对每个构建版本的指标。这让您能够随着时间推移看到所有重大的正面或负面趋势。您还应展示有关错误或异常数量的指标，确保测试的是正常工作的系统。
+ **可视化：**使用可视化技术，清楚了解出现性能问题、热点、等待状态或低利用率的位置。在架构图上叠加性能指标：调用图表或代码有助于快速发现问题。
+ **定期审核流程：**通常，不存在或不完整的性能审核流程会导致架构性能不佳。如果您的架构性能不佳，请实施性能审核流程，以便推动迭代改进。
+ **持续优化：**采用一种文化，不断优化云工作负载的性能效率。
以下问题主要针对性能效率方面的注意事项。
| PERF 5：您使用什么流程来提高工作负载的性能效率？ |
| --- |
| 在最初构建工作负载时，您可以采用一些原则和实践，协助您更好地运行高效、高性能的云工作负载。要采用能提高云工作负载性能效率的文化，请考虑以下关键原则和实践。 |
# 资源
请参阅以下资源，详细了解性能效率的最佳实践。
## 文档
+ [Amazon S3 性能优化](https://docs.aws.amazon.com/AmazonS3/latest/dev/PerformanceOptimization.html?ref=wellarchitected-wp)
+ [Amazon EBS 卷性能](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html?ref=wellarchitected-wp)
## 白皮书
+ [性能效率支柱](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html?ref=wellarchitected-wp)
## 视频
+ [AWS re:Invent 2019: Amazon EC2 foundations (CMP211-R2)](https://www.youtube.com/watch?v=kMMybKqC2Y0&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Leadership session: Storage state of the union (STG201-L)](https://www.youtube.com/watch?v=39vAsGi6eEI&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Leadership session: AWS purpose-built databases (DAT209-L)](https://www.youtube.com/watch?v=q81TVuV5u28&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Connectivity to AWS and hybrid AWS network architectures (NET317-R1)](https://www.youtube.com/watch?v=eqW6CPb58gs&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Powering next-gen Amazon EC2: Deep dive into the Nitro system (CMP303-R2)](https://www.youtube.com/watch?v=rUY-00yFlE4&ref=wellarchitected-wp)
+ [AWS re:Invent 2019: Scaling up to your first 10 million users (ARC211-R)](https://www.youtube.com/watch?v=kKjm4ehYiMs&ref=wellarchitected-wp)
# 成本优化
成本优化支柱包括以最低价格运行系统来实现业务价值的能力。
成本优化支柱概述了设计原则、最佳实践和问题。有关具体实施的说明性指导，请参阅《[成本优化支柱白皮书](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html?ref=wellarchitected-wp)》。
**Topics**
+ [设计原则](cost-dp.md)
+ [定义](cost-def.md)
+ [最佳实践](cost-bp.md)
+ [资源](cost-resources.md)
# 设计原则
在云中实现成本优化有五个设计原则：
+ **实施云财务管理：**要获得财务上的成功并加速在云中实现业务价值，请投资云财务管理和成本优化。您的组织应当投入时间和资源增强自身在这个新的技术和使用情况管理领域中的能力。与安全性或卓越运营能力类似，您的组织需要通过知识构建、计划、资源和流程来培养能力，从而成为一家具有成本效益的组织。
+ **采用消费模式**：仅为所需计算资源付费，并可根据业务需求而非复杂的预测增加或减少使用情况。例如，开发和测试环境通常只需要在每个工作日运行八个小时。您可以在不需要时停用这些资源，从而实现 75% 的潜在成本节约（40 小时对比 168 小时）。
+ **衡量整体效率**：衡量工作负载的业务产出及其交付成本。使用这种衡量方式了解您通过提高产出和降低成本获得的收益。
+ **不再把钱花在千篇一律的繁重工作上：**AWS 会帮您料理繁重的数据中心运营工作，如安装、堆叠和驱动服务器。它还消除了使用托管服务管理操作系统和应用程序的运营负担。因此，您可以集中精力处理客户和业务项目而非 IT 基础设施。
+ **对支出进行分析和归因**：使用云，您可以更轻松地确定系统的准确使用情况和成本，从而将 IT 成本透明地分摊到各个工作负载拥有者。这有助于衡量投资回报率（ROI），并让工作负载拥有者能够据此优化资源和降低成本。
# 定义
在云中实现成本优化包括五个方面的最佳实践。
+ **践行云财务管理**
+ **支出和使用情况意识**
+ **具有成本效益的资源**
+ **管理需求和供应资源**
+ **持续优化**
与良好架构框架中的其他支柱一样，成本优化支柱也需要权衡各种因素，例如，是优化上市速度还是优化成本。在某些情况下，最好优化上市速度以便快速上市、交付新功能或按时完成任务，而不是优化预付成本。设计决策有时是在仓促中而非是由数据决定的，并且人们总是倾向于过度补偿“以防万一”，而不是花时间进行基准测试以获得成本最优的部署。这可能会导致过度预置和优化不足的部署。但是，当您必须将资源从本地环境“直接迁移”到云，然后再进行优化时，这是一个合理的选择。通过预先在成本优化策略中投入适量的精力，您可以确保始终如一地遵守最佳实践，避免不必要的过度预置，从而更轻松地实现云的经济优势。以下部分介绍了一些技巧和最佳实践，可帮助您开始并持续实施工作负载的云财务管理和成本优化。
# 最佳实践
**Topics**
+ [践行云财务管理](cost-cfm.md)
+ [支出和使用情况意识](cost-aware.md)
+ [具有成本效益的资源](cost-cereso.md)
+ [管理需求和供应资源](cost-mandem.md)
+ [持续优化](cost-opti.md)
# 践行云财务管理
采用云后，由于缩短了审批、采购和基础设施部署周期，技术团队的创新速度会更快。要实现业务价值和财务成功，需要实施一种在云中管理财务的新方法。这种方法便是云财务管理，通过实施组织范围的知识构建、计划、资源和流程，在整个组织内培养能力。
许多组织由许多不同的单位构成，而这些单位又具有不同的要务。若能让组织遵循一组商定的财务目标并为组织提供实现这些目标的机制，将会打造一个更高效的组织。一个有能力的组织的创新和构建速度更快，更敏捷，并能够适应任何内部或外部因素。
在 AWS 中，您可以使用 Cost Explorer，也可以选择使用 Amazon Athena 和 Amazon QuickSight 查看成本和使用情况报告（CUR），从而了解整个组织的成本和使用情况。AWSBudgets 可主动发出成本和使用情况通知。AWS 博客提供有关新服务和新功能的信息，以确保您及时了解新发布的服务。
以下问题主要针对成本优化方面的注意事项。（有关成本优化问题的列表和最佳实践，请参阅[附录](a-cost-optimization.md)。）
| COST 1：如何实施云财务管理？ |
| --- |
| 实施云财务管理有助于组织在 AWS 上优化成本和使用情况并进行扩展，从而实现商业价值和财务成功。 |
在组建成本优化部门时，需要包括成员并为团队配备 CFM 和成本优化方面的专家。现有的团队成员将了解组织的当前运作方式以及如何快速实施改进。此外，还可以考虑配备拥有辅助或专业技能组合的人员，例如具备分析和项目管理能力的人员。
在组织中树立成本意识时，需要改进现有计划和流程或基于现有计划和流程进行构建。与构建新流程和计划相比，向现有流程和计划增添内容要快得多。这样将更快地取得成果。
# 支出和使用情况意识
通过云，您可以获得更大的灵活性和敏捷性，从而支持创新以及快速的开发和部署。这样便节省了自建本地基础设施所需的人工环节和时间，包括确定硬件规格、协商报价、管理购买订单、安排发货和部署资源。然而，要实现这种易用性并利用近乎无限的按需容量，我们需要以新方式考虑支出。
很多企业有多个由不同团队运行的系统。将资源成本分摊到各个组织或产品拥有者可以推动更高效的资源使用模式，减少浪费。准确的成本分摊能够帮助您了解哪些产品是真正盈利的，让您能够做出更明智的预算分配决策。
在 AWS 中，您可以使用 AWS Organizations 或 AWS Control Tower 创建账户结构，这种方式不仅实现了分离，而且有助于分配成本和使用。此外，也可以通过资源标记在使用情况和成本中标注业务和组织信息。使用 AWS Cost Explorer 查看您的成本和使用情况，或者使用 Amazon Athena 和 Amazon QuickSight. 创建自定义控制面板和分析。成本和使用情况控制通过 AWS 预算的通知来实现，并使用 AWS Identity and Access Management（IAM）和服务配额进行控制。
以下问题主要针对成本优化方面的注意事项。
| COST 2：您如何管理使用情况？ |
| --- |
| 制定各种策略和机制，确保花费适当的成本来达到目标。采用制约与平衡方法，您可以在不超支的情况下进行创新。 |
| COST 3：如何监控使用情况和成本？ |
| --- |
| 建立策略和程序以便监控并适当分配您的成本。这让您能够衡量和改进此工作负载的成本效益。 |
| COST 4：您如何停用资源？ |
| --- |
| 在从项目开始到结束的过程中实施变更控制和资源管理。这有助于您关闭未使用的资源，以便减少浪费。 |
您可以使用成本分配标记对 AWS 使用情况和成本进行分类并跟踪。当您对 AWS 资源（例如 EC2 实例或 S3 存储桶）应用标记后，AWS 将通过使用情况和成本标记生成成本和使用情况报告。您可以使用代表组织类别的标记（例如成本中心、工作负载名称或拥有者）整理您的多个服务的成本。
确保在成本和使用情况报告和监控中使用正确的详细级别和粒度。要获得大概见解和趋势，请在 AWS Cost Explorer 中使用每日粒度。要更深入地进行分析和检查，请在 AWS Cost Explorer中使用每小时粒度，或者在 Amazon Athena 和 Amazon Quick 中以每小时为粒度查看成本和使用情况报告（CUR）。
结合标记资源和实体生命周期跟踪（员工、项目），您可以确定无法再为组织创造价值而应停用的孤立资源或项目。您可以设置账单提醒，以在预计超支时通知您。
# 具有成本效益的资源
为工作负载使用合适的实例和资源是节约成本的关键。例如，在小型服务器上运行某个报告需要五个小时，而在另一个两倍成本的大型服务器上运行只需要一个小时。虽然两个服务器提供同样的结果，但小型服务器会逐渐产生更多成本。
良好架构的工作负载会使用最具有成本效益的资源，这样可以产生巨大而积极的经济效益。您还可以使用托管服务降低成本。例如，您可以使用按电子邮件收费的服务，而无需自己维护电子邮件服务器。
AWS 提供各种灵活且具有成本效益的定价选项，您可以从 Amazon EC2 和其他服务获取能最快满足您需求的实例。*按需型**实例*允许按小时支付计算容量的费用，且无需承诺最低用量。*节省计划和预留实例*与按需定价相比最高可节约 75% 的成本。使用竞价型实例，您可以利用未使用的 Amazon EC2 容量，并且与按需定价相比最高可节约 90% 的成本。*竞价型实例*适用于以下情况：系统可以容忍使用服务器实例集，其中单个服务器可以动态装卸（例如无状态 Web 服务器）、批处理、高性能计算及大数据场景。
选择合适的服务还可以减少使用情况和降低成本：例如，使用 CloudFront 可以最大限度地减少数据传输成本；或降低成本，例如，使用 Amazon Aurora on RDS 可以消除昂贵的数据库许可成本。
以下问题主要针对成本优化方面的注意事项。
| COST 5：您在选择服务时如何评估成本？ |
| --- |
| Amazon EC2、Amazon EBS 和 Amazon S3 属于基础 AWS 服务。托管服务（如 Amazon RDS 和 Amazon DynamoDB）属于更高级别或应用程序级别的 AWS 服务。通过选择适当的基础服务和托管服务，您可以优化此工作负载，从而降低成本。例如，使用托管服务，您可以节省或消除大部分管理和运营开销，让您有精力从事应用程序和业务相关活动。 |
| COST 6：在选择资源类型、规模和数量时，如何实现成本目标？ |
| --- |
| 确保选择适合当前任务的资源规模和资源数量。选择最经济实惠的资源类型、规模和数量可以尽可能减少浪费。 |
| COST 7：您如何使用定价模式来降低成本？ |
| --- |
| 使用最适合的资源定价模式可以尽可能减少支出。 |
| COST 8：您如何规划数据传输费用？ |
| --- |
| 确保规划并监控数据传输费用，以便制定架构决策，尽可能降低成本。持续以小步迭代的方式进行架构优化可以实现运营成本的大幅降低。 |
通过在选择服务时考虑成本因素，并使用 Cost Explorer 和 AWS Trusted Advisor 等工具定期检查 AWS 使用情况，您可以主动监控利用率并相应地调整部署。
# 管理需求和供应资源
在您迁移到云时，您仅为所需内容付费。您可以在需要时供应与工作负载需求匹配的资源，从而降低昂贵且浪费的过度预置需求。还可以通过节流、缓冲区或队列来修改需求，以满足需求并以更少的资源达成目标，从而降低成本，或者在以后使用批处理服务处理需求。
在 AWS 中，您可以自动预置资源来满足工作负载需求。通过使用基于需求或时间的方法进行 Auto Scaling，您可根据需要添加和删除资源。如果您可以预测需求变化，便可以节省更多资金并确保资源与工作负载需求匹配。您可以使用 Amazon API Gateway 实施节流，也可以使用 Amazon SQS 在工作负载中实施队列。这两种方法都允许您修改工作负载组件的需求。
以下问题主要针对成本优化方面的注意事项。
| COST 9：如何管理需求和供应资源？ |
| --- |
| 为了工作负载的性能与支出实现平衡，请确保您支付过费用的所有资源都得到利用，并避免出现实例利用率过低的情况。无论是从运营成本（由于过度使用导致性能下降）还是从浪费 AWS 支出（由于过度预置）的角度衡量，利用率指标过高或过低都会对组织产生负面影响。 |
当进行修改需求和供应资源的设计时，请主动考虑资源使用模式、预置新资源所需要耗费的时间，以及需求模式的可预测性。当管理需求时，确保您具有大小正确的队列或缓冲区，并在所需的时间内响应工作负载需求。
# 持续优化
AWS 不断发布新服务和功能，因此您最好不断审视现有架构决策，确保其始终最具成本效益。当您的需求发生变化时，请主动停用不再需要的资源、整体服务和系统。
实施新功能或资源类型可以逐步优化您的工作负载，同时最大程度地减少实施变更所需的工作量。这样可不断提高效率，并确保您始终使用最新的技术，从而降低运营成本。您还可以使用新服务替换或向工作负载中添加新组件。这可以显著提高效率，因此必须定期审查您的工作负载，并实施新服务和新功能。
以下问题主要针对成本优化方面的注意事项。
| COST 10：如何评估新服务? |
| --- |
| AWS 不断发布新服务和功能，因此您最好不断审视现有架构决策，确保其始终最具成本效益。 |
定期审查部署时，评估更新的服务如何帮助您节省成本。例如，Amazon Aurora on Amazon RDS 可以降低关系数据库的成本。使用无服务器（例如 Lambda）服务，无需操作和管理实例即可运行代码。
| COST 11：如何评估工作量成本？ |
| --- |
| 评估云端运营的工作量成本，审查耗时的云运营，并通过采用相关 AWS 服务、第三方产品或自定义工具实现自动化，以减少人力和成本。 |
# 资源
请参阅以下资源，详细了解成本优化的最佳实践。
## 文档
+ [AWS 文档](https://docs.aws.amazon.com/index.html?ref=wellarchitected-wp)
## 白皮书
+ [成本优化支柱](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html?ref=wellarchitected-wp)
# 可持续性
可持续性支柱侧重于环境影响，尤其是能源消耗和效率，因为它们是构架师在直接采取行动以减少资源使用时依据的重要杠杆。有关具体实施的说明性指导，请参阅《[可持续性支柱白皮书](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp)》。
**Topics**
+ [设计原则](sus-design-principles.md)
+ [定义](sus-def.md)
+ [最佳实践](sus-bp.md)
+ [资源](sus-resources.md)
# 设计原则
实现云中可持续性有六项设计原则：
+ **了解您的影响：**衡量您的云工作负载的影响并为工作负载的未来影响建模。包括所有影响来源，例如客户使用您的产品所产生的影响，以及产品最终淘汰和停用所产生的影响。通过查看每个工作单元所需的资源和排放量，将生产性输出与云工作负载的总体影响进行比较。使用这些数据来建立关键绩效指标（KPI），评估在降低影响的同时提高生产力的方法，并估计提议的更改随时间的推移所产生的影响。
+ **建立可持续性目标：**对于每个云工作负载，建立长期可持续性目标，例如减少每个事务所需的计算和存储资源。针对现有工作负载的可持续性改进的投资回报进行建模，并为负责人提供必须投资于可持续性目标的资源。规划增长并构建您的工作负载，以便增长可降低影响强度（以适当的单位衡量，例如每用户或每事务）。目标可帮助您支持您的企业或组织更广泛的可持续性目标、识别回归并确定潜在改进领域的优先级。
+ **最大限度提高利用率：**适当调整工作负载规模并实施高效设计，确保实现高利用率，最大程度提高底层硬件的能源效率。由于每台主机的基准功耗，两台以 30% 利用率运行的主机的效率低于一台以 60% 利用率运行的主机。同时，减少或尽可能减少空闲资源、处理和存储，以减少支持工作负载所需的总能源。
+ **预测并采用更高效的新硬件和软件产品：**支持您的合作伙伴和供应商进行上游改进，以帮助您减少云工作负载的影响。持续监控和评估更高效的新硬件和软件产品。设计灵活性以允许快速采用高效的新技术。
+ **使用托管服务：**在庞大的客户群中共享服务有助于更充分地利用资源，从而减少支持云工作负载所需的基础设施数量。例如，客户可以通过将工作负载迁移到 AWS 云 并采用托管式服务（例如用于无服务器容器的 AWS Fargate，AWS 在其中大规模运行并负责其高效运行）来分散电力和网络等常见数据中心组件的影响。使用有助于将影响降至最低的托管式服务，例如使用 Amazon S3 生命周期配置将不经常访问的数据自动移动到冷存储，或使用 Amazon EC2 Auto Scaling 来调整容量以满足需求。
+ **减少云工作负载对下游的影响：**减少使用服务所需的能源或资源量。减少客户为了使用您的服务而升级其设备的需要。使用设备场进行测试以了解预期影响，并对客户进行测试以了解使用您服务的实际影响。
# 定义
在云中实现可持续性包括六个方面的最佳实践：
+ 区域选择
+ 符合需求
+ 软件和架构
+ 数据
+ 硬件和服务
+ 流程和文化
云中的可持续性是一项近乎持续的工作，侧重于通过从所预置的资源中获得最大收益并尽力减少所需的总资源，让工作负载的所有组件降低能耗并提高能效。这项工作可能包括最初选择高效的编程语言、采用现代算法、使用高效的数据存储技术、部署大小合适且高效的计算基础设施，以及最大限度地减少对高性能终端用户硬件的需求。
# 最佳实践
**Topics**
+ [区域选择](sus-region-selection.md)
+ [符合需求](sus-user-behavior-patterns.md)
+ [软件和架构](sus-software-architecture-patterns.md)
+ [数据管理](sus-data-patterns.md)
+ [硬件和服务](sus-hardware-patterns.md)
+ [流程和文化](sus-development-deployment-patterns.md)
# 区域选择
为工作负载选择区域会显著影响其 KPI，包括性能、成本和碳足迹。为了提高这些 KPI，您应该根据业务需求和可持续性目标为工作负载选择区域。
以下问题主要针对安全方面的注意事项。（有关可持续性问题的列表和最佳实践，请参阅[附录](a-sustainability.md)。）
| SUS 1：您如何为工作负载选择区域？ |
| --- |
| 为工作负载选择区域会显著影响其 KPI，包括性能、成本和碳足迹。为了提高这些 KPI，您应该根据业务需求和可持续性目标为工作负载选择区域。 |
# 符合需求
用户和应用程序使用您的工作负载及其他资源的方式可以帮助您确定改进方面，以实现可持续性目标。扩展基础设施以持续匹配需求，并确认您仅使用了支持用户所需的最少资源。使服务水平与客户需求保持一致。定位资源以限制用户和应用程序使用这些资源所需的网络。删除未使用的资产。为团队成员提供满足其需求的设备，并尽可能降低他们的可持续性影响。
以下问题主要针对可持续性方面的注意事项：
| SUS 2：如何将云资源与您的需求相匹配？ |
| --- |
| 用户和应用程序使用您的工作负载及其他资源的方式可以帮助您确定改进方面，以实现可持续性目标。扩展基础设施以持续匹配需求，并确认您仅使用了支持用户所需的最少资源。使服务水平与客户需求保持一致。定位资源以限制用户和应用程序使用这些资源所需的网络。删除未使用的资产。为团队成员提供满足其需求的设备，并尽可能降低他们的可持续性影响。 |
使用用户负载扩展基础设施：确定利用率低或无利用率的时段，缩减资源以减少过剩容量并提高效率。
根据可持续性目标调整 SLA：定义和更新服务等级协议（SLA），例如可用性或数据留存期，以最大限度地减少支持工作负载所需的资源数量，同时继续满足业务需求。
减少未使用资产的创建和维护：分析应用程序资产（例如预编制的报告、数据集和静态图像）和资产访问模式，以识别冗余、利用率低下的情况和潜在的淘汰目标。整合具有冗余内容的生成资产（例如，具有重叠或共用数据集和输出的月度报告），以减少重复输出时消耗的资源。淘汰未使用的资产（例如，已停售产品的图片）以释放消耗的资源，并减少用于支持工作负载的资源数量。
针对用户位置优化工作负载的地理位置：分析网络访问模式以识别您的客户建立连接的地理位置。选择可减少网络流量必须传输的距离的区域和服务，以减少支持您的工作负载所需的总网络资源。
针对执行的活动优化团队成员资源：优化提供给团队成员的资源，在支持其需求的同时最大程度地降低对可持续性的影响。例如，在利用率高的共享云桌面上，而不是在利用率不高的强力单用户系统上，执行渲染和编译等复杂的操作。
# 软件和架构
实施用于执行负载平滑和保持已部署资源始终如一的高利用率的模式，以最大限度地减少资源消耗。由于用户行为会随着时间的推移而发生变化，组件可能会因缺乏使用而变得空闲。修改模式和架构以整合未充分利用的组件，从而提高整体利用率。停用不再需要的组件。了解工作负载组件的性能，并优化消耗最多资源的组件。注意客户用来访问您服务的设备，并实施相应的模式以最大限度地减少设备升级需求。
以下问题主要针对可持续性方面的注意事项。
| SUS 3：您如何利用软件和架构模式来支持您的可持续性目标？ |
| --- |
| 实施用于执行负载平滑和保持已部署资源始终如一的高利用率的模式，以最大限度地减少资源消耗。由于用户行为会随着时间的推移而发生变化，组件可能会因缺乏使用而变得空闲。修改模式和架构以整合未充分利用的组件，从而提高整体利用率。停用不再需要的组件。了解工作负载组件的性能，并优化消耗最多资源的组件。注意客户用来访问您服务的设备，并实施相应的模式以最大限度地减少设备升级需求。 |
针对异步和计划作业优化软件和架构：使用高效的软件设计和架构来尽可能减少每个工作单元所需的平均资源。实施可促成均匀的组件利用率的机制，以减少任务之间的空闲资源并最大限度地减少负载峰值的影响。
移除或重构工作负载组件的用处很低或根本没用：监控工作负载活动，以确定一定时间内各个组件的利用率的变化。移除未使用且不再需要的组件，并重构利用率低的组件，以限制资源浪费。
优化消耗最多时间或资源的代码区域：监控工作负载活动以确定消耗最多资源的应用程序组件。优化在这些组件中运行的代码，以最大限度地减少资源使用和提高性能。
优化对客户设备的影响：了解客户用来使用您服务的设备、它们的预期生命周期，以及更换这些组件对财务和可持续性的影响。实施软件模式和架构，以最大限度地减少客户更换和升级设备的需求。例如，使用与旧硬件和操作系统版本向后兼容的代码实现新功能，或管理有效负载的大小，使其不超过目标设备的存储容量。
使用最有效地支持数据访问和存储模式的软件模式和架构：了解数据在工作负载中被使用、被用户使用、被传输和存储的方式。选择相应的技术以最大限度地减少数据处理和存储要求。
# 数据管理
以下问题主要针对可持续性方面的注意事项。
| SUS 4：您如何利用数据管理策略和模式来支持可持续性目标？ |
| --- |
| 实施数据管理实践以减少支持工作负载所需的预置存储，以及使用存储所需的资源。了解您的数据，并使用能够更有效地支持数据的商业价值及其使用方式的存储技术和配置。当需求减少时，将数据移到更高效、性能更低的存储中，并删除不再需要的数据。 |
实施数据分类策略：对数据进行分类以了解其对业务结果的重要性。使用此信息来确定何时可以将数据移动到更节能的存储，或者何时可以安全删除数据。
使用支持数据访问和存储模式的技术：使用最能支持您的数据访问和存储方式的存储技术，以在支持您的工作负载的同时最大限度地减少预置资源。例如，固态硬盘（SSD）比磁性驱动器更耗能，应该仅用于活跃的数据使用场景。对不常访问的数据使用节能的存档级存储。
使用生命周期策略删除不必要的数据：管理所有数据的生命周期并自动执行删除时间表，以最大限度地减少工作负载的总存储需求。
最大限度地减少数据块存储中的过度预置：要尽可能减少总预置存储，请创建大小分配适合工作负载的数据块存储。随着数据的增长，使用弹性卷扩展存储，而无需调整附加到计算资源的存储大小。定期检查弹性卷并缩小过度预置的卷，以适应当前数据大小。
删除不需要或多余的数据：仅在必要时复制数据，以最大程度地减少消耗的总存储空间。使用备份技术在文件和数据块级别进行重复数据删除。限制使用独立驱动器冗余阵列（RAID）配置，除非需要满足 SLA。
使用共享文件系统或对象存储来访问通用数据：采用共享存储和单一事实来源，以避免重复数据删除并降低工作负载的总存储需求。仅在需要时从共享存储中获取数据。分离未使用的卷以释放资源。最大限度地减少跨网络的数据移动：使用共享存储和访问区域数据存储中的数据，以最大限度地减少支持工作负载数据移动所需的总网络资源。
仅在难以重新创建时备份数据：为了最大限度地减少存储消耗，仅备份具有商业价值或满足合规性要求所必需的数据。检查备份策略并在恢复方案中排除没有价值的临时存储。
# 硬件和服务
寻找机会，通过更改硬件管理实践来降低工作负载可持续性影响。最大限度地减少预置和部署所需的硬件数量，并为各项工作负载选择最高效的硬件和服务。
以下问题主要针对可持续性方面的注意事项。
| SUS 5：您如何选择并使用架构中的云硬件和服务来支持自己的可持续性目标？ |
| --- |
| 寻找机会，通过更改硬件管理实践来降低工作负载可持续性影响。最大限度地减少预置和部署所需的硬件数量，并为各项工作负载选择最高效的硬件和服务。 |
使用最少的硬件来满足您的需求：通过使用云的功能，您可以对工作负载实施进行频繁更改。在需求变化时更新已部署的组件。
使用影响最小的实例类型：持续监控新实例类型的发布并利用能效改进，包括那些旨在支持特定工作负载（例如机器学习训练和推理以及视频转码）的实例类型。
使用托管服务：托管服务将维持已部署硬件的高平均利用率和可持续性优化的责任转移给 AWS。使用托管服务将服务的可持续性影响分散到服务的所有租户，从而减少您的个人份额。
优化您对 GPU 的使用：图形处理单元（GPU）可能是高功耗的来源，许多 GPU 工作负载是高度可变的，例如渲染、转码以及机器学习训练和建模。仅在需要时运行 GPU 实例，并在不需要时自动停用它们，以最大限度地减少资源消耗。
# 流程和文化
寻找机会，通过更改开发、测试和部署实践来降低可持续性影响。
以下问题主要针对可持续性方面的注意事项。
| SUS 6：您的组织流程如何支持您的可持续性目标？ |
| --- |
| 寻找机会，通过更改开发、测试和部署实践来降低可持续性影响。 |
采用可以快速引入可持续性改进的运营：在将潜在潜在改进部署到生产环境之前，对其进行测试和验证。在计算改进的潜在未来收益时，考虑测试成本。开发低成本的测试运营，以实现细微的改进。
使您的工作负载处于最新状态：最新的操作系统、库和应用程序可以提高工作负载效率，并促进更高效技术的采用。最新的软件可能还包括更准确地衡量工作负载对可持续性的影响的功能，因为供应商提供的功能是为了满足其自身的可持续性目标。
提高构建环境的利用率：使用自动化功能和基础设施作为代码，在需要时启动预生产环境，并在不使用时将其关闭。一种常见模式是安排与开发团队成员的工作时间相吻合的可用时段。休眠是一个有用的工具，它可以保存状态，并且只在需要时才快速将实例上线。使用具有容量爆增的实例类型、竞价型实例、弹性数据库服务、容器和其他技术，使开发和测试能力与使用相一致。
使用托管式设备场进行测试：使用托管式设备场将硬件制造和资源使用的可持续性影响分散到多个租户。托管式设备场提供多种设备类型，使您能够支持不太受欢迎的较旧硬件，并避免不必要的设备升级对客户可持续性的影响。
# 资源
请参阅以下资源，了解关于我们的可持续性最佳实践的信息。
## 白皮书
+ [可持续性支柱](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp)
## 视频
+ [The Climate Pledge](https://www.youtube.com/watch?v=oz9iO0EOpI0&ref=wellarchitected-wp)