回答:
AMI（および対応するインスタンス）には2つのタイプがあります。
インスタンスストア（S3ベースと呼ばれることもあります）。これらはあまり一般的ではないので、初心者にはお勧めしません。インスタンスストアAMIは、ルートインスタンスストアボリュームと一部のメタデータのコピーであり、すべて特別な形式でS3バケットに保存されます。
EBSブート。これはおそらくあなたが使用しているものです。EBSブートAMI は、EBSルートボリュームのEBSスナップショットと、アーキテクチャ、カーネル、AMI名、説明、ブロックデバイスマッピングなどのメタデータです。
EBSブートボリュームのスナップショットを取得し、適切なメタデータに登録することで、EBSブートAMIに変えることができます。これの最もトリッキーな部分は、正しく起動するように正しいAKI ID（カーネル）を指定することです。
主な違いは、参照されるサービスの種類の間です。スナップショットは、特定の時点で状態を保存し、同じデータで再起動できるEBSボリュームのスナップショットです。
AMIも同様ですが、EC2インスタンス自体のものです。ebsを使用しないインスタンスのスナップショットを作成することはできませんが、1つのAMI（システムイメージ）を作成できます。
通常、EBSスナップショットをデータベースボリュームのバックアップソリューションとして使用し、AMIを使用してインスタンス構成を保存します
AMIはスナップショットを使用して作成できます。たとえば、単一の「スナップショット」を使用して、複数のAMIを作成できます。たとえば、同じスナップショットを使用して1つのPVと1つのHVM AMIを作成できます。
したがって、スナップショットにはシステム/ OSデータがあります。AMIは（スナップショット+マシン/ハードウェアメタデータ）です。
私もそれで混乱しました。これを理解する最も簡単な方法は次のとおりです。
EBS Snapshot 多くの場合、特定のEBSボリュームのバックアップを表します。これは、任意のボリューム（ルートボリューム、データボリュームなど）である可能性があります
AMI（Amazon Machine Image）は、EC2インスタンス全体のバックアップです。たとえば、適切な構成で、複数のEBSボリュームを含むAMIを作成できます。
混乱するかもしれませんが、どちらも「EBSスナップショット」として保存されます。
そのように考えてください：
EBS Snapshot 単なるデータのバックアップです。AMI特定の時点でのシステム状態を表します。そこから起動することもできます。EBS VolumeEC2の背後にある基盤となるディスクです。Snapshot特定の時点のバックアップですvolumeAMIは仮想マシンとまったく同じように複数の接続されたボリュームを持つ可能性のあるEC2インスタンス全体のバックアップですが。
ではパッカー、あなたはEC2用のAMIを含む自動化されたマシンのイメージを構築することができ、VMDK / VMXは、VMware社のファイル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を使用すると、アプリケーションをさまざまなリージョンに簡単にデプロイできます。
インストールされているすべてのソフトウェアとその構成を使用して、サーバーをより高い仕様または異なる仕様にアップグレードします
AMIはAWSアカウント間でパブリックに共有できます。
AMIスナップショットとEBSスナップショットの違いは次のとおりです。
1）AMIは起動可能であり、ルートデバイスへのリンクが含まれ、他のデータボリュームのスナップショットへのリンクが含まれる場合があります。
2）AMIに含まれるデータイメージは、インスタンスが再起動されない限り、明確に定義された特定の時点を表しません。これは、通常、実稼働環境では受け入れられないものです。スナップショットは、正確な時点を制御できるため、一貫した方法で取得できます。スナップショットを開始する前に、すべてが「バックアップの準備ができている」ことを確認できます。
3）AMIは、Linuxではルートデバイスの既存のスナップショットから作成できますが、Windowsでは作成できません。
AWSが提供する定義に従って、
AMIは、EC2インスタンスを開始できるテンプレートです。EBSスナップショットは、EBSボリュームのブロックレベルのコピーです。EBSボリュームは、ブートボリューム（つまり、オペレーティングシステムを含む）、またはデータのみのボリューム（たとえば、データベースファイルを含む）の場合があります。RegisterImageを使用して（スナップショットから）AMIを作成します。
これらは、異なるレベルで適用される2つの異なる概念（EBSボリュームとEC2テンプレート）ですが、2つの概念の間にはいくつかの依存関係があります。
EBSでバックアップされたEC2インスタンス（つまり、EBSボリュームから起動するEC2インスタンス）の場合、AMIは、ブートボリュームのEBSスナップショット+いくつかのメタデータ（マシンのアーキテクチャ-32ビット対64ビット-）、タイプ仮想化の例-HVM vs PV-など...）
したがって、EBSでバックアップされたEC2インスタンスの場合、AMIはEBSスナップショット+ XMLファイルです。所有しているブートボリュームのスナップショットに基づいて、独自のAMIを作成することもできます。
AMIは、OSとインストールされたコンポーネントが保持されるマシンの汎用テンプレートと考えることができます。
スナップショットには、AMIが行うすべてのことを含めることができますが、EBSボリュームのディスクデータも保存できます。
どちらを使用するかは、インスタンスがEBSでサポートされているかどうか、すべてのデータをそのままにしてマシンを正確に再作成するか、または汎用マシンテンプレートが必要かによって決まります。
AWSが提供する定義から、違いを明確にします。AmazonMachine Image（AMI）は、ソフトウェア構成（オペレーティングシステム、アプリケーションサーバー、アプリケーションなど）を含むテンプレートです。AMIからインスタンスを起動します。これは、クラウドで仮想サーバーとして実行されているAMIのコピーです。一方、スナップショットの場合特定の時点のスナップショットを作成することで、EBSボリュームのデータをAmazon S3にバックアップできます。スナップショットは増分バックアップです。つまり、最新のスナップショットの後に変更されたデバイス上のブロックのみが保存されます。スナップショットを削除すると、そのスナップショット専用のデータのみが削除されます。