先に結論
AWS を触り始めると、AMI とスナップショットがどちらも 保存 に見えて混ざりやすいです。
実際、どちらも EC2 や EBS を戻す話で出てくるので、初心者ほど区別が曖昧になりやすいです。
でも、この2つは同じものではありません。
似ているのは 復元に関わる という点で、役割はかなり違います。
この記事では、2026年4月28日時点で AWS EC2 User Guide、Amazon EBS User Guide、AWS Prescriptive Guidance の公開情報を確認しながら、AMI とスナップショットの違いを初心者向けに整理します。
まず一言でいうと
最初にざっくり分けるなら、こう考えると分かりやすいです。
つまり、
- サーバーを同じ構成でもう1台立てたい
- 同じ OS や初期設定を元にして起動したい
なら AMI が中心です。
一方で、
ならスナップショットが中心です。
スナップショットとは何か
AWS の EBS ドキュメントでは、スナップショットは EBS ボリュームの point-in-time copy、つまりある時点のコピーとして説明されています。
また、EBS スナップショットは増分バックアップで、最初はフル、以後は変更ブロックだけを保存する仕組みです。
ここで大事なのは、スナップショットが主に見ている対象は ボリューム だという点です。
たとえばできることは次です。
つまり、スナップショットは ディスクの中身をどう残すか に強いです。
AMIとは何か
AMI は Amazon Machine Image の略で、EC2 を起動するときの元になるイメージです。
AWS の EC2 ドキュメントや Prescriptive Guidance では、AMI には次のような情報が含まれると整理されています。
- 1つ以上のスナップショット
- 起動権限
- ブロックデバイスマッピング
ブロックデバイスマッピングというのは、起動時にどのボリュームをどう付けるかの定義です。
つまり AMI は、単なる 保存されたディスク ではなく、この内容でインスタンスを起動するための定義セット に近いです。
そのため AMI は、同じ構成のインスタンスを繰り返し起こすときに向いています。
関係はどうなっているのか
ここが一番混ざりやすいところです。
AMI とスナップショットは別物ですが、関係はあります。
AWS Prescriptive Guidance でも、AMI には 1つ以上のスナップショットが含まれると説明されています。
つまり関係を言い換えると、
- スナップショット: ボリュームのコピー
- AMI: スナップショットを含んだ起動用イメージ
です。
このため、AMI を作ると裏でスナップショットが関わることがある のは自然です。
でも、だからといって AMI = スナップショット ではありません。
何を復元したいかで使い分ける
実務では、違いを理屈で覚えるより、何を戻したいか で考えると整理しやすいです。
1. 同じサーバー構成をもう1台起こしたい
この場合は AMI が向いています。
たとえば、
- アプリ入りの EC2 を複製したい
- テンプレート化したサーバーを何台も起こしたい
- 同じ構成を別環境で使いたい
といった場面です。
AMI があると、毎回 OS から作り直さずに、近い状態から EC2 を起動しやすくなります。
2. ディスク内容を戻したい
この場合はスナップショットが中心です。
たとえば、
- 誤削除前の EBS に近い状態へ戻したい
- ある時点のデータだけ別ボリュームで見たい
- 既存ディスクを複製して調査用に使いたい
といった場面です。
このとき必要なのは 起動用テンプレート ではなく、ディスクの内容 だからです。
よくある誤解
AMIがあれば全部バックアップになる
AMI は便利ですが、万能なバックアップと考えると危ないです。
AMI は 起動しやすさ に強い一方で、個別ボリュームの細かな復旧や、論理バックアップのような粒度の細かい確認には向きません。
AWS Prescriptive Guidance でも、EC2 のバックアップでは インスタンス全体を AMI で取るか 個別ボリュームをスナップショットで取るか を分けて考える前提になっています。
スナップショットがあればそのままEC2を起動できる
スナップショット単体は、基本的にボリュームを作るための元です。
そこから EC2 を起動するには、AMI のような起動用定義まで含めて考える必要があります。
AWS の EC2 ドキュメントでも、ルートボリュームのスナップショットから AMI を作成できると説明されています。
この流れからも、スナップショットと AMI が別の役割だと分かります。
料金や保存の感覚も違う
スナップショットは、EBS のドキュメントで増分保存と説明されています。
つまり、同じボリュームに対して何度も取ると、毎回フルコピーを丸ごと持つ感覚とは違います。
一方 AMI は、裏で参照するスナップショットや起動定義を持つイメージです。
ユーザーの感覚としては、ボリュームの履歴管理 に近いのがスナップショット、再利用できるサーバーの元 に近いのが AMI です。
迷ったときの考え方
| やりたいこと | 向きやすいもの | 理由 |
|---|---|---|
| 同じ構成のEC2をもう1台作る | AMI | 起動に必要な定義をまとめて持てる |
| ある時点のディスク内容を残す | スナップショット | EBSボリュームの時点コピーだから |
| 誤削除後に中身だけ調査する | スナップショット | 別ボリュームとして切り出しやすい |
| OSや初期設定込みで再利用する | AMI | 起動テンプレートとして使いやすい |
AMIとスナップショットのよくある質問
Q. どちらをバックアップに使うべき？
A. 用途次第。サーバー全体の復旧 なら AMI、データボリュームだけ ならスナップショット。本番運用では 定期 AMI + EBS スナップショット の併用が定番。
Q. AMI 作成時に EC2 を停止する必要は？
A. 推奨。稼働中作成 も可能だが、整合性のない状態 で取得されるリスク。本番運用では 定期メンテナンス時間に停止 → AMI 作成 → 再起動 がベストプラクティス。
Q. AMI のコストは？
A. AMI 自体は無料、含まれる EBS スナップショットの容量で課金。1AMI で複数 GB のスナップショット保存料金。多数 AMI を作りっぱなしだとコスト増。古い AMI の定期削除運用が必須。
Q. 自動 AMI 作成の方法は？
A. AWS Backup、Data Lifecycle Manager、EC2 Image Builder、で自動化。日次バックアップ + N世代保持 の運用が標準。手動作成は事故の元。
Q. スナップショットからの復旧時間は？
A. 大型ボリュームでも数十分〜数時間。即座に使い始める ことは可能で、データは裏でバックグラウンドで復元(Lazy Loading)。データへの初回アクセスは遅め。
Q. AMI のリージョン間コピーは？
A. 可能。AMI Copy で別リージョンへ。東京 → us-east-1 のような DR 構成で使用。料金は転送料金 + 別リージョンでの保存料金が発生。
Q. AMI とコンテナイメージはどう違う？
A. AMI は OS全体 + アプリ の VM イメージ、コンテナイメージは アプリ + 依存ライブラリ の軽量イメージ。数分起動 vs 数秒起動 の差。最近は ECS、EKS でコンテナイメージ運用が主流。
まとめ
AMI とスナップショットの違いは、どちらも保存っぽい ところで混ざりやすいですが、役割はかなり違います。
- スナップショットは EBS ボリュームの時点コピー
- AMI は EC2 を起動するためのイメージ
- AMI にはスナップショットが含まれることがある
同じサーバーを起こすなら AMI、ディスクを戻すならスナップショット
この整理で考えると、どちらを使うべきかかなり迷いにくくなります。
バックアップや復旧の流れまで含めて見たい場合は、バックアップはあるのに戻せないを防ぐには？復元確認の手順と見落としやすい点を整理 や、誤終了時の判断なら AWSでEC2を停止ではなく終了してしまったときはどうする？まず確認すべきこと もつながります。
参考情報
- Amazon EBS User Guide: Amazon EBS snapshots
- Amazon EBS User Guide: How Amazon EBS snapshots work
- Amazon EC2 User Guide: Create an Amazon EBS-backed AMI
- AWS Prescriptive Guidance: Amazon EC2 backup and recovery with snapshots and AMIs