简介

AWS 基础知识课程旨在向您介绍在 AWS 中高效工作需要掌握的核心概念。

刚开始使用 AWS 时,您可能会觉得无从下手。原生云范式的基础设施构建与传统的本地方式天差地别。而且,无论这是您第一次处理基础设施,还是在过去十年间一直从事与 Linux 内核优化相关的工作,面对 AWS 精选的 175 多种服务,您都会感到无从入手。

AWS 基础知识课程旨在帮助您开始使用 AWS,新手和老手均可从中受益。在本课程中,我们将向您介绍 AWS 的五大支柱、考虑云时要使用的思维模式,以及与您最终使用的服务相关的关键概念。

 

结构

AWS 基础知识课程将分为五个模块。每个模块将遵循以下结构:

  • 简介:对我们将介绍的支柱的简短描述
  • 思维模式:一种指导性思维模式,可帮助您理解每个支柱中介绍的概念
  • 概念:涉及每个支柱的广泛基础主题的关键概念
  • 总结:对我们所讨论内容的总结
  • 进一步阅读:其他链接和资源
 

五大支柱

AWS 基础知识课程涵盖的五大支柱来自 AWS 架构完善的框架。架构完善的框架是在云上构建可扩展应用程序的十多年经验的结晶。

五大支柱包括以下方面:

  1. 安全性
  2. 性能效率
  3. 可靠性
  4. 卓越运营
  5. 成本优化
 

安全性

安全性支柱关注如何保护云中的基础设施。安全性和合规性是 AWS 和客户的共同责任。在此责任共担模式中,AWS 负责云的安全性。这包括 AWS 云服务的物理基础设施、软件和网络功能。客户负责云中的安全性。这包括特定云服务的配置、应用程序以及敏感数据的管理。

如果您的工作负载必须满足 FedRAMP、DoD SRG、ITAR、CJIS 或其他严格的合规性要求,或者它们包含归类为受控非机密信息 (CUI) 的数据,请参阅课程的 AWS GovCloud(美国)部分。

 

思维模式

思考云中的安全性时,采用零信任模式非常有用。

在此模式中,所有应用程序组件和服务都被视为离散的并且是潜在的恶意实体。这涉及基础网络结构、有权访问您的资源的所有代理以及在服务中运行的软件。

 

概念

当我们从零信任的角度来考虑安全性时,这意味着我们需要在系统的所有层级上应用安全措施。以下是在云中采取零信任的方式保证系统的安全性时涉及的三个重要概念:

  1. Identity and Access Management (IAM)
  2. 网络安全
  3. 数据加密

 

  • Identity and Access Management (IAM)

    IAM 是负责跟踪系统中身份和访问的服务。AWS 上的 IAM 服务就负责这部分功能。访问则通过 IAM 策略得到管理。这些策略对 AWS 内的代理划定访问边界。IAM 策略包含三个基本组成部分:

    • 主体指定向谁授予权限
    • 操作指定要执行的操作
    • 资源指定要访问的属性

    将零信任模式应用于 IAM 意味着采用最小权限原则。这意味着每个代理仅应拥有完成其职能所需要的最少权限

    IAM 策略可以应用于 AWS 主体或 AWS 资源。与主体相关联的策略称为基于身份的策略。与资源关联的策略称为 基于资源的策略。请注意,只有某些服务(例如 S3、KMS、SES)具有基于资源的策略。

    主体是否有权对特定资源执行操作取决于该主体的基于身份的策略是否允许其这样做,以及该资源的基于资源的策略(如果存在)是否禁止其这样做。

    请注意,这是对 IAM 权限模式主要的一种简化。还有许多其他策略类型会影响是否可以授予访问权限。这些包括权限边界组织服务控制策略访问控制列表会话策略。本课程暂不讨论其他这些策略类型。有关这些策略的更多详细信息,请参阅本模块的进一步阅读部分。

    要点

    • IAM 策略声明 AWS 中实体的访问边界
    • IAM 策略由主体、操作和资源构成
    • IAM 策略可用于实施最小权限原则
    • IAM 具有许多策略类型 - 基于身份和基于资源是其中之二
    • IAM 基于评估适用于给定资源的所有策略类型来评估访问权限
     

    进一步阅读

  • 网络安全

    网络安全涉及保障网络和网络可访问资源的访问和可用性的任何系统、配置或流程。AWS 提供了广泛的功能来保护您的网络,无论是在网络层面还是在资源层面。

    对网络安全采取零信任的方式涉及一种深度防御方法,该方法将安全控制应用于网络的所有层(而不只是最外层)。

    网络级别的安全性

    AWS 中基本的网络级基元是 Amazon Virtual Private Cloud (VPC)。这是一个逻辑网络,您可以定义该逻辑网络并将为其预置资源。

    以下是 VPC 的一些组成部分:

    • 子网:VPC 中的一个 IP 地址范围
    • 路由表:一组决定流量导向哪里的规则
    • 互联网网关:允许 VPC 内部资源与互联网之间进行通信的组件

    为了保护 VPC 中的流量,您可以将资源分为面向公众的资源和内部资源。为了减少攻击面,您可以使用诸如 Application Load Balancer (ALB) 之类的代理服务,来处理所有面向互联网的流量。然后,可以在内部子网中预置所有内部服务,例如服务器和数据库,这些内部子网与直接的公共互联网访问是断开的。

    除了 VPC,您还可以使用 AWS Web 应用程序防火墙 (WAF) 进一步限制进入您网络的流量。

    资源级别的安全性

    单个 AWS 资源也具有您可以配置的网络安全控制。最常见的控制称为安全组。安全组是虚拟防火墙,可以用来控制流入和流出资源的流量。使用安全组来仅允许从特定端口和可信源到您实例的流量。您可以将安全组附加到资源,例如 EC2 实例、RDS 实例和 Lambda。

    要点

    • 网络安全涉及旨在保护网络和网络可访问资源的访问和可用性的机制
    • 零信任的网络安全方法涉及在网络的所有层进行深度防御
    • VPC 和 WAF 让您可以在网络级别应用安全措施
    • 安全组让您可以在资源级别应用安全措施

    进一步阅读

  • 数据加密

    数据加密是一种对信息进行编码的过程,经过该过程后,任何不具备解密数据所必需的密钥的第三方都无法理解这些数据。

    对数据采用零信任模式意味着加密所有地方的数据,包括传输中和静止的数据。

    传输中加密

    传输中加密涉及数据在系统之间传输时对其进行加密。AWS 内的所有存储和数据库服务均提供 HTTPS 终端节点,这些终端节点支持对传输中的数据进行加密。AWS 还提供了网络服务,可以帮助您的服务实现传输中加密。例如,您可以使用 Application Load Balancer (ALB) 来强制到终端节点的连接使用 HTTPS。

    静态加密

    静态加密涉及对系统内的数据进行加密。所有 AWS 存储和数据库服务均支持静态加密。这些服务大多数默认已开启加密功能。加密不收取额外费用,而加密数据的性能开销则可忽略不计。

    大多数存储和数据库服务还直接与 Amazon Key Management Service (KMS) 集成。这是一项中央密钥管理服务,使您能够创建客户管理的密钥 (CMK) 来加密数据。

    您不仅可以使用 CMK 进行加密,还可以使用其他功能。这包括使用自己的自定义密钥存储的功能、通过与 AWS CloudTrail 集成来为加密资源创建审计跟踪的功能,以及实施自动密钥轮换。

    要点

    • 加密是对信息进行编码的过程,以使只有拥有正确密钥的各方才能解密信息
    • 通过在数据传输和静止时对其进行加密来保护数据
    • AWS 上的所有存储和数据库服务都提供静态和传输中加密
    • 您可以使用 ALB 等 AWS 网络服务来为自己的服务实施传输中加密
    • 您可以使用 CMK 解锁高级功能,例如创建审计跟踪、使用您自己的自定义密钥以及自动密钥轮换

    进一步阅读

    功能

     

    服务

     

    参考

     

     

总结

在本模块中,您学习了以下内容:AWS 的安全性支柱;零信任的思维模式;IAM 和最小权限原则;AWS 网络安全性和防护原理。数据加密以及如何对传输中的和静止数据进行数据加密。

 

进一步阅读

性能效率

性能效率支柱关注如何在云中高效、可扩展地运行服务。尽管云为您提供了处理任何大小流量的方法,但它要求您在选择和配置服务时要考虑到规模扩展。

 

思维模式

思考云中的性能效率时,将服务视为牛而不是宠物很有用。

在本地模式中,服务器昂贵,并且通常是手动部署和配置的。服务器实际交付并实际接入数据中心可能需要数周的时间。因此,服务器就像宠物一样得到照顾,每个服务器都是唯一的,并且需要大量维护。其中一些甚至拥有名字。

而云则将服务看作是牛。服务器是可以在几秒钟内自动预置的商品资源。没有哪一个服务器对于服务的运行是必不可少的。

 

概念

将服务器视为牛可以给我们带来许多与性能相关的好处。以“宠物模式”管理服务器时,将相同类型的服务器(甚至是同一服务器)用于多个工作负载是很常见的,因为订购和预置不同的机器太麻烦了。在“牛模式”中,预置既便宜又快速,这使我们可以自由选择最适合我们工作负载的服务器类型。

“牛模式”也让我们可以轻松扩展服务。由于每个服务器都是可互换的,并且部署迅速,因此我们可以通过添加更多服务器来快速扩展容量。

我们将关注以下两个性能效率概念:

  1. 选择
  2. 扩展
 
  • 选择

    在 AWS 上,选择是选择最符合工作负载需要的服务的能力。AWS 提供​最广泛的服务选择,涉及超过十二种类别的 175 多种服务。通过选择来实现性能意味着能够为作业选择合适的工具。

    典型的工作负载通常需要在 AWS 的四个主要服务类别中进行选择,包括计算、存储、数据库和网络。

    • 计算是处理数据的服务(例如,虚拟机)
    • 存储是数据的静态存储(例如,对象存储)
    • 数据库是数据的有组织存储(例如,关系数据库)
    • 网络处理您的数据的移动(例如,内容交付网络)

    在本模块中,我们将回顾如何在前三个类别中进行正确选择。请参考进一步阅读部分,以获取有关在不同网络选项之间进行选择的指南。

    无论您在哪个类别的服务中进行选择,都需要考虑三个方面。

    1. 服务种类
    2. 管理程度
    3. 配置

    服务种类

    在某个类别中进行选择时,AWS 为您提供许多可以使用的服务类型的选项。类型对于每个类别是唯一的。

    选择计算服务时,您需要确定使用基于 VM、基于容器还是基于无服务器的计算。

    • 基于 VM 的计算是大多数人最熟悉的思维模式,但价格可能更高,并且需要更多维护
    • 基于容器的计算可以让您更好地划分工作负载,并且可以快速扩展,但配置和编排更为复杂
    • 基于无服务器的计算可消除大部分管理和扩展复杂性,但存在硬性系统限制,并且需要采用新的工具链和流程

    选择存储服务时,您需要确定使用文件存储、块存储、对象存储还是存档存储。

    • EBS 这样的块存储服务非常适合持久存储来自单个 EC2 实例的数据
    • EFS 这样的文件系统非常适合让多个客户端访问同一数据
    • S3 这样的对象存储非常适合需要由任意数量的客户端访问的大数据 Blob
    • S3 Glacier 这样的存档存储非常适合访问不频繁的大量数据

    选择数据库服务时,您需要确定是否需要使用关系数据库、非关系数据库、数据仓库解决方案或数据索引和搜索解决方案。

    • 关系数据库让您可以拥有联接和 ACID 属性,但性能和数据存储存在上限
    • 非关系数据库具有更灵活的架构,并且上限比关系数据库更高,但通常缺少联接和完整的 ACID 功能
    • 数据仓库解决方案让您可以通过快速访问数 PB 的结构化数据,以实现大规模分析
    • 数据索引和搜索解决方案使您可以索引和搜索来自各种来源的数据
     

    管理程度

    确定服务类型后,您需要进一步精确到某个服务。对于特定服务类型,AWS 有时会提供多种产品。相同类型的各种 AWS 服务之间的主要区别在于其管理程度。

    使用计算服务并确定选择 VM 类型时,您需要在 EC2 LightsailElastic Beanstalk 之间进行选择。直接使用 EC2 可以让您获得最大的控制权,但管理却最少,而选择 Lightsail 则会牺牲一部分自定义能力,但可以获得更多的托管体验。而 Elastic Beanstalk 则介于两者之间,它为您的服务架构提供了一个固定的框架,但允许您通过配置进行自定义。

    当您使用存储服务时,选择服务会容易一些,因为对于任何一种类型,通常就只有一个服务(例如,对象存储为 S3、文件存储为 EFS)。

    使用数据库服务并确定选择关系数据库类型时,您需要在 RDSAurora 之间进行选择。RDS 使您可以更好地控制底层数据库,并且可用于大多数关系数据库。Aurora 仅适用于某些版本的 MySQL 和 PostgreSQL,但负责管理底层存储并内置集群支持。

    归根结底,服务的选择很大程度上取决于您对底层技术的熟悉程度,以及您对管理程度的偏好。

     

    配置

    决定要使用的服务后,您需要决定如何配置它。配置取决于您希望实现的特定性能特征,而这对于每种服务类别都有所不同。

    在评估计算服务的性能特征时,查看您的内存和计算需求是一个不错的开始:

    • 如果您使用的是基于 VM 的计算,那么内存和 CPU 会受到实例大小(例如 t3.small 与 t3.xlarge)和实例系列(例如 r3.small 与 c5.small)的影响。
    • 如果使用基于容器的计算,则可以分别设置内存和 CPU
    • 如果您使用的是基于无服务器的计算,则只能直接设置内存,计算(以及其他系统资源)的价值会随着可用内存的增加而线性增加

    请注意,根据您的工作负载的实际情况,您可能需要关注其他资源限制,例如网络容量和某些资源(例如实例存储)的可用性。

    在评估存储服务的性能特征时,需考虑延迟、吞吐量和 IOPS 需求:

    • 如果您使用的是块存储服务
      • 延迟受卷类型(例如,固态硬盘与普通硬盘)选择的影响
      • 对于大多数卷类型而言,吞吐量与卷大小成正比
      • 对于大多数卷类型而言,IOPS 容量与卷大小成正比
    • 如果您使用的是文件系统服务
      • 延迟和 IOPS 受您选择的性能模式的影响
      • 吞吐量受您选择使用预置吞吐量的影响
    • 如果您使用的是对象存储
      • 延迟受到与存储桶终端节点的地理距离的影响
      • 吞吐量受吞吐量优化的 API(例如分段上传)的使用的影响
      • IOPS 不可配置
    • 如果您使用的是存档存储
      • 延迟受到与存储桶终端节点的地理距离和检索方法的选择的影响
      • 吞吐量受吞吐量优化的 API(例如分段上传)的使用的影响
      • IOPS 不可配置

    在评估数据库服务的性能特征时,需考虑资源需求(例如,CPU、内存、存储等):

    • 如果您使用的是关系数据库
      • 资源能力取决于您选择的 EC2 实例
    • 如果您使用的是非关系型数据库,例如 DynamoDB
    • 如果您使用的是数据仓库解决方案,例如 Redshift
      • 资源能力取决于您选择的底层 EC2 实例
    • 如果您正在使用诸如 Elasticsearch Service 之类的索引解决方案
      • 资源能力取决于您选择的 EC2 实例

     

    要点

    • AWS 为您提供了很多服务和多种方式来帮助您实现目标
    • 在 AWS 上实施工作负载涉及从计算、存储、数据库和网络类别中选择服务
    • 在每个类别中,您可以根据用例选择合适的服务类型
    • 在每种类型中,您可以根据所需的管理程度选择特定的服务
    • 在每个服务中,您可以根据要实现的具体性能特征选择具体配置。
     

    进一步阅读

  • 扩展

    选择正确的服务对于起步很关键,而选择服务的扩展方式对于持续保持性能很重要。

    AWS 有两种主要的扩展方式:

    1. 纵向扩展
    2. 横向扩展


    纵向扩展

    纵向扩展是将底层计算升级为更大的实例类型。例如,假设您正在使用一个 t3.small 实例。纵向扩展此实例可能是将其升级到 t3.large。

    纵向扩展通常更容易实现,因为无需让服务形成集群。缺点是,与横向扩展相比,其上限(等于您的计算实例的最大大小)要低得多。它还会带来单点故障,因为实例中断可能会导致您的服务完全不可用。

     

    横向扩展

    横向扩展是增加底层实例的数量。例如,假设您正在使用一个 t3.small 实例。横向扩展此实例将涉及再预置两个 t3.small 实例。

    横向扩展需要更多开销。这是因为您需要代理服务才能将流量路由到您的服务群。您还需要执行运行状况检查,以将不良实例从路由池中删除,并选择最适合您的工作负载的特定路由算法。好处是,您最终可获得具有更大弹性的服务,并且相比纵向扩展具有高得多的上限。


    要点

    • 纵向扩展在操作上更简单,但存在可用性风险且上限较低
    • 横向扩展需要更多的开销,但可靠性更高,上限更高
     

    进一步阅读

总结

在本模块中,您学习了以下内容:AWS 的性能效率支柱;将服务器视为牛而不是宠物的思维模式;如何根据性能目标选择合适的服务和配置。扩展服务以及纵向和横向扩展之间的利弊得失。

 

进一步阅读

可靠性

可靠性支柱关注如何构建可抵御服务和基础设施中断的服务。与性能效率很相似,尽管云为您提供了构建可承受中断的弹性服务的方法,但它要求您在设计服务时考虑到可靠性。


思维模式

思考云中的可靠性时,将其看作影响半径很有用。您可以将影响半径视为发生系统故障时可能造成的最大影响。为了构建可靠的系统,您需要最小化任何单个组件的影响半径。

 

概念

当考虑影响半径时,故障不再是有没有的问题,而是 早晚的问题。在发生故障时,可以使用以下技术来限制影响半径:

  1. 故障隔离
  2. 限制


  • 故障隔离

    故障隔离通过使用通过故障隔离区分隔的冗余独立组件,来限制事件的影响半径。故障隔离区域会将任何故障对区域的影响限制在该隔离区内。

    AWS 具有三个级别的故障隔离区:

    1. 资源和请求
    2. 可用区
    3. 区域

     

    资源和请求

    AWS 服务根据给定维度(如资源 ID)对所有资源和请求进行分区。这些分区称为单元。单元被设计为独立存在,并在将故障限制在自身范围内。在背后,AWS 利用随机分区之类的技术来限制影响半径。每次您提出请求或创建资源时,所有这些都会以透明的方式发生,并且您不需要任何其他操作。


    可用区

    AWS 可用区 (AZ) 是完全独立的设施,具有专用的电源、服务和网络功能。可用区彼此之间在地理上相距较远,以免因火灾和洪水等环境危害而出现相关故障。

    通过在多个可用区中部署服务的冗余实例,可以在可用区级别实现故障隔离。这样做意味着一个可用区中的电源事件不会影响您在另一个可用区中的流量。

    关于延迟,尽管 AZ 在地理位置上是有距离的,但彼此之间的距离足够近,以至于 AZ 之间的网络延迟很小。这使得某些功能(如同步数据复制)可以在可用区之间实现。


    区域

    AWS 区域提供了最极致的隔离方式。每个区域都是一个完全自治的数据中心,由两个或多个可用区组成。通过在不同的 AWS 区域之间部署服务的冗余副本,可以在区域级别实现故障隔离(这正是 AWS 在自己的服务上所使用的方式)。

    如果您需要非常高的可用性,可考虑部署到多个区域。请注意,由于区域之间没有共享的基础设施,因此跨多个区域运行服务会产生大量开销。有一些服务和功能可以帮助您进行多区域构建。例如,您可以使用 AWS 的可扩展 DNS 服务 Route53 在不同区域之间路由流量。您还可以使用 DynamoDB 全局表S3 跨区域复制之类的功能来跨区域复制数据。


    要点

    • 利用故障隔离区来限制服务或基础设施中断的影响半径
    • 每个 AWS 服务在设计中都考虑了资源和请求级别的故障隔离,您不需要进行任何其他操作
    • 通过在多个可用区之间部署服务,可以在可用区级别实现故障隔离,并且对延迟的影响极小
    • 通过跨多个区域部署服务可实现区域级别的故障隔离,但这需要大量的运营开销


    进一步阅读

  • 限制

    限制是可用于保护您的服务避免承受过多负载的约束。它们是限制外部(例如,DDoS 攻击)和内部(例如,软件配置错误)事件的影响半径的有效手段。

    AWS 服务在每个账户每个区域都有特定于服务的限制。这些限制也称为服务配额。它们是您的 AWS 账户中某些资源、操作和项目的最大允许量。

    限制有两种类型:

    • 可以通过向 AWS 请求提高上限的软限制
    • 不能提高上限的硬限制

    每种服务都有不同的限制。要跟踪您的限制和请求提高上限,可以使用 Service Quotas 服务。

    监视服务限制并及时了解使用量是否接近服务限制很重要,这样可以避免服务中断。对于某些资源,例如并行 Lambda 执行,可以通过 CloudWatch 进行跟踪。其他资源(例如 EC2 实例的数量)需要手动或通过脚本进行跟踪。如果您有商业支持或企业支持计划,则可以使用 AWS Trusted Advisor 服务来跟踪限制。诸如 awslimitchecker 之类的开源工具也可以用于自动化该过程。


    要点

    • 限制是可用于保护服务避免承受过多负载的约束
    • 可以使用 Service Quotas 服务跟踪和管理 AWS 服务限制
    • 有可以提高上限的软限制和不可提高上限的硬限制
    • 监视您正在使用的服务的限制,并相应制定上限提升计划,以避免服务中断


    进一步阅读

总结

在本模块中,您学习了以下内容:AWS 的可靠性支柱;影响半径的思维模式;使用故障隔离区限制影响半径的方法;服务限制以及如何提高服务限制的上限以避免服务中断。

 

进一步阅读

卓越运营

卓越运营支柱关注如何不断提高运行系统、创建更好的程序并获得见解的能力。


思维模式

思考云中的卓越运营时,从自动化的角度来考虑它很有用。

人为错误是导致缺陷和运营事故的主要原因。自动化的操作越多,发生人为错误的机会就越少。

除了防止错误外,自动化还可以帮助您不断改善内部流程。自动化可将一套可重复使用的最佳实践推广到整个组织中。


概念

当您将运营视为自动化时,您希望将精力集中在当前需要最多人工操作且出现错误后可能导致最大后果的领域。您还将希望有一个流程来跟踪、分析和改善您的运营工作。

我们将关注卓越运营的以下两个概念:

  1. 基础设施即代码
  2. 可观测性


  • 基础设施即代码

    基础设施即代码 (IaC) 是通过计算机可读配置文件管理基础设施的过程。IaC 是实现基础设施自动化的基础。

    您无需创建手动预置服务,而是创建描述所需资源的模板。然后,IaC 平台将代您预置和配置资源。

    IaC 为您提供了一种声明式的自动预置基础设施的方式。它使您可以像对待代码一样对待基础设施,使用相同的工具(例如,git)和流程(例如,代码审查)。

    传统上,我们使用 CloudFormation 服务在 AWS 上实现 IaC。CloudFormation 需要使用 JSON 或 YAML 声明您的资源。如果您不喜欢这些配置语言,AWS 还提供了 Cloud Development Kit (CDK),让您可以使用 JavaScript、Python 和 Java 等本机编程语言来编写 CloudFormation 模板。

     

    要点

    • IaC 是通过机器可读的配置文件管理基础设施的过程
    • IaC 是一种声明式的自动预置基础设施的方式
    • 您可以对基础设施使用与代码相同的工具和流程
    • 使用 CloudFormation 和 CDK 等服务在 AWS 上实施 IaC
     

    进一步阅读

  • 可观测性

    可观测性是衡量系统内部状态的过程。通常这样做是为了将其优化到某个所需的最终状态。

    要实现卓越运营,您需要改进系统,而改善系统则要求您能够衡量系统。建立坚实的可观测性基础使您能够跟踪自动化的影响,并不断进行改进。

    实现可观测性涉及以下步骤:

    1. 收集
    2. 分析
    3. 行动


    收集

    收集是在评估系统状态时汇总所有必要指标的过程。

    这些指标可以分为以下几类:

    • 基础设施级指标
      • 这些指标由 AWS 服务自动发出,并由 CloudWatch 服务收集
      • 某些服务还会发出可通过 CloudWatch Logs 启用和收集的结构化日志。
    • 应用程序级指标
      • 这些指标由您的软件生成,可以由 CloudWatch 自定义指标 收集
      • 可以使用 CloudWatch Logs 存储软件日志或将其上传到 S3
    • 账户级指标
      • 这些指标由您的 AWS 账户记录,可以由 CloudTrail 服务收集


    分析

    要分析收集的指标,您可以使用 AWS 提供的众多数据库和分析解决方案之一。

    根据您的用例选择合适的解决方案:

    • 要分析存储在 CloudWatch Logs 中的日志,可考虑使用 CloudWatch Logs Insight,该服务可让您交互式地搜索和分析 Cloudwatch 日志数据。
    • 要分析存储在 S3 中的日志,可考虑使用 Athena(一种无服务器查询服务)
    • 要分析结构化数据,可考虑使用 RDS(一种托管的关系数据库服务)
    • 要分析大量结构化数据,可考虑使用 RedShift(一种托管的 PB 级数据仓库服务)
    • 要分析基于日志的数据,可考虑使用 Elasticsearch Service,这是流行的开源分析引擎 Elasticsearch 的托管版本。

     

    行动

    在收集并分析了指标之后,可以使用它们来实现特定的结果或流程。

    以下是这些结果和流程的示例:

    • 监控与警报
      • 您可以使用 CloudWatch Alarms 在系统超出特定指标的安全阈值时获得通知
      • 此警报可以触发手动或自动缓解措施。
    • 控制面板
      • 您可以使用 Cloudwatch 控制面板创建指标的控制面板
      • 您可以使用这些控制面板跟踪和改善服务性能。
    • 数据驱动型决策
      • 您可以跟踪绩效和业务 KPI 来制定数据驱动的产品决策

     

    要点

    • 可观测性是衡量系统内部状态以实现某些所需最终状态的过程
    • 可观测性由收集、分析指标并采取相应措施构成
    • 您可以在服务、应用程序和账户级别收集指标
    • 您可以通过 CloudWatch Log Insight、Athena、Elasticsearch Service、RDS 和 Redshift 等服务来分析指标
    • 您可以通过创建监视、警报和控制面板以及跟踪绩效和业务 KPI 来根据指标采取行动

     

    进一步阅读

总结

在本模块中,您学习了以下内容:卓越运营支柱;将运营视为自动化的思维模式;IaC 以及如何使用与当前用于代码的相同工具和流程通过 IaC 自动预置服务;可观测性以及如何收集、分析指标并采取相应行动以不断改进您的运营工作。

 

进一步阅读

成本优化

成本优化支柱可帮助您在最小化成本的同时实现业务成果。


思维模式

思考云中的成本优化时,将云支出视为运营支出而不是资本支出很有用。运营支出是一种持续的按实际使用量付费模式,而资本支出是一次性购买模式。

本地数据中心的传统 IT 成本主要是资本支出。无论最终是否使用,您都需要预先支付所有容量的费用。购买新服务器可能是一个漫长的过程,因为需要获得多方的批准。这是因为资本支出成本通常很高,一旦出现错误损失也很大。购买后,服务器仍可能需要数周才能实际投入使用。

在 AWS 中,您的成本是运营支出。您需要持续为所使用的容量付费。可以通过工程的方式实时配置新服务器,而无需冗长的审批过程。这是因为运营支出成本要小得多,而且如果需求发生变化,可以撤销。因为您只为使用的东西付费,所以任何多余的容量都可以简单地停止和终止。当您决定使用某个服务时,可以在几分钟甚至几秒内完成设置。


概念

从资本支出模式转变为运营支出模式,从根本上改变了基础设施的成本使用方式。您无需预付大量固定成本,而只需持续支付较小的可变费用。

此按实际使用量付费模式为您的成本优化带来以下改变:

  1. 按使用量付费
  2. 成本优化生命周期


  • 按使用量付费

    AWS 服务具有按使用量付费模式,您只需为使用的容量付费。以下是按使用量付费时优化云支出的四种常用方法:

    1. 合理调整大小
    2. 无服务器
    3. 预留
    4. Spot 实例


    合理调整大小

    合理调整大小是指让服务预置和配置与工作负载相匹配。对于基于 EC2 的服务,这意味着选择正确的实例大小和系列。如果您的计算资源大部分闲置,请考虑使用较小的 EC2 实例。如果您的工作负载需要大量特定的系统资源,请考虑转用针对该资源优化的实例系列。

    您可以使用 AWS Compute Optimizer 来根据过去的系统指标获得最佳的 EC2 调整建议,以更好地完成其过程。


    无服务器

    当您使用 Lambda 之类的无服务器技术时,只需为使用的部分付费。如果您的 Lambda 没有执行,则不会向您收费。无服务器是按使用量付费的最鲜明例子。在用例允许的情况下,选择无服务器可能是构建服务最具成本效益的方式。


    预留

    请求预留意味着承诺支付一定容量的费用以换取大幅折扣。对于 EC2,这可为您的计算带来高达 72% 的折扣。

    要为您的计算预留空间,可以使用 Savings Plans。您可以签订 1 年或 3 年期的合约,并承诺使用特定数量的计算,以在 EC2、Fargate 和 Lambda 上实现成本节省。

    请注意,预留并不是 EC2 独有的,因为您还可以为其他服务请求预留,例如 RDS、DynamoDB 和 CloudFront。


    Spot 实例

    EC2 Spot 实例使您可以利用未使用的 EC2 容量,最多可以以比按需价格少 90% 的折扣价格运行实例。这可以为您的容错工作负载节省大量资金。

    使用 Spot 实例时弊端是 EC2 可以随时回收容量。不过在回收之前,将提前两分钟向您的应用程序发送终止通知。


    要点

    • AWS 服务按时有没有付费,您只需要使用的容量付费
    • 您可以调整实例大小,以节省与您的工作负载不匹配的服务的成本
    • 您可以使用无服务器技术,来确保仅在客户使用服务时您才付出成本
    • 您可以通过预付费用进行预留,以获得折扣
    • 您可以使用 Spot 实例来获得运行容错工作负载的折扣


    进一步阅读

  • 成本优化生命周期

    成本优化生命周期是不断改善云支出的持续过程。

    它涉及以下包含三个步骤的工作流程:

    1. 查看
    2. 跟踪
    3. 优化


    查看

    在优化云支出之前,您需要首先了解支出的源头。

    AWS Cost Explorer 可帮助您直观地了解一段时间内的云支出。您可以按服务和类别等不同方面细分支出。使用 Cost Explorer 可以获取有关帐单的概述和详细报告。

    如果您需要更多精细的数据,则可以使用 AWS 成本和使用情况报告获取每小时的行项目。


    跟踪

    总体了解云支出后,就可以按照您关注的维度对其进行分组。您可以使用成本分配标签完成此操作。需要为每个要跟踪的标签打开这些。

    以下是标签类别的常见示例:

    • 应用程序 ID – 标识与特定应用程序相关的资源,以便轻松跟踪支出变化和在项目结束时将其关闭。
    • 自动化选择加入/退出 - 指示是否应将资源包括在自动化活动中,例如启动、停止或调整实例大小。
    • 成本中心/业务部门 – 标识与资源关联的成本中心或业务部门,通常用于成本分配和跟踪。
    • 拥有者 – 标识谁对该资源负责。这通常是技术拥有者。如果需要,您可以添加单独的业务拥有者标签。您可以将拥有者指定为电子邮件地址。使用电子邮件地址支持根据需要自动向技术和业务拥有者发出通知(例如,如果资源是弹性或合理调整大小的处理对象)。

    除了标签之外,您还可以使用 AWS 预算创建预算目标。使用预算,您可以监控自己关注的各个维度上的支出。预算会根据您设置的筛选条件,跟踪并创建您当前 AWS 支出的预测。


    优化

    在查看并跟踪了支出之后,您可以对其进行优化。优化支出涉及实施我们在按使用量付费部分讨论的技术。这种优化通常是总体预算目标的一部分。

    以下是优化目标的示例:

    • 成本节省计划覆盖的 EC2 实例的百分比 - 您的组织应争取 80%-90% 的覆盖率
    • 闲置资源百分比 - 闲置的定义和确切的比例将根据您业务的实际情况决定


    要点

    • 成本优化生命周期是不断改善云支出的持续过程
    • 成本优化生命周期包括查看、跟踪和优化支出三个阶段
    • 查看支出涉及使用诸如 Cost Explorer 以及成本和使用情况报告之类的工具
    • 跟踪支出涉及使用成本分配标签和预算,按与业务相关的维度筛选数据
    • 优化支出涉及将上一部分中提到的技术,作为实现总体预算目标的一部分加以使用


    进一步阅读

总结

在本模块中,您了解了成本优化支柱,学会了如何将以运营支出为主的模式运用于云支出,并熟悉了成本优化技术,例如合理调整大小、无服务器、预留和 Spot 实例。而且还了解了如何使用诸如 Cost Explorer、标签和预算之类的服务来查看、跟踪和优化预算。

 

进一步阅读

AWS GovCloud(美国)

本部分面向工作负载必须满足 FedRAMP、DoD SRG、ITAR、CJIS 或其他严格合规性要求或者其中包含归类为受控非机密信息 (CUI) 的数据的用户。

AWS GovCloud(美国)有助于达到联邦、州和本地级别美国政府机构以及航空、国防制造、执法、医疗保健、金融服务、能源和其他高度受管制领域的美国商业组织的特定合规性和法规要求。AWS GovCloud(美国)旨在将敏感数据和受管制工作负载托管到云中,它是由美国本土的美国公民员工运营的隔离 AWS 区域。

AWS GovCloud(美国)让政府客户及其合作伙伴可以灵活地构建符合以下标准的安全云解决方案:FedRAMP 高基准、美国司法部刑事司法信息系统 (CJIS) 安全政策、美国国际武器贸易条例 (ITAR)、出口管理条例 (EAR)、国防部 (DoD) 云计算安全要求指南 (SRG) 影响级别 2、4 和 5、FIPS 140-2、IRS-1075 和其他合规性机制。

从受控非机密信息 (CUI)、个人身份信息 (PII)、敏感患者医疗记录仪和财务数据到执法数据、出口受控数据和其他形式的 CUI,AWS GovCloud(美国)区域都可以帮助客户达到其云旅程中的每个阶段的合规性要求。

 

深度阅读

恭喜!

您现在已经完成了 AWS 基础课程。在本课程中,您学习了以下内容:

  • AWS 架构完善的框架的五大支柱
  • 代表着原生云对五大支柱的思考的重要思维模式
  • 五大支柱中每个支柱的关键概念

至此,您已经学习了在云中构建安全、性能高效、可靠、运营出色且成本优化的服务的基础知识。尽管这些都是一些基础知识,但却是您开启 AWS 之旅的良好起点。现在,您已经完成了 AWS 基础知识课程,不妨试着运用您所学的知识,在 AWS 上构建一个出色的服务吧。