Answers:
AMI有两种类型（以及相应的实例）：
实例存储（有时称为基于S3）。这些不太常见，我不建议初学者使用。实例存储AMI是根实例存储卷加上一些元数据的副本，所有这些都以特殊格式保存在S3存储桶中
EBS引导。这可能是您正在使用的。EBS引导AMI 是 EBS根卷的EBS快照，外加一些元数据，例如体系结构，内核，AMI名称，描述，块设备映射等。
您可以拍摄EBS引导卷的快照，并通过向相应的元数据进行注册将其转换为EBS引导AMI。最棘手的部分是指定正确的AKI ID（内核），以便其正确引导。
主要区别在于所引用的服务类型之间。快照属于EBS卷，您可以在其中保存状态并在特定时间点使用相同的数据重新启动。
AMI很相似，但适用于EC2实例本身。您不能为非ebs备份的实例制作快照，但是可以创建一个实例的AMI（系统映像）。
通常，我使用EBS快照作为数据库卷的备份解决方案，并且使用AMI保存实例配置。
可以使用快照创建AMI。例如，使用单个“快照”可以创建多个AMI，例如使用同一快照创建一个PV和一个HVM AMI。
因此，快照具有系统/ OS数据。AMI是（快照+机器/硬件元数据）。
我也对此感到困惑。这是理解它的最简单方法：
EBS Snapshot 通常代表特定EBS卷的备份，它可以是任何卷（根卷，数据卷等）
AMI（Amazon Machine Image）是整个EC2实例的备份。例如，通过适当的配置，可以创建包括多个EBS卷的AMI。
现在，这听起来有些混乱，但是它们都存储为“ EBS快照”。
只要想一想：
EBS Snapshot 只是数据备份。AMI是特定时间的系统状态的表示。您也可以从中启动。EBS Volume是EC2背后的基础磁盘。Snapshot是特定时间点的备份，volume而AMI是整个EC2实例的备份，该实例可能具有多个附加卷，就像虚拟机一样。
使用Packer，您可以构建自动化的机器映像，包括用于EC2的AMI，用于VMware的VMDK / VMX文件，用于VirtualBox的OVF导出等。
EC2 <-- EBS Volume (Boot) + EBS Volume
^
|
Snapshot (only of specific volume)
^
|
AMI (Combined snapshots of all volumes, snapshot must have boot volume)
^
|
Launch a new Instance (same installed softwares and configs, different specs)
快照可用于备份驱动器/卷。这是增量备份操作，这意味着每次您对卷进行快照时，它将仅添加自上次备份（不是整个备份）以来添加/引入的新更改（节省了备份时间，空间和最终成本） 。
快照可用于：
定期备份驱动器
更改卷的类型，例如您有流量或读写操作，并且需要增加IO操作，因此请从 gp2到io1具有更高IOPs
定制AMI可用于：
为了进行灾难恢复，以防当前正在运行的EC2实例损坏并且无缘无故无法运行。
标准公司的AMI已安装了所有必备软件，从而简化了部署过程（例如，配置为连接到`Splunk，已安装一些监视和可观察性软件，已安装docker或已配置为在启动时连接Puppet或Chef）
AMI可用于轻松地在不同区域中部署应用程序。
使用所有已安装的软件及其配置将服务器升级到更高或不同的规格
可以在AWS账户之间公开共享AMI。
根据AWS提供的定义，
AMI是可以从中启动EC2实例的模板。EBS快照是EBS卷的块级副本。EBS卷可以是引导卷（即包含操作系统），也可以是仅数据卷（例如包含数据库文件）。您使用RegisterImage创建AMI（从快照）。
这是两个不同的概念，适用于不同的级别（EBS卷与EC2模板）。但是，这两个概念之间存在一些依赖关系。
对于EBS支持的EC2实例（即从EBS卷启动的EC2实例），AMI被实现为启动卷的EBS快照+几个元数据（机器的体系结构-32位对64位-类型）虚拟化-HVM与PV-等等...）
因此，对于EBS支持的EC2实例，AMI是EBS快照+ XML文件。您甚至可以根据自己拥有的启动卷的任何快照来创建自己的AMI。
快照用作备份策略的成本较低，因为当您拥有多个快照时，您只需支付一次完整备份的费用，而其余的备份实质上就是差异，并且通常要小得多。
您可以将AMI视为保留了OS和已安装组件的计算机的通用模板。
快照可以包括AMI的所有操作，还可以保存EBS卷的磁盘数据。
您决定使用哪个实例通常取决于您的实例是否支持EBS，以及是否要完全重新创建所有数据完整的机器还是只需要通用机器模板。