AWS 基础知识

安全性

思维模式

概念

• 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 基于评估适用于给定资源的所有策略类型来评估访问权限

   

  进一步阅读

  • 功能
    • 权限边界
    • 服务控制策略
    • 基于身份和基于资源的策略
    • 访问控制列表
    • 会话策略
  • 服务
    • 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 让您可以在网络级别应用安全措施
  • 安全组让您可以在资源级别应用安全措施

  进一步阅读

  功能

  • 安全组

  服务

  • VPC
  • WAF
  • ALB

  参考

  • 深度防御
  • AWS 联网和内容分发

  
  

• 数据加密

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

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

  传输中加密

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

  静态加密

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

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

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

  要点

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

  进一步阅读

  功能

  • CMK

   

  服务

  • KMS
  • CloudTrail
  • ALB

   

  参考

  • AWS 加密博客

   

   

总结

进一步阅读

性能效率

思维模式

概念

• 选择

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

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

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

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

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

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

  服务种类

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

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

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

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

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

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

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

   

  管理程度

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

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

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

  使用数据库服务并确定选择关系数据库类型时，您需要在 RDS 和 Aurora 之间进行选择。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 上实施工作负载涉及从计算、存储、数据库和网络类别中选择服务
  • 在每个类别中，您可以根据用例选择合适的服务类型
  • 在每种类型中，您可以根据所需的管理程度选择特定的服务
  • 在每个服务中，您可以根据要实现的具体性能特征选择具体配置。

   

  进一步阅读

  • 功能
    • 实例存储
  • 服务
    • EC2
    • ECS
    • Lightsail
    • Lambda
    • Elastic Beanstalk
    • EBS
    • EFS
    • S3
    • S3 Glacier
    • RDS
    • Aurora
    • DynamoDB
    • Redshift
    • Elasticsearch Service
  • 参考
    • AWS 联网和内容分发
    • 联网和内容分发服务
     
• 扩展

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

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

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

  
  

  纵向扩展

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

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

   

  横向扩展

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

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

  
  

  要点

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

   

  进一步阅读

  功能

  • Route 53 路由策略
  • ALB 路由策略

  服务

  • Auto Scaling
  • Route 53
  • Elastic Load Balancer

  参考

  • AWS 可扩展性博客
  • AWS Auto Scaling 博客

   

总结

进一步阅读

可靠性

思维模式

概念

• 故障隔离

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

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

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

   

  资源和请求

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

  
  

  可用区

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

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

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

  
  

  区域

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

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

  
  

  要点

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

  
  

  进一步阅读

  • 功能
    • DynamoDB Global Tables
    • S3 跨区域复制
  • 服务
    • Route53
  • 参考
    • AWS re:Invent 2018：AWS 如何最大程度地降低故障的影响半径
    • 区域、可用区和本地扩展区
    • 区域服务可用性表

   

• 限制

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

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

  限制有两种类型：

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

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

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

  
  

  要点

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

  
  

  进一步阅读

  服务

  • Service Quotas
  • AWS Trusted Advisor

  参考

  • 所有 AWS Service Quotas
  • 使用 Trusted Advisor 和 Amazon CloudWatch 监控服务限制

   

总结

进一步阅读

卓越运营

思维模式

概念

• 基础设施即代码

  基础设施即代码 (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

   

  进一步阅读

  • 服务
    • CloudFormation
    • CDK
  • 参考
    • 基础设施即代码 (IaC)
    • CloudFormation 属性参考
    • CDK API 参考
     
• 可观测性

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

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

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

  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 来根据指标采取行动
    

   

  进一步阅读

  • 功能
    • CloudWatch Logs
    • CloudWatch Logs Insight
    • CloudWatch 控制面板
    • CloudWatch 警报
    • CloudWatch 自定义指标
  • 服务
    • Athena
    • CloudWatch
    • X-Ray
    • CloudTrail
    • Elasticsearch Service
    • RDS
    • CloudTrail

  • 参考
    • AWS 分析服务概述

   

总结

进一步阅读

成本优化

思维模式

概念

• 按使用量付费

  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 实例来获得运行容错工作负载的折扣

  
  

  进一步阅读

  • 功能
    • RDS 预留实例
    • DynamoDB 预置容量
  • 服务
    
    • Savings Plans
    • EC2 Spot 实例
    • 计算优化器
    • Lambda
  • 参考
    • 合理调整大小
      
     
• 成本优化生命周期

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

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

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

  
  

  查看

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

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

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

  
  

  跟踪

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

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

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

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

  
  

  优化

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

  以下是优化目标的示例：

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

  
  

  要点

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

  
  

  进一步阅读

  • 功能
    • 成本分配标签
  • 服务
    • AWS Cost Explorer
    • AWS 成本和使用情况报告
    • AWS 预算

  • 参考
    • AWS 成本优化资源中心

   

总结

进一步阅读

AWS GovCloud（美国）

深度阅读