译者序
AWS用户广泛，产品线复杂，AWS发布的白皮书《Architecting for the Cloud-AWS Best Practices》介绍了常见场景下云架构的最佳实践，不仅对于使用AWS的用户，对于广大使用云的用户都有参考意义，新钛云服工程师特意翻译了本白皮书，供广大使用云的用户参考。
本手册分为两部分
第一部分 传统环境和云环境的差异
第二部分 云架构设计原则
4. 设计原则
AWS 包含许多可应用于各种用例的设计模式和体系结构选项。AWS的一些关键设计原则包括可扩展性，可支配资源，自动化，用松耦合管理服务，以及灵活的数据存储选项。
4.1 可扩展性
预计随着时间的推移而增长的系统需要建立在可扩展的架构之上。这样的体系架构可以支持用户，流量或数据大小的增长，而不会降低性能。应该以线性方式按比例提供资源，添加额外资源至少导致成比例增加提供额外负载的能力。增长应引入规模经济，成本应遵循从该系统产生商业价值的相同维度。虽然云计算提供几乎无限的按需容量，但你的设计需要能够无缝地利用这些资源。
通常有两种扩展IT架构的方法：纵向扩展和横向扩展。
4.1.1 纵向扩展
纵向扩展通过增加单个资源的规模来实现，例如升级具有更大硬盘驱动器或更快CPU的服务器。使用Amazon EC2，你可以停止实例并将其调整为具有更多RAM，CPU，I/O或网络功能的实例类型。这种缩放方式最终将达到极限，并且它并不总是具有成本效益或高度可用的方法。但是，它很容易实现，并且对于许多用例来说已经足够了，特别是在短期内。
4.1.2 横向扩展
通过增加资源数量来横向扩展，例如向存储阵列添加更多硬盘驱动器，或添加更多服务器以支持应用程序。这是构建利用云弹性的互联网规模应用程序的好方法。并非所有体系结构都旨在将其工作负载分配给多个资源，因此让我们检视一些可能的情况。
1) 无状态应用
当用户或服务与应用程序交互时，通常会执行一系列形成会话的交互。会话是用户在使用应用程序时在请求之间保持不变的唯一数据。无状态应用程序是不需要先前交互知识，且不存储会话信息的应用程序。例如，给定相同输入，向任何最终用户提供相同响应的应用程序是无状态应用程序。无状态应用程序可以横向扩展，因为任何可用的计算资源（例如EC2实例和AWS Lambda函数）都可以为任何请求提供服务。如果没有存储会话数据，可以根据需要添加更多计算资源。当不再需要该容量时，可以在运行任务耗尽后安全地终止这些单独的资源。这些资源不需要知道同伴的存在，所需要的只是将工作负载分配给它们的方法。
2) 将负载分配给多个节点
要将工作负载分配到环境中的多个节点，可以选择推模型或拉模型。
使用推模型，可以使用Elastic Load Balancing（ELB）来分配工作负载。ELB跨多个EC2实例路由传入的应用程序请求。在路由流量时，网络负载均衡器在开放系统互连（OSI）模型的第4层运行，以处理每秒数百万个请求。通过采用基于容器的服务，还可以使用应用程序负载均衡器。应用程序负载均衡器提供OSI模型的第7层，并支持基于应用程序流量的基于内容的请求路由。或者，可以使用Amazon Route 53实施DNS轮询。在这种情况下，DNS响应以循环方式从有效主机列表中返回IP地址。虽然易于实施，但这种方法并不总能很好地适应云计算的弹性。这是因为即使你可以为DNS记录设置低生存时间（TTL）值，缓存DNS解析器也不在Amazon Route 53的控制范围内，并且可能并不总是遵循你的设置。
可以为异步，事件驱动的工作负载实现拉模型，而不是负载平衡解决方案。在拉模型中，需要执行的任务或需要处理的数据可以使用Amazon Simple Queue Service（Amazon SQS）作为消息存储在队列中，也可以作为流数据解决方案存储
比如亚马逊Kinesis，多个计算资源可以提取和使用这些消息，以分布式方式处理它们。
3) 无状态组件
实际上，大多数应用程序都维护某种状态信息。例如，Web应用程序需要跟踪用户是否已登录，以便可以基于先前的操作呈现个性化内容。自动化的多步骤过程还需要跟踪先前的活动，以确定其下一步应该是什么。仍然可以通过不在本地文件系统中存储需要多于一个请求的任何内容，来使这些体系结构的一部分无状态。
例如，Web应用程序可以使用HTTP cookie在Web客户端缓存中存储会话信息（如购物车项目）。浏览器在每个后续请求时将该信息传递回服务器，以便应用程序不需要存储它。但是，这种方法有两个缺点。首先，HTTP cookie的内容可能会在客户端被篡改，因此你应始终将其视为必须经过验证的不可信数据。其次，HTTP cookie随每个请求一起传输，这意味着你应该将其大小保持在最小，以避免不必要的延迟。
考虑仅在HTTP cookie中存储唯一的会话标识符，并在服务器端存储更详细的用户会话信息。大多数编程平台都提供以这种方式工作的本机会话管理机制。但是，默认情况下，用户会话信息通常存储在本地文件系统中，从而形成有状态架构。此问题的常见解决方案是将此信息存储在数据库中。Amazon DynamoDB是一个很好的选择，因为它具有可扩展性，高可用性和耐用性特征。对于许多平台，有一些开源替代库，允许你在Amazon DynamoDB中存储本机会话。
其他方案需要存储较大的文件（例如用户上载和批处理的中间结果）。通过将这些文件放在共享存储层（如Amazon Simple Storage Service，Amazon S3；或Amazon Elastic File System，Amazon EFS））中，可以避免引入有状态组件。
最后，复杂的多步骤工作流是另一个必须跟踪每个执行的当前状态的示例。可以使用AWS步骤功能集中存储执行历史记录，并使这些工作负载无状态。
4) 有状态组件
不可避免地，你的架构层将不会变成无状态组件。根据定义，数据库是有状态的。有关更多信息，请参阅后面的“数据库章节"。此外，许多遗留应用程序设计为依靠本地计算资源在单个服务器上运行。其它用例包括可能需要客户端设备长时间保持与特定服务器的连接。例如，实时多人游戏必须以非常低的延迟为多个玩家提供一致的游戏世界视图。在非分布式实现中实现这一点要简单得多，其中参与者连接到同一服务器。
仍然可以通过将负载分配到具有会话亲缘关系的多个节点来水平扩展这些组件。在此模型中，将会话的所有事务绑定到特定的计算资源。但是，这个模型确实有一些局限性。现有会话不会直接受益于新启动的计算节点的引入。更重要的是，无法保证会话亲和力。例如，当节点终止或变得不可用时，绑定到该节点的用户将断开连接并遇到特定于会话的数据丢失，这些数据不会存储在共享资源，如Amazon S3，Amazon EFS或a数据库。
5) 实现会话亲和性
对于HTTP和HTTPS流量，你可以使用应用程序负载均衡器的粘性会话功能，将用户的会话绑定到特定实例。使用此功能，应用程序负载均衡器将尝试在该持续时间内为该用户使用相同的服务器会议。另一个选项，如果你控制在客户端上运行的代码，是使用客户端负载平衡。这会增加额外的复杂性，但在负载均衡器不符合你的要求的情况下非常有用。例如，你可能正在使用ELB不支持的协议，或者你可能需要完全控制如何将用户分配给服务器（例如，在游戏场景中，可能需要确保游戏参与者匹配并连接到相同的服务器）。在此模型中，客户端需要一种方法来发现有效的服务器端点以直接连接。可以使用DNS，或者你可以构建一个简单的发现API，以便将该信息提供给客户端上运行的软件。在没有负载均衡器的情况下，还需要在客户端实现健康检查机制。应该设计客户端逻辑，以便在检测到服务器不可用时，设备重新连接到另一台服务器，而对应用程序几乎没有中断。
6) 分布式处理
涉及处理大量数据的用例，无法及时处理单个计算资源的任何事物，需要采用分布式处理方法。通过将任务及其数据划分为许多小的工作片段，可以跨一组计算资源并行执行它们。
7）实施分布式处理
通过使用AWS Batch，AWS Glue和Apache Hadoop等分布式数据处理引擎，可以水平扩展脱机批处理作业。在AWS上，可以使用Amazon EMR在一组EC2实例之上运行Hadoop工作负载，而无需运维复杂性。对于流数据的实时处理，Amazon Kinesis将数据分成多个分片，然后由多个Amazon EC2或AWS Lambda资源使用，以实现可扩展性。
有关这些类型工作负载的更多信息，请参阅《Big Data Analytics Options on AWS 》和《Core Tenets of IoT》白皮书。
4.2 一次性资源而不是固有服务器
在传统的基础架构环境中，由于引入新硬件的前期成本和前置时间，必须使用固定资源。这推动了诸如手动登录服务器以配置软件或修复问题，硬编码IP地址以及按顺序运行测试或处理作业等实践。
在为AWS设计时，可以利用云计算的动态配置特性。可以将服务器和其他组件视为临时资源。可以根据需要启动任意数量实例，并且只在需要时使用它们。
长期运行的服务器的另一个问题是配置偏差。随时间推移应用的更改和软件修补程序可能会导致跨不同环境的未经测试和异构配置。可以使用不可变的基础架构结构模型模式解决此问题。使用这种方法方式，服务器一旦启动永远不会更新。相反，当出现问题或需要更新时，问题服务器将替换为具有最新配置的新服务器。这使资源始终处于一致（和测试）状态，并使回滚更容易执行。使用无状态体系结构更容易支持这一点。
4.2.1 实例化计算资源
无论是部署新环境进行测试，还是增加现有系统的容量来应对额外负载，你都不希望使用其配置和代码手动设置新资源。重要的是，你要使其成为一个自动化且可重复的过程，以避免较长的交付周期，并且不会出现人为错误。有几种方法可以实现这一目标。
1）引导
启动AWS资源（如EC2实例或AmazonRelational Database Service（Amazon RDS）数据库实例）时，将启动默认配置。然后，可以执行自动引导操作，这些操作是安装软件或复制数据以将该资源带入特定状态的脚本。可以参数化在不同环境（例如生产或测试）之间变化的配置详细信息，以便可以重复使用相同的脚本而无需进行任何修改。
可以使用用户数据脚本和cloud-init指令设置新的EC2实例。可以使用简单的脚本和配置管理工具，例如Chef或Puppet。此外，通过自定义脚本和AWS API，或AWS AWS支持的自定义资源的AWS CloudFormation支持，可以编写几乎适用于任何AWS资源的配置逻辑。
2）黄金镜像
某些AWS资源类型（例如EC2实例，AmazonRDS数据库实例和Amazon Elastic Block Store，Amazon EBS）可以从黄金镜像启动，黄金镜像是该资源的特定状态的快照。与引导方法相比，黄金镜像可以缩短启动时间并消除对配置服务或第三方存储库的依赖性。这在自动扩展环境中非常重要，在这种环境中，你希望能够快速可靠地启动其他资源，以响应需求变化。
可以自定义EC2实例，然后通过创建Amazon Machine Image（AMI）来保存其配置。可以根据需要从AMI启动任意数量的实例，并且它们都将包括这些自定义项。每次要更改配置时，都必须创建一个新的黄金镜像，因此必须具有版本控制约定来管理你的黄金镜像。建议你使用脚本为你用于创建的EC2实例创建引导程序的AMI。这为你提供了一种灵活的方法来测试和修改这些镜像。
或者，如果你具有现有的本地虚拟化环境，则可以使用AWS的VM导入/导出将各种虚拟化格式转换为AMI。你还可以查找和使用AWS或AWS中的第三方提供的预封装共享AMI。
虽然启动新EC2实例时最常使用黄金镜像，但它们也可以应用于Amazon RDS数据库实例或Amazon EBS卷等资源。例如，当启动新的测试环境时，你可能希望通过从特定的Amazon RDS快照实例化数据库来预填充其数据库，而不是从冗长的SQL脚本中导入数据。
3）容器
开发人员喜欢的另一个选择是Docker，一种开源技术，允许你在软件容器内构建和部署分布式应用程序。Docker允许你将一个软件封装在Docker镜像中，这是一个软件开发的标准化单元，包含软件运行所需的所有内容：代码，运行时，系统工具，系统库等。AWS Elastic Beanstalk，Amazon ElasticContainer 服务（Amazon ECS）和AWSFargate允许你跨EC2实例集群部署和管理多个容器。你可以构建黄金Docker镜像并使用ECS容器注册表来管理它们。
另一种容器环境是Kubernetes和Kubernetes的亚马逊弹性容器服务（Amazon EKS）。借助Kubernetes和Amazon EKS，你可以轻松部署，管理和扩展容器化应用程序。
4）混合
你还可以使用这两种方法的组合：配置的某些部分在黄金镜像中捕获，而其他部分则通过引导操作动态配置。
不经常更改或引入外部依赖项的项目通常是你的黄金镜像的一部分。一个好的候选者的例子是你的Web服务器软件，否则每次启动实例时都必须由第三方存储库下载。
可以通过引导操作动态设置在不同环境之间经常更改或不同的项目。例如，如果要经常部署应用程序的新版本，则为每个应用程序版本创建新的AMI可能不切实际。你也不希望将数据库主机名配置硬编码到AMI，因为测试和生产环境之间会有所不同。用户数据或标签允许你使用可在启动时修改的更通用的AMI。例如，如果你为各种小型企业运行Web服务器，则它们都可以使用相同的AMI，并从启动时在用户数据中指定的S3存储桶位置检索其内容。
AWS Elastic Beanstalk遵循混合模型。它提供预配置的运行时环境，每个环境都是从其自己的AMI11启动的，但允许你通过ebextensions配置文件运行引导操作，并配置环境变量以参数化环境差异。
4.2.2 基础架构即代码
我们讨论的原则的应用不必限于单个的资源水平。由于AWS资源是可编程的，因此你可以应用软件开发中的技术，实践和工具，使你的整个基础架构可重用，可维护，可扩展和可测试。
AWS CloudFormation模板为你提供了一种简单的方法来创建和管理相关AWS资源的集合，并以有序和可预测的方式提供和更新它们。你可以描述运行应用程序所需的AWS资源，以及任何关联的依赖项或运行时参数。你的CloudFormation模板可以与你的版本控制存储库中的应用程序一起使用，这样你就可以重用架构并可靠地克隆生产环境以进行测试。
4.3 自动化
在传统的IT基础架构中，你通常必须手动对各种事件做出反应。在AWS上部署时，你可以进行自动化。
为了提高系统的稳定性和组织的效率，考虑将一种或多种这类自动化引入你的应用程序体系结构，以确保更高的弹性，可伸缩性和性能。
4.3.1 无服务器管理和部署
采用无服务器模式时，操作重点是部署自动化流水线。AWS管理基础服务，规模和可用性。AWS CodePipeline，AWS CodeBuild和AWS CodeDeploy支持这些流程部署的自动化。
4.3.2 基础架构管理和部署
AWS Elastic Beanstalk：你可以使用此服务在熟悉的服务器（如Apache，Nginx，Passenger和服务器）上部署和扩展使用Java，.NET，PHP，Node.js，Python，Ruby，Go和Docker开发的Web应用程序和服务。IIS开发人员可以简单地上传他们的应用程序代码，该服务自动处理所有细节，例如资源配置，负载平衡，自动扩展和监视。
Amazon EC2自动恢复：你可以创建监控EC2实例的Amazon CloudWatch警报，并在其受损时自动恢复。恢复的实例与原始实例相同，包括实例ID，私有IP地址，弹性IP地址，和所有实例元数据。但是，此功能仅适用于适用的实例配置。有关这些前提条件的最新说明，请参阅Amazon EC2文档。此外，在实例恢复期间，实例将通过实例重新引导进行迁移，并且内存中的所有数据都将丢失。
AWS Systems Manager：你可以自动收集软件清单，应用操作系统补丁，创建系统镜像以配置Windows和Linux操作系统，以及执行任意命令。提供这些服务简化了操作模型并确保了最佳的环境配置。
Auto Scaling：你可以根据你定义的条件自动维护应用程序可用性，并自动扩展Amazon EC2，Amazon DynamoDB，Amazon ECS，适用于Kubernetes的Amazon Elastic Container Service，（Amazon EKS）容量。你可以使用Auto Scaling帮助确保跨多个可用区运行所需数量的健康EC2实例。Auto Scaling还可以在需求峰值期间自动增加EC2实例的数量，在不太繁忙的时期保持性能并降低容量以优化成本。
4.3.3 警报和事件
Amazon CloudWatch警报：你可以创建CloudWatch警报，当特定指标超过指定阈值达指定数量的时段时，该警报会发送AmazonSimple Notification Service（Amazon SNS）消息。这些Amazon SNS消息可以自动启动执行订阅的Lambda函数，将通知消息排入Amazon SQS队列，或者对HTTP或HTTPS端点执行POST请求。
Amazon CloudWatchEvents：提供近乎实时的系统事件流，描述AWS资源中的变更.使用简单规则，你可以将每种类型的事件路由到一个或多个目标，例如Lambda函数，Kinesis流和SNS主题。
AWS Lambda预定事件：你可以创建Lambda函数并配置AWS Lambda以定期执行它。
AWS WAF安全自动化：AWS WAF是一种Web应用程序防火墙，使你能够创建自定义的特定于应用程序的规则，以阻止可能影响应用程序可用性，危及安全性或消耗过多资源的常见攻击模式。你可以通过API完全管理AWS WAF，从而简化安全自动化，实现快速规则传播和快速事件响应。
4.4 松耦合
随着应用程序复杂性的增加，IT系统的理想属性是可以将其分解为更小，松耦合的组件。这意味着IT系统的设计应该能够减少相互依赖性，一个组件中的更改或故障不应该级联到其他组件。
4.4.1 定义明确的接口
减少系统中相互依赖性的一种方法是允许各种组件仅通过特定的，与技术无关的接口（例如RESTful API）相互交互。通过这种方式，隐藏了技术实现细节，以便团队可以修改底层实现而不影响其他组件。只要这些接口保持向后兼容性，差异组件的部署就会分离。这种粒度设计模式通常被称为微服务架构。
Amazon API Gateway是一种完全托管的服务，使开发人员可以轻松地以任何规模创建，发布，维护，监控和保护API。它处理接受和处理多达数十万个并发API调用所涉及的所有任务，包括流量管理，授权和访问控制，监控和API版本管理。
4.4.2 服务发现
部署为一组较小服务的应用程序取决于这些服务相互交互的能力。因为每个服务都可以跨多个计算资源运行，所以需要有一种方法来解决每个服务。例如，在传统基础结构中，如果你的前端Web服务需要与后端Web服务连接，则可以对运行此服务的计算资源的IP地址进行硬编码。虽然这种方法仍然适用于云计算，但如果这些服务是松耦合的，那么它们应该能够在不事先了解其网络拓扑细节的情况下使用。除了隐藏复杂性之外，这还允许基础架构细节随时更改。如果你想利用云计算的弹性，可以在任何时间点启动或终止新资源，那么松耦合是一个至关重要的因素。为了实现这一目标，你需要一些实现服务发现的方法。
实施服务发现
对于Amazon EC2托管的服务，实现服务发现的一种简单方法是通过Elastic LoadBalancing（ELB）。由于每个负载均衡器都有自己的主机名，因此你可以通过稳定的endpoint使用服务。这可以与DNS和私有Amazon Route 53区域结合使用，以便可以随时抽象和修改特定负载均衡器的endpoint。
另一种选择是使用服务注册和发现方法来允许检索任何服务的endpoint IP地址和端口号。由于服务发现成为组件之间的粘合剂，因此高度可用且可靠性非常重要。如果未使用负载平衡器，则还应该进行服务发现允许健康检查等选项。Amazon Route 53支持自动命名，以便更轻松地为微服务配置实例。自动命名允许你根据定义的配置自动创建DNS记录。其他示例实现包括使用标签组合的自定义解决方案，高可用性数据库，调用AWSAPI的自定义脚本，或Netflix Eureka，AirbnbSynapse或HashiCorp Consul等开源工具。
4.4.3 异步集成
异步集成是服务之间松耦合的另一种形式。此模型适用于任何不需要立即响应的交互，以及已经注册请求的确认就足够了。它涉及一个生成事件的组件和另一个消耗它们的组件。这两个组件不通过直接的点对点交互进行集成，而是通过中间持久存储层进行集成，例如SQS队列或流式数据平台（如Amazon Kinesis），级联Lambda事件，AWS步骤功能或AmazonSimple Workflow服务。
图1：紧耦合和松耦合
这种方法将两个组件分离，并引入了额外的弹性。因此，例如，如果正在从队列中读取消息的进程失败，则仍可以将消息添加到队列中并在系统恢复时进行处理。它还允许你保护不太可扩展的后端服务免受前端尖峰的攻击，并找到正确的成本和处理滞后之间的权衡。例如，你可以决定不需要扩展数据库以适应偶尔的写入查询峰值，只要你最终以一些延迟异步处理这些查询。最后，通过从交互式请求路径中删除慢速操作，你还可以改善最终用户体验。
异步集成的示例包括：
- 前端应用程序将作业插入队列系统（如Amazon SQS）。后端系统检索这些作业并按照自己的进度处理它们。
- API生成事件并将其推送到Kinesis流中。后端应用程序批量处理这些事件以创建存储在数据库中的聚合时间序列数据。
- 多个异构系统使用AWS步骤函数来传达它们之间的工作流，而无需直接相互交互。
- Lambda函数可以使用来自各种AWS源的事件，例如Amazon DynamoDB更新流和Amazon S3事件通知。你不必担心实现排队或其他异步集成方法，因为Lambda会为你处理此问题。
4.4.4 分布式系统最佳实践
增加松耦合的另一种方法是构建以优雅方式处理组件故障的应用程序。你可以确定减少对最终用户的影响的方法，并提高你在脱机过程中取得进展的能力，即使在某些组件发生故障时也是如此。
实践中优雅的应对失败
失败的请求可以使用指数退避和抖动策略重试，也可以存储在队列中以供以后处理。对于前端接口，可以提供替代或缓存的内容，而不是完全失败，例如，你的数据库服务器变得不可用。Amazon Route 53 DNS故障转移功能还使你能够监控你的网站，并在主站点不可用时自动将访问者路由到备份站点。你可以将备份站点作为Amazon S3上的静态网站托管，也可以作为单独的动态环境托管。
4.4.5 服务，而不是服务器
开发，管理和运维应用程序，尤其是大规模应用程序，需要各种各样的底层技术组件。对于传统的IT基础架构，公司必须构建和运行所有这些组件。
AWS提供广泛的计算，存储，数据库，分析，应用程序和部署服务，可帮助组织更快地移动并降低IT成本。
不利用这种广度的架构（例如，如果它们仅使用AmazonEC2）可能无法充分利用云计算，并且可能错失了提高开发人员生产力和运营效率的机会。
4.4.5.1 管理服务
AWS托管服务提供开发人员可以使用的构建块来为其应用程序供电。这些托管服务包括数据库，机器学习，分析，排队，搜索，电子邮件，通知等。例如，使用Amazon SQS，你可以减轻运维和扩展高可用性消息传递群集的管理负担，同时仅为你使用的内容支付低价。Amazon SQS本身也具有可扩展性和可靠性。这同样适用于Amazon S3，它使你可以根据需要存储尽可能多的数据，并在需要时访问它，而无需考虑容量，硬盘配置，复制和其他相关问题。
为你的应用程序提供支持的托管服务的其他示例包括：
- 用于内容交付的AmazonCloudFront
- 用于负载平衡的ELB
- 用于NoSQL数据库的Amazon DynamoDB
- 用于搜索工作负载的AmazonCloudSearch
- 用于视频编码的Amazon ElasticTranscoder
- 用于发送和接收电子邮件的AmazonSimple Email Service（Amazon SES）
4.4.5.2 无服务器计算架构
无服务器计算架构可以降低运行应用程序的操作复杂性。无需管理任何服务器基础架构，就可以为移动，Web，分析，CDN业务逻辑和物联网构建事件驱动和同步服务。这些体系结构可以降低成本，因为你无需管理或支付未充分利用的服务器，也无需配置冗余基础架构来实现高可用性。
例如，你可以将代码上载到AWS Lambda计算服务，并且该服务可以使用AWS基础结构代表你运行代码。使用AWS Lambda，你需要为代码执行的每100毫秒以及触发代码的次数付费。通过使用Amazon API Gateway，你可以开发由AWS Lambda支持的几乎无限可扩展的同步API。与Amazon S3结合使用以提供静态内容资产时，此模式可以提供完整的Web应用程序。
在移动和Web应用程序方面，你可以使用Amazon Cognito，这样你就无需管理后端解决方案来处理用户身份验证，网络状态，存储和同步。Amazon Cognito为你的用户生成唯一标识符。
可以在访问策略中引用这些标识符，以基于每个用户启用或限制对其他AWS资源的访问。Amazon Cognito为你的用户提供临时AWS凭证，允许设备上运行的移动应用程序直接与受AWS身份和访问管理（IAM）保护的AWS服务进行交互。例如，使用IAM，你可以将对S3存储桶中的文件夹的访问权限限制为特定的最终用户。
对于物联网应用，组织传统上必须配置，操作，扩展和维护自己的服务器作为设备网关，以处理连接设备与其服务之间的通信。AWS IoT提供完全受管理的设备网关，可根据你的使用情况自动扩展，无需任何操作开销。
无服务器计算架构还使得在边缘计算运行响应式服务成为可能。
说明：
本文由新钛云服运维工程师傅雨斌翻译，新钛云服拥有八名认证的AWS工程师，在AWS使用和维护方面拥有丰富的经验，已经为多家用户提供AWS上云支持。
原文链接：
https://d1.awsstatic.com/whitepapers/AWS_Cloud_Best_Practices.pdf
閱讀更多 新鈦雲服 的文章
