AWS-管理权威指南第二版-全-

AWS 管理权威指南第二版（全）

原文：annas-archive.org/md5/688c1e7665f0bb88ed93e3f4d457ba3c

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

亚马逊云服务现在已经成为客户和企业的首选云服务很长一段时间了。这家云服务提供商已经从仅仅是基础设施即服务提供商发展为一切和任何服务，帮助开发应用程序、游戏开发、物联网、大数据分析、客户参与服务、AR-VR 等等！然而，随着每年推出这么多服务和产品，对于初学者来说，很难知道从哪里开始以及如何开始使用这些服务。

这本书是一个一站式商店，您可以找到所有关于开始使用 AWS 服务的内容，其中包括 EC2 系统管理器，弹性 Beanstalk，EFS，CloudTrail，EMR，IoT 等等！如果您是系统管理员、架构师或只是想学习和探索 AWS 服务的各个方面的人，那么这本书就是您的正确选择！本书的每一章都旨在帮助您理解各个服务的概念，并通过练习简单易行的步骤获得实践经验。该书还强调了一些您在使用 AWS 时应该牢记的关键最佳实践和建议。

本书适合对象

本书适用于希望学习和实施 AWS 用于其自身环境和应用程序托管的所有 IT 专业人员。虽然不需要任何先前经验或知识，但对于您具有基本的 Linux 知识和对网络概念和服务器虚拟化有一定了解将是有益的。

要充分利用本书

要开始使用本书，您需要在本地桌面上安装以下软件：

• 诸如 PuTTY 这样的 SSH 客户端、PuTTYgen 这样的密钥生成器以及 WinSCP 这样的文件传输工具

• 任何现代网络浏览器，最好是 Mozilla Firefox

下载示例代码文件

您可以从www.packtpub.com的帐户中下载本书的示例代码文件。如果您在其他地方购买了这本书，您可以访问www.packtpub.com/support注册，以便直接通过电子邮件接收文件。

您可以按照以下步骤下载代码文件：

1. 在www.packtpub.com上登录或注册。

2. 选择“支持”选项卡。

3. 点击“代码下载和勘误”。

4. 在搜索框中输入书名并按照屏幕上的说明操作。

下载文件后，请确保使用最新版本的解压缩文件夹：

• 用于 Windows 的 WinRAR/7-Zip

• 用于 Mac 的 Zipeg/iZip/UnRarX

• 用于 Linux 的 7-Zip/PeaZip

本书的代码包也托管在 GitHub 上，网址为github.com/PacktPublishing/AWS-Administration-The-Definitive-Guide-Second-Edition。如果代码有更新，将在现有的 GitHub 存储库上进行更新。

我们还提供了丰富的书籍和视频资源，您可以在 github.com/PacktPublishing/ 找到更多的代码包。快来查看吧！

使用的约定

本书中使用了许多文本约定。

CodeInText：表示文本中的代码词汇、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 账号。例如：“该文档包括两个主要部分：一个是 Parameters 部分，其中包含文档要执行的操作列表，接着是 mainSteps 部分，指定文档要执行的操作，在此案例中为 aws:configurePackage。在此情况下，当文档被调用时，系统将提示用户从下拉列表中选择 apache2、mysql-server或 php，并可以选择软件版本号。”

代码块格式如下：

{ 
    "Effect": "Allow", 
    "Action": [ 
      "ec2messages:AcknowledgeMessage", 
      "ec2messages:DeleteMessage", 
      "ec2messages:FailMessage", 
      "ec2messages:GetEndpoint", 
      "ec2messages:GetMessages", 
      "ec2messages:SendReply" 
    ], 
    "Resource": "*" 
}, 

当我们希望引起您注意某个代码块的特定部分时，相关行或项目会用粗体显示：

{ 
    "Effect": "Allow", 
    "Action": [ 
      "ec2messages:AcknowledgeMessage", 
      "ec2messages:DeleteMessage", 
      "ec2messages:FailMessage", 
      "ec2messages:GetEndpoint", 
      "ec2messages:GetMessages", 
      "ec2messages:SendReply" 
    ], 
    "Resource": "*" 
}, 

所有命令行输入或输出如下所示：

# wget https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_amd64/amazon-ssm-agent.deb

粗体：表示一个新术语、一个重要的词汇，或是你在屏幕上看到的词汇。例如，菜单或对话框中的词汇会以这种形式出现在文本中。这里有一个例子：“在 Create Role 向导中，从 AWS 服务角色类型中选择 EC2 选项，如下图所示。接下来，选择 EC2 作为此活动的用例，然后点击 Next: Permissions 按钮继续。”

警告或重要注意事项如下所示。

小贴士如下所示。

联系我们

我们始终欢迎读者的反馈。

一般反馈：请通过电子邮件发送至feedback@packtpub.com，并在邮件主题中提及书籍标题。如果您对本书的任何方面有疑问，请通过questions@packtpub.com联系我们。

勘误：虽然我们已尽一切努力确保内容的准确性，但错误难免。如果您在本书中发现任何错误，我们将非常感激您向我们报告。请访问 www.packtpub.com/submit-errata，选择您的书籍，点击“勘误提交表单”链接并输入相关信息。

盗版：如果您在互联网上遇到我们作品的任何非法复制品，恳请您提供相关位置地址或网站名称。请通过copyright@packtpub.com与我们联系，并附上相关链接。

如果您有兴趣成为作者：如果您在某个领域拥有专业知识，并且有兴趣撰写或参与书籍的创作，请访问 authors.packtpub.com。

书评

请留下评价。一旦您阅读并使用了本书，为什么不在您购买书籍的网站上留下评价呢？潜在读者可以看到并参考您的公正意见来做出购买决策，我们在 Packt 可以了解您对我们产品的看法，我们的作者也能看到您对其书籍的反馈。谢谢！

如需了解更多关于 Packt 的信息，请访问 packtpub.com。

第一章：AWS 有什么新变化？

在信息技术行业工作多年后，你会看到许多新技术、产品和平台的出现，它们开始发展，逐渐成熟，最终被更快、更好的技术所取代！我想在某些方面，这个概念也适用于这本书。当我在 2016 年首次开始撰写这本系列的第一版时，我认为这将是技术的巅峰，任何东西都无法取代它！而现在，我正做着完全相反的事情！撰写第二版只是一个小小的证明，证明一切都会随着时间的推移而发展！看看 AWS，你就能看到平台在过去几年中发生了多么巨大的变化和成长！

我还记得 2009 年我第一次开始探索 AWS 的时候，那时 EC2 和 CloudFront 仍处于早期阶段，仍在为它们添加新功能，SimpleDB 和 VPC 刚刚开始成形，等等；真正让我感到惊讶的是平台今天已经发展到如此地步！AWS 提供了 50 多种不同的解决方案和服务，涵盖了从大数据分析、无服务器计算，到数据仓库和 ETL 解决方案、数字工作空间和代码开发服务，AWS 应有尽有！这也是我一直是其忠实粉丝的原因之一！它不仅仅关乎收入和客户数量，更关乎如何适应和发展以应对不断变化的时代和需求。

所以，我们又回来了！一本新书，里面有许多新的内容等待我们学习和探索！但在我们深入研究一些非常有趣且强大的服务之前，让我们先回顾一下过去一年里 AWS 发生了什么变化，以及在第一版中我们探讨的那些服务今天是如何发展的！

本章将涵盖以下主题：

• 现有 AWS 服务的改进。

• 简要介绍新推出的 AWS 服务及其用途。

• 进攻计划！我们将如何推进本书的学习。

现有服务的改进

在第一版《AWS 管理 - 权威指南》中涵盖的服务中，有很多改进。在本节中，我们将重点介绍这些重要的改进，并理解它们的用途。首先，让我们看看过去一两年中 EC2 的关键增强功能。

弹性计算云

弹性计算云（EC2）迄今为止是 AWS 中运行时间最长的服务之一，然而，它仍然在不断发展，随着时间的推移添加新的功能。这里提到了一些值得注意的功能改进和新增内容：

• t2.xlarge 和 t2.2xlarge 实例的介绍：t2 工作负载是一种特殊类型的工作负载，因为它提供低成本的可突发计算，适合运行不需要持续使用 CPU 的通用应用程序，如 Web 服务器、应用服务器、LOB 应用、开发等。t2.xlarge 和 t2.2xlarge 实例类型分别提供 16 GB 内存和 4 vCPU，以及 32 GB 内存和 8 vCPU。

• I3 实例家族的介绍：虽然 EC2 提供了一个全面的实例家族集合，但对于专门优化存储的实例家族的需求日益增加，这些实例非常适合运行诸如关系数据库或 NoSQL 数据库、分析工作负载、数据仓库、Elasticsearch 应用等工作负载。于是，I3 实例应运而生！I3 实例使用基于非易失性内存快速接口（NVMe）SSD 运行，能够提供极为优化的高 I/O 操作。最大资源容量为 64 vCPU、488 GB 内存和 15.2 TB 本地附加 SSD 存储。

这并不是一个详尽无遗的列表。如果你想了解 AWS 带来的更多变化，可以查看这个链接：aws.amazon.com/about-aws/whats-new/2016/。

FPGA 和 GPU 的可用性

采用公共云的客户的一个关键用例是高端处理单元的可用性，这些处理单元是运行高性能计算（HPC）应用所需的。去年新增的一种实例类型是 F1 实例，它配备了现场可编程门阵列（FPGA），你可以编程来为应用程序创建自定义硬件加速。另一项加入 EC2 实例家族的令人兴奋的特性是引入了弹性 GPU 概念。这使你可以以显著更低的成本为应用程序提供图形加速支持，同时提高性能。弹性 GPU 非常适合需要少量 GPU 来进行图形加速，或者有一些应用程序可能从某些 GPU 中受益，但同时还需要大量计算、内存或存储的场景。

简单存储服务

与 EC2 类似，简单存储服务（S3）也增加了许多新特性和支持。以下是一些说明：

• S3 对象标签：S3 对象标签类似于 AWS 提供的其他标签机制，通常用于管理和控制对 S3 资源的访问。标签是简单的键值对，你可以用它们为 S3 资源创建和关联 IAM 策略，设置 S3 生命周期策略，并管理对象在不同存储类别之间的转换。

• S3 清单：S3 清单是一个特别功能，专门用于目录化各种对象，并将其提供为可用于进一步分析和盘点的 CSV 文件。通过 S3 清单，您现在可以每天或每周提取存储桶中所有对象及其元数据的列表。

• S3 分析：AWS 在 S3 上投入了大量的工作和努力，使其不仅仅是另一个无限可扩展的存储解决方案。S3 分析为最终用户提供了分析存储访问模式的手段，并根据这些分析结果定义合适的存储类别。您只需设置一个存储类别分析策略（无论是针对对象、前缀还是整个存储桶），即可启用此功能。启用后，该策略将监控存储访问模式，并在 AWS 管理控制台中提供您的存储使用情况的每日可视化报告。您甚至可以将这些结果导出到 S3 存储桶，以便使用您选择的其他商业智能工具（如 Amazon QuickSight）进行进一步分析。

• S3 CloudWatch 指标：这一功能终于来了！您现在可以利用 13 个专为您的 S3 存储桶对象设计的全新 CloudWatch 指标。您可以接收每分钟的 CloudWatch 指标，设置 CloudWatch 告警，并访问 CloudWatch 仪表盘，以查看 S3 资源的实时操作和性能，如已下载的总字节数、4xx HTTP 响应计数等。

• 全新 仪表盘：尽管 AWS 管理控制台的仪表盘和结构时常变化，但我最喜欢的还是全新的 S3 仪表盘。对象标签和存储分析策略功能现已通过新的 S3 仪表盘提供，此外，还有其他令人印象深刻且备受期待的功能，例如使用关键字搜索存储桶，以及在创建新存储桶时，能够从现有存储桶复制存储桶属性，如下图所示：

• Amazon S3 传输加速：此功能允许您以非常快速的速度将大量工作负载跨地域迁移到 S3。它通过将 Amazon CloudFront 终端与 S3 配合使用，实现了数据上传速度最高可达 300 倍，无需担心任何防火墙规则或前期费用。

虚拟私有云

与其他服务类似，虚拟私有云（VPC）在过去几年中增加了许多新功能；这里突出了其中一些重要的功能：

• 对 IPv6 的支持：随着信息技术行业和互联网的指数级增长，VPC 也开始支持 IPv6 只不过是时间问题。今天，IPv6 已经在所有 AWS 区域扩展并可用，甚至与 EC2 和 S3 等服务兼容。为你的应用程序和实例启用 IPv6 是一个非常简单的过程。你需要做的就是在 VPC 创建向导中启用 IPv6 CIDR 块选项，如下所示：

每个启用 IPv6 的 VPC 都会有一个 /56 地址前缀，而在该 VPC 中创建的单独子网支持 /64 CIDR 块。

• VPC 对等连接的 DNS 解析：启用 VPC 对等连接的 DNS 解析后，当从任何对等的 VPC 查询时，你现在可以将公共 DNS 主机名解析为私有 IP 地址。这实际上简化了 VPC 的 DNS 配置，并使你的网络环境能够无缝地扩展到云端。

• DynamoDB 的 VPC 终端节点：今年晚些时候，将为 VPC 提供的另一个令人惊叹的功能是支持 DynamoDB 表的终端节点。为什么这突然变得如此重要？首先，如果你使用 DynamoDB 终端节点，你就不需要为你的 VPC 附加互联网网关或 NAT 实例。这实际上节省了成本，并使得应用程序与数据库之间的流量保持在 AWS 内部网络内，而不像以前那样流量必须绕过互联网才能到达 DynamoDB 实例。其次，DynamoDB 的终端节点几乎消除了需要维护复杂防火墙规则来保护 VPC 的需求。第三，也是最重要的，它是免费的！

CloudWatch

CloudWatch 与几年前它作为服务首次推出时相比，已经经历了许多新的令人兴奋的变化和功能新增。下面是一些最新公告的快速概览：

• CloudWatch 事件：CloudWatch 新增的最受期待和最有用的功能之一就是 CloudWatch 事件！事件是一种让你能够几乎实时响应 AWS 环境中变化的方式。通过配置事件规则，并在触发特定事件时执行相应的操作步骤，这使得这一切成为可能。例如，设计一个简单的备份或清理脚本，在实例每天结束时关闭时被调用，等等。你也可以选择将事件规则安排在一天、一周、一个月甚至一年中的特定时间间隔触发！这真是太棒了！

• 高分辨率自定义指标：我们都曾感受到需要实时监控在 AWS 上运行的应用程序和资源的需求，然而，最小的可配置监控间隔为 10 秒，这一直是一个挑战。但现在不再是这样了！随着高分辨率自定义指标的引入，您现在可以将监控精确到 1 秒的分辨率！所有这一切的最佳部分是，标准警报和高分辨率警报的配置和使用之间没有特殊区别。两者都可以执行完全相同的功能，然而，后者比前者要快得多。

• CloudWatch 仪表板小部件：许多用户在将 CloudWatch 作为其集中式监控解决方案时遇到了问题，原因在于它无法创建自定义仪表板。但这一切现在已经改变，今天的 CloudWatch 支持根据应用程序的需求创建高度可自定义的仪表板。它还支持开箱即用的小部件，如 数字 小部件，它提供了被监控指标的最新数据点的视图，例如被监控的 EC2 实例数量，或者 堆叠图，它提供了个别指标及其对整体影响的便捷可视化。

弹性负载均衡器

在过去一年中，ELB 最重要和最有用的新增功能之一就是应用程序负载均衡器的引入。与前身 ELB 不同，应用程序负载均衡器是严格的第 7 层（应用层）负载均衡器，旨在支持基于内容的路由以及运行在容器上的应用程序。ALB 还旨在提供目标 EC2 实例和容器健康状态的额外可视化。理想情况下，这些 ALB 将用于在一组容器中动态地平衡负载，这些容器运行着可扩展的 Web 和移动应用程序。

与 AWS 在过去一年中所增加的各种服务和功能相比，这只是冰山一角！让我们快速浏览一下本书中将涵盖的各种服务。

新服务介绍

《AWS 管理 - 权威指南》第一版涵盖了许多核心的 AWS 服务，如 EC2、EBS、自动扩展、ELB、RDS、S3 等等。在本版中，我们将以不同的方式来探索和学习，通过探索许多与核心服务协同工作的服务和功能：

• EC2 系统管理器：EC2 系统管理器是一项基本上为管理你的计算基础设施提供许多附加功能的服务。每个由 EC2 系统管理器管理的计算实体被称为受管实例，它可以是一个 EC2 实例或一台本地机器！EC2 系统管理器提供开箱即用的功能，创建并基准化操作系统的补丁、自动创建 AMI、运行配置脚本等更多功能！

• Elastic Beanstalk：Beanstalk 是一项强大而简便的服务，旨在帮助开发者轻松部署和扩展他们的 web 应用程序。目前，Beanstalk 支持使用 Java、.NET、PHP、Node.js、Python、Ruby 和 Go 开发的 web 应用程序。开发者只需设计并上传他们的代码到 Beanstalk，后者会自动处理应用程序的负载均衡、自动扩展、监控等功能。在写作时，Elastic Beanstalk 支持通过 Docker 容器或直接通过 EC2 实例部署应用程序，而使用该服务的最佳部分是它完全免费！你只需为所消费的底层 AWS 资源付费。

• 弹性文件系统：定义 弹性文件系统 或 EFS 最简单的方法是把它看作是一个超强版的 NFS 共享！EFS 提供简单且高度可扩展的文件存储服务，旨在与 EC2 实例一起使用。你可以让多个 EC2 实例连接到单个 EFS 挂载点，从而为你的应用程序和工作负载提供一个公共的数据存储。

• WAF 和 Shield：在本书中，我们将探索一些提供安全性和合规性服务的服务，这些服务为你的标准 VPC 提供额外的安全层。我们将学习的其中两个服务是 WAF 和 Shield。WAF，或称 Web 应用防火墙，旨在保护你的应用程序免受可能影响其可用性和安全性的 web 漏洞攻击。通过使用 WAF，你可以创建自定义规则，以防止你的 web 应用程序受到常见攻击模式的侵害，例如 SQL 注入、跨站脚本等。

类似于 WAF，Shield 也是一项托管服务，提供防御 DDoS 攻击的功能，保护你的网页或 web 应用程序免受攻击：

• CloudTrail 和 Config：CloudTrail 是我们将在接下来的章节中学习的另一个服务。它旨在记录和监控你的 AWS 账户和基础设施活动。当你需要确保你的 AWS 账户符合合规性、审计和标准时，这项服务非常有用，并可以采取必要的措施来缓解这些问题。另一方面，Config 提供了一套非常相似的功能，但它专注于评估和审计 AWS 资源的配置。两项服务被同义使用，以提供合规性和治理，帮助进行操作分析、故障排除以及满足安全需求。

• Cognito：Cognito 是一个非常棒的服务，可以简化你为网站甚至移动应用创建注册页面的过程。你还可以选择集成社交身份提供商，如 Facebook、Twitter 和 Amazon，使用 SAML 身份解决方案。

• CodeCommit、CodeBuild 和 CodeDeploy：AWS 为开发人员提供了一套非常丰富的工具和服务，旨在快速且安全地交付软件。这些工具的核心包括 CodeCommit、CodeBuild 和 CodeDeploy 三个服务，我们将在本书中学习和探索它们。正如名字所示，这些服务为你提供了安全存储和版本控制应用程序源代码的能力，同时还能自动构建、测试并将你的应用程序部署到 AWS 或本地环境。

• SQS 和 SNS：SQS，即 简单队列服务，是 AWS 提供的完全托管的队列服务，旨在解耦基于微服务或分布式应用程序的架构。你甚至可以使用 SQS 在不同的应用程序之间发送、存储和接收消息，并且无需管理任何基础设施，同时还能处理高流量。SNS 是一个 简单通知服务，主要用作发布/订阅消息服务或通知服务。你还可以利用 SNS 触发其他 AWS 服务的自定义事件，例如 EC2、S3 和 CloudWatch。

• EMR：弹性 MapReduce 是一个托管的 Hadoop 即服务，提供一个基于 EC2 实例的集群平台，用于运行 Apache Hadoop 和 Apache Spark 框架。EMR 非常适用于处理大量数据，并用于将大量数据从一个 AWS 数据源转换和迁移到另一个数据源。EMR 还提供了高度的灵活性和可扩展性，你可以根据当前处理的数据量调整集群的大小。此外，它还设计为可以与其他 AWS 服务无缝集成，如 S3 用于存储数据，CloudWatch 用于监控集群，CloudTrail 用于审核请求等。

• Redshift：Redshift 是一个云中的千兆字节级别托管数据仓库服务。与其对应的 EMR 类似，Redshift 也基于集群化的 EC2 实例工作，在这些实例上，你可以上传大型数据集并执行分析查询。

• 数据管道：数据管道是一个托管服务，使用户能够处理和迁移数据集，从一个 AWS 服务迁移到另一个服务，甚至从本地数据存储迁移到 AWS 存储服务，如 RDS、S3、DynamoDB，甚至 EMR！你可以调度数据迁移任务，跟踪依赖关系和错误，甚至编写并创建前置条件和活动，定义数据管道对数据采取的操作，比如将数据运行通过 EMR 集群，执行 SQL 查询等。

• IoT 和 Greengrass： AWS IoT 和 Greengrass 是两个非常强大的服务，旨在收集和聚合各种设备传感器数据，并将这些数据流式传输到 AWS 云中进行处理和分析。AWS IoT 提供了一个可扩展且安全的平台，借助该平台，您可以将数十亿的传感器设备连接到云或其他 AWS 服务，并利用它们收集、处理和分析数据，而无需担心底层基础设施或可扩展性需求。Greengrass 是 AWS IoT 平台的扩展，基本上提供了一种机制，允许您在传感器设备上直接运行和管理数据预处理作业。

这些服务完成后，让我们快速看一下如何计划推进本书其余章节的内容！

攻略计划！

就像上一版一样，我们将为本书制定一个简单的攻击计划！所谓攻击计划，我只是指我如何规划章节内容的结构并将它们整合在一起！在本书的大部分内容中，我们将专注于一个简单的用例，比如使用 Elastic Beanstalk、Elastic File System、WAF 和 Shield、EMR、Redshift 等一些非常酷的服务在 AWS 上托管 WordPress 应用程序，等等！以下是我们目标在书末实现的简单展示：

以下是下一些章节的大致结构：

1. 我们将通过首先在 EC2 实例上手动托管 WordPress，作为独立安装，然后学习如何借助 EC2 Systems Manager 实用工具管理这些实例，开始设置我们的 WordPress。

2. 完成此步骤后，我们将使用 Elastic Beanstalk 和 Elastic File System 的组合来托管相同的 WordPress，并对高可用性和可扩展性有更多的控制，同时在此过程中学习这两项服务的内部工作原理及其用例。

3. 既然站点已经托管，我们将通过利用 WAF 和 Shield 以及启用 CloudTrail 和 Config 等治理功能，为其增加一层安全保护。

4. 稍后我们还将学习如何利用 AWS 提供的代码开发服务，分别是 CodeCommit、CodeBuild 和 CodeDeploy，来创建一个有效的 CICD 流水线，以便将更新推送到我们的网站。

5. 最后，我们还将执行一些对站点至关重要的日志分析，使用 Elastic MapReduce 和 Redshift，并学习如何使用 Data Pipeline 备份我们站点的数据。

6. 但这还不是全部！正如前面提到的，我们还将学习一些额外的服务，形式包括 IAM 和 AWS Cognito 服务，用于身份验证和安全性，以及 AWS IoT 和 AWS Greengrass。

总结

让我们快速总结一下到目前为止在本章中学到的内容！我们首先快速回顾了过去几年内核心 AWS 服务中包含的一些关键功能和新增内容。不过，请记住，这绝不是一个完整的列表！还有很多内容需要覆盖和学习，但为了简便起见，我会将这些内容留给大家自行阅读。之后，我们还浏览并了解了将会在这系列AWS 管理 - 权威指南中包含的服务。最后，我们通过利用一个简单的 WordPress 应用程序作为我们部署和用例的焦点，展示了我们将如何构建接下来的章节！

在下一章中，我们将首先在 EC2 实例上部署我们的简单 WordPress 应用程序，然后结合 EC2 系统管理器及其附加服务来管理和跟踪 EC2 实例的系统配置，所以请继续关注！我们才刚刚开始！

第二章：使用 Systems Manager 管理 EC2

EC2 实例一直是 AWS 提供的核心服务，EC2 也在不断发展，每年都会添加新的功能和实例类型。AWS re:Invent 2016 中新增的一项非常酷的服务就是 EC2 Systems Manager！

在本章中，我们将深入学习 EC2 Systems Manager 及其相关子服务；具体包括：

• 运行命令：允许你直接在启用 EC2 Systems Manager 的 EC2 实例上执行命令的服务

• 状态管理器：允许你为启用 EC2 Systems Manager 的 EC2 实例指定期望的状态

• 补丁管理：为管理员提供管理 EC2 实例上补丁部署的能力

• 自动化：允许管理员自动化某些任务的部署

• 清单：从管理的 EC2 实例收集和管理软件清单的服务

听起来很激动人心吧？那我们还在等什么呢？开始吧！

介绍 EC2 Systems Manager

正如名字所示，EC2 Systems Manager 是一项管理服务，它为管理员和最终用户提供了一套丰富的任务执行功能，涵盖了管理 EC2 实例集群的多个方面，比如定期为实例打补丁、跟踪实例的配置状态、确保实例符合状态模板、通过一个工具执行脚本和命令到你的实例集群，等等！EC2 Systems Manager 还特别设计用于帮助管理员管理混合计算环境，所有这些都可以通过 EC2 Systems Manager 仪表板进行管理。它高效且具成本效益，因为它不需要专门的软件或第三方服务来管理你的混合环境，这些服务往往昂贵！

那么 AWS 是如何实现这些功能的呢？一切都始于“托管实例”的概念。托管实例是由 EC2 Systems Manager 服务管理和控制的特殊 EC2 实例。每个托管实例都包含一个 Systems Manager（SSM）代理，该代理负责与 Systems Manager 工具进行通信并配置实例状态。Windows Server 2003–2012 R2 AMI，Windows Server 2003–2012 R2 AMI 将自动安装 SSM 代理。然而，Linux 实例默认情况下并不安装 SSM 代理。让我们快速看看如何安装该代理，并将我们的第一个开发实例设置为 AWS 中的托管实例。

开始使用 SSM 代理

在本节中，我们将安装并配置一个新的 Linux 实例上的 SSM 代理，我们将其称为开发实例，然后通过将代理的日志文件流式传输到 Amazon CloudWatch Logs 来验证它的工作情况。让我们开始吧！

配置 IAM 角色和策略以支持 SSM

首先，我们需要为我们的 EC2 系统管理器创建并配置 IAM 角色，以便其处理和执行对 EC2 实例的命令。你可以使用系统管理器提供的托管策略，或者选择创建你自己的自定义角色，并为其分配特定权限。对于这一部分，我们将创建一个自定义角色和策略。

开始时，我们首先为系统管理器托管的实例创建一个自定义 IAM 策略：

1. 登录到你的 AWS 账户并选择主仪表盘中的 IAM 选项，或者打开 console.aws.amazon.com/iam/ 以访问 IAM 控制台。

2. 接下来，从导航窗格中选择“策略”。这将显示当前 AWS 默认提供和支持的现有策略列表。

3. 在策略筛选器中输入SSM，以查看当前为 SSM 提供的策略列表。

4. 选择 AmazonEC2RoleforSSM 策略，并复制其内容以形成新的策略文档。以下是该策略文档的一个片段供参考：

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "ssm:DescribeAssociation", 
                  ..... SSM actions list  
            ], 
            "Resource": "*" 
        }, 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "ec2messages:AcknowledgeMessage", 
                "ec2messages:DeleteMessage", 
                "ec2messages:FailMessage", 
                "ec2messages:GetEndpoint", 
                "ec2messages:GetMessages", 
                "ec2messages:SendReply" 
            ], 
            "Resource": "*" 
        }, 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "cloudwatch:PutMetricData" 
            ], 
            "Resource": "*" 
        }, 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "ec2:DescribeInstanceStatus" 
            ], 
            "Resource": "*" 
        }, 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "ds:CreateComputer", 
                "ds:DescribeDirectories" 
            ], 
            "Resource": "*" 
        }, 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "logs:CreateLogGroup", 
                "logs:CreateLogStream", 
                ..... CloudWatch Log actions 
            ], 
            "Resource": "*" 
        }, 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "s3:PutObject", 
                "s3:GetObject", 
                "s3:AbortMultipartUpload", 
                "s3:ListMultipartUploadParts", 
                "s3:ListBucketMultipartUploads" 
            ], 
            "Resource": "*" 
        }, 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "s3:ListBucket" 
            ], 
            "Resource": "arn:aws:s3:::amazon-ssm-packages-*" 
        } 
    ] 
} 

1. 一旦策略被复制，返回到策略仪表盘，点击“创建策略”选项。在创建策略向导中，选择“创建您自己的策略”选项。

2. 提供合适的策略名称，并将复制的 AmazonEC2RoleforSSM 策略内容粘贴到策略文档部分。你现在可以根据自己的需求调整策略，但完成后，记得选择“验证策略”选项，以确保策略在语法上是正确的。

3. 完成后，选择“创建策略”以完成该过程。

完成此步骤后，你现在拥有一个自定义的 IAM 策略，用于管理系统管理器托管的实例。

下一个重要的策略是我们需要为系统管理器创建的自定义 IAM 用户策略。该策略将明确哪些特定用户可以查看系统管理器文档，并使用系统管理器的 API 对选定的受管实例执行操作：

1. 再次登录到你的 AWS IAM 仪表盘，选择“策略”选项，正如之前的步骤所做。

2. 在策略筛选器中再次输入SSM，然后选择 AmazonSSMFullAccess 策略。复制其内容，并将以下代码粘贴到新策略的策略文档部分，以创建一个自定义的 SSM 访问策略：

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "cloudwatch:PutMetricData", 
                "ds:CreateComputer", 
                "ds:DescribeDirectories", 
                "ec2:DescribeInstanceStatus", 
                "logs:*", 
                "ssm:*", 
                "ec2messages:*" 
            ], 
            "Resource": "*" 
        } 
    ] 
} 

1. 在完成创建过程之前，记得验证策略。你现在应该有两个自定义策略，如下图所示：

创建好策略后，我们接下来只需要创建一个新的实例配置文件角色，将完全访问策略附加到新角色，并最终验证系统管理器与新创建角色之间的信任关系：

1. 要创建一个新角色，从 IAM 管理仪表盘中选择“角色”选项。

2. 在“创建角色”向导中，从 AWS 服务角色类型中选择 EC2 选项，如下图所示。接下来，选择 EC2 作为本次活动的使用场景，然后点击“下一步：权限”按钮继续：

1. 在“附加权限策略”页面中，筛选并选择我们在本练习开始时创建的 ssm-managedInstances 策略。完成后点击“审核”。

2. 最后，在“审核”页面提供一个合适的角色名称，然后点击“创建角色”以完成整个过程！

配置好角色后，我们需要验证实例配置文件角色的 IAM 策略是否包含ssm.amazonaws.com作为受信实体：

1. 为了验证这一点，选择 IAM 角色页面中新创建的角色，然后点击“信任关系”选项卡。

2. 在这里，选择“编辑信任关系”选项，并在策略编辑器中粘贴以下代码片段，如所示。记得将EC2 和 SSM都添加为受信服务，而不是仅仅添加其中一个：

{ 
  "Version": "2012-10-17", 
  "Statement": [ 
    { 
      "Sid": "", 
      "Effect": "Allow", 
      "Principal": { 
        "Service": [ 
          "ec2.amazonaws.com", 
          "ssm.amazonaws.com" 
        ] 
      }, 
      "Action": "sts:AssumeRole" 
    } 
  ] 
} 

1. 配置好新的信任策略后，点击“更新信任策略”以完成此过程。恭喜！

2. 配置 Systems Manager 几乎完成！剩下最后一步，我们需要将之前创建的第二个策略（SSM 完全访问权限）附加到我们的一个 IAM 用户上。在这种情况下，我已将该策略附加到我 AWS 环境中现有的一个用户上，然而，你也可以创建一个完全新的用户，专门用于 Systems Manager，并将其分配 SSM 访问策略。

策略配置完毕后，我们可以继续在我们的简单开发实例上安装和配置 SSM 代理。

安装 SSM 代理

正如在本章开始时讨论的，Systems Manager 或 SSM 代理是一个至关重要的软件，需要在 EC2 实例上安装和配置，才能让 Systems Manager 管理它。写本文时，SSM 代理支持以下操作系统：

• Windows：

  • Windows Server 2003（包括 R2）

  • Windows Server 2008（包括 R2）

  • Windows Server 2012（包括 R2）

  • Windows Server 2016

• Linux（64 位和 32 位）：

  • Amazon Linux 2014.09、2014.03 或更高版本

  • Ubuntu Server 16.04 LTS、14.04 LTS 或 12.04 LTS

  • Red Hat Enterprise Linux（RHEL）6.5 或更高版本

  • CentOS 6.3 或更高版本

• Linux（仅限 64 位）：

  • Amazon Linux 2015.09、2015.03 或更高版本

  • Red Hat Enterprise Linux 7.x 或更高版本

  • CentOS 7.1 或更高版本

  • SUSE Linux Enterprise Server 12 或更高版本

若要在一个全新的实例上安装代理，例如我们稍后将创建的实例，你只需确保该实例提供了我们在上一节中创建的必要 SSM IAM 角色，并在实例配置的用户数据部分提供以下代码片段：

#!/bin/bash 
cd /tmp                
wget https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_amd64/amazon-ssm-agent.deb 
sudo dpkg -i amazon-ssm-agent.deb 
sudo start amazon-ssm-agent 

用户数据脚本在不同操作系统之间有所不同。在我的情况下，脚本旨在 Ubuntu Server 14.04 LTS (HVM) 实例上运行。你可以在 docs.aws.amazon.com/systems-manager/latest/userguide/sysman-install-ssm-agent.html#sysman-install-startup-linux 检查你的 SSM 代理安装脚本。

实例启动并运行后，通过 SSH 登录实例并使用以下命令验证你的 SSM 代理是否正在运行。记住，以下命令会根据你在启动时选择的操作系统有所不同：

# sudo status amazon-ssm-agent 

你应该能看到代理正在运行，如下图所示：

你还可以选择通过完成以下一组命令，在已运行的 EC2 实例上安装代理。

对于运行 Ubuntu 16.04 LTS 操作系统的实例，我们首先创建一个临时目录，用于存放 SSM 代理安装程序：

# mkdir /tmp/ssm 

接下来，使用 wget 工具下载特定操作系统的 SSM 代理安装程序：

# wget https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_amd64/amazon-ssm-agent.deb 

最后，使用以下命令执行安装程序：

# sudo dpkg -i amazon-ssm-agent.deb 

你还可以通过查看以下日志文件之一来验证代理的执行情况：

# sudo tail -f /var/log/amazon/ssm/amazon-ssm-agent.log  
# sudo tail -f /var/log/amazon/ssm/errors.log 

配置 SSM 代理将日志流式传输到 CloudWatch

这是 SSM 代理提供的一个特别有用的选项，特别是在你不想登录到每个实例并排除故障时。将 SSM 代理的日志与 CloudWatch 集成，使你能够将所有日志捕获并集中分析，这无疑节省了大量时间，而且它还带来额外的好处，例如配置警报、使用 CloudWatch 仪表盘查看各种指标，并将日志保留更长时间。

但是，在我们配置代理之前，我们首先需要在 CloudWatch 中创建一个单独的日志组，用于从各个实例流式传输代理日志：

1. 要做到这一点，首先在 AWS 管理控制台中选择 CloudWatch 选项，或者点击以下链接从 console.aws.amazon.com/cloudwatch/ 打开 CloudWatch 仪表盘。

2. 接下来，从导航窗格中选择日志（Logs）选项。在这里，点击创建日志组（Create log group），并为你的日志组提供一个合适的名称，如下图所示：

1. 完成后，使用 SSH 登录回你的开发实例，并运行以下命令：

# sudo cp /etc/amazon/ssm/seelog.xml.template /etc/amazon/ssm/seelog.xml 

1. 接下来，使用你喜欢的编辑器打开刚刚复制的文件，并将以下内容粘贴到其中。记得将 <CLOUDWATCH_LOG_GROUP_NAME> 字段替换为你自己的日志组名称：

# sudo vi /etc/amazon/ssm/seelog.xml 
<seelog minlevel="info" critmsgcount="500" maxinterval="100000000" 
 mininterval="2000000" type="adaptive"> 
 <exceptions> 
 <exception minlevel="error" filepattern="test*"/> 
 </exceptions> 
 <outputs formatid="fmtinfo"> 
 <console formatid="fmtinfo"/> 
 <rollingfile type="size" maxrolls="5" maxsize="30000000" 
 filename="{{LOCALAPPDATA}}\Amazon\SSM\Logs\amazon-ssm-agent.log"/> 
 <filter formatid="fmterror" levels="error,critical"> 
 <rollingfile type="size" maxrolls="5" maxsize="10000000" 
 filename="{{LOCALAPPDATA}}\Amazon\SSM\Logs\errors.log"/> 
 </filter> 
 <custom name="cloudwatch_receiver" formatid="fmtdebug" data-log-group="<CLOUDWATCH_LOG_GROUP_NAME>"/> 
 </outputs> 
CODE: 

1. 完成更改后，保存并退出编辑器。现在，通过 CloudWatch 仪表板查看您新创建的日志组；您应该能看到 SSM 代理的错误日志（如果有的话），以便轻松进行故障排除。

完成此步骤后，我们已经成功将 EC2 实例安装并配置为 Systems Manager 中的受管实例。要验证您的实例是否已成功添加，请在 EC2 仪表板的导航窗格中选择“Systems Manager 共享资源”部分下提供的“受管实例”选项；您应该能看到列出的实例，如下所示：

在下一节中，我们将深入探讨作为 Systems Manager 一部分提供的各种功能，首先介绍最广泛使用的一个：Run Command！

介绍 Run Command

Run Command 是 Systems Manager 的一个强大功能，基本上允许您在受管理的 EC2 实例队列中执行远程命令。您可以执行各种自动化管理任务，例如安装软件或修补操作系统、执行 Shell 命令、管理本地组和用户等！但这还不是全部！使用这个功能的最大优点是，它允许您在执行脚本时拥有无缝体验，即使是在您的本地 Windows 和 Linux 操作系统上，无论它们运行在 VMware ESXi、Microsoft Hyper-V 还是其他平台上。而且所有这些功能的成本？完全免费！您只需为创建的 EC2 实例和其他 AWS 资源付费，其它费用全免！

以下是由 Run Command 提供的一些常用预定义命令的简要列表，并附有简短描述：

• AWS-RunShellScript：在远程 Linux 实例上执行 Shell 脚本

• AWS-UpdateSSMAgent：用于更新 Amazon SSM 代理

• AWS-JoinDirectoryServiceDomain：用于将实例加入 AWS 目录

• AWS-RunPowerShellScript：在 Windows 实例上执行 PowerShell 命令或脚本

• AWS-UpdateEC2Config：运行 EC2Config 服务的更新

• AWS-ConfigureWindowsUpdate：用于配置 Windows Update 设置

• AWS-InstallApplication：用于在 Windows 实例上使用 MSI 包安装、修复或卸载软件

• AWS-ConfigureCloudWatch：配置 Amazon CloudWatch Logs 以监控应用程序和系统

在我们继续执行 Run Command 之前，重要的是要记住，Run Command 需要 SSM 代理以及正确的权限和角色集才能正常工作。因此，如果您还没有安装 SSM 代理或配置 IAM 策略和角色，现在是重新审视这些步骤的好时机！

在本节中，我们将看一下如何简单地执行一组命令来管理我们新添加的受管实例：

1. 首先，登录到 AWS 管理控制台并从主仪表盘选择 EC2 服务。或者，你也可以通过console.aws.amazon.com/ec2/直接进入 EC2 仪表盘。

2. 接下来，从导航窗格中选择“运行命令”选项，进入系统管理服务部分。你将被带到“运行命令”仪表盘，在这里你需要选择“运行命令”选项来开始。

3. 在“运行命令”页面，首先需要选择一个我们可以操作的命令文档。命令文档基本上是关于你想在托管实例上运行的命令的声明或信息集。在此场景中，我们将首先选择AWS-RunShellScript命令文档。

4. 在接下来的“选择目标”部分，你可以选择是否手动执行命令文档，通过选择单个实例，或者指定通过其标签名称标识的特定实例组。

5. “执行条件”选项让你可以选择要在其上执行命令文档的目标实例或实例百分比。选择“目标”允许你指定允许执行命令文档的确切实例数量。执行将在每个实例上依次进行。或者，如果你选择“百分比”选项，则可以提供一个实例的百分比值，指示在单次操作中应允许多少实例执行该命令。

6. 你可以选择设置“在发生 x 个错误后停止”选项，以便在实例遇到错误时中止命令文档的执行。

7. 最后，你可以在“命令”部分粘贴你的执行代码或 Shell 脚本，如下图所示。在这种情况下，我们运行一个简单的脚本，该脚本将安装并配置 Zabbix 监控代理，以便轻松监控我们的 EC2 资源：

你可以在www.zabbix.com/product了解更多关于 Zabbix 及其功能的信息。

1. 复制并粘贴以下代码片段，或者根据你为本次操作选择的 EC2 实例操作系统进行调整：

sudo wget http://repo.zabbix.com/zabbix/3.2/ubuntu/pool/main/z/zabbix-release/zabbix-release_3.4-1+xenial_all.deb 
sudo dpkg -i zabbix-release_3.4-1+xenial_all.deb 
sudo apt-get update -y 
sudo apt-get install zabbix-agent -y 

sudo bash -c "cat > /etc/zabbix/zabbix_agentd.conf <<EOF 
PidFile=/var/run/zabbix/zabbix_agentd.pid 
LogFile=/var/log/zabbix/zabbix_agentd.log 
LogFileSize=0 
Server=192.168.32.50 # Private IP of my Zabbix Server on EC2 
ServerActive=192.168.32.50 # Private IP of my Zabbix Server on EC2 
Include=/etc/zabbix/zabbix_agentd.d/*.conf 
EOF" 

sudo service zabbix-agent status 
sudo service zabbix-agent restart 

1. 其余的选项提供了其他配置项，例如设置一个可选的工作目录，以便在远程托管实例上执行命令。

此外，你还可以选择启用 SNS 通知，以及通过“高级选项”部分将命令输出日志写入 S3，如下所示：

1. 一旦配置项填写完毕，只需选择“运行”选项，开始执行您的命令文档。在此期间，系统管理器将对您提供的托管实例列表执行您提供的命令。如果执行过程中发生错误，系统管理器会停止执行并显示输出的状态，结果为成功或失败。

很简单，不是吗？您可以使用相同的机制，轻松且一致地远程管理和执行命令，针对您的 EC2 实例群组，甚至可以利用 AWS CLI 执行我们在本节中探讨的相同操作。

在接下来的章节中，我们将学习系统管理器提供的另一个非常有用的功能：状态管理器。

使用状态管理器

状态管理器 是一个强大的工具，帮助管理和治理托管系统的配置。例如，通过使用状态管理器，您可以为托管实例群组强制执行特定的防火墙规则，并将其设置为始终需要强制执行的要求状态。如果规则在状态管理器之外发生变化，它会自动恢复到与要求状态配置匹配的设置，从而维持合规性并在您的环境中执行标准化。

使用状态管理器非常简单直接。首先，您需要选择一个状态文档（基于 JSON），该文档指定了您需要配置或维护 EC2 实例的设置。这些文档是预定义的，您也可以创建自定义版本。创建文档后，您可以选择个别托管实例，这些实例可以是 EC2 实例或本地虚拟机，并指定应用这些状态的时间表，甚至可以指定应用的频率。就是这么简单！

但在继续调用状态管理器之前，让我们先更好地理解一下状态文档的概念，因为这些文档是支撑系统管理器工作的基础。

状态文档不过是简单的基于 JSON 的步骤和参数，定义了系统管理器需要执行的某些操作。AWS 提供了几十种这样的文档，可以用来执行各种任务，比如修补实例、配置某些软件包、配置 CloudWatch 日志代理等等！此外，您还可以创建自己的自定义文档！系统管理器支持三种类型的文档：

• 命令：命令文档通过运行命令来执行命令，这些命令可以作用于您的托管实例。或者，状态管理器也使用命令文档来应用某些策略。这些操作可以在实例生命周期的任何时刻对一个或多个目标执行。

• 策略：由状态管理器使用，策略文档用于在托管实例上强制执行某个策略。

• 自动化: 这些文档更经常被系统管理器内的自动化服务用来执行常见的维护和部署任务。我们将在本章稍后详细了解自动化文档。

要查看系统管理器的预定义文档，请从 EC2 仪表板的导航窗格中选择 Systems Manager 共享资源 部分下的 Documents 选项。在这里，您可以根据需要使用任何预定义文档来配置 State Manager，不过让我们快速创建一个非常简单的自定义文档，基于 aws:configurePackage 定义：

1. 要创建您自己的文档，请从 Documents 仪表板中选择 Create Document 选项，如下所示：

1. 在 Create Document 向导中，首先为您的文档提供一个合适的名称。在本例中，我已提供了名称 yoyodev-ssm-configure-packages。请注意，名称不能包含任何空格。

2. 接下来，从 Document Type 下拉菜单中选择 Command 作为选项类型，并在 Content 部分粘贴以下 JSON 代码，如下所示：

    {
          "schemaVersion": "2.0",
          "description": "Install or uninstall the latest version or specified version of LAMP stack.",
          "parameters": {
                "action": {
                      "description": "(Required) Specify whether or not to install or uninstall the package.",
                      "type": "String",
                      "allowedValues": [
                            "Install",
                            "Uninstall"
                      ]
                },
                "name": {
                      "description": "(Required) The LAMP package to install/uninstall.",
                      "type": "String",
                      "allowedValues": [
                            "apache2",
                            "mysql-server",
                            "php"
                      ]
                },
                "version": {
                      "description": "(Optional) A specific version of the package to install or uninstall.",
                      "type": "String",
                      "default": "",
                      "allowedPattern": "(^(?:(\\d+)\\.)(?:(\\d+)\\.)(\\d+)$|^$)"
                }
          },
          "mainSteps": [{
                "action": "aws:configurePackage",
                "name": "configurePackage",
                "inputs": {
                      "name": "{{ name }}",
                      "action": "{{ action }}",
                      "version": "{{ version }}"
                }
          }]
    }

1. 文档粘贴完成后，现在可以点击 Create Document 完成文档创建过程。

该文档包括两个主要部分：一个 parameters 部分，其中包含文档要执行的操作列表，然后是一个 mainSteps 部分，指定文档要执行的操作，在本例中是执行 aws:configurePackage。在调用文档时，文档将要求用户从下拉列表中选择 apache2、mysql-server 或 php 中的一个，并选择所选软件的可选版本号。然后，您可以选择是否要在托管的 EC2 实例群中安装或卸载此特定包，并在完成时执行文档！

现在，您的自定义文档已创建，让我们快速配置 State Manager 以调用它：

1. 从 EC2 导航窗格中的 Systems Manager Services 部分，选择 State Manager。在 State Manager 仪表板上，选择 Create Association 选项开始配置 State Manager。

2. 为您的关联提供一个合适的 Association Name。请注意，这是一个可选字段，如果您希望可以跳过它。

3. 接下来，从 Select Document 部分过滤并选择我们在前面步骤中创建的自定义文档。选择后，您将注意到子字段根据我们在文档中提供的参数而变化。让我们快速配置此项并创建我们的关联。

4. 在 Targets 部分，选择您的 Dev 实例或您希望与此 State Manager 关联的任何托管实例。最后，继续配置 Schedule，以基于 CRON 或速率计划触发关联。

5. 最后但并非最不重要的是，配置 Action 并从 Parameters 部分选择适当的 Package Name ，如下面的截图所示：

1. 您可以选择启用“写入 S3”复选框，将状态管理器的执行日志记录到您自己的自定义 S3 存储桶中。在此场景下，我没有选择此选项。

2. 最后，通过选择创建关联选项来完成状态管理器的关联过程。

现在，您可以通过状态管理器仪表板查看和修改您的关联。或者，您也可以选择通过选择立即应用关联选项来立即启用您的关联。

在接下来的部分中，我们将了解由 Systems Manager 提供的另一个简单易用的功能，它帮助自动化简单的实例和部署任务，称为 System Manager 自动化！

使用 System Manager 自动化简化实例维护

System Manager 自动化是一项托管服务，提供一个单一的集中界面，用于执行和监控常见的实例管理任务，如修补、执行备份、执行脚本等。让我们首先了解一些必要的先决条件，这些条件需要在您的环境中配置，以便自动化能够正常工作。

使用自动化文档

如在状态管理器服务介绍中简要讨论的那样，自动化文档是基于 JSON 的简单文档，旨在帮助您快速高效地开始使用自动化服务。您可以使用预定义的自动化文档，或者选择创建自己的文档集。在本节中，我们将了解如何利用现有的自动化文档来修补您的 Dev EC2 实例并从中创建一个新的 AMI：

1. 从 EC2 管理控制台中，在 Systems Manager 共享资源部分选择“文档”选项。

2. 使用文档仪表板，您可以过滤并查看仅设置为文档类型为自动化的文档。

3. 选择 AWS-UpdateLinuxAmi 并点击“内容”选项卡，以查看如下所示的自动化文档：

AWS-UpdateLinuxAmi 文档包括五个不同的步骤，每个步骤在此简要说明：

• launchInstance： 这一步骤基本上是使用您的 Systems Manager IAM 实例配置文件以及一个用户数据脚本来启动一个新的 EC2 实例，该脚本将安装最新版本的 SSM 代理在该实例上。SSM 代理至关重要，因为它将使得后续步骤能够通过运行命令和状态管理器执行。

• updateOSSoftware: 在实例启动并安装 SSM 代理后，下一步负责更新 Linux 实例中的包。这是通过执行更新脚本来完成的，脚本按照一定的方法更新包以及可能标记为升级的其他软件。你还可以通过分别使用 IncludePackages 和 ExcludePackages 参数，选择性地包括或排除某些包。如果未包含任何包，则程序将更新实例上所有可用的包。

• stopInstance: 一旦实例更新了最新的包，下一步操作会简单地关闭实例，以便为镜像创建过程做准备。

• createImage: 这一步骤将根据更新后的 Linux 实例创建一个新的 AMI。该镜像包含一个描述性名称，将其与源 ID 和创建时间关联。

• terminateInstance: 自动化文档中的最后一步，实际上是通过终止正在运行的 Linux 实例来清理执行过程。

让我们来看几个简单的步骤，通过这些步骤我们可以使用自动化仪表盘手动调用这个自动化文档。

使用自动化修补实例

在本节中，我们将手动调用 AWS-UpdateLinuxAmi 自动化文档，以修补我们的 Linux 实例，并随后从中创建一个新的 AMI：

1. 为此，首先选择“自动化”选项，该选项位于 Systems Manager 服务部分下。

2. 在自动化仪表盘中，选择“运行自动化文档”选项。

3. 在“文档名称”字段中，选择 AWS-UpdateLinuxAmi 文档，并根据此处描述填写输入参数部分的必填字段：

   • SourceAmiId: 提供源 Amazon Machine Image ID，用于从该镜像部署新实例。

   • InstanceIamRole: 提供允许 Systems Manager 管理实例的 IAM 角色名称。我们在本章开始时作为 SSM 先决条件的一部分创建了这个角色。

   • AutomationAssumeRole: 提供允许自动化代表你执行操作的 IAM 角色 ARN。

   • TargetAmiName: 这将是作为此自动化文档的一部分创建的新 AMI 的名称。默认情况下，系统会生成一个字符串，包含源 AMI ID 以及创建的时间和日期。

   • InstanceType: 指定启动用于 AMI 创建过程的实例类型。默认选择 t2.micro 实例类型。

   • PreUpdateScript: 你还可以提供一个脚本 URL，在任何更新应用之前运行。此项为可选字段。

   • PostUpdateScript: 提供一个可选的更新后脚本 URL，用于在包更新应用后运行。

   • IncludePackages: 包含要更新的特定包。默认情况下，会应用所有可用的更新。

   • ExcludePackages: 提供你希望从更新列表中排除的特定包名称。

4. 填充字段后，只需选择运行自动化选项，如下图所示：

1. 自动化文档完全执行需要几分钟。你还可以使用自动化仪表板来验证执行的输出。

2. 只需选择你的自动化任务执行 ID，就可以查看每个单独步骤的进度，如下图所示。你还可以通过选择相邻的查看输出链接来验证每个步骤的输出：

完成此操作后，你现在可以通过创建自己的自动化文档并按照此处提到的步骤执行它们来运行类似的自动化任务。但如果你希望基于某些事件或计划触发这些步骤呢？好吧，这正是我们将在下一节中讨论的内容——使用 CloudWatch 调度和事件触发自动化。

使用 CloudWatch 调度和事件触发自动化

虽然你可以手动触发自动化文档，但通过使用 CloudWatch 调度和事件安排或自动化执行自动化任务要更好。

让我们首先了解如何利用 CloudWatch 事件来触发系统管理器自动化事件的简单通知。这些事件可以用来通知你自动化任务是否成功、失败或仅仅是超时：

1. 首先，登录到 CloudWatch 仪表板。或者，你可以通过console.aws.amazon.com/cloudwatch/打开 CloudWatch。

2. 接下来，在导航窗格中选择事件选项，打开创建规则页面。在这里，从事件源部分选择事件模式。

3. 完成此操作后，我们需要构建我们的事件源。为此，在服务名称下拉列表中，搜索并选择 EC2 简单系统管理器（SSM）选项，如下所示：

1. 选择服务后，你现在还可以选择相应的 SSM 事件类型，例如，在本例中，我希望在某个特定的自动化任务失败时收到通知。因此，在事件类型下拉列表中，我选择了自动化选项。你也可以选择其他 SSM 服务。

2. 接下来，在详细类型部分，我选择了 EC2 自动化执行状态变化通知选项。相应地，我也选择了“失败”作为我的事件的特定状态。这意味着，如果由于自动化任务生成了失败状态事件，它将触发相应的操作，操作可以简单到使用 SNS 服务发送通知，甚至触发相应的 Lambda 函数执行某种形式的修复操作。

3. 你的事件模式预览应该类似于此处的代码片段：

    {
      "source": [
        "aws.ssm"
      ],
      "detail-type": [
        "EC2 Automation Step Status-change Notification",
        "EC2 Automation Execution Status-change Notification"
      ]
    }

同样，您还可以通过选择事件源部分中的“计划”选项，配置自动化任务的 CRON 表达式或固定执行频率：

1. 根据您的需求提供合适的 Cron 表达式，例如，我希望每周日晚上 10 点（UTC）运行 AWS-UpdateLinuxAmi 自动化文档。在这种情况下，CRON 表达式将是0,18,?,*,SUN,*。

2. 配置好计划后，转到目标部分，选择目标下拉菜单中的 SSM 自动化选项，如下图所示：

1. 接下来，按照我们之前讨论的方式配置 AWS-UpdateLinuxAmi 参数，一旦所需的字段填充完成，点击“添加目标”*以完成配置。

完成此步骤后，您现在可以根据事件和计划即时触发自动化任务，所有这些都由 CloudWatch 提供支持！是不是很惊人？

在接下来的最后一节中，我们将了解另一种简单易用的 SSM 服务，它能让您轻松管理和修补您的实例。

使用补丁基准和合规性管理实例的补丁

定期为实例打上正确的安全补丁是一个重要的活动，如果在每个实例上手动进行，会消耗大量时间和精力。幸运的是，AWS 提供了一种非常高效且简便的方式，通过 Patch Manager 服务自动化管理实例的补丁，SSM 提供了这种现成的功能。

作为管理员，您只需要扫描实例，查找缺失的补丁，并利用 Patch Manager 自动修复问题，通过安装所需的补丁。您也可以选择使用 SSM 的维护窗口任务安排自动为您的托管实例或实例组打补丁。

在本节中，我们将探索一种简单快捷的方法，为我们的开发实例创建一个独特的补丁基准，并随后为其创建并关联一个维护窗口，所有这些都通过 EC2 管理仪表盘完成。让我们马上开始吧！

首先，您需要确保您的实例拥有所需的 IAM 角色以及已安装并正常运行的 SSM 代理，正如本章开头所述。基本配置完成后，我们首先需要根据要求的补丁集来配置补丁基准：

1. 为此，启动您的 EC2 仪表盘，并从系统管理服务部分选择“补丁基准”选项。补丁管理器为每个受支持的操作系统提供默认的补丁基准，包括 Windows Server 2003 到 2016、Ubuntu、RHEL、CentOS、SUSE，甚至 Amazon Linux。您可以使用这些默认的补丁基准，或者根据您的需求创建一个自定义基准。在这里，我们将快速为我们的开发实例创建一个自定义基准。

2. 选择“创建补丁基准”选项，以打开“创建补丁基准”仪表板。在此处，提供您自定义基准的合适名称。

3. 在操作系统中，选择 Ubuntu 作为操作系统选项。您将注意到，基于您选择的操作系统类型，补丁规则会相应地发生变化。

4. 接下来，在“批准规则”部分，根据您的需求创建适当的补丁基准规则。例如，我希望将 Python 包的优先级设置为重要，并将合规级别设置为高。同样，您可以为一个基准添加最多 10 条此类规则，如以下截图所示：

1. 在最后一部分“补丁例外”中，您可以选择性地提及这些补丁的批准包、拒绝包以及合规级别。在这种情况下，我将这些值保持为默认值，并选择“创建补丁基准”选项以完成该过程。

创建完新补丁基准后，您现在可以通过从补丁基准仪表板中选择新基准并点击“设置为默认补丁基准”选项，将其提升为默认基准。

进入本教程的下一部分，我们将继续为我们新创建的补丁基准设置维护窗口：

1. 为此，请从系统管理器共享资源部分选择“维护窗口”选项。点击“创建维护窗口”以开始此过程。

2. 在“创建维护窗口”页面中，提供窗口的合适名称以及可选的描述。

3. 接下来，在“指定时间表”部分，您可以选择使用CRON 调度器或速率表达式来定义维护窗口的时间表。对于这个场景，我选择了 Cron 时间表构建器选项，并设置了一个每周日中午 12:00 UTC 开始的窗口：

1. 在“持续时间”和“停止启动任务”字段中，指定维护窗口必须持续的小时数以及在您希望系统停止启动新任务之前的小时数。填写所有必需字段后，点击“创建维护窗口”以完成创建过程。

创建维护窗口后，我们接下来需要为执行添加一些目标。目标是单独的 EC2 实例或通过标签标识的一组 EC2 实例。要配置目标，请选择您新创建的维护窗口，然后在“操作”选项卡中选择“注册目标”选项：

1. 在“注册目标”页面中，为您的维护窗口的目标提供一个目标名称，并填写可选描述。

2. 接下来，选择你希望与此目标关联的 EC2 实例，可以选择指定标签或手动选择实例，如下面的截图所示。在本场景中，我已为我的开发实例提供了标签OS:Linux；或者，你也可以手动选择你的实例：

1. 完成后，选择“注册目标”选项来完成此过程。

在目标实例与我们的维护窗口注册后，最后一步是将维护窗口与我们的补丁基准关联：

1. 为了做到这一点，我们需要选择新创建的维护窗口；在“操作”标签页中，选择“注册运行命令任务”选项。

2. 在“注册运行命令任务”页面，填写所需的详细信息，如为你的新 Run Command 指定一个名称，并可选择填写描述。

3. 接下来，在“命令文档”部分，选择 AWS-RunPatchBaseline 文档。你还会看到与此 Run Command 相关的目标实例，因为我们在之前的步骤中已经配置过它。

4. 最后，在“参数”部分，选择合适的 IAM 角色，提供一个适当的值给Run Command 在收到一定数量的错误后停止运行，最后但同样重要的是，别忘了选择是否希望安装或仅扫描目标实例以检查所需的补丁集。

5. 所有字段填写完成后，点击“注册任务”以完成此配置。

很棒吧？只需几个简单的点击，你就为你的开发实例设置了一个有效的补丁管理解决方案，而且无需任何专门的软件或专业知识！但在我们结束本章之前，让我们看一下系统管理器提供的最后一个简单而非常有用的服务，它帮助收集并盘点有关你 AWS 实例以及本地实例的元数据。

开始使用库存管理

库存管理（Inventory Management），或者简称库存，是系统管理器提供的另一个托管服务，负责收集来自你的 AWS 实例以及由系统管理器管理的本地环境中的操作系统、应用程序和实例元数据。你可以使用此服务查询库存元数据，用于映射、理解和根据某些软件或合规性要求修复 EC2 实例。

让我们看一个非常简单的例子，演示如何通过 AWS 管理控制台启用库存服务用于我们的开发实例：

1. 首先，你需要在你的托管实例上配置 SSM 代理和所需的 IAM 角色。完成后，从系统管理器共享资源部分选择“托管实例”选项。

2. 在这里，选择你的开发实例，并点击如下面截图所示的“设置库存”选项：

1. 在“设置清单”页面上，大部分选项你现在应该已经很熟悉了，比如“目标”和“计划”部分，所以我不会再在这里多做解释。这里更重要的部分是“参数”部分，你可以通过它选择启用或禁用不同类型的清单收集。例如，由于我们在使用 Linux 实例，我选择禁用Windows 更新参数，同时保持其他参数启用。

2. 最后一个字段“将执行历史写入 S3”基本上允许你将清单数据集中写入并存储在一个 S3 存储桶中。当你希望从多个实例中集中整理清单数据，并使用 Amazon Athena 或 QuickInsights 等服务查询这些数据时，这非常有用。完成后，点击“设置清单”来完成清单设置过程。

现在，你可以通过在“托管实例”页面选择你的 EC2 实例，并点击“清单”标签，查看收集到的元数据。在这里，你可以在各种清单类型的下拉列表中选择，查看实例特定的元数据。你可以在 AWS:Application、AWS:AWSComponent、AWS:Network 和 AWS:InstanceDetailedInformation 等选项之间切换，举几个例子。

通过这些，我们来到了本章的结尾，但在进入下一个章节之前，这里有一些关键要点和建议，你应该试试看！

规划你的下一步

好的，我们在本章中涵盖了许多新功能和服务，但仍然有一些事情我建议你亲自尝试。首先是参数存储（Parameter Store）！

参数存储是 Systems Manager 提供的另一个托管服务，旨在安全地存储实例的配置数据，如密码、数据库字符串、许可证代码等。你还可以选择将数据以纯文本或加密形式存储，并在以后的自动化文档或政策文档中作为变量引用，而不是直接作为纯文本。这还不是它的最棒之处！通过参数存储，你还可以在其他 AWS 服务中引用这些数据，如 EC2 容器服务和 AWS Lambda，从而使其成为一个集中存储所有配置和安全数据的地方。

我强烈推荐在你的环境中使用的另一个重要功能是资源数据同步（Resource Data Sync）。资源数据同步使你能够将从不同的 Systems Manager 服务收集到的实例元数据存储在一个集中位置。你可以配置它来收集来自实例操作系统、应用程序、微软 Windows 更新、网络配置等方面的元数据！这在生产环境中非常有用，尤其是当你想分析实例的软件和补丁合规性时。

总结

好吧，这确实是一个长章节，但我们学到了很多东西，希望这能帮助您在掌握 AWS 的道路上取得进展！让我们快速回顾一下到目前为止所学的内容。

我们首先快速介绍了 Systems Manager，然后深入了解了如何在您的托管 EC2 实例上安装、配置和验证 SSM 代理。接着，我们了解了如何利用 Run Command 在托管实例上执行某些类型的操作，然后简要介绍了如何使用 State Manager 维护实例的状态配置。我们还讨论了如何与自动化文档一起工作，以及如何通过它们有效地修补您的实例。章节最后，我们学习了如何使用 Patch Manager 修补实例，并且还了解了如何通过 Inventory Manager 有效地清点实例的元数据。

在下一个章节中，我们将介绍两项新服务，它们将帮助我们将简单的 WordPress 应用程序部署到云端。所以，敬请期待！

第三章：介绍 Elastic Beanstalk 和 Elastic File System

在上一章中，我们首先了解了一个很棒的托管服务——Systems Manager，它几乎可以执行与 EC2 实例相关的所有任务，比如自动化脚本执行、修补实例、维护状态和合规性等等。在本章中，我们将进一步提升难度，介绍两个非常强大的服务：Elastic Beanstalk，一个可以帮助您通过几次点击就能开发和部署丰富 Web 应用程序的服务，以及 Elastic File System，一个为 EC2 实例提供大规模共享文件系统的服务！因此，考虑到这一点，让我们快速回顾一下本章将涉及的各个主题：

• 介绍 Elastic Beanstalk 及其工作原理

• 如何通过 Elastic Beanstalk 轻松管理应用程序、环境和配置

• 使用 Elastic Beanstalk CLI 将应用程序推送到 AWS

• 开始使用 Elastic File System 及其各种用例

• 使用 Elastic Beanstalk 和 Elastic File System 托管一个高可扩展且高可用的 WordPress 网站

有很多事情要做，快点开始吧！

介绍 Amazon Elastic Beanstalk

云计算的一个关键特点是为用户和开发人员提供一个无缝且易于使用的平台，用于开发和部署他们的应用程序。这正是 Elastic Beanstalk 的作用所在。Elastic Beanstalk 于 2011 年首次推出，并不断发展，成为 AWS 提供的一个成熟的 PaaS 服务。

Elastic Beanstalk 是您在 AWS 上快速部署和管理 Web 应用程序的一站式解决方案。您只需将代码上传到 Beanstalk，完成！Elastic Beanstalk 会处理整个应用程序的部署过程，从 EC2 容量的配置到自动扩展实例，甚至通过 ELB 进行负载均衡！Elastic Beanstalk 负责一切，您可以专注于更重要的任务，如开发您的应用程序，而不必被复杂的操作细节困扰。

对我来说，Beanstalk 不仅仅是部署和管理应用程序的工具。让我们来看一下利用 Elastic Beanstalk 来支持 Web 应用程序的一些关键好处：

• 部署支持：今天，Beanstalk 支持标准 EC2 实例和 Docker 容器作为应用程序部署的基础。这使得您可以相对轻松地在 AWS 上托管 Web 应用程序和基于微服务的应用。

• 平台支持：Beanstalk 为开发人员提供了一套丰富的平台，用于在上面部署他们的应用程序。目前，支持的平台包括 Java、PHP、Python、.NET、Node.js 和 Ruby，未来将会增加更多语言和平台。

• 开发者友好：使用 Beanstalk，将应用程序构建并部署到 AWS 是极其简单的。你可以利用多种选项，包括 AWS 管理控制台或其命令行工具、代码库（如 Git），甚至是像 Eclipse 或 Visual Studio 这样的集成开发环境（IDE）来上传你的应用程序，剩下的由 Beanstalk 自动处理。

• 控制：使用 Beanstalk，你可以完全控制基础 AWS 资源以及托管应用程序的环境。你可以更改实例类型、扩展资源、添加更多应用环境、配置 ELB 等等！

• 费用：Beanstalk 最棒的地方之一就是它完全免费！没错，你没有听错！免费！你只需为根据你提供的配置启动的 AWS 资源付费，其他一切都不收费。是不是很惊人？

有了这些要点，让我们来看一下在开始使用 Elastic Beanstalk 之前，你需要了解的一些基本概念和术语。

概念和术语

以下是一些常见的概念和术语，您在使用 Elastic Beanstalk 时经常会遇到：

• 应用程序：Elastic Beanstalk 中的一个应用程序基本上是 Beanstalk 内部组件的集合，包括环境、版本、事件以及其他各种元素。可以将 Elastic Beanstalk 应用程序看作是一个高级容器，包含了应用程序的不同方面。

• 应用程序版本：应用程序版本不过是应用程序代码的不同版本。每个应用程序代码版本都会存储在由 Beanstalk 自动创建和管理的 S3 存储桶中。你可以创建多个应用程序代码版本，并将其用于部署到一个或多个环境中进行测试和比较。

• 环境：Elastic Beanstalk 环境是另一个逻辑容器，它一次只托管一个应用程序版本，并在指定的一组实例、负载均衡器、自动扩展组等上运行。通常，你会为开发、验收测试和生产托管设置不同的环境，但这并没有硬性规定。

环境有两种类型，在初始环境设置阶段你可以选择其中一种。第一种称为 Web 服务器环境，通常用于支持 HTTP 请求的应用程序，比如 Web 应用程序等。第二种是 工作环境，应用程序从 Amazon SQS 队列中拉取任务。以下是这两种类型的详细介绍：

• Web 服务器环境：如前所述，这种环境非常适合托管和管理 Web 前端应用程序，如网站、移动应用程序等。作为该环境的一部分，Beanstalk 提供了一个面向互联网的弹性负载均衡器（Elastic Load Balancer），一个具有一些最小化配置设置的自动扩展组，以及少量 EC2 实例，这些实例包含您的应用程序代码以及一个预安装的名为 Host Manager 的代理。Host Manager 代理是整个设置过程中的关键组件，它负责部署和监控应用程序，并定期修补实例和轮换日志。

这是一个示意图，展示了如何使用 Web 服务器环境对简单应用程序进行扩展。请注意图中的 RDS 实例。您还可以选择使用 Elastic Beanstalk 为您的应用程序设置 RDS 实例，或者稍后手动将其添加到应用栈中：

另外值得一提的是，每个环境都有一个唯一的 CNAME，例如 mywordpress。该 CNAME 映射到一个 URL，形式为 mywordpress.us-east-1.elasticbeanstalk.com。此 URL 通过使用 CNAME 记录在 Amazon 的 DNS 服务 Route53 中别名为 Elastic Load Balancing 的 URL，如 abcdef-123456.us-east-1.elb.amazonaws.com。

• Worker 环境：Worker 环境与 Web 服务器环境的工作方式非常不同。在这种情况下，Elastic Beanstalk 会在您的环境中启动一个 SQS 队列，并在每个 Worker 实例中安装一个小型守护进程。守护进程负责定期轮询队列以获取新的消息，如果队列中有消息，守护进程将其拉入 Worker 实例进行处理，如下图所示：

理想情况下，您可以使用 Web 和 Worker 环境的组合来托管应用程序，从而清晰地将 Web 前端资源和后端处理 Worker 实例解耦。请记住，在设置环境时，您还需要考虑许多其他设计要素，例如可扩展性如何处理、根据数据类型选择存储选项（例如，使用 S3 存储日志、使用 RDS 存储应用数据）、安全性、容错能力等。

完成这一部分后，让我们进入更有趣的部分，看看如何开始使用 Elastic Beanstalk！

开始使用 Elastic Beanstalk

在本节中，我们将深入探讨如何使用 Elastic Beanstalk 为我们的简单 WordPress 应用程序设置一个完全功能的开发和生产环境。在开始之前，这里有一份在继续之前需要准备的前提条件清单：

• 一个有效的 AWS 账户和用户凭证，并具有运行 AWS CLI 和 Elastic Beanstalk CLI 所需的权限集。

• 一个沙盒/开发实例，用于下载 WordPress 安装包，并随后将应用代码推送到相应的 Beanstalk 环境。请注意，您也可以使用其他资源，例如 Git URL 或 IDE，但目前我们将专注于这种方法。

创建开发环境

让我们首先通过创建一个简单明了的开发环境来为我们的 WordPress 站点奠定基础。为此，执行以下步骤：

1. 登录 AWS 控制台，并从服务筛选器中选择 Elastic Beanstalk 选项，或者通过在浏览器中启动 URL console.aws.amazon.com/elasticbeanstalk 来启动 Elastic Beanstalk 控制台。

2. 接下来，选择“创建新应用”选项以开始。请记住，应用是我们应用代码的最高级别容器，它可以根据需要包含一个或多个环境。

3. 在“创建新应用”对话框中，提供合适的应用名称和一个可选的描述来开始。完成后，点击“创建”。

4. 在创建了基础应用容器后，您现在可以继续创建开发环境。为此，在操作下拉列表中，选择“创建新应用”选项。

5. 在这里，您将有一个选项，可以选择 Web 服务器环境或 Worker 环境配置。请记住，环境类型只能在此处选择一次，因此请确保根据您的应用需求选择正确的级别。在这种情况下，我选择了 Web 服务器环境，如下图所示：

1. 在“创建新环境”向导页面中，为您的 WordPress 站点提供一个合适的环境名称。由于这是一个开发环境，我将其命名为 YoyoWordpress-dev。接下来，在“域名”字段中，为您网站的域名 URL 提供一个唯一名称。该 URL 将以区域特定的 Elastic Beanstalk URL 作为后缀，如下图所示：

1. 接下来，为您的新环境输入一个合适的描述，并继续进入基础配置部分。在这里，从平台下拉菜单中选择“预配置平台”选项，并选择 PHP 平台，如下图所示。PHP 是我们的默认选项，因为 WordPress 是基于 PHP 5.6 构建的。今天，Beanstalk 支持打包构建器、Docker 容器、Go、Java SE、带 Tomcat 的 Java、在 Windows Server 上运行 IIS 的 .NET、Node.js、PHP、Python 和 Ruby，更多平台支持也将在不久的将来推出：

1. 现在，到了需要保持冷静的部分！将其余选项保持为默认值，选择“配置更多选项”，而不是“创建环境”选项！是的，我们首先将配置一些附加项，然后再创建我们的开发环境！

2. 在配置环境页面中，您可以根据应用程序的要求选择三个预配置的配置预设选项之一。预设选项在这里简要说明：

   • 低成本（符合免费层资格）：此配置将启动一个单一的（t2.micro）实例，并未配置负载均衡或自动扩展组。如果您只是想使用基础功能开始一个应用程序，或希望设置一个简约的开发环境，那么这个配置非常理想，正如本例中所示。

   • 高可用性：与低成本预设不同，高可用性配置预先配备了一个自动扩展组，可以扩展到默认的四个实例或更多实例，并且具有跨区域负载均衡和连接排空功能的弹性负载均衡器。此外，您还将获得一系列用于监控的 CloudWatch 警报，以及为您的实例和负载均衡器创建的安全组。

   • 自定义配置：您还可以选择根据其他参数配置您的环境。您可以选择此预设，并根据需要修改环境中的每个组件。

3. 在配置预设设置为低成本（免费层）后，我们可以修改的下一个项目是平台配置。Elastic Beanstalk 支持以下 PHP 平台配置：

PHP 语言	Amazon Linux AMI	PHP 版本
PHP 7.1	2017.03.1	PHP 7.1.7
PHP 7.0	2017.03.1	PHP 7.0.21
PHP 5.6	2017.03.1	PHP 5.6.31
PHP 5.5	2017.03.1	PHP 5.5.38
PHP 5.4	2017.03.1	PHP 5.4.45

1. 由于我们正在使用 WordPress 应用程序，因此我们还需要修改平台，以适应正确的 PHP 版本。

为此，请选择更改平台配置选项。这将弹出选择平台版本的对话框，如下所示：

1. 在此，从下拉列表中搜索并选择运行 PHP 5.6 的 64 位 Amazon Linux 2017.03 v2.5.0 选项，因为 WordPress 执行在 PHP 5.6 上非常稳定。完成后，点击保存以完成此过程。

2. 在根据我们的需求更改了平台配置后，我们现在可以继续配置附加服务，如安全、通知、网络、数据库等！例如，我们可以通过在网络面板中选择“修改”选项，快速配置我们的 WordPress 开发环境的网络。

3. 在网络面板中，你可以选择在自定义 VPC 中启动你的环境，以及其他特定实例的设置，如启用公共 IP 地址、根据 VPC 设计选择实例子网，最后为你的开发实例分配实例安全组。在此情况下，我已经为开发环境专门创建了一个包含一个公共子网和一个私有子网的自定义 VPC，并且还有一个默认的安全组。以下是我的环境网络配置设置概览，你可以根据需求进行调整：

1. 设置完成后，点击保存以完成网络更改。你可以根据需要进行其他配置更改，但由于这是一个开发环境，我选择暂时保持其余选项为默认设置。完成后，选择创建环境选项以结束环境创建过程。

一旦环境创建过程开始，它将需要几分钟才能完成执行，如下图所示。在此阶段，你将看到 Elastic Beanstalk 创建一个新的安全组以及一个 Elastic IP 地址用于你的 EC2 开发实例。在这一阶段，环境也将从 Pending 状态过渡到 Ok 状态，你可以查看环境、应用程序的日志以及状态：

在环境启动并运行后，你也可以通过使用环境仪表板提供的 URL 来验证它。选择该 URL 后，你将被重定向到一个新的应用程序登陆页面，这基本上验证了你的环境已配置为可以使用 PHP 5.6。

但我们的 WordPress 应用程序在哪里呢？这正是我们接下来将要通过一个非常简单且易于使用的 Elastic Beanstalk CLI 部署的内容。

使用 Elastic Beanstalk CLI

在通过 AWS 管理控制台部署环境后，我们将重点转向使用 Elastic Beanstalk CLI，或 EB CLI，将应用程序代码推送到新创建的环境。

EB CLI 是一个强大的工具，可以使用几个简单的 CLI 命令操作和管理整个 Elastic Beanstalk 环境。它还与 AWS 开发服务（如 CodeBuild 和 CodeCommit）以及其他第三方代码仓库服务（如 Git）配合使用。

在本节中，我们将首先介绍在简单 Linux 实例上安装 EB CLI 的几个简单步骤，然后将继续配置并将我们的 WordPress 应用程序推送到相应的开发环境中：

1. 为此，我们首先需要确保实例已更新到最新的包。在我的案例中，我是在一个简单的 Ubuntu 14.04 LTS 实例上执行这些步骤，然而，您也可以使用您自己的本地虚拟机。

2. 运行以下命令以更新您的操作系统。命令将根据您的操作系统版本有所不同：

# sudo apt-get update

1. 接下来，我们需要确保实例中已安装所需的 Python 包。请注意，如果您使用的是 Amazon Linux AMI，那么默认情况下它将已经安装必要的 Python 包：

# sudo apt-get install python python-pip

AWS CLI 和 EB CLI 需要 Python 2 版本 2.6.5+ 或 Python 3 版本 3.3+。

1. 安装完 Python 包后，我们接着使用以下命令设置 AWS CLI：

# pip install awscli
# aws configure

第一个命令安装 CLI，而另一个命令将引导您通过一个简单的向导来为您的实例设置 AWS CLI。要了解更多关于如何配置 AWS CLI 的信息，您可以查看此网址：docs.aws.amazon.com/cli/latest/userguide/installing.html。

1. 最后，我们继续安装 EB CLI。安装过程非常简单明了：

# pip install awsebcli

1. 就是这样！现在您已经安装了一个功能齐全的 Elastic Beanstalk CLI 并准备好使用。接下来，让我们下载所需的 WordPress 代码 ZIP 文件并使用 EB CLI 将其推送到开发环境中：

# sudo git clone https://github.com/WordPress/WordPress.git

1. 将您的 WordPress ZIP 文件的内容提取到一个新文件夹中，然后在 WordPress 目录中运行以下命令：

# eb init

eb init 命令用于初始化并将 EB CLI 与您新创建的开发环境同步。请按照屏幕上的指示配置 EB CLI 的设置，例如选择一个默认的操作区域，选择要使用的应用程序等。请记住，默认区域必须与您当前开发环境的区域相匹配，在我的案例中是 us-east-1：

1. 设置好 EB CLI 后，现在唯一剩下的步骤就是使用另一个名为 eb deploy 的 EB CLI 命令将 WordPress 应用部署到开发环境：

# eb deploy

在部署过程中，CLI 会在您的环境中新建一个 S3 存储桶，并创建一个应用版本档案。每次应用部署都会导致 S3 中后续版本的创建。之后，您将看到您的应用代码被上传到开发环境，如下图所示：

1. 在应用程序上传并在您的开发实例中设置后，环境的状态同时从 Ok 变为 Pending。一旦应用程序可用，环境的健康状态将再次从 Pending 转为 OK，再到 Info。

2. 你可以通过刷新环境仪表板上的应用程序 URL（yoyoclouds.us-east-1.elasticbeanstalk.com）来验证应用程序是否已上传。你应该能看到 WordPress 的欢迎屏幕，如下图所示：

但需要注意的是，这个设置仍然需要一个 MySQL 数据库，因此不要忘记前往 RDS 管理控制台，创建一个简化的 MySQL 数据库，或者更好的是，为你的开发环境创建一个 Aurora DB 实例。记得记下数据库的用户名、密码、数据库主机和数据库名称；在配置 WordPress 时你将需要这些信息！

完成此步骤后，让我们花几分钟时间了解如何使用环境仪表板配置和监控你新部署的应用程序的各种选项！

理解环境仪表板

环境仪表板是你管理和监控新部署应用程序以及继承实例的集中平台。在本节中，我们将快速浏览环境仪表板中每个部分，并了解如何利用它们来管理你的应用程序。

首先，仪表板视图本身为你提供了一些高层次的信息和事件日志，展示了当前环境的状态。要了解最近一批事件的更多信息，你可以选择在“最近事件”部分选择“显示全部”选项，或者从导航窗格中选择“事件”选项。

仪表板还允许你通过选择“上传并部署”选项上传应用程序的新版，如下图所示。在这里，你还可以看到正在运行的 WordPress 应用版本。这就是我们刚刚使用 EB CLI 部署的应用。

你还可以通过环境仪表板右上角的“操作”标签来控制环境的各个方面，如保存配置、克隆环境和终止环境：

从仪表板移动到下一个值得查看的导航窗格标签，即“配置”部分。让我们更详细地查看每个配置选项，从扩展选项开始：

• 扩展：在这里，你可以选择将你的环境类型从单实例部署更改为负载均衡、启用自动扩展的环境，只需从环境类型下拉列表中选择正确的选项。你甚至可以通过选择“添加计划操作”选项来启用基于时间的扩展。

• 实例：在下一个选项卡中，你可以为你的环境配置特定实例的详细信息，例如实例类型、用于启用 SSH 连接到实例的 EC2 密钥对、实例配置文件以及其他选项，例如根卷类型及其所需大小。

• 通知：在这里，你可以指定一个特定的电子邮件地址，使用该地址，与你的环境相关的通知——例如其事件——将通过 Amazon SNS 发送。

• 软件配置：此部分允许你为应用程序配置一些关键参数，例如应用程序的文档根目录、运行 PHP 环境的内存限制以及日志选项。但是我真正喜欢软件配置的一点是环境属性部分。有了这个，你可以将密钥、端点、调试设置和其他信息传递给你的应用程序，而无需通过 SSH 登录到实例中，简直太棒了！稍后我们将在本章中了解环境属性以及如何创建简单的环境变量并将其传递给你的 WordPress 应用程序。

• 健康：在你的环境中，最重要的配置项之一就是健康部分，它允许你为应用程序配置健康检查 URL，并使用安装在系统上的特殊代理启用详细的健康报告。这个代理监控你的 EC2 实例的健康状况，捕获应用程序级别的健康指标，并将其直接发送到 Beanstalk 进行进一步分析。这与应用程序日志结合，帮助你深入排查问题并使用 Elastic Beanstalk 控制台解决所有问题。

• 注意：你可以在实例的/var/log/healthd/daemon.log文件中找到代理的日志。

除了配置选项卡外，Elastic Beanstalk 还为你提供了日志选项，在这里你可以请求完整的日志集或最后 100 行日志。你也可以通过这个部分下载每个实例的日志文件：

最后但同样重要的是，你还可以利用监控和警报部分查看整体环境健康状态，以及其他重要指标，如 CPU 利用率、最大网络流入和最大网络流出。要为单个图表配置警报，你只需选择每个图表旁边的警报图标，如下图所示：

会弹出一个相应的添加警报小部件，使用它你可以配置警报的基本信息，如名称、周期和阈值设置，以及所需的通知设置。

通过这种方式，你可以结合使用环境仪表板和 EB CLI 来执行日常的应用程序管理和监控任务。在下一节中，我们将利用这个环境仪表板，从现有的开发环境克隆并创建一个新的生产环境。

克隆环境

在开发环境已设置并正常运行后，接下来就是创建生产环境的时间了。从技术上讲，你可以重复我们之前为创建开发环境所遵循的所有步骤，这样也能顺利工作，但 Elastic Beanstalk 提供了一种非常简单和简洁的方法来使用现有环境作为模板创建新环境。这个过程叫做克隆，可以通过环境仪表板本身进行简单的几次点击完成：

1. 要开始，只需从环境仪表板页面选择“操作”选项卡，然后选择“克隆环境”选项。这将打开“新环境”页面，如下所示：

1. 在这里，首先为新环境提供一个环境名称，然后为环境 URL 添加一个独特的前缀。记住，这实际上是我们之前创建的开发环境的克隆，因此，默认情况下，它将包含相同的 Amazon Linux 实例和我们在开发阶段推送的 WordPress 应用程序。这不成问题，因为我们始终可以使用 EB CLI 将生产版本的应用程序推送到环境中。不过现在，请填写其余的详细信息并选择“克隆”选项。

新环境经历了与之前相同的初始化和创建过程，创建了独立的安全组，分配了一个新的弹性 IP，并启动了一个新的 EC2 实例，该实例与开发环境中推送的应用程序版本相同。

一旦完成，你现在应该有两个非常相似的环境并排运行，但生产环境难道不应该不仅仅是一个实例吗？嗯，这正是我们将在下一部分配置的内容。

配置生产环境

既然我们已经对环境仪表板有了全面了解，现在根据我们的需求配置生产环境应该相对容易。让我们从增加生产环境的实例数量开始：

1. 从新创建的生产环境的配置仪表板中选择“扩展配置”选项卡，将环境类型从“单实例”更改为“负载均衡，自动扩展”。实例数量设置以及自动扩展功能，只有在新更改反映到环境中后才会生效。完成后，点击“应用”。

要验证更改是否已传播，你可以将新创建的弹性负载均衡器 DNS 名称复制到网页浏览器中，验证是否能够访问 WordPress 入门向导。

1. 接下来，你还可以通过实例配置部分将默认实例类型从 t1.micro 更改为更强大的类型，如 t2.medium 或 t2.large。

2. 一旦主要设置完成，你还需要为你的生产实例创建一个新的 RDS 支持的 MySQL 数据库。所以，去console.aws.amazon.com/rds/使用 RDS 管理控制台创建一个新的 MySQL 数据库实例吧。

为了处理生产级负载，我强烈建议为你的 MySQL 数据库启用多可用区（multi-AZ）部署。

1. 在继续执行下一步之前，记得记录下数据库名称、数据库终端节点、用户名和密码！

2. 接下来，使用生产环境的 URL，启动你的 WordPress 网站，并填写所需的数据库配置详细信息，如下图所示：

这种配置数据库设置的方法并不理想，特别是在生产环境中。作为替代方案，Elastic Beanstalk 为你提供了环境属性的概念，使你能够将配置的键值对直接传递给应用程序。

1. 为此，你需要从生产仪表盘中选择配置部分，并在其中选择修改软件配置。

2. 在此，在“环境属性”部分，填写所需的生产数据库变量，如下图所示：

那么，这些变量最终会被配置到哪里呢？这就是我们利用名为wp-config.php的 WordPress 配置文件，将所有这些变量配置到文件中的地方。加载时，PHP 将从我们刚刚在 Elastic Beanstalk 中设置的环境属性中读取这些属性的值。

1. 使用你喜欢的文本编辑器打开wp-config.php文件，并更改数据库部分，如下代码片段所示：

/** The name of the database for WordPress */ 
define('DB_NAME', getenv('DB_NAME')); 

/** MySQL database username */ 
define('DB_USER', getenv('DB_USER')); 

/** MySQL database password */ 
define('DB_PASSWORD', getenv('DB_PASSWORD')); 

/** MySQL hostname */ 
define('DB_HOST', getenv('DB_HOST')); 

1. 保存文件并使用eb deploy命令将修改后的代码推送到生产环境。简单吧？

部署后，新的环境应该是这样的：

到目前为止看起来不错，对吧？完成这些设置后，你的 WordPress 配置应该能够高效地进行伸缩扩展，你不再需要担心负载均衡需求，甚至不用担心 MySQL 实例。此外，既然我们已经配置了实例从 Elastic Beanstalk 本身获取数据库信息，那么当底层的 WordPress 实例重启或终止时，我们也不必再担心网站会发生什么。这正是我们最初要做的事情，但还是有一个小问题。那就是，你最终会在 WordPress 网站上上传的内容文件，比如图片和视频呢？这些上传的文件最终会被存储在实例的本地磁盘上，这可能会成为一个问题，因为如果该实例被自动扩展策略终止，你可能会丢失所有数据。幸运的是，AWS 提供了一个解决方案来应对这个问题，这也是我们接下来要学习的内容。

介绍 Amazon 弹性文件系统

AWS 确实投入了大量创新和努力，推出了一些非常棒的服务，而我个人认为具有巨大潜力的一项服务就是弹性文件系统。为什么它如此重要呢？为了回答这个问题，我们需要稍微回顾一下，了解 AWS 目前提供的存储服务类型。

首先，我们有两种对象存储服务，分别是 Amazon S3 和 Amazon Glacier。虽然这两项服务在扩展能力上几乎是无限的，但与 EC2 实例存储和 EBS 相比，这些服务的性能稍显逊色。这是不可避免的，因为像 EBS 这样的服务是专门设计来提供快速且持久的块存储，但作为权衡，你不能跨多个可用区扩展 EBS 卷。另一方面，弹性文件系统（EFS）通过结合 EBS 卷的性能和跨多个 AZ 提供相同卷的可用性，提供了两者的优点，这真是太棒了！总结来说，EFS 是一个大规模可扩展的文件存储系统，它允许你同时将多个 EC2 实例挂载到它上面，跨 AZ 使用，而无需担心系统的耐用性、可用性或性能。

你问 EFS 是如何工作的？嗯，这正是我们将在下一节中学习的内容。

它是如何工作的？

EFS 的工作方式非常简单和极简，以减少作为最终用户需要执行和管理的配置量。首先，EFS 提供了创建一个或多个文件系统的功能。每个文件系统可以挂载到一个或多个实例，数据可以读取和写入到这些实例中。挂载文件系统要求您的实例支持网络文件系统版本 4.0 和 4.1（NFSv4）协议。大多数 Linux 操作系统都提供必要的支持，然而，如果这些机器上没有安装 NFS 客户端，您可能需要安装它才能连接到 EFS。那么，这对我们的 WordPress 应用有什么用呢？首先，一旦您有了 Amazon 弹性文件系统，您可以让多个 EC2 实例同时连接到它，并将其用作一个可扩展的共享驱动器，如果需要，它甚至可以扩展到 PB 级别。此外，Amazon 弹性文件系统在 EC2 实例重启甚至终止时不会出现任何停机或后果；数据将保存在文件系统中，直到您手动删除它或终止文件系统本身。然而，在使用弹性文件系统时，有一些规则和限制需要注意。

您一次只能将 Amazon EFS 挂载到一个 VPC 中的实例，并且文件系统和 VPC 必须位于同一 AWS 区域内。

文件系统创建后，系统将为您提供一个 DNS 名称，用于在您的区域内标识它。此外，您还需要在 VPC 内创建一个或多个支持挂载目标，这基本上充当了位于子网内的实例与文件系统之间的连接介质。以下是一个表示弹性文件系统如何通过挂载目标与 EC2 实例交互的示意图：

作为管理员，您可以在给定区域内的每个可用区创建一个挂载目标。您还可以在特定 VPC 中的每个子网中创建挂载目标，以便该 VPC 中的所有 EC2 实例共享该挂载目标。在接下来的部分，我们将介绍设置您自己的弹性文件系统所需的一些简单步骤。

创建弹性文件系统

设置您自己的弹性文件系统非常简单！您可以通过从 AWS 管理控制台启动弹性文件系统仪表板开始，或者访问以下 URL console.aws.amazon.com/efs/：

1. 在 EFS 登录页面上，选择“创建文件系统”选项以开始。

2. 在“配置文件系统访问”页面中，您可以首先选择要与文件系统关联的 VPC。请记住，您可以为每个 VPC 配置多个文件系统，但它们不能跨区域扩展：

1. 在选择了 VPC 后，关联的子网将自动根据它们所在的可用区，在“创建挂载目标”部分填充。在这里，您可以选择要与 Elastic File System 关联的适当子集及其对应的安全组。在我的案例中，我选择了 VPC 中的单个公共子网，因为 WordPress 应用程序实例将在这里部署，这些实例需要访问文件系统来存储图像和其他内容。

2. 填写完字段后，选择“下一步”选项继续。

3. 下一步是配置您 Elastic File System 的可选设置。在这里，您可以为文件系统添加标签以描述文件系统，并根据您的需求选择适当的性能模式。今天，EFS 提供了两种模式：通用目的模式，适用于大多数工作负载，以及最大 I/O 模式，专为环境需要扩展到成千上万的 EC2 实例并都连接到这个单一文件系统的情况设计。与通用目的模式相比，最大 I/O 模式提供了更好的性能，但在处理文件操作时，可能会出现略微更高的延迟。

4. 最后的选项是启用加密，选中后，将利用您现有 AWS 账户中的 KMS 密钥对存储在文件系统中的所有数据进行加密：

1. 在“审查并创建”页面上查看配置更改以完成 EFS 设置过程，最后点击“创建”以启用文件系统。此过程需要几分钟，一旦完成，您将看到新创建文件系统的 DNS 名称。请记下此名称，因为在我们的 Elastic Beanstalk 环境中也需要引用它。

到目前为止，一切顺利！我们已经在 Elastic Beanstalk 上启动并运行了我们的生产环境，现在我们创建了一个简单但功能强大的 Elastic File System。在下一部分，我们将探讨如何通过 Elastic Beanstalk 的配置文件概念，将这两个服务集成到 WordPress 中。

扩展 EFS 到 Elastic Beanstalk

尽管 Elastic Beanstalk 完全负责您的环境的配置和管理，但您仍然可以通过一些方法控制环境的高级配置，例如将应用程序集成到其他 AWS 服务（如 ElastiCache，甚至 EFS）。这可以通过 Beanstalk 本身提供的各种服务来实现；例如，通过利用 Beanstalk 的已保存配置，或使用环境清单（YML）文件。但在本节中，我们将重点介绍如何使用专门的配置文件 .ebextensions，将 EFS 服务与我们的 WordPress 应用程序集成。

这些.ebextensions是简单的 YAML 格式文档，文件扩展名以.config结尾。一旦创建了.ebextensions文件，你需要将其放置在应用程序源代码的根文件夹中，在一个名为.ebextensions的特殊目录内，最后，将你的应用程序部署到 Beanstalk。

这些配置文件非常强大，以至于你甚至不需要通过 SSH 连接到实例来发出配置命令。你可以通过使用.ebextensions，完全从项目源中配置你的环境：

1. 要开始在 WordPress 设置中使用.ebextensions，首先我们需要在 WordPress 应用程序的根目录中创建一个名为.ebextensions的文件夹。在你的开发实例中输入以下命令：

# cd wordpress && sudo mkdir .ebextensions

1. 创建一个扩展名为.config的新文件，并将以下内容粘贴到其中：

# sudo vi efs.config ### PASTE THE FOLLOWING CONTENTS ### 
packages: 
  yum: 
    nfs-utils: [] 
    jq: [] 
files: 
  "/tmp/mount-efs.sh" : 
    mode: "000755" 
    content: | 
      #!/usr/bin/env bash 
      mkdir -p /mnt/efs 
      EFS_NAME=$(/opt/elasticbeanstalk/bin/get-config environment | jq -r '.EFS_NAME') 
      mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 $EFS_NAME:/ /mnt/efs || true 
      mkdir -p /mnt/efs/uploads 
      chown webapp:webapp /mnt/efs/uploads 
commands: 
  01-mount: 
    command: "/tmp/mount-efs.sh" 
container_commands: 
  01-rm-wp-content-uploads: 
    command: rm -rf /var/app/ondeck/wp-content/uploads 
  02-symlink-uploads: 
    command: ln -snf /mnt/efs/uploads /var/app/ondeck/wp-content/uploads 

你可以在github.com/yoyoclouds/Administering-AWS-Volume2找到之前代码的完整副本。

该文件会使 Elastic Beanstalk 将新创建的 EFS 卷挂载到实例的/mnt/efs目录，并且如果存在，会删除wp-content/uploads目录，并将其符号链接到/mnt/efs/uploads，以便在实例之间共享并持久化：

1. 文件创建完成后，再次使用eb deploy命令将应用程序目录和新添加的.ebextensions目录推送到生产环境中。

2. 最后但同样重要的是，登录到你的生产环境，选择环境仪表板中的配置选项。在这里，选择软件配置图块，并在环境属性部分添加以下键值对，如下所示：

1. 在这里，EFS_NAME 的值必须是新创建的 EFS 文件系统的 DNS 名称。这与我们创建 EFS 时复制的 DNS 名称相同。

一旦部署状态发生变化并且可以使用，选择环境 URL 并验证 WordPress 的配置是否按照预期工作。如果你已经做到这一点，那么你应该已经拥有一个非常棒的、高可用、可扩展的 WordPress 站点并正在运行！棒极了，不是吗？

规划你接下来的步骤

好吧，本章我们已经介绍了许多新功能和服务，但我仍然有几件事推荐你自己尝试。首先是 Elastic Beanstalk 的高级配置。

如前所述，Beanstalk 为您提供了多种方式，可以通过各种内建服务（如.ebextensions，我们在前一节中已介绍过）来自定义和扩展您的应用并与其他 AWS 服务进行集成。另一个可以用来配置 Beanstalk 环境的服务是被称为环境清单（environment manifest）文件的配置。这是一个简单的 YAML 文件，包含了您的环境清单配置，例如环境名称、解决方案栈和在创建环境时使用的环境链接。该文件位于应用程序的根目录下，通常命名为env.yaml。此文件的一个关键用途是提供对环境链接的支持，允许您使用简单的名称作为引用连接两个应用环境。

例如，如果您有一个网站作为前端应用，接受用户的某些输入，另一个应用处理这些输入，您可以通过这个env.yml文件在工作者和前端应用之间创建一个链接。在调用时，这两个环境之间的链接将由 Beanstalk 自动设置和管理。

这是env.yml文件内容的一个小片段：

AWSConfigurationTemplateVersion: 1.1.0.0 
SolutionStack: 64bit Amazon Linux 2015.09 
EnvironmentName: frontend-environment 
EnvironmentLinks: 
  "WORKERQUEUE" : "worker-environment" 

您可以通过docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-cfg-manifest.html了解更多关于环境清单（env.yaml）的信息。

或者，Beanstalk 还为您提供了一个更简便的配置保存机制，您可以通过环境仪表板或 EB CLI 来调用它。这被称为保存的配置，可以通过在环境仪表板的操作（Actions）选项卡中选择“保存配置”（Save configuration）来启用。一旦应用，这些环境配置将接受任何存储在 S3 存储桶中的自定义配置作为对象。您甚至可以下载这个配置对象，并使用 EB CLI 创建环境的克隆。要了解更多关于保存配置的信息，请查看这个链接：docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-configuration-savedconfig.html。

另一个值得探索的非常有趣的功能是 Elastic Beanstalk 提供的对 Docker 容器的支持！如您所知，Docker 容器是创建微服务支持的应用程序的下一代重要技术，可以在巨大的规模上进行部署和扩展。Elastic Beanstalk 的 Docker 平台有两种通用配置，单容器和多容器选项，并且提供了几个预配置的容器镜像供您选择。

从弹性文件系统的角度来看，一个值得阅读和探索的关键方面是文件系统的整体性能考虑。本文件特别突出了与 EBS 提供的 IOPS 卷相比，不同的性能级别和使用案例。文档还提供了一些深入的见解和建议，帮助最大化文件系统的性能。你可以查看文档：docs.aws.amazon.com/efs/latest/ug/performance.html。

总结

所以，我们到了这里。又一章结束了！不过，在我们进入下一章之前，先快速回顾一下我们到目前为止学到的内容。

我们从简要介绍亚马逊 Elastic Beanstalk 开始，然后深入了解了它的概念和术语。接着，我们使用 Elastic Beanstalk 管理控制台和 EB CLI 为我们的 WordPress 应用创建了一个简单的开发环境。在这个过程中，我们还学会了如何使用 EB CLI 将应用部署到特定环境中，最后学会了如何快速克隆一个环境并配置它以处理生产工作负载。最后但同样重要的是，我们探索并学会了如何利用弹性文件系统创建一个持久且可扩展的文件共享系统，用于我们的 WordPress 设置，并以一些关键见解和下一步的计划结束了这一章。

在下一章中，我们将开始探索一些安全服务，例如 WAF 和 Shield。敬请期待——我们还有很多东西要学习！

第四章：使用 AWS WAF 保障工作负载安全

在上一章中，我们学习了如何利用 Amazon Elastic Beanstalk 和 Amazon Elastic File System 来构建和部署高度可扩展且可用的应用程序，且过程非常简单！然而，有一个关键方面我们在上一章没有过多讨论，那就是，当然，安全性！"我该如何保护我的应用程序和工作负载免受恶意软件和威胁的侵害？" 这个正是我们通过结合两个简单但非常强大的 AWS 服务——AWS Shield 和 AWS Web 应用防火墙（WAF）来回答的问题。

鉴于此，让我们快速浏览一下本章将涵盖的各个主题：

• 介绍 AWS WAF 及其工作原理

• 通过利用 WAF 和使用 Web ACL 保护我们的 WordPress 网站

• 了解用于防范跨站脚本和 SQL 注入的附加 WAF 条件

• 使用 CloudFormation 模板自动部署和配置 AWS WAF

• 使用 Amazon CloudWatch 监控 AWS WAF

• 简要介绍 AWS Shield 及其工作原理

• 了解 AWS Shield Advanced 以及如何利用它

有很多事情要做，让我们马上开始吧！

介绍 AWS Web 应用防火墙

安全性一直是并将永远是许多在云上运行工作负载和应用程序的组织的关键关注点。这正是 AWS 提供各种托管服务的原因，作为云管理员的您应当利用这些服务来保护和保障您的工作负载免受任何安全漏洞或威胁。在本节中，我们将探索这样一个简单但非常强大的服务——AWS WAF，或称 Web 应用防火墙。

AWS WAF 基本上是一个防火墙，帮助您保护面向互联网的应用程序免受常见的基于网络的威胁和攻击。它实际上是一个服务，允许您指定一组 Web 安全规则或访问控制列表（ACL），这些规则可以允许或限制通过 Amazon CloudFront 以及 应用负载均衡器（ALB）的某种类型的 Web 流量。到目前为止，WAF 可以用来创建自定义规则，帮助您的应用程序抵御诸如 SQL 注入、跨站脚本、分布式拒绝服务（DDoS）、恶意机器人、抓取器等攻击！您可以根据需求轻松创建新规则，并将其附加到现有的 ACL 列表中，使您能够更快速地响应并缓解变化的流量模式。

WAF 还配备了一个强大的 API，通过使用它，您可以自动化部署 ACL 规则以及以编程方式管理它们。此外，对于界面用户，WAF 提供定制的 CloudFormation 模板，这将使您能够在几分钟内开始使用完整的基于 WAF 的安全解决方案！我们稍后将查看如何部署此模板，以确保我们自己的 WordPress 应用程序在本章稍后的部分。

WAF 的定价基于您部署的 ACL 规则数量以及您的应用程序接收的 Web 请求数量。

这里是通过利用 AWS WAF 可以获得的一些好处的快速总结：

• 增强的保护：除了标准的 VPC 和安全组外，您还可以通过利用 WAF 的 ACL 规则来进一步保护应用程序免受常见的 Web 攻击。

• 高级流量过滤：与简单的 NACL 或安全组不同，WAF 为您提供了根据传入 Web 请求的特征定义自定义规则和条件的能力，例如头部中存在的值，请求的源 IP 地址，请求中是否存在任何 SQL 代码等。使用这些条件，您现在可以基本上根据这些预设条件允许、阻止或过滤流量。

• 简易管理：通过在一个中心位置定义和管理 WAF 规则，您可以轻松地在多个 CloudFront CDN 和应用程序负载均衡器上重用和传播自定义 ACL，并监视流量以及缓解任何问题，所有这些都可以使用相同的 WAF API 或 Web 用户界面完成。

• 成本效益的安全解决方案：利用 WAF 的最佳之处之一是，它完全没有预付费用或相关费用。您只需根据使用 WAF 创建的规则数量以及您的 Web 应用程序接收的流量量进行支付，而不会多花一分钱！

有了这些基本信息，让我们看看 WAF 的实际工作原理！

概念和术语

正如简要讨论的那样，WAF 可以在您的标准 ALB 和 CloudFront 分发上启用。但在我们开始配置 WAF 及其各种规则和 ACL 之前，我们首先需要了解一些常用术语和术语：

• 条件：条件构成了您 WAF 规则集的核心。这些基本上是您希望 WAF 在每个传入的 Web 请求中监视的可配置特征。在编写本书时，WAF 支持以下条件列表：

  • IP 匹配：你可以使用此条件检查传入的 web 请求是否来自指定的黑名单/白名单 IP 地址。然后，你可以根据需求对这些请求采取相应的操作，例如只允许来自白名单 IP 范围的流量，等等。AWS WAF 支持 IPv4 地址的 /8、/16、/24、/32 CIDR 块。

  • 字符串和正则表达式匹配：字符串匹配或正则表达式匹配条件可以用来指定传入 web 请求中的某一部分及其相应的文本，控制访问。例如，你可以创建一个匹配或正则表达式条件，检查用户代理头及其值是否与预设的字符串或表达式匹配。如果条件匹配，你可以选择允许或阻止该特定流量。

  • SQL 注入匹配：你可以使用此条件检查传入 web 请求的某些部分，比如 URI 或查询字符串，是否包含任何恶意的 SQL 代码。如果模式匹配成功，你可以选择阻止所有来自该请求 IP 范围的流量。

  • 跨站脚本匹配：黑客和利用者通常会在 web 请求中嵌入恶意脚本，这些脚本可能会危害你的应用程序。你可以利用跨站脚本匹配条件来检查传入请求的 URI 或头部，查找任何此类脚本或代码，并选择通过 WAF 规则阻止这些请求。

  • 地理位置匹配：你可以使用此条件列出你的 web 请求来源的国家，并根据你的需求决定是否阻止或允许这些请求。

  • 大小限制匹配：你可以使用大小限制匹配条件来检查传入 web 请求中指定部分的长度，比如查询字符串或 URI。例如，你可以创建一个简单的 WAF 规则来阻止所有查询字符串大于 100 字节的请求，等等。

• 规则：在定义了条件后，配置 WAF 的下一个重要方面是规则。规则基本上允许你将一个或多个条件组合成一个逻辑语句，然后可以用来允许、阻止或统计特定的传入请求。规则进一步分为两类：

  • 常规规则：常规或标准规则，应用一个或多个条件到你最近的一批传入的 web 请求。例如，一个规则可以阻止所有来自 IP 范围40.40.5.0/24的流量，或者当请求的查询字符串中包含任何类似 SQL 的代码时，等等。

  • 基于速率的规则：基于速率的规则与常规规则非常相似，不同之处在于它增加了速率限制。你现在可以配置条件并为其设置速率限制。只有当条件匹配或超过设置的速率限制时，规则才会触发。

WAF 会在 5 分钟的窗口期内检查速率限制。

例如，你可以配置一个简单的条件，阻止来自 40.40.5.0/24 IP 范围的所有传入流量，且请求速率限制为 10,000。在这种情况下，只有在满足条件并且 5 分钟内的请求数量超过 10,000 个时，规则才会触发相应的操作（允许、阻止、计数）。不符合这两个条件的请求将不会被计入速率限制，因此不会被此规则阻止。

• Web ACLs：一旦规则定义完成，你需要将它们组合成一个或多个 Web ACL。在这里，你可以为触发的规则定义一个操作，例如：允许、阻止、计数，或在请求不符合任何指定条件或规则时执行默认操作。Web ACL 按优先级工作，因此第一个列出的规则会首先与传入的请求进行比较。这使得你非常有必要了解在 Web ACL 中创建和分配规则的顺序。

下面是条件、规则和 Web ACL 如何在 WAF 中协同工作的简单示意图：

在了解了这些概念后，让我们来看一些简单的步骤，帮助你设置和配置 WAF Web ACL，以保护你的 Web 应用程序。

开始使用 WAF

在本节中，我们将介绍一些简单易行的步骤，帮助你快速开始使用 AWS WAF。为了演示，我们将使用与上一章节相同的环境和应用程序，因此，如果你还没有完成前面的案例，现在是时候快速回顾一下了！

在上一章节中，我们使用了 Elastic Beanstalk 和 Elastic File System 服务，将一个可扩展且高度可用的 WordPress 应用程序部署到互联网上。在本节中，我们将继续使用相同的设置，并通过引入 AWS WAF 进一步加强其安全性。为什么要为我们的 WordPress 应用程序使用 WAF？最简单的答案是：完全将安全检查从底层的 Web 服务器实例中抽象出来，而是将安全检查放在应用程序的入口点，如下图所示：

要开始使用，你首先需要确保你的 WordPress 应用程序已附加了 CloudFront CDN，或者至少前端请求是通过 Application Load Balancer 进行的。这一步至关重要，因为没有 CloudFront CDN 或 Application Load Balancer，WAF 根本无法工作！在我的案例中，我为我的生产级 WordPress 应用程序配置并部署了一个简单的 CloudFront CDN。你可以参考以下步骤指南，使用 CloudFront 设置你自己的 CDN：docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/。

创建 Web ACL

完成 CDN 设置后，前往 AWS 管理控制台，使用仪表板筛选 WAF 和 Shield 服务，或者直接访问此 URL console.aws.amazon.com/waf/home 打开 WAF 仪表板：

1. 假设这是您第一次配置 WAF，您将看到一个欢迎界面，提示您选择 AWS WAF 或 AWS Shield 服务。选择“前往 AWS WAF”选项。这将将您重定向到 WAF 仪表板，在此选择“配置 web ACL”选项以开始。

2. 选择“配置 web ACL”选项，将弹出一个“设置 web 访问控制列表（web ACL）”向导，指导您完成第一次 web ACL 设置。

3. 向导的第一页基本涵盖了条件、规则和 ACL 的概念，因此只需选择“下一步”继续。

4. 在“命名 web ACL”页面中，为您的新 ACL 提供一个合适的 Web ACL 名称。您会注意到，CloudWatch 指标名称字段会自动填充相应的名称。您可以根据需要更改名称。此指标名称将在以后用于通过 CloudWatch 仪表板监控我们的 web ACL。

5. 接下来，在“区域”下拉列表中，选择 Global (CloudFront) 或其他区域名称，具体取决于您是否要保护 CDN 或应用程序负载均衡器。以我为例，由于我已经设置了 CDN，所以我选择了 Global (CloudFront) 选项。

目前，WAF 对应用程序负载均衡器的支持仅限于以下地区：美国东部（弗吉尼亚北部）、美国西部（加利福尼亚北部）、美国西部（俄勒冈）、欧洲（爱尔兰）和亚太地区（东京）。

1. 在 AWS 资源关联字段中，您可以选择从下拉列表中选择您的 CloudFront 分发或应用程序负载均衡器；但是，为了简化起见，暂时不要配置此选项。请记住，完成此向导后，您始终可以将 web ACL 与一个或多个 AWS 资源关联！完成后，点击“下一步”继续：

1. 在命名 web ACL 后，我们进入下一个阶段，可以配置条件。在“创建条件”页面，选择您希望为您的 web 应用程序配置的适当条件。在此场景中，我们将配置一个 IP 匹配条件以及一个字符串匹配条件。目标是仅允许我的本地笔记本 IP 访问 WordPress 管理员登录页面（wp-login.php），而任何其他 IP 访问 wp-login.php 页面时，流量应被丢弃。

创建条件

如前所述，条件是您希望 WAF 监控的每个传入 Web 请求的可配置特性：

1. 要开始配置条件，请从 IP 匹配条件卡片中选择“创建条件”选项。

2. 在这里，为你的匹配条件提供一个合适的名称，并从 IP 版本中选择 IPv4 选项。在地址字段中提供你的桌面或笔记本电脑的公共 IP。你也可以使用支持的 CIDR 块提供一系列 IP 地址。

3. 请记得在创建匹配条件之前选择“添加 IP 地址或范围”选项：

1. 创建了 IP 匹配条件后，让我们继续为我们的 ACL 创建第二个条件。为此，请从字符串和正则匹配条件部分选择“创建条件”选项。

2. 我们再次通过为我们的字符串匹配条件提供一个合适的名称开始，然后选择与之匹配的字符串类型。在这里，首先选择字符串匹配选项。

3. 接下来，在请求过滤部分，选择你希望根据匹配条件过滤的请求部分。在我的例子中，我选择了 URI 选项，因为我们需要从 URI 中匹配资源wp-login.php。另外，你也可以根据需求选择以下值：

• • Header：用于匹配特定的请求头，如用户代理。

  • HTTPMethod：用于指示请求打算在源上执行的操作类型，如PUT、GET、DELETE等。

  • QueryString：用于定义 URL 中的查询字符串。

  • Body：用于匹配请求的主体。在这种情况下，WAF 仅检查请求主体中的前 8,192 字节（8KB）。你还可以设置大小限制条件，以阻止所有大于 8KB 的请求。

1. 接下来，在匹配类型下拉列表中，选择“包含”选项，如下图所示。“包含”选项意味着待匹配的字符串可以出现在请求的任何位置。你还可以根据需求从以下选项中进行选择：

• • ContainsWord：用于指定要在请求中匹配的特定值

  • 完全匹配：用于精确匹配字符串和请求值

  • 以...开始：用于检查请求开头的匹配字符串

  • 以...结束：用于检查请求结尾的匹配字符串

1. 转换字段在你需要在 WAF 检查请求之前重新格式化请求时非常有用。这可能包括转换为小写字母、HTML 解码、空白符规范化、URL 解码等。对于这个特定的用例，我们不需要对请求执行任何特定的转换，因此我选择了“无”选项。

2. 最后，在值匹配字段中，输入我们希望 WAF 在 Web 请求中搜索的文本（wp-login）。完成后，记得点击“添加过滤器”选项，然后再继续执行创建命令。

3. 完成此步骤后，我们的基本条件已设置完毕。或者，你可以根据你的标准和需求设置其他相关条件。完成后，选择下一步选项继续进行向导。

创建规则

在定义了条件后，我们将进入配置 WAF 的下一个重要方面：规则。规则基本上允许你将一个或多个条件组合成一个逻辑语句，之后可以用来允许、阻止或计数某个特定的传入请求：

1. 在创建规则页面，你现在可以合并我们之前创建的条件，并为每个规则分配相应的操作，例如允许、阻止或计数。要开始，选择创建规则选项。

2. 在创建规则弹出框中，我们将创建两个规则：一个规则基本上允许我从本地笔记本电脑访问 WordPress 管理员登录页面（wp-login.php），另一个规则阻止流量访问同一登录页面。让我们首先创建允许流量规则。

3. 为此，输入一个适当的规则名称。你会注意到，相应的 CloudWatch 指标名称字段也会自动填充为相同的名称。你可以根据需求选择更改此名称，或者保留其默认值。

4. 接下来，在规则类型下拉列表中，选择你希望此规则是常规规则还是评级规则。在此场景中，我选择了常规规则，如下图所示：

1. 完成后，继续进入添加条件部分，在这里我们可以将规则与一个或多个条件关联起来。首先选择适当的下拉选项来形成以下规则：

When a request: "Does": "Originate from an IP Address in": "<SELECT_YOUR_IP_ADDRESS_MATCH_CONDITION_HERE>"

这是你新规则应该是什么样子的，一旦正确设置完成，点击创建：

1. 在创建了“允许”规则后，我们再次使用相同的步骤来创建一个“阻止”规则。再次选择创建规则选项，并为规则提供一个适当的名称。与之前的情况类似，我在这里也选择了一个常规规则。

2. 接下来，在添加条件部分，我们首先添加一个匹配以下语句的条件：

When a request: "Does not": "Originate from an IP Address in": "<SELECT_YOUR_IP_ADDRESS_MATCH_CONDITION_HERE>"

1. 接下来，选择添加条件选项，添加字符串匹配条件：

When a request: "Does": "Match at least one of the filters in the string match condition": "<SELECT_YOUR_STRING_MATCH_CONDITION_HERE>"

这是在将条件添加到规则后，它应该是什么样子的：

1. 在设置好条件后，选择创建选项，最终创建你的阻止规则。

2. 现在你的两个规则已经创建完成，你应该能在添加规则到 Web ACL 页面中看到它们，如下图所示：

1. 在这里，请确保根据它们的优先级正确排序你的规则，通过选择所需的“顺序”选项。你还可以配置你的 Web ACL 的默认操作。只有当请求不匹配任何允许或阻止规则中提到的条件时，才会触发此默认操作。一旦你对配置感到满意，选择“审阅和创建”选项，如前所示。大功告成！你的基本 WAF 现在已经启动运行！

将 WAF Web ACL 分配给 CloudFront 分发

创建了 Web ACL 之后，你现在可以根据需求轻松地将其分配给一个或多个 CloudFront 分发。要做到这一点，只需登录到 AWS 控制台并过滤“CloudFront”服务，或者直接导航到console.aws.amazon.com/cloudfront/home直接查看 CloudFront 仪表板：

1. 一旦登录到 CloudFront 仪表板，选择你希望启用 WAF Web ACL 规则的适当分发 ID。

2. 从“常规”选项卡中选择“编辑”选项，以打开分发的配置和设置。

3. 在“编辑分发”页面中，从 AWS WAF Web ACL 下拉列表中选择你新创建的 Web ACL，如下图所示。

1. 一旦选择了 ACL，我还建议你启用你的分发日志记录，以防你还没有这样做。这只是一种额外的预防和安全措施，对于你可能正在工作的任何生产级环境都是必须的。在“编辑分发”页面上滚动到底部，并选择“日志记录”字段旁边的“打开”选项。在“日志记录桶的名称”字段中提供你的日志记录桶的名称，一旦所有必填字段都填写完毕，点击“是，编辑”选项。

更改将需要一些时间来传播到 CloudFront 分发中。一旦分发的“状态”更改为“已启用”，你可以开始测试你的 WAF。

要测试你的 WAF，请简单地打开浏览器，输入你的 WordPress 应用的 URL（<http://YOUR_CLOUDFRONT_URL>/wp-login.php）在你自己的笔记本电脑/台式机上。在这种情况下，你应该能够毫无问题地看到wp-login.php页面。但是，如果你尝试从不同的笔记本电脑或机器访问同一页面，你将在屏幕上看到以下错误：

在这一点上，你的 WordPress 管理员登录页面现在受到除了你在 Web ACL 允许列表中指定的 IP 之外的所有 IP 的保护！是不是很神奇？

你可以使用 CloudFront 分发设置创建自定义错误页面，并将用户重定向到此页面，而不是显示标准的错误页面，如前面截图所示。

到这里，我们即将结束本节的基本 Web ACL 配置内容。在下一节中，我们将探讨如何通过添加更多条件来增强您的基本 ACL 设置，重点关注 SQL 注入和跨站脚本攻击。

处理 SQL 注入和跨站脚本攻击条件

除了限制对特定 IP 地址集的访问外，WAF 还提供了防范更多攻击的能力，例如 SQL 注入和跨站脚本攻击。在本节中，我们将详细了解这两种条件，以及如何利用它们保护您的应用程序。

首先，让我们更详细地了解 SQL 注入。SQL 注入本质上是在客户端发出的请求中插入 SQL 查询，攻击目标是您的应用程序。

如果 SQL 注入成功实施，它可以读取并修改数据库中的敏感数据，甚至能够执行数据库的管理操作，比如从之前的备份文件恢复、完全关闭数据库等操作。

下面是一些常见条件及其关联配置的列表，您可以选择在 Web ACL 规则中应用它们：

HTTP 请求组件匹配	相关输入转换应用	理由
QUERY_STRING	URL_DECODE, HTML_ENTITY_DECODE	最常见的匹配组件。查询字符串参数常用于数据库查找。
URI	URL_DECODE, HTML_ENTITY_DECODE	如果您的应用使用友好或干净的 URL，那么参数可能会作为 URL 路径的一部分出现，而不是查询字符串的一部分。
BODY	URL_DECODE, HTML_ENTITY_DECODE	如果您的应用接受表单输入，这是一个常见的匹配组件。AWS WAF 仅评估正文内容的前 8 KB。
HEADER: Cookie	URL_DECODE, HTML_ENTITY	一个不太常见的匹配组件。如果您的应用在数据库查找中使用基于 Cookie 的参数，可以考虑匹配这个组件。
HEADER: Authorization	URL_DECODE, HTML_ENTITY_DECODE _DECODE	一个不太常见的匹配组件。如果您的应用使用该标头的值进行数据库验证，考虑匹配此组件。

要配置您自己的 SQL 注入条件和规则，请再次登录 WAF 仪表板，方法是访问 console.aws.amazon.com/waf/home。

1. 接下来，从导航窗格中选择 SQL 注入选项，然后选择创建条件以开始配置。

2. 在创建 SQL 注入匹配条件页面中，首先为您的新条件提供一个名称。您还可以选择是否要为您的 CloudFront CDN（全球）或单独的应用程序负载均衡器启用此条件。在这种情况下，我选择了全球（CloudFront）选项，如下图所示：

1. 接下来，在筛选设置部分，选择要筛选的请求的相应部分，以及相关的转换部分。如前所述，您可以参考 SQL 注入的常见条件表格。填写完值后，点击添加筛选器选项以完成该过程。

现在，这是一个非常实用的技巧！在某些情况下，您可能需要为 SQL 注入条件编写多个筛选器，依据您想要筛选的请求的不同部分，如 URI、查询字符串等。在这种情况下，建议在同一个 SQL 注入条件内创建多个筛选器，然后将该条件附加到 Web ACL 规则中。原因是，Web 请求只需要匹配 SQL 注入匹配条件中的一个筛选器，WAF 就会根据该条件允许或阻止请求。另一方面，如果您为每个 SQL 注入匹配条件仅添加一个筛选器，并且创建多个此类 SQL 注入条件，那么请求必须匹配所有条件，WAF 才会根据所有条件来允许或阻止该请求。

同样的设置也可以用于防护跨站脚本攻击（XSS）。跨站脚本通常发生在 Web 应用程序将用户提供的数据嵌入到网页中，并在没有正确清理的情况下发送到浏览器。如果数据没有经过适当验证或转义，攻击者可以利用这些向量将脚本、内联框架或其他对象嵌入渲染的页面中。这些攻击可以用于各种恶意目的，包括通过键盘记录器窃取用户凭据、安装系统恶意软件等。如果这些用户数据在服务器端的数据库中持续存在，并且随后被传递给更多的用户，攻击的影响将被放大。

以下是一些常见条件及其相关配置的列表，您可以选择应用于您的 Web ACL 规则中：

HTTP 请求组件匹配	应用的相关输入转换	理由
BODY	URL_DECODE, HTML_ENTITY_DECODE	如果您的应用程序接受表单输入，这是一个非常常见的组件。AWS WAF 只会评估前 8 KB 的正文内容。
QUERY_STRING	URL_DECODE, HTML_ENTITY_DECODE	如果查询字符串参数被反射回网页中，建议使用此设置。一个例子是分页列表中的当前页码。
HEADER: Cookie	URL_DECODE, HTML_ENTITY_DECODE	如果你的应用接受表单输入，这是一个常见的匹配组件。推荐在你的应用使用基于 Cookie 的参数并将其反射回网页时使用。例如，当前登录用户的名称存储在一个 Cookie 中，并嵌入在页面头部。WAF 仅评估正文内容的前 8KB。
URI	URL_DECODE, HTML_ENTITY_DECODE	不太常见，但如果你的应用使用友好的 URL，则参数可能作为 URL 路径的一部分出现，而不是查询字符串（这些参数随后会在服务器端被重写）。这与查询字符串存在类似的安全隐患。

要配置你自己的跨站脚本条件和规则，再次登录到你的 WAF 仪表板，访问console.aws.amazon.com/waf/home。

1. 接下来，从导航窗格中选择“跨站脚本”选项，然后在其中选择“创建条件”以开始操作。

2. 在创建跨站脚本匹配条件页面中，首先为你的新条件提供一个名称。你还可以选择是否启用该条件适用于 CloudFront CDN（全局）或单个应用负载均衡器。在这种情况下，我暂时选择了全局（CloudFront）选项。

3. 接下来，在“要过滤的请求部分”一栏中，选择你希望 WAF 过滤的请求部分。你可以选择 Header、HTTP 方法、查询字符串、URI 和 Body 作为有效参数。然而请注意，如果选择了 Header 选项，系统会提供一个额外的字段，在该字段中，你可以从头部列表中选择一个头部，或者直接输入头部名称。

4. 最后，选择你希望 WAF 在实际检查请求之前执行的适当转换操作。完成后，记得选择“添加过滤器”选项，然后完成条件的创建过程。

现在，你有两个额外的条件可以添加到现有的 Web ACL 中，或者你也可以继续创建一个新的 Web ACL。通过这种方式，你可以根据需求创建不同的过滤器和条件，并在需要时将其附加到 Web ACL 中。但是，这种手动设置规则和条件的方式，随着时间的推移可能会变得有些复杂，尤其是在没有专门的安全团队的情况下，如果你需要将 ACL 快速部署到环境中。接下来，我们将介绍如何解决这个问题。

使用 CloudFormation 自动化 WAF Web ACL 部署

与 Web ACL 配合使用时，有时可能会非常困难，特别是当您拥有一个大型分布式环境且不一定有专门的安全团队来定期创建和管理规则时。幸运的是，AWS 通过提供易于使用和定制的 CloudFormation 模板来简化这一过程，用户可以在短短几分钟内创建一个包含所有基本安全条件配置的单一 Web ACL！这一综合解决方案称为 AWS WAF 安全自动化，所有人都可以免费使用。最终用户只需指定所需的安全功能，进行配置并部署解决方案！剩下的工作完全由 AWS 负责！

AWS WAF 安全自动化解决方案的架构相对简单，包含了比 AWS WAF 更多的 AWS 服务，例如 AWS Lambda、Amazon CloudWatch、Amazon API Gateway 和 Amazon S3，如本节后面所示的图所示。

解决方案的核心是 WAF 服务，它作为做出所有与安全相关的决策和过滤的中央点。根据用户在 CloudFormation 模板配置中指定的输入，相应的解决方案组件会相应激活。这些组件在这里进一步解释：

• 蜜罐和反爬虫保护 (A)：此安全组件自动设置一个蜜罐，以诱使并偏转可能对您的应用程序发起的攻击。该解决方案为您提供一个 API Gateway 端点，您需要将其插入到您的 Web 应用中，作为陷阱来检测并诱使来自各种爬虫和抓取器的请求。如果某个来源访问了该陷阱请求，相关的 Lambda 函数将拦截该请求，收集其源 IP 地址，并将其添加到 WAF 的 Web ACL 阻止列表中。

• SQL 注入保护 (B) 和跨站脚本保护 (C)：选择此解决方案会创建两个 AWS WAF 规则，提供对常见 SQL 注入或跨站脚本模式的保护：

• HTTP 洪水、扫描器和探测器保护 (D)：也称为日志解析保护，当您需要分析 Web 应用的访问日志以查找可能导致潜在威胁的异常时，此解决方案非常有用。通过一个专门的 AWS Lambda 函数来解析存储在 CloudFormation 模板创建的 S3 存储桶中的访问日志。

• IP 地址白名单/黑名单 (E)：与 SQL 注入和跨站脚本解决方案类似，WAF 创建两个规则，允许您手动输入希望允许或阻止访问应用程序的 IP 地址。

• 已知攻击者保护（F）：此解决方案还利用了一个简单的 Lambda 函数，该函数监控某些第三方网站以获取潜在的 IP 地址列表，用于阻止威胁。这些网站包括 Spamhaus（www.spamhaus.org/drop/）、Proofpoint（rules.emergingthreats.net/fwrules/emerging-Block-IPs.txt）和 TOR（check.torproject.org/exit-addresses）等。

有了这些基本概念后，让我们迅速进入使用 CloudFormation 模板部署这些解决方案。撰写本书时，AWS WAF 安全自动化提供了两个模板供使用：一个用于基于 CloudFront CDN 的部署，另一个用于应用负载均衡器。两个模板都提供了一个默认配置，其中包括一个包含八组预配置规则的 web ACL，您可以根据需要随时更改或扩展这些规则。以下是下载相应模板的链接：

• 基于 CloudFront CDN 的模板: s3.amazonaws.com/solutions-reference/aws-waf-security-automations/latest/aws-waf-security-automations.template

• 基于应用负载均衡器的模板: s3.amazonaws.com/solutions-reference/aws-waf-security-automations/latest/aws-waf-security-automations-alb.template

您也可以复制这些链接并在 CloudFormation 中部署堆栈。

下载正确的模板后，我们现在可以继续使用 CloudFormation 配置和部署解决方案：

1. 为此，首先通过导航到 console.aws.amazon.com/cloudformation/home 登录到您的 CloudFormation 仪表盘。请注意，在本例中，我们将在 N.Virginia 区域部署基于 CloudFront CDN 的模板。

2. 在 CloudFormation 仪表盘中，选择“创建新堆栈”选项开始。在选择模板页面，您可以选择 上传 您下载的模板，或者仅在指定 Amazon S3 模板 URL 字段中复制模板的 URL，如下图所示。点击“下一步”继续设置：

1. 在指定详细信息页面，您可以通过为您的 CloudFormation 堆栈提供一个合适的堆栈名称来开始。

2. 然后，在“参数”部分，选择您希望选择的保护服务。请记住，这些是我们在本节开始时讨论过的服务。在这种情况下，我选择了一个相对简单的设置，包括启用对 SQL 注入、跨站脚本和恶意机器人防护。您也可以根据需要选择自己的保护服务。

3. 接下来，在 CloudFront 访问日志桶名称字段中，提供一个独特的名称，用于存储 Amazon CloudFront 访问日志的 S3 桶。您可以提供现有桶的名称或新建一个桶。

4. 最后，在“高级设置”部分，您还可以选择修改一些参数，如请求阈值、错误阈值和 WAF 阻止周期，以满足您的需求。如果您选择了 HTTP 洪水保护或启用扫描器与探测器保护，这些参数将非常有用，否则，您可以像我一样将这些值保持默认。选择“下一步”继续部署过程。

5. 在“选项”页面中，您可以为 CloudFormation 模板创建的资源指定标签，并选择提供任何特殊的IAM 角色，以允许 CloudFormation 创建、修改或删除堆栈中的资源。点击“下一步”查看所做的更改，然后在“审查”页面选择“创建”选项以开始堆栈的创建。

6. 堆栈部署成功需要花费几分钟。一旦完成，您可以通过检查“状态”栏来验证堆栈的完成状态，如下截图所示：

1. 此外，根据您的保护服务选择，您还可以验证模板为您的应用程序创建的其他输出，例如蜜罐端点，它实际上是一个 Amazon API Gateway 端点，您需要将其插入到应用程序中的某个位置，用来捕获机器人和爬虫。在我的案例中，模板创建了一个用于恶意爬虫的 Lambda 函数，针对 SQL 注入的 WAF 规则、IP 白名单和 XSS 检测，以及一个 API Gateway。

2. 堆栈成功运行后，您还可以返回 WAF 仪表板，查看模板自动填充的各个规则，针对一些保护服务。在这种情况下，SQL 注入 和 跨站脚本 条件已被自动填充；然而，IP 白名单 和 恶意机器人 规则仍然需要您手动提供 IP 范围和地址，或者允许 Lambda 函数在运行时将 IP 地址注入到列表中。以下是 SQL 注入条件创建的规则列表快照：

到这里，我们就结束了这一部分内容。你还可以使用这些模板为你的应用程序负载均衡器快速创建新的 Web ACL。记住，一旦测试完成，请删除你的堆栈，以避免产生不必要的费用。在下一部分中，我们将简要了解如何使用 AWS 提供的几个基本监控工具来有效监控你的 WAF 规则。

使用 CloudWatch 监控 WAF

监控你的 WAF 规则、条件以及应用程序的 Web 流量，对于识别和减轻可能的攻击和漏洞利用至关重要。AWS 提供了多种工具和服务，作为管理员的你可以利用它们来监控和报告此类活动。以下是简要说明的服务列表：

• AWS WAF 仪表盘：没错，你没看错！AWS WAF 还提供了一个简单的监控仪表盘，列出了通过 CloudFront CDN 或应用程序负载均衡器发送到你应用程序的总请求数量，以及实际匹配你指定规则的请求数量。要查看仪表盘，你只需要登录 AWS WAF，选择 Web ACL 页面，并点击 Requests 标签，如下图所示：

该图表按五分钟周期聚合和显示请求。你也可以使用 Amazon CloudWatch 打开相同的图表进行进一步分析。

• Amazon CloudWatch：Amazon CloudWatch 已经存在一段时间，并且提供了多种你可以选择和配置的指标，作为定制请求监控仪表盘的一部分。以下是支持的 WAF 指标列表及简要说明：

  • AllowedRequests：捕获被允许的 Web 请求数量。此指标的有效维度为 Rule 和 WebACL。

  • BlockedRequests：捕获被阻止的 Web 请求数量。此指标的有效维度为 Rule 和 WebACL。

  • CountedRequests：通常用于测试你的 Web ACL 和规则，这个指标提供了匹配特定规则中所有条件的 Web 请求计数。

你可以使用这些指标来监控你的 WAF 规则，甚至可以配置 CloudWatch 警报，当它们的阈值被超越时触发并发送通知。根据你的需求，你还可以进一步配置 CloudWatch 事件，触发相应的 Lambda 函数来缓解可能的攻击，正如我们在安全自动化解决方案中所执行的那样。你甚至可以利用 Amazon CloudWatch 来监控流入 CloudFront CDN 和应用程序负载均衡器的流量。

• AWS CloudTrail：AWS CloudTrail 是你可以并且应该利用的另一项服务，用于解析和分析你的应用程序访问和错误日志，以及 AWS 服务本身生成的日志。以下是一些由安全自动化解决方案自动创建的日志组，用于捕获 WAF 流量流动和事件。我们将在下一章深入探讨 AWS CloudTrail：

到这里，我们已经接近本章的结尾，但在我们结束之前，我想分享一些有趣的内容，我认为你作为 AWS WAF 的一部分应该尝试。

规划你的下一步

好吧，我们在本章中介绍了许多新的功能和服务。不过，我还是建议你自己阅读一些内容。首先要了解的是 AWS Shield 服务！

AWS Shield 介绍

AWS Shield 是 AWS WAF 的扩展，但其目标是提供针对潜在 DDoS 攻击的安全保护。它是一项完全托管的服务，提供始终在线的检测和自动化缓解功能，最大限度减少应用程序的停机时间和延迟。AWS Shield 提供两个服务级别：标准和高级：

• AWS Shield Standard：该服务不收取额外费用，默认启用在你的账户和 AWS 服务上，旨在保护你的 web 应用程序免受最常见和频繁发生的 DDoS 攻击。

• AWS Shield Advanced：旨在为你的 web 应用程序提供更高层次的保护，AWS Shield Advanced 适用于当前运行在弹性负载均衡器（Elastic Load Balancers）或应用程序负载均衡器（Application Load Balancers）、Amazon CloudFront 和 Amazon Route 53 资源上的应用程序。AWS Shield Advanced 还提供对潜在攻击的近实时可见性，并具备缓解能力。最棒的是，你还可以获得专门的 24x7 DDoS 响应团队 (DRT) 的支持，他们会关注你 web 应用程序上发生的潜在 DDoS 攻击，并提供快速的解决方案。

AWS Shield Advanced 的费用为每月 3,000 美元。

这是 AWS Shield 标准和高级服务之间的简要对比：

功能	AWS Shield Standard	AWS Shield Advanced
网络流量监控	是	是
自动化应用程序（第 7 层）流量监控	否	是
有助于防范常见的 DDoS 攻击，例如 SYN 洪水和 UDP 反射攻击	是	是
访问额外的 DDoS 缓解能力	否	是
第 3/4 层攻击通知及攻击取证和历史报告	否	是
高严重性事件期间的事件管理	否	是
攻击期间的自定义缓解措施	否	是
攻击后分析	否	是
补偿与 Route 53、CloudFront 和 ELB 相关的 DDoS 费用	否	是

要为您的环境启用 AWS Shield Advanced，只需登录到您的 AWS WAF 仪表盘，然后在导航窗格中的 AWS Shield 部分选择受保护资源选项。在这里，点击启用 AWS Shield Advanced 按钮，开始您的 Shield Advanced 保护计划。在此过程中，您将被要求选择一个特定的资源，以保护免受 DDoS 攻击。根据您希望保护的资源，选择您的 CloudFront CDN 或弹性/应用负载均衡器，并为您指定的保护资源提供一个合适的名称。最后，记得勾选启用复选框，以将您的资源与 Web ACL 关联（如果您已经创建了 Web ACL）。完成后，选择添加 DDoS 保护选项，完成！您的 AWS Shield Advanced 保护已经启动！很简单，不是吗？

总结

以下是本章中我们已经涵盖的主题的简要回顾。

我们首先学习并了解了 Web 应用防火墙服务的一些基本知识，以及它如何通过防止潜在的安全威胁和漏洞来保护应用程序。接下来，我们查看了如何通过利用 IP 匹配以及字符串/正则表达式匹配条件，来保护我们之前部署的 WordPress 应用免受限制性访问。我们还讨论了如何通过利用 WAF 高级条件（如 SQL 注入和跨站脚本攻击）来减轻和保护您的应用程序。最后，我们介绍了如何利用某些预构建的 CloudFormation 模板来自动部署我们的 WAF 规则，并以简要介绍 AWS Shield 及其不同层次作为本章的结束。

在下一章，我们将继续我们的安全之旅，并将介绍两个非常棒的服务：AWS CloudTrail 和 AWS Config，请继续关注！

第五章：使用 AWS CloudTrail 和 AWS Config 管理你的环境

在上一章中，我们学习了如何利用 AWS WAF 保护你的 web 应用免受常见的 web 攻击和漏洞利用。在这一章中，我们将探索两个非常有用且必不可少的安全和治理服务，即 AWS CloudTrail 和 AWS Config！

记住这一点，让我们快速看一下本章将涵盖的各种主题：

• 介绍 AWS CloudTrail、它的概念以及它是如何工作的

• 通过创建你自己的 Trail 为你的 AWS 环境启用 CloudTrail

• 使用 Amazon CloudWatch 集成和管理 CloudTrail 日志

• 使用 CloudFormation 为 CloudTrail 自动化 Amazon CloudWatch 警报

• 使用 Amazon Elasticsearch 查看 CloudTrail 日志

• 介绍 Amazon Config 及其工作原理

有很多事情要做，我们赶紧开始吧！

介绍 AWS CloudTrail

正如我们在上一章中了解到的，AWS 提供了多种工具和托管服务，帮助你保护运行在云上的应用，如 AWS WAF 和 AWS Shield。但这仅仅是一个更大拼图中的一个重要部分！那么合规性监控、风险审计以及环境的整体治理呢？你如何有效地分析环境中发生的事件并采取应对措施呢？幸运的是，AWS 为我们提供了解决问题的方法——AWS CloudTrail。

AWS CloudTrail 为你提供记录 AWS 账户内用户、服务、角色甚至 API 所采取的每一个操作的能力。每个记录的操作都被视为一个事件，之后可以分析这些事件来增强你的 AWS 环境的安全性。以下是启用 CloudTrail 后你可以获得的一些关键好处：

• 深入的可见性：使用 CloudTrail，你可以轻松获得账户使用情况的更好洞察，通过记录每个用户的活动，比如哪个用户发起了新的资源创建，这个请求是从哪个 IP 地址发起的，创建了哪些资源以及在何时创建等等！

• 更简单的合规性监控：通过 CloudTrail，你可以轻松地记录和记录发生在你的 AWS 账户内的事件，无论这些事件是来自管理控制台、AWS CLI，还是其他 AWS 工具和服务。最棒的是，你可以将 CloudTrail 与其他 AWS 服务（如 Amazon CloudWatch）集成，来警报和响应不合规事件。

• 安全自动化：正如我们在前一章所看到的，自动响应安全威胁不仅能够让你更快地减轻潜在威胁，还提供了一个机制来阻止所有后续攻击。AWS CloudTrail 同样适用！通过与 Amazon CloudWatch 事件的简单集成，你现在可以创建相应的 Lambda 函数，当合规性未达标时，自动触发这些函数，所有这些都可以在几秒钟内完成！

记住这些关键点后，让我们快速浏览一下 CloudTrail 的一些基本概念和术语：

• 事件：事件是 CloudTrail 中的基本计量单位。本质上，事件不过是记录某一特定活动的记录，这些活动可以是由 AWS 服务、角色或甚至 AWS 用户发起的。这些活动都作为 API 调用被记录，这些调用可以来自管理控制台、AWS SDK，甚至 AWS CLI。默认情况下，事件由 CloudTrail 与 S3 桶一起存储 7 天。你可以通过 CloudTrail 提供的事件历史功能查看、搜索，甚至下载这些事件。

• Trail：Trail 本质上是交付机制，通过它，事件被发送到 S3 桶中。你可以使用这些 Trail 记录特定桶中的特定事件，并且能够过滤事件以及加密传输的日志文件。默认情况下，每个 AWS 区域最多可以创建五个 Trail，且此限制无法增加。

• CloudTrail 日志：一旦你的 CloudTrail 开始捕获事件，它会将这些事件以 CloudTrail 日志文件的形式发送到 S3 桶中。日志文件是 JSON 文本文件，使用.gzip格式进行压缩。每个文件可以包含一个或多个事件。以下是 CloudTrail 日志的简单表示。在这个例子中，事件是我尝试通过 AWS 管理控制台将一个名为Mike的现有用户添加到管理员组时创建的：

{"Records": [{ 
    "eventVersion": "1.0", 
    "userIdentity": { 
        "type": "IAMUser", 
        "principalId": "12345678", 
        "arn": "arn:aws:iam::012345678910:user/yohan", 
        "accountId": "012345678910", 
        "accessKeyId": "AA34FG67GH89", 
        "userName": "Alice", 
        "sessionContext": {"attributes": { 
            "mfaAuthenticated": "false", 
            "creationDate": "2017-11-08T13:01:44Z" 
        }} 
    }, 
    "eventTime": "2017-11-08T13:09:44Z", 
    "eventSource": "iam.amazonaws.com", 
    "eventName": "AddUserToGroup", 
    "awsRegion": "us-east-1", 
    "sourceIPAddress": "127.0.0.1", 
    "userAgent": "AWSConsole", 
    "requestParameters": { 
        "userName": "Mike", 
        "groupName": "administrator" 
    }, 
    "responseElements": null 
}]} 

你可以通过访问在创建 Trail 时指定的 S3 桶来查看你自己的 CloudTrail 日志文件。每个日志文件都使用以下格式唯一命名：

AccountID_CloudTrail_RegionName_YYYYMMDDTHHmmZ_UniqueString.json.gz 

其中：

• AccountID: 你的 AWS 账户 ID。

• RegionName: 捕获事件的 AWS 区域：us-east-1，依此类推。

• YYYYMMDDTTHHmmz: 指定年份、月份、日期、小时（24 小时制）、分钟和秒数。z表示 UTC 时间。

• UniqueString: 一个随机生成的 16 字符长字符串，简单用于避免日志文件的覆盖。

了解了基础知识后，让我们快速看看如何开始在你自己的 AWS 环境中使用 CloudTrail！

使用 AWS CloudTrail

AWS CloudTrail 是一个相当简单且易于使用的服务，你可以在几分钟内开始使用。在本节中，我们将通过 AWS 管理控制台本身简单设置一个 CloudTrail Trail。

创建你的第一个 CloudTrail Trail

首先，登录到您的 AWS 管理控制台，并通过 AWS 服务筛选器过滤出 CloudTrail 服务。在 CloudTrail 仪表板上，选择“创建 Trail”选项以开始：

1. 这将打开创建 Trail 向导。使用此向导，您可以在每个区域创建最多五个 Trail。首先在 Trail 名称字段中输入一个合适的名称。

2. 接下来，您可以选择将 Trail 应用到所有区域，或者仅应用到您当前操作的区域。选择所有区域将使 CloudTrail 记录每个区域的事件，并将相应的日志文件导入您指定的 S3 存储桶。或者，选择只记录一个区域的事件将仅捕获该区域内的事件。在我的情况下，我选择仅为我当前工作的区域启用 Trail。在接下来的部分中，我们将学习如何使用 AWS CLI 更改此值：

1. 接下来，在管理事件部分，选择您希望捕获的 AWS 环境中的事件类型。默认情况下，CloudTrail 会记录所有在您的 AWS 账户中发生的管理事件。这些事件可以是 API 操作，例如由于调用 EC2 RunInstances 或 TerminateInstances 操作而引发的事件，或者甚至是非 API 类型的事件，例如用户登录到 AWS 管理控制台等。对于这个特定的使用案例，我选择记录所有管理事件。

选择只读选项将捕获所有 GET API 操作，而选择写入选项将仅捕获在您的 AWS 环境中发生的 PUT API 操作。

1. 接下来，在存储位置部分，提供一个合适的 S3 存储桶名称，用于存储您的 CloudTrail 日志文件。这个存储桶将存储所有您的 CloudTrail 日志文件，无论日志来自哪个区域。您还可以从 S3 存储桶选择字段中选择一个现有的存储桶：

1. 接下来，在高级部分，您可以选择性地配置日志文件前缀。默认情况下，日志将自动存储在类似文件夹的层级结构下，通常形式为 AWSLogs/ACCOUNT_ID/CloudTrail/REGION。

2. 您还可以选择通过 AWS KMS 密钥加密日志文件。强烈建议在生产环境中启用此功能。

3. 在启用日志文件验证字段中选择“是”将启用您验证已交付的日志文件完整性，确保它们在送达 S3 存储桶后没有被篡改。

4. 最后，您甚至可以启用 CloudTrail，以便每次新的日志文件被送到您的 S3 存储桶时，通过选择“是”来启用“每次日志文件交付时发送 SNS 通知”选项。这将为您提供一个附加选项，可以选择一个预定义的 SNS 主题，或者为这个特定的 CloudTrail 创建一个新的 SNS 主题。填写所有必填字段后，点击“创建”以继续。

到这里，您应该能够通过从 CloudTrail 仪表盘的导航窗格中选择“Trail”选项，查看新创建的 Trail，如下图所示：

查看和筛选捕获的 CloudTrail 日志和事件

创建完 Trail 后，您可以使用 CloudTrail 仪表盘导航窗格中的 事件历史 选项查看捕获的事件并进行筛选。在这里，您可以查看过去 7 天内捕获的事件，甚至可以通过使用一个或多个支持的筛选属性来筛选特定的事件。

这里是您可以与时间范围一起使用的筛选属性的快速查看，以提取所需的事件和日志：

• 事件 ID：每个由 CloudTrail 捕获的事件都有一个唯一的 ID，您可以通过它进行筛选和查看。

• 事件名称：事件的名称。例如，EC2 事件 RunInstances、DescribeInstances 等。

• 事件源：请求所针对的 AWS 服务。例如，iam.amazonaws.com 或 ec2.amazonaws.com。

• 资源名称：事件引用的资源的名称或 ID。例如，名为 useast-prod-wordpress-code 的存储桶，或者 EC2 实例的实例 ID i-1234567。

• 资源类型：事件引用的资源类型。例如，S3 的资源类型可以是 Bucket，EC2 的资源类型可以是 Instance，等等。

• 用户名：创建或执行该事件操作的用户的名称。例如，一个 IAM 用户登录到 AWS 管理控制台，等等：

一旦您选择了特定的筛选器并提供了其相关属性值，您可以使用时间范围来缩小搜索结果，基于预定义的时间窗口进行筛选。为了进一步分析，您还可以选择事件详细信息窗格中的“查看事件”选项。选择此选项将以 JSON 格式查看事件，如下所示的代码所示：

{ 
    "eventVersion": "1.05", 
    "userIdentity": { 
        "type": "IAMUser", 
        "principalId": "AIDAIZZ25SDDZAQTF2K3I", 
        "arn": "arn:aws:iam::01234567890:user/yohan", 
        "accountId": "01234567890", 
        "accessKeyId": "ASDF56HJERW9PQRST", 
        "userName": "yohan", 
        "sessionContext": { 
            "attributes": { 
                "mfaAuthenticated": "false", 
                "creationDate": "2017-11-07T08:13:26Z" 
            } 
        }, 
        "invokedBy": "signin.amazonaws.com" 
    }, 
    "eventTime": "2017-11-07T08:25:32Z", 
    "eventSource": "s3.amazonaws.com", 
    "eventName": "CreateBucket", 
    "awsRegion": "us-east-1", 
    "sourceIPAddress": "80.82.129.191", 
    "userAgent": "signin.amazonaws.com", 
    "requestParameters": { 
        "bucketName": "sometempbucketname" 
    }, 
    "responseElements": null, 
    "requestID": "163A30A312B21AB2", 
    "eventID": "e7b7dff6-f196-4358-be64-aae1f5e7fed6", 
    "eventType": "AwsApiCall", 
    "recipientAccountId": "01234567890" 
} 

您还可以选择下载图标，并选择是否希望使用“导出为 CSV”或“导出为 JSON”选项导出所有日志。

您还可以通过访问 CloudTrail S3 存储桶并根据需求下载各个压缩的 JSON 文件来下载日志文件。

到这里，我们已接近本节的结尾。您可以使用这些相同的步骤，创建不同的 Trail 来捕获数据以及管理活动。在下一节中，我们将看到如何利用 AWS CLI 来更新我们新创建的 Trail。

使用 AWS CLI 修改 CloudTrail Trail

设置好 Trail 后，您可以使用 AWS 管理控制台或 AWS CLI 来修改其设置。在此，我们将介绍如何使用 AWS CLI 对新创建的 Trail 进行简单的更改。在继续此部分之前，您需要确保已根据 docs.aws.amazon.com/cli/latest/userguide/installing.html 提供的指南在您的桌面/笔记本电脑上安装并配置了 AWS CLI。

一旦 CLI 安装并配置完毕，我们现在可以运行一些简单的命令来验证其有效性。首先，让我们使用 describe-trails 命令检查新创建的 Trail 状态，如下所示：

# aws cloudtrail describe-trails 

这将显示您的 CloudTrail Trails 的基本属性，如 Name、TrailARN、是否启用了日志文件验证以及该 Trail 是否为多区域 Trail 或仅属于一个区域。在此，IsMultiRegionTrail 的值设置为 false，这意味着该 Trail 仅会记录当前区域的事件，即 us-east-1。接下来，让我们使用 AWS CLI 修改这一设置。

为此，我们将使用 update-trail 命令：

# aws cloudtrail update-trail \ 
--name useast-prod-CloudTrail-01 \ 
--is-multi-region-trail 

以下代码将简单地将 IsMultiRegionTrail 值从 false 更改为 true。您可以通过之前执行的 describe-trails 命令来验证这一点。同样，您也可以使用 update-trail 命令来更改 CloudTrail Trail 的其他设置，比如启用日志文件验证功能，如下所示：

# aws cloudtrail update-trail \ 
--name useast-prod-CloudTrail-01 \ 
--enable-log-file-validation 

最后，您甚至可以使用 AWS CLI 执行 get-trail-status 命令来检查 Trail 的当前状态，如下所示：

# aws cloudtrail get-trail-status \ 
--name useast-prod-CloudTrail-01  

除了这些值之外，get-trail-status 命令还会额外显示两个字段（LatestNotificationError 和 LatestDeliveryError），用于显示 Amazon SNS 订阅失败或 CloudTrail Trail 在将事件写入 S3 存储桶时失败的情况。

完成此步骤后，我们将进入本章的下一个部分，在该部分中，我们将学习如何借助 CloudWatch Logs 有效地监控您的 Trails。

使用 CloudWatch 监控 CloudTrail 日志

使用 CloudTrail 的最佳功能之一是，您可以轻松将其与其他 AWS 服务集成，从而提升安全审计和治理体验。我们将在这里使用并探讨的一个服务是 Amazon CloudWatch。

使用 CloudWatch，您可以轻松设置自定义度量过滤器和一系列警报，当您的 AWS 环境中发生特定的安全或治理问题时，能够将通知发送给相应的人群。要开始使用 CloudWatch 与 CloudTrail，您首先需要配置 Trail，将捕获的日志事件发送到 CloudWatch Logs。这可以通过 AWS 管理控制台和 AWS CLI 轻松配置。接下来，一旦完成此步骤，您需要定义自定义 CloudWatch 度量过滤器，评估日志事件是否与特定模式匹配。一旦匹配，您可以进一步配置 CloudWatch 触发相应的警报、发送通知，甚至基于生成的警报类型执行补救措施。

这是 CloudTrail 与 CloudWatch 集成的示意图：

本节中，我们将使用 AWS CLI 将 Trail 的日志与 Amazon CloudWatch Logs 进行集成：

1. 首先，我们需要使用以下命令创建一个新的 CloudWatch 日志组：

# aws logs create-log-group --log-group-name useast-prod-CloudTrail-LG-01 

1. 接下来，您需要提取并记录新创建的日志组 ARN，以便进行后续步骤。为此，输入以下命令，并记录日志组的 ARN，如下所示：

# aws logs describe-log-groups

1. 成功创建日志组后，我们需要创建一个新的 IAM 角色，该角色将使 CloudTrail 能够将其日志发送到 CloudWatch 日志组。为此，我们首先需要创建一个策略文档，赋予 CloudTrail TrailAssumeRole权限。创建一个新文件，并将以下内容粘贴到该文件中。记得以.json扩展名创建该文件：

# vi policy.json 
{ 
  "Version": "2012-10-17", 
  "Statement": [ 
    { 
      "Sid": "", 
      "Effect": "Allow", 
      "Principal": { 
        "Service": "cloudtrail.amazonaws.com" 
      }, 
      "Action": "sts:AssumeRole" 
    } 
  ] 
} 

1. 创建文件后，使用create-role命令为 CloudTrail 创建具有所需权限的角色：

# aws iam create-role --role-name useast-prod-CloudTrail-Role-01 \ 
--assume-role-policy-document file://policy.json 

1. 执行此命令后，请记录下新创建角色的 ARN。接下来，将以下角色策略文档复制并粘贴到一个新文件中。此策略文档授予 CloudTrail 必要的权限，以便在您之前创建的日志组中创建 CloudWatch Logs 日志流，从而将 CloudTrail 事件传递到该日志流：

    # vi permissions.json
    {
      "Version": "2012-10-17",
      "Statement": [
        {

          "Sid": "CloudTrailCreateLogStream",
          "Effect": "Allow",
          "Action": [
            "logs:CreateLogStream"
          ],
          "Resource": [
            "<YOUR_LOG_GROUP_ARN>"
          ]

        },
        {
          "Sid": "CloudTrailPutLogEventsToCloudWatch",
          "Effect": "Allow",
          "Action": [
            "logs:PutLogEvents"
          ],
          "Resource": [
            "<YOUR_LOG_GROUP_ARN>"
          ]
        }
      ]
    }

1. 接下来，运行以下命令将权限应用于该角色。记得在这里提供我们在之前步骤中创建的策略名称：

# aws iam put-role-policy --role-name useast-prod-CloudTrail-Role-01 \ 

--policy-name cloudtrail-policy \ 
--policy-document file://permissions.json 

1. 最后一步是使用以下命令片段，更新 Trail，添加日志组 ARN 以及 CloudWatch Logs 角色 ARN：

# aws cloudtrail update-trail --name useast-prod-CloudTrail-01 \ 
 --cloud-watch-logs-log-group-arn <YOUR_LOG_GROUP_ARN> \ 
 --cloud-watch-logs-role-arn <YOUR_ROLE_ARN> 

到此为止，您已将 CloudTrail 日志与我们创建的 CloudWatch 日志组成功集成。您可以通过查看 CloudWatch 仪表板中的 CloudWatch Logs 部分下的日志组来验证这一点。

在下一节中，我们将利用新创建的日志组，为监控和警报目的分配自定义度量和警报。

创建用于监控 CloudTrail 日志的自定义度量过滤器和警报

在创建并将日志组与 CloudTrail Trail 集成后，我们现在可以继续创建并分配自定义度量过滤器和警报。每当 CloudTrail 识别出特定的合规性或治理问题时，这些警报可以用于触发通知。

首先，让我们通过 CloudWatch 日志创建一个自定义度量过滤器。在这个例子中，我们将创建一个简单的过滤器，每当对 S3 存储桶进行 API 调用时，就触发一个 CloudWatch 警报。这个 API 调用可以是对存储桶策略、生命周期等进行的简单 PUT 或 DELETE 操作：

1. 登录到您的 Amazon CloudWatch 仪表板，或者，您也可以通过以下链接开始：console.aws.amazon.com/cloudwatch/。

2. 登录后，从导航窗格中选择“日志”选项。选择我们之前创建的新日志组，并选择“创建度量过滤器”选项，如下图所示：

1. 在“创建度量过滤器并分配度量”页面中，首先为新度量提供一个合适的过滤器名称，然后将过滤器模式选项填写为以下片段：

{($.eventSource = s3.amazonaws.com) && (($.eventName = PutBucketAcl) || ($.eventName = PutBucketPolicy) || ($.eventName = PutBucketLifecycle) || ($.eventName = DeleteBucketPolicy) || ($.eventName = DeleteBucketLifecycle))} 

1. 完成后，输入一个合适的度量标准命名空间值，并随后输入度量名称。将其余值保持为默认值，选择“创建过滤器”选项以完成该过程。

2. 完成这一步后，您现在已经拥有一个正常工作的 CloudWatch 过滤器。为了为此过滤器分配警报，只需选择过滤器旁边的“创建警报”选项，如下图所示：

1. 创建警报是一个相当直接且简单的过程，我相信您完全有资格完成这项设置。首先为您的警报提供一个名称和可选的描述，然后通过设置事件计数为>= 1，在1个连续周期内配置触发器。接下来，记得在“操作”部分设置选择一个 SNS 通知列表，或者创建一个新的列表。所有设置完成后，选择“创建警报”选项以完成此过程。

完成这一步后，剩下的唯一任务就是试用过滤器！登录到您的 S3 仪表板并创建一个新存储桶，或者，您也可以更新现有存储桶的策略。CloudTrail Trail 会捕捉到这个变化，并将日志发送到您的 CloudWatch 日志组，在那里我们新创建的度量过滤器会触发一个警报，通知相关的云管理员！是不是很棒？您可以根据需求使用更多自定义过滤器和警报来配置 CloudWatch 的通知。

在下一节中，我们将讨论一种相当简单且自动化的方法，通过单个 CloudFormation 模板创建和部署多个 CloudWatch 警报。

自动化部署 AWS CloudTrail 的 CloudWatch 警报

如前一节所讨论的，你可以轻松地为监控你的 CloudTrail 日志文件创建不同的 CloudWatch 指标和警报。幸运的是，AWS 提供了一个非常简单且易于使用的 CloudFormation 模板，使你能够在几分钟内通过几个必要的警报快速启动！这个模板的最佳部分是，你可以通过添加自己的自定义警报和通知来扩展它。因此，不再多说，让我们开始吧。

该模板本身非常简单且易于使用。你可以在 s3-us-west-2.amazonaws.com/awscloudtrail/cloudwatch-alarms-for-cloudtrail-api-activity/CloudWatch_Alarms_for_CloudTrail_API_Activity.json 下载一个版本。

在撰写本书时，该模板支持为以下 AWS 资源集创建度量过滤器：

• 亚马逊 EC2 实例

• IAM 策略

• Internet 网关

• 网络 ACL

• 安全组

1. 要创建并启动这个 CloudFormation 堆栈，请通过导航到 console.aws.amazon.com/cloudformation 进入 CloudFormation 仪表板。

2. 接下来，选择“创建堆栈”选项，打开 CloudFormation 模板选择页面。将 s3-us-west-2.amazonaws.com/awscloudtrail/cloudwatch-alarms-for-cloudtrail-api-activity/CloudWatch_Alarms_for_CloudTrail_API_Activity.json 粘贴到“指定一个 Amazon S3 模板 URL”字段中，点击“下一步”继续。

3. 在“指定详细信息”页面，提供一个合适的堆栈名称，并填写以下必填参数：

   • 邮箱：一个有效的电子邮件地址，将接收所有 SNS 通知。模板成功部署后，你必须确认这个电子邮件订阅。

   • LogGroupName：我们在本章前面创建的日志组的名称。

4. 填写完必需的值后，点击“下一步”继续。审查模板设置后，在“审查”页面上选择“创建”选项完成过程。

该模板需要几分钟才能完成所需警报的创建和配置。以下是为你的环境创建的警报和指标的快照：

创建的资源的逻辑 ID	资源类型
AlarmNotificationTopic	AWS::SNS::Topic
AuthorizationFailuresAlarm	AWS::CloudWatch::Alarm
CloudTrailChangesAlarm	AWS::CloudWatch::Alarm
CloudTrailChangesMetricFilter	AWS::Logs::MetricFilter
ConsoleSignInFailuresAlarm	AWS::CloudWatch::Alarm
ConsoleSignInFailuresMetricFilter	AWS::Logs::MetricFilter
EC2InstanceChangesAlarm	AWS::CloudWatch::Alarm
EC2InstanceChangesMetricFilter	AWS::Logs::MetricFilter
EC2LargeInstanceChangesAlarm	AWS::CloudWatch::Alarm
EC2LargeInstanceChangesMetricFilter	AWS::Logs::MetricFilter
GatewayChangesAlarm	AWS::CloudWatch::Alarm
GatewayChangesMetricFilter	AWS::Logs::MetricFilter
IAMPolicyChangesAlarm	AWS::CloudWatch::Alarm
IAMPolicyChangesMetricFilter	AWS::Logs::MetricFilter
NetworkAclChangesAlarm	AWS::CloudWatch::Alarm
NetworkAclChangesMetricFilter	AWS::Logs::MetricFilter
SecurityGroupChangesAlarm	AWS::CloudWatch::Alarm
SecurityGroupChangesMetricFilter	AWS::Logs::MetricFilter
VpcChangesAlarm	AWS::CloudWatch::Alarm
VpcChangesMetricFilter	AWS::Logs::MetricFilter

到目前为止，我们已经了解了如何将 CloudTrail 的日志文件与 CloudWatch 日志组集成，以配置自定义指标以及通知的告警。那么，如何有效地分析和管理这些日志，尤其是在面对极其庞大的日志量时呢？这正是我们将在下一节中学习的内容，并且我们还将借助另一个强大的 AWS 服务——Amazon Elasticsearch！

使用 Amazon Elasticsearch 分析 CloudTrail 日志

许多组织的日志管理和分析开始和结束时，通常只有三个字母：E、L 和 K，它们分别代表 Elasticsearch、Logstash 和 Kibana。这三个开源产品基本上是一起使用，用于聚合、解析、搜索和可视化企业级日志：

• Logstash：Logstash 主要用作日志收集工具。它设计用于从多个来源（如应用程序、基础设施、操作系统、工具、服务等）收集、解析并存储日志。

• Elasticsearch：当所有日志都收集到一个地方后，你现在需要一个查询引擎来筛选和搜索这些日志中的特定事件。这正是 Elasticsearch 发挥作用的地方。Elasticsearch 基本上是一个基于流行信息检索软件库 Lucene 的搜索服务器。它提供了一个分布式的全文搜索引擎，并通过 RESTful Web 接口来查询日志。

• Kibana：Kibana 是一个开源的数据可视化插件，与 Elasticsearch 一起使用。它使你能够创建并导出日志，生成各种可视化图表，例如条形图、散点图、饼图等。

您可以轻松下载并安装这些组件到您的 AWS 环境，并在几个小时内启动并运行您自己的 ELK 堆栈！或者，您也可以利用 AWS 自有的 Elasticsearch 服务！Amazon Elasticsearch 是一种托管的 ELK 服务，可以根据您的需求快速部署、操作和扩展 ELK 堆栈。使用 Amazon Elasticsearch，您可以省去安装和管理 ELK 堆栈组件的麻烦，从长远来看，这将是一个更省心的选择。

对于此特定用例，我们将利用一个简单的 CloudFormation 模板，基本上会设置一个 Amazon Elasticsearch 域，用于过滤和可视化捕获的 CloudTrail 日志文件，如下图所示：

1. 要开始，请登录到 CloudFormation 仪表板，访问 console.aws.amazon.com/cloudformation。

2. 接下来，选择“创建堆栈”选项，进入 CloudFormation 模板选择页面。在“指定 Amazon S3 模板 URL”字段中粘贴 s3.amazonaws.com/concurrencylabs-cfn-templates/cloudtrail-es-cluster/cloudtrail-es-cluster.json，然后点击“下一步”继续。

3. 在指定详细信息页面，提供一个合适的堆栈名称，并填写以下必填参数：

   • AllowedIPForEsCluster: 提供将能够访问 nginx 代理的 IP 地址，从而能够访问您的 Elasticsearch 集群。在我的案例中，我提供了我的笔记本电脑的 IP。请注意，您可以在稍后阶段更改此 IP，方法是访问通过 CloudFormation 模板创建的 nginx 代理的安全组。

   • CloudTrailName: 我们在本章开始时设置的 CloudTrail 的名称。

   • KeyName: 您可以选择一个密钥对，用于获取 SSH 访问权限到您的 nginx 代理实例：

• • LogGroupName: 将作为输入到我们 Elasticsearch 集群的 CloudWatch 日志组名称。

  • ProxyInstanceTypeParameter: 您的代理实例的 EC2 实例类型。由于这是演示，我选择了 t2.micro 实例类型。您也可以选择其他实例类型。

1. 完成后，点击“下一步”继续。检查堆栈设置并点击“创建”以完成过程。

堆栈部署需要几分钟时间，因为新的 Elasticsearch 域正在创建。您可以通过查看 CloudFormation 的输出选项卡或通过查看 Elasticsearch 仪表板来监控部署进度。请注意，在此部署中，选择了默认的 t2.micro.elasticsearch 实例类型来部署 Elasticsearch。在将堆栈部署到生产环境之前，您应该将此值更改为更大的实例类型。

您可以在docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-supported-instance-types.html查看有关 Elasticsearch 支持的实例类型的信息。

堆栈成功部署后，复制来自 CloudFormation 输出标签的 Kibana URL：

"KibanaProxyEndpoint": "http://<NGINX_PROXY>/_plugin/kibana/"

Kibana UI 可能需要几分钟才能加载。一旦启动并运行，您将需要配置一些必要的参数，才能实际继续操作。选择设置并点击“索引”选项。在这里，填写以下详细信息：

• 索引包含基于时间的事件：启用此复选框以索引基于时间的事件

• 使用事件时间创建索引名称：也启用此复选框

• 索引模式间隔：从下拉列表中将索引模式间隔设置为每日

• 模式的索引名称：在此字段中输入[cwl-]YYYY.MM.DD

• 时间字段名称：从下拉列表中选择@timestamp 值

完成后，点击创建以完成该过程。这样，您现在应该可以开始看到日志填充到 Kibana 的仪表板上。随时查看并尝试 Kibana 提供的各种选项和过滤器：

呼！这确实涉及了很多内容！但等等，还有更多！AWS 还提供了另一个非常有用的治理和配置管理服务，我们也需要了解它，因此，接下来就介绍 AWS Config！

介绍 AWS Config

AWS Config 是另一种托管服务，属于安全与治理服务类别，它提供每个 AWS 资源配置设置的详细视图。这里的配置设置可以是任何内容，从对 EC2 实例或 VPC 子网的简单设置，到一个资源如何与另一个资源相关联，如 EC2 实例与 EBS 卷、ENI 等的关系。使用 AWS Config，您可以查看和比较过去对您的资源所做的配置更改，并在必要时采取相应的预防措施。

以下是您使用 AWS Config 可以实现的功能列表：

• 根据所需设置评估您的 AWS 资源配置

• 检索并查看一个或多个资源的历史配置

• 在创建、修改或删除特定资源时发送通知

• 获取您的资源的配置快照，您可以将其作为蓝图或模板进行后续使用

• 查看资源之间的关系和层次结构，例如属于特定网络子网的所有实例等

使用 AWS Config 可以通过设置治理策略和标准化资源配置，更有效地管理资源。每当配置变化违反规则时，您可以触发通知，甚至对变更进行补救。此外，AWS Config 还提供与 AWS CloudTrail 等工具的现成功能集成，为您的 AWS 环境提供完整的端到端审计和合规性监控解决方案。

在我们开始为自己的场景设置 AWS Config 之前，先快速浏览一些重要的概念和术语。

概念和术语

以下是一些你在使用 AWS Config 时需要牢记的关键概念和术语：

• 配置规则：配置规则是 AWS Config 操作的核心。这些规则本质上代表了特定 AWS 资源的期望配置设置。在服务监控资源的任何变化时，这些变化会映射到一个或多个配置规则，并根据规则标记资源是否存在不合规情况。AWS Config 提供了一些现成的规则，您可以直接使用，也可以根据需求进行自定义。或者，您还可以从头开始创建自定义规则。

• 配置项：配置项基本上是某个特定 AWS 资源配置的某一时刻的表示。该项可以包括关于资源的各种元数据，如其当前的配置属性、与其他 AWS 资源（如有）之间的关系、事件（如创建时间、上次更新时间等）。每当 AWS Config 检测到特定资源配置的变化时，都会自动创建配置项。

• 配置历史：某一资源在特定时间段内的配置项集合称为其配置历史。你可以使用此功能比较资源随着时间的推移可能发生的变化，从而决定采取必要的措施。配置历史存储在你指定的 Amazon S3 桶中。

• 配置快照：配置快照也是某个特定资源在一段时间内的配置项集合。此快照作为一个模板或基准，可以用来与资源当前的配置设置进行比较和验证。

牢记这些内容后，让我们看一些简单的步骤，让你在几分钟内开始设置自己的 AWS Config！

开始使用 AWS Config

开始使用 AWS Config 是一个非常简单的过程，通常只需要一两分钟的时间。总体而言，你需要首先指定希望 AWS Config 记录的资源，配置一个 Amazon SNS 主题以及一个 Amazon S3 桶用于通知和存储配置历史记录，最后添加一些 Config 规则来评估你的资源：

1. 首先，通过在 AWS 管理控制台中筛选该服务，或直接访问console.aws.amazon.com/config/来访问 AWS Config 仪表盘。

2. 由于这是我们第一次进行配置，选择“开始使用”选项以开始 Config 的创建过程。

3. 在“要记录的资源类型”部分，选择你希望 Config 监控的 AWS 资源类型。默认情况下，Config 将记录所有支持的 AWS 资源的活动。你可以选择仅指定你希望监控的服务，通过在“特定类型”字段中输入，如下图所示。在这种情况下，我选择了默认值：记录此区域支持的所有资源并包含全球资源：

1. 接下来，选择一个位置来存储你的配置历史记录以及配置快照。在这种情况下，我选择为 AWS Config 创建一个新的 S3 桶，并提供一个唯一的桶名称。

2. 接下来，在 Amazon SNS 主题部分，你可以选择创建一个新的 SNS 主题，该主题将向你指定的邮箱发送电子邮件通知，或者选择你账户中已有的主题。

3. 最后，你需要为 Config 提供一个只读访问角色，以便它能够记录特定的配置信息并将其发送到 S3 和 SNS。根据你的需求，你可以选择创建一个角色，或者选择一个已有的角色。点击保存以完成 AWS Config 的基本配置。

完成此步骤后，我们现在可以继续在设置中添加 Config 规则。为此，从 AWS Config 仪表盘的导航窗格中，选择规则并点击“添加规则”选项。

1. 在 AWS Config 规则页面，你可以使用提供的筛选器来筛选和查看预定义的规则。对于这个特定的场景，我们可以添加两个规则来检查账户中的 S3 桶是否存在禁止公共读取或禁止公共写入的情况。为此，只需在筛选器中输入 S3-bucket，然后选择其中一个规则，如下图所示：

• • 资源：当任何符合评估标准的资源被创建、修改或删除时

  • 标签：当具有指定标签的任何资源被创建、修改或删除时

  • 所有更改：当任何由 AWS Config 记录的资源被创建、修改或删除时

1. 选择特定规则将弹出该规则的配置页面，您可以在该页面中定义规则的触发器以及其范围。让我们首先选择 s3-bucket-public-read-prohibited 规则并进行操作。

2. 在“配置规则”页面中，为您的新规则提供合适的名称和描述。现在，由于这是一个托管规则，您将无法更改触发器类型；然而，当您创建自己的自定义规则时，您可以指定是否希望基于配置更改事件触发规则，或者使用周期性检查方法，利用您指定的时间频率来评估规则。

3. 接下来，您还可以选择希望规则评估发生的时间，方法是选择“变更范围”部分下提供的适当选项。在这种情况下，我选择了“资源”范围，并选择了 S3: 桶作为资源，如以下屏幕截图所示：

1. 可选地，您还可以通过“资源标识符”字段提供您希望配置监控的资源的 ARN。完成后，点击“保存”。

同样，使用上述步骤，创建另一个名为 s3-bucket-public-write-prohibited 的托管配置规则。

在设置好规则后，从配置的导航窗格中选择“资源”选项，查看当前已根据设定合规性评估的资源集。

在我的例子中，我的 AWS 环境中有两个 S3 桶：一个启用了公共读取权限，另一个没有。以下是您应看到的“已评估资源”仪表板：

在这里，您可以通过简单地选择具有相同名称的列中的资源名称，查看基于配置时间线评估的资源。这将显示您特定资源的配置状态的时间序列。您可以在不同的时间序列选项之间进行选择，查看状态变化，并使用日历图标在不同时间段之间切换。使用 config 这个功能的最佳部分是，您可以通过选择“管理资源”选项，同时更改资源的配置。这样做将自动打开 S3 桶的配置页面，如本例所示。您也可以从 AWS Config 导航窗格中选择“仪表板”选项，并获取您整体合规状态的可视化摘要，如以下屏幕截图所示：

您可以使用相同的概念为其他各种 AWS 服务创建更多这样的托管配置规则，包括 EC2、EBS、Auto Scaling、DynamoDB、RDS、Redshift、CloudWatch、IAM 等等！有关托管规则的完整列表，请查看docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html。

完成托管配置规则后，最后需要做的是创建一个自定义配置规则，这正是我们将在下一节中介绍的内容。

创建自定义配置规则

创建自定义配置规则的过程与之前的过程大致相同，只是在某些地方有所变化。在本节中，我们将探讨如何创建一个简单的合规规则，该规则将在用户启动除t2.micro实例类型以外的 EC2 实例时触发配置合规性警报：

1. 首先，从 AWS Config 导航窗格中选择“规则”选项，然后选择“添加自定义规则”按钮，进入“添加规则”页面。自定义规则的创建过程与其他规则相似，首先需要为规则提供适当的名称和描述。现在，实际的变化就在这里。自定义配置规则依赖于 AWS Lambda 来监控并触发合规检查。实际上，这正是完美的，因为 Lambda 函数是事件驱动的，非常适合托管我们自定义规则的业务逻辑。

2. 选择“创建 AWS Lambda 函数”以开始操作。在这里，我将使用一个预定义的 Lambda 蓝图，该蓝图实际上是为了与 AWS Config 配合工作而创建的。或者，您可以从头开始创建配置规则的业务逻辑，并将其部署到一个新的函数中。目前，请在蓝图过滤器中输入以下文本，如下截图所示（config-rule-change-triggered）：

1. 确保选择了蓝图，然后点击“下一步”继续。

2. 在函数的基本信息页面，为您的函数提供名称，然后从角色下拉列表中选择“从模板创建新角色”选项。该角色将为 Lambda 函数提供必要的权限，以便从 EC2 读取数据并将输出写回到 AWS Config，以及 Amazon CloudWatch。

3. 输入合适的角色名称，然后选择“创建函数”选项以完成过程。函数部署完成后，记下其 ARN，因为我们将在下一步中用到它。

4. 返回 AWS Config 的“添加自定义规则”页面，并将新创建的函数的 ARN 粘贴到 AWS Lambda 函数 ARN 文件中，如下图所示：

1. 将函数的 ARN 粘贴后，自定义规则的其余配置保持不变。与托管规则不同，您可以根据需要选择触发类型，选择“配置更改”或“定期”触发。在本例中，我选择了“配置更改”作为我的触发机制，并选择 EC2：实例 作为资源类型。

2. 最后但同样重要的是，我们还需要指定规则参数，这基本上是一个键值对，用于定义资源验证时所依据的属性。在本例中，desiredInstanceType 是键，t2.micro 是值。点击“保存”完成设置过程：

1. 配置好规则后，接下来要做的就是进行一次小测试！继续启动一个与 t2.micro 不同的新 EC2 实例。记住，实例必须在与您的 Lambda 函数相同的区域启动！当实例启动后，变更会立即在 AWS Config 的仪表盘中反映出来：

这样，我们就接近本节和本章的结束了！但是，在我们结束之前，以下是一些有趣的最佳实践和后续步骤，您在使用 AWS CloudTrail 和 AWS Config 时应牢记！

提示和最佳实践

以下是您在使用 AWS CloudTrail、AWS Config 和一般安全性时应牢记的一些重要提示和最佳实践：

• 定期分析和审计安全配置：虽然 AWS 提供了多种服务来保护您的云环境，但确保安全规则得到执行并定期验证是否存在潜在的配置错误，是组织的责任。

• 为所有用户提供完整的审计轨迹：确保跟踪每个用户（包括 root 用户、IAM 用户和联合用户）的所有资源创建、修改和终止操作。

• 全局启用 CloudTrail：通过在全局范围内启用日志记录，CloudTrail 可以捕获所有 AWS 服务的日志，包括全球性的服务，如 IAM、CloudFront 等。

• 启用 CloudTrail 日志文件验证：这是一个可选设置，但始终建议启用 CloudTrail 日志文件验证，以增加数据的完整性和安全性。

• 为 CloudTrail 和配置存储桶启用访问日志：由于 CloudTrail 和配置使用 S3 存储桶来存储捕获的日志，因此始终建议启用访问跟踪，以记录不当和未经授权的访问。或者，您也可以将日志和存储桶的访问限制给专门的用户组。

• 加密静态日志文件：对静态日志文件进行加密为日志数据提供了额外的保护层，防止未经授权查看或编辑日志数据。

总结

这一章确实非常有趣！在我们进入下一章之前，让我们快速回顾一下迄今为止学到的内容！

我们在本章开始时简要概述了 AWS CloudTrail，并提供了一个关于如何开始使用自己 CloudTrail Trail 的小型逐步指南。我们还学习了 AWS CloudTrail 日志及其与 Amazon CloudWatch Logs 的集成功能，以便提供更好的警报和通知功能。我们还利用了几个 CloudFormation 模板来部署预配置的 CloudWatch 警报，以便监控我们的 Trail，并设置了一个完整的 Amazon Elasticsearch 域来查看和筛选 CloudTrail 日志。最后，我们还介绍了 AWS Config 作为一个配置管理和合规性服务，通过部署托管的以及自定义的配置规则。

在下一章，我们将继续并结束我们的安全之旅，介绍两个非常棒的服务：AWS IAM 和 AWS Organizations，敬请期待！

第六章：使用 AWS IAM 和 AWS Organizations 进行访问控制

在上一章中，我们学习并探索了如何利用两个 AWS 服务——AWS Config 和 AWS CloudTrail 来管理你的云环境。在本章中，我们将继续安全之旅，重新审视 AWS IAM 并介绍一些实用功能，同时还会学习另一个服务——AWS Organizations！

牢记这一点，让我们快速看一下本章将要涵盖的各个主题：

• AWS IAM 的新功能

• 使用 IAM 可视化编辑器创建策略

• 使用 IAM 策略模拟器测试你的 IAM 策略

• 介绍 AWS Organizations 及其一些基本概念和术语

• 使用 AWS 管理控制台和 AWS CLI 创建你自己的组织

AWS IAM 的新功能

在我们查看 IAM 最近的增强功能之前，这里为没有接触过的朋友提供一个 IAM 的简短速成课程。AWS 身份与访问管理（IAM）是一个提供安全访问控制机制的 Web 服务，适用于所有 AWS 服务。你可以使用 IAM 创建用户和组，分配用户特定的权限和策略等等。最棒的是，IAM 完全免费！没错！使用它不需要支付一分钱。

让我们快速浏览一些 AWS IAM 提供的有趣功能：

• 多因素身份验证：IAM 允许你为用户提供双因素身份验证以增强安全性。这意味着，除了密码外，你还需要提供来自特殊硬件设备（如硬件令牌）或软件应用程序（如 Google Authenticator）的密钥/密码。

• 与其他 AWS 产品的集成：IAM 与几乎所有 AWS 产品和服务集成，并且可以根据需要为每个服务提供细粒度的访问权限和权限。

• 身份联合：你是否已经有一个本地 Active Directory，其中包含已创建的用户和组？没问题，IAM 可以与本地 AD 集成，通过一些简单步骤提供访问你的 AWS 账户的权限。

• 访问机制：IAM 可以通过多种工具访问，最常用且最频繁使用的是 AWS 管理控制台。除此之外，IAM 还可以通过 AWS CLI 访问，通过支持不同平台和编程语言的 SDK（如 Java、.NET、Python、Ruby 等）访问，甚至可以通过一个安全的 HTTPS API 进行编程访问。

牢记这些基础知识后，让我们来看看近年来对 IAM 进行的一些有趣和有用的增强功能。

使用可视化编辑器创建 IAM 策略

IAM 策略用于定义 IAM 实体（如用户、组和角色）的权限。你创建的每个策略由一个或多个语句组成，这些语句包含以下元素：

• 效果：此元素决定策略语句是否允许或明确拒绝对特定 IAM 资源的访问。

• 操作：操作用于在策略中定义 AWS 服务操作，例如，您可以指定与 Amazon S3 相关的操作，如列出存储桶、读取或写入存储桶等。

• 资源：资源是指 AWS 服务或单个实体，操作将在其上应用。

• 条件：条件用于定义在某个资源上何时允许或拒绝特定权限。您可以利用一个或多个条件来为 AWS 资源提供更细粒度的安全性。

创建策略后，您需要将其附加到资源上，资源可以是 IAM 用户、组或角色。然而，创建自定义且细粒度的 IAM 策略有时会带来挑战，尤其是当您刚开始使用 AWS 时。为了解决这个问题，AWS 提供了一个新的改进版可视化编辑器，您可以轻松地使用它创建自定义策略：

1. 要开始使用可视化编辑器，首先登录到 IAM 管理控制台，选择此 URL console.aws.amazon.com/iam/home。

2. 登录后，从导航窗格中选择“策略”选项。这将显示一个页面，列出 AWS 托管策略和客户托管策略。要创建策略，只需选择“创建策略”选项。在这个场景中，我们将创建一个简单的 S3 策略，仅授予对 S3 存储桶内单个文件夹的完全访问权限。

3. 在“创建策略”页面上，确保选择了“可视化编辑器”标签，然后点击“选择服务”选项以筛选并选择 Amazon S3。

4. 选择服务后，接下来点击“选择操作”选项，添加适合我们策略的操作。在这里，您可以通过选择手动添加操作或通过选择每个访问级别中的正确访问权限，选择资源的适当访问级别。在此示例中，我选择了权限的整个列表级别，并从读取访问级别中选择了s3:GetObject，随后又从写入访问级别中选择了s3:PutObject和s3:DeleteObject权限。以下是您参考的操作截图：

默认情况下，这里选定的所有操作都将被允许。如果要明确拒绝某些操作，请选择“切换到拒绝权限”选项，该选项位于“操作”部分。

1. 完成后，您可以选择“资源”部分，将所有或特定的资源添加到新的权限集。在此情况下，我们将权限集添加到一个名为useast-prod-stuff-01的特定存储桶中。为此，请选择与存储桶字段相邻的“添加 ARN”选项。

2. 在“添加 ARN(s)”对话框中，在“存储桶名称”字段中输入所选存储桶的名称，如以下截图所示。完成后，选择“添加”以完成此过程：

1. 完成后，你还可以选择为对象级别添加权限。点击对象字段旁边的“添加 ARN”选项，填写所需信息，就像我们在前面步骤中操作的那样。唯一的附加项是，你可以在对象名称字段中提供额外的文件夹名称，以便更精细地控制权限。完成后，点击“添加”以完成此过程。以下是我们策略完成的资源分配截图：

1. 在设置了权限和资源之后，你还可以选择向策略中添加条件。为此，选择“指定请求条件”选项。在这里，你可以选择并编辑符合需求的条件。例如，对于此策略，我们希望用户仅能从组织的内部网络访问特定的 S3 存储桶。为此，选择“源 IP”选项，并根据组织的 IP 范围输入合适的 IP 范围或单个 IP 地址。

2. 你还可以通过选择“添加请求条件”选项向策略中添加额外的条件。在这里，你可以使用条件键、限定符和操作符的组合，定制和指定更精细的条件，以下截图展示了这一过程：

在这里，条件将检查并允许只有用户名为 joe 的特定 AWS IAM 用户访问 S3 存储桶。你可以使用相同的方法创建自己的自定义条件，完成后点击“添加”以完成此过程。

1. 在设置了权限、资源和条件后，选择“审查策略”选项以完成策略创建过程。在选择“创建策略”选项之前，为你的策略提供一个合适的名称和可选的描述。

就是这样！简单吧，是吧！你可以使用相同的流程，轻松创建高度自定义和精细化的策略。然而，仍然有一个问题没有解答：我们如何在不发出实际请求的情况下测试和排查策略？这正是 IAM 策略模拟器的作用所在！

使用 IAM 策略模拟器测试 IAM 策略

创建好新策略后，接下来的步骤是将其附加到 IAM 用户或组，并进行测试。但你如何在不发出任何实际调用或请求的情况下有效地测试新策略呢？这正是新的 IAM 策略模拟器派上用场的地方！

IAM 策略模拟器用于评估 IAM 策略，以确定你可以指定的最有效的权限和操作集，而无需实际调用任何资源。策略模拟器内部利用与处理真实请求到 AWS 资源的策略评估引擎相同的引擎；然而，它本身并不进行任何实际的服务请求。因此，策略模拟器无法报告从生成的请求中得到的任何响应。你所得到的结果只是该策略是否允许或拒绝某个特定操作。以下是你可以利用 IAM 策略模拟器的一些方法：

• 你可以使用 IAM 策略模拟器来测试附加到现有用户、组和角色上的策略。

• 你也可以通过简单地复制并执行策略到模拟器，来测试那些尚未附加到你的资源上的策略。

• 模拟器还可以用于测试附加到各种 AWS 资源上的策略，比如 Amazon S3 桶、Amazon EC2 实例等。

• 你甚至可以通过传递各种上下文键（例如IP 地址或用户名），这些键与策略的条件一起传递，从而使用模拟器测试真实世界的场景，等等！

要开始使用 IAM 策略模拟器，只需选择这个网址policysim.aws.amazon.com/。策略模拟器是一个独立的实体，运行在你的标准 AWS 控制台之外。如果需要，请使用你的标准 AWS IAM 凭证登录到策略模拟器：

1. 登录后，你可以使用模拟器测试和验证现有的用户、组甚至基于角色的策略。首先，让我们测试一下我们在本章前面部分创建的策略！为此，在“用户、组和角色”部分，从下拉列表中选择“用户”。你应该能看到你的 AWS 账户中存在的用户列表。

2. 选择用于附加策略的适当用户。在我的例子中，用户名是joe。选择后，你将看到该用户当前关联的所有策略，在本例中，我们应该能看到我们在前面部分创建的自定义 S3 访问策略，如下图所示：

1. 选择策略以查看其详细信息。你甚至可以选择修改并在这里使用内置的策略编辑器来测试该策略，但请注意，在这里对策略所做的更改不会反映到实际的策略中。

2. 选择策略后，我们现在准备使用 IAM 策略模拟器部分来测试它。下面是我们将要测试的策略片段：

        { 
            "Sid": "VisualEditor0", 
            "Effect": "Allow", 
            "Action": [ 
                "s3:PutObject", 
                "s3:GetObject", 
                "s3:ListBucket", 
                "s3:DeleteObject" 
            ], 
            "Resource": [ 
                "arn:aws:s3:::useast-prod-stuff-01", 
                "arn:aws:s3:::useast-prod-stuff-01/Dummy" 
            ], 
            "Condition": { 
                "IpAddress": { 
                    "aws:SourceIp": "10.0.0.0/24" 
                }, 
                "ForAllValues:StringEqualsIfExists": { 
                    "aws:username": "joe" 
                } 
            } 
        } 
          . . . . . .  

            "Resource": "*", 
            "Condition": { 
                "IpAddress": { 
                    "aws:SourceIp": "10.0.0.0/24" 
                }, 
                "ForAllValues:StringEqualsIfExists": { 
                    "aws:username": "joe" 
                } 
            } 
        } 

根据我们的策略，只有用户joe拥有s3:PutObject、s3:GetObject、s3:ListBucket、s3:DeleteObject等权限，且只有当 Joe 从他所在组织的内部网络（10.0.0.0/24）访问useast-prod-stuff-01桶时才有效。

1. 要进行测试，请从“选择服务”下拉列表中选择 Amazon S3 选项。接下来，使用“选择操作”下拉列表匹配任一操作。在这种情况下，我只选择了s3:PutObject操作。

2. 完成后，在“全局设置”部分，输入与策略中出现的条件键相邻的值。在这种情况下，输入用户名和源 IP，如下图所示：

1. 接下来，在“操作设置和结果”部分，展开资源，并输入需要测试的策略对应的资源 ARN。在这种情况下，必须是 S3 桶的 ARN arn:aws:s3:::useast-prod-stuff-01。完成后，选择“运行模拟”选项。

在模拟运行过程中，您应该会根据在模拟过程中提供的值看到允许或拒绝的结果。您可以随意更改操作和条件键，并重新运行模拟。每次尝试后，您可以微调并排查策略问题，而无需真正向资源发出任何实际请求。

您还可以使用相同的策略模拟器来测试尚未附加到资源的新的策略。为此，您首先需要通过模拟器顶部提供的模式选项，将当前的（默认）现有策略模式切换为新策略模式。

一旦选择了“新策略”选项，您可以使用策略沙箱来创建新策略，并像之前一样测试它们。不过请记住，在此创建或编辑的策略不会反映到 AWS IAM 中。

至此，我们接近本节的结束。在下一节中，我们将介绍如何利用 AWS Organizations 轻松有效地管理多个 AWS 账户。

介绍 AWS Organizations

到目前为止，我们一直使用单一的 AWS 账户进行开发、测试和生产，但许多组织并非如此，他们会为了多个用途（如多个环境、合规问题等）拥有多个 AWS 账户。每个账户都有自己独特的管理方式，并没有集中式的所有权或控制。

AWS Organizations 是一个简单的服务，允许您集中管理多个 AWS 账户。它使您能够将 AWS 账户分组为一个或多个集体组织，您可以像管理一个整体一样进行创建和管理。

下面是一些 AWS Organizations 的关键概念和术语的简要介绍：

• 组织：组织是您所有 AWS 账户的集中视图，统一管理。通过组织，您可以在一个地方集中查看和管理所有 AWS 账户。组织提供了一项附加功能，您可以通过它来决定希望创建的组织类型。有两个此类功能集，即：

• 合并计费：AWS Organizations 提供的一个关键功能是能够查看并将每个 AWS 账户的计费合并到一个组织下。当您首次创建组织时，默认会选择此功能，并仅为您提供合并计费视图。要利用所有 AWS Organizations 的高级功能，您需要选择“全部功能”选项。

• 全部功能：此功能集提供了 AWS Organizations 的完整功能，包括合并计费以及许多其他功能，使您能够更好地控制您的各个账户。使用此功能集，您可以限制某些 AWS 服务的账户访问；修改访问角色等更多操作。

• 根：根是您在 AWS 中使用的所有单个账户的主要容器。当您首次创建组织时，AWS Organizations 会自动为您创建一个默认的根元素。任何在根级别应用的更改或策略都会传播到其后续的子元素。

• 组织单位（OU）：OU 是一个包含一个或多个 AWS 账户的容器。您还可以从单个 OU 分支出多个 OU，但 OU 的终点始终是一个账户。以下是一个示意图，展示了组织、根元素、OU 和各种 AWS 账户之间的交互关系：

• 账户：账户是包含您 AWS 资源的标准 AWS 账户。在创建组织时，AWS 将创建组织的账户标记为 主账户。稍后添加到此组织的任何其他账户都称为 成员账户。主账户还负责监督合并计费和为其他成员账户进行支付，并且可以用于邀请其他 AWS 账户加入组织、创建 OU、管理策略等。

• 服务控制策略（SCP）：SCP 本质上是附加到根、账户或组织单位（OU）上的策略，用于指定特定账户或 OU 的用户可以使用的服务和操作。例如，您可以在一个针对 HIPAA 合规性创建的账户上使用 SCP，并希望限制该账户的所有用户仅使用符合 HIPAA 合规的 AWS 服务，等等。

要了解更多关于 HIPAA 合规性以及它如何与 AWS 一起工作，请访问此 URL 了解更多信息 aws.amazon.com/compliance/hipaa-compliance/。

这里需要记住一个重要点：SCP 只有在您启用创建组织时的“全部功能”功能集时才会生效。

了解这些基本信息后，让我们看看如何通过几个简单的步骤开始使用 AWS Organizations。

开始使用 AWS Organizations

AWS Organizations 可以通过 AWS 管理控制台和 AWS CLI 进行设置。在本节中，我们将探索简单的步骤，您可以通过这些步骤在几分钟内开始使用自己的组织：

1. 从 AWS 管理控制台，使用“筛选”选项过滤出 AWS Organizations，或者直接访问此 URL console.aws.amazon.com/organizations/。

2. 由于这是我们第一次设置 AWS 组织，因此此帐户将被转变为主帐户。添加或创建到该主帐户的任何其他 AWS 帐户将被视为成员帐户。点击“创建组织”以开始操作。

3. 在创建组织时，您可以选择启用“启用所有功能”或“仅启用合并账单”选项，具体取决于您的需求。在此场景中，选择“启用所有功能”，然后在完成后点击“创建组织”。

4. 创建组织后，您应该可以在帐户页面上看到现有帐户，如下图所示。选择“添加帐户”选项，将新 AWS 帐户添加到我们的组织中：

1. 如前所述，AWS Organizations 允许您将现有的 AWS 帐户添加到新组织中，并作为主帐户的一部分创建新帐户。在此场景中，我们将继续创建一个名为 sandbox 的新帐户。在“添加帐户”页面选择“创建帐户”选项。

2. 在“全名”和“电子邮件”字段中分别为您的新帐户提供合适的名称和电子邮件地址。您提供的电子邮件必须是全球唯一的，因此请提供一个之前未在 AWS 使用过的电子邮件地址。

3. 接下来，在 IAM 角色名称字段中，为您的帐户提供一个合适的角色名称。此角色将使您能够在作为主帐户中的 IAM 用户登录时访问新成员帐户。完成后，点击“创建”完成该过程。

这是 AWS 创建的 IAM 角色的片段。该角色授予对新帐户中所有 AWS 服务和资源的完全访问权限：

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Effect": "Allow", 
            "Action": "*", 
            "Resource": "*" 
        } 
    ] 
}

帐户创建过程需要几分钟时间。一旦完成，您应该会看到名为 Sandbox 的新帐户以及新的帐户 ID，也会出现在 AWS Organizations 的帐户页面中。选择 sandbox 帐户，查看其关联的 ARN 和 ID，显示在旁边的窗格中。

创建帐户后，下一步是创建一个或多个组织单元（OU），并将新创建的帐户移入该 OU。在此场景中，我们将继续创建一个名为 Sandbox 的 OU：

1. 从 AWS Organizations 仪表板中选择“组织帐户”选项卡，以查看组织的当前层级设置。在“组织单元”部分，选择“+ 新建组织单元”选项以开始操作。

2. 在“创建组织单元”对话框中，在“组织单元名称”字段中提供新 OU 的合适名称，如下图所示。完成后，点击“创建组织单元”：

1. 创建完 OU 后，过程的最后一步是将账户移动到新创建的 OU 中。为此，从相同的“组织账户”页面，选择“沙盒”账户并点击“移动”。

2. 这将弹出一个简单的界面，您需要在其中选择要将沙盒账户移动到的新 OU。选择“沙盒”OU，点击“移动”以完成过程。

完成此步骤后，您应该会在新 OU 中看到一个新的账户。您可以使用相同的步骤根据需求创建多个 OU 和账户。您还可以通过为新账户创建并分配新的 SCP，进一步限制其访问服务：

1. 要创建新的 SCP，请在 AWS 组织仪表板上选择“策略”选项卡。您应该会看到一个默认的名为FullAWSAccess的策略。这个策略是 AWS 在您第一次创建 AWS 组织时自动创建的。沙盒环境目前也引用了相同的策略。

2. 要创建新的 SCP，请选择“创建策略”选项。AWS 组织在创建新 SCP 时提供两种选择。您可以选择利用策略生成器，从列表中选择特定服务和操作，构建自定义策略；或者选择复制现有的 SCP 并手动编辑。此处请选择“策略生成器”选项。

3. 接下来，提供一个策略名称和描述，然后选择策略在应用的 AWS 账户上应该具有的效果。

AWS Organizations 允许您根据需求对服务进行白名单（允许）或黑名单（拒绝）。将服务列入黑名单会导致策略中列出的所有服务默认被阻止，而将服务列入白名单则会阻止所有未在策略中列出的服务 API。接下来，我们将为沙盒 OU 创建一个简单的策略，允许使用 EC2、S3 和 RDS 服务，同时明确阻止 AWS CloudTrail。

1. 在“选择总体效果”部分，选择“允许”以首先创建服务的白名单。使用语句生成器选择正确的服务及其相应的操作。完成后，点击“添加语句”以添加更多服务和操作，如下图所示：

1. 添加完所需的语句后，直接选择“创建策略”选项以完成该过程。

2. 创建策略后，你可以将其附加到现有帐户、组织单位（OU）或甚至根目录，只需从策略页面选择策略，并根据需要选择根目录、帐户或组织单位选项。然而，在继续之前，你需要首先为根帐户启用 SCP 策略类型。为此，请从“组织帐户”选项卡中选择“根目录”选项。在相邻的详细信息窗格中，在“服务控制策略”部分旁边选择启用。

3. 完成此步骤后，你现在可以继续将新创建的策略附加到组织中的实体。记住，通过将策略附加到根域，你实际上也将策略传播到其成员中。这包括你可能已创建的子组织单位（OUs）和帐户。然而，对于此特定情况，请选择“帐户”选项，并点击列表中“沙盒”环境下方的“附加”选项。

就这样！这是一个简单的方法，通过它你可以轻松创建和管理你的 AWS 帐户。接下来，我们将展示如何通过 AWS CLI 实现相同的结果。

使用 CLI 创建和管理 AWS 帐户、OUs 和 SCPs 有其独特的优势。例如，你可以轻松自动化整个帐户创建过程，加快速度并简化新团队在组织中的入驻等：

1. 本练习的第一步是创建组织并设置为使用所有功能，正如我们在 AWS 管理控制台中所做的那样。为此，请输入如下命令：

# aws organizations create-organization --feature-set ALL

然而，对于已经将 AWS 帐户与组织关联的用户，这条命令可能会导致错误消息。

你也可以根据组织的需求，将 CONSOLIDATED_BILLING 值传递给 --feature-set 参数。

1. 组织就绪后，接下来我们将为我们的组织创建一个 AWS 帐户，但在此之前，我们需要执行一条命令来获取组织根目录的 ID。该 ID 将采用 r-<XY00> 的格式。请记下此 ID 以便后续步骤使用：

# aws organizations list-roots

1. 记下根目录 ID 后，输入以下命令来创建新帐户。在此情况下，我们将创建一个名为 prod 的新帐户。记得将 <EMAIL_ID> 字段替换为一个全球唯一的值：

# aws organizations create-account
--email <EMAIL_ID>
--account-name prod

下面是命令输出的快照。请记下新帐户的状态 ID，格式为 car-<UNIQUE_ID>，如以下截图所示：

1. 你可以使用此状态 ID 来检查帐户创建是否成功，通过输入以下命令。将 car-<UNIQUE_ID> 替换为之前步骤中复制的值：

# aws organizations describe-create-account-status
--create-account-request-id car-<UNIQUE_ID>

你可以使用以下命令查看新创建的帐户 ID：

**aws organizations list-accounts**

1. 一旦新账户创建完成，我们就可以继续创建一个新的 OU，并将账户移动到新的 OU 中。在这种情况下，我们将新 OU 命名为production。用我们在之前步骤中记下的 root ID 替换r-<XY00>的值：

# aws organizations create-organizational-unit
--parent-id r-<XY00>
--name production

该命令的输出将返回两个重要的值，第一个是新 OU 的 ARN，第二个是 OU 的 ID，格式为ou-<XY00>-<UNIQUE_ID>。请记下这些值，以便后续步骤使用。

1. 现在账户和 OU 已经创建完成，我们只需要将账户移动到新 OU 中。为此，输入以下命令，并替换account-id、parent-id和OU-id的正确值：

# aws organizations move-account
--account-id <NEW_ACCOUNT_ID>
--source-parent-id r-<XY00>
--destination-parent-id ou-<XY00>-<UNIQUE_ID>

就这样！你刚刚创建了一个全新的 AWS 账户，并且通过几个简单的命令将其移动到了新的 OU！就是这么简单！不过，你还可以通过创建一个新的 SCP 并将其附加到我们新创建的 OU 上来进一步完善。假设我们创建的这个特定 OU 只允许某些 AWS 服务在生产环境中运行。为此，我们首先需要创建一个新的 SCP，代码块如下所示：

{ 
  "Version": "2012-10-17", 
  "Statement": [{ 
    "Effect": "Allow", 
    "Action": [ 
      "ec2:*", 
      "rds:*", 
      "dynamodb:*" 
    ], 
    "Resource": "*" 
  }] 
} 

在这种情况下，SCP 是将 EC2、RDS 和 DynamoDB 列入白名单，当然你可以根据自己的需求进行修改：

1. 将 SQP 粘贴到一个名为policy.json的新文件中并保存。接下来，输入以下命令来创建它：

# aws organizations create-policy
--content file://policy.json
--name AllowProductionServices
--type SERVICE_CONTROL_POLICY
--description "This policy allows only certain production services"

1. 创建策略后，你应该会收到一个格式为p-<UNIQUE_ID>的策略 ID。请记下该 ID。接下来，使用以下命令将新创建的策略附加到我们的 OU 上：

aws organizations attach-policy
--policy-id p-<UNIQUE_ID>
--target-id ou-<XY00>-<UNIQUE_ID>

就这样！你已经成功地将一个新策略附加到你的 OU 上。你可以使用相同的语法直接将策略附加到每个单独的账户上。

规划你的下一步行动

在使用 AWS Organizations 时，仍然有很多值得尝试的事情。以下是一些建议：

首先，作为最佳实践，你应该始终监控你的个人组织，并确保每个更改都能被跟踪和报告。你可以利用 AWS CloudTrail 和 AWS CloudWatch 事件来实现这一点。监控组织至关重要，因为它帮助你确保没有不必要的更改影响你的账户和环境的合规性。你可以在docs.aws.amazon.com/organizations/latest/userguide/orgs_monitoring.html阅读更多关于如何利用 AWS CloudTrail 和 AWS CloudWatch 事件来监控组织的内容。

接下来，我还建议你试试 AWS 提供的端到端账户创建过程：

aws.amazon.com/blogs/security/how-to-use-aws-organizations-to-automate-end-to-end-account-creation/

自动化账户创建的整体过程与我们之前执行的 CLI 命令非常相似。脚本接受一些需要先定义的变量，并可以自定义角色名称。完成这些设置后，你只需执行 shell 脚本，它会调用 CloudFormation 模板来创建和配置新的成员账户。

总结

到这里，我们接近本章的结尾，但在进入下一章之前，让我们快速总结一下到目前为止学到的内容！

我们首先简要回顾了 AWS IAM 及其核心构建块，接着学习了最近对 IAM 做出的两项非常有用的增强功能。第一项是一个可视化编辑器，使用它你可以相对轻松地创建定制化和细粒度的 IAM 策略，接着是 IAM 策略模拟器工具，它帮助你创建和测试策略，而不影响云端任何正在运行的工作负载。之后，我们还了解了 AWS 组织及其如何帮助你在一个平台下创建和管理多个 AWS 账户。我们还看到了如何通过 AWS 组织仪表板以及 CLI，轻松地创建和管理根账户、组织和其他账户。

在下一章中，我们将学习和探索如何利用 AWS Code 套件服务，轻松地构建一个完整的端到端 CICD 流水线。

第七章：利用 AWS Code Suite 改变应用程序开发

在上一章中，我们探讨了 AWS 身份和访问管理服务（IAM）所做的一些有趣且非常有用的增强功能，以及对 AWS 组织的快速深入了解。

在本章中，我们将学习和探索由 AWS 提供的三项极其有用和强大的服务，专门为增强开发人员在持续代码部署方面的体验而设计：AWS CodeCommit、AWS CodeDeploy 和 AWS CodePipeline！

牢记这一点，让我们快速浏览一下本章将涵盖的各种主题：

• 介绍 AWS CodeCommit、AWS CodeDeploy 和 AWS CodePipeline 以及每个服务的概念和内部工作原理

• 创建您的第一个 CodeCommit 存储库并将应用程序上传到其中

• 运行基本的 Git 命令来操作您的新代码存储库

• 在 EC2 实例上配置 CodeDeploy 代理

• 利用 AppSpec 文件配置应用程序生命周期部署

• 使用 CodePipeline 创建您自己的持续交付系统

所以，不再拖延，让我们立即开始吧！

了解 AWS Code Suite

除了提供大量基础设施相关的服务外，AWS 还提供了一些旨在帮助开发人员快速设计、开发、构建和部署他们的应用程序在 AWS 云平台上的服务。在本节中，我们将快速浏览这些服务以及如何将它们结合起来利用，构建您自己的持续集成和交付流水线：

• AWS CodeCommit：任何 CI/CD 流水线的重要起点是一个简单但功能强大的源代码控制存储库。传统上，这将在一个或多个物理服务器上设置为 Git 或 SVN 存储库的形式，开发人员将使用它们来推送他们的代码和更新；然而，维护这样的代码存储库并扩展它们总是具有挑战性的。这就是 AWS CodeCommit 发挥作用的地方！AWS CodeCommit 是一项托管的源代码控制服务，使开发人员能够安全地将他们的代码存储在 AWS 云上。它提供了许多您在使用不同源代码控制存储库时需要和使用的功能，如分支、提交、回滚等。

• AWS CodeBuild：AWS CodeBuild 是开发人员可以利用的代码构建服务，用于自动化他们的源代码编译、测试、执行和代码打包以进行部署。与 Code Suite 中的其他对应服务类似，CodeBuild 也完全由 AWS 管理，从而消除了任何不必要的管理开销，如修补或扩展代码构建软件。CodeBuild 具有高度可扩展性，也很容易与您现有的 CI/CD 工作流程集成。

• AWS CodeDeploy：当你的应用代码安全地存储并编译完成后，最后一步是将代码部署到你的 EC2 实例群集中。这可以通过我们下一个 Code 套件服务，即 AWS CodeDeploy 来轻松实现。使用 CodeDeploy，开发人员可以自动将代码部署到运行 EC2 实例或本地数据中心服务器的任何环境。CodeDeploy 本质上通过让你自动化代码交付至数千个实例，消除了部署复杂性，无需经历任何长时间的停机。

• AWS CodePipeline：AWS CodePipeline 是 AWS 提供的一个完整的 CI/CD 服务，开发人员可以利用它构建端到端的 CI/CD 流水线，既可以使用 AWS Code 套件服务，也可以使用其他流行的第三方工具，如 GitHub、Jenkins 等。使用 CodePipeline，你还可以创建和定义自定义的软件发布模型，通过这些模型，你的应用程序会更新最新的一系列更新，进行测试，并为下一个迭代的部署进行打包。

以下是这些服务如何协同工作以创建一个完整的 CI/CD 流水线的简要表示：

然而，出于本章的目的，我们将只使用三个 AWS Code 套件服务，即 AWS CodeCommit、AWS CodeDeploy 和 AWS CodePipeline。本章将展示如何将这三种服务结合起来，构建适用于我们示例 WordPress 应用的 CI/CD 流水线。以下是我们整体用例的高层次示意图：

在对 Code 套件服务有了基本了解后，让我们深入了解 AWS CodeCommit，看看如何将它作为你自己的源代码仓库来使用！

开始使用 AWS CodeCommit

如前所述，AWS CodeCommit 是一个安全且高度可扩展的源代码控制服务，允许你创建多个私有 Git 仓库，而无需担心底层的管理工作。你可以用它来存储任何东西，从代码到应用程序二进制文件，再到代码包，所有这些都使用标准的 Git 类似功能。这使得即使你之前没有使用过 CodeCommit，它也极其易于使用。以下是一些最常用的 Git 命令的要点，以及你如何在 CodeCommit 中利用它们：

• git clone：用于将 AWS CodeCommit 仓库克隆并连接到你的本地开发服务器。

• git add：一旦将仓库克隆到本地，你可以根据需要添加、编辑或删除文件。完成后，使用 git add 命令将修改暂存到本地 Git 仓库。

• git commit：用于将对文件所做的修改提交到本地 Git 仓库。

• git push：用于将提交的文件和更改推送到 AWS CodeCommit 仓库。

• git pull：用于确保您正在处理的文件是最新版本，并且与 AWS CodeCommit 仓库中的版本保持同步。

在本节中，我们将介绍一些简单步骤，帮助您通过 AWS 管理控制台创建您自己的源代码仓库。然而，在我们继续之前，了解可以用来连接 CodeCommit 仓库的几种不同连接方式是非常重要的。连接方式可能会根据您的开发环境以及安全要求而有所不同：

• 使用 HTTPS 连接：通过 HTTPS 连接配置 Git 凭据是目前最简单和最广泛使用的连接 Git 仓库的方法。设置完成后，您只需使用 AWS IAM 生成一个静态用户名和密码。一旦凭据创建完成，您就可以在 Git 和任何第三方工具（如 IDE）中使用它们进行身份验证。

• 使用 SSH 连接：在这种情况下，用户需要在本地开发服务器上创建公钥和私钥文件，Git 和 AWS CodeCommit 将使用这些密钥进行 SSH 身份验证。此过程中生成的公钥与您的 IAM 用户关联，而私钥则保留在本地开发服务器上。密钥的生成过程因操作系统而异，有时可能会是一个繁琐的过程。

然而，在本节中，我们将利用 SSH 连接方法本身来连接到我们的 AWS CodeCommit 仓库：

1. 首先，登录到 AWS 管理控制台，并使用提供的“筛选器”选项筛选 IAM 服务。或者，您也可以选择 URL console.aws.amazon.com/iam/ 来查看 IAM 控制台。

2. 在这里，我们将从创建一个专门的用户开始，该用户将拥有对我们的 CodeCommit 仓库的完整管理权限。从 IAM 控制台的导航面板中选择“用户”选项，以显示当前创建的 IAM 用户列表。

3. 接下来，选择“添加用户”选项。这将打开“添加用户”页面，您可以在此页面上提供适当的用户名，并选择该用户的访问类型。在这种情况下，CodeCommit 用户仅需要编程访问权限。点击“下一步”继续。

4. 接下来，在权限页面中，我们需要筛选并将 AWSCodeCommitFullAccess 策略附加到新创建的用户。为此，选择“直接附加现有策略”选项，并选择 AWSCodeCommitFullAccess 策略，如下图所示。或者，您也可以根据需求在此处提供自定义访问策略：

1. 完成用户创建过程时，请审查更改并记下该用户的新访问密钥和秘密密钥。

此时，随着 CodeCommit IAM 用户的创建，我们进入本节的下一部分，即为 IAM 用户创建和配置一对公钥和私钥，使用一个简单的基于 Linux 的开发服务器。如果你使用的是 Windows 操作系统作为开发服务器，请访问 URL docs.aws.amazon.com/codecommit/latest/userguide/setting-up-ssh-windows.html：

1. 登录到开发服务器并运行以下命令生成新的密钥对：

# ssh-keygen 

1. 提示时，将密钥保存在以下目录结构中：

/home/<USER_NAME>/.ssh/<KEY_NAME> 

记下公钥和私钥的位置，如下图所示：

1. 接下来，使用以下命令显示并复制公钥的内容。注意，公钥将保存在以.pub扩展名结尾的文件中：

# cat /home/<USER_NAME>/.ssh/<KEY_NAME> 

1. 再次登录到 IAM 控制台并从用户页面中选择新创建的用户。选择该用户的“安全凭证”选项卡。在 AWS CodeCommit 的 SSH 密钥部分，点击“上传 SSH 公钥”并粘贴之前步骤中复制的完整文本。

2. 完成后，你应该能看到一个在 SSH 密钥 ID 列下自动生成的唯一密钥，如下图所示。复制此 SSH 密钥 ID，因为在接下来的步骤中我们需要它：

1. 将公钥上传到 IAM 并生成新的 SSH 密钥 ID 后，最后一步是在本地开发服务器中创建一个简单的config文件，并将以下内容粘贴到文件中：

# vi ~/.ssh/config
##### SUBSTITUTE THE <VALUES> WITH YOUR ACTUAL ONES #####
    Host git-codecommit.*.amazonaws.com
      User <SSH_KEY_ID>
      IdentityFile ~/.ssh/<PRIVATE_KEY_FILENAME>

1. 完成后保存文件。在继续验证步骤之前，记得修改config文件的权限：

# chmod 600 config

1. 为了验证连接，只需使用以下命令 SSH 连接到 AWS CodeCommit 端点。由于这是首次连接，你将被提示验证连接的真实性。提示时输入yes：

# ssh git-codecommit.us-east-1.amazonaws.com

你使用的端点将特定于你所在的 AWS 区域。你可以查看区域特定的 CodeCommit URLs 列表以及 CodeCommit 服务的可用性，访问docs.aws.amazon.com/codecommit/latest/userguide/regions.html。

完成此步骤后，我们成功验证并连接了开发服务器与 AWS CodeCommit 服务！但我们的 CodeCommit 存储库在哪里？

1. 要创建存储库，请通过 URL console.aws.amazon.com/codecommit登录 AWS CodeCommit 服务。记得根据在密钥验证阶段选择的区域更改区域。

2. 由于这是我们第一次使用 CodeCommit，请选择“Get Started”选项开始。这将显示创建存储库页面，如下图所示：

1. 提供一个合适的仓库名称，并填写可选的描述。完成后点击“创建仓库”。

2. 你还可以在“配置电子邮件通知”页面中，为特定的事件类型（如拉取请求和对你仓库的提交）配置通知。只需选择一个现有的 SNS 主题，或者根据需要选择“创建新主题”。完成后，点击“保存”以完成仓库创建过程。

仓库创建完成后，你可以使用开发服务器，并通过简单的git clone命令连接到它。你可以随时通过选择 Code 页面上的“连接”选项来获取仓库的连接 URL：

# git clone https://git-codecommit.us-east-1.amazonaws.com/v1/repos/<YOUR_CODECOMMIT_REPO> 

这是第一次执行git clone命令的输出快照：

由于仓库为空，克隆过程仅会在你的开发服务器上创建一个与仓库名称相同的文件夹。现在，你可以将该文件夹作为代码源控制，只需将程序文件、二进制文件和其他应用程序特定的数据添加到其中。

在下一部分中，我们将使用该仓库作为我们的 WordPress 应用程序源控制，并探索 AWS CodeCommit 提供的一些简单命令和功能。

与分支、提交和触发器一起工作

创建了 CodeCommit 仓库后，现在是时候将该仓库用作我们的源控制仓库了。为此，我们将首先使用简单的 Git 命令将本地开发服务器上的标准 WordPress 应用程序推送到 AWS CodeCommit 仓库，并稍后运行更多 Git 命令和 AWS 操作，以分支和提交我们的代码。

你可以通过从这里下载 WordPress 应用程序的 ZIP 文件：

github.com/WordPress/WordPress

首先，我们需要将 WordPress 应用程序的内容复制到之前克隆的本地仓库中：

1. 一旦 WordPress 应用程序下载到本地开发服务器，只需解压并将其内容复制到本地仓库。你的本地仓库现在应该显示出类似以下截图的文件夹结构：

1. 代码准备好后，只需使用以下 Git 命令提交并将代码推送到你的 AWS CodeCommit 仓库。首先，使用git add命令暂存文件：

# git add *

1. 接下来，使用git commit命令提交更改：

# git commit -m "First Commit!!"

1. 最后，将提交推送到 AWS CodeCommit 仓库。在这里，origin是 Git 用于你 AWS CodeCommit 仓库的默认远程名称，而master是默认的分支名称：

# git push -u origin master

1. 你应该能看到代码已上传到你的 AWS CodeCommit 仓库，如下图所示。你可以通过刷新并检查 AWS CodeCommit 仪表板上的 Code 页面来交叉验证：

同样，你和其他开发人员可以编辑并提交代码到 AWS CodeCommit 仓库。你还可以创建多个仓库分支，以便开发人员可以独立工作，而不会影响 master 分支。一旦功能经过充分测试并验证后，单独的开发者分支可以合并到更稳定的 master 分支中。

在 CodeCommit 中创建分支是一个非常简单的过程！你可以使用 CodeCommit 仪表盘、Git 命令行，甚至 AWS CLI 来创建属于你自己的分支：

1. 要通过 AWS CodeCommit 仪表盘创建分支，只需从导航面板中选择 Branches 选项。

2. 接下来，选择 Create branch 选项，进入创建分支页面。在这里，提供一个合适的 Branch name，并选择你希望新分支从哪个分支创建。在这种情况下，由于你只创建了 master 分支，因此可以选择它。完成后点击 Create。

3. 你也可以使用 Git 命令行来实现相同的效果。在这种情况下，从开发服务器上输入以下命令以创建新分支：

# git checkout -b <NEW_BRANCH_NAME>

创建新分支后，你还可以使用 CodeCommit 提供的 Compare 功能，将分支的更改与另一个分支进行比较。为此，我们首先需要在应用程序中进行一些更改，以便这些更改能够反映出来。

在不更改当前仓库分支的情况下，简单地通过添加或删除注释来更新 WordPress 文件。在我的案例中，我仅在 WordPress 应用程序的 index.php 文件中做了一些注释更改；但是，你可以根据需要修改任何其他文件。一旦完成更改，我们需要再次进行暂存、提交并将更改推送到我们仓库的新分支：

1. 使用 git add 命令暂存更改。你可以使用 * 将所有文件添加到暂存区，也可以指定你希望暂存的文件名：

# git add *

1. 接下来，使用 git commit 命令提交更改：

# git commit -m "<SOME_NEW_COMMIT_MESSAGE>"

1. 最后，使用以下命令将更改推送到分支：

# git push origin <NEW_BRANCH_NAME>

1. 在推送更改后，在 CodeCommit 仪表盘中的 Commits 部分使用 Compare 选项。在这里，选择 master 作为 源 分支，选择你通过 Git 命令行创建的分支作为目标分支。完成后点击 Compare。你应该会看到所做的更改进行比较，如下图所示：

如果你在多个文件中做了更改，你可以使用 Go to file 下拉列表在不同文件之间切换。或者，你还可以使用 Unified 和 Split 视图来根据需要更改视觉比较方式。

CodeCommit 还提供了一个额外的功能，叫做 触发器，你可以用它来发送通知或运行其他外部的代码构建或处理过程。你可以为每个创建的仓库分配最多 10 个触发器，但在撰写本书时，CodeCommit 只支持 AWS SNS 和 AWS Lambda 作为触发机制：

1. 要创建一个简单的触发器，使用 CodeCommit 仪表盘，从导航面板中选择“设置”选项卡。在这里，选择“触发器”选项卡，以创建和查看现有的触发器列表（如果有的话）。

2. 选择“创建触发器”选项以打开“创建触发器”页面。在这里，你可以根据某些仓库事件配置触发器，例如推送到现有分支、创建分支或标签、删除分支或标签，或者所有仓库事件。

3. 提供触发器名称，并选择你希望与触发器关联的适当事件和分支名称。完成后，你可以将触发器配置为使用现有的 SNS 主题或 Lambda 函数作为其服务。你甚至可以通过选择“测试触发器”选项来测试触发器的功能。这将根据你之前选择的 事件 模拟触发器。

通过这种方式，你可以根据仓库的需求配置触发器，以便向开发人员发送通知并触发特定的 Lambda 函数。

介绍 AWS CodeDeploy。

在将 CodeCommit 配置好并为我们的 WordPress 应用程序做好准备后，我们可以继续使用另一个可以实际将代码部署到成千上万 EC2 实例的 Code Suite 服务！这就是 AWS CodeDeploy 的介绍！

AWS CodeDeploy 本质上是一个部署服务，允许你自动化将应用程序部署到 Amazon EC2 实例、Lambda 函数，甚至本地实例。AWS CodeDeploy 的部署内容没有限制。你可以使用它部署几乎任何内容，从代码、包、二进制文件、脚本、文件等。到目前为止，CodeDeploy 仅支持 GitHub 仓库和 Amazon S3 存储桶作为默认的应用内容仓库。是的，你没听错，目前 CodeDeploy 不支持 CodeCommit 作为仓库源。

除了自动化之外，CodeDeploy 还为你提供了一系列有用的好处。它使你能够：

• 快速创建新的原型软件并大规模部署，无需人工干预。

• 轻松更新你的应用程序代码，而无需任何停机。

• 在出现错误时回滚部署。

• 将你的部署规模从一个实例扩展到一千个实例，而且不会中断现有应用程序的运行。

在本章的这一部分，我们将探讨如何为我们自己的应用程序部署设置 CodeDeploy，但在此之前，先简要了解一下 CodeDeploy 的一些基本概念。

概念和术语。

CodeDeploy 本质上由两个主要的可配置部分组成，可以广泛地分类为部署和应用程序。以下是这些概念的详细介绍：

• 应用程序：这里的应用程序指的是 CodeDeploy 用来识别针对特定部署的单个应用程序代码的简单名称。应用程序可以部署到 EC2 实例、本地实例，也可以部署到无服务器计算平台，如 AWS Lambda。

• 部署：部署是部署配置和部署类型的集合，包括：

  • 部署配置：部署配置是一组简单的规则，决定了应用程序的部署速度以及该部署的成功或失败条件。例如，对于 EC2 部署，配置规则可以指定所需的最小健康实例数量，而对于 Lambda 函数部署，这些规则可以用来指定部署期间流量如何路由到这些函数。

  • 部署组：这是一个由 EC2 或本地实例组成的组，这些实例可以是独立的，也可以是自动扩展组的一部分。由于 AWS Lambda 是一个托管服务，它不提供任何部署组。

  • 部署类型：部署类型指示用于将应用程序的最新版本部署到特定部署组的方法类型。支持两种部署类型：

    • 原地部署：在这种情况下，每个 EC2 实例上运行的应用程序会被停止、更新、启动并进行验证。这种部署方式仅支持 EC2 和本地实例。

    • 蓝绿部署：在这种情况下，底层实例会被新版本的实例替换，这些新实例运行更新后的代码。这些实例会注册到Elastic Load Balancer（ELB），ELB 将流量路由到新的实例，而旧的实例则可以被终止。在无服务器平台上，流量也会自动由 AWS 从当前的 Lambda 函数切换到更新后的 Lambda 函数。请注意，所有的 Lambda 部署实际上都是蓝绿部署。

• CodeDeploy 代理：CodeDeploy 代理是一个简单的软件包，安装在 EC2 实例或本地实例上，并由 CodeDeploy 用于设置和管理应用程序部署。一旦代理安装在实例上，会生成一个关联的配置文件。该文件包含应用程序特定的目录路径以及其他 CodeDeploy 用来与实例交互的设置。该文件是一个简单的 YAML 文件，基于实例的操作系统，可以位于以下目录：

  • Amazon Linux、Ubuntu、RedHat Enterprise Linux：/etc/codedeploy-agent/conf/codedeployagent.yml

  • Windows 服务器：C:ProgramDataAmazonCodeDeployconf.yml

• 应用程序规范文件：应用程序规范文件，或称 AppSpec 文件，用于将单个部署定义为一系列生命周期事件钩子。每个钩子本身可以是另一个文件，例如启动或停止服务、安装依赖项等的简单脚本。AppSpec 文件支持 JSON 和 YAML 格式。在部署时，AWS CodeDeploy 代理会在 AppSpec 文件的钩子部分查找当前事件的名称。如果找到该事件，代理将检索要执行的脚本列表，并按它们在 AppSpec 文件中的顺序依次运行这些脚本。

完成基本设置后，让我们快速看一下如何设置一个 EC2 实例，以便与 CodeDeploy 一起使用。

安装和配置 CodeDeploy 代理

在我们开始实际启动安装了 CodeDeploy 代理的 EC2 实例之前，我们需要设置 EC2 实例配置文件以及实例角色，这将授予我们的 EC2 实例与 CodeCommit 和 CodeDeploy 交互所需的权限：

1. 首先，登录到 AWS 管理控制台，从服务过滤器中选择 IAM 服务。或者，您也可以通过选择网址console.aws.amazon.com/iam/来启动 IAM 仪表板。

2. 从 IAM 仪表板中，选择导航窗格中的“策略”选项，以打开 IAM 策略页面。然后，点击“创建策略”开始。

3. 在“创建策略”页面，选择 JSON 标签并粘贴以下策略文档内容：

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Action": [ 
                "ec2:Describe*", 
                "sns:*", 
                "codecommit:*", 
                "codedeploy:*", 
                "codepipeline:*", 
                "codecommit:GetBranch", 
                "codecommit:GetCommit", 
                "codecommit:UploadArchive", 
                "codecommit:GetUploadArchiveStatus", 
                "codecommit:CancelUploadArchive", 
                "s3:*" 
            ], 
            "Effect": "Allow", 
            "Resource": "*" 
        } 
    ] 
}

策略文档基本上为 EC2 实例提供了与 AWS 服务（如 CodeDeploy、CodeCommit 和 CodePipeline）交互所需的权限集。

1. 完成后点击“审核策略”。在最终的“审核策略”页面，提供一个合适的策略名称，并点击“创建策略”以完成过程。

2. 创建策略后，我们现在只需将其分配给一个新的 IAM 角色。为此，从导航窗格中选择“角色”选项，以打开 IAM 角色页面。

3. 点击“创建角色”以启动向导。在“选择可信实体类型”部分，确保选择 AWS 服务并从中筛选出 EC2。点击“下一步：权限”继续。

4. 在“附加权限策略”页面，筛选之前创建的策略并将其附加到我们的新角色，如下图所示：

1. 最后，在“审核”页面，给您的角色提供一个合适的角色名称，并点击“创建角色”以完成过程。

2. 在使用此新创建的角色启动 EC2 实例之前，请确保角色的信任关系在其策略文档中添加了以下 AWS 服务：

{ 
  "Version": "2012-10-17", 
  "Statement": [ 
    { 
      "Sid": "", 
      "Effect": "Allow", 
      "Principal": { 
        "Service": [ 
          "codecommit.us-east-1.amazonaws.com", 
          "ec2.amazonaws.com", 
          "codedeploy.us-east-1.amazonaws.com", 
          "codepipeline.us-east-1.amazonaws.com" 
        ] 
      }, 
      "Action": "sts:AssumeRole" 
    } 
  ] 
} 

完成此步骤后，我们现在可以启动一个简单的 EC2 实例，并分配新创建的角色：

1. 在 EC2 管理控制台中，选择“启动实例”选项开始操作。对于这个特定的用例，我选择了标准的 Amazon Linux AMI (amzn-ami-hvm-2017.09.1.20171120-x86_64-gp2 - ami-55ef662f)，但是，您也可以根据需要选择其他 Linux 操作系统发行版。

2. 为托管我们简单的 WordPress 应用程序选择一个合适的实例类型。目前，我选择了 t2.micro 实例类型。

3. 接下来，在“配置实例详细信息”页面，选择适当的网络、子网和 IAM 角色来配置我们的新 EC2 实例。将以下几行作为用户数据粘贴到高级详细信息部分，如下所示。这个简单的用户数据脚本将会复制并安装 CodeDeploy 代理以及其他一些必要的依赖项。您可以在 github.com/yoyoclouds/Administering-AWS-Volume2 找到完整的代码：

#!/bin/bash 
yum -y update 
yum install -y ruby 
yum install -y aws-cli 
cd /home/ec2-user 
aws s3 cp s3://aws-codedeploy-us-east-1/latest/install . --region us-east-1 
chmod +x ./install 
./install auto 

请记得根据您当前的操作区域值更改 region 参数。

1. 一旦为实例分配了所需的存储，继续为我们的 EC2 实例分配一些必要的标签。这些标签稍后将在 CodeDeploy 中用于引用我们的 EC2 实例，因此请记下它们。

2. 最后，创建一个新的安全组，并确保 22（SSH）和 80（HTTP）端口对互联网流量开放。

3. 审查实例的设置并启动它。此外，记得在启动实例之前将其与密钥对关联，因为这对验证或排查 AWS CodeDeploy 代理的问题可能很有用。

到此为止，您已成功在 EC2 实例上启动并设置了 CodeDeploy 代理。在本章的下一节中，我们将介绍如何通过配置 AppSpec 文件来进一步推进这一安装过程，完成最终的 CodeDeploy 部署。

设置 AppSpec 文件

如前所述，AppSpec 或应用程序规范文件实际上是一个基于 YAML 或 JSON 的文件，用于定义特定部署的生命周期钩子。在这种情况下，虽然我们的 EC2 实例已经准备好并安装了 CodeDeploy 代理，但我们仍然需要 AppSpec 文件来定义一组依赖项，这些依赖项将会在 EC2 实例上安装必要的包，启动或停止服务，修改权限等。

AppSpec 文件包括以下部分：

• 版本：AppSpec 文件的版本。目前，CodeDeploy 支持的版本号为 0.0。请勿更改此值。

• 操作系统：指定底层 EC2/本地实例的操作系统。

• 文件：指定在部署过程中需要复制到实例上的文件。您还可以为应用程序指定源文件夹和目标文件夹。

• 钩子：钩子本质上指定了在何时触发特定的部署生命周期。钩子主要有四种类型：BeforeInstall、AfterInstall、ApplicationStart和ApplicationStop。每个钩子还需要附加参数，如要执行的脚本的位置、超时值，以及脚本应该以何种身份运行。

这是我们 WordPress 部署的一个简单 AppSpec 文件示例。由于我们使用的是 Amazon Linux 支持的实例，os值被设置为linux，并包含其他重要参数，如files和hooks。请注意，在我们的情况下，我们将配置 WordPress 应用程序文件从默认位置复制到/var/www/html/WordPress：

version: 0.0 
os: linux 
files: 
  - source: / 
    destination: /var/www/html/WordPress 
hooks: 
  BeforeInstall: 
    - location: scripts/install_dependencies.sh 
      timeout: 300 
      runas: root 
  AfterInstall: 
    - location: scripts/change_permissions.sh 
      timeout: 300 
      runas: root 
  ApplicationStart: 
    - location: scripts/start_server.sh 
      timeout: 300 
      runas: root 
  ApplicationStop: 
    - location: scripts/stop_server.sh 
      timeout: 300 
      runas: root 

要创建这个文件，登录到你的开发服务器，而不是你的 CodeDeploy 实例。登录到开发服务器后，打开我们在本章 CodeCommit 部分使用过的 WordPress 应用程序目录。这与我们用来同步主 CodeCommit 仓库的目录是同一个：

1. 在应用程序的根目录下，创建一个空白的appspec.yml文件，并复制粘贴之前解释过的appspec内容：

# vi appspec.yml 

1. 创建完 AppSpec 文件后，我们继续创建生命周期钩子的各个单独文件。为此，在 WordPress 应用程序目录内创建一个名为scripts的文件夹，并在其中创建这些单独的 Shell 脚本：

# mkdir scripts

1. 创建install_dependencies.sh脚本，该脚本将安装运行 WordPress 所需的必要软件包：

# vi scripts/install_dependencies.sh 
#!/bin/bash 
sudo yum install -y httpd mysql mysql-server php 
sudo yum install -y php-mysql 

1. 同样，创建change_permissions.sh脚本，修改scripts文件夹内文件的权限，使其可执行：

# vi scripts/change_permissions.sh 
#!/bin/bash 
chmod -R 755 /var/www/html/WordPress 

1. 最后，创建start_server.sh和stop_server.sh脚本，这些脚本将在部署的 EC2 实例上启动和停止httpd和mysql服务：

# vi scripts/start_server.sh 
#!/bin/bash 
service httpd start 
service mysqld start 

# vi scripts/stop_server.sh 
#!/bin/bash 
isExistApp=`pgrep httpd` 
if [[ -n  $isExistApp ]]; then 
   service httpd stop 
fi 
isExistApp=`pgrep mysqld` 
if [[ -n  $isExistApp ]]; then 
    service mysqld stop 
fi 

到这里了吗？太棒了！我们快完成 AppSpec 文件了，剩下的唯一步骤就是：将这些更改上传到我们的 CodeCommit 仓库！

为此，从部署服务器运行以下一组命令：

# git add * 
# git commit -m "Added scripts directory with AppSpec file!" 
# git push -u origin <NEW_BRANCH_NAME>

Et voila！WordPress 应用程序和我们的部署脚本都已上传到 CodeCommit 分支，准备好进行部署！在下一部分，我们将创建并配置 CodeDeploy 的应用程序和部署组。

创建一个 CodeDeploy 应用程序和部署组

我们已经准备好了 AppSpec 文件和脚本，并且 EC2 实例也已经配置好 CodeDeploy 代理，最后需要做的是配置 AWS CodeDeploy 并将这些内容连接起来：

1. 首先，通过选择 URL console.aws.amazon.com/codedeploy/home 登录 AWS CodeDeploy 服务。

2. 由于这是我们第一次使用 CodeDeploy，请选择“立即开始”选项。在这里，您将被提示选择一个示例部署，它会在 EC2 实例上部署一个示例应用程序；或者，如果您已有代码和 EC2 实例正在运行，您可以选择自定义部署。在本例中，我们将选择自定义部署选项。

3. 在“创建应用程序”页面，首先提供合适的应用程序名称、计算平台和部署组名称。记得从计算平台中选择“EC2/本地部署”选项，如下图所示：

1. 接下来，在部署类型部分，暂时选择“原地部署”选项。这将允许 CodeDeploy 使用更新后的应用程序代码更新现有实例，并带有一定的停机时间。

2. 在环境配置部分，您可以指定任何组合的自动扩展组、Amazon EC2 实例和本地实例，以将实例添加到此部署组中。由于我们在之前的步骤中已经创建了一个 EC2 实例，并安装了 CodeDeploy 代理，因此请选择“Amazon EC2 实例”标签。然后，在标签组下拉列表中选择实例的“键”和值，如图所示。

请注意，这些标签与您在之前部分中为实例配置的标签相同：

1. 接下来，在部署配置部分，您可以从默认和自定义部署配置列表中进行选择。如前所述，部署配置是一组规则，决定了应用程序的部署速度，并定义了特定部署的成功或失败条件。

AWS CodeDeploy 本身提供了三种默认配置：

• OneAtATime：将流量一次路由到替换环境中的一个实例

• HalfAtATime：将流量一次路由到替换环境中最多一半的实例

• AllAtOnce：将流量一次性路由到替换环境中的所有实例

由于我们目前只在使用一个 EC2 实例，因此请选择“OneAtATime”部署配置选项。

1. 最后，选择我们在启动时创建并分配给 EC2 实例的 IAM 角色，通过“服务角色”下拉列表进行选择。完成后，选择“创建应用程序”选项以完成该过程！

就这样！如果您已经完成到这里，那么您已经成功配置了 AWS CodeCommit 和 AWS CodeDeploy 来部署我们的 WordPress 应用程序！但我们仍然缺少将这些服务串联起来的“粘合剂”，这正是我们在下一部分介绍 AWS CodePipeline 时要讲解的内容！

介绍 AWS CodePipeline

AWS CodePipeline 是一种持续交付服务，你可以用它来建模、可视化并自动化发布应用软件所需的步骤。这是通过构建包含一个或多个阶段的“流水线”来实现的。这些阶段大致可以分为构建，即使用 AWS CodeBuild 或其他第三方工具编译并构建代码，暂存，以及部署，即通过 AWS CodeDeploy 将代码推送到计算实例等。每个阶段内部描述了为准备软件发布所需执行的一组操作。这些操作可以是从 Git 仓库构建源代码，到修改文件或部署包等等。对代码或 CodePipeline 中任何配置设置的每次更改都被视为一个修订，并且你可以在流水线的单个阶段中创建多个修订。

即使在流水线中的单个阶段进行更改，也会导致所有阶段中的所有操作被重新执行。

你可以使用 CodePipeline 提供的这些功能来有效地管理和监控软件的发布。在本节中，我们将继续使用之前设置的案例，利用 CodeCommit 和 CodeDeploy，看看如何利用 AWS CodePipeline 真正构建一个端到端的持续交付周期。

创建你自己的持续交付流水线

使用 CodePipeline 入门非常简单，只要你满足所有必要的先决条件，这些条件包括设置带有最新应用代码（在本例中为 WordPress 应用）的 CodeCommit 仓库，以及使用 CodeDeploy 配置应用程序和 AppSpec 文件：

1. 首先，通过选择 URL console.aws.amazon.com/codepipeline/home 启动 CodePipeline 管理仪表板。

2. 由于这是我们的第一次设置，点击“开始使用”选项以启动。这将显示“使用 AWS CodePipeline 入门”向导，如以下截图所示。首先提供一个合适的流水线名称，然后点击“下一步”继续：

1. 接下来，在“源”页面，我们需要选择并配置新流水线的源。在撰写本书时，CodePipeline 支持三个源代码提供者，即 Amazon S3、AWS CodeCommit 和 GitHub。为了本案例，选择“源”下拉列表中的 AWS CodeCommit。

2. 这将自动提示你输入后续的 CodeCommit 仓库名称以及其对应的分支名称。确保提供包含最新 WordPress 代码和 AppSpec 文件的相同分支名称。点击“下一步”继续。

3. 管道设置的第三个阶段是“Build”阶段，您可以在此指定构建提供程序。CodePipeline 支持三种构建提供程序，即 AWS CodeBuild、Jenkins 和 Solano CI。由于我们的 WordPress 安装不需要任何编译或构建过程，因此只需从下拉列表中选择“No Build”选项，然后单击“下一步”继续。

4. 第四个状态需要为管道设置部署配置。在这里，您也可以根据需要选择利用的各种选项。目前，CodePipeline 支持 AWS Opsworks、AWS CodeDeploy、AWS CloudFormation 和 AWS Elastic Beanstalk 作为部署提供程序。由于我们已经为我们的用例配置了 AWS CodeDeploy，因此从下拉列表中选择相同选项。

5. 接下来，填写正确的应用程序名称以及在设置 CodeDeploy 期间配置的部署组。完成后，单击“下一步”：

1. 最后一步是配置服务角色。服务角色基本上授予了 CodePipeline 在您的 AWS 账户中使用资源的权限。提供适当的角色名称，并单击“下一步”以审查管道的配置。

2. 在“Review your pipeline”页面上，确保所有字段都正确配置，并在完成后单击“创建管道”。

选择此选项首先在您的环境中创建一个唯一的 S3 存储桶，该存储桶将包含并存储该特定管道所需的所有必要工件。创建管道后，您可以在 AWS CodePipeline 仪表板上查看它。

将所有内容整合在一起

完成管道设置后，现在可以将整个设置作为一个协同解决方案进行测试！

首先确保在部署过程中的任何阶段中都没有错误。如果有任何错误，请简单地选择阶段提供的特定错误链接，并跟随其源头，可能是从 CodeCommit 的问题到甚至是 CodeDeploy 的设置。以下是我们使用前述所有部分积累创建的管道的屏幕截图：

在此，您可以通过简单选择“Edit”选项来为您的管道添加更多阶段，正如前面所强调的那样。此外，您还可以通过选择“View pipeline history”选项来查看您的管道执行历史记录。

在“Edit pipeline”页面上，您可以根据需要选择添加一个或多个阶段到您的管道中。只需选择每个现有阶段末尾提供的“+ Stage”选项即可。这将弹出一个新对话框，在其中您可以指定阶段的名称以及定义一个或多个操作。

考虑以下用例，我们需要在代码实际推送到暂存区之前添加一个批准步骤。在这种情况下，我们需要在现有的“Source”和“Staging”阶段之间添加一个新阶段：

1. 点击 + 阶段 选项，为这个新阶段提供一个合适的名称。接着，选择 + 操作 选项，添加设置审批过程的规则。

2. 在添加操作对话框中，首先从操作类别下拉列表中选择操作类型。以下操作可以添加到阶段中：审批、源、构建、测试、部署和调用。对于这个用例，选择审批：

1. 填写合适的操作名称，并选择一个合适的操作类型。目前，CodePipeline 只提供手动审批配置选项。

2. 最后，选择一个预先存在的 SNS 主题，使用 SNS 主题 ARN 字段，然后点击添加操作按钮，一旦完成。

3. 添加新阶段后，点击“保存管道更改”以提交更改。你应该能看到新阶段已成功添加并出现在你的管道中，截图如下所示：

1. 一旦源阶段准备好，管道会自动停在审批阶段，如下图所示。在这里，你只需选择“审核”选项并选择 approval 命令，即可批准流程。这将启动最终的 Staging 阶段，进而触发 CodeDeploy 服务，将 WordPress 代码部署到我们等待中的 EC2 实例上：

几分钟后，应用程序成功上传至实例并正常运行。你可以通过记下实例的公共 IP 地址，并在浏览器中输入以下 URL 来验证：

http:///WordPress/wp-admin/index.php

请记得在 URL 前缀中添加WordPress，因为 AppSpec 文件明确指向的是应用程序根目录 /var/www/html/WordPress，而不是 /var/www/html 本身。

通过这种方式，你可以轻松利用并自动化部署你的应用代码，使用 AWS Code 服务套件！是不是很棒？但这还不是全部！接下来还有许多有趣的内容，我希望你能够学习和探索，所有内容都会在下一节中讲解。

规划你的下一步

好了，我们在这一章中涵盖了许多新功能和服务。然而，还是有一些事情我建议你自己也需要深入了解。首先是 AWS CodeStar！

AWS CodeStar 是一个了不起的服务，可以帮助开发人员在一个地方创建、管理和开发应用程序。实现这一点的 CodeStar 的重要部分称为项目。开发人员可以基于预定义模板创建项目，这些模板包含支持的编程模型，可用于开发。您还可以从多种选项中选择应用程序的托管，包括 Amazon EC2、Elastic Beanstalk 和 AWS Lambda！CodeStar 还可以与多种 IDE（如 Eclipse、Visual Studio 等）轻松连接。您可以在 docs.aws.amazon.com/codestar/latest/userguide/welcome.html 上了解更多关于 AWS CodeStar 的信息。

第二个值得尝试的令人惊叹的服务是 AWS Cloud9！AWS Cloud9 是一个基于云的 IDE，您可以使用标准的 Web 浏览器编写、调试和运行代码！Cloud9 预装了最受欢迎的编程语言（包括 JavaScript、Python、PHP、Node.js、C++ 等）的基本工具，最好的部分是您可以轻松将 Cloud9 与 AWS 的其他服务（如 CodeCommit、CodeStar 等）集成。您可以在 docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html 上了解更多关于 AWS Cloud9 的信息。

最后，但同样重要的是，我还建议您尝试一下由 AWS 合作伙伴网络 (APN) 提供的完整的端到端 CI/CD 解决方案，该解决方案利用 CloudFormation 堆栈部署了全面的 AWS Code 套件，包括 CodeBuild、CodeCommit、CodeDeploy 和 CodePipeline！该堆栈使您能够体验使用 AWS CodeBuild 作为服务，并为您提供一个使用 CloudFormation 自动化部署代码的模板。您可以访问博客了解更多信息：aws.amazon.com/blogs/apn/deploy-to-production-using-aws-codebuild-and-the-aws-developer-tools-suite/。

总结

这是本章迄今为止涵盖的主题的快速总结！

我们首先学习了解了 AWS Code 套件的一些服务，以及它们如何与持续集成和持续交付生命周期相关联。然后我们学习了 AWS CodeDeploy 的基础知识，以及如何轻松入门。我们创建了一个简单的 CodeCommit 仓库，并将我们的示例 WordPress 应用程序存储在其中。随后，我们深入了解了 AWS CodeDeploy 的工作原理。我们还配置了一个 CodeDeploy 代理，并利用了 AppSpec 文件来管理我们的 WordPress 应用程序的部署生命周期。最后，我们通过将迄今为止完成的工作与 AWS CodePipeline 集成，将所有内容整合在一起，并在章节结束时介绍了一些自行尝试的基本内容！

在下一章中，我们将探讨两个特定应用的服务，并看看你如何利用它们来满足你的需求：Amazon SQS 和 Amazon SNS。敬请期待！

第八章：使用 Amazon SNS 和 Amazon SQS 在云中进行消息传递

在上一章中，我们简要探讨了 AWS 代码套件服务，即 AWS CodeCommit、AWS CodeDeploy 和 AWS CodePipeline，以及它们如何与应用程序的持续集成和持续交付生命周期结合。

在本章中，我们将学习并探索另一组在开发现代云原生应用程序时极其有用的 AWS 服务，以及用于管理 AWS 账户的常规操作：Amazon 简单通知服务（SNS）和 Amazon 简单队列服务（SQS）。

记住这一点，让我们快速浏览一下本章将要涵盖的各个主题：

• 介绍 AWS 提供的各种消息服务，并深入了解每个服务的用途

• 介绍 Amazon SNS 和 Amazon SQS，以及它们的核心概念和术语

• 创建您自己的 SNS 主题和订阅，并将其用于您的 AWS 账户

• 使用 Amazon CloudWatch 监控 SNS 通知

• 将 Amazon SNS 与 Slack 集成，提供更丰富的用户通知体验

• 入门标准队列和 FIFO 队列，并将 Amazon SNS 与 Amazon SQS 集成

那么，事不宜迟，我们开始吧！

了解 AWS 消息服务

我们现在都知道 AWS 提供了大量的服务，旨在帮助您开发丰富的云原生应用程序；但是，面对如此多的服务，您该如何选择合适的服务组合呢？这正是我们在本节中将要学习和探索的内容，首先是简要了解并比较几个常用的 AWS 消息服务，如下图所示：

• Amazon SNS： Amazon SNS，即简单通知服务，是一种同步的、托管的服务，能够让最终用户将消息发送或传递给一个或多个端点或客户端。它通过使用类似发布者–订阅者的模型来工作，如下图所示：

一个或多个发布者或生产者将消息发布到相应的 SNS 主题，而不需要知道哪些订阅者或消费者最终会消费这些消息。生产者也不需要等待消费者的响应，这使得 SNS 成为一种松耦合服务。消费者的任务是订阅主题并获取传入的消息通知。SNS 支持多种消费者实现选项，如电子邮件、移动推送通知、SMS、HTTP/HTTPS 通知，甚至是 Lambda 函数。

• Amazon SQS： 另一方面，Amazon SQS，或称为 Simple Queue Service，是一种异步托管服务，提供了将消息推送到队列并从队列中拉取消息的能力。在这里，多个生产者可以将消息推送到队列中，而在另一端的消费者会逐个消费并处理这些消息。这里需要注意的重要一点是，与其对应的 SNS 不同，后者会在有新消息时通知消费者，而在 SQS 中，消费者必须定期轮询队列以查找新消息。一旦发现消息，消费者需要处理它，并将其从队列中删除。该过程如下所示：

• Amazon Kinesis： Amazon Kinesis 与 Amazon SQS 很像；然而，它本质上是为高吞吐量的数据写入和读取而设计和优化的。在这里，代替队列，你将得到一个流，消费者可以多次读取该流。该流会在 24 小时后自动修剪，因此，与队列中的消费者不同，这里不需要在处理完消息后删除消息：

与 Amazon Kinesis 类似，AWS 也提供了一种流式功能，称为 DynamoDB streams，结合 DynamoDB 使用。通过这个功能，你可以基本上启用对表中某些项的实时变更，并以流的形式进行处理。最后，你还可以通过结合使用 Amazon API Gateway、ELB、AWS Lambda 和其他服务，获得标准的请求-回复消息模型。这种通信模式本质上是同步的，可以根据你的需求用于各种用例。

牢记这些基本的区别后，我们现在可以继续了解更多关于 SNS 的内容。

开始使用 Amazon Simple Notification Service

如前所述，SNS 是一种托管的 Web 服务，你可以作为最终用户利用它将消息发送到各种订阅的端点。SNS 采用发布-订阅或生产者-消费者模型，在该模型中，生产者创建并将消息发送到特定主题，随后一个或多个订阅者通过一组受支持的协议消费这些消息。在编写本书时，SNS 支持 HTTP、HTTPS、电子邮件、短信形式的推送通知，以及作为首选订阅者模式的 AWS Lambda 和 Amazon SQS。

SNS 是一个非常简单但又极其有用的服务，你可以将其用于各种目的，其中最常见的是在特定事件发生时向云管理员推送通知或系统警报。我们在本书中一直使用 SNS 来实现这一目的；然而，SNS 还有许多其他功能和使用案例。例如，你可以使用 SNS 向大量目标受众发送促销电子邮件或短信，甚至可以将其用作移动推送通知服务，将消息直接推送到你的 Android 或 iOS 应用程序。

记住这一点，让我们快速创建一个简单的 SNS 主题：

1. 为此，首先登录到你的 AWS 管理控制台，并在筛选选项中筛选出 SNS 服务。或者，你也可以通过选择 console.aws.amazon.com/sns 来访问 SNS 仪表板。

2. 如果这是你第一次使用 SNS，只需选择“开始使用”选项即可开始。在 SNS 仪表板中，你可以通过选择“创建主题”选项来开始，如下图所示：

1. 选择后，你将被提示提供一个合适的主题名称以及对应的显示名称。主题是 SNS 的核心功能。你可以使用主题向特定类型的订阅者发送消息。记住，一个主题可以被多个订阅者订阅。一旦你填写了所需的字段，选择“创建主题”选项以完成此过程。就这样！简单吧？

2. 创建主题后，你现在可以将其与一个或多个订阅者关联。为此，首先我们需要创建一个或多个订阅。在新创建的主题下，选择提供的“创建订阅”选项，如下图所示：

1. 在此，在“创建订阅”对话框中，选择一个合适的协议来订阅新创建的主题。在这种情况下，我选择了 Email 作为协议。接下来，在随后的“终端节点”字段中提供一个有效的电子邮件地址。终端节点字段会根据所选协议而有所不同。完成后，点击“创建订阅”按钮以完成该过程。

2. 创建订阅后，你现在需要验证该订阅。这可以通过启动你的电子邮件应用并选择你收到的邮件中的“确认订阅”链接来完成。

3. 一旦订阅得到确认，你将被重定向到一个确认页面，在那里你可以查看订阅的主题名称以及订阅 ID，如下图所示：

1. 您可以使用相同的过程为同一主题创建并分配多个订阅者。例如，选择创建订阅选项，按之前的操作，从协议下拉列表中选择 SMS 作为新的协议。接下来，在随后的端点字段中提供一个有效的电话号码。该号码可以以您的国家代码为前缀，如下图所示。完成后，点击创建订阅按钮以完成此过程：

1. 订阅成功创建后，您现在可以通过向您的主题发布消息来测试这两项功能。为此，请从您的主题页面选择发布到主题选项。一旦在此处发布消息，SNS 将尝试将该消息发送到每个订阅端点；在此案例中，发送到电子邮件地址以及电话号码。

2. 输入合适的主题名称，后跟您希望发送的实际消息。请注意，如果您的字符数超过 160 个字符，SNS 将自动发送另一条短信，包含剩余的字符数。您可以选择在原始格式和 JSON 格式之间切换消息格式，以符合您的需求。完成后，选择发布消息。

3. 再次检查您的电子邮件应用程序以查看已发布的消息。您应该会收到一封邮件，如下图所示：

类似地，您可以为每个创建的主题创建并关联一个或多个订阅。在下一节中，我们将介绍如何利用 SNS 向一个或多个电话号码发送短信或文本消息。

使用 SNS 发送短信

亚马逊 SNS 还为用户提供了一个非常易于使用的界面，允许您向一个或多个电话号码发送短信或 SMS 消息。它还提供了根据消息的紧急程度对消息进行分类和发送的功能，并可以指定您每月发送短信时愿意花费的最大金额。所以，别浪费时间，让我们直接开始吧：

1. 要使用 SNS 发送短信，首先通过选择console.aws.amazon.com/sns/登录 SNS 仪表板。

2. 登录后，从导航面板中选择文本消息（SMS）选项。这将打开文本消息（SMS）仪表板，您可以在此设置您的短信偏好设置，并向一个或多个电话号码发送消息。首先，通过从仪表板中选择管理短信偏好设置选项来设置一些偏好设置。

3. 填写以下偏好设置字段：

   • 默认消息类型：SNS 提供两种消息类型：推广和事务性。如果您要发送的消息不那么重要（例如，简单的营销信息等），可以选择推广选项。另一方面，事务性消息更适合发送关键性信息，例如一次性密码、交易详情等。SNS 优化事务性消息的发送，以确保最佳的可靠性。

在撰写本书时，发送短信在以下国家/地区得到支持，详情请见docs.aws.amazon.com/sns/latest/dg/sms_supported-countries.html。

对于这个特定场景，我选择了推广选项，如下图所示：

• • 账户消费限制：您希望每月发送消息时的最大花费，单位为美元。默认情况下，限制设置为 1.00 美元。在本场景中，我们将不更改此值。

推广消息和事务性消息类型的费用根据指定的国家或地区不同而有所不同。您可以在aws.amazon.com/sns/sms-pricing/查询价格。

• • CloudWatch Logs 访问的 IAM 角色：此选项用于创建一个 IAM 角色，允许 Amazon SNS 将日志写入 CloudWatch。由于这是第一次配置此功能，请选择创建 IAM 角色选项。这将引导您到一个新页面，您应选择允许选项，以授予 SNS 所需的权限。以下是为您的 IAM 角色提供的权限片段：

{ 
  "Version": "2012-10-17", 
  "Statement": [ 
    { 
      "Effect": "Allow", 
      "Action": [ 
        "logs:CreateLogGroup", 
        "logs:CreateLogStream", 
        "logs:PutLogEvents", 
        "logs:PutMetricFilter", 
        "logs:PutRetentionPolicy" 
      ], 
      "Resource": [ 
        "*" 
      ] 
    } 
  ] 
} 

• • 默认成功采样百分比：此选项用于指定成功发送的短信百分比，基于此，SNS 会将日志写入 CloudWatch。如果仅想记录失败的消息发送日志，请将此值设置为0。默认情况下，SNS 会记录所有成功的发送日志（100%）。

  • 默认发送者 ID：此选项用于指定消息发送者的名称。您可以在此处提供任何有意义的名称。

  • 报告存储：使用此选项配置一个 S3 存储桶，用于存储来自 Amazon SNS 的每日短信使用报告。如果您提供的是现有的存储桶作为报告存储，请确保该存储桶具有与 SNS 服务交互所需的访问权限。

1. 填写完所需字段后，选择更新偏好设置选项以完成该过程。

要发送短信，只需从文本消息（SMS）仪表板选择发送文本消息（SMS）选项。这将弹出发送短信（SMS）对话框，如下图所示。提供有效的电话号码和消息。记得在电话号码中前缀添加您的国家区号：

你还可以选择性地覆盖此处的 Sender ID 字段，不过在这个案例中，我们保持默认值，它是在偏好设置阶段配置的。填写完必填字段后，只需选择发送短信以完成消息发送过程。你还可以通过在“短信（SMS）”页面提供的账户统计部分验证每个消息的送达状态，可以是交易性或促销性。

使用 Amazon SNS 作为触发器。

拥有像 SNS 这样的服务的一个关键好处是，它也可以作为多种用例的触发机制。SNS 发送的消息可以触发简单的 Lambda 函数，Lambda 函数执行某些操作，比如对其他 AWS 服务进行操作，或者简单地处理 SNS 的消息内容并将其转发到另一个应用程序。在本节中，我们将探索一个非常简单的用例，其中 SNS 主题作为触发机制，触发 Lambda 函数将 CloudWatch 警报推送到 Slack！这些警报将发送到一个自定义的 Slack 频道，IT 团队可以在该频道中跟踪警报和有关 AWS 环境的其他重要通知。

从更广泛的角度来看，以下是我们计划为此活动做的事情：

• 创建一个 SNS 主题，它将作为 Lambda 触发器。

• 为我们的 EC2 机器创建一个 CloudWatch 报警，比如当 CPU 利用率超过 80%时触发报警。

• CloudWatch 报警将把通知发送到 SNS 主题。

• SNS 主题将作为我们的 Lambda 函数的触发器。

• 一旦 Lambda 函数收到触发，它将把通知发送到我们的 Slack 频道。

听起来很简单？那我们就开始实现它吧：

1. 首先，我们需要创建一个简单的 SNS 主题，它将作为 Lambda 函数的触发器。按照我们之前的步骤创建一个简单的 SNS 主题。完成后，记下主题仪表板中的 SNS 主题 ARN。在本例中，我们的 SNS 配置为将通知发送到一个电子邮件订阅者，该订阅者是 IT 管理员的邮件别名。

2. 接下来，我们创建我们的 CloudWatch 报警。为此，选择 AWS 管理控制台中的 CloudWatch 服务，并点击导航面板中的“警报”。选择“创建警报”以开始。

3. 在这个场景中，我们将监控我们环境中的 EC2 实例，因此我选择了 EC2 指标选项。你也可以根据需求选择其他指标。在我们的例子中，我们配置了一个简单的 CPUUtilization 报警，如下图所示：

1. 确保你为警报设置了通知，并将其指向新创建的 SNS 主题，如下图所示：

在设置好 SNS 主题和 CloudWatch 警报后，我们需要配置一个 Slack 频道，用于发布警报通知。为此，我们需要设置一个传入的 Webhook 并获取一个钩子 URL，之后可以用它来发布通知：

1. 进入你的 Slack 团队设置页面，选择“应用和集成”选项，如下图所示：

你可以在slack.com/get-started注册一个免费的 Slack 账户。

1. 一旦点击“应用和集成”，系统会将你带到一个新页面，列出了多种预配置的应用。搜索Incoming并从出现的选项中选择“传入 Webhook”。

2. 接下来，点击“添加配置”。系统会要求你选择要发布的频道，并填写一些其他必要的参数。在继续执行下一步之前，请确保你已复制并保存 Webhook URL。

现在我们已经准备好 Slack 钩子 URL，可以开始部署我们的 Lambda 函数了。在这个示例中，我们将使用为 Slack 集成设计的现有 AWS Lambda 函数蓝图，使用的是 Node.js 4.3 版本：

1. 从 AWS 管理控制台的仪表盘中，使用筛选选项筛选 Lambda 服务，或者选择console.aws.amazon.com/lambda/home。

2. 在 AWS Lambda 的首页，选择“创建函数”选项开始操作。

3. 在使用 Lambda 函数时，你可以选择从头创建一个新的函数，或者从一系列预定义和配置好的蓝图中筛选并使用一个函数。在这种情况下，选择“蓝图”选项，并使用相邻的蓝图筛选器搜索以下函数：蓝图名称：cloudwatch-alarm-to-slack（如下面的截图所示）：

1. 选择蓝图后，填写你函数的必要信息，比如名称、角色名称等。完成后，在 SNS 部分，从下拉列表中选择新创建的 SNS 主题。

2. 在继续下一步之前，记得勾选“启用触发器”复选框。

3. 最后，在“环境变量”部分，提供slackChannel和kmsEncryptedHookUrl参数的适当值，如下图所示。记住，kmsEncryptedHookUrl就是我们之前创建的 Slack 钩子 URL：

1. 填写完所有值后，简单选择“创建函数”选项，让魔法开始吧！

根据为告警选择的 CloudWatch 指标，继续为你的 EC2 实例创建一些合成负载。一旦负载超过告警中设定的阈值，它会触发相应的消息到 SNS 主题，进而触发 Lambda 函数在 Slack 渠道发布告警。通过这种方式，你还可以使用相同的 SNS 主题来订阅其他服务，例如 Amazon SQS，进行其他处理需求。

使用 Amazon CloudWatch 指标监控 Amazon SNS

Amazon SNS 会自动收集并将消息投递的各种指标发送到 Amazon CloudWatch。你可以查看这些指标，并为它们设置告警，提醒你在消息投递率低于某个阈值时。你还可以使用 CloudWatch 日志页面查看消息投递日志：

1. 要开始，首先确保你已经分配了允许 SNS 将短信投递日志写入 CloudWatch 的 IAM 角色。为此，从导航窗格中选择“文本消息（SMS）”选项。

2. 接下来，在“管理短信偏好设置”选项中，确保在“CloudWatch 日志访问的 IAM 角色”字段下提供了有效的 IAM 角色。

3. 一旦 IAM 角色创建完成，登录到你的 CloudWatch 仪表盘，选择console.aws.amazon.com/cloudwatch/home。

4. 在这里，从导航窗格中选择“日志”选项，打开 CloudWatch 日志组页面。你应该能看到一个名为DirectPublishToPhoneNumber的默认日志组。

5. 选择日志组以查看短信投递日志信息。日志将显示SUCCESS或FAILURE，并出现在status字段中，如下截图所示：

1. 你还可以为监控的 SNS 指标创建并关联 CloudWatch 告警。为此，从 CloudWatch 仪表盘中选择“指标”选项。

2. 从“所有指标”标签页中，筛选并选择 SNS 选项。

3. 根据需求，你现在可以选择根据 PhoneNumber、Country、SMSType 等查看指标。在本例中，我们选择了 PhoneNumber 选项，以查看 NumberOfNotificationsFailed 和 NumberOfNotificationsDelivered 指标。

4. 接下来，选择“图表化的指标”标签页，查看这两个指标及其相关操作。使用“操作”列，选择你希望监控的指标的“创建告警”选项。

5. 填写相关详细信息，并根据需求配置告警的阈值。一旦完成，点击“创建告警”以完成设置。

通过这种方式，你可以利用 Amazon CloudWatch 创建并查看由 SNS 服务生成的日志和告警。在下一部分中，我们将探索并学习 AWS 消息服务的第二部分：SQS。

介绍 Amazon 简单队列服务

Amazon SQS 是一项托管的、高度可扩展的且持久的服务，提供开发人员一种机制来存储消息，供一个或多个应用程序稍后消费。在本节中，我们将探讨 SQS 提供的一些概念和术语，并了解在不同场景下该使用哪个 SQS 队列，下面我们就开始吧！

首先，SQS 提供两种不同的模式：

• 标准队列：标准队列是使用 SQS 时的默认选择。在这里，所创建的队列提供几乎无限的每秒事务数（TPS），并配有 至少一次 的交付模型。这意味着消息至少会被交付一次，但偶尔也可能有很大概率同一消息会被多次交付。这是因为 SQS 设计和构建在一个高度分布式的系统上，已知会创建同一消息的副本以维持高可用性。因此，你可能会收到多次相同的消息。

标准队列还采用 尽力而为的顺序 模型，在这种情况下，消息的交付顺序可能与发送时的顺序不同。将消息按正确的接收顺序排序的工作由你的应用程序来完成。那么，什么时候标准队列是解耦应用程序的理想选择呢？如果你的应用程序有高吞吐量要求，例如批量消息处理、将用户请求与高强度背景处理工作解耦等，那么标准队列是正确的选择。

标准队列在所有 AWS 区域都可用。

• FIFO 队列：在使用标准队列时，会遇到保持消息顺序并确保每条消息只处理一次的问题。为了解决这个问题，AWS 引入了 FIFO 队列，它为开发人员提供了消息交付顺序的保证，并确保每条消息只交付一次，绝不发送重复或副本。

另一方面，FIFO 队列不像其前身那样提供无限的吞吐能力。截止本书编写时，FIFO 队列每秒最多支持发送 300 条消息，如果每次操作处理 10 条消息，则额外可支持每秒 3,000 条消息的吞吐量。

这种队列在消息顺序至关重要时非常有用，例如，确保用户在注册或购买产品时按照正确的事件顺序进行操作等。

FIFO 队列目前仅在美国东部（北弗吉尼亚）、美国东部（俄亥俄）、美国西部（俄勒冈）和欧盟（爱尔兰）地区提供。

在有了这些基本了解之后，让我们看看一些简单的步骤，帮助你在几分钟内创建自己的队列！

创建你的第一个队列

使用您自己的 SQS 队列入门是一个相当简单的过程。在本节中，我们将介绍如何使用 AWS 管理控制台创建您自己的标准队列：

1. 首先，登录到您的 AWS 管理控制台，并使用提供的过滤器选项过滤出 SQS 服务。或者，您也可以通过选择console.aws.amazon.com/sqs/home来访问 SQS 仪表板。

2. 由于这是我们第一次配置 SQS 队列，请选择“立即开始”选项继续。

3. 在“创建新队列”页面中，首先在队列名称字段中为您的队列提供一个合适的名称。

如果您正在构建 FIFO 队列，您需要在队列名称后加上 .fifo 后缀，例如：myQueue.fifo。

1. 填写完队列名称后，下一步是选择您希望设置的队列类型。在这种情况下，我们首先选择标准队列选项。

2. 接下来，选择“配置队列”选项，以查看队列的一些配置参数。或者，您也可以选择“快速创建队列”选项，选择队列的所有默认参数。

3. 在队列属性部分，您可以根据需求自由修改以下一组队列参数：

   • 默认可见性超时：Amazon SQS 不会自动从队列中删除消息，即使这些消息已经被消费者处理。因此，消费者有责任在接收到并处理消息后，将其从队列中删除。

然而，由于 SQS 的分布式特性，不能保证其他消费者不会尝试从同一消息的副本中读取。为了防止这种情况发生，SQS 在消息被消费者接收后，设置了一个短暂的可见性超时期。这会防止其他消费者在超时之前读取该消息。

默认情况下，可见性超时可以设置为最短 30 秒，最长 12 小时。如果消费者未能在分配的超时窗口内处理该消息，则该消息将被交付给其他消费者，直到消费者从队列中删除该消息为止，过程才会结束。

• • 消息保留时间：Amazon SQS 保留消息的时间，如果消息没有被删除。这里接受的值最小为 1 分钟，最大为 14 天。

  • 最大消息大小：Amazon SQS 接受的最大消息大小（字节）。最大限制为 256 KB。

  • 传递延迟：Amazon SQS 允许您在队列中暂时延迟新消息的投递，延迟时间为指定的秒数。这是通过将新消息放入由 AWS 完全管理的延迟队列来实现的。尽管这看起来与可见性超时的概念相似，但延迟队列在消息首次添加到队列时会将其隐藏，而后者则是在消息被消费者提取时将其隐藏。此处接受的值为 0 秒到 15 分钟之间：

• • 接收消息等待时间：Amazon SQS 定期查询少量服务器，以确定是否有新消息可供消费。此方法称为短轮询，并且通常在接收消息等待时间设置为 0 时默认启用。然而，这种方法会导致大量空响应，因为有时队列中可能没有可供消费的消息。在这种情况下，SQS 还提供了长轮询的概念，即 Amazon SQS 等待直到队列中有消息可用时才发送响应。这大大减少了空响应的数量，并有助于降低系统的整体运行成本。要启用长轮询，只需将接收消息等待时间的值更改为 0 到 20 秒之间的值。

配置了这些基本设置后，您现在可以继续创建自己的队列。不过需要注意的是，您还可以配置一些额外的设置，比如死信队列和服务器端加密。但我们暂时先不讨论这些内容。完成后请选择“创建队列”。

在创建新队列后，您现在可以通过简单地复制队列的 URL（https://sqs.us-east-1.amazonaws.com/<ACCOUNT_ID>/<QUEUE_NAME>）并将其提供给您的应用程序或消费者来开始使用它：

您还可以通过使用 SQS 仪表板向队列发送测试消息来测试队列的功能。从 SQS 仪表板中选择新创建的队列，然后在“队列操作”下拉菜单中选择“发送消息”选项。

这将打开“发送消息”对话框，如下图所示。接下来，在“消息正文”部分输入测试消息，然后点击“发送消息”以完成该过程：

您还可以选择通过启用“延迟发送此消息”选项并提供 0 到 15 分钟之间的值，来更改此单个消息的传递延迟。

发送消息后，你将收到消息的 标识符 和消息体的 MD5 校验和。点击“关闭”以关闭“发送消息”对话框。此时，“可用消息”列的状态应该变为 1，因为新消息现在正在等待被读取或消费。要从 SQS 控制台读取消息，再次选择队列操作下拉菜单，并选择“查看/删除消息”选项。

这将弹出“查看/删除消息”对话框，如下图所示。在这里，系统会每隔 2 秒轮询一次队列，直到你使用“轮询队列”选项指定轮询。你还可以通过修改“最多查看”字段来更改查看的最大消息数。完成后，选择“开始轮询消息”选项以启动操作：

启动轮询后，你应该很快在显示区域看到你的测试消息。你还可以通过选择与消息相邻的“更多详情”选项，并验证之前记录的 MD5 校验和，来验证消息的有效性。

完成后，选择消息并点击“删除消息”选项，将消息从队列中移除。记住，这是一个永久性操作，无法撤销。删除消息后，队列应该会再次显示零个正在传输或可用的消息。

使用 AWS CLI 创建 FIFO 队列

使用 AWS 管理控制台足够简单，但 AWS CLI 使事情变得更简单！在本节中，我们将介绍一些简单的 AWS CLI 命令，你可以使用它们来创建并操作你的第一个 FIFO 队列：

1. 要开始操作，我们需要一台已经安装并配置了最新版本 AWS CLI 的服务器或实例。如果你还没有配置好，可以快速查看docs.aws.amazon.com/cli/latest/userguide/installing.html提供的详细步骤。

2. 安装并配置好 AWS CLI 后，你可以使用以下命令来创建你的第一个 FIFO 队列。首先，创建一个简单的 JSON 文件，用于存储我们希望传递给新 FIFO 队列的必要属性列表：

# vi fifo-queue.json 
#### PASTE THE FOLLOWING CONTENTS ##### 
{"VisibilityTimeout" : "30", 
"MaximumMessageSize" : "262144", 
"MessageRetentionPeriod" : "345600", 
"DelaySeconds" : "10", 
"ReceiveMessageWaitTimeSeconds" : "0", 
"FifoQueue" : "true", 
"ContentBasedDeduplication" : "true" 
} 

在这里，大多数值你可能已经熟悉了，比如 VisibilityTimeout、MaximumMessageSize、DelaySeconds 等等。这里列出的两个专门为 FIFO 队列设计的新属性是：

• • FifoQueue：用于将队列指定为 FIFO 队列。请注意，无法将现有的标准队列更改为 FIFO 队列。你必须完全重新创建一个 FIFO 队列。此外，当你为队列设置此属性时，必须显式提供消息的 MessageGroupId。

  • ContentBasedDeduplication：它确保每条消息只会被处理一次。当启用ContentBasedDeduplication后，在去重时间窗口内，具有相同内容的消息会被视为重复消息，且只会传递一份消息。

1. 创建 JSON 文件后，运行以下命令以创建你的 FIFO 队列：

# aws sqs create-queue --queue-name myQueue.fifo
--attributes file://fifo-queue.json 

你应该在输出中收到新的 FIFO 队列终端节点 URL，如下图所示：

1. 创建队列后，你还可以使用 CLI 将消息传递到队列中。这也可以通过以下命令来实现：

# aws sqs send-message  
--queue-url https://queue.amazonaws.com/012345678910/myQueue.fifo  
--message-body "Well this is far easier than I expected."  
--message-group-id "R@nD0M" 

send-message命令将队列 URL 作为输入参数之一，另外还需要提供要发送的实际消息。消息可以是原始的、JSON 格式或 XML 格式。除此之外，send-message命令还使用--message-group-id参数，它基本上将消息标记为属于特定的消息组。属于同一消息组的消息会按 FIFO 顺序处理：

在使用 FIFO 队列时，--message-id-group参数是必需的。

1. 现在消息已被发送到队列，你也可以使用 AWS CLI 来接收消息。使用以下命令从你的 FIFO 队列中获取消息：

# aws sqs receive-message  
--queue-url https://queue.amazonaws.com/012345678910/myQueue.fifo 

你还可以额外使用--max-number-of-messages属性列出当前队列中最多 10 条可用消息。以下是你可能通过前述命令获得的输出片段：

{ 
    "Messages": [ 
        { 
            "Body": "Well this is far easier than I expected.", 
            "ReceiptHandle": "AQnmzJjGNrI9cl7ZyZ2NyVDDDy==", 
            "MD5OfBody": "d733b7da2656ffc18d99bea3613e24d7", 
            "MessageId": "a075bd88-4942-416d-b632-0258ac8" 
        } 
    ] 
} 

你也可以使用 AWS CLI 列出环境中可用的队列，修改其参数，推送和轮询新消息，删除消息，等等！记住，消息会在队列中持续存在，直到你手动删除它们或队列的MessageRetentionPeriod有效期过期。

集成亚马逊 SNS 和亚马逊 SQS

亚马逊 SQS 的一个关键特点是它可以轻松与其他 AWS 服务集成，例如亚马逊 SNS。为什么我需要这样的功能？首先，让我们快速回顾一下我们目前所了解的 SNS 和 SQS：

亚马逊 SNS	亚马逊 SQS
利用推送机制	利用轮询机制
亚马逊 SNS 消息可以直接推送到移动设备或其他订阅者	亚马逊 SQS 需要一个工作者来轮询消息
不支持消息持久化	亚马逊 SQS 支持消息持久化，如果由于网络故障无法接触到消费者，这非常有用

从表格中可以很容易地看到，这两项服务在使用时各有优缺点。然而，当我们将这两项服务结合使用时，实际上可以利用它们来设计和构建大规模可扩展且解耦的应用程序。结合 SNS 和 SQS 使用的一个常见架构模式被称为 扇出模式。

在这种模式下，发布到特定 SNS 主题的单条消息可以并行分发到多个 SQS 队列。因此，您可以构建高度解耦的应用程序，利用并行和异步处理的优势。考虑一个简单的示例来演示这种模式。用户将一张图片上传到其 S3 存储桶，这会触发 SNS 通知并发送到特定的 SNS 主题。该主题可以被多个 SQS 队列订阅，每个队列都运行与其他队列完全独立的进程。例如，一个队列可以用于处理图片的元数据，而另一个队列可以用于将图片调整为缩略图，依此类推。在这种模式中，队列可以独立工作，而无需担心其他队列是否完成了处理。以下是该模式的示意图：

1. 要集成 SNS 和 SQS 服务，您首先需要创建您自己的简单 SNS 主题。请按照本章前面所示，使用 AWS 管理控制台创建一个新的 SNS 主题。

2. 主题准备好后，下一步是创建关联的订阅。为此，在 SNS 控制台中，从导航面板中选择“订阅”选项，点击“创建订阅”以开始操作。

3. 在“创建订阅”对话框中，将新创建的主题的 ARN 复制并粘贴到 Topic ARN 字段，如下图所示：

1. 一旦粘贴了 Topic ARN，选择协议下拉列表中的 Amazon SQS 选项，然后将队列的 ARN 粘贴到 Endpoint 字段中。在这种情况下，我使用的是我们在本章前面创建的标准队列的端点。

2. 填写必填字段后，选择“创建订阅”以完成过程。

3. 接下来，在 SQS 控制台中，选择您为此集成所确定的队列，并在“权限”选项卡中选择“添加权限”，以允许 SNS 服务向该队列发送消息。为此，请提供以下权限集：

   • 效果：允许

   • 角色：Everybody

   • 操作：SendMessage

4. 完成后，点击“添加权限”以授予 SNS 服务所需的权限集。

5. 现在我们准备测试集成！要做到这一点，只需从 SNS 仪表板的“发布到主题”选项中发送一个示例消息。一旦消息成功发送，请切换到 SQS 仪表板，并使用“查看/删除消息”选项从“队列操作”下拉列表中轮询队列。

这是在长轮询队列后获取的消息正文片段：

同样，您可以使用这样的扇出模式来设计和构建自己的高度可扩展和解耦的云应用程序。

计划您的下一步

嗯，这确实是很多需要学习和尝试的内容，但我们还没有完成！您还应该自己尝试一些关于 SNS 和 SQS 的内容。首先是 Amazon SNS 移动推送通知。

我们已经提到了 Amazon SNS 可以用来向各种订阅者发送通知，包括 HTTP、HTTPS 端点、Amazon SQS 和 AWS Lambda，但最近增加的另一个关键功能是 SNS 直接推送通知到您的移动设备应用程序上。这就是所谓的SNS 移动推送通知，目前，SNS 支持以下推送通知服务：

• Amazon 设备消息 (ADM)

• Apple 推送通知服务 (APNS) 用于 iOS 和 macOS

• 百度云推送 (Baidu)

• Google 云消息传递 (GCM) 用于 Android

• Microsoft 推送通知服务 (MPNS) 用于 Windows Phone

• Windows 推送通知服务 或 Windows 通知服务 (WNS)

要开始使用移动推送通知非常简单明了。您只需要一组用于连接支持的推送通知服务的凭据，用于移动应用程序和设备本身的设备令牌或注册 ID，以及配置为向移动端点发送推送通知消息的 Amazon SNS。

您可以在docs.aws.amazon.com/sns/latest/dg/SNSMobilePush.html了解更多关于 SNS 移动推送通知服务的信息。

另一个值得尝试的重要功能是为您的 Amazon SQS 队列配置服务器端加密。您可以利用 SSE 对存储在队列中的数据进行加密和保护，但是目前此功能仅在美国东部（弗吉尼亚北部）、美国东部（俄亥俄州）和美国西部（俄勒冈州）地区可用。

在队列创建时以及队列创建后都可以对队列进行加密。但是，如果现有队列已经开启了 SSE，则队列中存在的旧消息不会被加密。

你可以通过在 SQS 仪表板上选择现有队列，并在队列操作下拉菜单中选择“配置队列”选项，来配置现有队列的 SSE。然后，选中“使用 SSE”复选框以启用队列的服务器端加密。此时，你将被提示选择一个客户主密钥（CMK）ID，如果你没有自己的 CMK，可以保留默认值。完成后，设置数据密钥重用周期的持续时间，范围为 1 分钟到 24 小时。点击“保存更改”以应用最近对队列的修改。

你可以阅读更多关于 SSE 以及如何在新队列上启用它的内容，访问docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-create-queue-sse.html。

最后但同样重要的是，我还建议你尝试一下 Amazon SQS 提供的死信队列功能。死信队列其实就是你为存储无法被应用程序主处理队列处理的消息而创建的队列。当你需要调试应用程序或消息系统中的问题时，这非常有用。然而，非常重要的一点是，标准队列的死信队列始终是标准队列，同样，基于 FIFO 的队列也是如此。

你可以通过简单地配置应用程序主队列的 Redrive 策略，将账户中的任何队列配置为另一个队列的死信队列。想要了解更多关于死信队列及其工作原理的信息，请查看docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html。

总结

哇，这一章确实很有洞察力。在我们进入下一章之前，快速回顾一下我们迄今为止学到的内容！

首先，我们快速了解了 AWS 提供的各种消息服务。接下来，我们深入探索了神奇的 Amazon SNS 世界，创建了我们的第一个主题，并订阅了电子邮件和手机订阅。我们还了解了如何配置和利用 SNS 的短信服务。

一旦我们掌握了 SNS 的基础知识，我们就进入了下一个消息服务 SQS，了解了它的一些概念和术语。我们使用 AWS 管理控制台和 AWS CLI 创建了我们的第一个队列，最后我们还了解了这两个服务的一个非常有用的集成，您可以利用它来设计和构建可扩展的、解耦的云应用程序。最后，我们为你提供了一个实用的后续步骤指南，供你在空闲时间尝试！

在下一章中，我们将学习并探索两个非常棒的分析服务，分别是 Amazon Elastic MapReduce 和 Amazon Redshift，敬请期待！

第九章：使用 Amazon EMR 和 Amazon Redshift 强化分析功能

在上一章中，我们学习了两个非常有用的服务，开发人员可以利用这些服务在云中构建高度可扩展且解耦的应用程序：Amazon SNS 和 Amazon SQS。

在本章中，我们将提高一个层次，探索两个非常强大的 AWS 服务，这些服务非常适合在云中处理和运行大规模分析和数据仓储：Amazon EMR 和 Amazon Redshift。

记住这一点，让我们快速浏览一下本章将要涵盖的各个主题：

• 通过深入了解 Amazon EMR、其用例和好处来理解 AWS 分析服务套件

• 介绍一些关键的 EMR 概念和术语，并进行快速入门指导

• 在 EMR 上运行样本工作负载，使用步骤

• 介绍 Amazon Redshift

• 开始使用 Amazon Redshift 集群

• 使用 Redshift 数据库和表

• 从 Amazon EMR 加载数据到 Amazon Redshift

所以，事不宜迟，让我们立即开始吧！

了解 AWS 分析服务套件

随着大数据的增长以及各大组织对其的广泛应用，许多云服务提供商现在提供了大量专门设计用于在海量数据上进行大规模计算和分析的服务。AWS 就是其中之一，它也在大数据和分析范式上投入了大量资源，提供了一系列现成的框架、商业洞察和数据仓储解决方案。以下是 AWS 分析服务套件的简要说明：

• Amazon EMR：Amazon Elastic MapReduce 或 EMR 是一项快速且易于使用的服务，提供可扩展的托管 Hadoop 生态系统和框架。你可以利用 EMR 处理大量数据，而无需担心配置底层的 Hadoop 平台。我们将在本章的后续部分中深入学习和探索 EMR。

• Amazon Athena：Amazon Athena 通过提供标准 SQL 接口来查询直接存储在 Amazon S3 上的数据，提升了大数据处理能力。使用 Athena 时，你不需要管理或维护任何底层硬件；这一切都由 AWS 管理。这种 无服务器 的方式使得 Athena 非常适合处理不需要复杂 ETL 处理的数据。你需要做的只是创建一个模式，将 Athena 指向存储在 Amazon S3 上的数据，并使用简单的 SQL 语法开始查询。

• Amazon Elasticsearch Service：Amazon Elasticsearch Service 提供了流行的开源搜索和分析引擎 Elasticsearch 的托管部署。当你希望处理来自各种来源（如实例生成的日志等）的数据流时，这项服务非常有用。

• Amazon Kinesis：与之前讨论的其他服务不同，Amazon Kinesis 更像是一个由 AWS 提供的流处理服务。您可以使用 Amazon Kinesis 将来自多个源的大量数据推送到一个或多个数据流中，这些流可以被其他 AWS 服务消费，用于执行分析和其他数据处理操作。

• Amazon QuickSight：Amazon QuickSight 是一个极具成本效益的商业洞察解决方案，可用于对数据进行快速的临时分析。

• Amazon Redshift：Amazon Redshift 是 AWS 提供的 PB 级数据仓库解决方案，您可以利用它使用现有的工具集来分析数据。在本章稍后，我们将更详细地了解 Redshift。以下是这些服务的示意图：

• AWS Data Pipeline：在 AWS 服务之间迁移大量数据可能非常困难，尤其是在数据源各异的情况下。AWS Data Pipeline 使得在不同的 AWS 存储和计算服务之间传输数据变得更加容易，同时也帮助进行数据的初步转换和处理。您甚至可以使用 Data Pipeline 将数据可靠地从本地环境传输到 AWS 存储服务。

• AWS Glue：AWS Glue 是 AWS 最近推出的托管ETL（提取、转换和加载）服务。使用 AWS Glue 可以大大简化从大型数据集准备、提取和加载数据到 AWS 存储服务的过程。

通过对 AWS 分析服务套件的简要概述，我们现在可以继续并开始进一步了解 Amazon EMR！

介绍 Amazon EMR

如前所述，Amazon EMR 是一种托管服务，提供开箱即用的大数据分析框架，如 Apache Hadoop 和 Apache Spark，并准备好供使用。通过使用 Amazon EMR，您可以轻松执行各种用例，如批处理、大数据分析、低延迟查询、数据流处理，甚至将 EMR 作为一个大型数据存储来使用！

使用 Amazon EMR，您无需管理太多底层基础设施。您只需决定最初希望在哪些实例上运行您的 EMR 集群，并开始使用该框架进行分析和处理。Amazon EMR 为您提供了能够根据需求扩展基础设施的功能，而不影响现有设置。以下是您可以通过利用 Amazon EMR 处理您自己工作负载所获得的一些好处：

• 定价：Amazon EMR 依赖于 EC2 实例来启动您的 Apache Hadoop 或 Apache Spark 集群。尽管您可以通过选择集群的实例类型（从大到超大等）来调整成本，但 EMR 的最大优势是，您还可以根据您的设置选择使用按需 EC2 实例、预留实例和竞价实例的组合，从而为您提供灵活性，并显著降低成本。

• 可扩展性：Amazon EMR 为您提供了一种简单的方式来根据工作负载的处理需求扩展运行中的工作负载。您可以根据需要调整集群或其各个组件的大小，并且可以配置一个或多个实例组，以保证实例的可用性和处理能力。

• 可靠性：尽管作为最终用户，您需要指定初始实例及其大小，但 AWS 最终通过更换那些已失败或即将失败的实例来确保集群的可靠性。

• 集成：Amazon EMR 与其他 AWS 服务集成，为您的集群提供额外的存储、网络和安全要求。您可以使用诸如 Amazon S3 来存储输入和输出数据，AWS CloudTrail 用于审计对 EMR 的请求，VPC 确保您启动的 EMR 实例的安全性，等等！

牢记这些细节后，让我们通过先了解一些关键概念和术语，逐步迈向启动我们自己的 EMR 集群。

概念和术语

在我们开始使用 Amazon EMR 之前，了解其一些关键概念和术语是很重要的，首先从集群和节点开始：

• 集群：集群是 Amazon EMR 的核心功能组件。集群是由一组 EC2 实例组成的，这些实例可以一起用来处理您的工作负载。集群中的每个实例称为一个节点，每个节点在集群内有不同的角色。

• 节点：Amazon EMR 通过为集群实例提供以下三种角色之一来区分集群实例：

  • 主节点：负责集群的整体可管理性、工作和监控的实例。主节点负责处理集群内发生的所有数据和任务分配。

  • 核心节点：核心节点与主节点非常相似；然而，它们主要用于运行任务并在您的Hadoop 分布式文件系统（HDFS）上存储数据。核心节点还可以包含一些 Hadoop 应用程序的额外软件组件。

  • 任务节点：任务节点仅设计用于运行任务。它们不包含任何 Hadoop 应用程序的额外软件组件，在集群部署时是可选的。

• 步骤：步骤是提交到集群进行处理的简单任务或作业。每个步骤包含一些指示，说明如何执行特定的作业。步骤可以按顺序安排，例如，某个步骤可以用于从 Amazon S3 获取输入数据，而第二个步骤可以用于运行 Pig 或 Hive 查询，最后第三个步骤用于将输出数据存储到 Amazon DynamoDB。如果某个步骤失败，后续的步骤会自动取消执行，然而，您可以选择通过设置步骤忽略失败并继续处理来覆盖这一行为。

除了这些概念，您还需要复习 Apache Hadoop 框架和术语。以下是一些在使用 Amazon EMR 时可能会遇到的 Apache 框架和应用程序的快速介绍：

• 存储：EMR 的一个重要部分是数据如何实际存储和检索。以下是使用 Amazon EMR 时提供的一些存储选项：

  • Hadoop 分布式文件系统（HDFS）：顾名思义，HDFS 是一个分布式和可扩展的文件系统，允许数据跨底层节点实例进行存储。默认情况下，数据会在集群中的实例间进行复制和存储。这提供了高可用性和数据弹性，以防实例发生故障。您可以在此处了解更多关于 HDFS 的信息：hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html。

  • EMR 文件系统（EMRFS）：EMRFS 是 HDFS 文件系统的扩展，您可以使用它直接在 Amazon S3 上访问和存储数据，就像使用普通文件系统一样。

  • 本地文件系统：除了 HDFS，每个集群中的实例还会提供一个小块的预附加临时磁盘，这也被称为本地文件系统。您可以使用这个本地文件系统来存储 Hadoop 框架所需的额外软件或应用程序。

• 框架：如前所述，Amazon EMR 提供了两种数据处理框架，您可以根据处理需求选择使用：Apache Hadoop MapReduce 和 Apache Spark：

  • Apache Hadoop MapReduce：MapReduce 是迄今为止构建分布式应用程序时最常用和最广为人知的编程模型。开源模型依赖于一个 Mapper 函数，该函数将数据映射为一组键值对，并且还有一个 Reducer 函数，它将这些键值对组合，应用一些额外的处理，最后生成所需的输出。要了解更多关于 MapReduce 以及如何利用它的信息，请访问此 URL：hadoop.apache.org/docs/r1.2.1/mapred_tutorial.html。

  • Apache Spark：Apache Spark 是一种快速的内存数据处理模型，开发者可以使用它来处理需要快速迭代访问数据集的流处理、机器学习或 SQL 工作负载。它是一个类似于 Apache Hadoop 的集群框架；然而，Spark 利用图形和内存数据库来访问数据。你可以在 spark.apache.org/ 阅读更多关于 Spark 的信息。

• 应用程序和程序：借助标准数据处理框架，Amazon EMR 还提供了其他应用程序和程序，供你用于构建原生分布式应用程序。下面是其中几个的简要介绍：

  • YARN：Yet Another Resource Negotiator（另一个资源调度器），是 Hadoop 框架的一部分，提供集群数据资源的管理功能。

  • Hive：Hive 是一个分布式数据仓库应用程序，利用标准 SQL 查询存储在 HDFS 文件系统中的超大数据集。

目前，Amazon EMR 提供了许多其他应用程序和程序可供使用，例如 Apache Pig、Apache HBase、Apache Zookeeper 等等。在接下来的部分，我们将探讨如何利用这些概念和术语来创建我们自己的 Amazon EMR 集群，快来开始吧！

开始使用 Amazon EMR

在基础内容介绍完之后，在本节中，我们将使用 Amazon EMR 仪表板创建我们的第一个集群。然而，在开始之前，以下是我们需要首先完成的小列表前提步骤。

首先，我们需要创建一个 Amazon S3 存储桶，用于存储输出、EMR 生成的日志以及一些附加脚本和软件文件：

1. 在 AWS 管理控制台中，使用“筛选”选项筛选并选择 Amazon S3 服务。或者，通过访问以下网址启动 Amazon S3 仪表板：s3.console.aws.amazon.com/s3/。

2. 接下来，选择“创建存储桶”选项。在创建存储桶向导中，提供一个合适的存储桶名称，并选择一个适当的区域来创建存储桶。对于本案例，EMR 集群以及 S3 存储桶都创建在 美国东部（俄亥俄州） 区域，不过你可以根据需求选择其他区域。点击“下一步”继续操作。

3. 在设置属性页面，你可以选择为存储桶提供一些 标签，用于成本分配和跟踪目的。点击“下一步”继续。

4. 在设置权限页面，确保不授予存储桶公共读取权限。点击“下一步”以查看设置，最后选择“创建存储桶”以完成操作。

5. 创建存储桶后，使用“创建文件夹”选项来为存储日志、输出以及未来可能使用的其他脚本创建专用文件夹。以下是完成所有前面步骤后存储桶的代表性截图：

1. 在存储桶创建并准备好使用后，剩下的一个先决条件是创建一个密钥对，您可以使用它通过 SSH 访问 EC2 实例。确保密钥对是在与 EMR 集群相同的区域（此处为 美国东部（俄亥俄州））中创建的。

既然先决条件已经处理完毕，我们终于可以开始设置 EMR 集群了！

1. 从 AWS 管理控制台中，使用筛选选项筛选并选择 Amazon EMR 服务。或者，可以通过选择此 URL 启动 Amazon EMR 仪表盘：us-east-2.console.aws.amazon.com/elasticmapreduce/home。

2. 由于这是我们第一次创建 EMR 集群，请选择“创建集群”选项开始。

3. 您可以通过两种方式配置 EMR 集群：快速简便的快速选项（默认显示给您），以及高级选项页面，在该页面上您可以选择并配置集群的各个项。在这种情况下，我们将选择进入高级选项。

4. 高级选项页面为我们提供了一个四步向导，基本上引导我们配置一个完全功能的 EMR 集群。首先，第一步是您可以选择并自定义要在 EMR 集群上安装的软件。

5. 从版本下拉列表中，选择您希望使用的 EMR 版本。本书写作时发布的最新版本是 emr-5.11.1。每个版本包含几个可供安装在集群上的分布式应用程序。例如，选择 emr-5.11.1（2018 年发布）包含 Hadoop v2.7.3、Flink v1.3.2、Ganglia v3.7.2、HBase v1.3.1 以及其他许多应用程序和软件。

要查看可用的 EMR 版本及其相关软件版本的完整列表，请访问：docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-components.html。

1. 在这种情况下，我已经选择了我们在此场景中所需的基本应用程序，包括 Hadoop、Hive 和 Hue。根据您的需求，可以选择其他应用程序。

2. 接下来的几个部分是可选的，但了解它们的目的非常重要：

   • AWS Glue 数据目录设置：在 EMR 版本 5.8.0 及以上版本中，您可以选择配置 Spark SQL 使用 AWS Glue 数据目录（外部 Hive 表）作为其元数据存储。

   • 编辑软件设置：您可以使用此选项覆盖某些应用程序的默认配置设置。通过提供一个 JSON 文件形式的配置对象来实现这一点。您可以选择输入配置或从 S3 加载 JSON 文件：

• • 添加步骤：软件配置页面上的最后一个可选参数是添加步骤。如本章前面简要讨论的那样，步骤本质上是我们提交给集群的工作单元。它可以是从 S3 加载输入数据，或者处理并运行 MapReduce 作业在数据上。我们将在本章稍后更详细地探索步骤，因此请将此字段保持默认值，并选择“下一步”继续流程。

1. 高级选项向导的第二步是配置集群的硬件，或实例配置，以及集群的网络设置。

EMR 提供两种选项：实例舰队和实例组；下面简要解释：

• • 实例舰队：实例舰队允许您为集群中存在的实例指定目标容量。通过此选项，您可以获得最多样化的实例配置选项，可以为节点利用混合实例类型，甚至为同一节点选择不同的购买选项。每创建一个实例舰队，您可以为按需实例和竞价实例设定目标容量。

每个节点类型（主节点、核心节点、任务节点）只能有一个实例舰队。

• • 实例组：另一方面，实例组每个节点类型的可自定义配置选项较少。在实例组中，每个节点由相同的实例类型和相同的购买选项组成。集群创建过程中配置了这些设置后，无法更改；不过，您可以随时根据需要添加更多实例。

1. 对于这个特定的使用案例，我们将选择统一实例组，如下图所示：

1. 接下来，从网络下拉列表中选择您希望启动 EMR 集群的适当VPC。您也可以选择使用旁边的“创建 VPC”选项为 EMR 创建一个新的 VPC。

2. 同样，从 EC2 子网下拉列表中选择适当的子网。

3. 最后，为集群中每个实例分配将要配置的根设备 EBS 卷的大小。您可以提供介于 10 GB 和 100 GB 之间的值。

4. 使用提供的编辑选项，您还可以为每个节点类型配置实例类型、实例数量以及购买选项，如下图所示。请注意，这些选项是因为我们选择了实例组作为首选的实例配置模式。如果选择了实例舰队选项，选项将会有所不同：

1. 您还可以选择启用核心和任务节点的自动扩展，通过在自动扩展列下选择“未启用”选项。随后，您也可以选择“添加任务实例组”选项来添加额外的任务实例组。完成后，选择“下一步”选项继续设置。

2. 高级选项中的第三步提供了您可以根据需求设置的一般配置。首先，提供一个合适的集群名称，然后选择“日志记录”选项来为您的 EMR 集群设置日志记录。使用文件夹选项浏览到我们新创建的 S3 存储桶，如下图所示：

1. 您还可以启用“终止保护”选项，以防止集群被意外删除。

2. 接下来，集群“常规选项”页面上的最后一个配置项是引导操作。顾名思义，引导操作是您希望在集群实例启动时执行的脚本或代码。因此，当您需要向现有运行中的集群添加新实例时，这个功能非常有用。

默认情况下，引导操作是使用 Hadoop 用户执行的。您可以通过使用sudo命令切换到 root 权限。

您可以在实例上执行两种类型的引导操作：

• • 运行时：运行时操作会在instance.json或job-flow.json文件中找到与实例特定相关的值时执行操作。这是一个预定义的引导操作，当您只希望在特定类型的实例上执行该操作时非常有用，例如，仅当实例类型为master时才执行引导操作。

  • 自定义操作：自定义操作利用您自己的脚本来执行定制的引导操作。

1. 要创建引导操作，从“添加引导操作”中选择“配置并添加”选项。确保在继续之前选择了“运行时”操作。

2. 这将弹出“添加引导操作”对话框，如下图所示。为您的运行时操作输入一个合适的名称。由于运行时操作是预定义的引导操作，因此脚本的位置不是可编辑字段。然而，您可以为脚本添加可选参数，如下所示。在此案例中，只有当实例是主节点时，运行时操作才会回显消息：

1. 完成后点击“添加”。类似地，您也可以通过将可执行脚本放置在我们在本章前置阶段创建的 Amazon S3 存储桶中，并提供该路径来添加自定义引导操作。

2. 进入集群创建过程的最后一步，在安全选项页面，你可以审查集群部署后将使用的各种权限、角色、身份验证和加密设置。从本章开始时创建的 EC2 密钥对开始。你还可以选择更改权限或使用默认提供的权限。

3. 完成后，点击 Create cluster 来完成过程。

集群的创建需要几分钟时间，具体取决于为集群选择的实例数量，以及要安装的软件。一旦完成，你可以使用 EMR 仪表板查看集群的健康状态和其他重要信息。

连接到你的 EMR 集群

一旦你已经配置好 EMR 集群，你应该能看到其状态从 Starting 变为 Bootstrapping，最终变为 Running。如果当前没有正在执行的任务，你的集群可能还会进入 Waiting 状态。此时，你可以开始使用 EMR 集群来运行各种任务和分析。但在此之前，以下是几种连接到正在运行的 EMR 集群的方法的简要介绍。

首先，通过简单的 SSH 连接到主节点。通过 SSH 连接到主节点可以用于监控集群、查看 Hadoop 的日志文件，甚至运行 Hive 或 Pig 编程的交互式 Shell：

1. 要做到这一点，请登录到你的 Amazon EMR 仪表板并从集群列表页面选择你新创建的集群名称。这将显示集群的详情页面，你可以在此管理和监控集群。

2. 接下来，复制主节点的公共 DNS 地址。复制后，打开 PuTTY 终端并将复制的公共 DNS 粘贴到主机名（或 IP 地址）字段中。

3. 将你与该 EMR 集群关联的密钥对转换为私钥，并通过在 SSH 部分选择 Auth 选项，将该私钥附加到 PuTTY 中。

4. 完成后，点击 Open 以建立连接。在证书对话框中，接受证书并在提示时输入 Hadoop 作为用户名。你应该能够获得对集群主节点的 SSH 访问权限！

同样的操作也可以通过 AWS CLI 执行：

1. 从终端中，首先输入以下命令来获取正在运行的集群 ID。集群 ID 将是 j-XXXXXXXX 这种格式：

# aws emr list-clusters 

1. 要列出在集群中运行的实例，可以使用从上一条命令输出中获取的集群 ID，执行以下命令：

# aws emr list-instances --cluster-id <CLUSTER_ID>

从此命令的输出中复制 PublicDnsName 值。然后，你可以使用以下命令集来获取对主节点的访问权限。

1. 确保集群的私钥具有必要的权限：

# chmod 400 <PRIVATEKEY.pem>

1. 完成后，使用以下命令 SSH 连接到主节点：

# ssh hadoop@<PUBLIC_DNS_NAME> -i <PRIVATEKEY.pem>

你还可以通过一些简单的步骤连接到各种应用程序的 Web 界面，例如 Hue 或 Hadoop HDFS NameNode：

1. 开始之前，您再次需要获取主节点的公共 DNS 名称。您可以从 EMR 仪表板获取该名称，或使用我们刚才介绍的 CLI 步骤。

2. 接下来，使用 PuTTY，将公共 DNS 名称粘贴到“主机名（或 IP 地址）”字段中，如之前所做的那样。也使用“身份验证”选项浏览并加载私钥。

3. 在 PuTTY 的导航窗格中，选择 SSH 选项，并选择“隧道”。

4. 填写以下列表中提到的所需信息：

   • 将源端口字段设置为 8157

   • 启用动态和自动选项

5. 完成后，选择“添加”并最终点击“打开”连接。

这种隧道或端口转发方式非常关键，因为网页界面只能通过主节点的本地 Web 服务器进行查看。完成后，启动您喜欢的浏览器并查看相应的网页界面，如下所示：

• 要访问 Hue，请在您的网页浏览器中输入以下内容：

http://<PUBLIC_DNS_NAME>:8888/

• 要访问 Hadoop HDFS NameNode，请输入以下内容：

http:// <PUBLIC_DNS_NAME>::50070/

您甚至可以使用 CLI 来创建隧道。为此，请在以下命令中替换公共 DNS 名称和私钥值：

# ssh -i <PRIVATEKEY.pem> -N -D 8157 hadoop@<PUBLIC_DNS_NAME> 

-D 标志表示端口转发是动态的。

在集群上运行作业

在建立连接后，您现在可以在集群上作为一个或多个步骤执行作业。在本节中，我们将通过一个简单的示例演示步骤的工作流程，该示例涉及处理一些 Amazon CloudFront 日志。示例数据和脚本的详细信息可以在此找到：docs.aws.amazon.com/emr/latest/ManagementGuide/emr-gs-prepare-data-and-script.html。您也可以使用类似的技术和基础，创建并执行您自己的作业：

1. 要开始作业，请在 EMR 仪表板中从“集群列表”页面选择您的集群名称。这将打开新创建集群的详细信息页面。在此页面中，选择“步骤”标签。

2. 由于这是我们的第一个步骤，请继续点击“添加步骤”选项。这将弹出“添加步骤”对话框，如下图所示。根据描述填写所需的信息，所有字段填写完毕后，点击“添加”以完成步骤创建：

• • 步骤类型：您可以选择各种选项，如流式程序，它会提示您提供 Mapper 和 Reducer 函数的详细信息，或者您也可以选择 Hive 程序、Pig 程序、Spark 程序或自定义应用程序。在此案例中，我们选择 Hive 程序选项。

  • 名称：为您的步骤选择一个合适的名称。

  • 脚本 S3 位置：在此提供 Hive 脚本的位置。由于我们使用的是预定义脚本，只需将 <REGION> 字段替换为您 EMR 所在的操作区域：s3://<REGION>.elasticmapreduce.samples/cloudfront/code/Hive_CloudFront.q。

  • 输入 S3 位置：在此处提供输入数据文件的位置。将 <REGION> 占位符替换为你 EMR 的操作区域，如之前所做的那样：s3://<REGION>.elasticmapreduce.samples。

  • 输出 S3 位置：指定处理后的输出文件存储位置。在这种情况下，我使用的是我们在 EMR 集群创建过程中作为先决步骤创建的自定义 S3 存储桶。你也可以提供任何其他替代存储桶。

  • 参数：你可以使用此字段提供脚本运行所需的任何可选参数。在这种情况下，复制并粘贴以下内容：-hiveconf hive.support.sql11.reserved.keywords=false。

  • 失败时的操作：你可以选择在步骤执行失败时 EMR 应该采取的措施。在这种情况下，我们选择了默认的 Continue 值。

1. 填写所需字段后，点击 Add 完成此过程。

该步骤现在开始在 EMR 集群上执行提供的脚本。你可以通过查看步骤状态从 Pending 到 Running 再到 Completed 的变化，来查看进度，如下图所示：

一旦作业完成执行，返回到 Amazon S3 的输出存储桶并查看处理结果。在这种情况下，输出包含对 CloudFront 发出的访问请求的数量，并按操作系统进行排序。

监控 EMR 集群

EMR 仪表板提供了丰富的功能集，借此你可以在一个地方管理和监控 EMR 集群。你还可以查看日志，并利用 Amazon CloudWatch 跟踪集群的性能。

本节将介绍几种简单的方法，帮助你监控 EMR 集群。首先，让我们看看如何通过 EMR 仪表板来监控集群的状态：

1. 在 EMR 仪表板中，从集群列表页面选择你的集群名称。这将打开新创建的集群的详情页面。在这里，选择 Events 标签，如下图所示：

Events 标签允许你查看集群记录的事件。你可以使用此功能查看由集群、运行的应用程序、步骤执行等生成的事件。

1. 仪表板还提供了关于集群在一段时间内性能的深入分析。要查看性能指标，请从集群详情页面选择 Monitoring 标签。

在这里，你可以查看有关集群的基本信息和状态，包括运行中的节点，以及底层的 I/O 和数据存储。

1. 或者，你也可以使用 Amazon CloudWatch 来查看和监控集群的各种指标。为此，通过选择以下 URL 启动 Amazon CloudWatch 仪表板：console.aws.amazon.com/cloudwatch/home。

2. 接下来，在导航面板中选择“Metrics”选项以查看与 EMR 相关的所有指标。如果您在同一环境中运行多个集群，可以使用JobFlowID维度来过滤 EMR 集群。

以下是一些值得监控的重要 EMR 指标列表：

指标名称	指标描述
AppsFailed	提交到 EMR 集群的应用程序中未能完成的数量。此应用程序状态由 YARN 内部监控并报告。
MRUnhealthyNodes	标记为UNHEALTHY状态的可用于 MapReduce 作业的节点数量。
MRLostNodes	被标记为LOST状态的 MapReduce 分配的节点数量。
CorruptBlocks	HDFS 报告为损坏的块数量。

您可以在以下链接查看监控的所有指标列表：docs.aws.amazon.com/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html。

1. 一旦确定了某个指标，选择该指标并点击“Graphed metrics”标签页。在这里，选择“Create alarm”选项，在“Actions”栏下创建并设置报警阈值及其对应的动作。

通过这种方式，您还可以利用 Amazon CloudWatch 事件定期监控集群生成的事件。然而，请记住，EMR 只会追踪并记录七天内的事件。至此，我们已经结束了这一部分内容，接下来将介绍另一项非常棒的分析服务——Amazon Redshift！

介绍 Amazon Redshift

Amazon Redshift 是 AWS 提供的数据库即服务（DBaaS）之一，它以显著更低的成本提供可大规模扩展的数据仓库作为托管服务。该数据仓库基于开源 PostgreSQL 数据库技术，但并非所有在 PostgreSQL 中提供的功能都能在 Amazon Redshift 中找到。以下是使用 Amazon Redshift 时需要牢记的一些基本概念和术语：

• 集群：与 Amazon EMR 类似，Amazon Redshift 也依赖于集群的概念。集群是包含一个或多个实例或计算节点以及一个负责集群整体管理的 Leader 节点的逻辑容器。以下是每个节点提供的简要说明：

  • Leader 节点：Leader 节点是集群中唯一的节点，负责协调和执行各种数据库操作，并促进数据库与关联客户端程序之间的通信。

  • 计算节点：计算节点负责执行由主节点提供的代码。执行完毕后，计算节点将结果返回给主节点进行汇总。Amazon Redshift 支持两种类型的计算节点：密集存储节点和密集计算节点。密集存储节点提供标准的硬盘驱动器，用于创建大型数据仓库；而密集计算节点提供更高性能的 SSD。您可以首先使用一个提供 160 GB 存储的单节点，并通过利用一个或多个 16 TB 容量实例来扩展至 PB 级别。

• 节点切片：每个计算节点根据集群的初始大小，被主节点划分为一个或多个更小的块或切片。每个切片包含一部分计算节点的内存、CPU 和磁盘资源，并利用这些资源处理分配给它的特定工作负载。工作负载的分配同样由主节点执行。

• 数据库：如前所述，Amazon Redshift 提供了一个可扩展的数据库，您可以利用它来进行数据仓库和分析用途。每个在 Redshift 中启动的集群，您都可以创建一个或多个关联的数据库。该数据库基于开源关系数据库 PostgreSQL（v8.0.2），因此可以与其他 RDBMS 工具和功能结合使用。应用程序和客户端可以通过标准的 PostgreSQL JDBC 和 ODBC 驱动与数据库进行通信。

这里是一个由 Amazon Redshift 提供支持的、工作中的数据仓库集群的示意图：

在了解了这些基本信息后，接下来让我们看看一些简单易行的步骤，您可以通过这些步骤设置并启动您的 Amazon Redshift 集群。

开始使用 Amazon Redshift

在本节中，我们将介绍几个简单的步骤，通过这些步骤，您可以在几分钟内启动并运行一个完整的 Amazon Redshift 集群：

1. 首先，我们有几个前提步骤需要在开始实际设置 Redshift 集群之前完成。从 AWS 管理控制台中，使用过滤选项筛选出 IAM。或者，您也可以通过选择此 URL 启动 IAM 仪表盘：console.aws.amazon.com/iam/。

2. 登录后，我们需要创建并分配一个角色，使我们的 Redshift 集群能够获得对 Amazon S3 存储桶的只读访问权限。这个角色将在本章后面加载一些示例数据到 Amazon S3 存储桶，并使用 Amazon Redshift 的 COPY 命令将数据复制到 Redshift 集群中进行处理时派上用场。要创建自定义角色，请从 IAM 仪表盘的导航面板中选择角色（Role）选项。

3. 在角色（Roles）页面，选择创建角色（Create role）选项。这将弹出一个简单的向导，我们将使用它创建并关联所需的权限到我们的角色。

4. 在 AWS 服务组部分，选择 Redshift 选项，并在“选择您的用例”字段下选择 Redshift - 可自定义选项。点击下一步以继续设置。

5. 在“附加权限策略”页面，筛选并选择 AmazonS3ReadOnlyAccess 权限。完成后，选择下一步：审查。

6. 在最终的审查页面，输入一个合适的角色名称，并选择“创建角色”选项以完成该过程。请记下角色的 ARN，因为后续步骤中将需要使用它。以下是角色策略的片段供参考：

{ 
  "Version": "2012-10-17", 
  "Statement": [ 
    { 
      "Effect": "Allow", 
      "Action": [ 
        "s3:Get*", 
        "s3:List*" 
      ], 
      "Resource": "*" 
    } 
  ] 
} 

创建角色后，我们可以继续创建 Redshift 集群。

1. 为此，登录到 AWS 管理控制台，并使用筛选选项筛选出 Amazon Redshift。或者，您也可以通过选择以下 URL 启动 Redshift 仪表板：console.aws.amazon.com/redshift/。

2. 选择启动集群以开始该过程。

3. 接下来，在“集群详情”页面，填写与您的集群相关的必要信息，如下所述：

   • 集群标识符：为您的新 Redshift 集群指定一个合适的名称。请注意，此名称仅支持小写字母。

   • 数据库名称：为您的 Redshift 数据库指定一个合适的名称。您可以在以后阶段随时在一个 Redshift 集群内创建更多数据库。如果未提供值，则会默认创建一个名为dev的数据库：

• • 数据库端口：数据库接受连接的端口号。默认情况下，值设置为5439，但是您可以根据安全需求更改此值。

  • 主用户名：为访问数据库提供一个合适的用户名。

  • 主用户密码：输入一个强密码，至少包含一个大写字母、一个小写字母和一个数字值。在确认密码字段中重新输入密码以确认。

1. 完成后，点击继续以进入向导的下一步。

2. 在“节点配置”页面，选择适合您集群的节点类型，以及根据功能需求选择集群类型。由于这个集群设置用于演示目的，我选择了 dc2.large 作为节点类型，并选择了一个单节点部署，包含1个计算节点。完成后点击继续进入下一页面。

这里需要特别注意的是，您即将启动的集群将是实时集群，而不是在类似沙盒的环境中运行。因此，您将按标准的 Amazon Redshift 使用费用计费，直到您删除该集群。您可以阅读更多关于 Redshift 定价的信息：aws.amazon.com/redshift/pricing/。

1. 在“附加配置”页面，你可以配置附加设置，如启用加密、为集群选择默认 VPC、是否允许集群直接访问互联网，以及选择特定的可用区供集群运行。大多数这些设置目前无需更改，可以保留默认值。

2. 本页面所需的唯一更改是将之前创建的 IAM 角色与集群关联。为此，从可用角色下拉列表中选择我们在先决条件部分创建的自定义 Redshift 角色。完成后，点击“继续”。

3. 在“审查”页面查看设置和更改，完成后选择“启动集群”选项。

集群的启动可能需要几分钟，具体取决于你选择的是单实例部署还是多实例部署。启动完成后，你应该能在“集群”页面看到你的集群，正如下图所示。确保你的集群在“数据库健康”列中显示为健康状态。你还可以记下集群的端点，方便后续通过编程方式访问：

在集群设置完成后，接下来要做的就是连接到它。在接下来的章节中，我们将介绍一些简单的步骤，帮助你连接到新部署的 Redshift 集群。

连接到你的 Redshift 集群

一旦集群启动并运行，你可以使用多种工具连接到它。大多数这些工具都符合 PostgreSQL 标准，并且可以轻松购买到。在本例中，我们将安装并使用一个开源的 SQL 客户端工具，叫做SQL Workbench/J。

首先，你需要在本地工作站安装 Java 运行时环境。Java 运行时版本必须与 SQL Workbench/J 的要求匹配，否则它将无法正常工作。如果你正在使用 Linux 操作系统，可以通过在终端输入以下命令来检查本地桌面上已安装的 Java 运行时版本，或者通过在控制面板中查找 Java 配置来查看版本：

# java --version

在这种情况下，我们使用的是一台普通的 Windows 桌面来安装 SQL Workbench/J。从这里下载正确版本的软件：www.sql-workbench.net/downloads.html。

软件下载完成后，安装过程相当简单。接受最终用户许可协议，选择软件安装路径，完成即可！此时，SQL Workbench/J 应该已成功安装并运行：

1. 要将 SQL Workbench/J 连接到你的 Redshift 集群，你需要新创建的数据库的 JDBC URL。你可以通过选择 Redshift 导航窗格中的“连接客户端”选项，并从“获取集群连接 URL”部分选择你刚部署的集群来复制该 URL，如下图所示：

1. 你还需要从相同页面下载正确版本的 Amazon Redshift JDBC 驱动程序 JAR。

2. 完成后，从 SQL Workbench/J 客户端中选择“文件”，然后选择“连接窗口”选项。

3. 在这里，点击“创建新连接配置文件”以开始操作。这将弹出一个“新建配置文件”框，您需要为此新配置文件输入名称。

4. 创建配置文件后，选择“管理驱动程序”选项。这将显示“管理驱动程序”对话框，如下截图所示。选择“Amazon Redshift”选项，并为你的连接驱动程序提供一个合适的名称。点击浏览图标并选择我们从 Redshift 下载的 Amazon Redshift 驱动程序 JAR 文件。点击确定以完成驱动程序设置：

1. 配置好驱动程序后，最后要做的就是连接到数据库并进行测试。为此，选择 SQL Workbench/J 中新创建的连接配置文件，并将复制的数据库 JDBC URL 粘贴到 URL 字段中，如所示。提供数据库的用户名和密码，密码是集群设置过程中配置的。同时，确保选中“自动提交”选项，如图所示：

1. 你还可以通过在 SQL Workbench/J 屏幕上选择“测试”选项来测试连接。完成后，点击确定以建立连接并打开 SQL 提示符。

完成这一步后，你应该已经将正在运行的 Redshift 集群连接到 SQL Workbench/J 客户端。接下来的最后一步是执行一些示例查询并测试集群的功能，快开始吧！

使用 Redshift 数据库和表

在开始查询 Redshift 数据库之前，我们首先需要将一些数据上传到它。对于这个特定的场景，我们将使用一小部分来自佛罗里达州 NASA 肯尼迪航天中心的 HTTP 请求日志。这些数据可以公开使用，并可以从这里下载：ita.ee.lbl.gov/html/contrib/NASA-HTTP.html。

日志文件基本包含以下列集：

• 主机：向 web 服务器发出 web 请求的主机。此字段还包含完全限定的主机名或 IP 地址。

• 时间戳：特定 web 请求的时间戳。格式为 DAY MON DD HH:MM:SS YYYY。此时间戳使用 24 小时制。

• 请求：用于请求服务器的方法（GET/HEAD/POST）。

• URL：客户端请求的资源 URL。

• 响应：包含 HTTP 响应代码（200、302、304 和 404）。

• 字节数：回复的字节大小。

以下是数据片段供你参考：

pppa006.compuserve.com,807256800,GET,/images/launch-logo.gif,200,1713 
vcc7.langara.bc.ca,807256804,GET,/shuttle/missions/missions.html,200,8677 
pppa006.compuserve.com,807256806,GET,/history/apollo/images/apollo-logo1.gif,200,1173 

你可以通过以下链接下载本场景使用的示例 CSV 文件（2.14 MB，包含 30,970 条记录）：

github.com/yoyoclouds/Administering-AWS-Volume2.

下载文件后，你只需将其上传到你的其中一个 Amazon S3 存储桶。记住，该存储桶应该能够被 Amazon Redshift 访问，否则你可能会在执行过程中遇到 S3ServiceException: Access Denied 异常。

接下来，从 SQL Workbench/J 客户端输入以下代码，以在我们的 Redshift 数据库中创建新表：

create table apachelogs( 
host varchar(100), 
time varchar(20), 
method varchar(8), 
url varchar(200), 
response varchar(10), 
bytes varchar(10)); 

你可以在以下链接找到前面代码的完整副本：github.com/yoyoclouds/Administering-AWS-Volume2。

选择“执行查询”按钮。你应该会收到一个输出，显示表格已创建，如下截图所示：

接下来，使用 COPY 命令将存储在 Amazon S3 中的数据文件内容加载到新创建的 Redshift 表中。COPY 命令是一个非常灵活的命令，可以用于从 Amazon S3、Amazon EMR，甚至是 Amazon DynamoDB 表加载数据到 Amazon Redshift。要了解更多关于 COPY 命令的信息，请访问此 URL：docs.aws.amazon.com/redshift/latest/dg/r_COPY.html。

用新创建的表名替换 <REDSHIFT_TABLE_NAME> 的值，用包含数据文件的 S3 存储桶名称替换 <BUCKET_NAME>，并用我们在 Amazon Redshift 先决条件过程中创建的 IAM 只读访问角色 ARN 替换 <REDSHIFT_IAM_ROLE_ARN>：

copy <REDSHIFT_TABLE_NAME> from 's3://<BUCKET_NAME>/data.csv'  
credentials 'aws_iam_role=<REDSHIFT_IAM_ROLE_ARN>'  
csv; 

一旦代码粘贴到 SQL Workbench/J 中，点击“执行查询”按钮。以下是来自 SQL Workbench/J 的命令执行快照：

数据加载完成后，你可以使用简单的查询来查询数据集，如本节所述。以下命令将列出表中的所有 30,970 条记录：

select * from apachelogs;

以下命令将只列出那些响应值为 404 的记录：

select * from apachelogs where response=404; 

以下命令将列出所有请求了特定资源的主机：

select host from apachelogs where url='/images/NASA-logosmall.gif'; 

你还可以使用 Redshift 仪表板来查看每个单独查询的性能和运行时，首先在集群页面选择你的 Redshift 集群名称。接下来，选择“查询”标签，列出最近执行的查询，如下图所示：

你也可以通过进一步选择 查询标识符 来深入查看每个查询。

规划你的下一步

在我们通过总结本章来结束之前，我强烈建议你尝试一些与 Amazon EMR 和 Amazon Redshift 相关的功能。首先是 EMRFS。

在决定选择哪种文件系统来部署 EMR 集群时，我们简要介绍了 EMRFS 主题。EMR 文件系统（EMRFS）是传统 HDFS 的一种实现，它允许从 Amazon EMR 直接读取和写入 Amazon S3 中的文件。这本质上让你能够利用 S3 提供的一致性以及其其他一些功能，如数据加密。要了解更多关于 EMRFS 以及如何在 EMR 集群中使用它的信息，请访问：docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html。

其次，Amazon EMR 还提供了以 MapR 形式提供的企业级 Hadoop 发行版。MapR 发行版的 Hadoop 为你提供了丰富的功能，增强了你在构建分布式应用程序以及管理整个 Hadoop 集群时的整体体验。例如，选择 MapR 作为 Hadoop 发行版提供对行业标准接口（如 NFS 和 ODBC）的支持，通过这些接口，你可以将 EMR 集群与任何主要的 BI 工具（包括 Tableau 和 Toad）连接。MapR 还提供内建的高可用性、数据保护、更高的性能和一系列额外功能。你可以在以下链接中了解更多关于 EMR 中 MapR 发行版的内容：docs.aws.amazon.com/emr/latest/ManagementGuide/emr-mapr.html。

最后但同样重要的是，我还推荐你尝试使用 Amazon Redshift 的一些高级功能，如保留节点和参数组。参数组本质上是一组在数据库创建时应用的参数。你可以通过从 Redshift 的导航面板中选择“参数组”选项来查找你现有数据库的参数组。你可以根据需求使用并调整这些参数组，以便微调和定制数据库。要了解如何利用参数组进行数据库调优，请访问：docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html。

总结

好的，这就带我们走到了又一章的结束。让我们快速总结一下目前为止学到的内容！

一开始，我们通过学习 AWS 为大数据分析提供的各种服务，随后快速浏览了 Amazon EMR 的入门指南。我们了解了一些 Amazon EMR 的概念，并启动了我们的第一个 EMR 集群。我们还在 EMR 集群上运行了第一个简单作业，并学会了如何使用 Amazon CloudWatch 等工具监控其性能。

在本章的末尾，我们了解了 Amazon Redshift 及其核心概念和工作原理。我们还创建了我们的第一个 Redshift 集群，使用开源客户端连接并运行了几条 SQL 查询。

在下一章，我们将学习和探索另一个旨在进行数据协调的 AWS 服务，敬请期待，我们还有很多内容要学习！

第十章：使用 AWS Data Pipeline 编排数据

在上一章中，我们深入探讨了 AWS 分析套件服务，详细了解了 Amazon EMR 和 Amazon Redshift 服务。

在本章中，我们将继续学习一个极其灵活且强大的数据编排和转换服务——AWS Data Pipeline。

让我们快速了解一下本章将涵盖的各个主题：

• 介绍 AWS Data Pipeline，并快速了解其一些概念和术语

• 使用简单的 Hello World 示例开始使用 Data Pipeline

• 使用 Data Pipeline 定义文件

• 使用数据管道在远程 EC2 实例上执行脚本和命令

• 使用简单的参数化数据管道将数据从一个 S3 桶备份到另一个

• 使用 AWS CLI 构建管道

那么，废话不多说，我们马上开始吧！

介绍 AWS Data Pipeline

AWS Data Pipeline 是一个极为灵活的 Web 服务，允许您在各种 AWS 服务和本地数据源之间双向传输数据。该服务专为提供内建的容错性和高可用性平台而设计，您可以利用它来定义并构建您自己的定制数据迁移工作流。AWS Data Pipeline 还提供了附加功能，如调度、依赖关系追踪和错误处理，使您无需花费额外的时间和精力自行编写这些功能。这个易于使用且灵活的服务，结合其低运营成本，使 AWS Data Pipeline 成为以下使用场景的理想选择：

• 定期将数据从 Amazon EMR 集群迁移到 Amazon Redshift 进行数据仓储

• 将存储在 Amazon S3 中的文件增量加载到 Amazon RDS 数据库中

• 将数据从 Amazon MySQL 数据库复制到 Amazon Redshift 集群

• 将数据从 Amazon DynamoDB 表备份到 Amazon S3

• 定期备份存储在 Amazon S3 桶中的文件，等等

在本节中，我们将通过先了解一些 AWS Data Pipeline 的内部组件、概念和术语，来进一步理解和学习 AWS Data Pipeline。

AWS Data Pipeline 的核心基础，如其名所示，就是一个管道。您可以创建管道来安排和执行数据迁移或转换任务。每个管道依赖于一个管道定义，该定义本质上包含了驱动数据迁移活动所需的业务逻辑。我们将在接下来的章节中深入学习管道定义。现在，让我们先来了解一些基本的管道概念和组件：

• 管道组件：单个管道可以包含多个部分，每个部分在整个管道的运行中都有其特定的位置。例如，管道可以包含指定输入数据源的部分，用于收集数据、在数据上执行的活动以及一些必要的条件、活动触发的时间等等。这些部分每个单独被称为管道的组件，并一起使用来构建管道定义。

• 任务执行器：任务执行器是执行管道中分配任务的特殊应用程序或代理。任务执行器轮询 AWS Data Pipeline，查看是否有可用的活动任务。如果发现，任务会分配给任务执行器并执行。一旦执行完成，任务执行器会将状态（成功或失败）报告回 AWS Data Pipeline。默认情况下，AWS 为通过 AWS Data Pipeline 启动和管理的资源提供了一个默认的任务执行器。您还可以在自己管理的实例或本地服务器上安装任务执行器：

• 数据节点：数据节点用于定义管道的输入和输出数据的位置及类型。目前，AWS Data Pipeline 提供了以下数据节点：

  • S3DataNode：用于将 Amazon S3 位置定义为存储数据的输入或输出

  • SqlDataNode：定义 SQL 表或数据库查询供管道使用

  • RedshiftDataNode：用于将 Amazon Redshift 表定义为管道的输入或输出

  • DynamoDBDataNode：用于指定 DynamoDB 表作为管道的输入或输出

• 活动：通过使用数据节点选择数据的位置和类型，接下来需要定义的是在该数据上执行的活动类型。AWS Data Pipeline 提供了一组预包装的活动，您可以根据需要使用并扩展：

  • CopyActivity：用于将数据从一个数据节点复制到另一个数据节点

  • ShellCommandActivity：用于将 Shell 命令作为活动执行

  • SqlActivity：在如SqlDataNode或RedhsiftDataNode等数据节点上执行 SQL 查询

  • RedshiftCopyActivity：一种特定的活动，利用 COPY 命令在 Redshift 表之间复制数据

  • EmrActivity：用于运行 EMR 集群

  • PigActivity：用于在 EMR 集群上运行自定义 Pig 脚本

  • HiveActivity：在 EMR 集群上运行 Hive 查询

  • HiveCopyActivity：用于运行 Hive COPY 查询，将数据从 EMR 集群复制到 Amazon S3 桶或 Amazon DynamoDB 表

• 资源：选择数据节点和活动之后，配置管道的下一步是选择适当的资源来执行活动。AWS Data Pipeline 支持两种类型的资源：

  • Ec2Resource：EC2 实例用于执行管道中选定的活动。此资源类型常用于诸如CopyActivity、ShellCommandActivity等活动。

  • EmrCluster：Amazon EMR 集群用于执行管道中选定的活动。此资源最适用于诸如EmrActivity、PigActivity、HiveActivity等活动。

• 操作：操作是在管道中，当发生成功、失败或延迟活动事件时，管道采取的某些步骤。您可以使用操作作为监控和通知管道执行状态的一种方式；例如，在CopyActivity失败时发送 SNS 通知等。

完成了这些概念和术语后，接下来让我们进行一些实际操作，创建我们第一个简单且简洁的管道。

开始使用 AWS Data Pipeline

创建您自己的管道是一个相对简单的过程，一旦您了解了与管道仪表板互动的复杂性。在本节中，我们将探索 AWS 数据管道仪表板、它的各种功能和编辑器，以创建一个简单的“Hello World”示例管道。首先，以下是您需要首先完成的几个必要的先决步骤，从创建一个简单的 Amazon S3 存储桶来存储我们所有的数据管道日志开始。

AWS Data Pipeline 仅在 EU（爱尔兰）、亚太地区（悉尼）、亚太地区（东京）、美国东部（北弗吉尼亚）和美国西部（俄勒冈）区域提供。为了本章中的情景，我们只使用美国东部（北弗吉尼亚）区域。

从 AWS 管理控制台，您可以通过从“筛选”选项中筛选服务名称，或直接访问以下 URL 来启动 Amazon S3 控制台：s3.console.aws.amazon.com/s3/home?region=us-east-1。

接下来，选择“创建存储桶”选项，并在“存储桶名称”字段中提供一个合适的值。将其他字段保持默认值，然后选择“创建”以完成该过程。

创建好日志存储桶后，接下来的先决步骤是创建几个 AWS Data Pipeline 所需的 IAM 角色，以便访问资源，以及它可以对这些资源执行的具体操作。由于我们将使用 AWS Data Pipeline 控制台来构建我们的第一个管道，Data Pipeline 提供了两个默认的 IAM 角色，您可以直接使用：

• DataPipelineDefaultRole：一个 IAM 角色，授予 AWS Data Pipeline 访问所有 AWS 资源的权限，包括 EC2、IAM、Redshift、S3、SNS、SQS 和 EMR。您可以自定义该角色以限制 Data Pipeline 可以访问的 AWS 服务。以下是创建的策略片段：

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "cloudwatch:*", 
                "datapipeline:DescribeObjects", 
                "datapipeline:EvaluateExpression", 
                "dynamodb:BatchGetItem", 
                "dynamodb:DescribeTable", 
                "dynamodb:GetItem", 
                ... 
                "ec2:RunInstances", 
                "ec2:StartInstances", 
                "ec2:StopInstances", 
                ... 
                "elasticmapreduce:*", 
                "iam:GetInstanceProfile", 
                "iam:GetRole", 
                "iam:GetRolePolicy", 
                ...   
                "rds:DescribeDBInstances", 
                "rds:DescribeDBSecurityGroups", 
                "redshift:DescribeClusters", 
                "redshift:DescribeClusterSecurityGroups", 
                "s3:CreateBucket", 
                "s3:DeleteObject", 
                "s3:Get*", 
                "s3:List*", 
                "s3:Put*", 
                ... 
                "sns:ListTopics", 
                "sns:Publish", 
                "sns:Subscribe", 
                ... 
                "sqs:GetQueue*", 
                "sqs:PurgeQueue", 
                "sqs:ReceiveMessage" 
            ], 
            "Resource": [ 
                "*" 
            ] 
        }, 
        { 
            "Effect": "Allow", 
            "Action": "iam:CreateServiceLinkedRole", 
            "Resource": "*", 
            "Condition": { 
                "StringLike": { 
                    "iam:AWSServiceName": [ 
                        "elasticmapreduce.amazonaws.com", 
                        "spot.amazonaws.com" 
                    ] 
                } 
            } 
        } 
    ] 
}

• DataPipelineDefaultResourceRole：此角色允许在数据管道资源（EC2/EMR 实例）上执行的应用程序、脚本或代码访问您的 AWS 资源：

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "cloudwatch:*", 
                "datapipeline:*", 
                "dynamodb:*", 
                "ec2:Describe*", 
                "elasticmapreduce:AddJobFlowSteps", 
                "elasticmapreduce:Describe*", 
                "elasticmapreduce:ListInstance*", 
                "elasticmapreduce:ModifyInstanceGroups", 
                "rds:Describe*", 
                "redshift:DescribeClusters", 
                "redshift:DescribeClusterSecurityGroups", 
                "s3:*", 
                "sdb:*", 
                "sns:*", 
                "sqs:*" 
            ], 
            "Resource": [ 
                "*" 
            ] 
        } 
    ] 
} 

完成前提条件后，现在让我们开始创建我们的第一个管道：

1. 从 AWS 管理控制台中，使用“筛选”选项过滤出数据管道，或者直接选择此处提供的 URL console.aws.amazon.com/datapipeline/home?region=us-east-1。选择“立即开始”选项。

2. 这将弹出显示创建管道向导。首先，使用“名称”字段提供管道的合适名称，然后可选地填写描述。

3. 接着，从源字段中选择“使用架构师构建”选项。

AWS 数据管道提供了多种创建管道的方法。你可以使用“通过模板构建”选项利用多个预构建的模板，或者选择更定制化的方式，选择“导入定义”选项，在此可以创建并上传自己的数据管道定义。最后，你可以使用数据管道架构师模式，通过一个简单直观的仪表板拖放并定制你的管道，这也是我们在此用例中要做的：

1. 接下来，你还可以通过选择调度部分提供的正确选项来安排管道的运行。目前，选择“管道激活时运行”选项，因为我们希望管道仅在首次激活时才开始执行。

2. 接下来，浏览并选择正确的S3 桶，通过“S3 日志位置”选项来记录数据管道的日志。此桶应该与在本场景的前提部分中创建的桶相同。

3. 可选地，你也可以通过在安全/访问部分选择提供的自定义选项，为数据管道提供自定义 IAM 角色。在这种情况下，我们已经选择了默认的 IAM 角色。

4. 一旦填充了所有必需的字段，选择“在架构师中编辑”选项继续。

完成此步骤后，你应该能看到当前管道的架构师视图。如图所示，默认情况下，你将只看到一个名为“配置”的框。

1. 选择配置框以查看管道运行所需的各种配置选项。此信息应在右侧导航窗格的“其他”部分中可见，如下图所示：

你可以使用此配置来编辑管道的资源角色、管道日志 URI、调度类型以及其他设置。

1. 要将资源和活动添加到管道中，选择所示的添加下拉列表。在此，选择ShellCommandActivity开始。我们将使用此活动来回显一个简单的“Hello World”消息作为开始。

2. 一旦选择了ShellCommandActivity选项，你应该能够在相邻的导航窗格的“活动”选项卡下看到相应的配置项。

3. 输入适当的活动名称。接下来，从类型部分，选择“添加可选字段”下拉列表，并选择“命令”选项，如图所示。在新的命令字段中，输入echo "This is just a Hello World message!"。

4. 配置活动后，最后一步是为流水线提供并关联资源。该资源将在 EC2 实例或 EMR 实例上执行ShellCommandActivity。

5. 要创建和关联资源，从“活动”部分再次选择“添加可选字段”选项，并从下拉列表中选择“运行于”选项。使用“运行于”选项，您可以为流水线执行任务创建和选择资源。

6. 选择“创建新的：资源”选项以开始。这将创建一个名为DefaultResource1的新资源，如下图所示：

1. 选择新创建的资源，或者从导航窗格中选择“资源”选项以查看并添加特定于资源的配置。

2. 在流水线的“资源”部分填写以下信息，如之前截屏所示：

   • 名称：为您的新资源提供一个合适的名称。

   • 类型：从下拉列表中选择Ec2Resource选项。

   • 角色/资源角色：您可以选择不同的 IAM 角色，但我选择了默认的流水线角色。

   • 实例类型：在相邻字段中键入t1.micro。如果未提供或选择实例类型字段，则资源将默认启动m1.medium实例。

   • 终止后：选择适当的时间，在这种情况下，我选择在10分钟后终止。

这是最终流水线填写“资源”部分后的屏幕截图：

1. 一旦流水线准备就绪，点击“保存”保存所做的更改。选择“保存”选项将自动编译您的流水线并检查任何错误。如果发现任何错误，它们将显示在“错误/警告”部分。如果没有报告错误，请点击“激活”最终激活您的流水线。

流水线需要几分钟来从“等待运行程序”状态转换为“完成”状态。这个过程首先涉及启动我们在流水线中定义的 EC2 实例或资源。一旦资源启动并运行，数据管道将自动在这个特定资源上安装任务运行器，因为数据管道本身管理它。安装了任务运行器后，它开始轮询数据管道以执行挂起的活动。

当流水线状态变为“完成”时，展开流水线组件名称并选择“尝试”选项卡，如所示。如果未指定，数据管道将尝试在最终停止执行之前默认执行三次您的流水线。

对于每次尝试，你可以查看相应的活动日志、Stdout 以及 Stderr 消息：

选择 Stdout 选项查看你的 Hello World 消息！瞧！你的第一个管道已启动并运行！

随意尝试其他管道选项，只需选择管道名称并点击“编辑管道”选项。你还可以通过选择管道名称并在“操作”选项卡中选择“导出”选项来导出管道的定义。

如果你喜欢使用 JSON 和 CLI 接口，管道定义是一种比标准管道仪表板更好、更简单的创建管道方式。与可能需要时间适应的标准管道仪表板相比，它们提供了更好的灵活性和可用性。考虑到这一点，在接下来的部分中，我们将探讨一些基本内容，帮助你通过创建自己的管道定义文件入门。

使用数据管道定义文件

AWS Data Pipeline 控制台提供了三种不同的选项来开始创建新管道。你可以使用架构模式，这正是我们在前面部分使用的方式，或者选择任何一个预定义的模板作为样板，从中构建你的管道。最后但同样重要的是，控制台还允许你上传自己的管道定义文件，它基本上是一个由多个管道对象和条件组成的 JSON 格式文件。在本部分中，我们将学习如何编写自己的管道定义，并随后使用它们来构建自定义管道。

首先，你需要两个组件来构建管道定义文件：对象和字段：

• 对象：对象是构建管道所需的单个组件。这些可以是数据节点、条件、活动、资源、计划等。

• 字段：每个对象由一个或多个字段描述。字段由键值对组成，键值对用双引号括起来，并通过冒号分隔。

这是一个管道定义文件的基本结构：

{ 
  "objects" : [ 
    { 
       "key1" : "value1", 
       "key2" : "value2" 
    }, 
    { 
       "key3" : "value3" 
    } 
  ] 
} 

下面是我们之前执行的 Hello World 管道示例导出的管道定义文件：

{ 
  "objects": [ 
    { 
      "failureAndRerunMode": "CASCADE", 
      "resourceRole": "DataPipelineDefaultResourceRole", 
      "role": "DataPipelineDefaultRole", 
      "pipelineLogUri": "s3://us-east-datapipeline-logs-01/logs/", 
      "scheduleType": "ONDEMAND", 
      "name": "Default", 
      "id": "Default" 
    }, 
    { 
      "name": "myActivity", 
      "id": "ShellCommandActivityId_2viZe", 
      "runsOn": { 
        "ref": "ResourceId_EhxAF" 
      }, 
      "type": "ShellCommandActivity", 
      "command": "echo "This is just a Hello World message!"" 
    }, 
    { 
      "resourceRole": "DataPipelineDefaultResourceRole", 
      "role": "DataPipelineDefaultRole", 
      "name": "myEC2Resource", 
      "id": "ResourceId_EhxAF", 
      "type": "Ec2Resource", 
      "terminateAfter": "10 Minutes" 
    } 
  ], 
  "parameters": [] 
} 

你可以在github.com/yoyoclouds/Administering-AWS-Volume2找到完整的代码副本。

每个对象通常包含一个id、name和type字段，用于描述对象及其功能。例如，在 Hello World 场景中，Resource对象包含以下值：

{ 
      "name": "myEC2Resource", 
      "id": "ResourceId_EhxAF", 
      "type": "Ec2Resource", 
       ... 
} 

你还可以在ShellCommandActivity和默认配置对象中找到相同的字段。

一个管道对象可以使用"ref" : "ID_of_referred_resource"字段引用同一管道中的其他对象。以下是ShellCommandActivity引用 EC2 资源的示例，使用资源 ID：

{ 
      "name": "myActivity", 
      "id": "ShellCommandActivityId_2viZe", 
      "runsOn": { 
        "ref": "ResourceId_EhxAF" 
      }, 
      "type": "ShellCommandActivity", 
      "command": "echo "This is just a Hello World message!"" 
    }, 
    { 
      "resourceRole": "DataPipelineDefaultResourceRole", 
      "role": "DataPipelineDefaultRole", 
      "name": "myEC2Resource", 
      "id": "ResourceId_EhxAF", 
      "type": "Ec2Resource", 
      "terminateAfter": "10 Minutes" 
    } 

您还可以创建自定义或用户定义的字段，并使用与前面代码中描述的相同语法，将它们引用到其他管道组件中：

{ 
  "id": " ResourceId_EhxAF", 
  "type": "Ec2Resource", 
  "myCustomField": "This is a custom field.", 
  "myCustomReference": {"ref":" ShellCommandActivityId_2vi"} 
  }, 

您可以在docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-pipeline-objects.html找到有关数据节点、资源、活动和其他对象的详细参考资料。

最后但同样重要的是，您还可以利用参数化模板来定制管道定义。使用这种方法，您基本上可以拥有一个通用的管道定义，并在管道创建时向其传递不同的值。

要使管道定义参数化，您需要使用以下语法指定一个变量：

 "#{VARIABLE_NAME}"

创建变量后，您可以在单独的parameters对象中定义其值，该对象可以存储在相同的管道定义文件中，也可以完全存储在一个单独的 JSON 文件中。考虑以下示例，我们将相同的 Hello World 消息传递给ShellCommandActivity，不过这次使用了变量定义：

{ 
      "name": "myActivity", 
      "id": "ShellCommandActivityId_2viZe", 
      "runsOn": { 
        "ref": "ResourceId_EhxAF" 
      }, 
      "type": "ShellCommandActivity", 
      "command": "#{myVariable}" 
}

一旦变量定义完成，我们将其对应的值和表达式传递到单独的parameters对象中，如下代码所示：

{ 
  "parameters": [ 
    { 
      "id": "myVariable", 
      "description": "Shell command to run", 
      "type": "String", 
      "default": "echo "Default message!"" 
    } 
  ] 
} 

在这种情况下，变量myVariable是一个简单的字符串类型，并且我们还为其提供了一个默认值，以防在管道创建时未为此变量提供值。

要了解更多有关如何在管道定义中利用和使用变量及参数的信息，请访问docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-custom-templates.html。

到此，我们已经接近本节的结束。在下一节中，我们将探讨如何利用 AWS 数据管道，在使用参数化管道定义的情况下，在远程 EC2 实例上执行脚本和命令。

使用 AWS 数据管道执行远程命令

使用数据管道的一个最大优点是，您可以仅通过这个工具实现多种任务。在本节中，我们将介绍一个相对简单的管道定义，您可以通过它在 EC2 实例上执行远程脚本和命令。

这个设置是如何工作的呢？首先，我们需要创建一个 S3 桶（可以位于任何 AWS 区域），用于存储并作为所有 Shell 脚本的存储库。创建桶后，您只需创建并上传以下 Shell 脚本到该桶。请注意，在此案例中，Shell 脚本名为simplescript.sh，并且在以下管道定义中也使用了相同的名称：

#!/bin/bash 
echo "----------------------------------" 
echo "Your username is: $(echo $USER)" 
echo "----------------------------------" 
echo "The current date and time : $(date)" 
echo "----------------------------------" 
echo "Users currently logged on this system: " 
echo "$(who)" 
echo "----------------------------------" 
echo "AWS CLI installed at: " 
echo "$(aws --version)" 
echo "----------------------------------" 

这个脚本相当不言自明。它将基于启动它的 EC2 实例打印一系列消息。您可以用任何其他用于备份特定文件或将现有文件存档为tar.gz并推送到等待存档的 S3 存储桶的 Shell 脚本替换它，等等。

将脚本文件上传到正确的 S3 存储桶后，最后一步是复制并粘贴以下流水线定义到一个文件中，并上传到数据管道以执行：

{ 
  "objects": [ 
    { 
      "failureAndRerunMode": "CASCADE", 
      "resourceRole": "DataPipelineDefaultResourceRole", 
      "role": "DataPipelineDefaultRole", 
      "pipelineLogUri": "s3://<DATAPIPELINE_LOG_BUCKET>", 
      "scheduleType": "ONDEMAND", 
      "name": "Default", 
      "id": "Default" 
    }, 
    { 
      "name": "CliActivity", 
      "id": "CliActivity", 
      "runsOn": { 
        "ref": "Ec2Instance" 
      }, 
      "type": "ShellCommandActivity", 
      "command": "(sudo yum -y update aws-cli) && (#{myCustomScriptCmd})" 
    }, 
    { 
      "instanceType": "t1.micro", 
      "name": "Ec2Instance", 
      "id": "Ec2Instance", 
      "type": "Ec2Resource", 
      "terminateAfter": "15 Minutes" 
    } 
  ], 
  "parameters": [ 
    { 
      "watermark": "aws [options] <command> <subcommand> [parameters]", 
      "description": "AWS CLI command", 
      "id": "myCustomScriptCmd", 
      "type": "String" 
    } 
  ], 
  "values": { 
    "myCustomScriptCmd": "aws s3 cp s3://<S3_BUCKET_SCRIPT_LOCATION>/simplescript.sh . && sh simplescript.sh" 
  } 
} 

记得用对应的实际值替换<DATAPIPELINE_LOG_BUCKET>和<S3_BUCKET_SCRIPT_LOCATION>的值，并将文件保存为 JSON 扩展名。

此流水线定义依赖于ShellCommandActivity，首先在远程 EC2 实例上安装 AWS CLI，然后通过从 S3 存储桶本地复制执行 Shell 脚本。

要上传流水线定义，请使用 AWS 数据管道控制台创建新的流水线。在“创建流水线”向导中，为新流水线提供适当的名称和描述。完成后，从“源”字段中选择“导入定义”选项，如下截图所示：

一旦脚本加载完成，您应该在“参数”部分中看到自定义 AWS CLI 命令。成功加载流水线定义后，您现在可以选择在计划或激活时运行流水线。在我的情况下，我选择在激活时运行流水线，因为这是为演示目的而设。

确保为新流水线启用了日志记录，并提到正确的 S3 存储桶来存储流水线的日志。填写所有必要的字段后，点击“激活”以启动流水线。

流水线将再次从“等待运行者”状态转换为“已完成”状态。通常需要一两分钟才能完成。

从数据管道控制台扩展现有流水线，并选择“尝试”选项卡，如下截图所示。在此处，点击“标准输出”以查看脚本执行的输出：

查看输出后，您可以选择流水线，然后点击“标记为完成”选项。这将阻止流水线进一步尝试执行。

简单，不是吗！您可以使用类似的方法和途径来备份您的文件并在托管实例上执行一些命令。在下一部分中，我们还将查看最后一个流水线定义示例，该示例基本上帮助我们定期备份存储在一个 Amazon S3 存储桶中的内容到另一个存储桶，同时使用数据管道控制台和 AWS CLI！

使用 AWS 数据管道备份数据

AWS 数据管道最常见的应用场景之一是其同步和调度备份任务的能力。你可以使用数据管道备份存储在 EC2 实例、EBS 卷、数据库甚至 S3 存储桶中的数据。在本节中，我们将介绍一个简单的、带参数的管道定义，你可以使用它来有效地调度和执行存储在 Amazon S3 存储桶中的文件的备份。

首先，我们来看看管道定义文件本身：

你可以在 github.com/yoyoclouds/Administering-AWS-Volume2 找到完整的代码副本。

首先，我们再次提供一份描述管道组件的对象列表，从管道配置对象开始，如以下代码所示：

  "objects": [
    {
      "failureAndRerunMode": "CASCADE",
      "resourceRole": "DataPipelineDefaultResourceRole",
      "role": "DataPipelineDefaultRole",
      "pipelineLogUri": "#{myDataPipelineLogs}",
      "scheduleType": "ONDEMAND",
      "name": "Default",
      "id": "Default"
    },

接下来，我们提供其他管道对象的定义，包括数据节点：

    {
      "filePath": "#{myInputS3FilePath}",
      "name": "inputS3Bucket",
      "id": "InputS3FilePath",
      "type": "S3DataNode"
    },
    {
      "filePath": "#{myOutputS3FilePath}/#{format(@scheduledStartTime, 'YYYY-MM-dd-HH-mm-ss')}.bak",
      "name": "outputS3Bucket",
      "id": "OutputS3FilePath",
      "type": "S3DataNode"
    },

在这种情况下，我们使用 #{VARIABLE_NAMES} 来声明一组变量，使管道定义更加可重用。一旦数据节点配置完成，我们还需要定义一组操作，这些操作将在管道成功或失败时触发 SNS 通知。以下是相关的代码片段：

{
    "role": "DataPipelineDefaultRole",
    "subject": "Failure",
    "name": "SNSAlertonFailure",
    "id": "OnFailSNSAlert",
    "message": "File was not copied over successfully. Pls check with Data Pipeline Logs",
    "type": "SnsAlarm",
    "topicArn": "#{mySNSTopicARN}"
},

定义好对象后，第二部分需要设置parameters，在这里详细定义了在对象部分声明的每个变量：

  "parameters": [
    {
      "watermark": "s3://mysourcebucket/filename",
      "description": "Source File Path:",
      "id": "myInputS3FilePath",
      "type": "AWS::S3::ObjectKey",
      "myComment": "The File path from the Input S3 Bucket"
    },
    {
      "watermark": "s3://mydestinationbucket/filename",
      "description": "Destination (Backup) File Path:",
      "id": "myOutputS3FilePath",
      "myComment": "The File path for the Output S3 Bucket",
      "type": "AWS::S3::ObjectKey"
    },
    {
      "watermark": "arn:aws:sns:us-east-1:28619EXAMPLE:ExampleTopic",
      "description": "SNS Topic ARN:",
      "id": "mySNSTopicARN",
      "type": "string",
      "myComment": "The SNS Topic's ARN for notifications"
    },
. . . .
  ]
}

牢记这一点，接下来我们首先来看看如何通过 AWS 数据管道的 Web 控制台上传这个定义：

1. 登录 AWS 数据管道控制台，访问此网址：console.aws.amazon.com/datapipeline/home?region=us-east-1。

到目前为止，我们已经将所有管道部署在美国东部（北弗吉尼亚）区域。你可以根据需求选择更改区域。

1. 完成后，选择“创建管道”选项以开始。在“创建管道”页面中，为新管道填写合适的名称和描述：

1. 接下来，选择“导入定义”选项，并点击“加载本地文件”如所示。将 JSON 文件定义复制并上传到此处。

2. 上传文件后，填写“参数”部分，如此处所述：

   • S3 存储桶路径到数据管道日志：浏览并提供用于存储管道日志的存储桶路径。

   • 源文件路径：浏览并选择一个你希望从 Amazon S3 存储桶备份的文件。

   • 目标（备份）文件路径：浏览并选择一个存储备份文件的 Amazon S3 存储桶路径。你也可以选择提供一个备份文件夹名称。每个备份到此位置的文件将遵循标准命名规则：YYYY-MM-dd-HH-mm-ss.bak。

   • SNS 主题 ARN：在此提供一个有效的 SNS 主题 ARN。此 ARN 将用于通知用户管道执行的成功或失败。

   • EC2 实例类型：你可以选择提供一个不同的 EC2 实例类型作为资源。默认情况下，它将使用 t1.micro 实例类型。

   • EC2 实例终止：你可以再次提供不同的实例终止值。默认情况下，设置为 20 分钟。终止时间应根据备份文件所需的时间来调整。文件越大，复制所需的时间就越长，反之亦然。

3. 一旦参数字段被填充，选择“在 Architect 中编辑”选项查看管道定义的整体组件。你应该能看到如下图示：

1. 点击保存以验证管道是否有错误。完成后，选择激活以启动管道的执行过程。

2. 管道需要几分钟时间才能从 WAITING_FOR_RUNNER 状态过渡到 FINISHED 状态。完成后，检查目标 S3 文件夹中的备份文件。

你可以进一步调整这个特定的管道定义，以包括整个 S3 文件夹路径，而不仅仅是当前执行的单个文件。此外，你还可以通过将 scheduleType 从 ONDEMAND 改为 Schedule 来改变管道执行的启动方式，如下面的代码片段所示：

{ 
  "id" : "Default", 
  "type" : "Schedule", 
  "period" : "1 hours", 
  "startDateTime" : "2018-03-01T00:00:00", 
  "endDateTime" : "2018-04-01T00:00:00" 
} 

以下代码片段将在 2018 年 3 月 1 日 00:00:00 开始，每小时执行一次管道，直到 2018 年 4 月 1 日 00:00:00。

若要了解更多有关如何使用 Schedule 对象的信息，请访问 docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-object-schedule.html。

现在，管道已经通过控制台启动并运行，我们还可以看看一些简单的 AWS CLI 命令，通过这些命令，你可以实现相同的结果：

1. 首先，使用以下命令创建一个空的管道：

# aws datapipeline create-pipeline  
--name <NAME_OF_PIPELINE>  
--unique-id <UNIQUE_TOKEN> 

<UNIQUE_TOKEN> 可以是任何字符字符串，用于确保在多次调用 create-pipeline 命令时的幂等性。

1. 创建管道后，你将看到管道的 ID，如下图所示。请记下这个 ID，因为接下来的步骤中会用到它：

1. 接下来，我们需要创建三个单独的 JSON 文件，文件内容如下：

   • pipeline.json：仅复制并粘贴此文件中的对象定义。

   • parameters.json：在此处复制并粘贴参数定义。

   • values.json：创建一个新文件，其中包含参数的值，如下代码片段所示。记得将 <> 中的值替换为你自己的值：

{ 
  "values": 
    { 
      "myDataPipelineLogs": "s3://<BUCKET_NAME>", 
      "myOutputS3FilePath": "s3://<BUCKET_NAME>/<FOLDER>", 
      "myInputS3FilePath": "s3://<BUCKET_NAME>/<FILE_NAME>", 
      "mySNSTopicARN": "<SNS_ARN_FOR_NOTIFICATIONS>", 
      "myEC2InstanceType": "t1.micro", 
      "myEC2InstanceTermination": "20" 
    } 
} 

1. 完成后，保存所有三个文件，并输入以下命令将管道定义附加到新创建的管道上：

# aws datapipeline put-pipeline-definition  
--pipeline-id <PIPELINE_ID>  
--pipeline-definition file://pipeline.json  
--parameter-objects file://parameters.json  
--parameter-values-uri file://values.json 

这是该命令输出的截图，供你参考：

1. 上传管道定义后，剩下的最后一步是使用以下命令激活管道：

# aws datapipeline activate-pipeline  
--pipeline-id <PIPELINE_ID> 

1. 一旦管道被激活，你可以使用以下命令查看其状态和最后的运行时间：

# aws datapipeline list-runs
--pipeline-id <PIPELINE_ID>

1. 一旦管道执行完成，你可以使用以下一组命令停用并删除管道：

# aws datapipeline deactivate-pipeline  
--pipeline-id <PIPELINE_ID> 
# aws datapipeline delete-pipeline  
--pipeline-id <PIPELINE_ID> 

这是该命令输出的截图，供你参考：

到此，我们又迎来了另一个有趣章节的结束，但在结束之前，来看看一些你应该自己尝试的下一步操作。

规划你的下一步

虽然我们在本章中已经讲解了很多内容，但关于数据管道的内容仍有许多需要讨论。开始使用数据管道的最快且最简单的方法之一是使用现成的管道定义模板。

截至目前，数据管道提供了以下可供使用的现成模板，你可以使用它们在几分钟内开始你自己的管道：

你还可以将这些定义作为模板，用于进一步定制和增强你自己的管道。只需使用之前展示的模板创建一个管道，但不要激活它。在架构模式下编辑管道并简单地将管道定义导出到本地。一旦模板的管道定义保存在本地，你可以进一步对其进行修改和增强，或者直接重用其中的组件来创建你自己的管道，可能性是无穷的！

管道的另一个酷功能是使用竞价实例作为任务节点。默认情况下，管道仅提供按需实例作为任务节点的资源。你可以通过简单地从管道的资源面板中选择任务实例出价价格选项来切换到竞价实例。在相应字段中提供合适的金额（介于 0 和 20.00 之间），就这么简单！下次管道激活并运行任务时，它将根据竞价实例的可用性来执行。

总结

好的，这也意味着我们又一精彩章节的结束。让我们快速总结一下到目前为止学到的内容！

首先，我们开始简要了解了 AWS 数据管道及其概念和术语。随后，我们还学习了管道定义，并了解了如何轻松编写和使用它们。我们甚至使用管道定义构建了第一个简单的“Hello World”管道，并给出了几个示例，你可以根据自己的使用案例进行调整和使用。最后，我们还探索了一些简单的 AWS CLI 命令，来帮助你与管道配合使用，并为下一步操作提供了实用的指南。

在下一个也是最后一章中，我们将学习和探索 AWS 多功能且强大的 IoT 服务，敬请期待！

第十一章：使用 AWS IoT 和 AWS Greengrass 连接世界

到目前为止，这一路走来已经挺长了，但我们终于到了本书的最后一章！如果你已经坚持到这里，那你绝对需要花点时间给自己一个应得的掌声！

到目前为止，我们已经介绍了许多服务，如 Amazon EFS、AWS Beanstalk、AWS Code Suite、AWS Shield 和 AWS Data Pipeline，等等。在最后一章，我们将深入探讨 AWS 提供的物联网服务套件，重点关注两个核心产品，即 AWS IoT 和 AWS Greengrass。

让我们快速浏览一下本章将要涉及的各种主题：

• 对物联网所需构建块的简要介绍

• AWS IoT 服务套件简介，并深入探讨 AWS IoT 及其概念和术语

• 使用树莓派 Zero 设备连接到 AWS IoT

• 探索 AWS IoT 设备 SDK，通过一些简单的代码示例

• 使用物联网规则将 AWS IoT 与其他 AWS 服务集成

• AWS Greengrass 简介，并附带一个简单的入门示例

• 有效监控物联网设备以及物联网服务

那么不再多说，让我们开始吧！

物联网——它究竟是什么？

对于外行来说，物联网（IoT）就是将日常的物品或物体通过使用一个共同的通信媒介（在此为互联网）连接起来，以便交换数据。我知道这听起来没什么了不起的，但如今，物联网几乎无处不在；从可穿戴设备、智能手机、家电（如冰箱、空调）到车辆、重型机械等，几乎无所不包！Gartner 预测，到 2020 年，预计将有约 260 亿个设备通过物联网连接，且随着物联网的普及，这一数字将继续增长。但物联网究竟是什么？又该如何构建物联网呢？下面是一些入门物联网所需的基本构建块：

• 物体：首先，任何形式的物联网都由我们使用或依赖的终端设备组成，这些设备用于执行我们日常生活中的某些任务。这些设备或物体可以是任何东西，包括简单的电子设备，如智能手机、可穿戴设备、闹钟、灯泡，到洗衣机、车库门、车辆、船只，等等，名单非常长！

• 传感器：传感器是可以嵌入到物体中的设备，用于捕获或提供我们的数据。一些常见的传感器包括红外传感器、湿度传感器、气体和压力传感器等。传感器本身并不处理数据，它们仅仅收集并将数据发送到一个或多个处理器。例如，一个监控灯泡开关状态的光传感器，等等。

• 处理器：处理器是物联网系统的大脑。它们的主要功能是处理由传感器捕获的数据。这种处理可以基于特定触发条件进行，或者也可以接近实时地执行。一个处理器还可以连接并处理来自多个传感器的数据。最常用的处理器类型包括微控制器、嵌入式控制器等。

• 网关：网关是负责收集和路由数据的特殊设备，这些数据由一个或多个处理器处理后传送到物联网应用程序以进行进一步分析。网关可以收集、汇总并通过互联网发送数据，具体是以流式数据或批量数据的形式，取决于其配置和连接选项。

• 应用程序：一旦从各种网关收集到数据，接下来需要进一步分析，以形成有意义的见解，从而能够在各自的操作上执行适当的动作。这可以通过利用一个或多个应用程序来实现，例如工业控制中心，甚至是家庭自动化系统。例如，可以使用应用程序来远程触发灯泡开关，一旦房间的环境光开始变暗，等等。

牢记这些基本信息后，让我们来看一看一些关键的 AWS 服务，帮助你开始在云端构建自己的物联网应用。

介绍 AWS 物联网服务套件

自 2015 年底首次推出以来，AWS 大大增强了其物联网服务套件。以下是其提供服务的简要说明：

• AWS IoT Core：AWS IoT Core 是一个托管服务，它允许你安全地连接并与数十亿的物联网设备进行交互，而无需担心设置或管理任何底层基础设施。你可以使用 IoT Core 服务构建物联网应用程序，还可以结合使用多个 AWS 服务，如 AWS Lambda、Amazon Elasticsearch、Amazon 机器学习等。

• AWS IoT 设备管理：AWS IoT 设备管理服务允许你轻松注册、组织和管理大量物联网设备。你可以使用该服务批量引入设备，并通过一个统一的视图管理所有设备。

• AWS Greengrass：AWS Greengrass 是一个软件服务，旨在在你的物联网设备上本地执行 Lambda 函数。此外，你还可以使用 Greengrass 在设备与 IoT Core 之间同步数据，利用数据缓存以及其他功能，如机器学习推理、消息传递等。

• AWS IoT 分析：连接和管理数十亿个 IoT 设备是一项任务，而查询庞大的 IoT 数据集则是另一项任务。AWS IoT 分析是一个完全托管的服务，允许你对极大量的 IoT 数据进行分析，无需配置或管理底层分析平台。使用此服务，你可以获得关于设备的更好洞察，并构建强韧的 IoT 应用程序。

• AWS IoT 按钮：AWS IoT 按钮是一个支持 Wi-Fi 的可编程按钮，使你能够编写并集成 IoT 应用程序，而无需了解任何设备特定的代码。

• AWS IoT 设备防护：随着设备数量的增加，保护设备免受恶意攻击变得同样重要。AWS IoT 设备防护是一个托管服务，允许你根据一套安全规则和政策来保护、管理和审核远程设备。如果发现任何偏离，IoT 设备防护会触发适当的通知。

• Amazon FreeRTOS：Amazon FreeRTOS 是一个专为小型、低功耗的边缘设备或微控制器构建的定制操作系统。该操作系统基于 FreeRTOS 内核，帮助轻松连接和管理与 AWS IoT 服务的设备。

至此，本节内容已结束。在接下来的章节中，我们将更详细地了解 AWS IoT Core 服务，并提供一个简单易懂的入门指南。

开始使用 AWS IoT Core

在简要了解了 AWS IoT 套件服务后，我们现在可以深入探索 AWS IoT Core 的世界！然而，在开始一些实际操作项目之前，下面是一些重要的 AWS IoT Core 概念和术语的快速介绍：

AWS IoT Core 服务提供设备与 AWS 云之间的双向通信，使用以下列表中描述的一组组件：

• 设备网关：设备网关为 IoT 设备与 AWS IoT 服务之间的通信提供了安全机制。

• 设备影像：设备影像是 IoT 设备在云端的持久表示。基于 JSON 的文档存储了设备的当前状态，你可以用它与云端进行同步。

• 消息代理：消息代理提供了一个安全可靠的通道，通过它，IoT 设备可以与云端进行通信。该代理基于发布–订阅模型，可以利用标准的 MQTT 协议，或通过 WebSockets 实现高级 MQTT 协议进行通信。

• 注册表：注册表是一项服务，用于安全地将 IoT 设备注册到云端。你可以使用注册表将证书和 MQTT 客户端 ID 与设备关联。

• 组：组是逻辑容器，用于将类似设备进行分组，从而有效地管理它们。你可以使用组来传播权限并对连接的设备执行批量操作。

• 规则：AWS IoT Core 中的规则引擎服务提供了一种机制，使您能够使用简单的 SQL 查询处理物联网数据。您还可以编写规则，将 AWS IoT Core 与其他 AWS 服务集成，如 AWS Lambda、Amazon S3、Amazon Kinesis 等。

下面是所有内容如何完美地配合在一起的！您首先准备一台设备，以便连接到 AWS IoT Core。这涉及创建一组证书，这些证书在设备连接到 AWS IoT Core 时验证设备。连接后，设备开始使用标准 MQTT 协议以 JSON 格式发布其当前状态的消息。这些消息被发送到消息代理，基于消息的主题将其路由到相应的订阅客户端。

您甚至可以创建一个或多个规则来定义基于消息中包含的数据的一系列操作。当特定数据匹配配置的表达式时，规则引擎会调用该特定操作，该操作可以是将数据发送到 Amazon S3 中的文件，也可以是使用 AWS Lambda 或 Amazon Kinesis 处理数据。以下是这些组件的表示方式：

牢记这一点，让我们看看如何将您的物联网设备连接到 AWS IoT Core！

连接设备到 AWS IoT Core

AWS IoT 支持多种专用物联网嵌入式设备和微控制器，您可以将其连接到。但是，为简单起见，您还可以使用本地设置的虚拟机或 EC2 实例来模拟物联网设备。对于本节，我们将使用基于 Ubuntu 的简单虚拟机，在 VirtualBox 中托管。虚拟机中安装了基本操作系统软件包，并以 512 MB RAM 和 1 CPU 核心分配运行，拥有 10 GB 硬盘。在继续任何进一步的步骤之前，请确保您的虚拟机具有开放的互联网连接和有效的主机名设置。

下面的列表展示了模拟物联网设备的配置供您参考：

• CPU：1 CPU

• RAM：512 MB

• 操作系统：Ubuntu Server 16.04.2 LTS（Xenial）x86_64 架构

• 软件包：核心服务器软件包以及 vim、node、npm、git、wget

设备或虚拟机准备好后，我们可以连接到 AWS IoT Core：

1. 从 AWS 管理控制台，使用提供的筛选器过滤并选择 AWS IoT 服务。或者，选择此网址，console.aws.amazon.com/iot/home 来启动 AWS IoT 控制台。

2. 选择“开始”选项以继续。

3. 登录控制台后，从控制台左侧的导航窗格中选择"入门"选项。在这里，您可以选择开始配置第一个设备与 IoT 服务的连接，并选择其他选项，如配置 AWS IoT 按钮或开始使用 AWS IoT 入门套件。在此部分中，选择在“配置设备”部分下的“开始使用”选项。

4. "开始使用"选项是一个简单的三步过程，首先是注册您的设备，然后下载一组凭证和 SDK，以便设备与 IoT Core 进行通信，最后测试检查设备是否成功连接。

5. 从“选择平台”选项中选择 Linux/OSX，然后从“选择 AWS IoT 设备 SDK”中选择 Node.js，如下图所示。请注意，您也可以选择 Java 或 Python SDK；不过，本用例的其余部分将仅基于 Node.js：

1. 选择适当的平台和 IoT SDK 后，点击“下一步”继续。

2. 下一步涉及注册一个Thing，在我们的例子中，就是物联网设备本身。首先为您的 Thing 提供一个合适的名称，然后选择显示可选配置选项。

3. 在“为此 Thing 应用类型”部分中，选择创建类型选项。Thing 类型通过为共享特定类型的 Thing 提供一致的注册数据，从而简化了 IoT 设备的管理。为您的 Thing 类型提供合适的名称和可选描述，并在完成后选择创建 Thing 类型。

4. 这是最终配置的样子。在我的例子中，我创建了一个名为 dummyIoTDevice 的 Thing 类型，用于将所有基于虚拟机的 IoT 设备逻辑地分类在一起。完成后选择创建 Thing 选项：

1. 成功创建 Thing 后，我们现在需要建立 Thing 与 AWS IoT Core 之间的连接。为此，请从 Things 控制台中选择新创建的 Thing 图标，以查看 Thing 的各种配置选项。重要选项之一是安全性选项。请从导航窗格中选择安全性选项。

2. 在这里，您可以创建并关联所需的证书，以及与 Thing 通信所需的策略，这些策略是与 IoT Core 通信时所必需的。首先选择创建证书选项开始。

3. 必要的证书由 AWS Core 自动创建。下载这些文件并保存在安全的地方。证书可以随时检索，但在关闭此页面后，私钥和公钥无法检索：

   • 此 Thing 的证书: xyz.cert.pem

   • 一个公钥: xyz.public.key

   • 一个私钥: xyz.private.key

此外，您还需要从 Symantec 下载 AWS IoT 的根 CA。您可以通过选择以下 URL 来完成此操作：

www.symantec.com/content/en/us/enterprise/verisign/roots/VeriSign-Class%203-Public-Primary-Certification-Authority-G5.pem

请记得选择“激活”选项，以成功激活密钥。完成后，选择“附加策略”选项，如下截图所示：

1. 由于这是我们第一次使用 IoT Core，我们需要从头开始创建一个新策略。该策略将用于授权我们在前一步创建的证书。选择“创建新策略”选项以开始。

2. 在创建策略页面，首先为你的新策略提供一个合适的名称。完成后，你可以选择 基础 或 高级 模式来创建 IoT 策略。为了简单起见，选择高级模式选项，并粘贴以下策略片段：

{
  "Version": "2012-10-17",
  "Statement": [
  {
    "Effect": "Allow",
    "Action": "iot:*",
    "Resource": "*"
  }
  ]
}

以下策略允许所有设备连接、发布和订阅 AWS IoT 消息代理。你也可以根据需求调整此策略。

1. 完成后，选择“创建”选项以完成策略创建过程。

完成此步骤后，我们距离建立 IoT 设备与 AWS IoT Core 之间的连接仅剩几个步骤。

1. 创建所需的策略并下载证书后，我们现在需要将这些证书复制到我们的 IoT 设备上，在此案例中是 Ubuntu 虚拟机。你可以使用任何 SCP 工具来执行此操作，例如 WinSCP。以下是我 Ubuntu 虚拟机上的文件截图：

对于这个场景，我将下载的 Symantec 根证书文件命名为 root-CA.crt。

一旦文件被复制到 IoT 设备的目标文件夹，你现在可以开始测试连接性，但为了做到这一点，我们首先需要在 IoT 设备上安装并配置 AWS IoT 设备 SDK。

开始使用 AWS IoT 设备 SDK

AWS IoT 设备 SDK 是一种快速简便的方法，可以将你的 IoT 设备连接到 AWS IoT Core。至今，AWS 提供了适用于 Node.js、Java、Python 和嵌入式 C 的 IoT 设备 SDK。在本节中，我们将使用 Node.js SDK 将虚拟的 IoT 设备与 AWS IoT 连接。

在开始之前，确保你已经安装并运行了设备上的最新版本的 node 和 NPM。由于我们使用 Ubuntu 虚拟机模拟 IoT 设备，你可以使用以下命令来安装并验证 node 和 NPM 的版本：

# sudo apt-get update 
# sudo apt-get install nodejs npm 
# node -v && npm -v 

安装所需的软件包后，我们现在需要安装 AWS IoT 设备 SDK。请输入以下命令：

# npm install aws-iot-device-sdk 

安装好 SDK 后，我们现在可以开始通过一个简单的 Node.js 程序测试连接性。将以下代码片段复制并粘贴到你 IoT 设备上的新 .js 文件中：

# vi test1.js 
//Connection parameters 
var awsIot = require('aws-iot-device-sdk'); 
var device = awsIot.device({ 
   keyPath: '<PATH_TO_PRIVATE.PEM.KEY>', 
  certPath: '<PATH_TO_CERTIFICATE.PEM>CRT>', 
    caPath: 'root-CA.crt', 
  clientId: '<THING_NAME>', 
    region: '<REGION>', 
      host: '<IoT_DEVICE_REST_API_ENDPOINT>' 
}); 
//Connection parameters end 

//Device Object 
device 
.on('connect', function () { 
console.log('Yaaa! We are connected!'); 
}); 

这段代码的作用是什么？首先，代码的第一部分是传递从前面的步骤中下载的私钥和证书，以及其他一些配置项，比如clientId、AWS IoT Core 所在的region，以及host，这实际上是你的设备的唯一 REST API 端点。你可以通过从 AWS IoT 仪表板中选择新创建的 IoT 设备，并选择“Interact”标签来找到这个端点，具体如下图所示：

代码的第二部分是使用配置好的参数连接到 AWS IoT Core。如果连接成功，它将打印出一个简单的消息，如下所示。要运行代码，只需输入以下命令：

# node test1.js 

设备现在成功连接到 AWS IoT Core，我们来看一些其他示例，帮助你与消息代理服务进行交互。首先，让我们看看如何使用 AWS IoT 设备 SDK 订阅主题，并打印出发布到该主题的任何消息。

将以下代码片段粘贴到连接参数下方：

# vi test2.js 
//Connnection parameters 
. . . . . 
//Connection parameters end 

//Device Object 
device 
.on('connect', function () { 
console.log('Yaaa! We are connected!'); 
device.subscribe('Topic0'); 
console.log('Subscribed to Topic'); 
}); 

device 
.on('message', function (topic, payload) { 
console.log('Received following message: ', topic, payload.toString()); 
}); 

以下代码将设备订阅到名为Topic0的主题。一旦订阅完成，代码将显示发布到该主题的任何消息。

在代码就绪后，保存文件并使用以下代码运行程序：

# node test2.js 

接下来，我们来看一下如何将消息发布到新创建的主题：

1. 要将消息发布到以下主题，我们将使用 AWS IoT Core 本身提供的 MQTT 客户端。为此，从 AWS IoT Core 仪表板中选择导航窗格中的“Test”选项。

2. 使用 MQTT 客户端，你既可以订阅，也可以发布消息到主题。点击“Publish to topic”选项。

3. 在“发布”部分，提供你想发布消息的主题名称（在本例中为Topic0），然后点击“Publish to topic”按钮，如下图所示：

检查设备终端以获取相应的消息。你应该会看到以下输出：

设备现在能够订阅主题，你还可以让设备发布消息到主题。

再次创建一个新文件，并将以下代码片段粘贴到连接参数下方：

# vi test3.js 
//Connnection parameters 
. . . . . 
//Connection parameters end 

//Device Object 
device 
.on('connect', function () { 
console.log('Yaaa! We are connected!'); 
device.subscribe('Topic0'); 
console.log('Subscribed to Topic'); 
var msg = "Hello from IoT Device!"; 
      device.publish('Topic0', msg); 
      console.log ("Publishing message: "+msg); 
}); 

device 
.on('message', function (topic, payload) { 
console.log('Received following message: ', topic, payload.toString()); 
}); 

从以下代码可以看到，我们只是添加了一个publish()方法，它将把自定义消息发布到预定义的主题，在本例中为Topic0。

保存代码并使用以下命令运行程序：

# node test3.js 

你应该在设备终端看到以下输出：

很简单，对吧！你也可以将相同的概念应用于实际的 IoT 设备，只需做一些小的调整。下面是一个代码片段，你可以用它来生成虚拟数据并将数据发布到 MQTT 主题。

创建一个新文件，并将以下代码片段粘贴到连接参数之后，如本节中所示：

# vi test4.js 
//Connnection parameters 
. . . . . 
//Connection parameters end 

var uuid = require('node-uuid'); 
var numbers = new Array(10); 
function getRandomInt(min, max) { 
  return Math.floor(Math.random() * (max - min + 1)) + min; 
} 

device 
.on('connect', function () { 
console.log('Yaaa! We are connected!'); 
device.subscribe('Topic0'); 
console.log('Subscribed to Topic'); 

for (var i = 0; i < numbers.length; i++) 
    { 
  for (var j = 0; j < numbers.length; j++) 
     { 
       numbers[i] = getRandomInt(0,1); 
       uuid[i] = uuid.v4() 
      } 
      var msg = "{"uuid":"" + uuid[i] + """ + "," +"""+ "state":" + numbers[i]+"}"; 
      device.publish('Topic0', msg); 
      console.log ("Publishing message: "+uuid[i],numbers[i]); 
   } 

}); 

device 
.on('message', function (topic, payload) { 
console.log('Received following message: ', topic, payload.toString()); 
}); 

以下代码片段使用 node-uuid 模块随机生成长字符串的 UUID。每生成一个 UUID 记录，就会打印一个随机值，值为 0 或 1，表示 UUID 的状态。你可以通过调整数组对象的值来控制生成的记录数量。默认情况下，以下代码将以正确的 JSON 格式将 10 条记录发布到 MQTT 主题，如以下代码片段所示：

{ 
"uuid":"357d6212-3444-4f55-9784-93a265905289", 
"state":0 
} 
{ 
"uuid":"ad8cb61b-f29d-4a84-a7eb-42633dd3a3c2", 
"state":0 
} 
. . . . .  
{ 
"uuid":"19492c45-0cf7-4468-b275-5b7b1bdf3a64", 
"state":1 
} 

一旦代码就位，只需使用以下命令执行它：

# node test4.js 

到此，我们这一节的内容已经结束。在下一节中，我们将讨论如何使用简单的 IoT 规则将 AWS IoT Core 与其他 AWS 服务集成。

使用 IoT 规则

最近 AWS IoT Core 提供的最吸引人的功能之一就是 IoT 规则。通过 IoT 规则，你可以为连接的设备提供与其他 AWS 服务交互的能力。IoT 规则提供了一组预定义的规则，使你能够执行各种任务，下面列举了一些：

• 将设备接收到的数据写入 Amazon DynamoDB 表

• 向所有用户发送推送通知，使用 Amazon SNS

• 将数据发布到 Amazon SQS 队列

• 调用 Lambda 函数执行数据转换

• 使用 Amazon Kinesis 处理设备数据，等等

一个 IoT 规则还为你提供了额外的功能，使你能够查询和过滤设备数据，同时使用简单的 SQL 命令。根据 SQL 语句的执行结果，你可以触发成功或错误的操作：

1. 要开始使用 IoT 规则，从 AWS IoT Core 控制台中选择 Act 选项。由于这是第一次使用，请点击创建规则，继续下一步。

2. 在创建规则页面，首先为规则提供一个合适的名称和描述。在本场景中，我们将创建一个 IoT 规则，将所有设备数据写入 DynamoDB 表。

3. 接下来，从使用 SQL 版本的下拉列表中选择一个适合此规则的 SQL 版本。默认情况下，将选择 2016-03-23 版本。

4. 接下来，我们形成规则查询语句。此语句用于从大量设备数据中筛选出特定的消息。在这种情况下，我们希望将来自演示设备的所有数据写入 DynamoDB 表，因此在属性字段中输入一个*，表示所有字段，接着在主题过滤选项中输入有效的主题名称。你还可以设置一个可选的条件来匹配查询。

这是最终查询应该呈现的样子：

1. 在查询设置完成后，下一步是将一个或多个操作与您的物联网规则关联。在“设置一个或多个操作”部分，选择“添加操作”选项以开始操作。

2. 在“选择操作”页面，您可以浏览并选择一个预定义的操作模板。在这种情况下，我们将选择“将消息插入到 DynamoDB 表”操作，它允许您将整个或部分 MQTT 消息写入 DynamoDB 表。选择后，点击“配置操作”以继续。

3. 这将带您进入“配置操作”页面，您可以选择一个现有的 DynamoDB 表，或者创建一个新的表。在此用例中，我们将依赖于我们在示例设备上最后执行的 UUID 和 state 代码。为了拆分并将消息数据写入各自的列，请确保您创建的 DynamoDB 表符合以下设置：

   • 分区键：uuid

   • 排序键：state

   • 阅读容量单位：5

   • 写入容量单位：5

1. 创建表格后，从“表格名称”下拉列表中选择该表格。接下来，填写“哈希键值”和“范围键值”字段中的相应表达式，如下图所示。这些表达式会将消息值写入其对应的 DynamoDB 表列：

1. 确保您还创建并分配一个 IAM 角色，该角色将授予 DynamoDB 表的写入 AWS IoT 访问权限。表格和 IAM 角色分配完成后，点击“添加操作”以完成操作配置。您可以使用相同的过程向单个 IoT 规则添加多个操作。例如，将设备消息写入 DynamoDB 表以及 SQS 队列，等等。规则设置好后，点击“创建规则”以完成该过程。

2. 现在，测试规则。运行我们在前面部分中运行的 uuid-state 代码。确保代码中的主题名称与 IoT 规则中的主题名称匹配，否则代码将无法将任何内容写入 DynamoDB 表：

# node test4.js

在代码执行时，检查 DynamoDB 表中的数据。您应该看到与以下截图类似的输出：

到此为止，我们已完成 AWS IoT Core 的内容。确保在测试完成后清理并删除 DynamoDB 表，以避免不必要的费用。在下一部分，我们将探讨另一个强大的 AWS IoT 服务——AWS Greengrass。

介绍 AWS Greengrass

AWS Greengrass 是一种边缘计算服务，通过允许数据收集和分析更接近数据源的方式，将云功能扩展到您的物联网设备。这是通过在物联网设备本地执行 AWS Lambda 函数来实现的，同时仍然利用云端进行管理和分析。

这对企业有什么帮助呢？首先，通过使用 AWS Greengrass，您现在可以近实时地响应本地生成的事件！借助 Greengrass，您可以编程 IoT 设备在本地处理和筛选数据，仅将重要的信息传回 AWS 进行分析。这也直接影响到成本和传输回云端的数据量。

下面简要介绍 AWS Greengrass 工作原理中所需的一些组件：

• Greengrass Core（GGC） 软件（software）： Greengrass Core 软件是一个打包的模块，包含一个运行时环境，允许在本地执行 Lambda 函数。它还包含一个内部消息代理和一个部署代理，定期通知 AWS Greengrass 服务有关设备的配置、状态、可用更新等信息。该软件还确保设备与 IoT 服务之间的连接通过密钥和证书保持安全。

• Greengrass 群组（Greengrass groups）： Greengrass 群组是用于管理一个或多个由 Greengrass 支持的 IoT 设备的 Greengrass Core 设置和定义的集合。群组内部包括一些其他组件，具体如下：

  • Greengrass 群组定义（Greengrass group definition）： 关于 Greengrass 群组的相关信息集合。

  • 设备定义（Device definition）： 作为 Greengrass 群组一部分的 IoT 设备集合。

  • Greengrass 群组设置（Greengrass group settings）： 包含连接及配置相关信息，以及与其他 AWS 服务交互所需的 IAM 角色。

  • Greengrass Core： IoT 设备本身。

• Lambda 函数（Lambda functions）： 可以部署到 Greengrass Core 的 Lambda 函数列表。

• 订阅（Subscriptions）： 一组消息源、消息目标和用于传输消息的 MQTT 主题。消息源或目标可以是 IoT 服务、Lambda 函数，甚至是 IoT 设备本身。

• Greengrass Core SDK： Greengrass 还提供了一个 SDK，您可以用它在 Greengrass Core 设备上编写和运行 Lambda 函数。当前 SDK 支持 Java 8、Python 2.7 和 Node.js 6.10。

牢记这些关键信息后，让我们开始在 IoT 设备上部署我们自己的 Greengrass Core。

将设备连接到 Greengrass Core。

将 IoT 设备连接到 AWS Greengrass 的步骤与我们在设置 AWS IoT Core 时执行的步骤非常相似。在本节中，我们将使用 AWS 管理控制台为我们的虚拟机上的 Ubuntu Server 添加 Greengrass 以扩展我们的虚拟 IoT 设备：

1. 要开始使用，请在 AWS IoT 控制台中，选择导航窗格中的 Greengrass 选项。

2. 设置 Greengrass 包括三个步骤，首先创建和配置一个 Greengrass 群组（Greengrass group），然后将 Greengrass Core 添加到群组，最后将 IoT 设备添加到群组。开始之前，请点击“定义 Greengrass 群组”面板下的“开始使用”选项。

3. 在“设置您的 Greengrass 组”页面，选择“使用简单创建”选项。此过程将自动在注册表中预配一个核心，使用默认设置生成一个新组，并为您的核心提供一个新的证书和密钥对。

4. 输入一个合适的组名，并点击“下一步”继续。

5. 您可以选择通过从下拉框中选择“Thing 类型”来为此组应用类型，如下图所示。在这种情况下，我们已经在之前的练习中定义了一个 Thing 类型，因此我们将使用这个。点击“下一步”继续：

1. 由于我们使用的是 简单创建 方法，AWS 执行一个脚本操作，基本上为我们完成以下任务：

   • 在云中创建一个新的 Greengrass 组

   • 在 IoT 注册表中预配一个新的核心并将其添加到组中

   • 为您的核心生成一对公钥和私钥

   • 使用这些密钥为核心生成新的安全证书

   • 将默认安全策略附加到证书上

2. 点击“创建组和核心”继续执行脚本安装。

3. 最后，在“连接您的核心设备”页面，选择“将这些资源下载为 tar.gz”选项，将特定于核心的证书和配置文件作为 TAR 资源下载。您还需要下载适合在 IoT 设备上运行的 Greengrass 核心软件版本。由于我们正在 Ubuntu 基础的虚拟机上执行所有这些操作，请从 Greengrass 核心软件下拉列表中选择 x86_64_Ubuntu 选项并下载。下载完成后，点击“完成”退出设置。

下载了 Greengrass 核心软件和必要的 Greengrass 证书后，我们需要使用任何 SCP 工具将它们传输到我们的 IoT 设备上。传输完成后，运行以下命令集以设置并启动 Greengrass 核心：

1. 首先，使用以下命令解压 Greengrass 核心软件。

# sudo tar -xzvf greengrass-<PLATFORM-VERSION>.tar.gz -C /

1. 接下来，运行以下命令以解压并将安全文件和证书放置在 greengrass 目录中：

# sudo tar -xzvf <UID>-setup.tar.gz -C /greengrass

1. 一旦两个 TAR 文件的内容被解压，运行以下命令从 Symantec 下载根 CA 证书：

# cd /greengrass/certs/
# sudo wget -O root.ca.pem http://www.symantec.com/content/en/us/enterprise/verisign/roots/VeriSign-Class%203-Public-Primary-Certification-Authority-G5.pem

以下是最终的文件夹结构供您参考：

1. 完成后，运行以下命令集为 Greengrass 核心软件创建一个专用的用户和组：

# sudo adduser --system ggc_user 
# sudo addgroup --system ggc_group 

1. 接下来，使用以下命令更新主机操作系统并安装 sqlite3 软件包：

# sudo apt-get update 
# sudo apt-get install sqlite3 

1. 当所有组件就位后，我们现在准备好在 IoT 设备上启动 Greengrass 核心服务。按如下所示输入以下命令：

# cd /greengrass/ggc/packages/1.3.0/ 
# sudo ./greengrassd start

您应该在终端上看到以下输出，如下所示：

如果连接时出现错误，您还可以查看 Greengrass 运行时日志文件，路径如下：

/greengrass/ggc/var/log/system/runtime.log.

很简单，对吧！完成了三步中的两步，剩下的最后一步就是将设备添加到我们创建的 Greengrass 组中：

1. 为此，在 AWS IoT 控制台中，选择导航窗格中 Greengrass 部分下的“组”选项。您应该在这里看到新创建的 Greengrass 组。点击选择它。

2. 选择“设备”，然后点击“添加您的第一个设备”选项继续。

3. 在“添加设备”页面中，您可以选择创建新设备或选择使用现有的 IoT Thing 作为设备。由于我们已经在之前的 IoT 设置中注册了物联网设备，请选择“选择 IoT Thing”选项继续。

4. 选择已添加的 IoT 设备的名称，然后点击“完成”以完成该过程。

完成了！您已成功安装并将物联网设备与 AWS Greengrass 连接！在下一节中，我们将通过运行一个简单的 Lambda 函数来测试此部署。

在 AWS Greengrass 上运行 Lambda 函数

在您的物联网设备上成功运行 Greengrass Core 软件后，我们现在可以继续在其上运行一个简单的 Lambda 函数！在本节中，我们将使用一个 AWS Lambda 蓝图，该蓝图会打印一个简单的 Hello World 消息：

1. 首先，我们需要创建我们的 Lambda 函数。进入 AWS 管理控制台，通过筛选器选项筛选出 Lambda 服务，或者选择此网址：console.aws.amazon.com/lambda/home。

确保 Lambda 函数是在与 AWS Greengrass 相同区域启动的。在这种情况下，我们使用的是 US-East-1（北弗吉尼亚）区域。

1. 在 AWS Lambda 控制台首页，选择“创建函数”选项以开始。

2. 由于我们将利用现有的函数蓝图来完成此用例，请在“创建函数”页面中选择“蓝图”选项。

3. 使用筛选器查找名为 greengrass-hello-world 的蓝图。目前有两个与此名称匹配的模板，一个基于 Python，另一个基于 Node.js。对于本节内容，请选择基于 Python 的 greengrass-hello-world 函数，并点击“配置”以继续。

4. 填写新函数的必需详细信息，例如名称，然后选择一个有效的角色。对于本节内容，请选择“从模板创建新角色”选项。提供一个合适的角色名称，最后，从“策略模板”下拉列表中选择 AWS IoT 按钮权限角色。

5. 完成后，点击“创建函数”以完成函数的创建过程。但在将此函数与 AWS Greengrass 关联之前，您还需要从该函数创建一个新的版本。在“操作”标签中选择“发布新版本”选项。

6. 提供合适的版本描述文本，完成后点击 Publish。您的函数现在已准备好用于 AWS Greengrass。

7. 现在，返回到 AWS IoT 仪表板，选择导航窗格中的 Groups 选项，然后选择新部署的 Greengrass 群组。

8. 在 Greengrass 群组页面，选择导航窗格中的 Lambdas 选项，然后选择 Add Lambda 选项，如下图所示：

1. 在将 Lambda 添加到您的 Greengrass 群组页面上，您可以选择创建一个新的 Lambda 函数或使用现有的 Lambda 函数。由于我们已经创建了函数，请选择 Use existing function 选项。

2. 在下一页，选择您的 Greengrass Lambda 函数，然后点击 Next 继续。最后，选择已部署函数的版本，完成后点击 Finish。

3. 最后，我们需要在 Lambda 函数（源）和 AWS IoT 服务（目标）之间创建一个新的订阅。在同一 Greengrass 群组页面中选择 Subscriptions 选项，如下所示。点击 Add Subscription 以继续：

1. 在选择源和目标页面，选择新部署的 Lambda 函数作为源，然后选择 IoT 云作为目标。完成后点击 Next。您还可以提供一个可选的主题过滤器，用于过滤在消息队列中发布的消息。在此示例中，我们提供了简单的 hello/world 作为过滤器。完成后点击 Finish 以完成订阅配置。

所有组件准备就绪，现在是时候将我们的 Lambda 函数部署到 Greengrass Core 上了。为此，选择 Deployments 选项，并从 Actions 下拉菜单中选择 Deploy 选项，如下图所示：

部署需要几秒钟完成。完成后，通过查看 Status 列来验证部署状态。状态应该显示为 Successfully completed。

函数部署完成后，使用 AWS IoT 提供的 MQTT 客户端进行测试，如之前所做。记得在订阅主题字段中输入相同的 hello/world 主题名称，完成后点击 Publish to topic。如果一切顺利，您应该会从 Greengrass Core 收到一个自定义的 Hello World 消息，如下图所示：

这只是 Greengrass 和 Lambda 能实现的高层次概述。您可以利用 Lambda 在 IoT 设备本身上执行各种数据预处理，从而节省大量时间和成本。

至此，本节内容已结束。在下一节中，我们将介绍一些简单有效的监控 IoT 设备的方法。

监控 AWS IoT 设备和服务

AWS 提供了多种方法来监控你的 IoT 设备以及 IoT 服务及其调用。为了开始，让我们先看看 AWS IoT 仪表板本身提供的简单设备监控功能。在 AWS IoT 控制台页面上，选择“监控”选项。在这里，你可以查看各种图表和数据，比如过去一小时、一天或一周内与 AWS IoT 服务建立的成功连接数。你甚至可以检查通过 MQTT 或 HTTP 协议传输的消息数，如下图所示：

你还可以使用监控页面查看发布的消息数、执行的规则数和影像更新数。

除此之外，你还可以为 AWS IoT 服务启用日志记录。为此，请从 AWS IoT 控制台的导航窗格中选择“设置”选项。默认情况下，AWS IoT 的日志记录是禁用的，但你可以通过选择日志部分下的“编辑”选项轻松启用它。当你的 IoT 设备的消息通过消息代理和规则引擎时，你可以使用 AWS IoT 日志来处理事件，进而排查设备端以及服务端的问题。

根据你的日志记录需求，你可以选择调试（最详细）、信息、警告和错误（最简洁）等不同的详细级别。

总结

嗯，就像所有美好的旅程一样，这本书也迎来了它的终结！我只想借此机会说，这真是一次美妙的旅程和体验，写这本书的过程让我非常愉快！尽管这本书看起来有很多内容需要阅读和理解，但相信我，这一切不过是沧海一粟！AWS 不断努力通过新增越来越多的功能来发展其服务，以至于如今，你几乎可以找到任何你需要的即用型服务，包括游戏开发、人工智能、客户互动、商业生产力等，仅举几例！

简要总结一下我们到目前为止所学的内容：我们从与 EC2 Systems Manager 的一些有趣实践开始，接着是我最喜欢的两个服务——Elastic Beanstalk 和 Elastic File System。我们还涉及了很多安全内容，包括 AWS WAF、AWS Shield、AWS CloudTrail 和 AWS Config！在接近结尾时，我们开始探索一些以开发者为主的服务，比如 AWS CodeDeploy、AWS CodeCommit 和 AWS CodePipeline 等。最后，我们以高亢的调子结束了最后几章，重点讲解了 Amazon Redshift、Amazon EMR、AWS Data Pipeline 以及最后但同样重要的 AWS IoT 中的物联网和分析服务！

直到下次，再见！