译者序
AWS用户广泛，产品线复杂，AWS发布的白皮书《Architecting for the Cloud-AWS Best Practices》介绍了常见场景下云架构的最佳实践，不仅对于使用AWS的用户，对于广大使用云的用户都有参考意义，新钛云服工程师特意翻译了本白皮书，供广大使用云的用户参考。
本手册分为两部分
第一部分 传统环境和云环境的差异
第二部分 云架构设计原则
4.5 数据库
对于传统的IT基础架构，组织通常仅限于可以使用的数据库和存储技术。可能存在基于许可成本和支持各种数据库引擎的能力的约束。在AWS上，这些约束由托管数据库服务解除，这些服务以开源成本提供企业性能。因此，应用程序在多语言数据层之上运行并为每个工作负载选择正确的技术并不罕见。
4.5.1 为每项业务负载选择正确的数据库技术
下面的问题可以帮助你决定在架构中包含哪些解决方案：
这是一个读多，写多或读写平衡的业务负载吗？你需要每秒多少次读写操作？如果用户数量增加，这些值将如何变化？你需要存储多少数据以及存储多长时间？会增长多快？在不久的将来是否有上限？每个对象的大小（平均值，最小值，最大值）是多少？如何访问这些对象？数据持久行非规范化，以创建更容易扩展的更平坦的数据结构吗？你需要什么样的功能？你是否需要强大的完整性控制，或者你是否在寻求更大的灵活性（例如，无架构数据存储）？你需要复杂的报告或搜索功能吗？你的开发人员是否比NoSQL更熟悉关系数据库？相关的数据库技术许可成本是多少？这些成本是否会考虑应用程序开发投资，存储和使用成本？许可模式是否支持预计的增长？你是否可以使用Amazon Aurora等云原生数据库引擎来获得开源数据库的简单性和成本效益？4.5.2 关系数据库
关系数据库（也称为RDBS或SQL数据库）将数据规范化为称为表的明确表格结构，表格由行和列组成。它们提供强大的查询语言，灵活的索引功能，强大的完整性控制，以及快速有效地组合来自多个表的数据的能力。Amazon RDS可以轻松地在云中设置，操作和扩展关系数据库，并支持许多熟悉的数据库引擎。
4.5.2.1 可扩展性
关系数据库可以通过升级到更大的Amazon RDS数据库实例或添加更多更快的存储来垂直扩展。此外，请考虑使用Amazon Aurora，它是一种数据库引擎，与在同一硬件上运行的标准MySQL相比，可提供更高的吞吐量。对于读取繁重的应用程序，你还可以通过创建一个或多个只读副本来横向扩展超出单个数据库实例的容量限制。
只读副本是异步复制的单独数据库实例。因此，它们会受到复制滞后的影响，可能会丢失一些最新的事务。应用程序设计人员需要考虑哪些查询对稍微陈旧的数据具有容忍度。这些查询可以在只读副本上执行，而其余查询应该在主节点上运行。只读副本也不能接受任何写入查询。
需要将其写入容量扩展到单个数据库实例的约束之外的关系数据库工作负载需要使用称为数据分区或分片的不同方法。使用此模型，数据分别跨多个数据库模式在自己的主要数据库实例中运行。尽管Amazon RDS消除了运行这些实例的操作开销，但分片会为应用程序带来一些复杂性。需要修改应用程序的数据访问层，以了解数据的分割方式，以便将查询定向到正确的实例。此外，必须跨多个数据库模式执行模式更改，因此值得投入一些精力来自动执行此过程。
4.5.2.2 高可用性
对于任何生产关系数据库，我们建议使用Amazon RDS MultiAZ部署功能，该功能在不同的可用区中创建同步复制的备用实例。如果主节点发生故障，Amazon RDS会自动故障转移到备用节点，而无需手动管理干预。执行故障转移时，会有一段短时间内无法访问主节点。通过使用只读副本提供减少的功能（例如只读模式），可以为弹性应用程序设计弹性应用程序。Amazon Aurora提供多主机功能，可以在可用区域之间扩展读取和写入，还支持跨区域复制。
4.5.2.3 非标准模型
如果你的应用程序主要索引和查询数据而不需要连接或复杂事务，特别是如果你希望写入吞吐量超出单个实例的约束，请考虑使用NoSQL数据库。如果你有大型二进制文件（音频，视频和图像），则在Amazon S3中存储实际文件并仅保存数据库中文件的元数据会更有效。
4.5.3 NoSQL数据库
NoSQL数据库交换关系数据库的一些查询和事务功能，以获得更灵活的数据模型，可以无缝地水平扩展。NoSQL数据库使用各种数据模型，包括图形，键值对和JSON文档，并且因易于开发，可扩展性能，高可用性和弹性而广受认可。Amazon DynamoDB是一种快速灵活的NoSQL数据库服务，适用于任何规模都需要一致，一位数，毫秒级延迟的应用程序.它是一个完全托管的云数据库，支持文档和键值存储模型。
4.5.3.1 可扩展性
NoSQL数据库引擎通常会执行数据分区和复制，以便以水平方式扩展读取和写入。它们透明地执行此操作，并且不需要在应用程序的数据访问层中实现的数据分区逻辑。特别是Amazon DynamoDB自动管理表分区，随着表的大小增加或者读取配置和写入配置容量更改而添加新分区。Amazon DynamoDB Accelerator（DAX）是DynamoDB的托管，高可用内存缓存，可充分利用性能提升。
4.5.3.2 高可用性
Amazon DynamoDB在AWS区域中的三个设施之间同步复制数据，在服务器发生故障或可用区域中断时提供容错功能。Amazon DynamoDB还支持全局表，以提供完全托管的多区域，多主数据库，为大规模扩展的全局应用程序提供快速，本地，读取和写入性能。全局表在所选AWS区域中复制。
4.5.3.3 非标准模型
如果你的模型无法规范化，并且你的应用程序需要连接或复杂事务，请考虑使用关系数据库。如果你有大型二进制文件（音频，视频和图像），请考虑将文件存储在Amazon S3中，并将文件的元数据存储在数据库中。
4.5.4 数据仓库
中的用户行为，来自财务和计费系统的数据，或客户关系管理或CRM），以使其可用于分析和决策。
传统上，设置，运行和扩展数据仓库既复杂又昂贵。在AWS上，你可以利用Amazon Redshift，这是一种托管数据仓库服务，其运行成本仅为传统解决方案的十分之一。
4.5.4.1 可扩展性
Amazon Redshift通过大规模并行处理（MPP），列式数据存储和目标数据压缩编码方案的组合实现了高效存储和最佳查询性能。它特别适用于针对超大型数据集的分析和报告工作负载。Amazon Redshift MPP体系结构使你可以通过增加数据仓库集群中的节点数来提高性能。Amazon Redshift Spectrum支持Amazon RedshiftSQL查询，以防止Amazon S3中的数据数据，从而将AmazonRedshift的分析功能从存储在数据仓库中本地磁盘上的数据扩展到非结构化数据，而无需加载或转换数据。
4.5.4.2 高可用性
Amazon Redshift具有多种功能，可增强数据仓库集群的可靠性。我们建议你在多节点群集中部署生产工作负载，以便将写入节点的数据自动复制到群集中的其他节点。数据也会持续备份到Amazon S3。Amazon Redshift持续监视群集的运行状况，并自动重新启动故障驱动器中的数据，并根据需要替换节点。
4.5.4.3 非标准模型
由于Amazon Redshift是基于SQL的关系数据库管理系统（RDBMS），因此它与其他RDBMS应用程序和商业智能工具兼容。虽然Amazon Redshift提供典型RDBMS的功能，包括在线事务处理（OLTP）功能，但它并非针对这些工作负载而设计。如果你期望高并发工作负载通常涉及一次读取和写入少量记录的所有列，则应考虑使用Amazon RDS或Amazon DynamoDB。
4.5.5 搜索
搜索经常与查询混淆。查询是正式的数据库查询，以正式术语表示特定数据集。搜索可以查询未精确构建的数据集。因此，需要复杂搜索功能的应用程序通常会超出关系数据库或NoSQL数据库的功能。搜索服务可用于索引和搜索结构化和自由文本格式，并且可以支持其他数据库中不可用的功能，例如可自定义的结果排名，过滤的分面，同义词和词干。
在AWS上，你可以选择Amazon CloudSearch和Amazon ElasticsearchService（Amazon ES）。AmazonCloudSearch是一项托管服务，几乎不需要配置，并且会自动扩展。Amazon ES提供开源API，使你可以更好地控制配置详细信息。亚马逊ES也已经发展成为一个不仅仅是一个搜索解决方案。它通常用作日志分析，实时应用程序监控和点击流分析等用例的分析引擎。
4.5.5.1 可扩展性
Amazon CloudSearch和Amazon ES都使用数据分区和复制来横向扩展。不同之处在于，使用Amazon CloudSearch，你无需担心需要多少分区和副本，因为该服务会自动处理该分区和副本。
4.5.5.2 高可用性
Amazon CloudSearch和Amazon ES都包含跨可用区冗余存储数据的功能。
4.5.6 图数据库
图形数据库使用图形结构进行查询。图形被定义为由边（关系）组成，其直接与商店中的节点（数据实体）相关。这些关系使商店中的数据可以直接链接在一起，从而可以快速检索关系系统中复杂的层次结构。出于这个原因，图形数据库是专门用于存储和导航关系的，通常用于社交网络，推荐引擎和欺诈检测等用例中，你需要能够在数据之间创建关系并快速查询这些关系。
Amazon Neptune是一个完全托管的图形数据库服务。
4.5.6.1 可扩展性
Amazon Neptune是专为处理图形查询而优化的专用高性能图形数据库。
4.5.6.2 高可用性
Amazon Neptune具有高可用性，具有只读副本，时间点恢复，连续备份到Amazon S3以及跨可用区复制。海王星是安全的，支持静止和传输中的加密。
4.5.7 管理不断增加的数据量
传统的数据存储和分析工具无法再提供提供相关业务洞察所需的灵活性和灵活性。这就是为什么许多组织正在转向数据湖架构。数据湖是一种架构方法，允许你将大量数据存储在中央位置，以便你可以随时对组织内的不同组进行分类，处理，分析和使用。由于数据可以按原样存储，因此你无需将其转换为预定义的架构，并且你不再需要事先了解有关数据的问题。这使你可以选择正确的技术来满足你的特定分析要求。
4.5.8 消除单点故障
生产系统通常具有定义或隐含的正常运行时间目标。当系统能够承受单个组件或多个组件（例如硬盘，服务器和网络链路）的故障时，该系统具有高可用性。为了帮助你创建具有高可用性的系统，你可以考虑自动化恢复的方法，并减少架构每一层的中断。
4.5.8.1 引入冗余
通过引入冗余可以消除单点故障，这意味着你可以为同一任务提供多个资源。冗余可以在待机或主动模式下实现。
在主备冗余中，当资源发生故障时，将使用故障转移过程在备用资源上恢复功能。故障转移通常需要一些时间才能完成，在此期间资源仍然不可用。备用资源既可以在需要时自动启动（以降低成本），也可以已经空闲运行（以加速故障转移并最大限度地减少中断）。主备冗余通常用于有状态组件，例如关系数据库。
在主主冗余中，请求被分发到多个冗余计算资源。当其中一个失败时，其余的可以简单地吸收更大份额的工作量。与备用冗余相比，主动冗余可以实现更好的使用，并在出现故障时影响较小的人口。
4.5.8.2 检测失败
你应该在检测和响应故障时尽可能多地构建自动化。你可以使用ELB和Amazon Route 53等服务通过将流量路由到健康端点来配置运行状况检查和屏蔽故障。此外，你可以使用Auto Scaling或使用Amazon EC2自动恢复功能或AWS Elastic Beanstalk等服务自动替换不健康的节点。无法在第一天预测每种可能的故障情况。确保收集足够的日志和指标以了解正常的系统行为。了解之后，你将能够设置警报以进行手动干预或自动响应。
设计良好的健康检查
为应用程序配置正确的运行状况检查有助于确定你是否能够正确，及时地响应各种故障情况。指定错误的运行状况检查实际上可能会降低应用程序的可用性。
在典型的三层应用程序中，你可以在ELB上配置运行状况检查。设计你的运行状况检查，目的是可靠地评估后端节点的运行状况。简单的TCP运行状况检查不会检测实例本身是否正常但Web服务器进程是否已崩溃。相反，你应该评估Web服务器是否可以针对某个简单请求返回HTTP 200响应。
在此层，配置深层运行状况检查可能不是一个好主意，这是一种依赖于应用程序的其他层成功的测试，因为可能会导致误报。例如，如果你的运行状况检查还评估实例是否可以连接到后端数据库，则当该数据库节点很快不可用时，你可能会将所有Web服务器标记为不健康。分层方法通常是最好的。深度健康检查可能适合在亚马逊Route53级实施。通过运行更全面的检查来确定该环境是否能够实际提供所需的功能，你可以将Amazon Route 53配置为故障转移到网站的静态版本，直到数据库启动并再次运行。
4.5.8.3 可靠的数据存储
你的应用程序和用户将创建和维护各种数据。你的体系结构保护数据可用性和完整性至关重要。数据复制是引入冗余数据副本的技术。它可以帮助水平扩展读取容量，但它也提高了数据的耐用性和可用性。复制可以在几种不同的模式下进行。
同步复制仅在主要位置及其副本中持久存储之后才确认事务。它是保护主节点发生故障时数据完整性的理想选择。同步复制还可以扩展需要最新数据（强一致性）的查询的读取容量。同步复制的缺点是主节点耦合到副本。在所有副本执行写入之前，无法确认事务。这可能会影响性能和可用性，尤其是在运行不可靠或高延迟网络连接的拓扑中。出于同样的原因，不建议维护许多同步副本。
无论你的解决方案的耐用性如何，这都不能替代备份。同步复制冗余地存储你的数据的所有更新，甚至是那些由软件错误或人为错误导致的更新。但是，特别是对于存储在Amazon S3上的对象，你可以使用版本控制来保留，检索和还原其任何版本，通过版本控制，你可以从非预期的用户操作和应用程序故障中恢复。
异步复制以引入复制延迟为代价将主节点与其副本解耦。这意味着主节点上的更改不会立即反映在其副本上。异步副本用于水平扩展系统对可以容忍复制延迟的查询的读取容量。当故障转移期间可以容忍某些最近事务丢失时，它还可用于提高数据持久性。例如，你可以在单独的AWS区域中维护数据库的异步副本作为灾难恢复解决方案。
基于Quorum的复制结合了同步和异步复制，以克服大规模分布式数据库系统的挑战。
可以通过定义必须参与成功写入操作的最小数量的节点来管理到多个节点的复制。详细讨论分布式数据存储超出了本文档的范围。有关分布式数据存储的更多信息以及超可扩展且高度可靠的数据库系统的核心原则。
了解你使用的每种技术在这些数据存储模型中的位置非常重要。在各种故障转移或备份/还原方案期间，它们的行为应与恢复点目标（RPO）和恢复时间目标（RTO）保持一致。你必须确定你希望丢失的数据量以及恢复操作所需的速度。例如，AmazonElastiCache的Redis引擎支持使用自动故障转移进行复制，但Redis引擎的复制是异步的。在故障转移期间，很可能会丢失一些最近的事务。但是，具有多可用区功能的Amazon RDS旨在提供同步复制，以使备用节点上的数据与主节点保持同步。
4.5.8.4 自动化的多数据中心恢复能力
业务关键型应用程序还需要针对不仅影响单个磁盘，服务器或机架的中断方案进行保护。在传统基础架构中，你通常需要一个灾难恢复计划，以便在主要数据中心发生重大中断时允许故障转移到远程第二个数据中心。由于两个数据中心之间的距离很远，因此延迟使得维护数据的同步跨数据中心副本变得不切实际。因此，故障转移肯定会导致数据丢失或数据恢复过程非常昂贵。这使故障转移成为一种风险并且不总是经过充分测试的程序。尽管如此，这种模型可以提供出色的保护，防止低概率但具有巨大的影响风险，例如长期影响整个基础设施的自然灾害。
更可能的情况是数据中心中断时间更短。对于预计故障持续时间不长的短暂中断，执行故障转移的选择是困难的并且通常被避免。在AWS上，可以采用更简单，更有效的保护来防止此类故障。每个AWS区域包含多个不同的位置或可用区。每个可用区都设计为独立于其他可用区中的故障。可用区是数据中心，在某些情况下，可用区由多个数据中心组成。区域内的可用区域提供廉价，低延迟的网络连接到同一地区的其他区域。这允许你以同步方式跨数据中心复制数据，以便故障转移可以自动化并对用户透明。
也可以实现主动冗余。例如，一组应用程序服务器可以分布在多个可用区中，并附加到ELB。当特定可用区的EC2实例未通过运行状况检查时，ELB将停止向这些节点发送流量。此外，AWS Auto Scaling可确保正确数量的EC2实例可用于运行你的应用程序，根据需求启动和终止实例，并由你的扩展策略定义。如果你的应用程序由于可用区故障而不需要短期性能下降，那么你的体系结构应该是静态稳定的，这意味着它不需要更改工作负载的行为以容忍故障。在这种情况下，你的体系结构应该提供多余的容量来承受一个可用区的丢失。
AWS上的许多高级服务都是根据多可用区（多可用区）原则设计的。例如，AmazonRDS使用多可用区部署为数据库实例提供高可用性和自动故障转移支持，而对于Amazon S3和Amazon DynamoDB，你的数据跨多个设施进行冗余存储。
4.5.8.5 故障隔离与传统水平扩展
虽然主主冗余模式非常适合平衡流量和处理实例或可用区中断，但如果对请求本身有任何不利影响是不够的。例如，可能存在每个实例都受到影响的情况。如果某个特定请求碰巧触发导致系统故障转移的错误，则调用者可能会通过反复尝试针对所有实例的相同请求来触发级联故障。
随机分片
你可以对传统的水平缩放进行隔离改进，这称为分片。与传统上与数据存储系统一起使用的技术类似，你可以将实例分组为分片，而不是在每个节点上传播来自所有客户的流量。例如，如果你的服务有八个实例，则可以创建四个分片，每个分片包含两个实例（每个分片中有两个实例用于冗余），并将每个客户分配到特定分片。
就这样，你能够与你拥有的分片数量成正比地减少对客户的影响。但是，一些客户仍然会受到影响，因此关键是要使客户端容错。如果客户端可以尝试一组分片资源中的每个端点，直到成功，那么你将获得显着的改进。这种技术称为随机分片。
4.6 优化成本
当你将现有架构迁移到云中时，由于AWS的规模经济，你可以减少资本支出并节省成本。通过迭代和使用更多AWS功能，你可以有机会实现创建成本优化的云架构。
4.6.1 正确的实例
AWS为许多用例提供了广泛的资源类型和配置。例如，Amazon EC2，Amazon RDS，Amazon Redshift和Amazon ES等服务提供了许多实例类型。在某些情况下，你应该选择最适合你工作负载要求的类型。在其他情况下，使用较少实例类型的较少实例可能会降低总成本或提高性能。你应该对应用程序环境进行基准测试，并根据工作负载使用CPU，RAM，网络，存储大小和I / O的方式选择正确的实例类型。
同样，你可以通过选择适合你需求的存储解决方案来降低成本。例如，Amazon S3提供各种存储类，包括标准，简化冗余和标准 – 不常访问。其他服务（如Amazon EC2，Amazon RDS和Amazon ES）支持你应评估的不同EBS卷类型（磁性，通用SSD，预配置IOPS SSD）。
随着时间的推移，你可以通过持续监控和标记来继续降低成本。就像应用程序开发一样，成本优化是一个迭代过程。因为，你的应用程序及其使用将随着时间的推移而发展，并且由于AWS经常迭代并定期发布新选项，因此持续评估你的解决方案非常重要。
AWS提供的工具可帮助你识别这些节省成本的机会并使你的资源保持正确的大小。为了使这些工具的结果易于理解，你应该为AWS资源定义和实施标记策略。你可以使用AWS管理工具（如AWS Elastic Beanstalk和AWS OpsWorks）将标记作为构建过程的一部分进行自动化。你还可以使用AWS Config提供的托管规则来评估特定标记是否应用于你的资源。
4.6.2 充分利用弹性
使用AWS节省资金的另一种方法是利用平台的弹性。计划为尽可能多的Amazon EC2工作负载实施Auto Scaling，以便你在需要时横向扩展并缩小规模并在不再需要该容量时自动减少支出。此外，你可以在不使用时自动关闭非生产工作负载。最后，考虑你可以在AWS Lambda上实施哪些计算工作负载，以便你永远不会为空闲或冗余资源付费。
尽可能将AWS EC2工作负载替换为不需要你做出任何容量决策的AWS托管服务（例如ELB，Amazon CloudFront，Amazon SQS，Amazon Kinesis Firehose，AWS Lambda，Amazon SES，Amazon CloudSearch或Amazon EFS ）或使你能够在需要时轻松修改容量（例如Amazon DynamoDB，Amazon RDS或Amazon ES）。
4.6.3 充分利用各种采购方案
Amazon EC2 On-Demand实例定价为你提供最大的灵活性，无需长期承诺。另外两个可以帮助你减少开支的EC2实例是预留实例和竞价型实例。
4.6.3.1 预留实例
与按需实例定价相比，Amazon EC2预留实例允许你保留Amazon EC2计算容量，以换取大幅折扣的小时费率。这是具有可预测的最小容量要求的应用的理想选择。你可以利用AWS Trusted Advisor或Amazon EC2使用情况报告等工具来识别你最常使用且应考虑保留的计算资源。根据你的预留实例购买，折扣将反映在每月帐单中。按需EC2实例和预留实例在技术上没有区别。不同之处在于你为预留的实例付费的方式。
其他服务也存在预留容量选项（例如，Amazon Redshift，Amazon RDS，Amazon DynamoDB和Amazon CloudFront）。
提示：在对生产中的应用程序进行充分基准测试之前，不应提交预留实例购买。在你之后已购买预留容量，你可以使用预留实例利用率报告确保你仍在充分利用预留容量。
4.6.3.2 竞价实例
对于不太稳定的工作负载，请考虑使用竞价实例。Amazon EC2 Spot实例允许你使用备用Amazon EC2计算容量。由于与按需定价相比，竞价实例通常以折扣价格提供，因此你可以显着降低运行应用程序的成本。
竞价实例使你可以请求未使用的EC2实例，这可以显着降低你的Amazon EC2成本。竞价实例（每个可用区中的每个实例类型）的每小时价格由Amazon EC2设置，并根据竞价实例的长期供应和需求逐步调整。只要容量可用且你的请求的每小时最高价格超过竞价价格，你的竞价型实例就会运行。
因此，竞价实例非常适合可以容忍中断的工作负载。但是，当你需要更可预测的可用性时，也可以使用竞价型实例。例如，你可以将预留，按需和竞价型实例组合在一起，将可预测的最小容量与对其他计算资源的机会访问相结合，具体取决于竞价市场价格。这是提高吞吐量或应用程序性能的一种极具成本效益的方法。
4.7 缓存
缓存是一种存储先前计算的数据以供将来使用的技术。该技术用于提高应用程序性能并提高实现的成本效率。它可以应用于IT架构的多个层。
4.7.1 应用程序数据缓存
可以设计应用程序，以便它们从快速，托管，内存中的缓存中存储和检索信息。缓存信息可能包括I / O密集型数据库查询的结果，或计算密集型处理的结果。当在缓存中找不到结果集时，应用程序可以计算它，或者从数据库或昂贵的，缓慢变化的第三方内容中检索它，并将其存储在缓存中以用于后续请求。但是，当在缓存中找到结果集时，应用程序可以直接使用该结果，这可以改善最终用户的延迟并减少后端系统的负载。你的应用程序可以控制每个缓存项目保持有效的时间。在某些情况下，对于非常受欢迎的对象，即使几秒钟的缓存也会导致数据库负载的急剧下降。
Amazon ElastiCache是一种Web服务，可以轻松部署，操作和扩展云中的内存缓存。它支持两个开源的内存缓存引擎：Memcached和Redis。
Amazon DynamoDB Accelerator（DAX）是DynamoDB的完全托管，高可用性内存缓存，可提供从毫秒到微秒的性能改进，实现高吞吐量。DAX为你的DynamoDB表添加了内存加速，而无需管理缓存失效，数据填充或集群管理。
4.7.2 边缘缓存
静态内容（图像，CSS文件或流媒体预录制视频）和动态内容（响应式HTML，实时视频）的副本可以缓存在Amazon CloudFront边缘位置，这是一个在全球有多个存在点的CDN。边缘缓存允许内容由更接近的基础设施提供服务查看器，可以降低延迟并为你提供高大，持续的数据传输速率，从而为大规模的最终用户提供大型流行对象。
你的内容请求将智能地路由到Amazon S3或原始服务器。如果源在AWS上运行，请求将通过优化的网络路径传输，以获得更可靠和一致的体验。你可以使用Amazon CloudFront来交付整个网站，包括不可缓存的内容。在这种情况下，好处是Amazon CloudFront重用Amazon CloudFront边缘和源服务器之间的现有连接，这减少了每个源请求的连接设置延迟。还应用其他连接优化以避免互联网瓶颈并充分利用边缘位置和观看者之间的可用带宽。这意味着，当你浏览Web应用程序时，Amazon CloudFront可以加快你的动态内容的交付，并为你的查看者提供一致，可靠，个性化的体验。Amazon CloudFront还将上传请求应用于与下载动态内容请求相同的性能优势。安全
4.8 安全
你可能已经在传统IT基础架构中熟悉的大多数安全工具和技术都可以在云中使用。同时，AWS允许你以各种方式提高安全性。AWS是一个平台，允许你在平台本身中正式设计安全控制。它简化了管理员和IT部门的系统使用，使你的环境更容易以连续的方式进行审计。
4.8.1 使用AWS功能进行深度防御
AWS提供了许多功能，可以帮助你构建具有深度防御方法的体系结构。从网络级别开始，你可以构建VPC拓扑，通过使用子网，安全组和路由控制来隔离部分基础结构。AWS WAF（Web应用程序防火墙）等服务可以帮助保护你的Web应用程序免受SQL注入和应用程序代码中的其他漏洞的影响。对于访问控制，你可以使用IAM定义一组精细策略，并将其分配给用户，组和AWS资源。最后，AWS Cloud提供了许多选项来保护你的数据，无论是在运输途中还是静止状态。
4.8.2 与AWS共享安全责任
AWS在共享安全责任模型下运行：AWS负责底层云基础架构的安全性，你负责保护你在AWS中部署的工作负载。这有助于你通过使用AWS托管服务减少你的职责范围并专注于你的核心竞争力。例如，当你使用Amazon RDS和Amazon ElastiCache等服务时，安全补丁会自动应用于你的配置设置。这不仅可以降低团队的运营开销，还可以减少你的漏洞风险。
4.8.3 减少特权访问
当你的服务器是可编程资源时，你将获得许多安全优势。随时随地更改服务器的功能使你无需客户操作系统访问生产环境。如果实例遇到问题，你可以自动或手动终止并替换它。但是，在替换实例之前，你应该收集并集中存储日志数据，这些数据可以帮助你在开发环境中重新创建问题，并通过持续部署过程将它们部署为修复程序。此方法可确保日志数据有助于排除故障并提高安全事件的意识。这在服务器是临时的弹性计算环境中尤为重要。你可以使用Amazon CloudWatch Logs收集此信息。如果你没有直接访问权限，则可以实施A
另一个常见的安全风险是使用存储的长期凭证或服务帐户。在传统环境中，服务帐户通常会分配存储在配置文件中的长期凭据。在AWS上，你可以使用IAM角色通过使用自动分发和轮换的短期凭据向EC2实例上运行的应用程序授予权限。对于移动应用程序，你可以使用Amazon Cognito允许客户端设备通过具有细粒度权限的临时令牌访问AWS资源。
作为AWS管理控制台用户，你可以类似地通过临时令牌提供联合访问，而不是在你的AWS账户中创建IAM用户。然后，当员工离开你的组织并从组织的身份目录中删除时，该员工也会自动失去对你的AWS账户的访问权限。
4.8.4 安全代码
传统的安全框架，法规和组织策略定义了与防火墙规则，网络访问控制，内部/外部子网和操作系统强化等项目相关的安全要求。你也可以在AWS环境中实现这些，但你现在有机会在定义黄金环境的模板中捕获它们。AWS CloudFormation使用此模板，并根据你的安全策略部署资源。作为持续集成管道的一部分，你可以在多个项目中重用安全性最佳实践。你可以在发布周期中执行安全测试，并自动发现应用程序差距并从安全策略中消失。
此外，为了获得更好的控制和安全性，可以将AWS CloudFormation模板作为产品导入AWS Service Catalog.5。这使你可以集中管理资源，以支持一致的治理，安全性和合规性要求，同时使你的用户能够快速部署他们需要批准的IT服务。你应用IAM权限来控制可以查看和修改产品的人员，并定义约束以限制可以为产品部署特定AWS资源的方式。
4.8.5 实时审计
测试和审核你的环境是保持安全的快速移动的关键。涉及定期（通常是手动或基于样本）检查的传统方法是不够的，尤其是在变化不变的敏捷环境中。在AWS上，你可以实施控制的持续监控和自动化，以最大限度地降低安全风险。AWS Config，Amazon Inspector和AWS Trusted Advisor等服务会持续监控合规性或漏洞，从而清楚地了解哪些IT资源符合要求，哪些不符合要求。使用AWS Config规则，你还可以了解资源是否在短时间内不合规，从而使得时间点和时间段审核非常有效。
你通过启用AWS CloudTrail，可以为你的应用程序（使用Amazon CloudWatch Logs）和实际的AWS API调用实施广泛的日志记录AWS CloudTrail是一种Web服务，它记录对AWS账户中受支持的AWS服务的API调用，并将日志文件传送到S3存储桶。然后，日志数据可以以不可变的方式存储，并自动处理以发送通知或代表你采取行动，从而保护你的组织免受不合规。你可以使用AWS Lambda，Amazon EMR，Amazon ES，Amazon Athena或AWS Marketplace中的第三方工具扫描日志数据，以检测未使用权限，特权帐户过度使用，密钥使用，异常登录，策略违规和系统等事件滥用。
5. 结论
在AWS中设计云架构时，重要的是要考虑AWS中的重要原则和设计模型，包括如何为应用程序选择正确的数据库，以及如何构建可以水平扩展且具有高可用性的应用程序。由于每项实现都是唯一的，因此你必须评估如何将此指南应用于你的实现。云计算体系结构是一个广泛而不断发展的主题。您可以使用AWS网站上提供的材料以及AWS培训和认证产品，随时了解AWS云产品的最新更改和添加。
说明：
本文由新钛云服运维工程师傅雨斌翻译，新钛云服拥有八名认证的AWS工程师，在AWS使用和维护方面拥有丰富的经验，已经为多家用户提供AWS上云支持。
原文链接：
https://d1.awsstatic.com/whitepapers/AWS_Cloud_Best_Practices.pdf
