回答:
最も単純な形式では、AMIは仮想マシンの説明です-仮想化のタイプ、アーキテクチャ（32/64ビット）、カーネル、およびルートデバイス。アマゾンの言葉で：
AMIは、Amazonの実績のあるコンピューティング環境で実行できるソフトウェア構成（オペレーティングシステム、アプリケーションサーバー、およびアプリケーション）を含むテンプレートです。
EC2インスタンスは、Amazonのハードウェアで実行される仮想マシンです。インスタンスを開始するには、最低限必要な情報がいくつかあります。さらに、異なるインスタンスタイプは異なる構成をサポートします（たとえば、32ビットAMIをサポートしないものもあります）。
各AMIには識別子（ami-a1b2c3d4など）があり、そのAMIの構成は作成後に変更できません。（ただし、起動時に、または場合によっては、インスタンスが起動された後でも、多くの設定をオーバーライドできます）。
ルートボリュームの観点から、AMIには既存のボリュームへの参照が含まれます（たとえば、AMIはEBSバックアップインスタンスのスナップショットを参照するか、S3バックインスタンスの場合はイメージパーツを参照します）。
AMIには、ある程度のエラーチェックも含まれています。通常、所有権を示すユーザーID、暗号化キー（イメージを暗号化する）、および署名（イメージの整合性を検証する）です。S3でバックアップされたインスタンスを作成するときに作成されたマニフェストファイルを見ると、AMIがどのようなものであるかを理解できます。これは、データと他のアイテム（ストレージ、カーネルなど）への参照を含む単なるファイルです。
イメージは、それをブロックデバイスマッピングとして参照します。デバイス（/ dev / sda1など）とデータソース（エフェメラル（および関連する場合はS3パーツ）またはebs-snapshot）を指定します。S3パーツは署名されており、ebs-snapshotsは変更（削除のみ）できないため、AMIからインスタンスを起動すると（設定を上書きせずに）、常に同じソフトウェア設定のインスタンスが生成されます。（同じAMIから起動されたインスタンスは、ユーザーデータまたは異なるブロックデバイスマッピングにより、実行状態が異なる可能性があります（たとえば、マイクロインスタンスには一時ストレージがありませんが、他のインスタンスタイプにはあります）。ここでは、接続されたボリュームはAMIとは別に保存されますが、ボリュームを変更できないようにAMIによって参照されます。
AMIからインスタンスを起動する前に、ブロックデバイスマッピングをオーバーライドできます（例：追加のEBSボリューム、またはインスタンスタイプがサポートしている場合は別の一時ボリュームを追加するため）。EBSボリュームの場合、インスタンスの起動後に、ルートボリュームをデタッチして、別のEBSボリュームを完全にアタッチできます。
だから、あなたの質問に簡単に答えると：インスタンスへのリンクですか、それとも保存されていて変更されていませんか？保存され、変更されることはありません。
また、イメージには、ローカルストレージとそのインスタンスにインストールされているすべてのパッケージなどが含まれていますか、それとも特定のインスタンスの構成の単なるコピーにすぎませんか？イメージには、ローカルストレージと、そのインスタンスにインストールされているすべてのパッケージなどが含まれます。（通常、これは単なるルートボリュームですが、複数のボリュームが設定されたインスタンスを起動するようにAMIを設定できます）。
AMIは、アーキテクチャなどのメタデータとともに、新しいEC2インスタンスを起動するために使用されるルートファイルシステムのマスターコピーです。これには、そのディストリビューションの新しいコピーを起動したときに通常見つかる完全なオペレーティングシステムとソフトウェアパッケージに加えて、AMI作成者が追加するのに適していると判断されたものが含まれています。
インスタンスからAMIを作成する場合、基本的にはそのインスタンスのルートファイルシステムのコピーを作成します。これは、後で新しいインスタンスを作成するために使用できます。
ここでの私の答えも役立つかもしれません：https : //stackoverflow.com/a/7895489/111286