IT Lab Service – Bing哥的博客

Architecting for the Cloud – AWS Best Practices

这份白皮书提供了架构的建议，告诉解决方案架构师和开发者如何在AWS上设计出安全、可靠、高性能和高性价比的架构。

云计算的魅力

使用云计算，可以带给我们非常多的好处，比较有代表性的是：

• 几乎没有太多初始成本
• 随时随地创建基础架构资源（甚至自动化地创建）
• 更高的资源利用率（用多少才申请多少资源）
• 更高的性价比（用多少才付多少钱）
• 更快的迭代速度和更短的市场推出时间

技术优势

• 自动化（基础架构即代码，IAAC）
• 自动伸缩的架构
• 提前伸缩资源
• 更有效的开发生命周期（CI/CD，敏捷开发，快速迭代）
• 提高测试性
• 更好的灾难恢复和业务持续性

弹性

使用云计算我们可以有非常灵活的弹性。下图展示给我们了基础架构的花销和时间推移关系的关系。

我们可以看到在传统的基础架构中，如果实际需求（红线）不断地增加，我们可以通过增加CPU，内存，磁盘空间等进行纵向扩展（蓝色虚线）；或者通过增加更多的服务器数量进行横向扩展（绿色虚线），但两种方式都会让我们在一瞬间投入过多的硬件投资，周期也很长，同时在之后的一段时间内可能会造成大量资源的浪费。

但如果使用云计算的资源，我们可以通过自动化/自动弹性伸缩等特性，让系统提供的计算能力和实际需求的计算能力有非常完美的吻合（绿色实线）。这样子一来不会造成资源的浪费，而来也不会因为周期过长而流失客户。

组件解耦

我们可以将有强耦合关系的组件进行解耦，这样的话如何其中一个组件出现了故障或者性能问题，另一个相关联的组件也不会受到影响。

解耦的过程让你的应用程序的不同组件和层之间通过异步的方式进行通信，你的app服务器无法直接感知你的web服务器，你的app服务器也无法直接感知你的db服务器。

AWS 良好架构框架

https://s3.cn-north-1.amazonaws.com.cn/aws-china-website/whitepapaer/AWS%E8%89%AF%E5%A5%BD%E6%9E%B6%E6%9E%84%E6%A1%86%E6%9E%B6_+%E7%99%BD%E7%9A%AE%E4%B9%A6.pdf

根据多年来AWS的专家们积累的经验，创建了这一份AWS良好架构框架，其中包含了以下五大支柱：

• 安全性（Security）
• 可靠性（Reliability）
• 性能效率（Performance Efficiency）
• 成本优化（Cost Optimisation）
• 卓越操作（Operational Excellence）

一般性设计原则

良好架构框架定义了一系列一般性设计原则，包括了：

• 不需再猜测您的容量需求：在以往的基础架构部署中，我们往往面临着高成本闲置的资源或者资源容量紧张导致业绩受损的情况。利用云计算，这个问题可以得到解决。你可以先尽可能使用较少的容量，然后在后期根据需求进行随意伸缩。
• 以生产规模进行系统测试：我们可以在云环境中轻松搭建与生产环境1:1的测试环境，在做完一系列测试之后清空这些资源，同时只为使用的资源和时间而付费。这在传统基础架构环境中是无法轻松达到的。我们可以如之前实验所示，使用CloudFormation在半小时内搭建一套复杂的基础架构，并且在使用完毕后将其完全删除。
• 自动简化架构实验：在云计算环境中，自动化可以帮助我们降低成本以及手动操作带来的种种投入。我们可以使用CloudTrail追踪各种变更、审计相关的影响并且在必要时进行恢复。我们也可以使用例如Lambda函数来进行大量自动化的工作。
• 允许实现架构演进：在传统环境中，对应用程序架构的变更周期非常长。想象一下我们使用ITIL对系统生命周期进行管理，随着业务的发展，我们的架构可能无法适应不断变化的业务需求，但是更改系统的风险非常高。在云计算的环境中，我们可以巧妙利用自动化、DevOps、IaaC (Infrastrature as a Code)的特性来对架构进行更快速的迭代，实现敏捷开发（Agile）。
• 数据驱动型架构：在云环境中，你可以通过CloudWatch收集相关数据，来了解你的架构负载情况。你的云基础架构以代码的形式存在，因此可以利用这些数据来改善你的架构。
• 通过模拟促销日实现改进：通过模拟例如淘宝双11，京东618等促销日的大型流量，来改进架构中的不足之处，并且积累应对的经验和方案。

AWS白皮书 – 1. 安全性

AWS良好架构框架（AWS Well-Architected Framework）里其中五大支柱之一：安全性（Security）

设计原则

• 在所有层面考虑安全性：除了要在传统的防火墙上考虑安全性之外，我们还需要在每个、安全组、网络ACL，负载均衡器本身（开放什么端口）、EC2服务器本身（是否安装防病毒软件，更新补丁）都考虑到安全的机制。
• 事件可追溯性：对环境中的一切操作和变更进行记录和审计，如果遭受到黑客攻击，我们需要知道我们遭受了怎么样的攻击，什么时候遭受的攻击等等。
• 最低权限原则：永远只赋予所需要的最小权限，不赋予过多的不必要的权限
• 专注于保护你的系统：在AWS责任分担模型的帮助下，你能够专注于保护自己的应用程序、数据和操作系统；而AWS负责保护基础架构和服务。
• 自动化安全最佳实践：使用和创建安装有补丁和强化过的虚拟服务器镜像（AMI），而后利用这个镜像来做服务器的搭建。利用版本控制机制来对模板进行定义和管理。

AWS责任分担模型

AWS责任分担模型（AWS Shared Responsibility Model）表明了AWS和客户在运营和维护云环境的时候所承担的安全性和合规性责任。

基本上，AWS需要负责“云本身的安全”。

AWS需要负责保护运行所有AWS云服务的基础架构，包括基础架构内的所有硬件、软件、网络和设备。同时也包括了区域、可用区和边缘节点。

举个例子，AWS会负责云环境的机房是否装有CCTV、是否有物理访问安全的审计（据闻AWS的数据中心是禁止任何客户的其他公司参观的，只有自己的运维人员可以进入）、保证不同的可用区之间的网络互通和高可用、保证物理服务器的健康状态以及禁止非授权的人士进行物理访问、保证所有磁盘和设备都没有到达生命周期、保证数据库服务（比如RDS）的操作系统层面已经打上了补丁，不会被黑客侵入等等……

而客户需要负责“云内部的安全”。

客户的责任取决于使用了什么AWS服务，客户需要负责自己所使用的EC2实例在操作系统层面已经打好了补丁，配置好了相应的安全组和端口、VPC和S3都使用了ACL进行访问控制、IAM已经做好了MFA（Multi-Fator Authentication，多因素认证）并且对相关人员的权限控制已经做好了相应的规划、保证使用了数据加密、保证在OS上安装的应用程序没有漏洞已经是最安全的配置、保证RDS配置了相应的安全组和子网等等……

定义

定义的内容非常丰富，在这里只截取一部分比较重要的信息，更多信息可以查看文末的链接。

云环境下的安全性主要由以下五方面组成：

• 身份与访问管理（Identity and Access Mangement）
  • 使用IAM和MFA来使你的账号更加安全
  • 常见问题：
    • 如何保护你的AWS根账号的安全性？
    • 如何定义角色和责任来管理人员访问AWS资源（通过管理控制台以及通过API）
    • 如何限制你的程序访问AWS资源（应用程序、脚本、第三方工具或服务）
• 检测控制（Detective Controls）
  • 使用AWS CloudTrail, AWS Config, Amazon CloudWatch
  • 常见问题：
    • 如何捕捉和分析AWS的日志？
• 基础设施保护（Infrastructure Protection）
  • 使用VPC、安全组、NACL来保护你的基础设施安全
  • 常见问题：
    • 如何保护实例的安全，如何保护网络的安全？
    • 如何保护AWS服务的安全？
    • 如何保护操作系统和EC2实例的安全？（是否有补丁，杀毒软件等）
• 数据保护（Data Protection）
  • 你需要保护数据在传输过程中和存储过程中的安全性
  • 使用EBS, S3和RDS的加密功能
  • 常见问题：
    • 如何加密和保护你的数据存储
    • 如何加密和保护你的数据传输
• 事件响应（Incident Response）
  • 使用IAM, CloudFormation, API来做事件响应

更多资料请阅读安全性支柱 – AWS良好架构框架

AWS白皮书 – 2. 可靠性

AWS良好架构框架（AWS Well-Architected Framework）里其中五大支柱之一：可靠性（Reliability）。

可靠性支柱包含系统从基础设施或者服务中断的状态下进行恢复的能力、动态获取资源以满足需求的能力以及缓解错误配置或者瞬间网络问题等故障的能力。

设计原则

以下几个原则可以帮助你有效地提升可靠性水平：

• 测试恢复流程：在云环境中，我们可以通过自动化的手段模拟不同故障或者重现已经发生的故障，以此来验证我们的故障恢复流程。通过这样做，我们可以在实际故障发生之前纠正错误，同时我们可以避免一些还未发生的潜在危险。
  • NetFlix通过在公司生产环境中引入Chaos Monkey这个“捣乱鬼”，在每天的工作时间随机地对Netflix的AWS环境进行破坏，从而不断完善自己的云环境，保证系统越来越健壮，不再因为一部分应用失效而影响整个生产系统。
  • 除了Chaos Monkey，NetFlix还引入了其他的服务来检查错误的配置以及无效的服务，详情可以阅读Simian Army
• 自动实现故障恢复：通过监控系统内的各项性能指标，你可以在触及阈值的时候触发自动响应操作，自动恢复故障。
• 横向扩展以提升系统可用性：利用多种小型资源取代单一大型资源，来降低单点故障（Single Point of Failure）对整体系统的影响。使用横向扩展，即水平增加更多同样的资源（比如增加实例数量）；而不是纵向扩展，增加资源的容量（比如提升实例类型）。
• 不再猜测容量需求：在云环境中，我们不需要因为资源预测过少而担心影响系统的性能，或者资源预测过多造成资源的浪费。我们可以随时调整资源的大小，甚至可以通过自动化的方法来添加或删除资源，以维持资源的最优水平。
• 自动管理变更：基础设施内的变更应都以自动化的方式实现。

定义

定义的内容非常丰富，在这里只截取一部分比较重要的信息，更多信息可以查看文末的链接。

云环境下的可靠性主要由以下三方面组成：

• 基础（Foundations）
  • 在构建系统之前，我们需要确定一些基础性因素，包括服务限制和网络拓扑结构
    • AWS设置了多项服务设置，用来保护我们免收资源过度配置带来的影响。如果我们需要的资源超过了限制，我们可以寻找AWS支持中心提升我们的限制
    • 具体的AWS服务限制可以查看这里
    • 在设计之初我们需要考虑到未来可能的增长和整合需求，一次来规划网络架构
  • 常见问题：
    • 如何管理AWS账号内的服务限制
    • 如果管理和规划AWS内的网络拓扑
    • 如果找到AWS技术支持，是否有专门的TAM（Technical Account Manger）支持
• 变更管理（Change Management）
  • 在AWS中，我们可以通过API或者AutoScaling来对资源进行弹性地扩展，并且使用CloudWatch来监控一切参数，更快发现容量问题和不良的趋势。
  • 使用CloudTrail来追踪变更
  • 常见问题：
    • 如何让你的系统适应真实的需求？
    • 如何监控你的AWS资源？
    • 如何执行变更管理
• 故障管理（Failure Management）
  • 要对架构中出现故障有一定的预期，我们需要意识到这些故障，了解它们是如何发生的，如何去预防它们再发生。
  • 定义Recovery Point Objective (RPO)和Recovery Time Objective (RTO)
  • 常见问题：
    • 如何备份你的数据？
    • 系统内组件出现故障需要如何处理？
    • 你的故障恢复计划是什么？

更多关于可靠性的资料，请阅读可靠性支柱 – AWS良好架构框架。

AWS白皮书 – 3.性能效率

AWS良好架构框架（AWS Well-Architected Framework）里其中五大支柱之一：性能效率（Performance）。

性能效率支柱专注于高效利用计算资源来满足各类需求，同时随着需求变更和技术演进而不断保持这种效率水平。

设计原则

• 普及先进技术：在云环境中，我们可以直接使用很多先进的技术，比方说NoSQL数据库、媒体转码、机器学习、语音识别、大数据分析等等。这些服务会以PaaS的形式提供给你，你不需要具备每一个技术的专业技术能力，不需要一步一步去配置和管理新技术环境，只需要专注于使用这些现成服务进行产品开发。
• 数分钟内实现全球化：你需要在GUI环境轻松点击几下，就可以创建全球范围的低延迟、高性能的应用环境，并且保持最低的运营成本。
• 使用无服务架构：使用无服务架构（Serverless），我们可以不需要依赖于任何服务器资源（EC2、ECS或者Lighsail）。我们可以使用Lambda + API Gateway或者其他形式的无服务架构来帮助我们降低非常多的基础架构成本。
• 提升测试频率：利用虚拟化和自动化方法，我们可以利用不同实例、存储类型和配置来完成各种测试。
• 机器同理心：我们不需要对AWS服务的里里外外深入进行了解，但我们需要了解如何更好地使用各种服务。比如在设计数据库和存储方案时，我们需要考虑数据访问的规律和模式。

定义

我们应该着重考量以下四大主要资源类型（计算、存储、数据库和网络）。

• 计算（Comupte）
  • 在AWS中，我们可以以三种方式来提供计算服务，它们分别是实例、容器（微服务）和函数（无服务）
  • 我们在设计架构的过程中可能需要利用不同的计算解决方案来支持不同的组件，同时启用多种功能来实现性能提升
  • 关键服务：AutoScaling
  • 常见问题：
    • 如何选择适合你的系统的实例类型？
    • 如何确保你所使用的是最新/最适合的实例类型？
    • 如何监控实例来确保它们的性能达到了要求？
    • 如何确保实例的数量满足业务的需求？
• 存储（Storage）
  • 特定的系统最优存储方案取决于访问方式（块存储、文件存储还是对象存储）、访问模式（随机还是连续）、数据吞吐量要求、访问频率（在线、离线还是归档）、更新频率（WORM [一次写入，多次读取] 还是动态）以及可用性和持久性的限制。
  • 在AWS中，存储资源经过虚拟化并且可以通过不同方式交付
  • 在S3中我们有11个9的持久性
  • 在EBS中我们有不同类型的存储（SSD, Magenetic, PIOPS等）
  • 关键服务：EBS，S3，Glacier
  • 常见问题：
    • 如何选择适合你的系统的存储方案？
    • 如何确保你所使用的是最新/最适合的存储系统？
    • 如何监控你的存储系统来保证其性能？
    • 如何确保存储的容量满足你的业务需求？
• 数据库（Database）
  • 在选择数据库方案的时候，我们需要考虑到很多特性，比如数据库可用性、一致性、分区容错性、延迟、持久性、可扩展性和查询能力等。
  • 关键服务：RDS，DynamoDB，Redshift，ElastiCache
  • 常见问题：
    • 如何选择适合你系统的数据库方案？
    • 如何保证当新的数据库方案发布的时候你用哪一种数据库最合适？
    • 如何监控数据库保证其性能达到要求？
    • 如何保证数据库的容量和吞吐量可以满足业务需求？
• 网络（Network）
  • 设计系统最优的网络解决方案的时候，我们需要考虑到延迟、数据吞吐量等因素。
  • 我们可以使用S3传输加速、CloudFront内容分发服务、Route53基于延迟的路由、AWS DirectConnect等方案来解决延迟和卡顿的问题
  • 常见问题：
    • 如何选择合适的网络方案？
    • 如何保证新的网络技术出现的时候你使用哪一种网络方案最合适？
    • 如何监控你的网络保证其性能？
    • 如何确保网络性能满足业务需求？

更多关于性能效率的资料，请阅读性能效率支柱 – AWS良好架构框架。

AWS白皮书 – 4. 成本优化

AWS良好架构框架（AWS Well-Architected Framework）里其中五大支柱之一：成本优化（Cost Optimization）。

一套成本优化型系统应充分利用全部资源、以最低价格来实现业务成果，同时充分满足你的功能需求。本份白皮书将面向工作负载设计、服务选取、服务配置与运营以及应用和优化杠杆等层面为你提供深层指导。

设计原则

• Pay-as-you-go的消费模式：我们仅根据自己业务消费的要求来申请自愿，同时随时添加和减少资源的数量，最终只为实际的消费付费。比如，我们的开发和测试环境只有在每周工作日的工作时间运行，那么这类资源可以在非运行时间段关闭，以减少资源产生的费用。我们可以将原本每周需要运行168小时的资源减少到运行40小时，从而实现75%的成本节约。
• 规模经济效益：数十万家客户都使用AWS的云服务，因此我们可以获得更加优惠的服务单价。
• 不需要为数据中心运营支出：AWS会负责数据中心的搭建、服务器机架安装、部署和电力供应等问题。我们不需要花费大量人力物力到这些事情上面，我们只需要专注于我们的业务即可。
• 支出分析和原因分析：云环境中的所有花销都可以很清楚、很准确地被看到，我们可以更加透明地对IT成本进行归因，从而帮助我们量化投资回报率（ROI）和更好地为削减成本提供决策。
• 使用托管服务来降低拥有成本：使用AWS托管服务，我们可以不需要操心例如邮件发送或者数据库管理等工作带来的负担。而且托管服务以云规模的方式运行，我们可以享受到更低的每事务/每服务的单价成本。

定义

• 成本效率高的资源
  • 我们需要确保对配置的资源进行优化调整，控制其容量处于合理的水平。
  • 我们如果在一个t2-micro类型的实例需要运行10个小时才能处理完的一个任务，同时如果我们使用一个m4.2xlarge在几分钟就能完成相同的任务，我们显然选择后者会有更高的成本效率
  • 常见问题：
    • 如何选择合适的资源类型来满足支出需求？
    • 如何选择合适的收费模式来满足支出需求？（按需实例，预留实例和竞价实例）
    • 是否有其他服务来代替现有的服务可以增加你的投资回报率？（比如用S3静态网站代替EC2，Lambda代替EC2等）
• 供需匹配
  • 最优供需匹配应能够为特定系统提供最低的成本，同时还可以具备充足的资源来满足业务的需求，我们可以利用监控指标和自动化机制来保证我们的工作，以及确保不产生过高的成本。
  • 我们可以使用CloudWatch服务来监控我们的需求
  • AutoScaling可以帮助我们事先动态的弹性伸缩
  • Serverless无服务架构也可以帮助我们实现完美的供需匹配
  • 常见问题：
    • 如何确保你的容量满足你的需求又不会超出需求太多？
    • 如何优化对AWS服务的使用？
• 支出认知
  • 使用AWS服务，我们不需要再介入到冗长的采购流程中：向不同厂家询价、下PO/PR并且经过一系列冗长的财务部门，采购部门，管理层的审批、等待厂家送货，等待硬件安装和配置……
  • 我们可以点几下鼠标就创建了我们需要的服务和基础架构
  • 我们可以使用Tag标签来追踪我们不同类型的服务支出
  • 我们可以使用账单告警来防止我们误操作导致的高费用
  • 我们可以使用整合账单（Consolidated Billing）来对账单进行整合
  • 我们可以使用成本管理器来估算我们年度的AWS费用
  • 关键服务：CloudWatch，SNS
  • 常见问题：
    • 使用哪一些访问控制和流程来控制AWS的费用？
    • 如何监控我们的AWS用量和费用？
    • 如何将我们不使用的资源给关闭？
    • 如何在设计架构的时候考虑数据传输的费用？
• 不断优化
  • AWS的发展速度非常快，每一年会创新出成千的新服务（可以参照下图）。因此我们在为架构进行设计的时候，也可能需要不断地对架构进行优化。
  • 比如以前我们可以使用Mysql数据库，现在可以使用Amazon Aurara数据库来作为替代品
  • Lambda和Serverless也可能是替代一部分EC2的更新的方案
  • 我们可以使用Trusted Advisor服务来查看推荐的改进方案
  • 常见问题：
    • 我们如何管理和考虑使用更新的服务？

更多关于成本优化的资料，请阅读成本优化支柱 – AWS良好架构框架。

AWS白皮书 – 5. 卓越操作

AWS良好架构框架（AWS Well-Architected Framework）里其中五大支柱之一：卓越操作（Operational Excellence）。

卓越操作包含了管理生产负载的运营实践和流程，比如计划的变更如何去执行、如何应对预料之外的运营事故。

变更的执行和相应应当可以自动化进行，所有卓越操作的流程和程序都应该被记录、测试和定期的审查。

设计原则

• 利用代码执行操作：我们可以将所有云环境中的基础架构都定义为代码，并且通过代码管理和更新它们。我们可以将操作步骤做成脚本，通过事件响应来触发脚本的自动执行。这样子可以减少人工的错误，保证对事件响应的一致性。
• 进行频繁、小型、可逆的变更：对工作负载中的组件进行定期更新，并且保证这些更新是小型的、增量的、可逆的。而不是大型的、批量的更新。
• 遇见失败：通过“预演”来找出潜在的不足之处，并且从中找到并解决有可能的系统薄弱点。同时可以让操作人员熟悉这个响应过程和处理方法。比如NetFlix的Simian Army中的Chaos Monkey就是专门用来制造随机错误，帮助搭建更加健壮的系统的工具。
• 从失败中汲取经验：通过所有操作事件和失败中汲取经验来推动改进。将汲取的经验在团队内部或整个组织内进行分享。
• 注释文档：所有的文档可以在构建后自动注释，并且可以让注释文档作为你的操作代码输入。同时，需要保证文档的版本持续性地进行更新。
• 经常优化操作流程：寻找机会优化操作流程，组织定期的Game Day促销日来验证流程的有效性，并且让团队成员熟悉这么流程。

定义

云环境的卓越操作主要由以下三方面组成：

• 筹备（Preparation）
  • 团队应该对整个工作负载，他们在其中的角色，以及共享的业务目标有一个共同的理解，从而设置能够帮助业务成功的操作优先级。
  • 你需要通过日志记录以及富有洞察力的业务和技术指标进行观察。
  • 你应该有一致的流程来了解何时准备好启动工作负载。
  • 核心服务：Cloudformation, AutoScaling, AWS Config, Tagging
  • 常见问题：
    • 你使用的云操作流程有什么最佳实践？
    • 你如何进行配置管理？
• 操作（Operation）
  • 团队应该能够掌握工作负载的运行状况，你将系统通过基于运行结果的指标来获取有用的见解。你应该使用这些指标来实施具有业务和技术观点的仪表盘，来帮助团队成员做出明智的选择。
  • 你应该遇见操作事件，包括计划内的事件和计划外的事件，并且尽量自动化。
  • 可以创建CI/CD流程 （源代码仓库、系统搭建、测试/开发自动化等）。
  • 核心服务：AWS CodeCommit, AWS CodeDeploy, AWS CodePipeline, AWS CloudTrail
  • 常见问题：
    • 如何在最小变更影响的情况下对的你业务系统进行变革？
    • 如何监控你的系统来保证它可以按预期一样运行？
• 演进（Response）
  • 在出现故障时，保证你的团队能够从失败中汲取经验，并且制定改进计划。
  • 分享团队的学习收获，增加整个团队的收益。
  • 核心服务：CloudWatch
  • 常见问题：
    • 如何处理意料之外的运营事件？
    • 在处理意料之外的事件的时候有什么事件升级的流程？

更多关于卓越操作的资料，请阅读卓越操作支柱 – AWS良好架构框架。

AWS白皮书总结

AWS Well-Architected Framework白皮书包含了五个不同的支柱：

• 安全性（Security）
• 可靠性（Reliability）
• 性能效率（Performance Efficiency）
• 成本优化（Cost Optimisation）
• 卓越操作（Operational Excellence）

下面简单总结一下每一个支柱里面的内容。

安全性

• 身份与访问管理（Identity and Access Mangement）
  • 如何保护你的AWS根账号的安全性？
  • 如何定义角色和责任来管理人员访问AWS资源（通过管理控制台以及通过API）
  • 如何限制你的程序访问AWS资源（应用程序、脚本、第三方工具或服务）
  • 如何管理你的管理密钥和凭证？
• 检测控制（Detective Controls）
  • 如何捕捉和分析AWS的日志？
• 基础设施保护（Infrastructure Protection）
  • 如何保护实例的安全，如何保护网络的安全？
  • 如何保护AWS服务的安全？
  • 如何保护操作系统和EC2实例的安全？（是否有补丁，杀毒软件等）
• 数据保护（Data Protection）
  • 如何加密和保护你的数据存储
  • 如何加密和保护你的数据传输
• 事件响应（Incident Response）

可靠性

• 基础（Foundations）
  • 如何管理AWS账号内的服务限制
  • 如何管理和规划AWS内的网络拓扑
  • 如何找到AWS技术支持，是否有专门的TAM（Technical Account Manger）支持
• 变更管理（Change Management）
  • 如何让你的系统适应真实的需求？
  • 如何监控你的AWS资源？
  • 如何执行变更管理
• 故障管理（Failure Management）
  • 如何备份你的数据？
  • 系统内组件出现故障需要如何处理？
  • 你的故障恢复计划是什么？

性能效率

• 计算（Comupte）
  • 如何选择适合你的系统的实例类型？
  • 如何确保你所使用的是最新/最适合的实例类型？
  • 如何监控实例来确保它们的性能达到了要求？
  • 如何确保实例的数量满足业务的需求？
• 存储（Storage）
  • 如何选择适合你的系统的存储方案？
  • 如何确保你所使用的是最新/最适合的存储系统？
  • 如何监控你的存储系统来保证其性能？
  • 如何确保存储的容量满足你的业务需求？
• 数据库（Database）
  • 如何选择适合你系统的数据库方案？
  • 如何保证当新的数据库方案发布的时候你用哪一种数据库最合适？
  • 如何监控数据库保证其性能达到要求？
  • 如何保证数据库的容量和吞吐量可以满足业务需求？
• 网络（Network）
  • 如何选择合适的网络方案？
  • 如何保证新的网络技术出现的时候你使用哪一种网络方案最合适？
  • 如何监控你的网络保证其性能？
  • 如何确保网络性能满足业务需求？

成本优化

• 成本效率高的资源
  • 如何选择合适的资源类型来满足支出需求？
  • 如何选择合适的收费模式来满足支出需求？（按需实例，预留实例和竞价实例）
  • 是否有其他服务来代替现有的服务可以增加你的投资回报率？（比如用S3静态网站代替EC2，Lambda代替EC2等）
• 供需匹配
  • 如何确保你的容量满足你的需求又不会超出需求太多？
  • 如何优化对AWS服务的使用？
• 支出认知
  • 使用哪一些访问控制和流程来控制AWS的费用？
  • 如何监控我们的AWS用量和费用？
  • 如何将我们不使用的资源给关闭？
  • 如何在设计架构的时候考虑数据传输的费用？
• 不断优化
  • 我们如何管理和考虑使用更新的服务？

卓越操作

• 筹备（Preparation）
  • 你使用的云操作流程有什么最佳实践？
  • 你如何进行配置管理？
• 操作（Operation）
  • 如何在最小变更影响的情况下对的你业务系统进行变革？
  • 如何监控你的系统来保证它可以按预期一样运行？
• 演进（Response）
  • 如何处理意料之外的运营事件？
  • 在处理意料之外的事件的时候有什么事件升级的流程？

如果需要查看官方关于Well Architected的白皮书，可以详细阅读页面AWS Well-Architected。

良好架构相关问题、答案与最佳实践

问题1：什么因素推动您的业务重点？企业的存在是为了满足客户的需求。运营要满足业务需求。业务优先级由业务和客户需求决定。诸如法规遵从要求或行业最佳实践等外部因素也可能影响运营优先级。在制定运营优先级时，基于利益和风险，作出决策。

• 业务需求：让业务和开发团队参与确定运营优先级。
• 合规要求：监管或行业标准等外部因素可能会使您的业务承担特定要求，例如SOX法规遵从要求与PCI行业最佳实践。
• 风险管理：平衡决策与潜在利益的风险。

问题2：您如何设计工作负载以实现可操作性？考虑运营需求是系统设计的一部分。设计工作负载，提供对其运行状态、客户行为和客户体验的洞察力，从而对问题作出响应以及确定需要改进的领域。实施低风险、零停机时间的部署方法，以便轻松识别故障和快速恢复。

• 共享设计标准：在团队之间分享现有最佳实践、指导和管理要求，并纳入系统设计。流程可以对设计标准进行更改、添加和异常处理。
• 针对云操作的设计：包含云启用的功能，可在系统设计中提供优于物理资源的优势。
• 提供有关工作负载行为的深入见解：在您的系统设计中设计组件，以便了解系统内正在发生的事情，并衡量各个组件的性能
• 深入了解客户行为：在您的系统设计中设计组件，以便了解客户如何使用系统以及他们的体验质量。
• 减少缺陷，简化补救措施并改善流程：采用包括快速反馈质量的方法，实现重构和缺陷修复。
• 降低部署风险：使用频繁、小型、可回溯、自动部署、测试、灰度部署、蓝绿部署等方法。

问题3：如何确定准备好支持工作负载？采用流程来验证运营就绪情况以支持工作量。足够和适当的技能人员已经到位，并且准备好支持工作负载。公开运营流程，经常审查，并根据情况进行更新。运营流程以代码形式出现，并在适当的地方自动执行程序。

• 持续改进文化：控制您的运营方式，并认识到变化是一直存在的。您需要继续尝试和发展，寻找机会并采取行动。
• 对企业价值的共识：让团队了解企业工作负载的价值，并制定流程吸引更多团队寻求支持。
• 人员能力：确保您拥有适当数量的经过培训的人员来支持您的工作负载需求。定期检查工作量需求，并根据需要培训或调整人员能力。
• 把指导和操作文档公开：确保标准易于获取，易于理解，并且可以衡量合规性。建立标准流程，以及特殊流程。
• 使用清单：使用清单来评估是否准备好运行工作负载。这些包括操作准备和安全检查表。
• 运营手册：具有充分理解的事件和程序的运行手册。剧本：为故障场景制作剧本。
• 恢复演习：识别潜在的故障情况并测试您的响应（例如，竞赛日，模拟失败）。

问题4：什么因素加深您对健康运营的理解？ 以业务成就定义成功，确定成功标准，确定工作负载和运营指标，以满足这些衡量标准，并创建成功运营的业务级视图。建立基准并进行主动评估以确定趋势并回应。使用跨职能团队验证工作负载和运营状况，并酌情调整回应。

• 定义预期的业务和客户结果：从业务和客户的角度对成功的工作负载进行定义。
• 确定成功指标：定义根据业务和客户期望来衡量工作负载行为的指标。
• 识别工作负载指标：定义根据成功标准来衡量工作负载及其组件状态的指标。
• 识别操作指标：定义衡量运营活动（操作手册和剧本）执行情况的指标。
• 建立基线：建立基准作为衡量标准，提供预期值作为比较的基础。
• 收集并分析您的指标：定期进行主动评估，以确定趋势并确定回应。
• 验证洞察力：与跨职能团队和企业所有者一起检查分析结果和回应。酌情调整回复。
• 业务级运营视图：确定您是否满足客户需求，并可确定需要改进的地方以实现业务目标。

问题5：你如何管理运营事件？通过业务影响来指定运营优先级。为任何警报的事件定义流程，并进行响应。在适当的地方自动执行这些动作。对于运营状态的变化进行沟通，以便受影响的各方可以根据需要做出响应。找出计划外事件的根本原因，以及计划事件的意外影响，以便可以使用这些信息来减轻未来事件的发生可能。方便时与受影响方共享此信息。

• 根据业务影响确定运营事件的优先级：当多个事件需要干预时，基于业务影响制定优先级。
• 事件、意外和问题管理流程：流程适用于处理观察到的事件，需要干预的事件（意外），以及需要干预并重现和/或目前无法解决的事件（问题）。基于警报的通知机制：在特定指标超出安全范围时接收来自监控系统的自动警报
• 以警报进行处理：对于任何警报事件，应该明确定义责任人（例如个人，团队或角色）的明确响应（操作手册或剧本）。
• 定义升级路径：操作手册和剧本应该定义，事件升级，升级过程以及具体确定每个步骤的责任人。升级可能会包括第三方（例如供应商，AWS支持）。
• 确定决策者：当行为可能对业务有潜在影响时，确定决策者有权以组织的名义作出决策。
• 通过仪表板发布状态：仪表板存在业务当前运行状态的信息，针对目标受众（例如，内部技术团队，领导力和客户）量身定制。示例包括CloudWatch仪表板，个人健康仪表板（PHD）和服务健康仪表板（SHD）。
• 推送通知：当用户所使用的服务受到影响，并恢复时与用户及时沟通（例如，通过电子邮件或短信）。
  根本原因分析流程：确定并记录事件根本原因的流程。
  对于问题原因进行沟通：适当时，对于问题原因和影响，与特定客户进行沟通。

问题6：如何对管理进行演变？专注于工作周期以实现持续的渐进式改进。评估从反馈、经验教训、分析和跨团队评论中获得的改进机会。验证机会并确定优先顺序。在团队中分享经验和益处。

• 持续改进流程：运营流程包括特定的工作周期，以实现持续的变化改进。对机会进行评估并优先采取行动。
• 改进动力：考虑所需的特性、功能和改进、不可接受的问题、错误和漏洞；以及在评估改进机会时所需的更新，以保持遵守供应商提供的政策或支持。
• 反馈：流程包括反馈以确定需要改进的地方。
• 经验教训：有流程来获取并记录运营中经验教训，以便其他团队可以利用这些经验教训。
• 分享学习：有适当的流程来分享团队中学到的经验教训。 分析经验教训：有适当的流程来学习趋势，并找出需要调查以寻求改进机会的领域。
• 运营指标评估：对跨业务参与者的运营指标进行回顾性分析，以确定改进的机会和方法。
• 进行更改：实施修改以改进并评估结果，确保成功。

问题7：您如何保护与AWS root帐户凭证相关的访问与使用活动？AWS root帐户凭证类似于其它操作系统当中的root或者本地管理员机制，因此应尽量少使用。目前的最佳实践在于创建AWS身份与访问管理（简称IAM）用户，将其关联至管理员组，并利用IAM用户管理该帐户。该AWS root帐户不应具有API密钥，应拥有一条高强度密码且应关联硬件多因素验证（简称MFA）设备。这意味着使用者必须利用惟一root身份通过AWS管理控制台进行访问，且该root帐户无法通过应用程序编程接口（简称API）进行调用。需要注意的是，部分经销商或者区域并未发布或者支持AWS root帐户凭证

• MFA与最低Root使用原则：AWS root帐户凭证应仅用于最低必要活动。
• 不使用Root

问题8：您如何为系统用户定义角色与责任，并借此控制AWS管理控制台与API的人为访问？目前的最佳实践在于创建用户组，从而面向客户对各系统用户的角色与责任进行拆分及定义。用户组可通过多种不同技术方案进行定义，具体包括身份与访问管理（简称IAM）组、跨帐户访问IAM角色、网络身份、通过安全断言标记语言（简称SAML）集成（例如在Active Directory当中进行定义）或者采用通常经由SAML或者AWS安全令牌服务（AWS Security Token Service ，简称STS）实现的第三方解决方案（例如Okta、Ping Identity或者其它定制化技术方案）。我们明确反对直接使用共享帐户。

• 受控员工生命周期：经过严格定义与执行的员工生命周期政策。
• 最低权限原则：用户、组以及角色经过明确定义且仅被分配完成业务要求所必需的最低权限。

问题9：您如何限制指向AWS资源的自动访问？（例如应用程序、脚本以及/或者第三方工具或服务）应当以类似的方式定义系统访问行为，因为用户组手工创建。对于Amazon EC2实例，此类组被称为IAM EC2角色，且目前的最佳实践在于使用EC2专用IAM角色以及AWS SDK或CLI，内置支持对EC2对应IAM角色凭证进行检索。立足于传统作法，用户凭证往往会被注入至EC2实例当中; 但我们强烈建议您不要将凭证以硬编码方式注入脚本及源代码当中。

• 用于自动化访问的静态凭证：以安全方式加以存储。
• 用于自动化访问的动态凭证：利用实例配置文件或者Amazon STS加以管理。

问题10：您如何对日志进行获取与分析？获取日志记录对于从性能到安全事件在内的各类调查工作而言至关重要。目前的日志记录最佳实践在于定期将相关信息由来源直接移动至日志处理系统当中（例如CloudWatch Logs、Splunk以及Papertrail等等）或者将其存储于Amazon S3存储桶内以待后续根据需求加以处理。常见的日志来源包括AWS API以及用户相关日志（例如AWS CloudTrail）、AWS特定服务日志（例如Amazon S3及Amazon CloudFront等）、操作系统生成日志以及第三方特定应用日志。您可以利用Amazon CloudWatch Logs对来自Amazon EC2实例、AWS CloudTrail或者其它来源的日志文件进行监控、存储与访问。

• 适合的主动监控：Amazon CloudWatch日志事件、VPC流日志、ELB日志以及S3存储桶日志等等。
• 启用AWS Cloud Trail。
• 监控操作系统或者应用程序日志。

问题11：您如何确保对网络及主机级边界进行保护？在本地数据中心当中，DMZ方案能够利用防火墙将系统拆分为多个受信与非受信区。在AWS当中，客户可使用有状态与无状态两类防火墙。有状态防火墙被称为安全组，而无状态防火墙则被称为网络访问控制列表（简称ACL），负责保护Amazon虚拟私有云（简称VPC）之内的各子网。目前的最佳实践在于立足VPC内运行一套系统，并在安全组内定义基于角色的安全机制（例如网络层、应用层等），而后在网络ACL之内定义基于位置的安全机制（例如在每个可用区内的一套子网中定义弹性负载均衡层、并在各可用区内的另一子网中定义网络层等）。

• VPC中的受控网络流量：例如使用防火墙、安全组、NACLS以及堡垒主机等。
• 边界位置上的受控网络流量：例如使用AWS WAF、基于主机的防火墙、安全组以及NACLS等等

问题12：您如何运用AWS服务级安全功能？AWS 服务提供多种额外安全功能（例如Amazon S3存储桶政策、Amazon SQS、Amazon DynamoDB以及KMS密钥政策等等）。

• 采用适合的其它各项功能。

问题13：您如何立足Amazon EC2实例保护操作系统完整性？另一项传统控制要求在于保护操作系统完整性。您能够利用基于主机的传统技术方案（例如OSSEC、Tripwire以及Trend Micro Deep Security等等）在Amazon EC2实例当中轻松实现这一点。

• 文件完整性：在EC2实例当中使用文件完整性控制机制。
• EC2 入侵检测：在EC2实例当中使用基于主机的入侵检测控制机制
• AWS Marketplace或合作伙伴解决方案：采用来自AWS Marketplace或者APN合作伙伴的解决方案。
• 配置管理工具：采用定制化Amazon Machine Image（简称AMI）或者默认受到安全保护的配置管理工具（例如Puppet或Chef）。

问题14：您如何对数据进行分级？数据分级机制能够根据敏感程度对数据进行分类组织，其中包括可用数据类型、数据所在位置、访问级别以及数据保护机制（例如通过加密或者访问控制实现）

• 采用数据分级模式。
• 全部数据皆被视为敏感类型。

问题15：您如何对处于静态的数据进行加密与保护？传统的安全控制机制强调对静态数据进行加密。AWS利用客户端（例如SDK支持的、受支持操作系统、Windows Bitlocker、dm-crypt以及Trend Micro SafeNet等）与服务器端（例如Amazon S3）双管齐下的方式支持这种控制能力。您亦可以采用服务器端加密（简称SSE）与Amaozn弹性块存储服务中的加密卷。

• 不要求：不要求对静态数据进行加密。
• 对静态数据进行加密。

问题16：您如何管理密钥？密钥属于应得到严格保护的机密信息，同时亦应配合适当的轮换政策以实现定义与使用。最佳实践在于绝对不可以硬编码方式将这些机密信息添加至管理脚本及应用程序当中——但此类作法确实时有发生

• AWS CloudHSM：采用AWS CloudHSM。
• 采用AWS服务控制：静态数据可利用AWS特定服务控制（例如Amazon S3 SSE、Amazon EBS加密分卷、Amazon关系数据库服务（简称RDS）以及传输数据加密（简称TDE）等）实现加密。
• 采用客户端加密：静态数据可利用客户端技术方案进行加密。
• AWS Marketplace或合作伙伴解决方案：使用来自AWS Marketplace或者APN合作伙伴的解决方案。（例如Trend Micro SafeNet等）。

问题17：您如何对传输的数据进行加密与保护？最佳实践在于利用加密机制对传输的数据进行保护。AWS支持面向各服务API的加密端点方案。另外，客户亦可在其Amazon EC2实例之内使用多种技术方案

• 不要求：不要求对传输的数据进行加密。
• 加密通信：利用TLS或者其它同类方案对通信内容加以恰当保护

问题18：您如何确保采用适当的事件响应方案？在安全事件发生之前，确保将相关工具部署到位，而后定期进行事件响应演练以确保架构始终保持更新并有能力及时实现调查与恢复

• 预配置访问：信息安全人员应有权或者有能力快速实现访问。这种能力应以预配置方式实现，从而保证可在发生事件时作出适当响应。
• 预部署工具：信息安全人员应在AWS内预部署正确工具，用以确保在事件发生时可进行适当响应。
• 非生产竞赛日活动：应定期在非生产环境开展事件响应模拟活动，同时将由此获取的经验与教训纳入架构及操作体系当中。
• 生产竞赛日活动：应定期在生产环境开展事件响应模拟活动，同时将由此获取的经验与教训纳入架构及操作体系当中。

问题19：您如何为自己的帐户管理AWS服务限制？AWS 帐户默认配置有服务上限，旨在防止新用户遭遇意料之外的资源配置超量。AWS客户应评估自身对于AWS服务的实际需求，并提交申请以适当变更各区域内的可用资源上限。

• 限制监控与管理：评估您对于AWS资源的潜在使用量，合理上调所在区域资源上限，同时允许根据实际使用情况进行计划内增长。
• 设置自动化监控机制：利用SDK等工具在触及指标阈值时发出警报。
• 了解固定服务限制：了解不可变更的服务限制，并在架构设计中考虑到相关因素。
• 确保您的服务限制与最大资源使用量之间始终存在充足空间，借以适应故障转移需求。
• 应跨越全部相关帐户与区域考量服务限制因素

问题20：您如何在AWS上规划自己的网络拓扑结构？应用程序可存在于一套或者多套环境当中：EC2Classic、VPC或者默认VPC等等。网络考量则包括系统连接性、弹性IP/公共IP地址管理、VPC/私有地址管理以及作为云环境下资源利用根本性前提的名称解析等。经过良好规划及记录的部署方案能够切实降低重叠和争用等风险。

• 不需要返回数据中心的连接。
• AWS与本地环境间的高可用性连接（如果必要）：可根据需求使用多DX线缆、多VPN隧道以及AWS Marketplace方案。
• 面向工作负载用户的高可用性网络连接：高可用性负载均衡与/或代理、基于DNS的解决方案、AWS Marketplace方案等。
• 非重叠私有IP地址范围：虚拟私有云内IP地址范围与子网的使用不应存在彼此重叠、与其它云环境重叠或者与本地环境相重叠。
• IP 子网分配：各Amazon VPC IP地址范围应足以适应应用程序的实际需要，包括未来的扩展规模以及跨可用区间各子网的IP地址分配需求

问题21：您的系统如何适应需求变化？一套可扩展系统能够提供必要弹性以自动添加及移除各类资源，从而确切满足任意给定时间点之内的当前需求

• 自动化规模伸缩：使用各类自动化规模伸缩服务，例如Amazon S3、Amazon CloudFront、Auto Scaling、Amazon DynamoDB以及AWS Elastic Beanstalk等等。
• 负载测试：利用负载测试方法衡量规模伸缩活动是否满足应用程序的实际需要。

问题22：您如何监控各类AWS资源？日志与指标是了解您应用程序运行状态的强大工具。您可以通过系统配置监控日志与指标，并在触及阈值或者发生重大事件时发出通知。在理想条件下，一旦低性能阈值被触及或者发生故障，系统应拥有必要架构设计以自动实现自我修复或规模伸缩响应。

• 监控：利用Amazon CloudWatch或者其它第三方工具对您的应用程序进行监控。
• 通知：在计划中考虑到发生重大事件时接收通知的需求。
• 自动响应：利用自动化方案在检测到故障时执行对应操作，例如替换故障组件

问题23：您如何执行变更？您环境当中的非受控变更将使变更影响变得难以预测。要确保各应用程序与操作环境始终运行已知软件并以可预测方式安装补丁或进行组件替换，我们必须保证利用受控变更进行AWS资源与应用程序配置。

• 自动化：以自动化方式执行部署与补丁安装。

问题24：您如何对数据进行备份？对您的数据、应用程序以及操作环境（所谓操作环境，是指纳入应用程序且经过配置的操作系统）进行备份，从而满足平均恢复时间（简称MTTR）与恢复点目标（简称RPO）的要求

• 自动备份：使用AWS功能、AWS Marketplace解决方案或者其它第三方软件以实现自动化备份。
• 定期恢复测试：通过恢复测试验证备份流程是否符合RTO与RPO要求

问题25：您的系统如何承受组件故障？您的应用程序是否存在（隐性或明确的）可用性及平均恢复时间（简称MTTR）要求？如果是，您应建立起应用弹性机制并通过资源分配确保其能够承受中断问题。为了进一步提升可用性水平，资源分配机制应跨越多个不同物理位置。在架构当中纳入多个独立层（例如Web服务器、数据库等）以实现弹性，其中包含监控、自我修复、重大事件通知以及故障应对等因素。

• 多可用区/区域：跨越多个可用区/区域分发应用程序负载（例如DNS、ELB、应用程序负载均衡器以及API网关等）。
• 松耦合的依赖关系：例如使用队列系统、流式系统、工作流以及负载均衡器等。
• 优雅降级机制：当组件间的依赖关系存在问题，并不代表组件本身的运行状态不佳。应确保组件能够在降级模式下继续响应请求。
• 自动修复：利用自动化方式检测故障并执行修复操作。持续监控系统的运行状态并计划接收一切关于重大事件的通知信息

问题26：您如何对弹性进行测试？ 当您对弹性进行测试时，可能会发现某些潜在bug只存在于生产环境中。通过竞赛日活动定期进行模拟，从而帮助企业顺利贯彻并执行既定规程。

• 响应剧本：面向故障场景建立响应剧本。
• 故障注入：定期进行故障测试（例如使用Chaos Monkey）以确保覆盖故障情况。
• 规划竞赛日活动。
• 根本原因分析(简称RCA)：根据重大事件执行系统故障审查并进行架构评估。

问题27：您如何规划灾难恢复机制？灾难恢复（简称DR）机制在立足备份方案实现数据恢复这类任务当中发挥着重要作用。您应当对执行工作的目标、资源、位置以及功能进行定义与执行，且确保相关举措同数据的RTO及RPO目标相吻合

• 定义目标：定义RTO与RPO。
• 灾难恢复：建立一套灾难恢复策略。
• 配置草案：确保灾难恢复站点/区域内的Amazon Machine Image（简称AMI）与系统配置状态处于最新。
• 灾难恢复测试与验证：定期测试灾难恢复策略的故障转移能力，确保其能够满足RTO与RPO目标。
• 实施自动化恢复：利用AWS与/或第三方工具以实现自动系统恢

问题28：您如何选择最佳性能架构？ 特定系统的最佳解决方案根据工作负载的具体类型而有所区别，且通常需要将多种方案加以结合。良好架构系统采用多种解决方案并通过不同功能共同提升性能水平。

• 基准测试：立足AWS对已知工作负载进行测试，并借此确定最佳选项。
• 负载测试：利用多种不同资源类型与规模在AWS之上部署您系统的最新版本，同时利用监控机制收集性能指标，而后根据性价比计算结果得出最终选择

问题29：您如何选择计算解决方案？特定系统的最优计算解决方案取决于应用程序设计、使用量模式以及配置设置等多种因素。各类架构方案可能采用多种不同计算解决方案以满足各组件的实际要求，同时启用各项功能以提升性能水平。在架构当中选用错误的计算解决方案可能导致性能效率低下。

• 选项考量：考虑各实例、容器以及函数所使用的具体选项以实现最佳性能表现。
• 实例配置选项：如果您使用实例，请考虑家族、实例大小以及特性（GPU、I/O、可突发）等配置选项。
• 容器配置选项：如果您使用容器，请考虑内存、CPU以及租户配置等容器配置选项。
• 函数配置选项：如果您使用函数，则应考虑内存、运行时及状态等配置选项。
• 弹性：利用弹性（例如Auto Scaling、Amazon EC2容器服务（简称ECS）以及AWS Lambda等）功能以满足变更需求

问题30：您如何选择自己的存储解决方案？特定系统的最优存储解决方案取决于访问方法（块、文件或者对象）、访问模式（随机或者连续）、数据吞吐量要求、访问频率（在线、离线及归档）、更新频率（WORM与动态）以及可用性与持久性限制等因素。良好架构系统利用多种存储解决方案并启用不同功能以提升性能表现

• 特性考量：考虑您所需要的不同特性（例如共享性、文件大小、缓存大小、访问模式、延迟、数据吞吐量、数据持久性等）以选择您需要使用的具体服务（包括Amazon S3、Amazon EBS、Amazon弹性文件系统（简称EFS）以及EC2实例存储等）。
• 考虑配置选项：考虑PIOPS、SSD、磁盘以及Amazon S3传输加速等配置选项。
• 考虑访问模式：根据访问模式优化您的存储系统使用方式（例如条带化、密钥分发与分区等）

问题31：您如何选择自己的数据库解决方案？面向特定系统的最优数据库解决方案取决于可用性、一致性、分区容限、延迟、持久性、可扩展性以及查询容量等因素。多数系统采用不同的数据库解决方案以适合各子系统的需求，同时启用多种功能以提升性能水平。为系统选择错误的数据库解决方案与功能可能导致性能效率低下

• 考虑特性：考虑各项不同特性（例如可用性、一致性、分区容限、延迟、持久性、可扩展性以及查询容量等）以选择最符合实际需求的数据库方案（关系、NoSQL、仓库、内存内）。
• 考虑配置选项：考虑各类配置选项，包括存储优化、数据库级设置、内存以及缓存等。
• 考虑访问模式：根据实际访问模式优化您的数据库系统使用方式（例如索引、密钥分发、分区以及横向扩展等）。
• 考虑其它方案：考虑利用搜索索引、数据仓库以及大数据等其它方案实现数据可查询性。

问题32：您如何配置自己的网络解决方案？面向特定系统的最优网络解决方案取决于延迟、数据吞吐量要求等因素。用户或者本地资源等物理限制将决定位置的选择，且可利用边缘技术或资源安置等方式解决。

• 位置考量：为降低网络延迟考虑位置选项（例如区域、可用区、安置组、边缘位置）。
• 考虑产品功能：考虑利用各产品功能（例如EC2实例网络容量、多种网络实例类型、Amazon EBS优化实例、AmazonS3传输加速、动态Amazon CloudFront等）优化您的网络流量。
• 考虑网络功能：考虑利用各项网络功能（例如Amazon Route 53基于延迟路由、Amazon VPC端点、AWS Direct Connect）减少网络距离或者卡顿现象。
• 适当的NACLS：使用NACLS最小设置以维持良好的网络数据吞吐能力。
• 考虑加密卸载：考虑利用负载均衡机制卸载加密终端（TLS）。
• 考虑协议：考虑优化网络性能您需要哪些协议

问题33：面对持续推出的资源类型与功能，您如何确保能够始终采用与自身需求最为匹配的资源类型？ 在设计架构解决方案时，您面对着相对有限的实际方案选项。然而随着时间推移，将出现更多能够提升您架构性能的新型技术与方法。

• 审查：制定流程以审查新的资源类型与规模。反复运行性能测试以评估性能效率层面的一切改进机会。

问题34：您如何在布发后监控各项资源以确保其表现符合预期？系统性能可能随着时间推移受到内部及/或外部因素的影响而有所降低。监控系统性能将帮助您发现这类降低问题并修复相关的内部或外部因素（例如操作系统或应用程序负载）。

• 监控：利用Amazon CloudWatch、第三方或者定制化监控工具监控性能表现。
• 基于警报的通知机制：如果指标超出安全范围，则从您的监控系统处接收到自动警报。
• 基于触发条件的操作：设置由警报触发的自动操作，用以恢复或者升级问题

问题35：您如何利用权衡机制提升性能表现？在设计架构解决方案时，主动考虑权衡机制将帮助您找到最优方案。您通常可以在一致性、持久性以及空间/时间与延迟之间进行权衡，从而实现更佳性能表现

• 服务考量：使用能够提升性能的服务，例如Amazon ElastiCache、Amazon CloudFront以及AWS Snowball等。
• 模式考量：使用能够提供性能表现的各类模式，例如缓存、只读副本、分片、压缩以及缓冲等。

问题36：您在为解决方案选择AWS服务时，是否考虑到了成本因素？Amazon EC2、Amazon EBS以及Amazon S3等属于“基础构建块”型AWS服务。Amazon RDS与Amazon DyanmoDB等托管服务则属于“高级”AWS服务。通过选择基础构建块与托管服务，您可以对自己的架构进行成本优化。举例来说，利用托管服务，您可以降低或者彻底摆脱管理及操作类日常开销，从而将精力投入在应用程序及业务相关工作上

• 选择服务以降低成本：分析服务以了解您能够通过哪些服务实现成本节约。
• 许可成本优化
• 利用无服务器与基于容器类方案实现成本优化：利用AWS Lambda、Amazon S3网站、Amazon DynamoDB以及Amazon ECS等服务降低成本。
• 利用适当存储解决方案实现成本优化：根据使用模式使用最具成本效益的存储解决方案（例如Amazon EBS冷存储、Amazon S3标准-低频访问、Amazon Glacier等等）。
• 利用适当数据库实现成本优化：根据需求使用Amazon关系数据库服务（简称RDS）（Postgres、MySQL、SQL Server以及Oracle Server）或者Amazon DynamoDB（或者其它键-值存储、NoSQL替代方案）。
• 利用其它应用程序级服务实现成本优化：根据实际需求使用Amazon简单队列服务（简称SQS）、Amazon简单通知服务（简称SNS）以及Amazon简单邮件服务（简称SES）

问题37：您是否对资源进行规模调整以契合成本目标？确保您为当前任务选择适当的AWS资源规模。AWS鼓励您使用基准评估机制以确保您选择的资源类型符合工作负载的最优需求。

• 指标驱动型资源规模：利用性能指标选择正确的资源规模/类型以实现成本优化。合理配置数据吞吐量、规模以及具体存储服务，例如Amazon EC2、Amazon DynamoDB、Amazon EBS（预配置IOPS）、Amazon RDS、Amazon EMR以及网络等。

问题38：您是否选择了适当的计费模式以契合成本目标？使用最适合您工作负载的计费模式以降低使用成本。最优部署方案可能为全按需实例、按需与预留实例相结合，或者在适用时选择竞价实例。

• 预留容量与提交申请：定期分析使用情况并据此购买预留实例（例如Amazon EC2、Amazon DynamoDB、Amazon S3以及Amazon ClouFront等等）。
• 竞价实例：为选定工作负载（例如批处理、EMR等）使用竞价实例（例如竞价时段、竞价队列）。
• 区域成本考量：在区域选择中纳入成本考量。

问题39：您如何确保自己的容量匹配但又不会过度超出需求？在对架构进行支出与性能平衡的过程中，确保您付费的一切资源皆得到使用，从而避免实例未得到充分利用的问题。任何不够准确的利用率量化指标都会对您的业务运营成本产生影响（过度使用造成性能下降）或浪费AWS支出（供过于求）。

• 基于需求的方案：使用Auto Scaling以响应需求变化。
• 基于缓冲区的方案：利用缓冲区（例如使用Amazon Kinesis或者Amazon简单队列服务（简称SQS））推迟工作，直到您腾出充足的处理容量。
• 基于时间的方案：基于时间类方案包括工作时间外任务分配、在周末期间关闭开发与测试实例以及遵循季度或者年度规划（例如黑色星期五）等

问题40：您是否在架构设计当中考虑到数据传输成本？确保对数据传输成本进行监控，以便在架构决策时尽可能降低其中部分成本。举例来说，如果您身为内容供应商，以往直接Amazon S3存储桶向最终用户交付内容，您可以将您的内容推送至Amazon CloudFront的内容交付网络（简称CDN），从而显著降低使用成本。请记住，一项小型但有效的架构变更能够显著降低运营支出

• 优化：在架构当中对数据传输进行优化（应用程序设计、WAN加速、多可用区以及区域选择等）。
• CDN：在适当情况下使用CDN。
• AWS Direct Connect：分析实际情况并在适当时使用AWS Direct Connect。

问题41：您如何监控使用情况与支出？建立监控与控制政策与规程，同时合理分配成本预算。利用AWS提供的可视化工具了解谁在使用哪些资源以及与之对应的成本水平。这将帮助您更为深入地理解您的业务需求以及团队运营情况。

• 标记一切资源：标记一切可标记的资源，借以将其同您帐单中的变更进行关联，并最终反映基础设施与资源使用量中的变化。
• 利用计费与成本管理工具：建立一套标准化流程以加载并解释详尽的结算报告或成本管理器。利用Amazon CloudWatch或者第三方工具（例如Cloudability、CloudCheckr以及CloudHealth等）定期监控资源使用量与支出情况。
• 通知：让团队当中的关键成员了解您的支出是否已经超出了明确定义的范畴。
• 财务驱动型退费/显示退费方法：借此向成本中心分配实例与资源（例如使用标记机制）。

问题42：您是否会清理不再需要的资源，或者中止暂时不需要的资源？从项目启动到生命周期结束，始终坚持采用变更控制与资源管理方案，从而确保您有能力发现必要的流程变更或者功能增强空间。您亦可通过AWS技术支持服务获取针对工作负载实现项目优化的详尽建议，例如何时使用Auto Scaling、AWS OpsWorks、AWS Data Pipeline或其它不同Amazon EC2配置方案，或者参阅Trusted Advisor给出的成本优化建议。

• 自动化：精心设计您的系统，确保其能够在您发现并停用非关键性或者不再需要的低利用率资源时实现符合预期的处理效果。
• 定义流程：制定一套流程以发现并停用不再需要的资源

问题43：您采用哪些访问控制与规程以治理AWS资源使用？制定相关政策与机制，确保您能够在达成目标的同时拥有合理的成本水平。通过将检查与平衡方案贯彻至标记与IAM控制体系，您能够在不受过度支出影响的前提下顺利实现创新

• 建立组与角色：（例如：开发/测试/生产）利用治理机制控制各分组内谁能够启动实例及资源。（可利用AWS服务或者第三方解决方案实现。）
• 追踪项目生命周期：追踪、衡量并审计项目、团队及环境的生命周期，借以避免使用并支付不必要的资源

问题44：您如何管理及/或考量对新服务的采用？随着AWS不断发布各类新型服务与功能，最佳实践要求您对现有架构决策进行审查以确保其仍然拥有最佳成本效益

• 建立成本优化功能。
• 审查：制定流程以审查各项新服务、资源类型以及具体规模。反复进行性能测试以评估潜在成本节约机会。