AWS 认证 DevOps 工程师（一）

最新推荐文章于 2025-10-03 00:50:35 发布

原创最新推荐文章于 2025-10-03 00:50:35 发布 · 1.9k 阅读

15 ·

CC 4.0 BY-SA版权

License CC BY-NC-SA 4.0 / 自豪地采用谷歌翻译

文章标签：

#默认分类

默认分类专栏收录该内容

10503 篇文章

订阅专栏

原文：annas-archive.org/md5/b44a68a3321a441a0fdffa7dcbaf1892

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

越来越多的公司正在转向云计算，特别是Amazon Web Services（AWS）云服务。进入云端后，这些公司和企业希望通过采用 DevOps 实践中的技术来精简其流程和软件开发生命周期（SDLC）。这包括自动化构建和发布流程，使开发团队能够专注于编写客户所需的代码和功能。还包括确保日志记录和监控到位，这不仅仅是为了在部署清单上勾选一个选项，而是为了使团队能够快速找到问题的根本原因，无论是性能问题、错误问题，还是安全问题。

对于熟练且认证的 AWS 专业人士的需求达到了历史最高点并且还在增长。通过 AWS DevOps 工程师专业认证考试，您可以立刻与他人区别开来，证明您不仅花时间和精力学习这些宝贵的技能，还通过了 AWS 专业认证这一严格的标准。

AWS 提供的认证，尤其是专业认证考试，绝非易事。行业内的从业者和招聘方都知道这一点。考试本身不仅需要耗费大约 3 小时的时间，而且还在不断更新。

这次考试有大量信息需要消化和理解。您不仅需要了解 AWS 提供的蓝图中涵盖的主题，还需要具备扎实的 AWS 知识基础，以便有效地使用这些服务。如果您有实际的工作经验，或者至少有动手实践的经验，那将大大帮助您。这也是本书中包含的练习的意义所在。它们不仅仅是一个终点，而是一个起点，帮助您构建其他项目，从而在参加考试时，能够自信地点击“开始”按钮，拥有通过认证考试所需的技能和知识，并将您的职业生涯提升到一个新的水平。

本书旨在帮助您扎实掌握 AWS DevOps 专业认证考试中涉及的服务。这通过多种方式实现。书中为许多服务提供了示例架构，帮助您可视化不同服务如何协同工作。书中还提供了大量的实践示例，帮助您了解如何在实际场景中应用这些服务。此外，还提供了不同服务的最佳使用案例和反模式示例。这些内容对于评估专业认证考试中的问题尤为重要，因为这些问题通常呈现为大型场景格式。理解某项服务在哪些场景下最为合适，在哪些场景下不适用，有助于您作出正确的选择。

最后，本书不仅是一本通过考试的学习指南，还是通过考试后日常工作中的参考指南。这就是超越的意义所在。书中提供了额外的信息，这些信息虽然不要求出现在考试中，但有意为之。我想分享一些我在与各种企业（从中小型公司到大型财富 100 强企业）在 AWS 上合作过程中积累的多年经验。

本书的目标读者

无论你在 AWS 的旅程中处于何种阶段，如果你有成为认证 DevOps 专业工程师的愿望，那么本书将帮助你理解基本概念和服务，同时考察考试大纲中涵盖的关键服务。

在开篇的章节中，我们为 AWS 世界中什么是“优秀”奠定了基础，尽管这看起来像是很多理论，但它有助于你解决考试题目中提出的许多复杂场景。书中还提供了大量的实践练习，帮助你使用一些可能不熟悉的服务，以便你在考试期间和之后都能获得信心和经验。

在每章的结尾，都有知识评估，帮助自我检查是否掌握了不仅能通过这项具有挑战性的考试，还能成功完成未来云计算领域其他任务所需的信息。

本书涵盖的内容

第一章，亚马逊 Web 服务支柱，聚焦于构成 AWS Well-Architected Framework 的基础支柱。通过理解这些支柱，你将更好地理解认证考试中所提问题的背景。

第二章，基本 AWS 服务，探讨了大量基本的 AWS 服务，了解这些服务对于继续学习后续章节至关重要。对一些已经通过初级认证考试的人来说，这可能看起来像是复习。然而，它也能作为一个快速回顾，并提供一些之前未曾了解的小技巧。

第三章，AWS 中的身份与访问管理及处理机密，聚焦于 AWS 的基本安全构建块，即通过 IAM 服务进行身份和访问管理。在简要介绍 AWS 的共享安全模型以及授权与认证的概念后，我们将回顾创建用户和用户组的过程。本章还涵盖了通过跨账户访问提供对其他账户的访问权限，并进行实际操作练习。在这一基础安全章节中，我们还会讨论其他在考试题目中可能出现的重要安全服务，如 AWS 目录服务、Secrets Manager 和 Systems Manager Parameter Store。本章还将比较 AWS 目录服务的不同版本使用场景，并讨论哪些服务更适合存储你的机密。最后，我们将介绍 Amazon Cognito，以及它如何帮助应用程序认证。

第四章，亚马逊 S3 Blob 存储，聚焦于 AWS 简单存储服务（S3）中的一个关键服务。尽管此服务易于立即开始使用，但它也具有许多功能和特性，若你打算获得 AWS 认证，必须了解这些功能和特性。

第五章，亚马逊 DynamoDB，解释了原生的 NoSQL 数据库 DynamoDB。它不仅讲解了 DynamoDB 的一些基本概念，还涉及诸如流、全球表、使用 DynamoDB 加速器，甚至使用 Web Federation 连接到 DynamoDB 表等主题。

第六章，理解 CI/CD 和软件开发生命周期（SDLC），聚焦于持续集成、持续开发和持续部署的许多理论方面。接下来，我们将介绍 SDLC，并查看哪些服务映射到 SDLC 的不同阶段。

第七章，使用 CloudFormation 模板部署工作负载，教你如何使用原生的 CloudFormation 服务来进行基础设施即代码（IaC）。首先，我们将介绍 CloudFormation 模板的基础知识，然后快速进入基本模板的变更集创建示例，接着讨论内在函数和嵌套堆栈。利用 CloudFormation 模板的知识，我们将讨论如何使用 ServiceCatalog 为开发人员和非开发人员快速便捷地提供模板设计。本章最后，我们将讨论 Cloud Development Kit，它可以用你选择的编程语言编写，然后用来创建 CloudFormation 模板。

第八章，使用 CodeCommit 和 CodeBuild 创建工作负载，引导您使用 AWS 原生工具进行软件开发生命周期（SDLC）的初步步骤。我们首先创建一个全新的用户组和用户，并为其分配一整套仅限该角色的权限。创建了初始的 CodeCommit 仓库后，我们让开发者使用 Git 将代码提交到特性分支，并请求将其合并到主分支。接下来，我们通过让 CodeBuild 服务使用 AWS CodeBuild 构建一个容器，来探讨 CodeBuild 服务。

第九章，使用 CodeDeploy 和 CodePipeline 部署工作负载，展示了如何使用原生的 AWS CodePipeline 服务创建 DevOps 管道。这一章涉及了我们之前讨论和练习过的许多服务。示例中的管道是通过 CloudFormation 模板构建的。我们之前创建的开发者用户需要扩展权限，以便查看和运行我们的管道，因此本章还包含了扩展他们 IAM 权限的练习。此外，本章还讨论了如何使用 AWS CodeDeploy 服务来部署工作负载。

第十章，使用 AWS OpsWorks 管理和部署您的应用堆栈，重点介绍了如何使用 AWS OpsWorks 服务创建堆栈和层，以便部署基础设施和应用程序。文中对不同版本的 OpsWorks 进行了比较，并附有一个练习，指导如何创建包含层和应用程序的堆栈。

第十一章，使用 Elastic Beanstalk 部署您的应用程序，详细讲解了 DevOps 专业考试中的一个关键服务——Elastic Beanstalk。使用 EB CLI 在 Elastic Beanstalk 中创建并部署应用程序，不仅能让你从开发者的角度观察事物，还能帮助你思考如何在现实世界中自动化这些任务。

第十二章，Lambda 部署与版本管理，探讨了无服务器计算的概念，并介绍了如何使用 AWS Lambda 平台进行无服务器计算。通过按需计算和按使用量计费的方式运行计算任务，可以带来显著的成本节约，这种模式正成为当今组织中越来越受欢迎的趋势。我们不仅讨论了如何部署和监控 Lambda 函数，还讨论了如何实现版本管理和别名。在本章的最后，我们还将演示如何在步骤函数中协调多个 Lambda 函数的运行。

第十三章，蓝绿部署，重点介绍了蓝绿部署策略及其不同的变种，包括哪些服务可以使用这些策略以及如何根据你使用的服务来实施不同的策略。在使用 EC2 实例和自动扩展组时，你可以采用特定的策略，而在使用 Lambda 函数时，也有其他可用的策略。本章的核心目标是确保即使在部署过程中遇到问题，你的最终用户和客户也能享受到无缝的体验。

第十四章，CloudWatch 和 X-Ray 在 DevOps 中的角色，展示了监控和日志记录在使用 AWS 原生 CloudWatch 和 X-Ray 服务中的作用。日志流和日志搜索可能是繁琐的任务，有时感觉就像在大海捞针。性能问题也同样如此。将 X-Ray 服务添加到 Lambda 应用中，可以帮助你快速定位问题所在，并知道如何解决这些问题。

第十五章，CloudWatch 指标和 Amazon EventBridge，展示了如何使用来自各个服务的指标，并将其与 Amazon EventBridge 服务结合，创建自动化的系统警报。我们讨论了哪些指标对于不同的关键服务最为有用，帮助我们保持监控。我们还演示了如何在 Amazon CloudWatch 控制台中创建仪表板。

第十六章，生成的各种日志（VPC 流日志、负载均衡器日志和 CloudTrail 日志），探讨了 AWS 服务生成的其他类型日志，这些日志并非 CloudWatch 日志。这些日志在故障排除时非常有价值，可能需要在某些或所有情况下启用。作为 DevOps 专业人员，了解如何获取这些日志以及如何搜索这些日志可能是你需要执行的任务。

第十七章，高级和企业日志场景，展示了构建和处理日志文件的现实场景和架构。这不仅包括 CloudWatch 和 CloudTrail 服务，还包括 Elasticsearch、Kinesis 和 Lambda 等服务，用于实时处理多个日志流。理解如何收集和处理大量日志文件的概念，对于现实工作中的应用和 DevOps 专业认证考试中的潜在场景都至关重要。

第十八章*,* 自动扩展和生命周期挂钩，详细讲解了自动扩展和自动扩展组的工作原理。这包括检查自动扩展生命周期和生命周期挂钩。还有一个练习，指导你创建启动模板，这是启动配置的继任者。我们还将进行实践，介绍如何在自动扩展组内删除和终止实例。

第十九章，保护静态和传输中的数据，展示了如何使用诸如密钥管理服务和 Amazon 证书管理器等服务，保护既处于静态状态又在传输中的数据。如果你使用基础设施即代码构建系统，你需要将这些关键部分集成到你的系统中，以确保从一开始就保护你的数据安全。

第二十章，使用系统管理器的角色和 AWS Config 强制执行标准和合规性，重点讲解了如何使用自动化来保持 AWS 环境的合规状态。通过使用 AWS Config 服务，你可以持续检查在 AWS 环境中创建的内容。将此与标记违规行为的规则结合使用，对于不允许的内容，可以发送警报或执行自动化的执行和修复。再加上系统管理器的功能，它可以使用运行手册自动在实例上安装软件，满足病毒扫描器等合规性需求，或进行定期的操作系统升级；这样，创建执行任务的审计日志就变得更加容易。

第二十一章，使用 Amazon Inspector 检查你的环境，演示了如何使用 Amazon Inspector 服务向你的 DevOps 生命周期添加自动化安全扫描。我们将讨论如何以自动化和手动的方式配置 Inspector 服务，然后查看和理解 Inspector 生成的不同报告。

第二十二章，其他需要了解的策略和标准服务，介绍了一些在 DevOps 专业考试中可能出现的服务，但未包含在其他章节中。这些服务包括 AWS GuardDuty、Amazon Macie 和服务器迁移服务。我们还将再次讨论 AWS Organizations 及其与服务目录服务的整合，以确保你全面了解这些服务如何协同工作。

第二十三章，DevOps 专业认证考试概述，解释了测试过程本身。它还列出了你应该与本书结合使用的额外资源，以便阅读和备考，以及一些学习技巧。

第二十四章，实践考试 1，主要是为了帮助你检查准备情况。本章展示了考试中会出现的问题，并提供了答案和解释，帮助你理解为什么选择正确答案。

为了最大程度地从本书中受益

以下领域的知识将帮助你更好地理解本书内容：

软件架构、编程语言和应用设计的知识
关系型和非关系型数据库的知识
AWS 区域和地理位置的知识
对 JSON 和 YAML 文件格式的理解
操作系统基础知识和系统命令的知识
应用程序和系统可用性的日志记录与监控知识

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/01.jpg

设置 AWS CLI 是完成本书中许多练习的必要步骤。安装 CLI 的逐步操作指南可以在 第二章，基础 AWS 服务中找到，如果你的计算机上尚未安装 CLI。

如果你正在使用本书的数字版，我们建议你自己输入代码或从书中的 GitHub 仓库访问代码（下节会提供链接）。这样可以帮助你避免因复制粘贴代码而导致的潜在错误。

下载示例代码文件

你可以从 GitHub 下载本书的示例代码文件，链接：github.com/PacktPublishing/AWS-Certified-DevOps-Engineer-Professional-Certification-and-Beyond。如果代码有更新，GitHub 仓库中的代码将会同步更新。

我们还提供了其他代码包，可以从我们丰富的书籍和视频目录中找到，链接：github.com/PacktPublishing/。快来看看吧！

下载彩色图像

我们还提供了一个 PDF 文件，包含本书中使用的截图和图表的彩色图像。你可以在此下载：static.packt-cdn.com/downloads/9781801074452_ColorImages.pdf。

使用的约定

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

文本中的代码：表示文本中的代码词、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 账号。举个例子：“你将看到用户名和密码都未加密地返回在 SecretString 字段中，供你使用。”

一段代码块的格式如下：

{
  "Project_ID": {"N": "0100"},
  "Dept": {"S": "Test Team"},
  "Dept_ID": {"N": "0001"},
  "Project_Name": {"S": "Serverless Forms"},
  "Owner": {"S": "Jerry Imoto"},
  "Builds": {"NS": ["2212121"] },
  "Language": {"S": "python" },
  "Contact": {"S": "test_team@testcompany.com" }
}

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

[default]
exten => s,1,Dial(Zap/1|30)
exten => s,2,Voicemail(u100)
exten => s,102,Voicemail(b100)
exten => i,1,Voicemail(s0)

任何命令行的输入或输出如下所示：

$ aws iam list-groups --output text
$ aws iam create-group --group-name Admins

粗体：指示新术语、重要词汇或您屏幕上看到的词语。例如，菜单或对话框中的词语显示为粗体。以下是一个示例：“您可以选择使用 SSE-S3 或您选择的**密钥管理服务（KMS）**密钥来加密报告。”

提示或重要说明

显示为这样。

保持联系

我们随时欢迎读者的反馈。

customercare@packtpub.com并在您的消息主题中提及书名。

勘误：尽管我们竭尽全力确保内容的准确性，错误偶尔还是会出现。如果您在本书中发现错误，我们将不胜感激您的报告。请访问www.packtpub.com/support/errata并填写表格。

copyright@packt.com与资料链接。

如果您有兴趣成为作者：如果您对某个专题有专业知识，并且有意撰写或为一本书作出贡献，请访问authors.packtpub.com。

分享您的想法

一旦您阅读了《AWS 认证 DevOps 工程师-专业认证及更多内容》，我们很乐意听取您的想法！请单击此处直接转到此书的亚马逊评论页面并分享您的反馈。

您的评论对我们和技术社区非常重要，将帮助我们确保提供优质内容。

第一部分：建立基础

在这一部分，我们将了解 AWS 云的基础，包括 Well-Architected Framework 的基础、安全性和存储。

本书的这一部分包括以下章节：

第一章, Amazon Web Service 支柱
第二章, 基本的 AWS 服务
第三章, AWS 中的身份与访问管理及与密钥的使用
第四章*,* Amazon S3 Blob 存储
第五章*,* Amazon DynamoDB

第一章：Amazon Web Services 支柱

DevOps 本质上是开发与运维技能的结合，并打破这两个不同团队之间的壁垒。DevOps 使开发人员能够轻松执行运维任务。DevOps 还包括赋能运维团队成员创建自己的基础设施即代码，并使用其他编码技术，如持续集成流水线，以便在多个区域快速部署相同的基础设施。

本书将介绍 DevOps 专业考试中涉及的服务和概念，以便你从实践角度，既通过讲解又通过动手练习，拥有扎实的理解。

成为 Amazon Web Services（AWS）认证工程师不仅能立即验证你所掌握和保持的技术技能，还能强化你作为技术专业人士的能力。AWS DevOps 工程师专业认证是一个累积性的考试，涵盖了 AWS 基础服务的基本知识，包括在 AWS 上运行、管理和监控工作负载的系统操作能力。这些内容还包括将代码开发并部署到函数、容器和实例。

我们将在 第二十三章 中更深入地探讨考试本身，DevOps 专业认证考试概述，并提供一些应试技巧。

AWS 支柱是指导架构师和开发人员在通用云架构和设计中普遍接受的五个指导原则。在 DevOps 专业考试中，这些支柱被间接引用，但它们及其指导方针是与任何云服务提供商合作的最佳实践的基石——尤其是 Amazon Web Services。这些原则是 DevOps 实践和流水线中的指导原则，深入理解这五个方面不仅能帮助你顺利通过考试，还能在你的 DevOps 职业生涯中提供帮助。

在本章中，我们将涵盖以下主要主题：

操作卓越
安全性
可靠性
性能效率
成本优化

服务支柱概述

一开始，你可能会想，为什么我们不直接进入 AWS、持续集成/持续交付（CI/CD）以及其他 DevOps 相关主题。主要原因是这五个支柱是考试的基础框架。此外，它们将帮助你为公司或客户提供最有效、可靠和高效的环境。这些设计原则不仅在为成功架构 Amazon Web Services 或任何云服务提供商时至关重要，而且在指导你日常工作的实践时同样适用。

一旦您熟悉了这些支柱，您会在进行认证的过程中看到它们及其主题，尤其是在获得 DevOps 专业认证时，测试问题中会涉及到操作、安全性和可靠性等特定部分。

以下是良好架构框架的五个支柱：

运营卓越
安全性
可靠性
性能效率
成本优化

将这些支柱作为指导原则，不仅用于设计在 AWS 中的工作负载，还用于改进和重构当前的工作负载。每个组织都应努力实现良好架构的应用程序和系统。因此，改进您正在处理的任何 AWS 应用程序将使您成为宝贵的资产。现在，让我们详细看看这些支柱。

运营卓越

当我们查看运营卓越支柱时，特别是在 DevOps 的背景下，这是一个——如果不是最重要的话——对于您日常职责来说最为重要的服务支柱之一。我们将从思考团队如何组织开始；毕竟，DevOps 运动的出现就是为了打破开发与运维团队之间的壁垒。

问题 – 您的团队如何确定其优先事项？

是否与客户沟通（无论是内部客户还是外部客户）？
是否从已绘制出路线图的产品负责人那里获得方向？

亚马逊概述了五个设计原则，将运营卓越融入云计算中：

将操作视为代码执行
经常精炼操作
进行小规模、频繁且可逆的更改
预见失败
从所有操作失败中学习

让我们详细看看这些操作设计原则，看看它们如何与您作为 DevOps 工程师的工作相关。随着您逐步了解这些设计原则，不仅仅是这个支柱，而是所有服务支柱，您会发现最佳实践已明确列出，辅以不同的服务，帮助您完成目标。

将操作视为代码执行

借助基础设施即代码（Infrastructure as Code）的构想，云计算使团队能够仅通过代码创建应用程序，而无需与图形界面进行交互。此外，它还允许任何底层的网络、服务、数据存储等，这些都是运行您的应用程序和工作负载所必需的。将大部分（如果不是所有）操作转移到代码中，可以为团队带来以下好处：

快速分发知识，防止团队中只有一个人能够执行某个操作
允许进行同行评审环境，并进行快速迭代
允许快速测试更改和改进，而不会干扰生产环境

在 AWS 中，你可以通过几种不同的服务执行操作代码，例如CloudFormation、Cloud Development Kit（CDK）、特定语言的软件开发工具包（SDK），或者通过使用命令行界面（CLI）。

经常精炼操作

在云端运行工作负载时，你应该处于一个持续改进的过程，不仅是应用程序和基础设施，也包括你的操作方法。采用敏捷流程的团队通常会在每个冲刺后进行回顾会议，提出三个问题：什么做得好，什么做得不好，哪些方面有改进空间？

在云端运行工作负载同样为回顾提供了机会，可以提出那些相同的三个问题。回顾不必发生在冲刺之后，但应该在以下事件之后进行：

自动化、手动或混合部署
自动化、手动或混合测试
在生产问题发生后
进行游戏日模拟

在每种情况之后，你应该能够回顾当前的操作设置，并查看哪些方面可以改进。如果你为事故或部署创建了逐步执行手册，问问自己和团队，是否有遗漏的步骤或不再需要的步骤。如果发生了生产问题，是否配置了正确的监控来排查该问题？

做小而频繁且可逆的更改

随着我们将工作负载迁移到云端，最好遵循的设计实践是将大型的单体设计拆分成更小、更解耦的组件，而不是将多个系统放在同一台服务器上。通过将组件做得更小、解耦且更易管理，可以处理更小的、更可逆的变化，以应对可能出现的问题。

逆转更改的能力也可以体现在良好的编码实践中。AWS CodeCommit 允许在代码仓库中使用 Git 标签。在每次发布部署后，通过为每个版本打标签，你可以快速重新部署以前的工作版本，以防代码库中出现问题。Lambda 也有类似的功能，称为版本。

预见故障

不要认为仅仅因为你将应用程序迁移到云端，且所依赖的服务被标记为托管服务，就不再需要担心故障。故障会发生，虽然可能不常见；然而，在经营业务时，任何形式的停机都可能导致收入损失。拥有一个应对风险的计划（并且测试该计划）实际上可能意味着保持你的服务级别协议（SLA）与不得不道歉，甚至更糟的是不得不给客户补偿或退款之间的差异。

从失败中学习

事情偶尔会失败，但当它们失败时，重要的是不要纠缠在失败中。相反，进行事后分析，并找到可以使团队和工作负载更强大和更具弹性的教训。跨团队分享学习有助于集中每个人的视角。失败后应该问并回答的一个主要问题是，问题是否可以通过自动修复来解决？

当今较大组织中的一个重要问题是，在追求伟大的过程中，它们停止了做好的努力。有时，您需要在日常事务中做好您所做的事情。这可能是通往伟大的垫脚石。然而，如果没有回顾阻碍您变得优秀的原因，永恒追求卓越有时可能只是在原地打转，而不是获得进展。

示例 – 运营卓越

让我们来看一个相关示例，展示了在环境中为实例实施自动化补丁的情况：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_1.1_B17405.jpg

图 1.1 – 运营卓越 – 自动化补丁组

如果您的环境中有需要自行管理并需要更新补丁的实例，那么您可以使用系统管理器 – 补丁管理器来帮助自动化保持操作系统的更新任务。这可以通过使用系统管理器维护任务定期完成。

初始步骤是确保安装了SSM代理（以前称为简易系统管理器）在您希望通过补丁保持更新的机器上。

接下来，您将创建一个补丁基线，其中包括在发布后几天内自动批准补丁的规则，以及已批准和已拒绝补丁的列表。

之后，您可能需要修改实例上的 IAM 角色，以确保 SSM 服务具有正确的权限。

可选地，您可以设置补丁管理组。在前面的图表中，我们可以看到我们有两种不同类型的服务器，它们都运行在相同的操作系统上。然而，它们运行不同的功能，因此我们希望为 Linux 服务器设置一个补丁组，为数据库服务器设置另一个组。数据库服务器可能只会获得关键补丁，而 Linux 服务器可能会获得关键补丁以及更新补丁。

安全

下一个是 AWS Well-Architected Framework 的安全支柱。今天，安全问题是每个人头脑中的重要问题。恶意行为者始终试图找到任何代码和基础设施（无论是在本地还是在云中）的漏洞。回顾 AWS 前 10 年的经验教训时，CTO Werner Vogels 表示保护您的客户应始终是您的首要任务…对 AWS 来说绝对如此。（Vogels，2016）

如今，确保所有云系统具有安全实践是每个人的责任。这种（保护）包括为应用程序服务的基础设施和网络组件，使用安全编码实践和数据保护，最终确保客户拥有安全的体验。

当你思考安全时，安全支柱关注四个主要领域。它们在下图中展示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_1.2_B17405.jpg

图 1.2 – 安全支柱中的四个主要安全领域

安全支柱由七个原则构成：

实施强大的身份基础
启用可追溯性
在所有层面应用安全性
自动化安全最佳实践
保护传输中和静态数据的安全
将人员远离数据
准备应对安全事件

在本书的过程中，你将找到一些针对安全支柱中介绍的安全原则的实际答案和解决方案。这将帮助你养成将安全性融入到所构建的每个部分中的肌肉记忆，而不是将自己的部分交给安全团队去担心。记住，安全是每个人的责任。最初，我们将更详细地了解这些安全原则。

实施强大的身份基础

在建立强大的身份基础时，一切从实现最小权限原则开始。任何用户或角色的权限都不应多于或少于执行其工作或职责所需的权限。如果进一步深化这个概念，如果你使用 IAM 来管理用户，那么请确保密码策略到位，以确认密码定期轮换，避免密码变得过时。检查 IAM 密码策略与公司密码策略是否一致也是一个好主意。

此外，随着组织的成长和用户与权限管理变得更加复杂，你应考虑建立集中身份管理，使用 Amazon 单点登录或连接公司 Active Directory 服务器。

启用可追溯性

安全事件可能会让你处于被动应对的状态；然而，你的反应能力取决于你能够收集到多少关于该事件的信息。在事件发生之前，建立适当的监控、日志记录、警报以及审计环境和系统的能力，对于在需要时能够执行正确的评估和步骤至关重要。

从多个来源捕获足够的日志可以通过 AWS 服务来实现，例如 CloudWatch Logs、VPC Flow Logs、CloudTrail 等。在本书的第三部分，我们将详细探讨日志记录和监控，因为它们对于 DevOps 专业认证考试非常重要。

考虑以下场景：

有人通过弱密码获得了服务器访问权限并且破坏了一些数据。你认为你当前收集了很多日志；然而，你能弄清楚以下问题吗？

用于访问系统的用户名
用于访问源的 IP 地址
访问开始的时间
被更改、修改或删除的记录
受影响的系统数量

在所有层级应用安全措施

保护环境中的所有层级有助于通过为你的行为提供更广泛的覆盖来提高安全性。为了应对网络级别的安全，可以使用简单的技术，如安全组和网络 ACL 来保护不同的 VPC。经验丰富的 AWS 专业人士知道，额外的安全层会扩展安全防护的范围——例如，在边缘（AWS 云的网络接入点）、操作系统级别，甚至通过向左偏移来保护应用程序代码本身。

自动化安全最佳实践

随着你和你的团队在云端安全实践方面的教育不断深入，重复性的任务应该被自动化。这可以让你更快速地响应正在发生的事件，甚至在你没有意识到事件发生时也能作出反应。

这是你开始深入学习时需要关注的话题。作为一名 DevOps 专家，你习惯于将重复的手动流程通过自动化来提高效率。自动化可以表现为自动分析日志、删除或修复不符合组织安全政策的资源，或智能地检测威胁。

亚马逊 Web 服务推出了一些工具来帮助这一过程，包括 GuardDuty、CloudWatch、EventHub 和 AWS Config。

保护传输中和静态存储的数据

坏意图的攻击者无处不在，他们不断寻找可以被利用的、在互联网上未加保护的数据。你绝对不能依赖最终用户使用最佳实践，如通过 VPN 进行安全通信，因此，这项工作需要由你和你的团队在服务器端实施最佳实践。诸如在负载均衡器、CloudFront 分发上，甚至在服务器层面实施证书等基本操作，可以确保数据在传输过程中进行加密，从而实现端到端的安全传输。

同理，打个比方，确保通过启用传输层安全协议（TLS）或 IPsec 协议来验证网络通信，有助于确保网络通信的认证。

AWS 提供了一些服务来帮助保护你的数据，无论是在传输中还是静态存储中，例如 AWS 证书管理器、AWS Shield、AWS Web 应用防火墙（即另一个WAF）以及 Amazon CloudFront。密钥管理服务（KMS）也可以帮助保护静态存储的数据，允许你轻松创建、使用和轮换加密密钥。

要深入了解如何保护传输中和静态数据，请参阅第十九章，保护传输和静态数据。

使用机制将人员与数据隔离

有多种方法可以自动化数据访问，而不是允许个人直接访问数据。通过变更控制过程验证的项目通常是一个更好的选择。这些项目可以是系统管理运行手册或 Lambda 函数，负责访问数据。与此相对的是允许通过堡垒主机或弹性 IP 地址/CNAME 直接访问数据源。

提供这种直接访问可能导致人为错误或用户名和密码被泄露，最终导致数据丢失或泄露。

为安全事件做准备

即使您执行了前面描述的所有安全原则，也不能保证未来不会发生安全事件。您最好通过练习并准备一套快速执行的步骤，以防万一。

您可能需要创建一个或多个运行手册或操作手册，列出如何执行任务的步骤，例如拍摄 AMI 快照进行取证分析并将其转移到安全账户（如果有的话）。当这些步骤变得必要时，会有来自不同地方的问题。这些答案将有时间方面的要求。如果负责执行这些任务的团队从未进行过这些任务的练习，也没有为他们制定指南，那么宝贵的时间将被浪费，仅仅是为了组织和安排。

以下是 AWS 与您（客户）之间的共享责任模型：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_1.3_B17405.jpg

图 1.3 – AWS 共享责任模型

提问问题

如何保护您的根账户？

根账户上是否有多因素认证（MFA）设备？
根账户是否未被使用？

如何分配 IAM 用户和组？
如何委派 API/CLI 访问权限？

接下来，让我们了解云端可靠性的五个设计原则。

可靠性

云端可靠性设计有五个原则：

自动化故障恢复
测试恢复程序
横向扩展以提高整体工作负载的可用性
停止猜测容量
管理自动化中的变更

自动化从故障中恢复

当你想到自动化故障恢复时，大多数人首先想到的是技术解决方案。然而，这不一定是可靠性服务支柱中所指的上下文。这些故障点应该是基于业务设定的关键绩效指标（KPIs）。

作为恢复过程的一部分，了解组织或工作负载的恢复时间目标（RTO）和恢复点目标（RPO）非常重要。

RTO（恢复时间目标）：服务中断和恢复之间可以接受的最大延迟时间
RPO（恢复点目标）：自上次数据恢复点（备份）以来可接受的最大时间（亚马逊网络服务，2021 年）

测试恢复程序

在你的云环境中，你不仅应该测试工作负载是否能正常运行，还应测试它们是否能够从单个或多个组件故障中恢复，特别是在服务、可用区或区域层面发生故障时。

通过使用基础设施即代码、持续集成（CD）流水线和区域备份等实践，你可以快速启动一个全新的环境。这可以包括你的应用程序和基础设施层，能够让你测试其是否与当前生产环境中的工作方式相同，并且数据是否正确恢复。你还可以记录恢复所需的时间，并通过自动化恢复时间来改进它。

主动记录运行手册或操作手册中每一个必要步骤，可以促进知识共享，并减少对构建系统和流程的特定团队成员的依赖。

水平扩展以提高工作负载可用性

从数据中心环境过渡时，规划峰值容量意味着找到一台可以运行应用程序所有不同组件的机器。一旦达到该机器的最大资源，就需要迁移到更大的机器。

当你从开发环境迁移到生产环境，或者当你的产品或服务的受欢迎程度增长时，你需要扩展资源。实现这一点的主要方法有两种：垂直扩展或水平扩展：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_1.4_B17405.jpg

图 1.4 – 水平扩展与垂直扩展

垂直扩展的主要问题之一是你会在某个时刻碰到瓶颈，必须不断迁移到更大的实例。最终，你会发现没有更大的实例可以迁移，或者更大的实例运行成本太高，无法负担。

另一方面，水平扩展使你能够以成本效益的方式，在需要时获得所需的容量。

采用云思维意味着将应用程序组件解耦，将多个相同的服务器组放在负载均衡器后面，或从队列中拉取并根据当前需求进行最优的上下扩展。

停止猜测容量

如果资源被压垮，它们往往会发生故障，尤其是在本地部署时，当需求激增，而这些资源没有能力向上或向外扩展以满足需求时。

有一些服务限制需要注意，尽管它们中的许多被称为软限制。这些限制可以通过简单的请求或打电话给支持团队来提高。还有一些被称为硬限制。它们是为每个账户设置的固定数字，无法提高。

注意

虽然没有必要记住所有这些限制，但熟悉它们并了解其中的一些限制是个好主意，因为它们有时会出现在一些测试问题中——并不是作为直接问题，而是作为情景的背景。

自动化中的变更管理

虽然手动更改基础设施（或应用程序）似乎更容易且有时更快捷，但这可能导致基础设施漂移，并且无法重复操作。最佳实践是通过基础设施即代码、代码版本控制系统和部署管道自动化所有更改。这样，所有更改都可以被追踪和审查。

性能效率

如果你和你的架构设计团队来自数据中心基础设施，并且配置过程需要几周或几个月才能获得所需的系统，那么云资源的快速性和可用性无疑是一次清新的体验。需要了解如何根据工作负载需求选择正确的实例类型或计算选项（即基于服务器、容器化或基于函数的计算）。

一旦你做出了初步选择，就应该进行基准测试，以查看你是否充分利用了分配的所有 CPU 和内存资源，并确认工作负载是否能处理它所需执行的任务。在选择实例类型时，不要忘记考虑成本，并记录那些可能节省你资金或在基准测试过程中让你花费更多的成本差异。

AWS 提供了本地工具来创建、部署和监控基准测试，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_1.5_B17405.jpg

图 1.5 – 使用 AWS 工具进行基准测试

使用 AWS 提供的工具，你可以快速启动一个环境来进行资源适配、基准测试和负载测试，检查你为计算实例选择的初始值是否合适。你还可以轻松地更换其他实例类型，查看它们在相同测试下的性能表现。通过使用 CloudFormation 构建基础设施，你可以以快速且重复的方式运行测试，使用 CodeBuild 进行测试，同时通过 CloudWatch 收集度量数据，比较结果，确保你做出了最佳决策，并有数据支持这一决策。在 第七章中，我们将更详细地讨论如何使用 CodeBuild，[使用 CloudFormation 模板部署工作负载]。

性能效率 支柱包括五个设计原则，帮助你在云中保持高效的工作负载：

让先进技术更易于为你的团队实现
能够在几分钟内实现全球化
使用无服务器架构
允许你的团队进行实验
使用与你目标一致的技术

让先进技术更易于为你的团队实现

随着托管服务的出现，云计算简化了使用先进技术的过程。你不再需要聘请全职数据库管理员来专门处理不同类型的数据库，以测试 Postgres 或 MariaDB 哪个更优化地运行。类似地，如果你需要该数据库的复制，只需勾选一个框，你就能立即获得高可用的设置。

过去需要花费时间在文档上，努力搞清楚如何安装和配置特定系统，现在这些时间可以用来专注于最重要的事情——为你的客户和业务提供价值。

能够在几分钟内实现全球化

根据你运行的应用程序或服务，客户可能会集中在一个地区，或者分布在全球各地。一旦你将基础设施转化为代码，通过 CloudFormation 模板或 CDK 中的构造，你可以利用区域参数快速重用之前构建的模式或架构，并将其部署到世界的其他地区。

即使没有部署完整的应用程序和架构，依然有能力利用内容分发网络（CDN）CloudFront 来服务全球用户。在这里，你可以使用应用程序创建安全的全球存在，或者在主要区域（即原始区域）部署内容。

使用无服务器架构

首先，迁移到无服务器架构意味着不再需要管理服务器。这意味着不再需要在启动时配置带有软件包的服务器，不再需要调整服务器大小，也不再需要修补服务器。

无服务器架构意味着你已经解耦了应用程序。无论是使用函数、事件还是微服务，每个组件都应该执行特定的任务。每个组件只处理其独特任务时，你可以在任务级别微调内存和使用 CPU，并在特定任务级别进行扩展。

这并不是每个工作负载的最佳选择，但不要仅仅因为某个工作负载需要进行少量重构就将其排除。当应用程序可以迁移到无服务器架构时，它可以让生活更轻松，使应用程序本身更加高效，通常还会带来成本节省——特别是在长期看来。

允许你的团队进行实验

一旦你迁移到云端，你可以迅速且持续地重构你的工作负载，以提高性能和降低成本。如果你已经将基础设施构建为代码，那么为测试创建一个新的临时环境可以是一个快速且成本高效的方式，尝试你应用程序中的新模块，而无需担心会影响到任何客户或组织的其他部分。

许多实验可能不会成功，但这就是实验的本质。如今的商业竞争异常激烈，找到一个有效的解决方案，使你的服务更快、更便宜、更好，可能会成为真正的游戏规则改变者。

使用与工作负载目标对齐的技术

列出你的业务目标，并让产品负责人根据这些目标帮助推动产品和服务的选择。如果开发团队对某些技术已有一定了解，他们可能会倾向于使用那些他们已经自信的技术。

另一方面，还有一些团队力求使用最新的技术，但这并不一定是因为这些技术解决了已识别的问题。相反，他们的兴趣在于不断丰富简历，确保能够尽早接触并体验到最前沿的服务。

成本优化

许多人误以为迁移到云端会立即为他们的公司或组织带来成本节约。一旦没有严格的控制措施或无法将工作负载分摊给相关团队时，现实就显现了出来，越来越多的团队发现，配置新资源就像按一个按钮一样简单。一旦账单开始出现，大部分情况下，来自高层的成本削减运动就会随之而来。

在你着手优化成本时，要理解那些已被证明是托管服务的云服务，每分钟的费用较高；然而，人力资源成本却要低得多。你无需关心和维护底层服务器，也不需要担心更新底层操作系统。许多服务允许你根据用户需求进行扩展，这些都会自动为你处理。

监控成本和使用情况的能力也是成本优化策略的关键要素之一。拥有一个合理的资源标签策略，可以使负责财务管理 AWS 账户的人进行正确部门的费用分摊。

云中的成本优化有五项设计原则：

实施云财务管理
采用消费模型
衡量整体效率
停止为无差异的大量基础设施工作付费
分析和归因支出

实施云财务管理

云财务管理正在各大组织中迅速发展，无论大小。它需要一个专门的团队（或者一组部分负责此任务的团队成员）来建立一个系统，能够看到云支出的去向。该团队会查看费用使用报告，设置预算警报，跟踪开支，并希望能够执行一个计费标签，以展示每个部门、成本中心或项目的费用分摊。

什么是费用分摊？

IT 费用分摊是一种流程，允许各个部门将费用与特定的部门、办公室或项目关联，从而准确跟踪 IT 支出。我们在此示例中具体指的是云支出，但 IT 费用分摊也应用于 IT 的其他领域，例如会计目的。

采用消费模型

使用云并不需要复杂的预测模型来控制成本，尤其是在有多个环境的情况下。开发和测试环境应该能够在不使用时关闭或暂停，从而节省空闲时的费用。这就是云端按需定价的魅力。如果开发人员因数据丢失而抱怨，那么可以教他们在关闭之前使用快照功能备份数据库实例；这样，他们就可以从中断的地方继续开发。

一个更好的策略是自动化在工作日结束时关闭开发和测试环境的过程，并要求使用专门的标签，这样可以防止实例在下班后或周末被关闭。你还可以自动化在工作日开始前 30 到 60 分钟重启实例的过程，以便操作系统有足够的时间启动，确保团队认为它们根本没有被关闭过。只需要注意，任何运行在实例存储上的 EC2 实例可能会丢失数据。

衡量整体效率

组织在云预算方面失去效率的最明显方式之一就是忽视停用未使用的资产。虽然在云中启动新服务和创建备份较为容易，但如果没有计划将折旧的数据、卷备份、机器镜像、日志文件和其他物品进行退役，这将增加每月账单的底线。这应该用手术刀而非砍刀进行。数据一旦删除，就无法恢复；然而，并不需要将所有东西永远保存。即使是合规要求，也有一个渐退期，数据可以以更合理的价格存储在冷存储中。

一个完美的例子是 EBS 快照。试图主动保护数据的客户可能每天多次对卷进行快照，并将这些快照复制到灾难恢复区域。如果在 30 天、60 天或 90 天后没有办法使旧的快照失效，那么这个成本中心项可能很快就会成为一个问题。

停止在无差异的重型工作上花费资金。

当我们谈论重型工作时，我们指的是在数据中心中架设、堆叠和冷却服务器。运营数据中心是一项 24 小时全天候、365 天的工作，而当你不使用这些机器和存储时，不能轻易关闭它们。将工作负载迁移到云端，减轻了团队成员对数据中心运营的负担，使他们可以将更多时间和精力投入到关注客户需求和功能上，而不是照料和管理服务器及硬件。

分析和归因支出

云计算——尤其是 AWS 云——提供了帮助你分析和参考账户费用来源的工具。工具箱中的第一个工具是标签和标签策略。一旦你决定了一个稳定的基础标签集，包括成本中心、部门和应用等内容，你就为其余可用工具奠定了基础。

通过使用 AWS Organizations 从单一账户结构扩展到多个账户和组织单元，可以在不使用账户级别标签的情况下自动分类支出。

AWS 成本探索器允许你的财务管理团队深入分析费用发生的服务和区域，并能够创建自动化仪表板，快速可视化支出。亚马逊网络服务还设定了预设的服务配额，其中一些是不可更改的硬性配额，但许多则是允许你通过简单请求增加特定服务数量（在某个区域内）的软性配额。

总体服务支柱原则

《良好架构框架》识别了一套通用设计原则，旨在促进云端的良好设计：

在完整生产规模下测试系统。
自动化尽可能多的组件，使实验尽可能简单。
使用数据驱动架构设计。
停止猜测容量需求。
允许架构随着新技术和服务的出现而不断演进。
利用游戏日推动团队改进。

在你思考这些服务原则并如何将它们付诸实践时，要意识到有时候这些原则可能会感觉相互矛盾。最明显的例子是成本优化支柱。如果这是你所在的组织最关注的支柱，其他支柱可能会影响纯粹的成本节约。加强你在可靠性支柱中发现的弱点，通常意味着更多的资产，而资产意味着更多的资金。然而，你仍然可以努力使这些资产尽可能具有成本效益，从而符合所有支柱的要求。

总结

在本章中，我们学习了指导架构师和开发人员设计良好的五个服务原则。我们讨论了这些原则是如何成为 DevOps 专业考试中的测试问题的基础主题，以及掌握这些基础知识在你确定正确答案时如何帮助你。我们在讨论每个服务支柱时，也讨论了它们的基础设计原则。

我们简要提到了一些不同的 AWS 服务，以及哪些服务支柱或设计原则在特定服务中发挥作用。在下一章中，我们将学习贯穿于你将要工作中的环境和账户的基本 AWS 服务。

复习题

Well-Architected 框架的五个支柱是什么？
安全在云中的五个主要领域是什么？
性能效率支柱包含的四个领域是什么？
可靠性支柱包含的三个领域是什么？
RTO 的定义是什么？
RPO 的定义是什么？

复习答案

Cost Optimization, Reliability, Operational Excellence, Performance Efficiency, 和 Security。（使用助记符CROPS帮助记住这五个支柱，每个支柱的首字母分别是 C、R、O、P、S。）
数据保护、基础设施保护、权限管理、事件响应和侦测控制。
计算、存储、数据库和网络。
基础、变更管理和故障管理。
恢复时间目标 – 中断服务和恢复服务之间可接受的最大延迟。
恢复点目标 – 自上次数据恢复点（备份）以来可接受的最大时间间隔。

深入阅读

以下是推荐的论文和资源列表，供进一步阅读：

AWS Well-Architected 白皮书: d1.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf
成本优化白皮书: docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/wellarchitected-cost-optimization-pillar.pdf
可靠性白皮书：docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/wellarchitected-reliability-pillar.pdf#welcome
操作卓越白皮书：docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/wellarchitected-operational-excellence-pillar.pdf
性能效率白皮书：docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/wellarchitected-performance-efficiency-pillar.pdf#welcome
安全白皮书：docs.aws.amazon.com/wellarchitected/latest/security-pillar/wellarchitected-security-pillar.pdf
计算系统总可用性：

www.delaat.net/rp/2013-2014/p17/report.pdf
Well-Architected 实验室：

www.wellarchitectedlabs.com/
AWS Well-Architected 框架支柱：

wa.aws.amazon.com/wat.pillars.wa-pillars.en.html
10 年 AWS 经验的 10 个教训：www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html

第二章：基础 AWS 服务

现在我们已经了解了构成最佳实践的服务原则和支柱，这些内容构成了使用Amazon Web Services（AWS）时的基本框架，是时候来看一些你将在环境和账户中使用的基础服务了。我们提到的基础服务包括计算服务，如弹性云计算（EC2）、全球域名系统（DNS）服务Route 53、数据库服务，如RDS和Aurora，以及咨询服务Trusted Advisor。如果你已经参加过云从业者、SysOps 或开发者考试，这些服务可能会让你感觉像是在复习已知内容。然而，由于现在没有要求在参加（并通过）DevOps 专业考试之前必须通过任何较低级别的关联考试，因此对一些基本服务进行复习也是一个不错的选择。

本章并不打算全面介绍这些服务。所提到的服务将被引入到 DevOps 考试的背景中，因此不建议跳过本章。不过，如果你认为自己对这些话题有很强的掌握，可以通过检查复习题和参考资料来验证这一点。同样，你也可以复习任何你已经掌握的主题。

在本章中，我们将覆盖以下主要内容：

设置和访问你的 AWS 账户
虚拟私有云网络和 Route 53 网络
云数据库
消息和队列系统
Trusted Advisor

技术要求

你需要一个 AWS 账户才能访问管理控制台和 CLI，这些内容将在本章的初始部分提到。如果你需要创建账户的帮助，访问aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/页面，它将指导你完成创建新账户的步骤。还需要具备基本的终端使用知识，以便完成 shell 命令。

重要提示

在本书中，我们不会详细讨论 AWS 的地理位置、区域、可用区或边缘位置。这些是你在尝试 DevOps 考试之前应该牢牢掌握的基本概念。

设置和访问你的 AWS 账户

在这一点上，你很可能已经拥有一个 AWS 账户来进行操作；然而，你可能只能通过你的工作场所访问该账户，其中一些权限被限制，因此你无法练习所有你需要掌握的技能，以便自信地通过 DevOps 专业考试。

如果您尚未为测试设置个人账户，那么现在是设置一个账户的完美时机。即使您已经有一个账户，您可能希望花时间设置一个新账户，专门用于考试，以确保您能够在提供的服务中利用首年的免费套餐（在 AWS 上分配）。

如果您已经拥有账户，转换到 AWS 组织 特别是使用控制塔，是一个很好的练习，如果您希望创建服务控制策略、组织单位、单点登录（SSO）和跨账户角色。

重要提示

控制塔需要至少三个不同的电子邮件账户来启动创建的三个独立账户。

创建主账户后，您可以向之前创建的账户发送邀请，并允许其加入组织。

进入 AWS 管理控制台

AWS 管理控制台是访问您的 AWS 账户的前门（GUI）。

首先打开任何网页浏览器并访问 aws.amazon.com/。

在起始页面上，查找 我的账户 菜单项。将鼠标悬停在此菜单项上，应该会给您选择 AWS 管理控制台 的选项：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.2_B17405.jpg

图 2.2 - 创建我们的用户

然后我们可以点击下一步，继续设置权限。
在设置权限下，我们要选择直接附加现有策略。
对于这个初始用户，我们将使用AdministratorAccess职位功能策略。选择此策略，使左侧的框被选中，然后点击底部的下一步：标签按钮：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.3_B17405.jpg

图 2.3 - 附加策略
只需点击底部的下一步：审查按钮。
如果一切看起来正常，点击底部的蓝色按钮，标记为创建用户。
因为我们已经选择了程序访问权限，所以一旦我们创建了用户，就会有机会查看秘密访问密钥，并下载访问密钥和秘密密钥对的 CSV 文件。请记下此用户的秘密密钥，或下载该文件，因为这是唯一一次可以获取秘密访问密钥的机会。

到此为止，我们已经设置了第一个用户及其访问策略、密码、访问密钥和秘密密钥。在本书的其他练习中，我们将引用此用户。你可以自由设置任何你喜欢的用户名，但对于一个不使用 root 账户的管理用户账户，我们将使用devops用户。

设置和使用 AWS CLI v2

你确实可以使用基于图形的 Web 界面管理控制台执行大多数任务。作为 DevOps 工程师，你会希望在环境中自动化一些操作，CLI 通过一系列脚本功能赋予你这种能力。CLI 是许多人最喜爱的工具之一，因其速度和强大的功能。

以前 CLI v1 用户注意

如果你之前安装过 AWS CLI v1，强烈建议你在安装 CLI v2 之前先卸载 v1。两个 CLI 命令都使用相同的命令名称aws。如果你不想卸载 CLI v1，那么可以在你的路径中设置别名。

Mac 设置

只要你的机器上有 sudo 权限，你就可以轻松使用捆绑安装程序在 Mac 上安装 AWS CLI v2：

打开终端窗口。

运行以下两条命令来安装 AWS CLI：

$ curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
$ sudo installer -pkg AWSCLIV2.pkg -target /

通过运行以下命令来检查是否已安装正确版本：
```
$ aws --version 
```
输出应该类似于以下内容：
```
aws-cli/2.1.29 Python/3.8.8 Darwin/18.7.0 exe/x_86_64
```

只要cli后面的数字以2开头，你就成功安装了 AWS CLI v2。

现在你可以跳到配置 CLI 的部分。

PC 设置

PC 用户注意

要运行 CLI v2，你的 Windows XP 或更高版本操作系统必须是 64 位版本。

如果您有在计算机上安装软件的管理权限，您可以按照以下说明安装 AWS CLI v2：

下载适用于 Windows 的 AWS CLI MSI 安装程序：awscli.amazonaws.com/AWSCLIV2.msi。
运行下载的 MSI 安装程序并按照屏幕上的指示进行操作。
通过运行以下命令确认是否已安装正确的版本：
```
C:\> aws --version 
```

Linux 设置

在 Linux 机器上安装 CLI v2 之前，需要先处理一些先决条件：

您需要具备解压软件包的能力，可以使用系统的 unzip 命令或其他已安装的软件包。
为了确保 AWS CLI v2 正常运行，您需要确保在发行版中已安装 glibc、groff 和 less 软件包。大多数主要发行版默认已安装这些软件包。
AWS 支持在更新的 64 位版本的 CentOS、Fedora、Ubuntu、Amazon Linux 1 和 Amazon Linux 2 上使用 AWS CLI v2\。

现在先决条件已满足，您可以按照以下说明安装 CLI：

运行以下 curl 命令以下载 AWS CLI v2 的 ZIP 文件：

$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ sudo installer -pkg AWSCLIV2.pkg -target /

现在 ZIP 文件已下载，我们可以解压它：
```
$ unzip awscliv2.zip 
```
解压后，我们可以运行 install 程序：
```
$ sudo ./aws/install
```
通过运行以下命令检查是否已安装正确的版本：
```
$ aws --version 
```

输出应类似于以下内容：

aws-cli/2.1.29 Python/3.8.8 Linux/4.14.133-133.105.amzn2.x86_64 botocore/2.0.0

设置 CLI 的参考资料可以在 AWS 的文档中找到：docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html。

配置 CLI

安装 CLI 后，建议进行配置。如果您曾安装过 CLI v1 并使用过配置文件，您应该可以继续使用这些配置文件。为了快速配置 CLI，您可以使用 aws configure 命令；不过，作为先决条件，最好事先在 IAM 中为您的用户创建并下载密钥和秘密密钥。如果您要配置默认配置文件或辅助配置文件用于本书中的示例，您将需要这对凭证。

如果您尚未操作，请通过管理控制台重新登录 AWS 账户，然后导航至 IAM 服务，创建一个用户和角色。使用该用户，您可以分配 访问密钥 ID 和 秘密密钥 ID，并将其输入 CLI 中，以便在本书中的教程中使用。

获得密钥对后，按照以下步骤配置 CLI：

运行 aws configure 命令：
```
$ aws configure 
```
当提示时，剪切并粘贴访问密钥 ID。
当提示时，剪切并粘贴秘密密钥 ID。
当提示时，为示例设置默认区域（我们将使用 us-east-2）。
您可以直接按 Enter 键退出并使用默认的 JSON 输出；然而，我发现将输出设置为表格形式会更易于用户阅读。

在本书的许多示例中，CLI 命令将会添加一个 profile。

AWS 中的云计算

当我们谈论 AWS 中的计算时，我们指的是多个服务，包括 Amazon EC2、弹性负载均衡（Elastic Load Balancing）、AWS 批处理（AWS Batch）、弹性容器服务（Elastic Container Service）和弹性 Kubernetes 服务（Elastic Kubernetes Service），以及 AWS Fargate 这项托管服务，它允许你以最小的开销运行容器。它甚至包括 Lightsail，这是开发人员在云中快速启动的最快方式，无需配置软件或网络：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.4_B17405.jpg

图 2.4 – AWS 中的计算服务

虽然 AWS 中有许多服务属于计算服务的范畴，但最基础的服务是 EC2。EC2 是你在 Amazon 云中的虚拟实例。尽管其他服务，如弹性容器服务（Elastic Container Service）、弹性 Kubernetes 服务（Elastic Kubernetes Service），甚至 Elastic Beanstalk，都可以让你在 AWS 中运行容器，但它们的核心仍然是运行在 EC2 实例上。因此，了解 EC2 服务的基础知识，例如如何选择正确的实例类型，如何使用最优的负载均衡器（因为有三种可供选择），以及如何将存储卷添加到实例中，这些都是相对的信息，无论是处理 DevOps 专业考试问题，还是作为专业人士在日常工作中的任务：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.5_B17405.jpg

图 2.5 – EC2 在实际架构中的应用

在前面的图示中，我们可以看到一个实际场景，其中 EC2 实例被用于自动扩展组中，以支持 WebSphere 平台。多个 EC2 实例位于一个私有子网中，外部用户只能通过 Route 53 中的 DNS 记录，通过应用负载均衡器访问这些实例。如果内部用户需要访问 WebSphere 服务器中的任何一个，可以通过位于公共子网中的堡垒主机使用 SSH 协议进行访问。堡垒主机位于一个跨越两个可用区的自动扩展组中，但每次只有一个主机处于活动状态。

现在我们将更详细地了解这些服务，特别是 EC2 服务。

亚马逊弹性云计算（EC2）

亚马逊 EC2 允许你创建一个虚拟服务器，在云中执行多个任务。EC2 提供了广泛的定制选项。你可以选择多种操作系统，以满足应用需求。适当配置内存和处理能力只需根据工作负载的需求选择合适的实例类型即可。

EC2 还提供三种不同的定价模式，每种模式都可以根据需求提供灵活性或折扣。它们分别是按需实例、预留实例和竞价实例。

按需实例是默认的实例类型，在请求 EC2 计算实例时无需长期承诺。你可以自行决定何时启动、停止、休眠、启动或终止实例，并且不会有任何后果。从定价的角度来看，你只需为处于运行中状态的按需实例按秒计费。

如果你有已知的工作负载将在 EC2 上持续运行一年，或需要在特定可用区内的预定容量，那么预留实例可以提供成本节省，并且在该特定可用区内提供预留容量。预留实例有两种不同的承诺期限，分别为 1 年和 3 年，后者在长期承诺下提供更大的节省。

当 AWS 有多余的容量未被利用时，这些实例会作为竞价实例以大幅折扣提供。不同类型实例的供需情况会导致价格波动，有时波动较快。这些折扣可以达到正常按需定价的 80%；然而，这也有一些限制。首先，你必须立即启动实例，并且不能停止或休眠竞价实例。在启动竞价实例时，你需要设置一个最大价格，例如当前的按需价格，如果价格超过你设置的最大价格，AWS 会发出信号，给你 2 分钟的时间保存工作，然后实例会被终止。

EC2 实例类型

在写本文时，已有超过 170 种实例类型，允许你根据任何想要在云中运行的工作负载定制计算需求。并不重要的是记住所有不同类型和大小的实例，以及它们的计算和内存规格。然而，了解 EC2 在工作负载特定性方面如何划分不同的类别，以及哪些 EC2 系列属于这些类别，是一个好主意。

注意

只有部分 EC2 实例支持增强型网络，这可能成为选择正确实例类型时的决定性因素。增强型网络功能在处理故障排除或工作负载时尤其重要，因为它支持更高的带宽和每秒更多的数据包。

由于有许多类型的工作负载正在迁移到云中，每种工作负载都有其特定的需求，AWS 创建了几个不同的 EC2 实例系列。每个系列包含一种或多种实例类型，并具有优先应用程序配置文件。

这些实例系列可以按以下方式进行分组：

通用型实例
计算优化型实例
内存优化型实例
加速计算实例
存储优化型实例

让我们更详细地看看这些内容。

通用型实例

通用型实例平衡内存、计算和网络资源，是各种工作负载的理想选择。这包括 T 类实例，这些实例具有可积累的突发信用点。若你没有完整的工作负载分类，通用型实例是一个很好的起点。

使用案例：Web 服务器、开发和测试服务器、代码库、小型到中型数据库以及 SAP 后台服务器。

计算优化实例

计算优化实例专为从高性能处理器中获益的工作负载量身定制。该系列中的实例还具备增强网络功能，并默认优化为弹性块存储（EBS）。

使用案例：批处理、视频编码、广告投放、分布式分析、基于 CPU 的机器学习、游戏、科学建模以及高性能科学与工程应用，如基因组分析或计算流体动力学。

内存优化实例

这一系列实例，顾名思义，是为内存密集型应用而设计的。它们旨在为需要大量内存的任务提供快速的性能能力。

使用案例：开源数据库、内存缓存和实时分析。

加速计算实例

加速计算实例包含协处理器或硬件加速器，这些加速器比其他处理器执行特定功能的效率更高。这些功能可能包括数据模式匹配、浮点数计算和图形处理。

使用案例：语音识别、高性能计算、药物发现、计算金融和自动驾驶汽车。

存储优化实例

存储优化实例提供直接连接的存储选项，能够满足特定的存储需求。这意味着实例存储可以针对非常定制化的输入和输出（I/O）性能进行优化，例如 H1 实例，或者在高存储（HS）实例的情况下提供非常高的存储密度。

使用案例：NoSQL 数据库、数据仓库、Elasticsearch、内存数据库、传统数据库和分析工作负载。

实例由两种存储类型支持：实例存储和 EBS。在选择实例类型时，系统会显示该实例是由 EBS 还是实例存储支持。这两种存储类型之间存在一些重要区别，尤其是在持久性方面。实例存储的一个主要优势是其高 I/O 和吞吐量。这是因为它直接连接到实例。基于实例存储的卷的缺点则在于持久性。如果你重新启动一个由实例存储支持的 EC2 实例，所有临时数据，如日志和临时文件，将会丢失。基于 EBS 的实例则不同，因为存储并未直接连接到实例。

了解 Amazon 机器镜像（AMI）

每当您启动 EC2 实例时，它必须从Amazon 机器镜像（AMI）启动，以便包含启动所需的信息。这些可以是基础操作系统镜像，实际上是干净的起点。或者，它们也可以是您或其他实体创建的 AMI，作为一个有效的工作系统或在单个实例上运行的多个系统的检查点。

AMI 可以由 Amazon 本身提供，由您的用户账户提供，私下与您的其他账户共享，或者来自合作伙伴账户，由社区成员创建，甚至可以在 AWS Marketplace 上免费或按小时收费提供。

AMI 的使用案例

您可以创建自己的 AMI，用于自动伸缩组或加速启动需要多个步骤下载、安装和配置软件的复杂实例。

也有一种情况是组织中的基础镜像，预先批准了操作系统，并为所有用户预装了安全设置以便遵循。

有可用的社区 AMI；然而，使用这些 AMI 时需要自行承担风险，因为它们上面可能已安装了未知的软件包。

另一种选择是使用由供应商和合作伙伴提供的市场 AMI，这些 AMI 已经经过验证并预先配置了已知的软件。这些 AMI 通常会在运行实例时收取每小时额外费用。

备份 Amazon EC2 实例

如果您想备份您的实例，无论是为了时间点恢复的目的，还是为了在自动伸缩配置中使用它，那么您需要创建一个 AMI：

首先，我们必须借助 Systems Manager 服务找到最新版本的 Amazon Linux2 AMI，并将其存储到变量中以便下一步使用：

$IMAGE='aws ssm get-parameters --names /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 --query 'Parameters[0].[Value]' --output text --region us-east-2'

启动 EC2 实例。现在我们知道了要使用的基础 AMI 的最新版本，我们需要有一个实例来进行备份并创建自定义 AMI：
```
i-02666d4b05eee61c1.Create the AMI as a backup: 
```
ImageId 值：
```
{
    "ImageId": "ami-0aa7408c42669e27b"
}
```

验证镜像：

State. If the value says available, then you have successfully backed up your EC2 instance and are ready to test.

让我们测试一下我们的备份。

在这里，我们将回到我们在步骤 2中用于创建实例的原始命令，但现在，我们将用我们刚刚创建的 AMI 替换原始的镜像 ID：
```
$aws ec2 run-instances \
--image-id ami-0aa7408c42669e27b \
--instance-type t2.micro \
--region us-east-2
```

正如您所看到的，借助几个简单的命令，我们不仅备份了正在运行的 EC2 实例，而且还从中创建了一个可启动的 AMI。我们可以进一步备份，将 AMI 复制到另一个区域；只要镜像上没有硬编码的区域特定项目，它应该能够顺利启动并运行。

一旦您完成了 EC2 实例的启动并创建了 AMI，建议终止实例并删除 AMI，以免在 AWS 账户中产生额外费用。

使用用户数据脚本在启动时配置 EC2 实例

尽管我们可以启动 EC2 实例，然后手动配置所需的软件和包，但这并不是最有效的方法。除了手动步骤容易出错外，这种方法比使用自动化过程更加耗时。

示例用户数据脚本

接下来，我们将查看一个用户数据脚本的示例，该脚本可以通过预先执行创建文件、更新已安装的包、更新软件仓库，甚至运行命令等操作，在无需用户交互的情况下配置 EC2 实例：

#cloud-config
package_upgrade: true
repo_update: true
repo_upgrade: all
packages:
 - boto3
 - aws-cfn-bootstrap
write_files:
  - path: /test.txt
    content: |
      This is my file.
      There are many like it but this one is mine. 
runcmd:
  - [ sed, -i, -e, 's/is/was/g', /test.txt]
  - echo "modified my file"
  - [cat, /test.txt]

到此为止，我们已经学习了如何使用用户数据脚本在启动时自动配置 EC2 实例，这些脚本可以完成安装和升级包、运行脚本和命令等操作。接下来，我们将了解 EC2 实例的网络接口。

弹性网络接口（ENI）

弹性网络接口（ENI）就像虚拟网络卡，因此它们允许实例拥有一个 IP 地址，并连接到特定子网。EC2 实例允许附加多个 ENI，每个网络接口可以在同一子网中，或者由于特定原因穿越不同的子网：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.6_B17405.jpg

图 2.6 – 不同安全组中的 ENI

由于安全组是在网络接口级别而不是实例级别附加的，向实例添加额外的 ENI（弹性网络接口）可以使实例加入多个安全组，以满足特定需求。如果你有一台需要访问公共互联网的 Web 服务器，你可以将一个网络接口附加到提供此功能的安全组中。此外，在同一实例中，你可能需要通过 SSH 连接到机器，以便团队成员查看日志或检查服务器上运行的进程。可以通过这种方式锁定附加到特定 ENI 的安全组，从而限制对 SSH 端口（端口22）的访问。

弹性块存储（EBS）

虽然 EBS 和 EC2 紧密相关，但值得记住它们是两个独立的服务。EBS 是一个存储服务，提供基于网络的存储，它被分配到与实例相同的可用区，并挂载供使用。分配给实例的存储量因实例类型而异，并且并非所有类型的 EC2 实例都包含实例存储卷。

EBS 与基于一些关键特性的 实例存储 有所不同。实例存储卷是物理附加到 EC2 实例的存储。由于实例存储在实例停止、终止或实例故障时不会持久化，因此它最适合用于临时存储。相比之下，存储在 EBS 卷上的数据将会持久化：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.7_B17405.jpg

图 2.7 – AWS 中的 EBS 概述

EBS 卷可以在实例创建时分配，也可以在实例已放入服务后作为额外存储创建。

从 DevOps 的角度来看，在分配和恢复 EBS 卷时需要记住的一个关键特性是，卷必须保留在它创建时所在的同一可用区。

在尝试决定使用哪种类型的 EBS 卷时，一个关键的术语是每秒输入/输出操作数（IOPS）或预配置 IOPS（PIOPs）。IOPS 是测量每秒卷所能执行的输入/输出操作（以千字节为单位）。通过使用 CloudWatch 指标，你可以监控特定卷的性能，使用的卷度量标准包括以下内容：

VolumeReadOps
VolumeReadBytes
VolumeWriteOps
VolumeWriteBytes

现在我们已经了解了如何测量 EBS 卷性能的基本概念，接下来我们将查看一些可用的不同类型的 EBS 卷。

EBS 卷类型

EBS 卷有三种主要类型，这些类型在性能、最佳使用场景和成本上各不相同：

固态硬盘（SSD）：这是一种针对重读写操作进行优化的驱动器，适用于需要更高 IOPS 的场景。可以为配置提供两种类型的 SSD EBS 卷：

a. 通用型 SSD：提供成本与性能的平衡，最适合用于开发和测试环境。

b. 预配置 IOPS SSD：用于性能关键的任务工作负载，例如数据库或缓存。
硬盘驱动器（HDD）：这是一种针对流媒体工作负载进行优化的驱动器，当需要因持续读取和/或写入而保证性能时使用。可以为配置提供两种类型的 HDD EBS 卷：

a. 吞吐量优化型硬盘（HDD）：这种类型的 EBS 卷最适合用于数据仓库、日志服务器或大数据工作负载。

b. 冷 HDD：这是一种低成本的 HDD，适合用于不常访问的数据。
前一代：这是一种适合用于较小数据集且不具有关键重要性的数据驱动器。与 SSD 不同，这些 EBS 卷使用的是磁盘，因此性能不如其他两种类型的 EBS 卷。只有一种前一代 EBS 驱动器，适合用于不常访问的数据。

查看 EC2 服务，其中还包括 AMI 和 EBS 卷，你可以选择多个选项，能够根据实例的需求选择合适的大小。这不仅仅与操作系统的选择有关，还包括如何快速配置实例，以及存储性能的要求。

接下来，我们将了解 AWS Batch，这是一个服务，允许我们轻松执行大规模操作，无论是按需还是按计划执行。

AWS Batch

有时，你需要大量的计算资源。

这里可以考虑的一个例子是统计选举结果。一旦投票结束，多个人员和机器开始在不同的区域中心进行计数。每个区域中心统计票数并提交该小计，以便获得最终结果。

统计票数的这个过程是一个批处理过程。如果所有票数都保存在不同的逗号分隔值（CSV）文件中，那么它们可以全部上传并由 AWS Batch 服务处理。

AWS Batch 可以将作业作为 Shell 脚本、Linux 可执行文件或 Docker 容器来运行。

AWS Batch 有五个主要组件：

作业
作业定义
作业队列
作业调度器
计算环境

让我们更详细地看一下这些内容。

作业

在 AWS Batch 中，作业仅仅是工作单元。这些单元可以是 Shell 脚本、Docker 容器镜像或 Linux 可执行文件，但无论作业如何提交，都会在容器化环境中运行。

作业定义

告诉作业如何运行是 AWS Batch 作业定义的功能。这也是你为作业提供额外详细信息的地方，例如，如果作业需要访问其他 AWS 资源，你可以指定使用的 IAM 角色，还可以定义作业所需的内存和计算能力。

作业队列

直到计算环境可用来运行作业时，作业将停留在作业队列中。你并不限于每个 AWS 账户只有一个作业队列，因为队列可以与不同类型的计算环境关联。

高优先级作业可能会被放入由按需实例组成的队列中。低优先级作业则可能会等待在由抢占实例组成的队列中，直到抢占实例可用时才能运行。

作业调度器

一旦 AWS Batch 作业被提交到队列中，调度器会评估当前的计算环境，看它们是否可以运行该作业。由于作业可能依赖于其他作业的运行和/或完成，因此调度器也会考虑这一点。正因如此，作业会按合理的顺序从队列中提交并运行，但并不总是能保证一个精确的顺序。

计算环境

一旦你设置好作业队列所在的计算环境，你有多个选择。你可以选择托管或非托管的计算环境，并指定特定的实例类型，或者仅在可用的最新实例类型上运行。

如果你使用 Batch 的原因之一是为了节省成本，你还可以确定计算实例的抢占价格。如果计算环境的可靠性是必要的，那么你最好设置按需实例来搭建环境。

虚拟私有云网络和 Route 53 网络

AWS 的 虚拟私有云（VPC）服务允许你在云中创建虚拟网络。它允许你的计算和数据库实例要么允许互联网连接，要么与互联网隔离。安全性可以通过有状态或无状态的虚拟防火墙规则来实现，这些规则提供了你认为合适的网络连接量：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.8_B17405.jpg

图 2.8 – AWS 中的网络流量与安全

VPC 服务包含多个组件，可以让你路由和保护来自 AWS 服务的流量，且可选地包括互联网和/或本地网络。

VPC

虽然解决方案架构师（或可能是网络架构师）通常会确定用于 VPC 的 CIDR 地址范围，但很多时候，实施 VPC 的工作由 DevOps 工程师来完成，利用 基础设施即代码（IaC）。

有很多组件可以帮助构成一个 VPC。虽然我们不会深入讨论 VPC，但我们将介绍一些你应当了解的项目，以防它们出现在考试题目中。

子网

子网定义了 VPC 中的 IP 地址范围。既有公共子网，也有私有子网。公共子网应当用于需要通过互联网访问的资源。私有子网应当用于那些无法从互联网访问的资源。每个子网只能存在于一个可用区，无法跨越多个可用区。

安全组

安全组充当 Amazon VPC 中的虚拟防火墙。每个 EC2 实例最多可以拥有五个安全组，并且安全组在实例级别强制执行（而不是在子网级别）。

安全组允许有状态的流量，这意味着如果流量根据规则被允许进入，那么它将被返回，而不受任何现有规则的影响。你可以根据端口、IP 范围或其他安全组的组合来指定入站流量规则。

网络访问控制列表（NACL）

网络访问控制列表（NACLs）在子网级别工作（与在实例级别工作的安全组不同）。

虽然安全组是有状态的，但 NACL（网络访问控制列表）是无状态的，任何需要通过 NACL 返回的流量都需要打开端口和 IP 范围。NACL 规则按照顺序进行评估，最低的规则首先被处理。

互联网网关

除非你将 VPC 作为数据中心的私有扩展，否则你需要互联网连接。互联网网关为 VPC 提供与互联网的连接，具有高度可用、可扩展和冗余的特点。互联网网关提供的两个主要功能是：第一个是为路由表中指定的子网提供互联网访问；第二个是为已分配 IPv4 公共地址的实例提供网络地址转换。

仅出站互联网网关

如果你正在为 VPC 和实例使用 IPv6，那么你需要一个 单向出口互联网网关，而不是常规的互联网网关。这种类型的互联网网关可以防止互联网主动连接到你的实例，但仍然提供与其他互联网网关相同的可扩展性、冗余性和高可用性。

网络地址转换器（NAT）

当你的实例位于私有子网时，默认情况下，它们无法访问互联网。即使你已经设置了互联网网关，你也希望将私有实例与直接的互联网访问分离。这时，NAT 实例或 NAT 网关便发挥作用。

NAT 设备将私有子网中的实例流量转发到互联网或其他 AWS 服务。自从 VPC 端点 的出现以来，使用 NAT 来与账户中的其他 AWS 服务通信被认为是一种不安全的做法，绝不应该在生产环境中使用。

VPC 端点

如果你需要从 VPC 安全地访问 AWS 服务，可以创建 VPC 端点。VPC 端点允许 EC2 实例和其他 AWS 计算服务（如 Lambda 和 Fargate）与支持的 AWS 服务（如 S3 和 DynamoDB）进行通信，而无需创建互联网网关，甚至不需要公共 DNS 名称。

这对于那些既不需要也不应该连接互联网的 EC2 实例尤其有用。使用 VPC 端点允许数据连接通过内部 AWS 网络进行传输，并且不需要互联网网关、虚拟私有网关、NAT 设备、VPN 连接或 AWS Direct Connect 连接。VPC 端点是虚拟设备，可以根据需求进行扩展，并且具有冗余和高可用性。

DHCP 选项集

当你创建 VPC 时，Amazon 会默认自动为你创建一组 动态主机配置协议（DHCP）选项。然而，你可以通过创建新的 DHCP 选项集 来自定义一些可用设置，然后将该 DHCP 选项集附加到你的 VPC（从而移除默认的 DHCP 选项集）。

一些允许的选项包括：

domain-name-servers：使用你自己的 DNS，而不是 AWS 提供的 DNS。
domain-name：未限定的服务器的默认域名。
ntp-servers：你可以指定最多四个网络时间协议（NTP）服务器。
netbios-name-servers：你可以指定最多四个 NetBIOS 名称服务器。
netbios-node-type：NetBIOS 节点类型（1、2、4 或 8）；此设置默认为空，且 Amazon 不支持广播或多播。

注意

了解 DHCP 选项对于在实际环境中配置 VPC 非常有用，但记住所有可用选项并不是 DevOps 专业考试的必要要求。

使用自定义 DNS 配置你的 VPC

亚马逊提供了一个默认的 DNS 服务器（Route 53 解析器）；不过，如果你愿意，也可以使用自己的 DNS 服务器。一些公司要么在混合环境中从他们的数据中心运行 DNS，要么将当前的 DNS 服务器镜像到云端，这样他们就不需要创建包含所有必需信息的 Route 53 托管区域，或者干脆选择在他们最熟悉的平台上管理 DNS。

如果是这种情况，且你想指定 DNS 而不是使用默认的 DNS 服务器，那么你需要创建一个 DHCP 选项集，并填写你的 DNS 服务器的值。完成后，你可以将该 DHCP 选项集附加到你的 VPC，VPC 中的实例将开始使用你指定的 DNS 服务器。

连接多个网络的方法

在 AWS 网络世界中，提供了多种工具来帮助你连接不同的网络。

VPN 连接

你可以使用多种选项将 AWS 与自己的 虚拟专用网络（VPN）连接：

AWS 站点到站点 VPN：这个选项创建一个 IPSec 连接，将你的 VPN 与远程 VPC 连接。
AWS 客户端 VPN：这个选项使用一个托管客户端，允许你的用户通过基于 OpenVPN 的客户端从几乎任何位置连接。
AWS VPN CloudHub：这个选项允许你通过虚拟专用网关创建与多个 VPC 的站点到站点 VPN 连接。（其他选项仅创建与单一 VPC 的 VPN 连接。）
第三方 VPN 设备：这个选项允许你使用在 EC2 实例上运行的第三方软件创建 VPN 连接。然而，重要的是要注意，在选择此选项时，你需要负责 EC2 实例的维护和保养。

AWS Transit Gateway

AWS Transit Gateway 允许你通过一个中央网络中心连接本地网络和多个 VPC。Transit Gateway 作为你的云连接的路由器，只需将每个网络连接到 Transit Gateway 一次。连接完成后，其他网络可以通过 AWS 全球私有网络而非公共互联网，使用定义的网络规则相互通信。

AWS Direct Connect

如果你或你的公司有持续的数据传输需求，既需要向 AWS 传输数据，也需要从 AWS 传输数据，那么 Direct Connect 服务可以为你的本地环境与 AWS 之间提供一个私有网络连接。这些专用连接可以通过直连服务提供商以 1 Gbps、10 Gbps 或 100 Gbps 的速度进行连接。

与直接通过公共互联网连接不同，使用 AWS Direct Connect 连接通过专用通道将数据从你的数据中心或办公室传输到 AWS，而不是通过公共互联网，从而提供一致的网络性能。

Route 53

AWS 提供的全球 DNS 服务是 Route 53。这是 AWS 中为数不多的几个不与任何特定区域相关联的服务之一。Route 53 服务还拥有最强的承诺之一，声明其 将采取商业上合理的努力，使 Amazon Route 53 保持 100% 可用（Amazon Web Services, 2021）。

Route 53 有三个主要的组成部分是基础性的重要：

注册（并管理）域名的能力
DNS 服务
执行健康检查（并随后根据其功能性、可用性和可达性路由流量）的能力

本节将介绍一些有关 Route 53 服务的基本信息，特别是那些对 DevOps 考试有帮助的话题。

了解 Route 53 中可用的不同类型的记录

有许多不同类型的 DNS 记录，目前为止，Route 53 支持以下类型的 DNS 记录：

地址 (A) 记录
AAAA（IPV6 地址记录）
规范名称 (CNAME) 记录
认证机构授权 (CAA)
邮件交换 (MX) 记录
名称授权指针记录 (NAPTR)
名称服务器 (NS) 记录
指针 (PTR) 记录
授权起始 (SOA) 记录
发件人策略框架 (SPF)
服务 (SRV) 位置
文本 (TXT) 记录
别名记录（这是 Route 53 特有的 DNS 扩展）

现在我们知道了 Route 53 支持哪些类型的记录，接下来让我们看看域名和托管区域之间的区别。

了解域名和托管区域之间的区别

了解域名和托管区域的第一件事是，首先，域名是一个互联网构造，属于域名服务器，它将一个人或组织的唯一名称与一个数字地址的互联网资源关联起来。

域名有区域文件，它们是不同资源及其关联的名称、地址和当前映射类型的文本映射。而托管区域则是 Route 53 独有的东西。它在结构和映射上类似于 DNS 区域文件（你可以将 DNS 区域文件导入到 Route 53 托管区域中），但一个主要的不同之处在于它可以通过 Route 53 界面、CLI 或 API 进行管理和修改。

Route 53 健康检查

Route 53 允许你检查应用程序的健康状况，然后根据你提供的规则将流量重新路由到其他服务器或资源。你甚至可以在 Route 53 的 web 控制台中查看健康检查的最新状态。

检查特定终端节点的健康状况

在这种情况下，您将创建一个来自 Route 53 的检查，该检查将在您指定的常规间隔内执行检查。您的健康检查监控的是一个端点，可以是 IP 地址或域名。然后 Route 53 会按照间隔检查该服务器、应用程序或其他资源是否可用且正常运行。您还可以请求一个特定的网页或 URL，该 URL 会模拟大多数用户的操作，而不仅仅是放在服务器上的一个简单健康检查页面，该页面会在系统正常运行时返回简单的 200 代码。

计算健康检查（监控其他健康检查的健康检查）

如果您有多个执行相同功能的资源，您可能会想知道是否至少有一些资源是健康的。这时计算健康检查就派上用场了：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.9_B17405.jpg

图 2.9 – 计算健康检查示例

计算健康检查充当根健康检查，其中后代检查可以失败，直到源被视为不健康。

如果触发任何警报，此类健康检查会失败。

检查 CloudWatch 警报的状态

Route 53 可以利用 CloudWatch 指标和警报的功能。一旦创建了 CloudWatch 警报，您可以在 Route 53 中创建一个健康检查，观察与 CloudWatch 警报相同的数据流。

为了提高 CloudWatch 警报健康检查的可用性和灵活性，Route 53 查看来自 CloudWatch 的数据，然后确定该路由是否健康。它不会等待达到 ALARM 状态后再将路由设置为不健康。

Route 53 路由策略

Route 53 中的路由策略告诉服务如何处理查询。这些策略可以从简单到复杂，正如我们接下来将看到的。

简单路由

这是指 DNS 配置没有特殊配置。您只需要设置 DNS 文件应指向的单个记录。没有加权，也没有故障转移——只需保持简单即可。

故障转移路由

使用故障转移路由时，当初始记录集中的主资源不可用或未通过定义的健康检查时，您将有一个备用记录。

这可以是另一个位于不同区域的服务器，或者是通过 S3 存储桶提供的备用网站。

地理位置路由

如果您有一个跨越某个国家、洲或全球的观众或用户群，并且希望根据他们的地理位置向他们提供定制的信息或网站（而无需使用复杂的 cookies 和动态内容），那么您可以使用 Route 53 的地理位置路由功能，将他们引导到最适合其源位置的服务器或内容来源。

您可以按洲、国家或美国的州指定地理位置。

地理邻近路由

您可能有一个地理上分布广泛的用户群，但希望能够将更多（或更少）流量推送到某个特定地区或资源集。地理接近路由与地理位置路由的区别在于此功能。它可以根据每个特定资源的偏移值以及请求用户的原始位置，决定将更多或更少的流量路由到该资源。偏移值会扩大或缩小流量路由到资源的地理区域的范围。

基于延迟的路由

当您的观众或用户群体地理分布广泛，并且您在多个区域运行资源时，您可以使用基于延迟的路由将每个用户引导到能够提供最快响应时间的资源或内容。

问题

地理位置路由与基于延迟的路由有什么区别？

尽管在这两种情况下您都在处理一个地理上扩展的用户群，基于延迟的路由则基于 Route 53 创建并存储在原始点和 IP 或 DNS 记录点的延迟记录。这些延迟记录可能会发生变化，因此最好确保提供一致的体验，或根据客户设置提供定制化的体验。

地理位置路由，另一方面，是将用户请求与已与该源 IP 地址地理绑定的资源进行匹配，这样您就可以为最终用户体验提供本地化的内容。

多重响应路由

尽管多重响应路由不能取代负载均衡器，但它确实允许 Route 53 随机选择最多八个健康的值来响应。

您可能想使用多重响应路由的一些场景如下：

创建多个相同名称类型的记录
将流量路由到多个源
将 Route 53 健康检查与记录关联

加权路由

如果您有多个资源，并希望将请求分配到这些资源，同时实现不均衡的流量分配，您可以通过 Route 53 设置加权路由。这有几个应用场景，例如推出带有重要或次要更新的金丝雀发布，并将仅一部分流量重定向到新环境。您可以根据关键绩效指标（如放弃购物车的数量）来评估。

实现加权路由从有多个资源开始，您希望将流量在这些资源之间进行平衡。然后，您可以在 Route 53 托管的区域内创建记录来反映这些资源。这些记录必须是同一类型的记录，且位于同一域或子域中；也就是说，两者需要是 A 记录。

一旦记录设置完成，您可以继续配置路由，通过为特定资源分配权重来进行路由。加权值可以是从 0 到 255 之间的任何数字（如果您指定为 0，则该记录将不再接收流量）。

流量是通过计算当前记录的权重来平衡的，然后将其除以所有记录的总和。

示例：如果你有两台服务器运行，并且服务器 A 的记录权重为 75，服务器 B 的权重为 150，那么 75 + 150 = 225 总权重，使用公式 75 / 225 = 0.3333333，服务器 A 将获得 33%的流量。

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.10_B17405.jpg

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.10_B17405.jpg)

图 2.10 – 在 Route 53 中创建加权记录

Route 53 将在稍后详细讨论，当我们进入第十三章，蓝绿部署，并讨论蓝绿部署策略时。

云数据库

当你查看下图时，可能会想，为什么有这么多种数据库。这源于过去几十年应用架构的演变，其中专业化、速度和规模都已成为这一行业成功的关键。

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.11_B17405.jpg

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.11_B17405.jpg)

图 2.11 – AWS 中的数据库类型和服务

本章篇幅有限，无法介绍 AWS 提供的每种数据库类型。不过，作为本基础概述的一部分，我们确实希望涵盖一些关系型数据库及其基本特性。

我们将在接下来的章节中更详细地讨论键值数据库 Dynamo DB。

关系型数据库

说到数据库，通常会想到关系型数据库，它们有行、列和模式。

AWS 中的关系型数据库有三种主要的类型，并且其引擎可以根据社区版、商业版或云原生进行分类。云原生引擎被用于 Aurora 服务，因为它们是基于社区引擎构建的，具有云原生存储、备份和复制能力。

注释

当我们谈到云原生时，我们指的是构建和运行利用云计算模型的应用程序：松耦合的服务，动态可扩展，可以在多租户平台上运行，并具备灵活的网络和存储。

关系型数据库通常遵循 ACID 数据库属性集合：

原子性：你的所有事务要么都成功，要么都不成功。
一致性：写入数据库的任何数据必须符合所有已定义的规则。
隔离性：确保并发执行事务时，数据库会保持在一个与按顺序执行事务时相同的状态。
持久性：一旦事务被提交，它将保留在系统中，即使系统发生崩溃。

关系型数据库服务

关系型数据库服务（RDS）旨在接管以前由数据库管理员执行的任务，数据库管理员曾需要在职，但现在很多日常工作都可以通过自动化和脚本来处理。这些任务包括配置新数据库、创建备份、扩展为只读副本、修补和升级实例，以及在发生事件时切换到高可用性实例。RDS 简化了软件和数据库配置的设置与安装。使用托管的 RDS 服务还可以帮助组织在创建和部署数据库时实现一致性标准。无需自定义脚本来部署、设置和修补数据库，因为这一切都在后台自动处理。

部署后，开发人员和应用程序可以访问一个可以方便连接的数据库端点，用户可以通过客户端或身份验证应用程序进行连接，然后对数据库执行查询。

RDS 提供多种不同的引擎格式，包括两个商业引擎和三个流行的开源引擎。支持的两个商业引擎是 Oracle 和 Microsoft SQL Server。这两个商业引擎都广泛用于企业中。RDS 支持通过 Oracle SQL 访问 Oracle 模式，并提供 Microsoft SQL Server 的本地工具，如 SQL Server Management Studio。在社区版中，RDS 允许使用 MySQL、PostgreSQL 和 MariaDB 创建数据库。MySQL 是最受欢迎的社区关系型数据库之一，AWS 运行该数据库的社区版，默认使用 InnoDB 表，并在文档中说明 MyISAM 存储引擎不支持可靠的崩溃恢复。

PostgreSQL

PostgreSQL 是另一个非常流行的数据库，开发人员青睐其丰富的功能集。RDS 支持常用工具，如 pgAdmin，或通过 JDBC/ODBC 驱动程序连接到数据库。

确定选择的引擎后，您可以选择一个实例类型，以便提供不同级别的计算和内存能力。通常用于测试环境的有突发性实例（T 系列）。在将数据库工作负载迁移到更生产化的环境时，建议选择通用实例（M 系列）或内存优化实例（R 系列）。

RDS 和你在 EC2 实例上自行运行的相同类型引擎之间的一个区别是副本的工作方式。只需点击一个按钮，无论是在同一可用区还是不同可用区，都可以极其容易地创建只读副本；然而，这些节点是只读的，不能执行写操作。在同一背景下，你可以让实例立即具备高可用性，将数据异步复制到另一可用区或区域的主节点副本中。如果发生故障，应用和最终用户将感受不到任何中断，因为它们用于连接数据库的 DNS 地址保持不变。然而，这个二级主节点不能从主主服务器上分担负载，因为它除了作为故障转移节点外，不能承担其他任何功能（例如作为只读副本）。只读副本可以提升为独立数据库，并且此时它将具备执行写操作的能力。然而，它将不再与之前所复制的主节点保持同步。

Aurora

Amazon Aurora 是为了响应客户希望获得像 Oracle 或 Microsoft SQL Server 这样的商业级数据库引擎的性能，同时不必处理与这些产品相关的许可束缚问题而构建的。

关于 Amazon Aurora 的另一个重点是，与其他由 EBS 存储支持的 RDS 引擎不同，Aurora 在听取了多年来多位客户的需求后，从零开始构建了自己的存储解决方案。

Amazon Aurora 提供 MySQL 兼容版和 PostgreSQL 版。用户可以选择将 Aurora 作为集群运行，甚至运行 Aurora 数据库的无服务器版本。需要了解关于 Aurora 无服务器版本的主要事项是，它根据应用或用户的需求按需提供容量。这是预配 Aurora 集群与无服务器版本之间的显著区别。

键值数据库

随着应用的构思，初期无法完全预测会服务多少用户。通常人们希望，随着时间的推移，应用的受欢迎程度会从初期的用户和测试者扩展到指数级规模。为了支持这种增长，底层数据库必须能够无缝应对这种规模。这也是键值数据库的特点之一。

我们将在 第五章 中更详细地了解 DynamoDB，Amazon DynamoDB。

内存数据库

当你频繁从主数据存储（如关系型数据库）访问存储的项目时，有时仅从数据库请求数据无法提供客户期望的用户体验。这时，像Amazon Elasticache这样的内存数据库成为一个可行的选择。

Elasticache 提供两个不同的引擎版本：Redis 和 Memcached。

文档数据库

文档数据库是一种非关系型数据库，它允许你以 JSON 格式存储文档和数据，并查询这些数据以找到所需的内容。文档数据库的一个独特特点是没有固定的架构，并且它们可以包含互相嵌套的文档。

AWS 提供了Amazon DocumentDB（具有 MongoDB 兼容性）作为一个托管数据库服务，适用于那些曾经使用过 MongoDB 或者正在寻找文档数据库功能的用户。如果你曾经在 MongoDB 的操作端工作过，那么你知道，尽管 MongoDB 功能强大并具有一些高级功能，包括在当前主节点不可用时自我选举新主节点，但其部署和运行有一些复杂的设置要求。

它需要（在生产环境中）至少三个节点——可以是两个节点和一个仲裁者，或者三个主节点。所有这些复杂的设置在 DocumentDB 中都不再需要。亚马逊会处理设置和安全性，并允许你配置自动备份，然后可以将备份存储在 S3 上。

你可能会放弃一些小的功能，比如无法使用管理员或本地表，这意味着你不能使用 mongodump 或 mongorestore 工具，但有一些功能可以代替这些工具。

文档数据库特别适合那些不想处理数据库管理方面的团队，想通过 JSON 简化初始架构值使用的方式，并且只想开始将数据推送到数据库中，以便之后可以进行简单或高级的查询。

消息和队列系统

当你开始构建云规模应用时，你需要找到一种方法来解耦应用程序的不同层，使得每一层能够独立扩展。这样做有几个原因，包括使你的应用程序更加弹性，并允许每一层独立于其他层进行扩展。能够使用托管服务来执行这些任务，在这种情况下，你或你的团队成员无需担心队列或消息系统的设置和维护，能够加速在云中迁移或开发时使用这些技术。

接下来我们将了解 AWS 提供的消息和队列系统，以及它们如何对你有所帮助。

简单通知服务（SNS）

有时，你需要能够简单地发送消息，无论是来自你的应用程序还是其他服务，消息可以采用多种格式，例如电子邮件或短信，并可以以多种方式使用。这些可以基于编程调用或发生在你的 AWS 账户中的事件。这就是简单通知服务（SNS）派上用场的地方。

SNS 是一个发布者和消费者系统，发布者可以将消息推送到一个主题。然后，任何订阅该主题的消费者都可以消费该消息：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.12_B17405.jpg

图 2.12 – SNS 广播

SNS 主题充当一个频道，可以将单个消息广播到一个或多个订阅者。发布者，即前面图中的应用程序，只需要将消息发送一次到该主题；每个消费者（或订阅者）可以以适合自己的方式接收并处理该消息。这些消息可以存储在 S3 中作为归档，或在移动短信或电子邮件中按需消费，或者在 Lambda 中进行解析和执行。

简单队列服务（SQS）

如果你在寻找一种完全托管的队列服务，允许你以云原生的方式拆分应用程序，那么 简单队列服务（SQS）就是一个非常合适的服务选择。它有两种类型：标准队列和先进先出（FIFO）队列。标准队列允许至少一次的消息投递，而 FIFO 队列则保证对队列中的消息进行一次性投递。这两种队列的另一个主要区别是，FIFO 队列中的消息会按接收顺序进行处理。标准队列尝试保留接收到的消息顺序；然而，如果消息顺序错乱，它不会进行任何洗牌或重新排序操作来保持原始的消息顺序。

SQS 是一个分布式队列系统，这意味着它分布在区域内的不同节点上。这是 SQS 带来的一项设计特性，它使 SQS 具备了高度可扩展、可用、可靠和耐用的优势。SQS 还支持 服务器端加密（SSE），可以通过 AWS 提供的 KMS 服务密钥或自定义密钥实现。你还可以通过访问策略控制谁可以访问产生或消费的消息。SQS 分布式队列系统的主要组成部分有三部分：

生产者/消费者（组件）
队列
队列中的消息：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.13_B17405.jpg

图 2.13 – SQS 分布式队列

消息由生产者放入 SQS 队列，然后被分配到队列组件中以实现冗余。当消费者准备处理消息时，它会使用长轮询或短轮询技术检查队列中是否有待处理的消息。如果检测到待处理的消息，它会消费该消息进行处理；然而，消息仅会被标记为已处理，并且可见性超时开始。一旦消费者成功处理消息并删除该消息，消息就会从所有分布式队列节点中移除。

消费者在成功处理消息后必须删除这些消息。由于 SQS 运行的分布式系统的特性，一旦消费者拉取了一个消息进行处理，该消息就会被标记，以确保其他消费者无法拉取相同的消息。不过，在超时期之前，消费者需要确认消息已经处理。如果 SQS 没有收到这个确认，那么该消息会取消标记，并可供其他消费者处理。

在什么情况下使用 SNS 而不是 SQS？

在尝试决定使用哪个消息服务时，有一条规则可以帮助你决定哪个服务最适合你；问以下一组问题：

我的消息需要保证送达吗？
（如果答案是“是”，那么 SQS 将是最佳选择，因为 SNS 没有提供保证送达的选项。）
我的消息是否只会被我的应用程序消费？

（如果答案是“是”，那么 SQS 将是最佳选择。）
我的消息是否会被多个来源消费？

（如果答案是“是”，那么 SNS 将是最佳选择。）

通过这三个问题，你可以判断自己是处理一个封闭循环，即收集消息并在应用程序中进行处理（SQS），还是创建一个消息供应用程序外部消费（SNS）。

Amazon MQ

如果你正在迁移一个之前使用 Apache MQ 或 Rabbit MQ 的应用程序，并且你不再想管理实例，那么Amazon MQ是一个不错的选择。Amazon MQ 更像是一个消息代理，而不仅仅是一个简单的队列。

当你去分配你的 Amazon MQ 时，必须选择 Rabbit MQ 或 Apache MQ 引擎类型。选择好引擎类型后，使用管理控制台配置 Amazon MQ 时，它会通过一系列选择提示你使用单一代理，或使用一个高可用的活动和备用代理。它甚至可以通过预定义的蓝图为你创建一个单一或活动与备用代理的网状网络。

Amazon MQ 和 SQS 之间的区别

尽管 SQS 也是 AWS 提供的托管服务，它是一个可扩展的队列，并不需要建立消息代理。Amazon MQ 的优势在于，它允许依赖 MQTT、OpenWire 或 STOMP 等 API 的先前构建的应用程序快速且轻松地迁移到云端，同时保持高可用性，并且几乎没有额外开销。

简单邮件服务（SES）

简单邮件服务（SES）允许你设置并发送电子邮件，而无需处理运行 SMTP 服务器的大多数复杂性。

SES 仅在三个区域运行：us-east-1（北弗吉尼亚）、us-west-2（俄勒冈）和 eu-west-1（爱尔兰）。

亚马逊帮助你验证邮件的来源。通过向我们发送电子邮件的 DNS 记录中添加一系列 DKIM 记录，它为你发送给客户的邮件提供了信任。

可信顾问

随着 AWS 账户中资源数量的增加，跟踪所有资源有时会变得具有挑战性。挑战开始出现，例如有些磁盘处于空闲状态未被使用，弹性 IP（EIPs）也处于空闲状态，未连接到任何实例或接口，这会消耗你的预算。一旦进入受信顾问仪表盘，你将看到该工具为自动检查生成的四个类别：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_2.14_B17405.jpg

图 2.14 – 受信顾问仪表盘

当涉及到容错检查时，它可以告诉你是否在单一可用区或区域中拥有过多实例。

可用的受信顾问检查数量随着账户支持级别的提高而增加。对于具有基础或开发者支持级别的账户，显示的是基本检查集。当支持级别提高到商业或企业级时，账户将可以访问所有 115 个受信顾问检查。

即使在基础支持级别，受信顾问也提供四个领域的多个检查：

成本优化
性能
安全
容错

注意

你是否注意到受信顾问提供的四个基本检查可以映射到 AWS 服务支柱的四个方面？

此外，受信顾问可以设置为每周向账单联系人、操作联系人、安全联系人或三者的任何组合发送通知。

访问受信顾问

受信顾问具有图形化的仪表盘界面，可以查看，而且当你第一次从 AWS 控制台查看该服务时，甚至可以看到在成本优化图标下可能的月度节省。AWS 一直在精细化控制台界面，使其更易于使用，并尽可能直观，展示每个主要标题图标下的三个图标，分别表示没有警告的检查（绿色）、建议调查的检查（黄色）和建议采取行动的检查（红色）。

你还可以通过 AWS CLI 访问受信顾问。从 DevOps 角度来看，这很有用，尤其是在服务限制检查方面。你可以使用自动化管道或周期性 Lambda 作业来检查特定服务的服务级别，然后自动请求服务级别的提升，或将通知发送到正确的电子邮件或分发列表中，以避免在构建过程中出现中断。

总结

AWS 不断增长其提供的服务数量。我们在本章中简要介绍了许多服务，虽然内容较为简略，但只涵盖了在 AWS 平台上托管和服务应用程序的许多关键服务。

在本章中，我们回顾了 AWS 提供的基础服务。这些服务，以及我们在第一部分剩余部分中将要学习的其他服务，将作为我们 DevOps 旅程中的部署组成部分。掌握这些服务的基础知识可以帮助我们在开发和部署目标上做得更多，同时也有助于我们理解 DevOps 专业考试中的问题，以及在日常工作中遇到的场景。

在下一章中，我们将探讨身份与访问管理，它是保护我们的 AWS 云账户和资产的基础。

回顾问题

如果你想对 Amazon EC2 空闲容量进行竞价，以下哪项将允许你做到这一点？

a. 预留实例

b. 自动扩展

c. Spot 实例

d. 节省计划
你所合作的公司希望加强网络安全。然而，他们当前不想声明返回流量的出口。你可以使用哪个 VPC 构造来帮助调整他们的安全设置？

a. 网络访问控制列表（NACLs）

b. 网络地址转换器（NAT）

c. VPC 端点

d. 安全组
判断题：Trusted Advisor 可以通知你账户即将达到的服务限制。
如果你的公司目前在数据中心运行 SQL Server 实例，并希望将其迁移到 AWS 云中，哪些选项可用？

a. 在 EC2 上运行数据库

b. 设置 Direct Connect 使得云资源可以连接到 SQL Server 实例

c. SQL Server on RDS

d. SQL Server on Amazon Aurora
以下关于 FIFO SQS 队列的哪项陈述是正确的？

a. 你不能保证消息按照发送顺序到达。

b. 消息将按照 FIFO 顺序精确投递。

c. 消息将被准确投递一次。

d. 消息可以被投递一次或多次。

回顾答案

c
d
正确
a 和 c
b 和 c

第三章：AWS 中的身份与访问管理以及密钥管理

在掌握了众多基本服务的基础上，我们现在进入 身份与访问管理 (IAM) 部分。

定义用于管理对不同 Amazon Web Services (AWS) 服务的访问的控制和政策，正是 IAM 的基本内容。这可以通过用户、组、政策，甚至访问控制来实现，包括联合访问或短期凭证。还可以使用外部 身份提供者 (IdPs) 来允许用户访问您的应用程序。理解如何使用本地 AWS 工具保护密钥，尤其是在 持续开发 (CD) 过程中，是一种企业级技能，这不仅出现在 DevOps 专业考试中，而且在工作中也至关重要。

在本章中，我们将覆盖以下主要主题：

理解 AWS 中的共享责任模型
IAM 角色、组、用户和政策
将 AWS Organizations 作为指导的一部分
与 AWS 账户进行联合身份验证
在 AWS 中安全存储密钥
使用 Amazon Cognito 与应用程序身份验证

技术要求

在阅读本章时，您应该已经创建了一个 AWS 账户，并安装了 AWS 命令行界面 (CLI) 版本 2 (v2)，以便您可以跟随本章中的实际操作活动进行练习。如果您打算跟随 AWS 假设角色练习进行实践，您还需要多个 AWS 账户。

理解 AWS 中的共享责任模型

虽然我们在 第一章 中简要提到过它，亚马逊 Web 服务支柱，但理解共享责任模型对于管理账户的安全性，特别是 IAM 服务，是至关重要的。

下图提供了该模型的概览：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.1_B17405.jpg

图 3.1 – AWS 共享责任模型：基础设施即服务（IaaS）

共享责任模型的本质是提供灵活性和客户控制。在此模型下，有两个主要概念，如下所示：

谁负责 云的安全性：

这是 AWS 承担责任的部分。
谁负责 云中的安全性：

这是您作为客户需要承担的责任。

AWS 控制着全球基础设施，其中包括承载所有 AWS 服务的服务器的数据中心。这些数据中心根据安全最佳实践和一系列安全合规规范进行管理。虽然客户不允许访问实际的数据中心，但独立的外部机构会对这些中心和实践进行认证和审计，以确保控制措施、政策和程序得到了遵循。

AWS 在多个层级上保护其数据中心，具体如下：

在边界层——AWS 选择用于容纳其数据和计算设施的建筑物并未向公众披露。这些设施也有严格的进入要求，并配备入侵检测和严密的监控来保护它们。
在环境层——在选择位置之前，AWS 会考虑环境风险，如恶劣天气、洪水和潜在的地震活动。
在基础设施层——在建筑物内部，有一套结合了火灾检测和抑制设备的系统。

作为客户，你的责任之一是你在账户中上传、存储和创建的数据。根据你和客户的需求，你可以选择以未加密的形式存储和传输数据。如果要求比明文数据更严格，AWS 提供了多种加密选项，或者你可以管理自己的加密。我们将在稍后的第十九章《保护静态和传输中的数据》中进一步讨论如何加密数据。

你在 AWS 云上的责任还包括你允许谁和什么访问你账户中的各种服务。这时，IAM 服务发挥着关键作用。默认情况下，AWS 不允许任何应用程序或用户访问其他任何服务。

保持操作系统的更新，包括对你弹性计算云（EC2）实例的任何补丁和更新，也属于你在共享责任模型中的责任。这些服务如系统管理器（SSM）和 Amazon Inspector 可以帮助你完成这项任务，识别关键的安全补丁并遵循维护计划。如果你运行实际的基础设施服务，那么最终责任就落在你身上。

你如何通过网络层允许流量进入你的实例也是你的责任。在第二章《基础 AWS 服务》中，我们讨论了虚拟私有云（VPC）以及你用来通过安全组和网络访问控制列表（网络 ACL）来保护网络的工具。将安全规则限制为仅允许必要的流量——而不是更多——可以防止外部实体通过端口扫描和其他恶意活动获取不必要的信息。

这个最初由 AWS 发布的主要共享安全和责任模型反映了 IaaS 模型中的责任。然而，随着不同的云计算模型的出现，例如平台即服务（PaaS），在容器服务和更像软件即服务（SaaS）的托管服务的情况下，Amazon 承担了更多的责任。

使用容器（特别是在 Fargate 的情况下）时，安全模型更倾向于 PaaS 模式，因此更多的责任被推向 AWS。你不再负责操作系统，因为 AWS 正在管理这一部分。然鹅，你仍然负责客户数据以及进出系统的网络流量，正如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.2_B17405.jpg

图 3.2 – AWS 共享责任模型：容器服务

需要理解的主要内容之一是，在所有共享责任模型中，您需要对数据的保护负责。这包括数据将暴露到多少个端口，以及数据将如何加密或是否保持未加密状态。

授权与认证

当我们开始了解身份和访问管理（IAM）时，我们首先需要完全理解授权与认证的概念。尽管这两个术语听起来相似，并且经常一起使用，但理解它们之间的区别对于我们深入探讨非常重要。

认证

认证是验证你所声称身份的过程。系统在询问你是谁，你通常会用用户名和密码进行回答，但有时也会使用安全会话令牌。认证是在回答问题你是谁？ 和 你能验证你自己说的身份吗？

授权

授权发生在认证之后，确定你被允许执行的操作。大多数情况下，它发生在认证之后。规则和政策决定了你被授权访问的内容。在计算机世界中，这可以通过令牌传达，例如承载令牌或JavaScript 对象表示法（JSON）Web 令牌（JWT），它授予你访问服务或应用程序处理接口（API）的权限。

认证与授权的过程如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.3_B17405.jpg

图 3.3 – 认证与授权

认证和授权容易混淆，因为它们看起来相似，但可以将认证看作是你的照片身份证明，而授权则像是一个射频识别（RFID）徽章，它允许你访问。让我们通过另一个例子进一步明确这一点。

授权与认证的实际示例

在许多大型办公楼中，您需要一张带照片的身份证明才能进入大楼。在大多数情况下，您被要求随时佩戴该证件，以证明您已获得授权进入大楼，不会被安保人员拦截。当您走向电梯时，您可能需要扫描您的证件才能访问您工作的楼层。按下您的身份证明，其中包含一个与政策系统和用户资料相关联的 RFID 芯片，系统会知道您可以访问哪些楼层。如果您在三楼工作，那么您已经验证了可以按下 3 号按钮并乘坐电梯到三楼。大楼中可能还有其他门，您可能没有权限访问，具体取决于您的身份验证级别。

IAM 需要理解的术语

当我们开始讨论 IAM 服务及其各个组件时，首先需要列出我们将使用的术语及其定义。对于职业考试来说，没有必要记住这些术语，但它们是您需要了解的整个服务的组成部分，尤其是低级考试中必考的内容。以下列出了这些术语：

主体：一个应用程序或人员，使用 AWS 根账户用户、IAM 用户或 IAM 角色进行身份验证并发起请求。这是可以对 AWS 资源执行操作的对象或人员。
资源：资源是您可以在 AWS 账户内操作的项目。资源的一个示例可能包括 Lambda 函数、EC2 实例或 简单存储服务（S3）存储桶。
实体：实体可以是 IAM 用户、联合用户，或来自身份提供者（IdP）的用户，或者在 AWS 上下文中的假设 IAM 角色。它仅仅是 AWS 用于身份验证的 IAM 资源对象。
身份：用于识别谁在使用服务的资源称为 IAM 中的身份。这些包括用户、组和角色。

IAM 可以进行主体身份验证的方式

IAM 具有多种方式可以进行主体身份验证，具体如下：

用户名和密码——用户名和密码是进入 AWS 管理控制台的初始方式。
访问密钥和秘密访问密钥——这些是可以与用户或根用户关联的长期安全凭证。它们可以被轮换，并且每个用户在任何时刻最多可以关联两个访问密钥。
会话令牌——您可以使用假设的角色来利用安全令牌服务（STS）传递一个令牌，允许您或您的应用程序获得分配的访问权限。

注意

AWS 管理控制台用户默认不能使用其用户名和密码凭证运行任何特定程序并访问 AWS 服务或底层基础设施。所有这些都依赖于 IAM 策略提供的授权。

IAM 的授权概念

在为用户和应用程序添加授权时，有两个模型需要注意：基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）。接下来我们将讲解每个概念。

RBAC

传统的访问控制基于将用户和应用程序分组为组（或角色），然后为这些组分配权限。很多时候，这些组代表的是工作职能，与该职能相关的权限处理该职能的责任。

将特定的权限集映射到一个角色，将该角色定义为认证服务中的一个组，如Active Directory（AD）或 AWS IAM，然后将用户加入该组，以便他们能够假设这些权限，这被定义为 RBAC。

ABAC

ABAC 可以基于三种不同类型的属性进行访问控制，列举如下：

用户属性
与要访问的系统相关的属性
当前环境条件

在 AWS 中，这些属性大多数通过标签、账户信息（即账户号码、别名或组织单位（OU））以及与用户关联的联合数据来管理。

IAM 服务概念

使用 IAM 时，最重要的概念之一，以及在浏览 AWS 访问时的关键点，是只授予完成任务所需的最小权限，绝不多给。

IAM 角色、组、用户和策略

在 IAM 中控制对资源的访问，归结于你如何设计附加到用户、组和角色的策略。服务本身假设角色，而在 IAM 中创建的用户，如果被放入组中，将更容易进行管理。

注意

每个账户有 500 个 IAM 用户的服务限制。

IAM 策略

IAM 策略是一组权限，以 JSON 语句的形式表示，指定实体拥有哪些访问权限。

当你开始分配账户中的权限时，你将处理这些 IAM 策略。AWS 提供了许多预先制定的策略，帮助你快速入门，可以附加到用户和组或服务上。许多基于 AWS 的策略将资源列为*，但这意味着任何资源都可以被访问。即使是简单策略，也有多种方式可以限制可以访问的资源数量。

让我们看一个非常简单的 IAM 策略示例，展示了如何使用通配符在账户中为所有 S3 存储桶上的所有对象操作授予访问权限：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllS3ObjectActions",
            "Effect": "Allow",
            "Action": "s3:*Object",
            "Resource": ["*"]
        }
    ]
}

然而，我们可以通过修改策略中的资源行来限制我们的用户可以访问的存储桶，如下所示：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllS3ObjectActions",
            "Effect": "Allow",
            "Action": "s3:*Object",
            "Resource": ["arn:aws:s3:::my-bucket/*"]
        }
    ]
}

AWS 中有多种不同类型的策略可以使用，如下所示。每种策略在权限管理中扮演着不同的角色：

基于身份的策略
基于资源的策略
权限边界
组织的服务控制策略（SCPs）
ACLs
会话策略

现在我们知道了 IAM 策略如何工作，以及可用的不同类型的策略，让我们来看看一些 IAM 策略的基本概念，以及不同类型的策略如何协同工作形成有效的权限。

IAM 策略概念

当你开始使用 IAM 时，你需要理解该服务是如何根据其内部逻辑评估策略请求的。以下是你需要记住的规则概览：

默认情况下，所有请求都会被拒绝（除非你是根用户）。
如果某项服务已被明确拒绝，则该规则优先，即使另一个规则允许该服务。
策略中的显式 allow 将覆盖默认的隐式 deny。
如果一个 SCP、会话策略或权限边界授予某项服务访问权限，那么它也会覆盖隐式的 deny。

为了更深入理解规则是如何处理的，我建议你阅读此处提供的文档：docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html。

在 图 3.4 所示的图示中，有三个圆圈。最底部的圆圈是基于身份的策略——即用户或组授予该有效用户权限的位置。然而，还有其他身份策略在起作用，这些策略可以限制——在某些情况下扩展——用户的有效权限。所有策略交汇的中心——在此情况下箭头指向的地方——是该用户的有效权限集，如下所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.4_B17405.jpg

图 3.4 – 有效的策略权限

通过了解这些不同类型的策略如何相互作用以形成有效的权限，我们现在可以开始创建我们的身份，包括角色、组和用户。

身份

当你首次创建 AWS 账户时，注册时使用的电子邮件账户将成为你的 AWS 根用户。尽管你可以使用这个根用户访问管理控制台，并且该用户拥有对 AWS 账户中所有服务和资源的完整无限制权限，但不建议你使用该用户来创建资源和工作负载。

在下图中，我们可以看到根用户位于 AWS 账户结构的顶部，然后我们的组会继承给用户和角色：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.5_B17405.jpg

图 3.5 – IAM 用户和组

一旦我们确定了要在账户中创建的组，并了解每个组或角色将继承的权限基础，我们就可以开始创建这些组。

IAM 组

以下是关于组的一些重要事项：

一个用户可以属于多个组，组也可以有多个用户。
组只能包含用户，而不能包含其他组，因此组不能相互嵌套和继承权限。
用户必须手动添加到组中。在创建用户或角色时，不会自动为其分配权限的默认组。

创建 IAM 组

在我们实际添加用户之前，让我们创建这些组并将 Amazon 托管的 IAM 策略与这些组关联，如图 3.5所示。我们将创建以下组，并将以下托管策略与它们关联：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.6_B17405.jpg

图 3.6 – 组及其关联的托管策略

现在我们知道要设置哪些组，让我们使用 CLI 来创建这些组，如下所示：

打开你的终端并输入以下命令，我们来创建第一个组（Admins）：
```
Admins at the end of it.
```

现在，让我们检查我们账户中的当前组，如下所示：

$aws iam list-groups --output text

注意我如何更改输出——对于我即将展示的四个组，这种方法不会占用像 JSON 格式那样多的页面空间。输出应该类似于此处显示的内容：

GROUPS  arn:aws:iam::470066103307:group/Admins  2021-03-11T22:36:46+00:00       AGPAW24Q7QQF4DBRNWTM4   Admins  /
GROUPS  arn:aws:iam::470066103307:group/Billing 2021-03-11T22:41:23+00:00       AGPAW24Q7QQF2FJB3ZW27   Billing /
GROUPS  arn:aws:iam::470066103307:group/Developers       2021-03-11T22:54:10+00:00       AGPAW24Q7QQF7NUSSDSWF   Developers      /
GROUPS  arn:aws:iam::470066103307:group/Testers 2021-03-11T22:51:26+00:00       AGPAW24Q7QQFZ6FIU6WDA   Testers /

一旦我们看到列出的所有组，我们就可以开始附加我们之前识别的托管策略。然而，在使用 CLI 时，我们需要知道grep来帮助我们的搜索，具体如下所示的代码片段：

grep command to quickly search through the output and find the exact name we were looking for. We were able to use some of the command-line flags to help narrow our initial search; however, there isn't a great option to search for a particular policy name. If you would like to read more about the options for the command, you can find all flags available on the documentation page listed here: https://docs.aws.amazon.com/cli/latest/reference/iam/list-policies.html.The output should look like this:

AdministratorAccess，这是第一个返回的结果。其他的返回是因为它们的名称中包含了 AdministratorAccess。

现在我们找到了托管策略的 ARN，我们可以将其附加到组中，具体如下所示的代码片段。一旦 IAM 策略附加到组，任何我们稍后添加的用户将自动获得这些权限：
```
$aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --group-name Admins
```
执行此命令后，它不会返回任何结果或反馈。
我们可以通过命令行检查我们的策略是否已附加到组中，方法如下：
```
$aws iam list-attached-group-policies --group-name Admins
```
这将返回我们刚刚附加到组上的策略，具体如下所示的代码片段：
```
{
    "AttachedPolicies": [
        {
            "PolicyName": "AdministratorAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AdministratorAccess"
        }
    ]
}
```
到此为止，我们暂时完成了这一步。我们需要创建用户以便将其添加到组中。

注意

我们也可以使用 CloudFormation 脚本来完成这项任务，这样可以更容易地回滚或清理我们刚刚创建的任何组。我们将深入探讨 CloudFormation 和基础设施即代码（IaC）的内容，在第七章中，使用 CloudFormation 模板部署工作负载。

IAM 用户

IAM 用户是有凭证访问和与指定 AWS 服务集进行交互的人员或应用程序。

当你创建账户时，你会自动成为根账户用户。

创建用户后，他们初始没有任何权限，且未经授权无法对 AWS 资源执行任何操作，直到你或其他管理员（或具有 IAM 权限的人员）通过内联策略授予他们访问权限，或者将他们添加到一个组中。

IAM 用户不能与多个 AWS 账户关联。

IAM 的用户部分也是你存储每个用户的安全外壳（SSH）密钥的地方，以访问 AWS Git 服务 CodeCommit。我们在第八章中才会深入探讨 CodeCommit，使用 CodeCommit 和 CodeBuild 创建工作负载；然而，理解密钥、用户和 IAM 权限之间的相互作用是很重要的，特别是当你希望你的用户能够自我管理、添加、移除和轮换他们自己的 SSH 密钥时。

如果你想为你的账户创建更多具有指定角色的用户，可以使用你刚刚创建的新角色，并按照第二章的步骤，基础 AWS 服务，来创建一个用户。

角色

IAM 角色允许你授权服务、应用程序和其他 AWS 服务在不将访问密钥和秘密访问密钥等凭证硬编码到应用程序中的情况下访问——或者对于用户而言，甚至创建一个访问密钥和秘密访问密钥对。

角色在切换账户时也非常有用。如果你有多个账户——例如，开发、测试和生产账户——你可以在开发账户中使用你的用户，然后在其他两个账户中创建角色，这些角色可以被你的主用户假设。

角色的另一个优点是它们可以由同一服务的多个实例承担（例如，EC2/Lambda）。就像在 IAM 组中一样，如果你需要为角色的策略添加更多权限或移除权限，这些更改几乎会立即生效。

对于 EC2，你会使用实例配置文件将角色传递给 EC2 实例。实例配置文件只能包含一个角色，这是一个无法增加的硬性服务限制。如果实例的权限需求发生变化，你可以移除当前附加到实例配置文件的角色，然后附加一个包含不同权限集的角色。

角色和角色假设也是一种提供访问给第三方的方式，这些第三方可能也有自己的 AWS 账户，但可能需要有限的访问权限。这可能是一个第三方合作伙伴，或者是一个只需要只读访问权限的审计员。

注意

对于本次练习，我们将需要两个账户，如下所示：

账户 A：这将是我们创建一个角色的账户，允许该角色被假设。

账户 B：这将是我们之前在操作的账户，我们将使用之前创建的一个用户来假设该角色并访问另一个账户。

在开始之前，最好知道账户编号，并将其保存在名为账户 A和账户 B的文本文件中。这样在我们开始设置角色的过程时会更加方便。如果您不知道您的 AWS 账户编号，找到它最简单的方法是点击主菜单顶部的用户名。下拉菜单出现后，其中一项是账户，显示您的账户编号。

我们首先进入账户 A，并创建一个角色，具体步骤如下：

使用具有管理员用户权限或能够创建 IAM 用户和角色的账户 A中的用户登录控制台。
访问 IAM 服务：console.aws.amazon.com/iam/home。
在左侧菜单中，点击角色。
一旦角色屏幕出现在主窗口中，点击标签为创建角色的蓝色按钮。
在下一屏幕上，您要选择的可信身份类型是另一个 AWS 账户，如下面的截图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.7_B17405.jpg

图 3.7 – 创建 IAM 角色
在账户字段中输入账户 B的账户编号，然后点击页面底部的下一步：权限按钮。
在S3FullAccess上。这将调出AmazonS3FullAccess策略。勾选此策略名称旁边的框。在勾选框后，参照下面的截图，点击页面底部的蓝色按钮，标记为下一步：标签：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.8_B17405.jpg

图 3.8 – IAM S3 完全访问策略
我们在本练习中不会添加任何标签，所以只需点击屏幕底部的蓝色按钮，标签为下一步：审查。
一旦我们进入AssumeS3，如果您想输入描述，可以输入（请参见下面截图中的示例描述），但这不是必要的。确保一切看起来正确，然后点击底部的创建角色按钮：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.9_B17405.jpg

图 3.9 – IAM 假设 S3 角色审查

现在我们已经在账户 A中设置了角色，可以退出该账户，然后重新登录到账户 B，以便使用我们创建的新角色，从主角色切换到账户 A中的AssumeS3角色，步骤如下：

一旦我们登录后，点击右上角菜单中的您的名字，显示下拉菜单（我们之前通过这种方式查找了账户编号）。
在下拉菜单显示时，点击菜单项切换角色，如下面的截图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.10_B17405.jpg

图 3.10 – 从 AWS 管理控制台切换角色
现在，在切换角色屏幕上，点击标签为切换角色的蓝色按钮。
在下一屏中，你将看到三个文本框需要填写，具体如下：

a. 在标有AssumeS3的框中）。

c. 在标有AccountA_S3的框中，如以下截图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.11_B17405.jpg

图 3.11 – 假设角色在账户 A

填入这些信息后，你现在可以切换角色了。
填入所有信息后，点击蓝色的切换角色按钮。
现在你应该已处于账户 A中，并且菜单栏顶部的颜色标示了AssumeS3权限，以及角色的显示名称，具体如以下截图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.12_B17405.jpg

图 3.12 – AWS 管理控制台显示成功切换角色

我们刚刚了解了角色如何帮助我们管理自己账户中的权限，同时也赋予我们在另一个账户中承担定义权限集的能力。接下来，我们将介绍如何通过权限边界在账户级别设置限制，并分享一些 IAM 的最佳实践。

权限边界

权限边界是 IAM 的高级功能，它允许你使用 AWS 托管策略，但为这些策略设置最大资源限制。在实际使用中，权限边界可以非常有用，允许你将具有所需权限的 AWS 托管策略应用到用户、组或角色上，并通过权限边界策略确保该实体不会访问超出所需的资源。

如果我们回顾一下图 3.4，可以看到身份基础的策略与权限边界策略的交集。两者之间的部分即为该实体的有效策略。AWS 提供的大多数托管策略允许在*）范围内使用。对于大多数组织，无论大小，这都是一个过于宽松的权限集。这不仅在组织的不同部门之间存在安全隐患，而且限制访问有助于减轻用户在意外情况下可能造成的影响范围。

IAM 最佳实践

让我们来看看在使用 IAM 时的一些最佳实践，如下所示：

不要使用根账户进行日常访问。根账户仅应在初始化管理员用户时使用，或在紧急/破玻璃场景中使用。
始终为根用户设置多因素认证（MFA）。此外，最佳实践是为任何账户管理员配置 MFA。尽量为所有用户启用 MFA。
设置一个密码策略，要求用户设置强密码，并定期更换密码。
不要直接将权限赋给用户；应使用组或允许用户承担角色—将权限集分配给角色，并允许用户承担这些角色。
不要让秘密以明文形式留在代码中。使用 Secrets Manager 或 Parameter Store 等秘密存储服务来安全地存储秘密。

在下一部分中，我们将学习如何将 AWS Organizations 作为你指导的一部分。

将 AWS Organizations 作为你指导的一部分

AWS Organizations 是一个帮助你整合多个 AWS 账户以便于管理和计费的服务。AWS Organizations 不仅帮助你在组织框架下快速轻松地创建新账户，还提供了在独立 AWS 账户中无法获得的治理功能。

与 IAM 相关的两个功能是 OU 和 SCP。

使用 OU 进行分离

要理解 OU，首先需要了解两个基本概念，如下所示：

组织
根账户

组织是你创建的实体，用于统一你控制下的不同 AWS 账户，以便你能够作为一个单元进行管理。一个主账户会分配给一个组织，该组织可以分支成零个或多个单元。许多时候，组织是以树状结构组织的，根账户位于顶部，OU 和子账户在下面分支。

根账户 是组织中所有其他账户的源容器。如果你将 SCP 应用于根账户，它会向下流动，并因此应用于所有组织账户和子账户。

OU 只是一个用于将账户分组在根账户下的容器。组织账户可以嵌套在其他 OU 单元中，从而创建你的组织层次结构，根账户位于顶部。

组织的功能

组织允许你在 AWS 账户之间集中管理策略。这有助于你通过使用 AWS Organizations 创建一个账户组，并将策略附加到指定的组，从而提升对 AWS 环境的控制，确保在这些账户上应用正确的策略，而无需任何自定义脚本。

你可以集成 AWS 单点登录（SSO），以便在一个地方简化为你的用户提供不同账户的访问权限。

SCP 允许组织为 AWS 服务、资源和区域管理权限保护措施。

AWS Organizations 还允许你轻松设置合并计费，为组织中的所有账户使用单一支付方式。这使你能够享受价格优势，如聚合使用量和不同服务的批量折扣，而这些在账户分开的情况下是无法获得的。

SCP

SCP 是一种工具，您可以使用它通过继承管理特定 OU 或整个组织的策略。它们可以增强或限制用户当前权限的范围，且在与高级 IAM 结构（如 Condition、ArnNotLike、StringNotLike 和特定区域）结合使用时最为有效，从而提供组织一致同意的保护措施，确保用户不会故意或无意地执行不当的操作。

SCP 示例

以下代码示例提供了一个 SCP 示例，您可以将其附加到组织的根级别，以确保如果有人要删除 EC2 或 关系型数据库服务（RDS）实例，则必须先提供多因素设备进行验证：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDeleteandTerminateWhenMFAIsNotPresent",
      "Effect": "Deny",
      "Action": [
        "rds:Delete*",
        "ec2:TerminateInstances"
      ],
      "Resource": "*",
      "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": false}}
    }
  ]
}

您会注意到 SCP 语法几乎与普通的 IAM 策略语法完全相同，包含 Effect、Action、Resource 和 SID。此 SCP 实际上有一个可选的条件值，在这里我们检查是否存在 MFA，如果不存在，则拒绝该操作。

将联合身份验证与 AWS 账户集成

如果将要访问您账户的用户已经拥有身份验证方法，那么有几种不同的方法可以将联合身份验证集成到您的 AWS 账户中。

“身份联合是一种两方之间的信任系统，用于验证用户身份并传递授权访问资源所需的信息。在此系统中，身份提供者（IdP）负责用户身份验证，而服务提供者（SP），如服务或应用程序，控制对资源的访问。”（AWS，2021）

当您集成联合身份验证时，您的用户将使用 STS 来请求一个会话以授权访问您的账户。

一个会话包含以下内容：

一个访问密钥
一个秘密访问密钥
一个安全令牌
一个过期日期（用于指示安全令牌何时不再有效）

默认情况下，联合令牌将在 12 小时后过期，但可以设置为在最短 15 分钟或最长 36 小时后超时。

联合令牌是通过几种不同的请求类型从 STS 服务发放的，其中列出了一些请求类型：

GetFederatedToken
AssumeRoleWithSAML

何时使用联合身份验证？

在某些场景下，联合身份验证在您的环境或账户中是非常适用的。首先是如果您有一个安全断言标记语言（SAML）2.0 兼容的企业目录。此类目录的例子有 AD 联合身份验证服务（AD FS）、Okta、Shibboleth 等。当您的目录符合 SAML 2.0 标准时，您可以将其配置为为 AWS 管理控制台提供 SSO 访问。

即使目录不符合 SAML 2.0 标准，您仍然可以为用户提供单点登录（SSO）功能。然而，在这种情况下，您需要创建一个身份代理应用程序来提供 SSO 访问。

你可能会使用联合身份验证的第二种场景是，如果你的用户通过第三方进行身份管理，例如 Web 身份。在这种情况下，Web 身份提供者（IdP）提供身份验证步骤，然后你可以使用联合身份验证授权用户访问他们需要的 AWS 服务。我们将在本章后面讨论如何使用 AWS Cognito 服务时进一步探讨这一点。

使用 AD 联合身份验证与 IAM

当你使用 AD FS 提供账户访问时，流程按以下顺序进行：

用户（或应用程序）向联合身份验证代理请求会话。
用户然后通过 AD 进行身份验证，以确保他们是活跃用户并且具有访问 AWS 云的权限。
接下来，AD 确定用户有权接收的权限数量。
然后，联合身份验证代理会从 AWS 账户中的 STS 服务发起 GetFederationToken 请求。
STS 服务随后返回联合令牌（包括访问密钥、秘密密钥和会话令牌）。
联合身份验证代理随后将令牌传递给用户。
用户然后可以向 AWS 账户发出 API 调用。

使用联合身份验证来访问你的 AWS 账户，对于拥有大型组织的用户尤其有用，因为这样你就不需要在 AD 和 AWS IAM 中分别管理用户了。它还可以帮助你绕过每个账户最多只能创建 500 个 IAM 用户的服务限制。

AWS 根据你的需求提供了多个不同的版本的 AD，接下来我们将讨论这些选项。

AWS 目录服务

AWS 根据你的需求提供了多种不同的云中使用 AD 的选项。AWS 目录服务提供了三个不同级别的服务，每个服务的用途不同。

AWS 目录服务 for Microsoft AD (MS AD)

如果你希望在云中运行托管服务版的企业版 AD，那么 AWS AD 服务是一个非常好的选择。该服务可以处理最多 50,000 个用户和最多 200,000 个 AD 对象。它还支持在多个区域中以高可用的方式进行部署。多区域复制仅在 AWS 托管 MS AD 的企业版中支持。

如果你有超过 5,000 个用户，并且当前没有 AD 服务器或无需在 AWS 云中管理用户和/或 AD 对象，那么 AWS 目录服务是你最好的选择。

使用此服务的一个缺点是，如果遇到性能问题，你没有很多可调整的选项。这毕竟是一个托管服务，目的是减轻你的管理任务。这也不适用于 Web 联合身份验证。

AD 连接器

如果您已经有一个本地的 AD 服务器，并且想要快速将其扩展到云端，那么 AD 连接器是一个不错的选择。AD 连接器不会在云端缓存信息，而是作为本地 AD 服务器的代理。这也意味着您不能在云端对 AD 连接器进行任何更改，所有更改和更新都必须在本地服务器上进行。

简单 AD

简单 AD 有两个版本：小型版和大型版。小型版支持最多 500 个用户和 2000 个对象，大型版支持最多 5000 个用户和 20000 个对象。如果这些数字无法满足您组织的增长需求，您需要考虑其他解决方案，例如 MS AD。

简单 AD 支持基于 Kerberos 的 SSO 身份验证，并且可以通过 CloudFormation 脚本快速启动。

重要提示

简单 AD 基于 Samba 4，并不是真正的 MS AD。它不支持与其他 AD 系统的信任关系，也不支持 MFA、PowerShell、AWS SSO 或 Amazon Chime 等功能。虽然如果您只有少量用户，或者需要为少量 Windows 机器提供完全合格的域名（FQDN）来使用云端服务，它是一个不错的选择，但请注意其局限性，尤其是在阅读考试题目时。

AWS SSO

即便 AWS 提供了丰富的服务，仍然有其他服务是您或您的客户可能希望作为 SaaS 服务集成，并且这些服务需要身份验证。与其让用户每次都验证自己对每个服务提供商（SP），AWS 使用其自有的 SSO 服务使这一过程变得简单。

即使您使用的是本地的 AD 或 Azure 基础的 AD，您也可以使用第三方身份验证服务，例如 Okta 或 Ping Identity，并且这些服务同样可以与 SSO 集成。

AWS SSO 使管理员轻松管理多个 AWS 账户，您可以快速且轻松地将用户及其角色映射到账户，并通过单一入口点进行管理。这样，您无需再设置 SAML 令牌或让用户去选择切换角色的账户。

选择用户身份策略

使用这些不同的方法来管理用户及其授权管理方式时，您可能需要一些关于何时使用每种方法的指南。

如果您有一个小团队，那么通常使用 IAM 组来管理最为合适。

如果您想使用联合身份验证来管理用户登录，并且已经有一个 AD 环境，那么通过 AD 实现 SAML 联合身份验证将是正确的选择。

如果您需要联合身份验证，并且尚未拥有 AD，且希望获得 AD 提供的额外功能，例如为 Windows 实例提供域名系统（DNS）管理，那么可以使用 AWS 目录服务。

然而，如果你需要联合身份认证，并且不想麻烦地设置和管理 AD 或承担许可费用，那么 AWS SSO 将是你最好的选择。

在 AWS 中安全地存储机密

作为一名 DevOps 工程师，负责通过部署管道对我们的基础设施和应用程序进行编码并部署，并不意味着可以省略诸如用户名、密码或第三方 API 身份验证等凭证管理。然而，这确实要求我们在更加安全和可重复的基础上进行身份验证，从而避免影响开发和测试，并且仅与那些真正需要知道的人共享访问权限。如果所有开发人员都在使用相同的应用程序，并不需要每个人都有数据库的用户名和密码。此外，如果你不直接将凭证分发给每位开发人员，而是让开发人员从秘密管理器中请求凭证，便可以减少每次人员变动时需要更改凭证的管理负担。虽然市场上有第三方解决方案可以执行此任务，但 AWS 提供了两种不同的本地服务，允许进行机密管理，甚至机密轮换。

AWS Secrets Manager

你可以使用 Secrets Manager 来存储、轮换、监控和控制对诸如数据库凭证、API 密钥以及 开放授权（OAuth）令牌等机密的访问。Secrets Manager 的主要特点之一是它允许通过 AWS Lambda 函数自动轮换机密。

不再需要将硬编码的机密存放在你的 IaC 或应用程序代码中，甚至不需要在启动时将其下载到实例并以未加密的易受攻击状态存储。现在，你可以通过调用 Secrets Manager 简单而安全地在需要时检索机密。

对 Secrets Manager 的访问也受到 IAM 策略的管控。用户或角色必须获得访问 Secrets Manager 服务整体或特定实例的权限，才能执行如存储和检索机密等操作。

Secrets Manager 的另一个功能是每次访问机密时，都会留下审计跟踪记录。这在高合规性行业中是一个非常有价值的功能。

你可能会想：什么是机密？ 在 Secrets Manager 中，机密通常是用于访问受保护设备的一组凭证（用户名和密码）以及连接详细信息。

Secrets Manager 中机密的基本结构

在 Secrets Manager 中，机密包含加密的机密文本以及多个元数据元素，这些元素表示机密并定义 Secrets Manager 应如何处理机密，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.13_B17405.jpg

图 3.13 – Secrets Manager 中机密的结构

现在我们已经了解了 Secrets Manager 如何存储和管理我们为安全存储而放入的密钥版本，让我们通过一个练习来创建和存储一个密钥，使用 AWS Secrets Manager。

在 AWS Secrets Manager 中创建和存储密钥

在以下练习中，我们将使用 AWS 管理控制台和 AWS Secrets Manager 安全地存储一个密钥。操作步骤如下：

打开浏览器，返回到亚马逊 Web 控制台。如果您的会话已过期，您可能需要重新登录。在顶部的搜索栏中，输入Secrets Manager，以使Secrets Manager图标显示。点击该图标以进入主AWS Secrets Manager页面，如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.14_B17405.jpg

图 3.14 – 主 Secrets Manager 页面
在主 Secrets Manager 页面或密钥列表页面中，一旦进入控制台中的Secrets Manager部分，点击存储新密钥。
在存储新密钥页面上，选择其他类型的密钥，如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.15_B17405.jpg

图 3.15 – 在存储新密钥页面上选择密钥类型
在指定要存储在此密钥中的键/值对下，选择密钥/值，这样您就可以将密钥作为键值对输入，如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.16_B17405.jpg

图 3.16 – 向您的密钥添加键值对及值到 Secrets Manager
对于DefaultEncryptionKey，如以下屏幕截图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.17_B17405.jpg

图 3.17 – Secrets Manager 加密
在第一个框中，输入username。在第二个框中，输入devopspro。
选择**+ 添加行**以添加第二个键值对。
在第一个框中，输入password。在第二个框中，输入MyTopSecretP@ssword#。

一旦我们输入了密钥的值，我们可以在 JSON 格式下查看它，以确保其正确性。
选择密钥的SecretString字段。
对于DefaultEncryptionKey，然后点击下一步。
在chapter3/SecretManager下。这会将您的密钥存储在一个虚拟的chapter3文件夹中。
对于Secret Manager Tutorial，然后点击下一步。
我们不需要轮换此密钥，因此选择禁用自动轮换，然后点击下一步。
在复审页面上，您可以检查您所选择的所有设置。如果您在应用程序中使用该密钥，请务必查看示例代码部分，其中包含可以粘贴到您自己应用程序中的代码，以便使用此密钥来检索凭证。每个标签页都包含不同编程语言中的相同代码。
要保存更改，请选择存储。

从 Secrets Manager 中检索您的密钥

现在我们知道如何使用 AWS 管理控制台保存秘密，我们将使用 AWS CLI 检索秘密，并查看它已成功存储。操作如下：

如果您之前关闭了终端，请打开它，并输入以下命令，以便我们可以检索秘密：

$aws secretsmanager list-secrets

执行上述命令后，应该会返回类似于以下内容：

{
    "SecretList": [
        {
            "ARN": "arn:aws:secretsmanager:us-east-2:470066103307:secret:chapter3/SecretManager-qBEqSh",
            "Name": "chapter3/SecretManager",
            "Description": "Secret Manager Tutorial",
            "LastChangedDate": "2021-03-15T21:55:53.828000-04:00",
            "Tags": [],
            "SecretVersionsToStages": {
                "83e08e0f-00d6-46d2-b05a-223041403f19": [
                    "AWSCURRENT"
                ]
            },
            "CreatedDate": "2021-03-15T21:55:53.783000-04:00"
        }
    ]
}

现在我们可以看到我们在 Secrets Manager 中以名称chapter3/SecretManager存储的秘密，我们可以通过运行以下命令来检索秘密：

SecretString field for you to use. You should also notice that it has returned the current value by default. We could have also asked Secrets Manager to return us back to the previous version of the secret stored if we needed that version of the secret.

我们刚刚使用 AWS Secrets Manager 成功创建、存储和检索了一个秘密。我们能够检索秘密的原因之一是因为我们的 IAM 角色赋予了我们这样做的权限。接下来，我们将查看 AWS 为秘密的安全保管提供的另一项服务：SSM 参数存储。

SSM 参数存储

参数存储是 AWS 提供的一项托管服务，用于存储字符串。这些可以是明文字符串，或者在将其用作秘密管理器时，它可以存储加密数据。访问这些参数受 IAM 策略访问的管理。

参数存储比 Secrets Manager 更灵活，如果您在那里存储标准参数，则没有费用，但参数数量有限制为 10,000 个。

存储在参数存储中的秘密和值可以从许多不同的 AWS 服务中访问，包括以下服务：

EC2
弹性容器服务 (ECS)
Secrets Manager
AWS Lambda
CloudFormation
CodePipeline
CodeBuild
CodeDeploy

如果您或您的团队正在寻找一种集中的方法来将秘密和配置数据与代码库分离，以及存储不同环境的不同值的能力，那么参数存储可能是一个不错的选择。

Secrets Manager 与 Parameter Store

当我们查看不同的 AWS 安全存储秘密的服务时，我们可能会想知道为什么选择其中一个而不是另一个。让我们快速比较这两种服务，看看它们的主要区别，如下所示：

如果您正在寻找一种不会增加预算的选项，则 SSM 参数存储是您和您的组织的正确选择。
如果您希望能够存储明文秘密，则 SSM 参数存储具有此功能。AWS Secrets Manager 无法存储明文值。

两种服务在安全性方面都是成比例的，因为两者都可以使用密钥管理服务 (KMS) 在静态时安全地加密值。

如果您希望能够自动轮换秘密，则 AWS Secrets Manager 需要成为您的服务选择。（使用参数存储，您将不得不手动轮换秘密。）

使用 Cognito 进行应用程序身份验证

Cognito 是一项服务，允许 Web 和移动应用程序通过用户名和密码或第三方身份验证社交 IdP（如 Amazon、Facebook 或 Google）来进行身份验证。Amazon Cognito 的三个主要功能是用户管理、身份验证和同步。Cognito 可用于协调外部用户通过第三方 IdP 进行身份验证。您还可以通过任何基于 SAML 的 IdP 联邦化您的用户。

使用 Cognito 的一些优势包括以下几点：

设置简便，您可以在几分钟内让集成到 AWS 服务中的身份验证和授权系统上线，而与之相对的，自定义编程同样任务所需的时间要长得多。
您可以快速而轻松地将 MFA 集成到 Amazon Cognito 中。
Cognito 指标可以通过 CloudWatch 服务轻松监控，无需额外的工作或编码。
对 Cognito 服务的任何 API 调用都会记录到 CloudTrail（假设您已为该帐户和区域启用 CloudTrail）。

您会在哪里使用 Cognito？

当您为外部客户（即不是您公司的一部分的客户）构建应用程序，并希望这些客户无论使用何种设备都能有相同的体验时，这时使用 AWS Cognito 就是一个合适的选择。Cognito 允许用户无论使用手机、平板、笔记本电脑还是 虚拟机（VM），都能拥有相似的登录体验。

使用 Cognito 的另一个案例是，如果您希望快速将 双重身份验证（2FA），如电子邮件或 简单消息服务（SMS）身份验证集成到您的应用程序中。

用户池

Cognito 的第一个主要组件是用户池。实际上，用户池提供了注册和登录服务。了解关于用户池的以下事实：

它们提供注册和登录服务。
用户池有一个内置的 用户界面（UI），并且可以自定义。
它们允许通过社交 IdP（如 Amazon、Google、Facebook 和 Apple）以及来自用户池的 SAML IdP 进行登录。
它们支持诸如 MFA 身份验证等安全功能，可以检查泄露的凭证，并具有帐户接管保护。
用户池支持电话和电子邮件验证。
用户池允许通过 AWS Lambda 触发器进行自定义工作流以及用户迁移。

一旦您成功通过用户池对用户进行身份验证，Cognito 就会发放一个 JWT，可以用于授权访问您的 AWS 凭证或 API，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.18_B17405.jpg

图 3.18 – Cognito 用户池身份验证

了解了用户池及其功能后，我们可以来看一下 Amazon Cognito 的另一个主要组件：身份池。

身份池

Amazon Cognito的第二个主要组成部分是身份池。身份池提供访问 AWS 服务的凭证。使用身份池，你可以为用户创建独特的身份，使他们能够临时访问 AWS 服务。

如果你查看图 3.17中显示的工作流，你会看到用户从其设备上的应用程序启动登录（通常是通过 Web IdP）。一旦通过 Web IdP 验证，GetId调用会传递给 Amazon Cognito，后者会验证请求。然后，应用程序会发出GetCredentialsForIdentity请求。Cognito 会再次验证此请求。此时，Cognito 将调用 STS 服务并为应用程序授权的服务获取一个短期令牌，然后将其返回给应用程序，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_3.19_B17405.jpg

图 3.19 – Cognito 身份池授权流程

身份池还允许你定义自己的自定义开发者认证身份，除了 AWS 支持的社交 IdP 进行身份验证之外。你可以在 Cognito 控制台中选择自定义，设置自己的名称，然后使用 AWS 提供的示例代码作为创建新自定义联邦身份池的基础。

记住的提示

用户池提供身份验证，身份池提供授权。

总结

在本章中，我们学习了 AWS 中的身份验证和授权方法。我们讨论了如何使用用户名和密码或通过 IAM 服务进行联邦授权用户，然后通过 IAM 策略对他们进行身份验证。AWS Organizations还向我们展示了如何通过使用 SCP 进一步限制授权设置。我们查看了与 AD、AWS SSO 和 Cognito 等服务的不同联邦模型。我们还了解了如何使用 Secrets Manager 或 SSM Parameter Store 安全地存储密钥，以便在开始与应用程序工作时使用。

在下一章中，我们将通过介绍 NoSQL 服务 DynamoDB 来总结 AWS 基础知识部分。

复习问题

在 AWS 为 IaaS 提出的共享责任模型中，谁负责操作系统的安全性和补丁管理？
在此处提供的选择中，用户和角色之间的主要区别是什么？

a. 角色可以由多个主体假定；用户不能被假定。

b. 角色使用长期凭证。

c. 角色可以是一个组的成员。

d. 角色不使用长期凭证。
授权和身份验证哪个先进行？
AWS 中哪个原生服务存储密钥并提供自动密钥轮换？
一家公司希望将当前的 AD 扩展到 AWS 云中，但不想管理更多的服务器。对于他们来说，哪个服务是最佳选择？

a. AWS 简单目录服务

b. AWS Cognito

c. AWS 用户池

d. AWS AD 连接器

复习答案

客户负责操作系统的补丁和安全性。
a 和 d。
认证。
AWS Secrets Manager。
d.