AWS的主要服务

EC2 即 Amazon Elastic Compute Cloud，提供可调整规模的计算能力，也就是虚拟服务器。S3 即 Amazon Simple Storage Service，将任意数量的数据作为对象进行存储。把这两者的角色互换的描述自古以来就很常见，需要能够从名称的拼写联想到各自的角色。执行函数代码的是 Lambda，共享文件的是 EFS。

Lambda 无需预置或管理服务器即可运行代码，只按所消耗的计算时间计费。代码未执行期间不会产生费用，这是它与只要在运行就会产生费用的 EC2 之间的重大区别。函数的数量或上传代码本身的容量并不是计费的单位。

无服务器并不意味着不存在物理服务器，而是指用户无需进行服务器的采购、配置和扩展。Lambda 被描述为「无需预置或管理服务器即可运行代码」，Fargate 被描述为「无需预置、配置和扩展服务器或集群」。物理服务器位于 AWS 一侧，由用户决定操作系统种类和补丁应用方针则是 EC2 这类形态的做法。

Fargate 是面向容器的无服务器按量计费计算引擎，无需预置、配置和扩展服务器或集群，可作为 ECS 或 EKS 的启动类型使用。Kubernetes 的托管运营是 EKS，由自己选择实例类型和台数的是 EC2 启动类型，将步骤定义为工作流的是 Step Functions。

ECS 的容量选项基本上有两种：无服务器、由 AWS 管理基础设施的 Fargate，以及由用户选择并管理实例类型和台数的 EC2。此外还有 ECS Managed Instances，以及面向本地环境的 ECS Anywhere。无论选择哪一种，负责容器的部署和扩展的都是 ECS，不同的只是由谁来照看底层基础设施。

EKS 即 Amazon Elastic Kubernetes Service，是一项托管服务，无需自行安装和运营 Kubernetes 集群，就能在AWS上运行 Kubernetes，并通过了 Kubernetes 一致性认证。数据库运维自动化由 RDS 负责，从靠近用户的位置分发内容由 CloudFront 负责，流量分流由 Elastic Load Balancing 负责。

Lambda 无需管理服务器即可运行代码，只按所消耗的计算时间计费，未执行期间不会产生费用。因此对于调用较为稀疏的处理，等待期间不产生费用的 Lambda 更有优势。让 EC2 或 EKS 集群始终保持运行的架构，在处理未运行的大部分时间里也会持续产生费用。

EC2 是一项在云端提供安全且可调整规模的计算能力的服务，官方说明其按使用量付费，并可以完全控制计算资源。只对执行时间计费、无需接触操作系统的是 Lambda，以对象为单位存储的是 S3，将工作流定义为状态的是 Step Functions 的性质。控制范围越广，操作系统的管理也就相应留给用户，这一点也需要一并记住。

ECS 即 Amazon Elastic Container Service，是一项全托管的容器编排服务，可以简化容器化应用程序的部署、管理和扩展。提供符合 Kubernetes 的集群是 EKS，启动虚拟服务器是 EC2，根据事件执行代码是 Lambda。ECS 与 EKS 都用于编排容器，区别在于是否使用 Kubernetes。

EKS 是一项托管服务，无需自行安装和运营 Kubernetes 集群，就能在AWS上运行 Kubernetes，并通过了 Kubernetes 一致性认证。而 ECS 是AWS的全托管容器编排服务，并不以 Kubernetes 为前提。两者都是处理容器的服务，并非只处理虚拟服务器镜像。作为启动目标，两者都可以选择 Fargate。

EBS 是供 EC2 实例使用的持久性块存储卷，在一个可用区内自动进行复制，原则上挂载到一个实例上使用。EFS 是面向 Linux 工作负载的文件系统，容量会自动伸缩，支持数千台 EC2 实例的并行共享访问。可以共享的是 EFS 一方，并不存在两者都面向共享、或都只能单独连接的情况。

S3 即 Amazon Simple Storage Service，是一种可以存储、保护任意数量数据，在可扩展性和可用性方面表现优异的对象存储。块存储是 EBS，面向 Linux 的共享文件系统是 EFS，内存缓存是 ElastiCache。对象、块、文件这三种数据形态的区别，是选择AWS存储服务时的出发点。

EFS 是一种文件存储，容量会随文件的增减自动伸缩，并支持数千台 EC2 实例的并行共享访问，适合让多台实例同时挂载同一目录的用途。EBS 是可用区内的块存储，原则上只连接到一个实例，因此每个实例的存储区域是各自独立的。Glacier Deep Archive 是取出耗时较长的归档存储类别，ElastiCache 并非文件系统，而是内存缓存。

EBS 是面向 EC2 实例的持久性块存储，在一个可用区内自动复制，提供一致的低延迟性能。由于这种单一可用区的性质，如果需要跨可用区的可用性，就需要其他机制。跨区域复制以及通过边缘节点分发都不属于 EBS 的作用。

S3 Glacier 是一组面向归档的存储类别，包括面向需要即时取出的数据的 S3 Glacier Instant Retrieval、面向极少访问的长期数据的 S3 Glacier Flexible Retrieval，以及以最低成本、耗时数小时取出的 S3 Glacier Deep Archive。其设计是根据取出速度与费用的权衡来选择类别，取出时间并非一律相同。可存储的数据种类没有限制，也不能作为块存储进行连接使用。

S3 是对象存储，EBS 是连接到EC2的块存储，EFS 是面向 Linux 工作负载的文件存储。可以整理为：对象是通过API整体存取的形式，块是从操作系统看来像磁盘一样的形式，文件是可从多台主机挂载共享的形式，这样按需求选择时就不容易迷惑。

EBS 是供 EC2 实例使用的持久性块存储卷，提供一致的低延迟性能，适合用作操作系统或数据库的磁盘。S3 是对象存储，并不具备将存储桶作为块设备连接的机制。Glacier 是取出耗时较长的归档类别，CloudFront 是用于加速分发的CDN。

S3 是一种可以存储和保护任意数量数据、在可扩展性、可用性、安全性和性能方面表现优异的对象存储，官方列举的用途包括Web、移动、备份、归档、物联网和大数据分析等。像磁盘一样被操作系统识别的是 EBS，以连接到1个实例为原则的也是 EBS，将数据放在内存中的则是 ElastiCache 的性质。

EFS 是一种简单、可扩展且具备弹性的文件系统，添加或删除文件时容量会自动伸缩，无需事先设计容量。先确定容量并将其固定，或为了扩容而重新创建，都是块存储的思路，连接的实例的内存量也不会决定容量。这种伸缩性正是它便于用作共享工作区域的原因。

S3 Glacier Deep Archive 是以最低成本保存极少访问的数据、取出需耗时数小时的归档类存储类别，符合这一条件。EBS 和 EFS 的设计都以保持取出速度为前提，用作长期休眠数据的存放地往往成本偏高。ElastiCache 是内存缓存，本来就不是用于长期保存的机制。先确定能接受多长的取出等待时间，是选择存储类别的思路。

RDS 是一项让在云端搭建、运营和扩展关系型数据库变得容易的托管服务，能自动完成硬件的资源准备、数据库的搭建、补丁应用、备份等管理工作。而表和列的设计、索引的判断、应用程序的构建、数据内容的合理性，这些仍然留给用户负责。所谓托管，是把运维的麻烦交给对方，而不是连设计也一并交出去。

Aurora 是托管数据库服务 Amazon RDS 的一部分，通过相同的管理控制台、CLI、API操作来完成资源准备、补丁应用、备份、恢复和故障检测。区别在于管理的单位：标准 RDS 管理的是单个数据库实例，而 Aurora 管理的是由复制同步的数据库服务器组成的整个集群。Aurora 是与 MySQL、PostgreSQL 兼容的关系型数据库，并非键值型。

DynamoDB 是一种支持键值型和文档型的 NoSQL 数据库，是一项全托管、支持多区域的数据库服务，能在任意规模下提供个位数毫秒级的性能。数据仓库是 Redshift，与 MySQL、PostgreSQL 兼容的关系型数据库是 Aurora，内存中的读写由 ElastiCache 负责。

Redshift 是云端的全托管PB级数据仓库服务，无论数据集大小如何，都能从现有的基于SQL的工具或BI应用程序中获得快速的查询性能。ElastiCache 是内存缓存，EFS 是共享文件系统，SQS 是消息队列，都不是承担海量数据统计和分析的基础设施。

ElastiCache 是一项能够在云端轻松部署、运营和扩展内存缓存的服务，通过从高速的内存缓存中获取信息、而不依赖基于磁盘的数据库，从而改善Web应用程序的性能。加快分析用查询的是 Redshift，降低长期保存费用的是 S3 Glacier 的存储类别，共享目录的是 EFS 负责的内容。

Aurora 是一款与 MySQL、PostgreSQL 兼容的全托管关系型数据库引擎，拥有高性能的分布式共享存储子系统，存储会根据需要自动扩展，无需预先确定容量再手动扩容。以键值对形式保存的是 DynamoDB，以耗时取出换取最低保存费用的是 S3 Glacier 面向归档的存储类别。

Redshift 是全托管的PB级数据仓库服务，适合从基于SQL的工具或BI应用程序中对海量数据进行汇总和分析。RDS 是让关系型数据库的搭建、运营和扩展变得容易的服务，适合业务系统读写日常交易数据的用途。两者都用SQL查询，看起来相似，但都不是 NoSQL，区别也不仅仅在于数据量。

官方说明 DynamoDB 是支持键值型和文档型的 NoSQL 数据库，能在任意规模下提供个位数毫秒级的性能。Redshift 适合海量数据的汇总与分析，是数据仓库；RDS 负责关系模型下的读写；EFS 是负责文件共享的存储，都不是以此条件为首要目标的基础设施。

RDS 即 Amazon Relational Database Service，是一项让在云端搭建、运营和扩展关系型数据库变得容易的托管服务。以键值对形式保存的是 DynamoDB，内存缓存是 ElastiCache，海量数据的汇总由数据仓库 Redshift 负责。另外，Aurora 是作为 RDS 的一部分提供的引擎。

Aurora 作为 RDS 的一部分提供，可以通过相同的管理控制台、CLI、API操作来完成资源准备、补丁应用、备份、恢复和故障检测。不需要另外搭建管理用实例，这些流程也无需用户自行搭建。与标准 RDS 管理单个数据库实例不同，Aurora 以整个集群作为管理单位，这是两者的区别所在。

SQS 是将消息保存在队列中，通常由一个消费者轮询取出的点对点服务。SNS 是发布者向主题发送消息，由多个订阅者同时以推送方式接收的发布订阅服务。把两者互换的描述是典型的混淆，也并非两者的分发方式相同。可以按方向记忆：队列是接收方前来取用的存放处，主题是发送方主动推送的分发角色。

SQS 有标准队列和FIFO队列两种，标准队列是至少一次（at-least-once）投递，因此同一条消息可能会送达多次。FIFO队列具备恰好一次（exactly-once）处理和顺序保证，能保持发送顺序并只处理一次。在顺序和防止丢失很重要的工作流中，会选择FIFO队列。

SNS 会将发送到主题的消息同时以推送方式分发给多个订阅者，订阅者可以指定为SQS队列。这种从一个SNS主题分发到多个SQS队列的形式，正是官方作为经典模式给出的扇出模式。队列是接收方而非发送方，因此不会出现队列去读取主题的方向。

SNS 的订阅者类型可以整理为两类：SQS、Lambda、HTTP(S)、Data Firehose 等指向应用间（A2A）的目的地，以及Email、移动推送、SMS等指向人（A2P）的目的地。并不限于其中一种，也不是只能以EC2实例为目的地的机制。正是这种广泛性，使得 SNS 既可用于面向人的通知，也可用于应用间的协作。

Step Functions 是一项创建工作流（即状态机）的服务，可用于构建分布式应用程序、实现流程自动化、编排微服务、构建数据和机器学习流水线。其中每个步骤称为state，正在执行的实例称为execution。流量的分流由 Elastic Load Balancing 负责，对象的保存由 S3 负责，键值对的缓存是 ElastiCache 的领域。

API Gateway 是一项可在任意规模下创建、发布、维护、监控和保护REST、HTTP、WebSocket API的服务，作为通往EC2上运行的工作负载、Lambda、任意Web应用程序等后端访问的前门发挥作用。执行处理本身的是后端一侧，统一应用保护规则的是 AWS Firewall Manager，在边缘进行缓存的是 CloudFront 的角色。

EventBridge 是一项使用事件连接应用程序各组件的无服务器服务，负责事件的接收、过滤、转换和分发。事件总线是将来自众多来源的事件路由到众多目标的路由器。等待队列是 SQS，状态机是 Step Functions，前门则是 API Gateway 的说明。

EventBridge Scheduler 是通过 cron 表达式或 rate 表达式来管理定时执行和一次性执行的机制，因此按固定时刻启动的需求由它来处理。SQS 是保存消息、供接收方取出的队列，SNS 是向订阅者分发的发布订阅服务，API Gateway 是发布并中转API的服务，都不是以按时刻启动为目的的机制。

SQS 是一项安全、具备高耐久性和高可用性的托管队列服务，用于集成分布式软件系统和组件，实现松耦合。受理方在将消息放入队列的那一刻就能返回响应，后续处理可以按自己的速度取出并推进，因此一方的延迟不容易拖累另一方。直接调用或整合成一个程序的架构，会让后续处理的延迟直接变成受理方的等待时间。

SNS 会将发送到主题的消息同时以推送方式分发给多个订阅者，订阅者可以指定为SQS队列，因此要将一次事件分发给3项处理，可以使用SNS主题加多个SQS队列构成的扇出模式。如果让3项处理共用1个队列，通常一旦其中一个取出，其余就无法再取得。由发生方发送3次，或由接收到的处理再转发的架构，每增加一个目的地都要修改发送方，无法实现松耦合。